Test from theTop

Teams

Building Test Aware Teams

Today let's talk about why every last part of a team needs to understand at least the basics of testing.

As your team develops software, new code moves closer to public release in stages. At each stage, testing should be carefully considered.


An example. Your development pipeline might be simpler, and that's fine. Or it might be more complex, in which case you have my condolences. (But that's also fine.)

Bare with me for these examples, I'll show how each part of your team benefits from testing awareness.

Development

Individual engineers test software as they produce it. They also need to test their changes against all other existing parts of the system, to be sure they didn't break anything. This is simply not practical to achieve with manual testing.

During development, project managers need to account for time building test code. Product representatives need to allow for that extra development time on a per-project basis.

Directors need to advocate for the testing code that may not be capitalize-able development work.

Staging Internal

This stage is for development-complete code that is ready for a Quality Assurance team to test. This team benefits the most from automated testing tools, that's their only job. The more you can speed up their work, the faster you can find bugs that might block progress, and send them back to development. Understanding the application being tested is crucial, and so formal specifications are extremely valuable as a reference.

Staging External

This is where your client may be examining your work before it's finalized for public release. Miscommunication here is a major source of wasted time. Did your client find a bug? Is it really a bug or a new feature they are requesting? Defining specifications is the best way to prevent unmet expectations. I can't emphasize enough that your clients and internal teams need clearly defined application behavior to test against. I promise I will dig into this more in the the next email in this series.

Production

Now your software is out in the world. Your client and users are testing it for you! But you're probably also sanity checking it yourself. Maybe you have a dedicated User Acceptance Testing team checking every release, or external security audits. No matter what, you're probably going to find bugs that made it out. (Tragically, it's unavoidable.) Automated testing can be leveraged here to find the source of bugs much more quickly.

Your executives are going to get a report of these production bugs (once clients call them to complain). They're going to ask what you're doing to prevent bugs during development. This is when you politely ask for more resources for testing.

The point of this example is to show that all levels of an organization have a salient interest in the value of software testing.

In the next few weeks I'll cover topics like how to define specifications, fitting testing into your development process, and choosing the right technology for the job.