Last week I took part in my first pair-programming session. Up to now I had done pair-testing many times, so I was aware of the added value from pairing, but somehow I always assumed that as a tester I had little to add to a programming session. Boy, was I wrong?!
The story goes like this. As a user and Functional Architect of PractiTest I manage a list of “small improvements” that I think can greatly improve the system, stuff that is not big enough to be called a feature and so hard to push it into the backlog for one of the sprints. These are the kind of things I give to developers when they come asking if I have something small that needs handling “between tasks”.
Lately I realized that at least one of the other internal users of PractiTest, a developer in our team, also started writing down his own list of “small improvements” and so I proposed to him we merge our lists and start taking care of them. I went and set aside a spot of 5 hours and we scheduled a pair programming session.
I was not sure what was going to happen, so I brought my laptop along and thought to myself that in the worst case-scenario I would get some work done while he was developing the stuff we had in our list. In the end I was so busy throughout the session that I didn’t even open my laptop.
What can a tester add to a Pair Development Session?
1. Feature Architecture – Let’s start by the trivial things, a tester knows the functionality of the product a lot better than a developer does and so he can take the lead when dynamically defining how the feature should work. It’s not that the developer doesn’t know what to do, but when a tester sits in the session he automatically becomes the authority with the knowledge and experience to define how it should work.
2. Finding the hidden repercussions of the change – Imagine that as a tester you could be able to test just as the developer is writing his code, finding the non-trivial bugs in the features even before they are finished. This is exactly what happened during our session, as the developer was writing the code I was constantly asking questions about the solution. Some of these questions made the developer realized he was about to run into issues, and in at least a couple of occasions I was able to point at “apparently unrelated” issues (bugs!) that were linked to the change we had just made together.
3. Adding my technical knowledge – As much as I’d like to deny it there are some technical things I still know how to do. For example although not an expert I can still hold my grounds on HTML and CSS coding and so I was able to propose better alternatives to solve some of the issues that we were finding along our development. It made it feel weird, but even I have some programming to teach, even to some of the most experienced programmers in my team 🙂
4. Another set of eyes – Many times a programmer will make mistakes that are not related to coding, for example forget to commit changes on a specific file or applying the changes in the wrong environment. These are things that can be caught by any member of the session, without any prior development knowledge.
5. The art of asking the right questions – This was one of the most amazing things I realized after the session was over when we examined what we had accomplished. Just by asking the developer to explain what he was doing we were able to understand the underlying issues faster and more thoroughly and to find better and more elegant solutions for them, achieving the value of a walk-through during our session.
Tips that can make the whole difference for a tester on a pair development session
I don’t think it is trivial for a tester to achieve real value in a pair development session, in the end it depends on how you approach this activity. I think that some of the things that helped me this time were the following:
1. Come prepared to add value. Make it an objective to sit and add to the process and not only to sit there and serve as an intelligent scare-crow making sure the developer doesn’t get up from his sit before he is done with the task.
2. Don’t underestimate your technical skills. Remember that writing and understanding code is not that hard, so come to the session ready to understand what the developer is doing, to ask questions and to provide feedback where you think you can add it. The fact that you test for a living doesn’t mean you can’t understand about the code behind the application.
3. Ask (good) questions. Come prepared to ask questions and understand what is going on. Don’t sit like a doll while the work is being done. Use the session as a learning experience and while learning make sure you understand why and what is being done.
4. Be part of the session. Don’t try to do other stuff while working on the development session, you are not there to answer other emails, talk to your girlfriend, or go over some documents in your to do list; you are there to program so make sure you are doing that with your developer.
The session went great, we achieved more than I though we would in the time we had set for ourselves. So much so that we decided to do this a weekly activity, our next session is due later this week.
So, dear testers, get of your sits and start taking part of pair programming session. I bet that after a couple of times your team will even start asking you to do it more often and with most of them.
Practitest is an end-to-end test management tool, that gives you control of the entire testing process - from manual testing to automated testing and CI.
Designed for testers by testers, PractiTest can be customized to your team's ever-changing needs.
With fast professional and methodological support, you can make the most of your time and release products quickly and successfully to meet your user’s needs.