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#.

Part of each session was spent going through the unit tests to verify the right things were being checked. After a couple of weeks I was able to read the unit tests without explanation, and I added the review of the unit tests as one of my regular tasks.

A tester has many techniques available to validate whether the right things are checked in the unit tests. Once you are familiar with the syntax used in the unit tests, you can easily spot these parts and review them. This allows you to give feedback to the developer as you walk through the specifications together.

After multiple review sessions (rubber ducking and unit test reviews) and deliveries, I started to check the change sets that were checked into the code base before I even started my testing. I checked what had changed and whether this was what was expected to be delivered in every change set that I reviewed. Based on this review, I was able to determine whether I could start my tests or whether I should get together with the developer to walk through the code changes.

The main focus of this article is about working together with the developers in hopes of raising the quality early on in the development lifecycle. But that still means we have to get the right input from our analysts and the business to enable us to do so. Doing a walkthrough of the specifications with the analyst who wrote them is a variation of the rubber-duck sessions performed with the developer.

In addition to these sessions, you should get extra business scenarios to add as input for the rubber-ducking sessions. When these scenarios are implemented in the unit tests, they will create insight early on from a business perspective, so don't forget to inform the analysts and business about the outcome of these tests throughout the development cycle.

Adding Value Earlier in the Lifecycle

As a tester, you have a different view from the developers and the analysts on what has to be built and whether the right thing was built. We quite often wait for the code to be delivered and then start our planned tests, but in many settings, the first delivery has anomalies that could’ve been detected and prevented earlier on during rubber-duck sessions. Pair programming and code review help get the technical quality of the code up, but generally the check to see if whether the code is fit for use or purpose is performed later on in the development cycle.

In our team the workload increased significantly after a few releases, and we added several developers. Code review was part of the development cycle, but these checks were mainly focused on whether the code was complete and whether it met the coding standards.

Using the scenarios supplied by the analyst and the business, I was able to change my focus from the way the code was built to whether we were going to deliver code with the right behavior. I also supplied our developers with the business scenarios translated into readable test scripts, so they could create unit tests based on them. This way we knew before deploying to the test environment that the unit tests were successful and that we did not have to do more work on the package before delivery.

To review, there are four concrete processes testers can adopt to collaborate with the rest of the team and help add value to the development lifecycle:

• Talk through the code, and use the specifications or test scripts as a checklist
• Review the unit tests and code
• Implement walkthrough sessions with analysts and the business to get extra input for your test scripts and rubber-duck sessions
• Translate business scenarios into readable test scripts, which can be used to make the correct unit tests

Adding value to the development lifecycle isn’t solely for environments where continuous integration is implemented. Working together with the entire team is key to increasing quality early on. What you can do as a tester in a continuous integration, delivery, and deployment environment starts with adding value in the development lifecycle.