What is a development team without QA?

, Dog owner, expat, gin lover. Allegedly wise to the ways of digital marketing, PR, and social media. Currently waging a war on mediocrity in communication and storytelling.

Predicting the death of Quality Assurance (QA) testing isn’t anything new. The argument goes that modern software development eliminates the need for QA teams. DevOps teams exist in a constant state of development, so the theory goes that they will automatically test features as they’re moved from staging to production.

There are a few problems with that idea though.

DevOps tends to look for automation of testing.

While that is a great way to test quickly and should be used in QA testing, automation is inherently narrower in scope. DevOps can only automate to look for a series of issues with the goal being to get the system to pass the test. If you’re a developer, do you really know what tests to automate? Your sole goal would be to get the automated test over with a pass, so you can move on to the next feature. Therefore, the DevOps automation testing tends to be quite simple and narrower in scope than a QA team.

The forest for the trees

Developers tend to be too near to the product. A QA team can give tests an outside perspective. After all, they didn’t build it, so they’d be more able to highlight possible issues that a development team might overlook. Developers have a vested interest in writing bug-free code, to prove that their team is great. The inverse of that, of course, is a team of QA testers whose goal is to find flaws. It’s a perfect balance.

Automation vs. Manual testing

As previously stated, automation tools are a great way to augment a testing team. It can take redundant tasks that come with constant iteration and give you the same standard feedback on each automation. What manual testing does, however, is give your team a chance at exploratory testing. This is especially true with QA teams. They will look at several different scenarios of a piece of software that a user might face. This is actually the creative part of testing that really can’t be automated. It’s also the main reason why QA teams are an important part of the development process.

Developers won’t usually look at creative ways to use the software, because they already know exactly how it was designed to function and will usually stay within those limits while testing. The end-user, and likely the QA teams, weren’t part of the design discussions though. Users will use software in a multitude of ways and developers need to test for as many scenarios as possible to ensure a consistent experience.

Quality of the team is everything

Just like in devops teams, QA teams should be built with a variety of experience and skillsets. Most team members bring their own expertise to testing and should be utilized to get the best results of the project. Likewise, a QA team manager will know the strengths of their team and make sure that they have the best person for each individual part of the testing phase. It should also be pointed out that the diversity of a team highlights those creative scenarios.

If your QA team has a team member that isn’t as experienced in a certain area of testing, that doesn’t mean that that team member shouldn’t be included. You want to diversify your team as much as possible and common side-effects are that you get a new perspective that the expert tester didn’t see and you get to train across your team for more in-depth experience.

Agile vs. Waterfall

QA and DevOps are on the same side, not mortal enemies. QA brings expertise and an outside perspective to the dev process. The sooner these two teams can work together, the better. In waterfall development, the testing starts rather late, but with Agile becoming more popular for development teams, QA is brought in earlier. This gives QA teams a chance to be more involved in the development process and head-off problems before they arise.

Early collaboration helps teams focus on building quality product instead of trying to dodge the testing team that arrives late. Product buy-in is an important part of QA too and shouldn’t be left to developers alone. Each team needs to focus on highlighting, not only the good parts of the product but also actively seek to eliminate shortfalls.

Conclusion

By bringing QA teams in early in the development process, companies can build a shared trust on both sides of the process. While automation will increasingly be used by DevOp teams, it doesn’t eliminate the need for creative and exploratory testing from an experienced QA team.

By having these two teams working in close harmony, companies should be able to increase both the speed of their iteration and the quality of the software that reaches production.  

Jumbotron image

Ready to take your software testing to the next level? Our expert human testers are your partners in the process of improving QA. Contact us today and learn how.