Do You Have To Be...

I'm sure you all thought you were through with hearing me post comments and thoughts from CAST, seeing as the conference finished last night, and all that's left today is to clean up the last bits and go home. while the conference is over, the reverberations from sessions should continue for some time to come. I woke up this morning and checked my Twitter and saw that I appeared in an interesting side discussion, and it's that side discussion, from a session I was not actually in, that prompted this particular post.

I've had the pleasure of getting together with and talking over dinner and at several other events with Jeff Morgan (@chzy) and Henrik Andersson (@henkeandersson) over the past few years. I have worked through Jeff's book "Cucumber and Cheese" and found it to be both great fun, and a great way to construct an automation framework. I have used Henrik's "Context-Driven Robots" module as a core component in teaching about context to new testers in the SummerQAmp curriculum. Both of these gentlemen took part in a spirited debate about whether or not software testers should code. Again, I could not attend this session because I was facilitating and co-presenting a session with Albert Gareev (@agareev) about how to design and how to test for Accessibility. Still, much was said and many tweets resulted from this discussion. I replied to some, retweeted others, and it was in this process and in light of one exchange that things got interesting :):

There's more to this conversation, and if you would like to see the rest,  I encourage looking at the other tweets, but the last message is what prompted this post today. I look forward to others who will post on the topic, too.

There are three aspects that I think are coming into play with this discussion:

1. Do we want to have a separate role and focus of energy within organizations for programmers and testers?

2. Do we want to see more testers become programmers in their own right?

3. Do we want to see programmers develop the skills to become better software testers?

Note: this may not be where the original conversation meant to go, and that's totally OK. This is my thoughts on this, and based on talks we had at CAST (I'm specifically thinking of Jessie Alford's talk about Pivotal and Cloud Foundry and how they code and test).

Let's start with the first. Several organizations are either considering, or have already decided, that there will not be a separate role for software testing that is distinct from programming (role as in dedicated teams or members of staff that do that particular job). Jessie Alford presented a model that Cloud Foundry uses where programmers rotate into a role for a time as explorers, and then they go back to programming. The focus and activities are the same. There is definitely software testing happening, and software testing as those of us who consider ourselves being testers would recognize as what we want to see testing be represented as. It is not, however, being performed by strictly manual testers. It is being performed by the programmers on the team. It's an interesting model, and from Jessie's talk, it's working quite well for them. Can a programmer be an excellent tester? If Jessie's experience is to be believed, the answer is "yes". This certainly indicates that the third point I mentioned above is not only possible, it is happening. 

There are arguments for and against a dedicated test team within an organization. My company has both roles and dedicated staff for them. We have dedicated programmers and dedicated explorers. We report to the same person, the VP of Engineering. At this time, the test team is integrated into the programming team, but we have a clear distinction between programmer and tester. That doesn't mean we don't program, especially in the area of automation. Each of us on the team has the skills and the experience to create and edit the automated tests that we use. I have the experience to be the release manager for the company, in addition to being a software tester. Thus, I certainly do feel that having programming skills can be a solid benefit to a tester. At the same time, I will not pretend that I have the same level of programming skill or experience as our production programmers do. I'm also not being asked to provide that. We have a dedicated person whose sole responsibility is to create automated tests. My teammates and I supplement their efforts, but generally, it's our efforts as explorers (to borrow from Jessie once again) that is desired most by our engineering team, at least at this time.

Michael Bolton makes a clear point in the exchange above and in other tweets that were part of the conversation. Do I have to be an expert photographer to edit National Geographic? Do I have to be an expert healer to be a pathologist? Do I have to be an expert mechanic to be a race car driver? Note, Michael didn't actually say that last one, I added it for the fun of it. The point is, we do not have to be any of those things to do the things that we excel at... but having a good knowledge of each area will certainly be helpful, as it will help us to understand better the domains we work in, and will help inform what we do. 

As testers, being able to understand code and what makes it work can give us a tremendous boost into ways we can test and ideas we can develop. At the same time, I've had experiences where the code I have written, and tested, has been enhanced by an external tester who can think of things I did not consider. I value that software tester's help and insights. I also realize that that software tester can be a programmer on my team. Exploration skills and mastery of testing approaches and ideas are important. If a team can do that with having programmers take on the role of explorers for a time, or reciprocate for one another in that capacity, it may prove to be a very workable solution. In other teams, it may make sense to have a dedicated testing group do that. 

As was made clear in the debate, the process of programming and testing are both vital. Both need to be done. There are many ways to accomplish those goals, and varying approaches will be used. Personally, I know enough programming to be dangerous, and enough testing to help mitigate danger. I'm not personally good enough at both to mitigate my own danger, but I'm working on it. My personal opinion as relates to the debate is that no, software testers do not have to be production level programmers in addition to being excellent software testers, but if you would like to get to know more about how systems work and what influences those systems to work, and if you have that base level curiosity that all good testers have (in my opinion), adding some programming to your personal portfolio would certainly not be a detriment. It's possible that you might learn something and decide that it's not for you. Again, that is OK, but don't be surprised if the effort to learn starts to give you new ways to think about the testing you are already doing, and presumably quite good at performing. In my opinion, that seems to be a good trade :).