We live in a cruel world. Our profession of software development is very young compared to other fields such as banking, hotels, or carpenters. I truly believe we have taken a couple of wrong turns in our short history. In this blog entry I try to shed some light on it by some seemingly unrelated stories.
The woman in the bus
A woman heads home from work. She has spent all day working hard – actually 10 hours straight with hardly a break in it. She needs to drive back home for 60 minutes. She waits at the bus stop for the bus to take her home.
She enters the bus. There are no free seats available to her. She goes to a restricted area of the bus, and takes a seat there. Immediately the bus driver points out that she is not allowed to sit there. Other passengers start to rally.
The woman leaves the bus, and walks home.
Outrageous story, isn’t it? How would you react if the bus driver was black, and the woman was white? Keep that thought for a minute.
Now, how would you react if the bus driver was white and the woman was black? Keep that thought for another minute.
To be frank, this one was paraphrased from the story around Rosa Parks that started off the whole movement to give blacks the same rights as whites in the USA in the 1950s and 1960s.
Rosa Parks was able to deliver passive resistance. She initiated that blacks went home from work by feet for several months. Just to indicate that they are treated differently.
Eventually they were able to change the public view on blacks and whites in America – though I think America still needs way to go on this.
Not in my contract
I heard the following story from a colleague who was coaching teams in a larger company a few years back. They talked to team members about unit testing, how to do it, and tried to motivate them to essentially apply coding practices from the 21st century, rather than the 19th.
One of the developers went to his desk, opened the drawer, pulled out his contract, and told my colleague that it didn’t state to write unit tests in the contract.
Now, observe your reactions to this story. Keep that thought for a minute before reading on.
Seriously, how can the programmer dare to refuse testing his code? Seriously, he can’t. He is not caring about quality in the code. That guy should be hung, drawn, and slaughtered – shouldn’t he?
Related, he is handing off work to his fellow testers. Thereby he is postponing feedback for the work he is doing. He will have a hard time finding out about those bugs later. It’s even worse than that, because he might start to justify his coding decisions later in order to avoid the tremendous amount of re-work later.
Of course, you scream that that guy should report to his manager – and maybe get fired. Rightly so. That guy does not care about the product, the quality, and the underlying system dynamics in play.
Another story
Here’s another story that I experienced one way or another. I consult with a development team for the first time. I notice that several of the team members have a problem with one or two others. It’s even worse. They are close to a witch hunt – of course an instance of the identified patient pattern. Everyone hates those one or two guys on the team since they are clearly not contributing, or helping the team to deliver better software.
I approach the one or two guys. I point out that they need to learn a certain skill to improve the overall team performance. I point out that they can learn from their team members. I point out that they can even teach their teammates some of their special skills.
They still refuse to do so.
Again, take a minutes to examine your reactions to this story before reading on. I will wait here for the time being.
Just a bit.
Ready?
Ok, here it goes. I was speaking about several situations I faced when dealing with testers on agile teams. The skill they refuse to take on is the programming skill. They are not willing to pair up with a programmer – to learn some of that – to teach them some of their testing skill.
How do you react now to that story?
I wonder how we started to treat testers differently to programmers. The programmer that does not want to learn anything about testing is cursed, hates, and brought to the stake. The tester that refuses to learn anything about programming is promoted to test manager.
Seriously? Where does this underlying value system come from?
To me, there are two major factors involved here: history, and cognitive dissonance.
Historically our industry suffered from good people in the 1970s and 1980s. That was also when we started to automate a couple of business process. At that time that people that were eventually replaced by automation were asked to become the testers of the software they were replaced with. Maybe they liked it, and became testers themselves in the end.
Typically these testers don’t have much programming know-how since they came from a totally different background. Skip forward twenty years, and we ask them to learn programming. Unlikely to work.
Cognitive Dissonance is cited by Leeds & Weinberg in Computer Programming Fundamentals. My paraphrasing of it is that a programmer cannot test effectively his own code if he knows what he has been coding, anyways. The historical solution that our industry came up with was to separate the person, team, and even the department that tested the software compared to the one that wrote it. Nowadays this is the prevalent solution to deal with cognitive dissonance. Some call it independent testers. Others call it the four eyes principle.
The problem I have with this, is that cognitive dissonance is taken as an excuse in order avoid learning programming, while programmers are expected to learn testing on their end.
Note, that several experts in the testing field recognize that programming skills help testers to large extents. I have read about it in Basiswissen Softwaretest, a German ISTQB book, in Lessons Learned in Software Testing, the context-driven foundation. I am sure there are others out there. The bottom line is that all these experts state basic programming knowledge helps a tester to improve their testing. How come we still use that excuse to not learn basic programming skills? On face value, it would improve our testing skills even further.
One thing I learned from my father was that learning does not end after your first education, rather it starts. My father was a car mechanic. He didn’t take university courses. He didn’t study computer programming. Though he knew that he needed to learn all his life – even after finishing his apprentice years. Unfortunately some of the higher educated folks do not seem to have the same attitude when it comes to learning. Sadly so.
So, what additional skill did you learn today? Which one are you going to learn?
Coding is not a skill that suits every temperament. It is one thing to say that learning is important, but quite another to demand that everyone learning some of everything. Many people who might be powerful as testers are not interested in coding. Let them develop other skills. Don’t impose your biases and preferences on everyone, Markus. That creates a hostile atmosphere.
As I have commented earlier, here, specialization is not a sin. People who take the time to develop special skills also have a place on good teams. In fact, they are especially important to the team dynamic, I have found.
I advise testers, if you want to learn to code, do it. If you don’t, then don’t. Develop the skills that suit the rhythms of your mind, not some template created by a shadowy Agilist guru.
I code, and that helps me test. But I don’t need everyone in the team to be exactly like me.
As an automation engineer I think it is useful to be able to read and write code, but I think it is way more useful to understand some of the principles. I want a tester to understand the basics of data structures. Why a “Date” is different from a “String” and why converting between the two has risks. Why sorting by String causes the order to be 1, 10, 3 instead of 1, 3, 10. Someone who can read code logic flow diagrams. These are valuable skills, but while I want testers to know them, requiring ALL testers to have these skills is silly.
Testing, like development, requires different skill sets. What about database developers whom often (for cultural or code reasons?) don’t write unit tests on their stored procedures or triggers. I knew one developer who in two years never made a code-logic bug (spec misunderstandings did happen, but never something a unit test would have caught). Unit testing was not a requirement for him. You can have a developer who doesn’t do unit tests but rather does more of the development documentation while the rest of the team helps cover because they don’t like documentation. In my experience in agile development, the team decides how work is divided, and I have seen these sorts of choices many times. Sometimes they work out, sometimes not. But not everyone is suited to be a Jack of All Trades.
That being said, that does not excusing a person whose team asks them to try something, who says, “We’ll take on some of your work load while you learn” from at least trying. Maybe they will never pick up the skill, or will never be good at it, but at the very least they should try, even if it is just to humor the team. Acting like the developer in the second scenario and pointing to your contract the instant you are asked to try something new seems like a jerk move in my mind.
– JCD
Interesting thought, JCD. How did the developer you mentioned transfer his knowledge to the teammates that needed to maintain his code in his vacation times? Furthermore, which skills should a tester have? And how does he know which one to pick?
They often worked in silo projects on their own changing areas no one else touched because of their experience and because they were less risk. They did a lot of communication using emails would often bring the tester over to show their logic. They were a craftsmen in their care and were always slower than other developers. They came in on weekends and felt that was reasonable, not because of pressure but because of love of the craft. I’m not saying they didn’t write unit tests, just that ultimately, their careful methods kept the quality up in a way others couldn’t achieve. I don’t think they could teach others to do the same; their skill isn’t something you could package up and train others. The “Expert” in the Dreyfus model of Skill Acquisition would be the best way I can label it. Ultimately, the team’s failure was in that he was not replaceable because no one could do what he did with the skill he did it at and unit tests wouldn’t have cured that problem.
As for what testers need to learn, why don’t you insist testers learn formal artistic design? Most development has a user interface, and it seems they are done poorly, so why worry about the underlying code when we fail to handle the presentation? Or perhaps we should have testers learn statistics as we could use statistical models for user interactions to decide what to test. Perhaps we should force all testers to learn accounting rules since clearly all testers affect the budget of a company. Why don’t all testers who do QA (rather than QC) have MBAs when most testers work for businesses and often we are involved in the process and attempt to improve it? While intended as rhetorical questions, I guess I fail to see why code should be the center of every testers world when there are many different areas that might matter more in particular cases. Allow me two examples then I’ll try to answer your question directly. Q1: What about a business in which the customer is in a specialized field like corperate accounting? Would account or programming be a more useful skill? Q2: Is it better to find code-oriented bugs or a user-oriented bug? (Bonus question, what answer would each of the schools of testing give?)
Ok, so you wanted some skills that testers should learn outside of coding:
* Communication: Social Skills, Speaking & Writing
* Coaching & Mentoring
* Defect Management
* Management: Leadership, Time Management, Risk, Planning, Culture Development
* Learning
* Logic, Rational Thought & Math
* Modeling
* Risk Analysis
* Tech (Like using the shell, profiling, etc.)
* Test Design
I don’t think you can know what to pick. The keyword there is know. In the same way you can’t know if you are improving, you can’t know what skills will be valuable. Team suggestions are useful as a heuristic and if a team asks me to try something, I’m certainly inclined to try it, including learning to code. However, sometimes you know somethings are not going to work. For example, I’m terrible with languages (not computer languages), so if a team asked me to learn Spanish for localization testing, I might say it isn’t the best use of my time. If my boss required me to take classes during work hours, then I’d try, but I might also start looking for a new job,.
– JCD
Hi JCD,
I see value for testers in having all of the skills that you mentioned. The question is how deep. And I know that I am actually drawing a false dichotomy here – on purpose. I will explain that in another blog entry. :)
Best
Markus
I am not sure whether you grasped the essence of my main message, James. How come we treat programmers differently than testers? How come we demand that programmers learn to test while testers don’t need to learn programming? Why do we draw this imbalance? Maybe a philosopher could help me understand the bottom line of those questions.
The thing is that testers and developers are not easily exchangeable.
To arrive at your answer you need dissect the two roles and identify individual skills at a very low level. Once you do that you’d need to start thinking about the amount of workload and time needed by each role to complete its tasks, then factor in general practices.
Personally, I find that basic testing skills are easier to pick up than programming, but using them correctly requires rigorous execution. Programming however requires much more continuous practice and learning. This however, comes with a disclaimer; test automation guy is not a tester. That guy is a coder making a testing machine.
It is a false assumption to compare history of racial separation to corporate culture. Both of these things are highly unrelated because on one side you’re putting political, cultural and legislative history and on the other corporate training, agile methodology, and personal competences. It’s not like the white driver could be compared to the tester in any way.
Agile way of working asks experts and industry newbies alike to broaden their skill sets even if it means they will be moved out of their comfort zones. This make people cranky, defensive, or aggressive. Another fallacy in your article is the the implication that all coders get shunned for not wanting to test and all testers are excused for not wanting to code. Truth is that there are more variations on this. Coders who are ok with testing, those who try and are asked to stop, testers who get paycuts for not conforming to Agile, etc.
So why does the coder get bad rap for not wanting to test? I’d guess that it’d be his personal approach to the issue that causes backlash. Why would the tester be OK here? Maybe because a single sprint would not be anywhere near enough to contribute meaningfully?
Hi Matt,
I draw on the Toyota system there that teaches everyone to learn a bit about the activities around them, so they can compensate for queues piling up before or after their work. That said, I value in cross-training programmers in architecture and design as well as in testing, and I see value in cross-training testers in programming and operations to maintain flow.
Best
Markus
I humbly disagree with you in regards to automation people being coders. I think the distinction is not that clear cut. My entire team works on automation of APIs that are computer to computer communication. If you hand craft curl calls or use Java, does that convert you from being a tester to being a coder? Or in your view is it not possible to test APIs (assuming no GUI) as curl calls are effectively code testing code? In fact, if a curl call was moved into a bash script that was called and then the output was verified by a computer (say a straight string compare), did the tester who made it turn into a coder?
Also, the first time an automator does something, they are likely to manually test it. Are they at that point in time a tester and later not? When an automated test fails and they manually run the test, what are they?
Even worse yet, if the automator writes the steps in the automation (E.G. Step 1. Log in Step 2. Search for …), is that just code design or is there test design?
– JCD
Overall I like the post, it makes me think. You make a good case that testers should learn coding skills. At least as well as programmers we work with have learned testing skills, which in my case is pretty well. And I enjoy learning coding skills.
But I would quibble with your observation: “though I think America still needs way to go on this.”. Absolutely – and so do European countries and the whole rest of the world though in some cases with different minorities. :->