Question: is it common for test guys to ask you for data that requires you to explicitly break your software? I mean literally remove safety checks from the software to generate such data? Cuz our test guys seem hell bent on breaking our system, even if it means supplying data that is illegal.

🤔 pretty sure something is wrong here.
But I can't tell if it is the dev, or QA.

say to him that he should try all he can, its HIS job to find errors.

Basically they want broken data for FQT to feed back into the system. Thing is that our system is the only thing that generates such data and has a number of safety checks to prevent the type of bad data they want from getting out.

We ended up finding a solution that would allow us to generate crap data without have to intentionally hack apart our baseline, but holy crap. They don't seem to realize that when you INTENTIONALLY break the system, that it will break.

What is the point of testing if not to break the system. I would do the same. Think of it this way... when the system will be feed broken data, and trust me... someday it will.... you wil know how to handle the situation

Here is the issue. We already test for broken and invalid data. We know how it handles bad data. It has been done. But there is a difference between bad data and unnecessary/useless testing. If you have a non-modifiable bounded dropdown, testing numbers outside of the bounds is not a valid test case, for example. At least not for an FQT.

Here is the issue. We already test for broken and invalid data. We know how it handles bad data. It has been done. But there is a difference between bad data and unnecessary/useless testing. If you have a non-modifiable bounded dropdown, testing numbers outside of the bounds is not a valid test case, for example. At least not for an FQT.

@projektaquarius That drop-down thingy should be tested though I think. Also outside the box, maybe by a security minded person?

@linuxxx maybe security testing, but I fell like bounds testing on the value could be accomplished via unit tests. Which is what we currently do on this erroneous data. It's pretty cool actually. We purposely overflow values etc.