How a QA Team Fits into an Agile, TDD/BDD World

2 Comments

by Chris Durand, CTO

ChrisDurand-B360Let’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…

  1. 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.
  2. 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.
  3. 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.

Author: bridge360blog

Software Changes Everything.... Bridge360 improves and develops custom application software. We specialize in solving complex problems at every phase of the software development lifecycle, removing roadblocks to help our clients’ software and applications reach their full potential in any market. The Bridge360 customer base includes software companies and world technology leaders, leading system integrators, federal and state government agencies, and small to enterprise businesses across the globe. Clients spanning industries from legal to healthcare, automotive to energy, and high tech to high fashion count on us to clear a path for success. Bridge360 was founded in 2001 (as Austin Test) and is headquartered in Austin, Texas with offices in Beijing, China.

2 thoughts on “How a QA Team Fits into an Agile, TDD/BDD World

  1. Hi Alex, thanks for your comment! While the first line of my post is very much tongue-in-cheek (we are a QA services company after all!), there is actually a lot of truth to it. I’d also argue that no one wants developers, business analysts, scrum masters, or project managers. Customers want working software. They don’t care about how it comes about. If customers could push a button and get working software from a robot without all those pesky humans involved, they would do it. This is important to remember since people often get hung up on their roles and how they do things today. If there is a better way to do something that blurs (or removes!) the lines among traditional team roles, we need to embrace that since the software development industry needs to do more with less. QA professionals need to adapt to continue to add value to the software development process.

    BTW: The classic example of this idea is to think of a drill. No one wants a drill! They want a hole. If someone comes up with a better way of making holes that doesn’t involve a drill, we won’t use drills anymore.

    Thanks!
    C

  2. Hey Chris, you start off by saying QA is evil 🙂 had some bad experiences have you? Look QA is actually complementary to development not opposed.
    I’ve been doing QA in both corporate and remote environments and have met a lot of different teams.
    I wrote an article about the role of QA in Agile teams, check it out:
    http://softwareqapro.blogspot.ro/2014/04/agile-software-development.html

    Cheers

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s