This is a guest posting by Justin Rohrman.
Being a test specialist in XP, or Extreme Programming, can be awkward, especially when working as the tester for a developer pair. I have heard some people describe this as being the third person in a handshake.
As far as I know, there aren’t a lot of companies developing software this way, so I couldn’t just reach out to Google to find lessons other people had already learned. But after getting some experience, I’ve picked up on a few areas where the tester can add value beyond what two developers on their own can do.
After I started noticing these patterns, I was able to contribute to the pair much more efficiently and effectively. Here are six ways you can add more value, in case you ever want to try joining a developer pair.
Get TestRail FREE for 30 days!
1. Monitor Coverage
Developers work in pairs because it shortens learning curves on languages and product code bases, it is a fun and sustainable way to work, and — maybe most importantly — pairing is an efficient way to improve code quality. The teams I work with double down on this code improvement philosophy by test-driving new code most of the time. We start a change by writing a test, then write product code that satisfies that test.
Over the course of one change, we write tests, refactor tests, delete some and usually review existing test coverage. As I see new code, or opportunities to write new code, I ask how we plan to test something, whether we have existing coverage, or if we even need to test this programmatically. This helps create effective unit tests and informs how and where we will begin when it is time to explore.
2. Debrief about Work
Once or twice every day — usually in the morning right before we get started, and at the end of the day before we break — I like to review what we have done so far and what we have left to do. It is easy to get into the mindset of a feature factory, just jamming out one change after the other, with no focus on what is happening. Asking daily about what we are doing is a tool I like to use to bring focus to the change we are working on now and who will use it. This also allows us some time to think about how it works and the ways in which it might fail.
Reviewing what we have left at the end of the day helps us create a running task list. Context switching, which is what we do when we set aside whatever we’re focusing on to go to a meeting or read an email or talk to whoever just walked up, gives us temporary amnesia. We forget, just for a moment, about what we are working on and then have to get back up to speed. This running task list makes the context switch of going home for the day easier to recover from.
3. Discover Code to Refactor
Every once in a while, I’ll come across a part of the product I don’t understand, so I’ll go to a developer and see if we can walk through the code. We open the model and the controller and start working through it line by line, and then eventually I hear, “How does this even work?” (Usually there is also an expletive in that phrase.)
This is an important moment. It tells me that this code needs to be refactored so that the next person can understand what is happening, and also that our tests are either not effective at describing what is being tested or are nonexistent.
Hearing this phrase, or any variant on it, is a call to action for improving and testing that part of the product.
4. Write Code
When I work with a developer pair as a test specialist, I want to participate and be effective. My goal is both to monitor what we are doing for potential quality problems and to guide during the development process where I can. We work collaboratively on code through screen-sharing so remote people can have the option to control the screen, or through a terminal multiplexer, such as tmate, that allows everyone to edit the same file in different shells.
Over time, I have gotten familiar with both our code base and the languages we use — not to any point of expertise, but enough that I can find patterns in code that make bugs. Sometimes I’ll stop and ask about a line of code in a file we are working in. Other times, when I’m feeling confident, I’ll ask if I can type for a minute. When I do this, I make the change and run the unit tests right after. Generally it is a typo in the code, but occasionally I’ll spot a small logic problem.
This is using the skill of a tester to discover bugs, but with the ability to make changes and take action, like a developer.
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.
5. Ask How We Know We Are Done
Some software professionals live and die by acceptance criteria, but I think they are generally garbage. Acceptance criteria try to capture something the customer will value in the product, but they usually end up being a very basic list of functions the new change should be able to do. I occasionally hear about people using acceptance criteria as rejection criteria, but they fail in the same way by not being descriptive enough and usually missing some important aspect of what we are doing.
Rather than ticking checkboxes in a bug-tracking system to show that we have implemented the acceptance criteria, I like to have a conversation and ask questions: Who is the customer, why do they want this thing, how will they use it, and how many people will be using it and when?
I was recently working on a change that seemed fairly straightforward: A case file has demographic information about a person, and we want some of that to auto-populate rather than having a person fill that out. While working on the change, I asked what specific data we wanted, what field that should go into and when this should happen. These questions led to a design change and, hopefully, better software.
6. Give a Dose of Reality
I was talking with a developer friend the other day and he said, slightly embarrassed, that he doesn’t spend very much time in the product. I’m not really surprised; developers spend time in code making small changes, then will flip to a browser briefly to see the change render or to troubleshoot whatever undesirable thing they have introduced. Developers tend to have a very deep understanding of the parts of the product they work in but not the finished piece.
Test specialists, on the other hand, spend the majority of their time working in the product. That might be doing test setup, data setup or administering accounts, or just doing their normal test work. To get any of this done, we need a wide-spanning view of how different parts of the product work together and how we send and receive data from other products.
Both perspectives are valuable and important, and both perspectives need each other. When the developer is frustrated about troubleshooting a difficult bug, we can talk about why it is important and who cares about it. When I am confused and lost, the developer can walk me through what they are doing and why. This sort of empathy and insight into each other’s craft makes better software.
Join a Pair
Pairing can make hyper-effective developers on the right product and with the right people. Adding a test specialist to that is complicated; you want someone who contributes through the development process, not someone just along for the ride, waiting for a build like they normally would.
These six actions are a few ways I contribute to a developer pair. What would you add?
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
