Lately, I happened to have an interesting discussion with my colleague Dirk Meißner on whether programmers should have reasonable understanding of testing or not. A lot has been talked and written about how testers need to be great with their technical skills so that they can contribute effectively and remain valuable. Sure, that's helpful and I too insist that it's high time that testers get over with their traditional way of working (and thinking). However, what surprises me is that there is not enough awareness or enough discussions happening around programmers learning to understand testing to amplify their effectiveness.

Does it matter? Why? 

It absolutely does. At least now, if it did not before. "Whole Team Testing" is new cool (again) especially in DevOps contexts. And it has it's own reasons to be that way.

Let me explain. Agile teams typically have one tester dedicatedly looking after testing and related activities in team. This tester is usually busy testing (and automating often) stories for each sprint with primary focus on acceptance criteria. If the tester is "cool kid" then they go over the board and test things beyond acceptance criteria too. Cool! Let's park this thought here for a moment. Okay?

James Bach, in his interesting article "Seven Kinds of Testers“ beautifully explains the key patterns surrounding testing styles and how testers typically fit into one pattern or the other or combination of more some times (or checkout this thought-provoking tweet series by Michael Bolton).  In over eight years of hands-on experience of testing, I have found myself to be of one kind (or maximum two) at a time and by the time I wish to change my hat (or style) it is usually almost the time to deploy the feature in production. Pity!

The point is, there is limit on how much versatile a tester can be in limited period of time for each story they test. Sure, it's not impossible but I would say it's not very easy either, given the time constraints. Now, imagine that we add "programmers" from team as other kinds of tester (based on their skills, expertise and experiences) working on same story. Do you not think it will most likely add more coverage to the quality of that feature, without having to spend really additional time on it? Do you not think that testing wisdom of a programmer would help tester and the team to ship quality product? I'm sure, now you do!

When I say programmers should contribute to testing, it does not have to be only in a way that they will need to test the software like testers do. Even if they develop the required mindset, it's already a good start. Indeed it will be great if they can test it but I feel that if they could at-least understand modern testing, it will greatly benefit the project teams. 

How exactly programmers can learn to test and start off with it, or how testers can help them to onboard with testing is another topic. It requires a dedicated post (more on that later). 

This post is about identifying programmers with testing mindset or skills that can help them test better, while you interview them. I recommend watching out for these skills/traits in interview:

1. Quest for Context

The scholar John von Neumann once said, "There's no sense being exact about something if you don't even know what you're talking about." In a world that is growing increasingly dependent on highly complex, computer-based systems, the importance of defining what you want to make before making it -- that is, knowing what you're talking about -- cannot be stressed enough. (Exploring Requirements: Quality before Design by Weinberg & Gause). 

