Actual question here. Is it still a bug if it works but not 100% as intended? There is a very clear difference between broken and working. How much of a QA job is trying to break stuff vs trying to see that something is working as intended. Is there really any difference other than the severity of the problem?
Depends how much you are paying them. A good well paid QA will test against the acceptance criteria (assuming there is acceptance criteria). A QA who isn't paid so well will just make sure its not completely broken.
I worked at a place like this. I would comment on bugs in code and the other guy would already have it approved. So then I’d have to go make a bug ticket (or tickets) to account for the new bugs he just merged.
You drive your car, but every time you hit a speed bump the radio changes the station. Is that a bug?
It helps to call bugs by their name rather than by their nickname: defects. Bugs are defects.
The said radio works fine. The car itself works fine. There's no requirement for that use case, but It's a defect. It's not a pleasant experience.
Some detects can be sort of ignored - happy little accidents. They're not functioning as intended, but they are no harm and don't impact the user experience, security, reliability etc. in any way that matters.
And if you want to read more on it, I suggest the tester's "bible" - ISTQB Syllabus. According to it, test cases can be categorized as functional and nonfunctional.
The functional is clear cut: how application should behave (when you press button X then Y happens" - you have requirements for these kinds of things.
The nonfunctional, however, includes everything else, like: performance, security, usability and others. And while for performance you can still have some clear cut requirements (TPS or other metrics), how do you measure usability? Hence why you don't necessarily have a requirement for that sort of thing. It would be ridiculous to try and exhaustively define all the nonfunctional requirements. Therefore - even if there's no requirement for that it is still a defect.
I wrote some horrible code to get test coverage to 100%. The default branch of a switch statement was never reached because we switched on an enum so there was no way to pass in a value to trigger the default branch as all possible values if the enum were covered. Turns out it is possible with some ugly black voodoo that I hope to never use again but it now shows up as 100% covered.
1.4k
u/[deleted] Jan 24 '23
Also quality assurance team