More Agile Ways of Working

If you built software in the 90s and 2000s, you'll remember a few things that aren't around much anymore. There was a stack of paper the size of textbooks on our desk before development started. Programmers, testers, and product managers all sat in different parts of the building. And, there were invisible "walls" that people would throw work over to let the other team know it was time to do their part.

Most companies claim "agileness" now, and a lot has changed in how programmers and product managers work. But somehow, the testing groups were left out of this change. As a result, some testers might be lagging behind the rest of the team and be seen as a “bottleneck” to the agile process.

What Are Some Ways Testers Can Start Catching Up?

Most agile transformations end in something people call “agile-ish” or “scrummer-fall” or “scrum-but”. Some of the aspects of agile are in place, like the daily standup meeting and sprints, but everything else is a basically waterfall. I have seen agile shops with a requirements sprint, followed by a development sprint, followed by a testing sprint, followed by a hardening / pre-release sprint. To me, that feels like a consultant stopped by and dropped off some tools and frameworks, but completely forgot the most important part – culture change.

How Testers are Adapting to Agile

Teams that manage to move past the lag seem to have a couple of things in common — (1) pairing the testers and developers, and (2) more technically skilled testers. These teams are able to deliver quality software instead of just checking boxes.

Pairing Tester and Developer

My experiences with pairing have been mostly positive. Here’s an example. I was working with a front end developer who was in the middle of making a change to a page designed to create an advertising template for marketers and had a question about the user experience. I did some light testing on his environment; working through the most basic workflow to get a sense for how the customer would feel. While doing that, I discovered that I was able to edit a page that was supposed to be in read-only state. My programmer comrade was able to quickly fix this issue and we re-tested that day before the bug made it to the test system.

This wasn’t a constant pairing, rather the developer would call me over to his desk when he had questions. I made an effort to show that I was available to help. We had the same goal – produce the best possible product. Before I left that company we were working together on his machine at least an hour every day.

Improving the Tester’s Technical Skills

Another company had a product based on a REST API. Programmers would create the tools to create and change data on the back end and UI programmers would hook that up to a browser a little later in the sprint. At the time, we would just wait for the whole thing to be ready. That was like buying parts to make a car and just letting them sit on the shelf for days without thinking about them.

This is the story of how I learned to do some basic programming in javascript. Using a library freely available in GitHub, a programmer and I did an experiment to see if we could create some automated checks for his API piece while he was developing it. By the time he was done building his part, we had gone through several rounds of testing and had some automation that could be added to the CI system and run with every build. When the feature left his hands, most of the data testing was done. The combination of pairing and using tools to help us find bugs earlier created a much better build for the next testing pass.

Finding the Right Balance

Pairing isn’t a magic trick. It can be challenging. There is usually a tension between being a critical software investigator, while at the same time maintaining a good working relationship with that programmer. There is also a balance to be struck in personality types between people that are quiet and reserved, and those that are more outgoing. Good things happen when that balance is found.

Being a more effective tester on an agile team hinges on learning new skill sets. Collaboration and new technical expertise are at the center. If you find your testers are lagging behind the rest of the pack, try a small experiment. Have a tester and a programmer pair up and drive a feature to done. You might be surprised at the result.