The power of quality assurance
- Processes, standards and quality
Once upon a time, there was a young Project Leader. There were also two Developers and one quality assurance engineer in his project. Or, if you wish a QA. The team was making a product of the highest quality, safeguarded by QA who was responsible for different functions to be covered with regression tests. Each feature was checked with those tests – the team was always sure that its product dit not contain critical bugs.
Everything was nice and idyllic. One day, the rotation of team members was made…
… and there are a few versions of what happened next:
… one of Developers left the project. Although it was a huge loss, there was already a „fresh” Developer to take his place. But he did not seem promising. Well, they had to wait until the end of trial period, he had to have his chance.
„Damn it!” – the Project Leader thought – „we will be in trouble, if that guy writes poor codes. The other Developer will have to correct everything he had done, development will slow down, and the code will break down”.
And he was right – new Developer was not very good, he spoiled a lot in code.
The release date was coming – version was frozen, QA started tests, many bugs were found (made by a newcomer…), Developers had to manage the situation. After a while the tests were good and a proper version was released.
Finally, the client got a stabile version, code quality was a little bit lower, and new Developer got fired. The other Developer was a little disgusted with a mess left in code.
… QA left the project. Although it was a huge loss, there was already a „fresh” quality assurance engineer to take his place. But the first impression of him was not too good – unfortunately, he was on a trial period, so he had to have a chance.
„Well…” – the Project Leader thought – „…I have got two great Developers in my team, I have good regression tests coverage . Code quality will not get any worse, and as for application stability, we will check all tests and bugs before releasing”.
And they were all working – Developers were making codes of the highest quality, new QA was testing something, somehow.
The release date was coming – version was frozen, QA and Project Leader started tests (leader decided to help newcomer, because there were a lot of tests to be checked). Some bugs were found, Developers repaired them. When tests started passing, the new version was released.
But it did not work.
Anny attempt to use one of the most important new functions messed up the entire application.
The client went off at the deep end – he got tests report together with new application and everything was green!
It turned out that new QA missed out few test cases and mistakenly marked them as „passed”. It happens.
The conclusion is that quality assurance engineers have extremely responsible tasks. They are the last line of defence against bugs. They are the client’s peace guarantee. Having a feeble QA is way more dangerous and risky than having a feeble Developer*.
Your client does not care if the code is botched – what really matters for client is that it works. He will not pay for those that do not work. And it is our beloved QA’s job to verify the working of application.
(Of course, we are not considering situation when there is a QA in team, so – called „clicker”, whose work is based on „hey, check if it is working”. In such case it is pointless anyway).
* of course, the most dangerous and the riskiest is not having a QA at all ;>.