by Chris Durand, CTO
Let’s be honest, Quality Assurance is a necessary evil. Many of you have probably wondered why developers can’t just get it right the first time. Why do we pay developers to write bugs, and then pay testers to go and find them?
The answer simply stated is — writing software is hard. Software developers need to be extremely detail oriented, yet also keep the big picture in mind. They must balance short-term tradeoffs with long-term considerations. They often have to learn new tools and technologies with each project while balancing the demands of outside influencers. Oh, you needed that feature or bug fix done yesterday? And you want that application to work on all browsers released in the last 3 years (that’s 24 versions of Google Chrome alone since March 2011), plus mobile? It’s no wonder developers struggle to write perfect code every time.
While it can produce quality results, the old model of throwing code over the wall from the development team to the QA team is inefficient. We that build software have to do more for less, faster, and in a more complex environment than ever before. The rise of automated unit testing and Test- or Behavior-Driven Development (TDD and BDD) is an attempt to realize improvements. By testing at the core (that is, with the developer), we find bugs as early as possible (which yields tremendous savings as discussed in the post https://bridge360blog.com/2013/12/04/5-ways-qa-supports-development/). Automated unit testing also makes it easier to update the application going forward by identifying unexpected broken dependencies in the code before they get in front of a customer.
But unit testing is not enough. Just because you tested individual pieces of an application doesn’t mean it will all work together as expected. In 1999 NASA lost its Mars Climate Orbiter (http://en.wikipedia.org/wiki/Mars_Climate_Orbiter) because two software components that were thoroughly tested in separate environments did not work together once combined. Total cost of the project: $328 million. Oops.
So, as we ask developers to shoulder more of the burden of testing, what are the top 3 ways QA professionals are bringing value to agile teams? I’m glad you asked…
- Have Team Members Dedicated to Quality. Agile practices make quality a team responsibility, but don’t interpret that to mean ‘we don’t need any testers.’ Creating things and breaking things are different skill sets, and developers are focused on building things. Having team members with core strength in testing is crucial to ensure quality is not forgotten in the excitement to build the “Next Big Thing,” or rush something out the door to make a demo or ship date. Your QA team should be flexible enough to take on other team tasks besides testing within your agile team, but they can never lose sight of the fact that they are the last line of defense against bugs impacting customers. Your QA team should be involved from the beginning of your project working hand-in-hand with development to ensure automated unit testing is built into the core of your application. This should be supplemented by a solid quality plan, automated functional testing and, where necessary, manual testing. The QA team should also be the final judge of whether or not your product meets the quality standards set by your organization.
- Maximize Your Skill Sets and Productivity (and minimize your resource costs). The development team should work with the QA team to build test infrastructure into the application. Your development team should then use that infrastructure to test for the obvious (to them) test cases. The QA team can then flesh out those tests more extensively to improve test coverage and find all those edge cases that developers tend not to address and ensure your application meets your organization’s quality standards. It’s the 80/20 rule where 20 percent of the work will take 80 percent of the time. And the more cost-efficient QA resources should be working on that 80 percent, not the more expensive development team.
- Don’t Forget System and Integration Testing. Once you have many components or systems built, you must test that they all work together smoothly. A separate, dedicated QA team is well utilized doing integration testing of multiple components and systems, or you may need to bring in some additional testing resources for a few sprints to ensure this testing is done right to avoid Mars-Climate-Orbiter-like disasters.
Despite trends towards developers doing more testing, the role of the QA professional isn’t going away any time soon. Instead, the way QA teams are working is evolving rapidly to ensure applications are delivered more quickly, more efficiently, and with the right level of quality. It should be very interesting to see how the profession progresses over the next 5-10 years.