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