My sister, Erica, is not a programmer. Normally she’s not a tester, either. But recently she paired with me, playing a tester role, and spotted bugs while I wrote in Perl. In the process, it became clear to me that testers do not need to become programmers in order to help programmers write programs in real-time.
The Context
While working on the report for the Rapid Testing Intensive, recently, I needed a usable archive of the materials. That meant taking all of the pages, comments, and attachments out of my Confluence site and putting them in a form easier to shuffle, subdivide, organize, refer to, and re-distribute. It would be great if that were a feature of Confluence, but the closest I can get to that is either manually downloading each item or downloading an entire archive and dealing with a big abstract blob of XML and cryptically named files with no extensions.
(Note to Atlassian: Please enhance Confluence to include a archivist-friendly (as opposed to system administrator-friendly) archive function that separates pages, attachments, and comments into discrete viewable units with reasonable names.)
The Deflection
While Erica catalogued the names of all the attachments representing student work and the person or persons who created them, I was supposed to write a program to extract the corresponding material from the archive. Instead, I procrastinated. I think I checked email, but I admit it’s possible I was playing Ghost Recon or watching episode 13 of Arang and the Magistrate on Hulu. So, when she was ready with the spreadsheet, I hadn’t even started my program.
To cover my laziness, I thought I’d invite her to sit with me while I wrote it… you know, as if I had been waiting for her on purpose to show her the power of code or whatever. I expected her to decline, since like many computer power users, she has no interest in programming, and no knowledge of it.
The Surprising Outcome
She did not decline. She sat with me and we wrote the program together. She found six or seven important bugs while I typed, and many other little ones. The programming was more fun and social for me. I was more energized and focused. We followed up by writing a second, bigger program together. She told me she wants to do more of this kind of work. We both want to do more.
A Question
How does someone who knows nothing about Perl programming, and isn’t even a tester, productively find bugs almost immediately by looking at Perl code?
That’s kind of a misleading question, because that’s not what really happened. She didn’t just look at my code. She looked at my code in the context of me talking to her about what I was trying to do as I was trying to do it. The process unfolded bit by bit, and she followed the logic as it evolved. It doesn’t take any specific personal quality on the part of the “coding companion,” just general ones like alertness, curiosity, and basic symbolic intelligence. It doesn’t take any particular knowledge, although it can help a lot.
Perhaps this would not work well for all kinds of coding. We weren’t working on something that required heaps of fiddly design, or hours of doodling in a notebook to conceive of some obscure algorithm.
My Claim
A completely non-technical but eager and curious companion can help me write code in real-time by virtue of three things:
- The dynamic and interactive legibility of the coding process. I narrate what I’m doing as it comes together step-by-step. The companion doesn’t eat the whole elephant in a bite; and the companion encounters the software mediated by my continuous process of interpretation. I tell him what and why and how. I do this repeatedly, and answer his questions along the way. This makes the process accessible (or in the parlance I like to use “legible” because that word specifically means the accessibility of information). The legibility is not that of a static piece of code, sitting there, but rather a property of something that is changing within a social environment. It’s the same experience as watching a teacher fill a whiteboard with equations. If you came at the end of the class, it would look bewildering, but if you watched it in process, it looks sensible.
- The conceptual simplicity of many bugs. Some bugs are truly devious and subtle, but many have a simple essence or an easily recognized form. As I fix my own bugs and narrate that process, my coding companion begins to pick up on regularities and consistency relationships that must be preserved. The companion programs himself to find bugs, as I go.
- The sensemaking faculties of a programmer seeking to resolve the confusion of a companion. When my dogs bark, I want to know why they are barking. I don’t know if there’s a good reason or a bad reason, but I want to resolve the mystery. In the course of doing that, I may learn something important (like “the UPS guy is here”). Similarly, when my coding companion says “I don’t understand why you put the dollar sign there and there, but not over there” my mind is directed to that situation and I need to make sense of it. It may be a bug or not a bug, but that process helps me be clear about what I’m doing, no matter what.
And Therefore…
A tester of any kind can contribute early in a development process, and become better able to test, by pairing with a programmer regardless of his own ability to code.
Thanks for the post.
I have also done the same ,why testing and reporting bugs to the developer.
I like this approach as i can use my programming skills in the mean time to solve the issues with developer.
Question: You called programmer instead of developer.. Why ?
[James’ Reply: When I am speaking specifically about one who writes code, I prefer to say programmer. It’s a little less ambiguous.]
A post well needed. I’ve tried to get my testers to pair with developers in a very early stage such as this. I’ve done it myself and find it very fun, interesting and valuable. The tricky part is to get the programmer to talk about what he or she is doing so that I can follow the thought process and find potential bugs in the thought process. And also you need to find a programmer that also believes that you as a tester can add value.
Thanks for this post!
I really like how you laid out your claims thus putting a perspective on your context. In all my years working with development teams I’ve realized that not many programmers have your innate ability to narrate what is going on as you are doing it in an adroit manner. Even fewer will have the patience. That is probably one of the the first hindrance that organizations will have to deal with.
Claims 2 and 3 are very important to note since a lot of the complications that happen when a developer receives an issue is caused by how the problem is communicated. Having someone who has first hand knowledge and understanding of the issue definitely helps a lot in solving the problem at hand. On the other hand, someone looking over your shoulder asking questions is also a good way in confirming that you are actually doing what you intend to do. It’s almost an acceptance of your solution without seeing the entire picture.
This exercise will definitely help the programmer, and help the tester understand what is going on under the surface. Though, I’m worried that this will give inattentive blindness to some testers due to too much attention given.
I paired with programmers several times; and have mixed results 🙂 The biggest drawback would be ‘social’ – some programmers ‘think with their hands’, so to speak. They write and rewrite the code continuously, and usually it involves reconstructing the code functions in a certain way. One time I sit with the programmer for the whole session without any way to provide an input. Another time, the typing speed of the programmer was so fast, that he stopped talking – he couldn’t follow his hands with his mouth. There was a time, when I suggested few unit tests to the piece of logic that the programmer was writing while pairing with me – and she refused, claiming it’s too many.
Usually, instead of pairing, I ask the programmer to explain his/her code logic to me. This way, I am able to spot bugs – by following their thought process. It usually works well for both of us.
I had no idea I would enjoy the experience of the pairing. I knew he had to write this program and I knew I wouldn’t be going home until it was done. Therefore, sitting next to my brother would ensure the task would get done. I watched the blank screen fill with expressions and punctuations. To my surprise, I was looking forward to each time he hit SAVE, and let it ride! I was thrilled to see our data organize into folders, exactly how we wanted it to be. Voila, delicious results. When I did find a error, I was encouraged to find more. That encouragement was enough keep me glued to the screen.
I wish I could say that I want to be a programmer at this point, it is tempting. Until that happens, I will happily stay by my brother’s side, as he writes the magic and I catch the missing bracket!
When I think about it really makes sense. Developers are mostly lazy and too confident about their code. Maybe you found a new paradigm? Something similar to pair programming but with a tester (or any normal not developer person) aside and just talking to them. I think that just by saying to somebody what you are coding you can realize your mistakes. It’s worth a try in a real life project in a company. It would make development process more stable probably. Obviously it may slow down it a little bit but probably it would make testing lot easier and it would help to eliminate bugs as soon as possible which is a good thing.
[James’ Reply: Lazy? Too confident? Those are loaded and derogatory terms. I think we can say the same thing in a nicer and really more reasonable way. We can say that pairing liberates more energy (literally, in terms of glucose burned/calories consumed in absolute mental effort) and creates more focus (since the mental processes of narration serve as an additional channel of thinking that acts as a cross-check on the others) and produces more skepticism (in terms of openness to alternative possibilities owing to the duty of each party to respond to the other).]
Paired programming with a tester is definitely a productive approach. It helps the tester understand what is being written and how it’s being written, and therefore can help drive future test cases, as for the developer having a tester by their side helps them feel more energized and will mean bugs are spotted at the earliest possible stage!
We’re trying to implement this where I work currently, and one of the first problems when it was first announced was from QA that they didn’t know how to write code, so felt their input would be minimal, whilst it’s still being adopted, posts and stories like this will help them realise that there is value to this.
James I’ve meant the lazy in the good way. If somebody is intelligent enough he (or she) tries to achieve a result with a minimum effort required. So I was trying to say that programmers are mostly intelligent and are trying to write less code to do something. But on the other hand they sometimes tend to overestimate their experience and helpful hand from somebody that is thinking different might be very productive.
Nice article. And a nice approach too. Sure it gives a contrarian point of view if we have a tester nearby when we code. For me, this is close to a new TDD… Tester Driven Development.. 😛
— Rajaraman R
TDM Blog: http://tdminsights.blogspot.in
Agile Blog: http://agiledevtest.blogspot.in
Hmm… I’m not so sure about this one. If this is about catching missing brackets I think a simple validation tool would be both cheaper and more efficient. Furthermore, if the tester has knowledge of the code I can think of scenarios where this might limit his creativity in black box testing and steer him down the wrong path. Not arguing that this method has situational use though, which is obvious from your example.
[James’ Reply: It’s a bit odd to suggest using a validation tool for something that is automatically handled by the compiler itself. I would think THAT would be your point: just trying to run my Perl program will immediately reveal the missing bracket. However, as to that, if you have used validation tools you know that they catch some things, miss others, and complain about a thousand things that you may not care about. It can be a real expensive pain to use them. Still, I do use Perlcritic when I want to be at my best.
But this isn’t about confidently locating missing brackets. It’s about first-mind and second-mind focus and energy and all the intangible benefits coming with that. The process was enjoyable and free-flowing, and inexpensive for me and her. Give it a try once in a while.
The point of the article is this: stop ASSUMING that a non-programmer can’t help you program. That’s all. I’m not really claiming anything grander than that.
I agree with you about the potential for limiting creativity. For that reason I would not do this all the time.]
Interesting…would be great to see a film of this!
Great article, I have expereinced this doing sometime back and it was really fun working with programmer and it is more over like early testing in Dev environment 🙂
~Mahendra
It really makes sense that non-programmer can also help in finding many early bug those like finding syntax (in one place you have just written ” you have used bracket there and here than why it is missing here”)and logical workflow bugs.
As a tester I have also gone through such practices, sometime we normally sit full day with developer to see them fixing the bugs and helping them to understand the bug reported. But while doing this some time we tester get so engrossed in logic that some time we just want to see the developer fix the bug anyway ..sometime it hampers the maintainability of product at code level in coming future, this behavior shows that we forget the instinct of tester and start thinking more like a developer and more and more at code level.
So I think this is very helpful in one way because through this we tester could flow with the real coding flow that have many rules at multiple stage but on the other way miss the testing instinct sometime.
– Thank you!!
Great post, and a worthwhile goal for a variety of projects.
Hi
Thanks, its a very nice article. In my previous company(KAZ Software) we had a process called pre-qa(we named it) which is similar to that. We had a specified instructions for that.
I wrote an small article(http://shantonusarker.blogspot.com/2012/09/pre-qa-essential-step-in-agilekan.html) about that pair-QA, last year.
My opinion, regarding this is , It makes a lot of conversation that can be very helpful to see things in different prospective. And, that process is proven to produce qualified product for KAZ software.
Thanks
Well the post bought back memories for me when I was involved in a similar stuff some 15 years back with one of my friends and I was the smarter guy out in the pair (not the programmer, but the better half ;)). It was more of a personal stuff we were working on I will accept that at that time initially I was a bit frustrated, since I wanted to try my hands on coding since during that time if you are not coding you were considered dumb!!, and also James was not their 🙂 (I mean I never knew he existed on this planet Earth….). But as we continued working, I realized the contribution I was making to the whole process. My friend did narrate the logic as to what he was trying to write, and i constantly questioned him on the various scenarios/options that could happen. So it was like he working on the coding, and myself more taking the overall picture into account.
The end result was pretty cool, and we completed this complex piece of work, with good success albeit with a slight delay.
When I look back today after reading this post I feel that my initial Testing & Quality skills were nurtured during the phase. Thanks!! James for this post.
The act of describing a block of code while you do the coding seems a sound idea. I know from my time as a developer that if I encountered a bug that I could not solve on my own, the very act of giving someone a commentary of the circumstances would often lead to me solving the problem myself.
Pairing the tester with the developer has the additional benefit of extending the testers knowledge and allowing him to come up with more extensive tests in the future
Hi James. A very interesting article and one I can relate to. Similar experience has shown that the tester can help the programmer spot errors, and also that the programmer gains in confidence from having the tester’s input. Questions of functionality and logic can be discussed and even simple things like the spelling of text that will appear to the end user can be checked. It works really well.
I’d also say that two testers working together has a similarly positive dynamic. I don’t think the difference is just down to having two pairs of eyes. I think working as a duo inspires confidence and also an element of competition i.e. to put the best they have into the work. The end result is better software.
Hi James, love your posts.
As a non-programmer tester, the biggest problem that I face is a lack of respect from my peers and my boss for my work, even though throughout my 2 years on the job I managed to find hundreds of bugs, the feeling is I am still perceived as a dilettante in their eyes. Therefore the opportunity of pair-testing which looks to be very interesting and even exciting, I fear, will never be given to me.
My question is: what do you think will be the best way for me to convince my boss to give me this opportunity?
thanks
Gidon
[James’ Reply: First, learning about programming is not the same thing as becoming a programmer. Consider trying learning some of the language your programmers work in.
Even if you don’t, I wouldn’t ask your manager for permission to work with a programmer, I would just go to a programmer and ask to do it. If for some weird reason they won’t do this with you, then go on twitter and ask there. I bet there are lots of people who will do this with you.]
Hi, just catching up on what I’ve missed… This reminded me of the cardboard cutout dog paper (http://www.sjbaker.org/humor/cardboard_dog.html). They are talking about paired programming but come to a similar conclusion: The programing capabilities of the “navigator” do not have to be grand. As a bonus it’s also quite funny.
Totally agree.. pairing a Developer with a tester is what helps the tester understand how the application works under the hood, this way helps his creativity in creating test cases, and also helps the developer not have some doubtful logic in the code, or add some extra try catches scenarios that the tester will come up with.
However, I think the tester must have at least a beginner level knowledge of the code. This way he understands what is being done, not only by listening to DEV, but reading the code also.
Very interesting and I like this, great concept.