I've posted my thoughts about the decline, and eventual end, of the 'QA phase'.
one plus one
Shared publicly•View activity
- Nice find, especially within the comments. Some people totally disagree with him. Others partly agree - making the same arguments as I make in my article. I'll use my own team as an example of why simply 'firing QA' isn't a good idea for everyone (I still believe we should nix the 'QA phase' however).
We develop a software product that uses the Java runtime and is installed on customers' machines via a binary. This has two significant challenges:
1) The Java promise, like every other platform abstraction tech, doesn't quite deliver the 'write once run anywhere'. It does a good job, but we have differences between OSX, Windows and Linux that we have to adjust for. Likewise, when a bug comes in we need to have someone who knows these differences and can check if the reported bug, actually is a bug. This happens quite a bit. Many times, customers have a configuration problem that is the real cause of the 'bug' and not our software. This takes up so much time that we need a dedicated person to be constantly checking this - which leads to point #2...
2) Testing and handling bug requests takes time - lots of it. It's also very time consuming to have a developer handling all the tests involved and also to interact with the customers when gather more information. Our developer's time is best spent working on new features and fixing bug and not exploring and confirming bugs. Both takes LOTS of time. We find that a great combo is to have the QA engineer right next the developer and when a features or bug fix is being developed. The developer works on it and when they are 'done' QA can check it out and provide feedback right then that it does work in all the possible deployment environments.Dec 19, 2011
Add a comment...