My experience of agile when it initially went mainstream was that teams continued doing what they already had been doing, just over the course of two weeks instead of two months. Our developers still had a “write the code” part of the development cycle where they made a large amount of the feature changes locally before attempting to spin up a new build, and our test team still spent a majority of their time waiting around for that first build, and then again after rounds of testing when we needed bug fixes.
Teams I see today are at the logical conclusion of agile. Developers take very small feature changes and work on them until they are done — not ready to test, not ready for a demo; “done” as in ready to go to production. A development pair can take a feature request from Jira to production in days instead of weeks.
Where do testers fit into this new, fast-paced workflow?
Get TestRail FREE for 30 days!
Pairing, Plus One
The normal development workflow is a single person working on a single change. The developer takes a new card; disappears for some time, maybe coming out occasionally to ask a question; and then, in a few days or a week, has something to commit.
Pairing reduces the number of mistakes and misunderstandings one person can have on their own, as well as the number of handoffs that come with a process where people work on their own. So what if you add a third person to that? Having two developers “pair” with a test specialist further reduces errors and ensures quality.
The developers and test specialist start a change with a “Three Amigos” meeting to review what they are supposed to build and ask any clarifying questions. One of the first things I like to ask as a test specialist working with a developer pair is, “How do we test this thing?” That small question helps us find a place to start, and usually that is a test.
That test might be something at the unit level, something at the service layer or a cuke that runs in the browser, but the initial point is that it will fail when we run it. Sometimes that test is written by the developer, sometimes by the tester. Once the test is written a developer will write the product code that will satisfy the test. We go back and forth in that pattern until we get a gut feeling that we are in a good place to make a new build to explore the changes we have made so far.
One thing that occasionally comes up is a test will feel difficult to build. Either the process of building that test is taking too long, it requires a lot of data setup or the code needs significant refactoring to be possible. Usually at this point we will stop and ask whether we are testing the right thing at the right level in the technology stack. We review what we are trying to test and why, then we make a decision about how to move that test up or down the stack, or even to an exploratory activity, to have a more effective test.
If you were paying attention there, you might have noticed there are large swaths of time when the tester isn’t “working.”
The Lag
There is a lag in the process, even when a test specialist is blended into a developer pair. Let’s take a closer look at the pairing flow I described above.
The flow starts with a “Three Amigos” meeting where we get refreshed on the change. The change is fairly well defined at this point, but we can still occasionally discover missing scope by asking questions. After this, the tester is active when talking about initial test design and jumpstarting the development flow.
Depending on the driver-switching cadence, which I see ranging from switching on every test to not switching through the entire change, the tester might be mostly idle for a while. During this time I ask questions about programming language features, pointing out typos or the occasional syntax error and asking leading questions about where we are going with a feature. I generally don’t see testers with hands on the keyboard until some sort of UI automation needs to be written.
At some point during the sprint, we have a feeling about where the product is in terms of usability, and we create and deploy a new container. When we are ready to explore, I might disengage from the developer pair while I explore the changes so far in a browser, but I still listen and occasionally watch via terminal to what is going on.
Despite being embedded in a developer pair and working in what is close to a continuous delivery process — namely, being release-ready once we create a pull request — there is still a notion of “testers’ work” and “developers’ work.” The tester role in this equation is only minimally effective at the beginning and end of the process. The middle is mostly asking questions and trying to stay engaged in a process we are only minimally involved in.
So, how do we fix this?
Join 34,000 subscribers and receive carefully researched and popular article on software testing and QA. Top resources on becoming a better tester, learning new tools and building a team.
The Technical Tester
In my experience, the tester in this scenario needs to develop some technical skill to become more effective. Let me explain with an example.
Instead of having two developers and one test specialist, let’s say we have one developer and one test specialist. Rather than the tester asking a question about how we’ll test at the beginning of the code change, the tester and developer have a conversation and the tester writes the test. Working on one terminal or IDE, the pair goes back and forth, with the test specialist writing tests or building test data and infrastructure and the developer writing code to satisfy that test.
Each person in the pair contributes to what the other is doing by helping through problems, pointing out mistakes to prevent tedious debugging later, or helping with course correction, but they also each work within their realm of expertise. This back-and-forth flow between two people keeps both parties engaged in the work and aware of what is happening.
When it is time to build and deploy a container, the test specialist will probably talk through the work they imagine needs to be done, then divide that work up between the pair so that both the tester and developer are doing exploration. The tester might take some of the more involved or complicated exploration work, just as the developer might take some of the more difficult programming tasks.
This pair structure of one developer and one test specialist, along with the driver-navigator switching cadence, keeps the power structure more level. There is less a notion of “testers’ work” and “developers’ work” and more the idea that they are working together on the same tasks to send something important to production in a reasonable amount of time.
Putting It into Practice
Getting to a smooth pairing flow when it isn’t already built into the company culture can be a challenge — as can moving from a process with strong divisions between roles and handoffs at each break point in the development flow. If you are new to pairing, try doing it with two developers and a test specialist to get into the flow. Once you have that down, you can maximize efficiency by asking a high-performing test specialist if they want to get a little more involved in the pairing process.
Just as with agile, this process will need assessment and tweaking when you notice areas where the product could be better or your team could be more efficient. But also as with agile, when you encourage collaboration and let the workers direct themselves, you should end up with higher quality and happier team members.
This is a guest posting by Justin Rohrman. Justin has been a professional software tester in various capacities since 2005. In his current role, Justin is a consulting software tester and writer working with Excelon Development. Outside of work, he is currently serving on the Association For Software Testing Board of Directors as President helping to facilitate and develop various projects.
Test Automation – Anywhere, Anytime
