How Testers Can Add Value Earlier in the Development Lifecycle

Before you can achieve continuous delivery, you need to first start implementing continuous integration. Some say CI is just for developers, but testers also play their own important roles. This article describes solutions that will help you add value to the development lifecycle—whether you work in an agile, DevOps, or traditional context.

One of the practices becoming increasingly popular in the software world is continuous delivery. Before you can achieve continuous delivery, however, you need to first start implementing continuous integration (CI). Some say CI is just for developers, but they are wrong. In the Scrum context, everyone is part of the development team, and testers play their own important roles in CI.

Still, testers can often feel forgotten or unsure about how they fit into the CI lifecycle. This article will describe solutions that will help you add value to the development lifecycle—whether you work in an agile, DevOps, or traditional context.

Rubber Ducking

I’ve heard testers say, “But I’m not into coding and I’m not that technical.” That may be true, but it doesn’t mean they can’t help out in the process.

So, how do you start when you are dropped into a team that practices continuous integration? Communication is key, especially when you are working in an agile setting. Therefore, you should start talking to the developers and get to know them. Talking doesn’t add direct business value, but it does open up space for conversation about what the developers are doing.

When there are multiple developers on your team, it is likely that they use pair programming, code review, or, ideally, both. Both tasks are aimed at ensuring the code has a certain quality. However, they are mainly focused on the technical quality of the code, such as coding standards, dead code, never-ending loops, and deadlocks, not on whether the right thing was built.

On one assignment I was working in a small team of three people analyzing, coding, and testing. At the beginning of the project I was supplied with a new release that was ready for testing. But I had no understanding of the code’s technical quality or the software’s expected behavior, so we planned a test phase before delivering the code to the business for acceptance testing.

We weren’t working in an agile setting at the time, and sometimes we delivered code that wasn’t exactly what the business had asked us to deliver. To help avoid rework, we decided to introduce “rubber-duck sessions” to check whether we had built the right thing before I even started testing. The name “rubber ducking” is a reference to a story in the book The Pragmatic Programmer , in which a programmer would carry around a rubber duck and debug his code by forcing himself to explain it, line by line, to the duck.

Our analyst wrote detailed specifications I could use for testing without having to script too much. Each day, the developer talked me through his code in layman’s terms, and I used the specifications as a checklist for those sessions.

This allowed me to give immediate feedback to the developer, who added the items to his backlog. At first these sessions weren’t planned as part of development or testing estimation, but after a couple of weeks, we saw the quality of what was being built increase incredibly. We decided to make these sessions a regular, planned part of our development cycle. The sessions were limited to one hour, once a day, to give the developer enough time to code and me enough time to prepare the session as well as complete my other work.

Working Together with Developers

I have some experience in coding and scripting (foundations such as Visual Basic, Python, Delphi, and JavaScript), but we used C# in our environment for both development and unit testing. During the rubber ducking sessions, we went through the code and I observed the syntax used in C#.

About the author

StickyMinds is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.