OK, maybe not all of us. My house keeper isn’t a software developer. At least I don’t think she is. And my cat Stewie isn’t. But this post is aimed at Business Analysts and, in particular, Testers. In fact, anyone involved in your team should view themselves this way when they’re working with the team.

The reason I write this is because I often see people trying their best to do what they think is their particular job or role, without having the end product in mind. Testers in particular seem to do this frequently. I often see Testers aiming to test their product the best that they can. But this attitude doesn’t always produce the best software. It’s all very admirable to try and test well, but changing your attitude slightly from “How can I test this the best?” to “How can we, as a team, produce the best software?” is a subtle change, but a worthwhile one.

I can trace this difference in attitude, in myself anyway, from a conversation with my younger brother, probably near 20 years ago. We were chatting about software development and he maintained that developers shouldn’t really call themselves developers if they’re just ‘programming’. And that software development is a lot more than writing code. I was a Business Analyst at the time writing specification documents and quite liked that idea as I was able to include myself under the software development umbrella. Soon after I swapped from Business Analysis to Testing but it took a while to really grasp the fact that I was a software developer, or at least part of the software development process.

Back when I started testing, lots of testers seemed to put themselves at odds with the rest of software development. Business Analysts often had reasonable relationships with everybody, but testers would be seen as, and often pride themselves on being, well, gits. All too often I’d see Testers taking pride in how they could ‘break software’ or how they could make developers  afraid of them. It’s not as bad as that these days, but many still only try to concentrate on their specific job, as opposed to thinking about the goal of the team.  It’s all very well testing software after it’s been developed but, as testers, if we can help build the best software we can and build it right the first time around, then we’ll be so much more valuable than testers who are just good at finding bugs.

To summarise so far: Finding bugs is good, preventing bugs is better.

As software developers, we should try to avoid rework at all costs. It’s expensive and (usually) unnecessary. It seems crazy for me to even need to write this, but for some reason rework in IT doesn’t seem to be seen to be as bad as it actually is. Perhaps it’s because we don’t produce physical output. If I can steal an analogy from my colleague Steve Patterson for a moment, if we were building a house, we’d not want to have to build it twice before it works. If there’s a problem with the doors, we’d rather have it highlighted at the design stage or at least when we’ve only built one door. If we had the building inspector come round when we were finished and tell us all the doors were no good, we’d have wasted a lot of time, effort and money.

Building software is no different. If we can highlight potential issues early and avoid bugs instead of finding them, then we’ll save money and build better software faster. This is why testers should consider themselves software developers. They should strive to be involved as early as possible in the process to help delivery. When stories are first discussed, they should be involved in the initial kick off meetings to define acceptance criteria. Testers are great at coming up with edge cases and are ideal to help with defining acceptance criteria. These acceptance criteria, usually in the form of scenarios, can then form the basis of their tests. If Testers are coming up with additional things that they want to test that haven’t been included in the acceptance criteria then that’s a smell that the acceptance criteria isn’t exhaustive or that there are misunderstandings somewhere.

Testers should then co-ordinate what’s being tested and where. There’s no point in testing things more than once. If things are already covered in unit tests then there’s probably little point in replicating those specific tests down the line. If you’re an Automated Tester it’s a bit easier to class yourself as a software developer as you’re writing code, but manual testers are still valuable long before the software is written. If you’re a manual tester, don’t just think about how well you can test the software when it’s delivered to you. Think about how you can make the software as good as possible before it’s ever delivered. If you find a bug when testing, don’t think about how good you are to find it, think about how you can head off similar bugs in the future and what it would have taken to prevent it from ever being written in the first place.

Ultimately, everyone in the team should be aiming to deliver the best software, the best code, to production. It’s not just the people who write the code, it’s the Business Analysts, the Product Owners, the Testers, the Scrum Masters, everybody. If you can do something a little differently or a little earlier that will mean the quality of the software delivered is improved or the software can be delivered earlier, then you should do it. As a Tester myself, I always ask the Business Analysts how I can help them to write the best acceptance criteria possible. I liaise with everyone else in the team to see what’s being tested elsewhere, in unit tests for example, to see if I can help and to ensure my tests aren’t duplicating theirs. I try to find out what the biggest risk areas are and the areas of concern to the Business so that I can write automated tests to cover them and put their minds at ease. I also try to make my tests as useful as possible. I try to strike the perfect balance between testing as much as possible but keeping my automated suites quick. Having an exhaustive test suite is fine, but if it takes too long for someone to run before pushing their code then they’ll be slowed down.

It may seem like a subtle difference, but if you think of yourself as a Tester, your mind will be subconsciously trying to test things as well as you can. If you think of yourself as a Software Developer, you’ll subconsciously be thinking of the bigger picture. As a team, if members think of themselves as Developers, Testers, etc. then they’ll be more likely to create barriers between them. If every team member considers themselves as a Software Developer, it’s easier to work together, to work towards achieving a common goal and to work towards becoming more efficient. If everyone has individual goals, the danger is that they could conflict with the overall goal of the team.

The bottom line is that as Software Developers we should always, ultimately, strive to produce the best software possible. I would want every member of my team to have this goal and, as such, to class themselves in this way.