Having a dedicated group of testers can be an invaluable resource when you’re a developer. But having testers (or maybe even a full-blown quality assurance department) doesn’t mean that a developer should avoid executing tests. Developers should understand how to most effectively use their own time, as well as the time of the testers.
Unit tests are useful and so are “sanity checks”
There are plenty of other people discussing how – from a developer perspective – unit testing is as important as “going to the gym” so I won’t belabour the point. But as a quality assurance (QA) professional I have experienced a marked difference between code that has extensive unit tests and code that does not. That said, I’ve also noticed improved quality amongst developers that do functional sanity checks. These checks became such a good indication of a project’s readiness for QA that we instituted a series of quality gateways here at The Nerdery to encourage this behavior.
So, what’s a “functional sanity check?” Short answer: Use your application/code/system as if you were a user. This can be as simple as loading up a website in Internet Explorer 8 to see if it looks remotely close to the way it does in Chrome. This could also be a meeting of the development team where someone drives through the application and everyone else has the chance to catch, triage, and assign defects as the team discovers them. Performing the most basic functional integration tests eliminates the easy-to-find issues.
As a project prepares to enter its QA phase, I’ve heard some developers say “why should I bother finding all these tickets when QA is just going to test everything?” This attitude is dangerous because at first blush it seems to make sense. No one wants to duplicate effort or make a project drag on longer than necessary. But in reality, projects are neither faster nor cheaper when all test activities are left to QA.
I’ve seen these projects slow to a crawl in their QA cycle. Their issue databases become quickly bloated with issues that are low-hanging fruit and – with the deadline quickly approaching – the time that could have been spent on final polish is instead spent on making sure the whole project doesn’t fall apart. The team inevitably faces the unenviable choice of either prolonging development to add polish, or “finishing” the project without a full QA cycle.
From a QA Engineer’s perspective, these projects are a source of frustration. Spending your days writing defect tickets for “Site does not load in Chrome” or “User cannot login” or “Order form does not validate submissions” is like being a home inspector and being asked to sign off on a house that has no walls and is on fire.
Let’s all do what we do best
On the opposite end of the spectrum, projects that have passed all of our internal quality gateways and were built by developers that are passionate about quality tend to breeze through their QA cycle. They hit their deadlines and satisfy clients and users. These successes are the result of developer/QA partnerships where both groups can leverage their unique strengths.
In this scenario, developers have helped mop up the obvious issues by performing unit tests during development and basic sanity tests as integration occurs. From there, QA Engineers can focus on helping the development team double-check each and every requirement in each and every environment, and test the boundaries of the application. Good QA Engineers will vigorously push the application in ways the developers didn’t consider. And that is where the partnership flourishes.
Developers, remember, are focused on making the application work. That’s their job. And so, they are the most likely people to see their code work. In counterpoint, QA Engineers are focused on verifying that the application works. That may seem a small difference, but it’s why QA Engineers are good at finding unexpected variations and results outside the “happy path” that developers have worked hard to create.
This push and pull is invaluable to developing high-quality software but is only possible when QA Engineers are forced to be creative. And they can’t be creative if all their time is spent documenting “fish in a barrel” defects. When a developer has tested enough to feel confident that “QA won’t find anything,” a QA Engineer must leverage all her/his testing skills to verify everything works. This translates into a highly motivated and engaged QA Engineer who will work very hard to help a development team meet the goals of the client and/or users.
And thus, instead of QA being a safety net that developers use to avoid testing their own work, QA helps push developers – and their the applications – toward the best possible final result.