Trish Khoo wrote an excellent blog post on being a tester in an a programming team. More specifically, a team that values testing and incorporates it into everything they do. I found myself nodding along with Trish’s post and identifying very strongly with her experiences. I fear whatever I write in addition to her post will merely be gilding the lily, nonetheless I will add my voice and say that I find this a wonderful way for software development professionals to work together.
I’m fortunate enough to work with a highly talented team of programmers at eBay. I’ve worked closely with skilled developers before, formed strong and lasting friendships, was supported by them in my role. This is different. This is really the first time that I’ve worked with a group who value testing as much as these guys do, not as a role outside of programming, but as an activity that the team owns.
There are different strengths within the team. Mine happens to be testing. That doesn’t mean the responsibility for testing is abdicated to me. At the start of a sprint, we’ll identify the highest priority work to be done and we’ll talk about the complexity of each story not just in terms of getting a solution in place, but how we’ll know that we have a good enough solution of high enough quality. I’m generally not the one driving the conversation about quality. That’s a refreshing place to be.
One of the things I enjoy most about working in this format is the discussion around testability becomes a lot less contentious. It’s no longer a matter of developers doing you a favour, or becoming wary when you ask for access to their code (or horrified at the prospect of you committing changes), it’s something that just happens. It’s the difference between having a conversation along the lines of ‘I think we need to think about the impact of testing and how it affects this work’ and ‘what else do we need to think about to make sure this work is valuable when we deliver it?’. It is a damn shame that this seems to be such an unusual situation to be in. It should be the norm.
Like Trish, I’ve found that the bulk of my involvement comes at the start when we still know the least, be that at the project inception when we’re gathering requirements, or during sprint planning/backlog grooming when we’re working out what we need to deliver next and how. I recently used James Bach’s heuristic test strategy model as a project planning tool as a way of eliciting questions to ask as we built a model of the project. The work is ongoing, but thus far it seems to be something that the entire team has found incredibly valuable. I still do a lot of exploratory testing. The difference here is that I don’t have to waste time on the trivial and the obvious. Most of that stuff has been taken care of and because I can trust the programmers to take care of the basics, it provides me great freedom to delve deeper into the product and look for more crucial issues.
I’ve been a proponent of the mindset that a tester’s mindset is quite different to that of a programmer and there is some truth in that statement, but that doesn’t mean programmers are incapable of contemplating good testing, nor does it mean they have no responsibility to do good testing. Lisa Crispin and Janet Gregory in their book ‘Agile Testing’ make the distinction between code-supporting tests and product supporting tests and I find that distinction a valuable one to call out when working with programmers. They get the need for code-supporting testing (TDD) – it drives the design of the solution and provides a safety net when creating the solution and later with maintenance. Where programmers sometimes have blinkers on is the testing that happens around the solution itself, from questioning whether we’re building the right thing in the first place to probing the solution to see where it misbehaves. I’m the first person to admit that I’m not a highly skilled programmer. The more I pair with the coders on my team, the more I improve. The same goes for the testing skills of the coders I work with. We’re a multi-skilled team and the ultimate aim is not that I become a rock star programmer and that they become kick arse testers, but to become proficient enough in each of the skills we have to know when we can handle the work in front of us and when we need specialist help – killing off the Dunning Kruger effect and understanding the strengths of our team mates so we can draw on them when we need.
My sincere hope is that this is a way of working that becomes commonplace for testers and programmers alike. That would be an awesome industry to work in.