Quality Assurance is the title given to someone who monitors the processes and methods used to ensure quality. In this article, we’re looking at why it’s important to have (software) Quality Assurance in particular. The methods by which this is accomplished are many and varied and may include ensuring conformance to one or more standards.
Loved By Clients, Hated By Developers
When developers are embedded with a QA resource, the overall quality of the delivered product goes up. Although the number of defects within the code will seemingly increase, this is actually because defects are brought to our attention more often – after all, that’s what a QA is there for – but that’s the result of a good QA tester and ultimately, will make the product being delivered better too.
Its also a great way to help your developers improve as coders; developers are notoriously proud and protective of their code. So the stigma of having defects opened against their code will bother them. Also, typically when there’s a QA in the room, there is more conversation about how the software should work. You can hear the general hum of questions in the room… “what if an error happens when I click on this form?” … “should I be able to click this button when logged in as a certain user?”.
Without QA, developers tend to leave testing until the end of the project. This can sometimes leave the outcome with poor quality software, riddled with defects. This isn’t to say that developers are doing a bad job! More that developers aren’t known for their love of documenting bugs so others can understand and patch.
QA Be Nimble, QA Be Quick
A QA can work in both Agile and non-Agile environments and can fit perfectly within the concept of a cross-functional team. Having a dedicated tester adds loads of benefits with most QA’s out of good practice doing regression testing; ensuring robust code remains just as or simply catching defects that have slipped through.
Of course, having a dedicated QA isn’t the only option for testing. There are other software development methodologies like Waterfall where you put the end product to a group of testers. However, though Waterfall sounds great, one of the reasons companies moved to an agile approach was because people realised that waiting until the end to test the software led to a lot of defects and more often than not, surpassing deadlines and missing the objective.
Other Options
Another approach is to have a centralised QA team; it’s quite similar to the Waterfall approach and doesn’t work as well for many of the same reasons. Although centralised QA is in the habit of testing more frequently and not specifically at the end of the project. It doesn’t however, promote a sense of everyone working towards the same goal. QA resources aren’t involved in the requirements gathering or accepting criteria, they do not work closely with developers and worryingly it seems, to create a wall between the development and testing team. This happens because these kinds of QA teams ensure objectives are met to the finest of details, leaving the client most happy but not necessarily the development team. It’s all about finding the right balance.
Developer Defects
As mentioned before, developers testing their own code doesn’t really work. They’re not usually afraid to admit they are not the best testers of software: can they write great unit tests? Sure. Can they write great load tests? Definitely. Can they write great automated tests? Without a doubt. But taking time away from coding and testing another developers code? Not so much.
They also don’t particularly enjoy writing defect documentation. Defects written by developers might not be that good; they can find themselves making assumptions about why it might not work and not put a lot of information for the other developer in the defect. They have a tendency to write it from the point of view that they’re the ones fixing it. Plus, what developers really have time to do all the testing for their work? I know that our team are always too busy coding.
Just as it is a developers job to be good at coding, it’s a QA’s job to be good at documenting defects. They should know all the businesses rules of the entire system much better than a developer usually does. Each developer might know a certain part of a system and know the low-level implementation, but might not understand all the ways a user might use the system. But a QA tester usually does and can provide that detail in the defect. Plus, if testing the system is a full-time responsibility, it makes sense that a QA would have more time to spend finding and writing defects… because that their full-time job.
Not All Developers Write Bad Defects
That’s obviously not to say that all developers write poor defects and that all QA’s write great defects. At the end of the day, what is most important is that the defects are well documented so that developers can understand and fix them. Defects not written properly can cause all sorts of problems, including miscommunication and misunderstanding between developers and the QA. It’s also a poor use of a developers time because they have to stop to get more information then get back to fixing the defect.
This is especially bad if the developers in question are from an agile team where their velocity can be affected by poor quality defects. And all this isn’t even including the fact that testing cycles can be wasted if they’re not fixed correctly due to poorly written defects.
The whole notion that developers shouldn’t be testers is not a new one. It is as valid today as it was 10 – 15 years ago.
Testing, A Strategic Move?
Testing uses three main strategies, unit, integration and regression. Unit testing is code tested in an isolated environment, integration is in conjunction with other new features or just in a more production-ready environment. For example, a door and a bed, both do as they’re supposed to. But as part of a room, problems could arise. I wanted to emphasise what an important benefit QA testing is as things in obscure parts of the software can be affected. Our QA ensures me he always tests for any regressions and although the defects should be low if you have a quality automated tests, it’s good practice, nonetheless.
For embedded QA resources and cross-functional teams, it’s important for automated tests to play the larger role in QA, leaving manual tests for the finer and more obscure features. Both add critical value to the development process. Having an embedded QA resource has a lot of benefits including, writing requirements and improving collaboration and communication on teams.
If you were unsure of dedication to quality prior, you’ll be assured now. A great QA model yields brilliance all round and for us, it seems to work best as part of a cross-functional team. It’s never perfect and will always need improvements but by utilising an embedded QA resource, quality and ideas are guaranteed to increase as testers and developers collaborate more. We get better requirements and we get better feedback We get better software and in return, happier clients. Ultimately adding to our successes as we retain and gain clients.