Developing software is not just about writing a program that will do the stuff but it is more about building a product that your customer would like to use. In past, I have come across programmers who were excellent coders but failed to care enough about purpose of the program they used to write. I rarely see programmers questioning the user story beyond acceptance criteria and technical implementations if any (unfortunately, it's not very different for majority of testers either).

If I were to hire a programmer, I would expect him to ask Context Revealing questions. By that, I don't mean just questioning the business value of the user-story. There are things beyond that which matter. What if we find out that other team has worked on similar solution before? What if we could re-use some components developed by other teams?  What happens when particular feature development requires specific technology expertise and team does not have it? What happens when stakeholders' understanding of technical details defer from engineering team's? What if implementation of some solution requires tools not available with team or required access levels for that matter? 

Sure, one can eventually find these things out when they start working on the ticket but what's the point in findings things with accident and when it's already late? 

Programming interviews typically include coding challenge that typically gets assessed for candidate's technical skills, familiarity with known technological issues, understanding of best programming practices, problem solving skills etc. which are indeed important. However, I am yet to see a programmer being assessed for the kind of questions they asked before jumping on to the coding challenge itself.  See if they are questioning the very purpose of challenge, see if they question the business value, check if they ask about other elements of Project Environment and Product Elements for that matter.  And, please check if they ask questions about testing and Quality Criteria if nothing else. Most of the programmers I got to interview usually assumed that that there will be a tester in team who will QA their code. They just have to write the code and throw it in tester's bucket. You better watch for such kind if your team does not have a tester. 

Just like testing, good software development should be treated like an intellectual activity. The better one understands it the more ways one can contribute to product quality. And it all begins with asking questions. 

​2. Interactional Expertise 

If you are unfamiliar with the idea of Interactional Expertise, I suggest you start from understanding it first. Even better if you could read Tacit and Explicit Knowledge by Harry Collins.  I personally found it to be very useful learning when I was introduced to it by my friend Iain McCowatt. 

​The purpose of mentioning Interactional Expertise as a skill here is that, I find it to be very important skill when it comes to have technical discussions with non-technical people. Or, even when it is about having meaningful technical discussions in short period of time. 

Bringing up technical topic for discussion in planning meetings or grooming/estimation meetings is usually like opening the Pandora's box. Over the years, I have been a part of deep discussions in meetings with only conclusion of carrying them to next meeting or scheduling separate meeting for that. Then again, special meetings for explaining those technical things to non-technical people were required. Does that not sound familiar to you? 

I feel that spending so much time on deep discussions very often is unnecessary and it can be significantly controlled if all of us (not just programmers or testers) learn the skill of explaining things in short (and to the point) when needed without losing the substance of it or compromising with the impact an elaborated version would make. Same goes with explaining technical things to non-technical people. As techies, we can't expect the whole world to understand the language we speak (it would be nice if that happens though) but we can make things simple by learning the art of explaining those to other in language and context they would understand better. 

Added advantage would be when you onboard new members in team. Regardless of what role they are hired for, person's IE skills would help them onboard much better and the skill will definitely help for better collaboration and communication. In fact, when testers and programmers both have great interactional expertise then sessions like pair testing or programming will be super productive. Imagine what value it can add for Mob Programming and Mob Testing sessions. I have worked with some programmers who were master of explaining technical things to non-technical members of team as if they were putting a child to sleep by telling a story. Short, sweet and yet satisfying. That's what I mean by Interactional Expertise. 

Next time when you interview a programmer, look for these. It will help you. When I interview testers for it, I usually ask them to explain some technical concept in 50 words for example and again same concept in 100 words. It helps me analyse how good (or bad) they are with their Interactional Expertise. Asking programmers to write a technical bug report or user story can also be helpful trick to evaluate them for their IE. 
​
​3. Understanding of Testability 

May be I am wrong about it, but I honestly feel our industry still lacks required seriousness (and awareness) for building testable products. This is not just about programmers being unaware of it but even testers. 

The only times I hear of the word "test" in programmer interviews are when they talk about their unit tests or TDD or automated tests at the max. And it's a pity!

Building testable products is an important part of software development and it is important that programmers understand how to bake testability right from the beginning. Sure, skilled testers can certainly be advocates for testability but it won't hurt if programmers too understand what it means to them and how they can contribute to it. 

While interviewing programmer, I suggest you pay special attention to their solution if that demonstrates at-least few aspects of Intrinsic Testability as explained in ​Heuristics of Software Testability by James Bach. If not, at-least make an attempt to discuss other aspects of software testability (listed in the heuristics) with candidate in general and gauge their fitness for your requirement. 

For sure, the skills mentioned above are equally important for testers too but since "Whole Team Testing" thing is picking up, I wanted to make it explicit for traditional non-testers. Next time when you interview a programmer, please try and see if it helps. 

If we need technical testers, we also need programmers who understand testing. And that is reasonable to ask for, isn't it? 
   
Oh and by the way, I will be touching on some of the related topics in my talk for Online Testing Conference. Feel free to join if the topic interests you. 

As a part of day 3 of #20DaysofTesting at XING AG challenge, I was expected to read one blog and comment on it. But the blog I have chosen to comment on has rather encouraged me to write a blog instead of just leaving a comment.

While reading some interesting discussion around testing and “100% test automation” thing, I stumbled upon “No Testing” blog by flowchainsensei (aka Bob Marshall) shared by one of the participants in discussion (thanks Nilanjan).

This is an interesting post I must say, particularly because the arguments and ideas presented by Bob made me ponder and encouraged me to think critically about the value of my own profession i.e. Software Testing, yet again.

The blog is bit old and I don’t know if Bob’s opinions have changed but I would like to discuss around some ideas he has expressed in his blog. I must mention that this blogpost is not a response to Bob in person, I have great respect for his work and I admire his writing around Agile/Software delivery. I decided to discuss the ideas from his blog mainly because I still come across people who share similar opinions. This post is my humble attempt to explain what I think about those opinions as a “passionate tester”.

If I have understood Bob correctly, his key arguments are something like below and I believe that majority of the fans of “no testing” idea share them (more or less):

1. It’s possible to deliver a software that ‘just works’ without having to “test” it as such
2. Customers are unkeen to pay for testing
3. Testing adds little or no value from customer’s point of view, then why to invest in it?
4. One of the needs testing addresses is that, “Testers need to continue earning a living in their chosen profession, to feel belonging in a community, to earn the respect of their peers for a job well done, to continue their self-development and learning, to add value and make a difference.”
5. If there is any possibility that we can get folk’s needs met by some other strategy than testing, which is most economic and most human.

Alternative to testing:

While I tried to think deeply about the above argument in the list, I felt that it is indeed possible and is being already done by testers who understand what testing really is, who know how to test software rapidly, inexpensively and in a way that would still stand up to scrutiny. It is already being done by testers who know how to do “more with less”. The only difference is, they still call that strategy as ‘testing’ but hey, what’s in the name as long as it does what matters?

I would not hold it against Bob (or anyone else with similar opinions) if they want to find alternative for “testing” (whatever it might mean to them) because it’s possible that what they saw someone doing as “testing” was not more than filling excel-sheets with Pass/Fail and being a bottle-neck for deliveries. If that makes them want to find alternative to ‘testing’ or getting rid of it completely then I can totally understand it.

The good part is, testing is far beyond just a process, profession, phase or strategy for most of the thinking testers today. For us (thinking testers) Testing is a performance as James Bach rightly says. And the number of testers who think this way is growing like never before.

Testing is needed so that testers can earn their living:

This can’t be really true anymore, at-least for the testers who know how to add value with their work and what their worth is in software development. I completely understand the humanitarian aspect here but with due respect I deny that ‘testing’ is needed so that “testers” continue to earn their living. This holds equally true for all sort of professions in software field for you never know what would science discover tomorrow.

Today, earning the respect of peers appears an overrated issue to me, to be honest. If non-testers understand how “testing” helps their work then there is not any reason why someone would disrespect testers. How can someone’s ignorance be someone else’s problem? As a matter of fact, I have seen programmers feeling envy of their testing/QA counterparts for the kind of weight they hold in a team and the way testers get treated as project-trusted advisors. I have seen programmers who do not understand the difference between writing a code “that does what specification says” and to “develop a product that customer would like to buy/use”. Does that mean “programmers” have a respect issue? I don’t think so. Respect issue with testers probably gets highlighted because they are far less in numbers compared to their programmer counterparts (1:4 I guess?) and unfortunately, bad testers continue to outnumber the better ones. Slowly but surely, this is changing for better.

Testing adds little or no value from customer’s point of view

The value testing can add to the project can be best summarized by Bob’s excellent definitions Quality and core purpose of Software Development.

According to Bob, the core purpose of Software Development is, “to create elements of complete products or services. Complete products or services, which attend to – and hopefully meet – the emotional, human needs of a variety of interested people”

Bob’s definition of Quality says, “It is meeting the needs of some several collections of people” and I agree with that in principle.

Meaningful testing caters to ensure exactly those and if that’s not a value then what else is? And most importantly, customer or anyone for that matter would understand this value provided by “testing” only if they know that “testing” has a role to play in it. Do we give up on better practices, making better technological choices just because customer fails to understand them? No, instead we help them understand what they really want and how best we (as service providers) can do that for them. Why to give up on testing then if customer does not know its worth?

Customers are unkeen to pay for testing

I feel that customers are unkeen to pay more for “entire cost of software development” and not just for testing in particular. Customers want a quality product at a price they can afford. Whether to do it by cutting the testing short, with no testing at all or by employing testers who know their job very well, is service provider’s problem. And I feel there is a lot of other waste we need to get rid of apart from bad testing. I would highly recommend checking out “Lean Software Delivery” by Matt Heusser if you are curious to know more about this subject.


It’s possible to deliver software that "just works" without having to “test” it

I admit it is possible as long as our "it works" matches with customer's expectations and user experience. But ensuring that they match is hardly possible without doing any testing.

Some years ago, I had asked same question to Jerry Weinberg and his response was detailed enough for me, not to think about that possibility anymore.

I asked Jerry if there is any method/strategy that can eliminate the need of testing or testers as a role. Jerry’s response below:

You're kidding, right?

This is a pipe dream of managers who do not know how to manage s/w development, just like their dream that some magic method will allow them to get rid of developers. "Tester" might not be a job description, but "testing" had better be part of somebody's job description--and taken seriously.

Over more than 50 years, I have watched managers fall for these illusions. Sure, it would be nice to be able to develop s/w without testing, or without developers. Indeed, it would be nice to become a billionaire without leaving your easy chair in front of the TV. But just because it would be nice, that doesn't mean we know how to do it.

The only times when I've seen s/w developed w/o testing, the s/w produced was not usable, and nobody wanted it. So, I guess if nobody wants the s/w, it could be developed w/o testing.

Heck, I could cook a fabulous meal as long as nobody wanted to eat it and live through the experience.

The times are changing fast and the pace with which science is advancing, I sometimes feel, "Would humans be ever needed in future to build software for customers? What if they build a computer that reads the requirements and delivers the software just like a pizza fresh from oven?"

“No Testing, No Agile and No Software Delivery” attempts to flag up these questions. No soapbox. Just open enquiry.