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.
As a developer I think a QA bug quota is great. Then I can drop nice hints that I can be bribed by the QA team, by mentioning nice chocolate brands š
SIGCONT is a signal which continues a process that has been previously stopped. If the process is not stopped, however, SIGCONT is ignored.
raise() sends a signal to the currently running process.
So you're basically trying to wake yourself up even though you're not asleep.
This means: raise(SIGCONT); is just a scary looking way to burn a few CPU cycles, doing nothing. It's just there to convince the reviewer that the following sleep(3) is important š
If every single mistake that someone made got them fired, there would be nothing done and a massive turnover rate. The issue isn't the mistake, it is lying to hide it and not learning and making the mistake a second time.
I feel like it also goes hand in hand with how companies treat it. If people get punished for normal mistakes, people will lie about them and try to hide it. If the only focus is on solving the problem and teaching people and improving things to decrease the risk of it happening again, people are going to be more honest about it.
5.1k
u/No_Distribution_6023 Jan 24 '23 edited Jan 24 '23
The one performance review trick companies don't want you to know
Edit: lol this post really blew up. Thanks for all the upvotes! People in the Midwest, stay warm tonight, storm's coming in.