3 ms·

The state of QA, if there is such a concept, is not in a good place. To me, it's more divergently interpreted at each organization than any other role. For ex

The state of QA, if there is such a concept, is not in a good place. To me, it's more divergently interpreted at each organization than any other role. For example, this individual seems to work at a place where manual/automation overlap is taboo and gives rise to the issues described.

mikestew 10y ago
The state of QA, if there is such a concept There is, it just rarely applies to software. What all but a tiny fraction of a percentage of shops do is Quality Control. Were it actually quality assurance, when I file a bug on the 35 empty catch statements littering our code, there would be absolutely no debate on fixing it. But because we do quality control, dev has the option to say "no" when told to fix Pokémon-style try/catch statements. But on to your point, yeah, software testing is not in a good place and probably won't be for a while. For starters, software development is still quite young, and formal testing is even younger than that. So give it time. But as long as job descriptions for software testers start with "we're looking for people to break software!", we're not there yet. Because if it were up to me, we'd collectively be looking for people to tell us whether or not our shit works, not find esoteric bugs. Software verification can include finding esoteric bugs, but not limited to that. The difference is subtle, but very important. An anecdote to back my point: for junior testers I will often describe a blender, coffee grinder, what have you, and then ask them to describe a list of tests with bonus points for a rough outline of a test plan. 90% of the time a candidate will come up with creative ways to break the blender (put rocks in it, flip the switch 1000x), and yet fail to come up with a test case that tests what happens when I put ordinary food in the blender and flip the switch. Because we have, as an industry, fostered this idea of the tester's role as breaking things. That is an extremely naive, immature, and limited view of the software tester's role. When we can expand beyond that view, then we might begin to stand a chance of actually verifying software instead of throwing rocks in a blender.
- achievingApathy 10y ago
  This is absolutely true. Every tester that we get in at our shop has the break-it mentality, but that just comes as part of how some of these people are trained to get through testing technical interviews. Wishing that QA was more standard as part of software development is such a double-edged sword. We're going to end up with some very finely trained people who look at defects in only specific ways and no more "out of the box" thinking.

mikestew 10y ago

The state of QA, if there is such a concept There is, it just rarely applies to software. What all but a tiny fraction of a percentage of shops do is Quality Control. Were it actually quality assurance, when I file a bug on the 35 empty catch statements littering our code, there would be absolutely no debate on fixing it. But because we do quality control, dev has the option to say "no" when told to fix Pokémon-style try/catch statements. But on to your point, yeah, software testing is not in a good place and probably won't be for a while. For starters, software development is still quite young, and formal testing is even younger than that. So give it time. But as long as job descriptions for software testers start with "we're looking for people to break software!", we're not there yet. Because if it were up to me, we'd collectively be looking for people to tell us whether or not our shit works, not find esoteric bugs. Software verification can include finding esoteric bugs, but not limited to that. The difference is subtle, but very important. An anecdote to back my point: for junior testers I will often describe a blender, coffee grinder, what have you, and then ask them to describe a list of tests with bonus points for a rough outline of a test plan. 90% of the time a candidate will come up with creative ways to break the blender (put rocks in it, flip the switch 1000x), and yet fail to come up with a test case that tests what happens when I put ordinary food in the blender and flip the switch. Because we have, as an industry, fostered this idea of the tester's role as breaking things. That is an extremely naive, immature, and limited view of the software tester's role. When we can expand beyond that view, then we might begin to stand a chance of actually verifying software instead of throwing rocks in a blender.

achievingApathy 10y ago
This is absolutely true. Every tester that we get in at our shop has the break-it mentality, but that just comes as part of how some of these people are trained to get through testing technical interviews. Wishing that QA was more standard as part of software development is such a double-edged sword. We're going to end up with some very finely trained people who look at defects in only specific ways and no more "out of the box" thinking.