Why Do You Need to Unit Test If You Have a QA Team? (Part 2)

In our previous post, we covered all the bases. In this part, we dig deeper and identify what the real differences are in practice. Let's continue!

Real-Life Features

Let's assume that we have a customer account feature in our application. Users modify things on their account, like their name, current phone number, credit card information, or their system avatar. Somewhere in the system, there must be a "save account information" module.

The QA team works with the business stakeholders and the developers to outline a suite of story tests for this "save account information" feature. Story tests are part of an overall test plan for the feature.

A test plan is one technique that a QA team uses to ensure that every feature is verified. A test plan acts as a guide or checklist for this part of the quality assurance process.

An Example Test

A simple example of a story test might be "The save account module verifies that the account record contains an account holder name so the account holder can be identified by name." For most features, there will be many tests. Each one needs to contain three things: an action, a result, and a "why." Our example test tells us the action is verifying upon save. The result is that the save requires the account holder name. The "why," which is "can be identified by name," places the test in context. Remember, these tests start out in plain English; they need to be understandable. Therefore, they might not rigidly conform to any format.

So in planning for this feature, we want to create story tests; plan for exploratory testing; possibly create test scripts; schedule, execute, and report on user acceptance testing; and ensure that we use unit tests where we need them.

How QA and Unit Test Creators Work Together

The QA team works across the entire development group. They interact with the stakeholders, users, product team, architects, developers, DevOps team, system administrators, help desk, technical writers-pretty much everyone involved in defining, delivering, and using the software.

The QA team may help the developers understand the requirements or the quality goals with respect to automated unit tests. Developers may help the QA team understand the system components so they can define or build other kinds of tests. The two groups must work together to gain the maximum effect of quality assurance.

Closest to the Source Wins

Unit testing is best done by the people developing the units. I strongly advocate for test-driven development (TDD); in fact, I generally refuse to work without it. Unit tests are a consequence of TDD. A disciplined team using TDD to build software will get both testable and tested software as a side effect of the TDD process.

If you choose not to use TDD, here are some issues to consider.

"Test after" approaches include having the developers build their own unit tests and having other developers build the unit tests. Both of these approaches have serious flaws.

Having the developers build tests after the code is "code complete" does nothing to ensure the testability of the system. Often, it requires changes in the system to make it more testable. When it's too difficult to create tests, developers skip or exclude them.

Having the QA team (or anyone else) build tests after the code is code complete has the same flaws as having the developers do test after. Because the QA team doesn't spend all of their time writing code, they may also struggle to keep up with the developers or have difficulty understanding the code.

The distribution of labor here does not pay off.

What Should You Do?

Now that we've discussed how unit tests and the QA team are related, here's some advice on using both to deliver high-quality software. First, empower the QA team to participate across the entire development process. Their job is to ensure that the right thing is built and that it's built well.

Second, look closely at how unit testing is being done. Ask your developers to explore TDD. Take a very serious look at TDD. Look at how it affects the way your software is built. Talk to your QA team about unit testing. They'll have some strong opinions about its utility.

Summing Up

I hope that this has clarified what a QA team does for your organization. I also hope you're a little clearer on what a unit test is, though that's a very broad topic and I've only skimmed the surface here.

What's most important to take away is that the existence of the unit test is mandatory, but the responsibility for its creation is on the developers. The QA team is there to provide guidance and support for the developers in this sense, not to create them.