Me and Peter (aka Simon) Schrijver arrived at Runö in Åkersberga early Sunday morning after picking up Fiona Charles at her hotel in Stockholm. Here we met the organisers of the conference: Johan Jonasson, Hendrik Andersson, Ola Hyltén, Torbjörn Ryber and Hendrik Emilsson. The venue is beautiful!

The venue: Runö – Möten & Events

Hotel buildings 1 and 2	Keynote hall (l) and main building (r)
My Room	The view
More view	The garden

Sunday May 6^th: LTWET (LEWT goes Sweden / Let’s LEWT)

After a quick breakfast I joined a LEWT-style peer workshop organized by James Lyndsay. Peter joined the people who were trained as facilitators for the Let’s Test conference by Paul Holland. Later that morning some of them would join the peer workshop. The theme of the peer workshop was “design” and we started with a small group: James Lyndsay, Desi (James’ wife), Neil Thompson, Fiona Charles and me. Later Paul Holland, Ilari Aegerter, Ben Kelly, Torbjörn Ryber, Rikard Edgren, Peter/Simon Schrijver and Simon Morley joined.

Dot voting monkeys	Great topics
Fiona, Paul and Ilari	Torbjörn and Peter/Simon
Desi, Simon and Rikard	James, Ben and Neil
Neil on relation between analysis and design	Rikard on Charisma Testing
Simon on Experimental design

Sunday evening May 6^th: pre Let’s Test fun

After dinner drinks	More drinks in the cafe
They also have coke ;-)

Pascal went home with this challenge: “Apply the Constructal Law to improve testing.” This challenge James gave himself since he is reading this book. Jean-Paul asked for a challenge via twitter and got this one: “Explain dendogram-based testing”. Since I start with BBST tomorrow, I didn’t ask for one.

We discussed a lot of topics, one of them was coaching. In July I go to Test Coach Camp in San Jose the weekend before CAST 2012. I told James I had an idea for a session at Test Coach Camp:  “What they teach us in TMap Class and why it is wrong”. I think he likes it I asked James what he would do if he had to train newbies to be testers. He answered that he would have them test something. He certainly wouldn’t start with lectures about processes, definitions and testing vocabulary.  During the testing session the aspirant-tester will do stuff that can be named. They will (ignorant) use all kinds of techniques that can be further explained and explored while they pop-up.

James also gave an interesting insight: the way testing is often trained and implemented results in dull testing jobs where most of the great people (who could be excellent testers) will run away from. I have to chew on that a little more, but I think this might be true. It definitely rings a bell.

Today I created a first draft for the proposal for Test Coach Camp: 

“What they teach us in TMap Class and why it is wrong”

In my former job I have been an instructor/trainer for ISTQB and TMap classes. This was before I saw the Context-Driven light I trained ISTQB and TMap to people new to testing and also lots of experienced testers. I also was an instructor for all kinds of other training courses. These training courses are not focussing on the right things and are not preparing testers to do proper testing. Let alone that they encourage testers to become excellent their profession. For example: in these 3 day courses, all exercises are done on paper without actually testing software. This makes me wonder if there are classes where developers are trained without actually coding.

In this session I would like to point out the structure and content of a typical TMap (or ISTQB) class and the method/approach used. In the discussion later in the session the group collaborates in listing what is wrong with this approach and what can be done to improve it. This creates an insight in what is wrong with the majority of training courses in my country (and probably also around Europe and the rest of the world). This insight can help us create training courses to properly train people in testing, but also improve existing classes.

Let me know what you think and please share your experiences.

• Experience what a testing dojo is (useful? fun?)
• Learn from group
• Practice stuff we learned in RST last year 

At our dojo 20 people showed up: mostly testers but also a business analysts and a developer. After ordering pizza for all, I did a short intro presentation. I explained what a testing dojo is, what the rules are for the dojo and the mission for the evening. I wrote down the rules on a flip-over and put that on the wall:

• Work in pairs
• We recognize 3 roles:
1. Driver / tester
2. Recorder / note taker
3. Observers (audience)
• Switch roles after 5 minutes:
1. Tester –> audience
2. Recorder –> tester
3. Audience –> recorder
• Everybody in audience (observers) take notes using checklist
• Audience does not interfere with testing, unless they are asked

Mission:
Test parking calculator Gerald R.Ford International Airport using SFDPOT and the Test Heuristic Cheat Sheet.

Observer checklist:

• What happened?
• Testing
• Communication
• Collaboration
• How do they communicate?
• Are they listening to each other?
• Who is in charge?
• Also note emotions
• What path do the testers take? 
• depth
• breadth
• Explore first: what do we have?
• When does what happen
• What happens if they find a bug?

I gave the group a sneak preview of the parking calculator. I also showed them the webpage with the information on the car parking and the parking rates. While preparing the dojo I thought the participants would like to do some preparation while eating pizza. I figured they could think about their approach and maybe write down some test ideas or other stuff they thought that could be useful. But the group wanted to start right away. There were some questions about the exact purpose of testing this application. I told the group, while playing the role of product owner, the goal is to inform me if this calculator needs adjustments.

In the room the participants were sitting in a u-shape all facing the screen were the beamer projected the display of the laptop in front of the room. The pair behind the laptop was facing the group. I think it’s not easy to test when 20 people are watching you and you are sitting in front of the room. In the back of the room were 2 flip overs with the parking rates. We decided that everybody would have 3 minutes of testing time and after 3 minuted we would switch roles. After three pairs had finished their testing we stopped for a short retrospective to discuss the progress so far. We noticed that nobody was in charge really and communication between the pairs was minimal. They were trying stuff, without having a clear strategy or approach. The first pair could get away by telling they were exploring the application to see what they had in front of them, what it could do, etc. The other pairs had some sort of strategy but couldn’t explain. A discussion on the further approach took place and the group decided to create a list on a flip over with items that needed testing. I noticed that SFDPOT wasn’t used explicitly and the strategy followed by the group was almost fully focussed on testing functionality.

After a flip over with the “test strategy” was created by one of the participants, testing was more focussed. But still I noticed that it was difficult for the participants to test in pairs (communication) and keep focussed without scripted tests (structure). None of the pairs debriefed or communicated with the next group. To fill this “gap” I asked every pair after their time was up, if I could “tick off” one of the items from the test strategy. One of the participants created a list of test ideas before he took his place behind the laptop. It was fun to see a lot of different styles and approaches. I also noticed that being observer is a rather difficult job. Not a lot of notes were taken on observations despite the checklist on the wall. Most of the participants focussed their observations on the testing and the application being tested, rather then on the people testing and their communication and collaboration.

After all pairs had their go testing, we did a retrospective. Below the feedback from the group. 

Lessons learned:

• Group was too big, a group of up to 10 people is better.
• More time to test: with a smaller group it’s probably better.
• Give the group a bit more structure. It is helpful when the starting point is clear.
• Stop more often to evaluate. Idea: 1. Mission – 2. Test – 3. Self debrief – 4. Group feedback – 5. Test again

It was a great evening, although it didn’t went as smoothly as I hoped. But we learned a lot about testing dojos and I think it was a successful evening. I hope the attendees went home with the same feeling. In a small group we discussed the dojo somewhat further and the reactions were enthusiastic. There is still enough room for improvement, as always: practice makes perfect! For a first time I think this was quite a successful evening. A second dojo is already planned. I am looking forward to it.

Other notes made during the test dojo:

This truely will become a magnifiant year! Busy but awesome for sure. Some highlights:

• Together with DEWT colleague Peter I am going to Test Coach Camp and CAST in San Jose USA. Still have to send in some proposals this week(end).
• I am doing talks at Czech Test and Let’s Test Conference
• I am finally going to do the BBST training: foundation, but maybe bug advocacy also.
• DEWT colleague Jean-Paul and I will try to get a tutorial at the Agile Testing Days
• Will do a lot of writing: a book for TestNet on the future of software testing, a column for agile record, columns for testnieuws.nl and testnewsonline.com and my own blog. And if I can find some more time I’ll try to get something published in Testing Planet.

And another DEWT peer conference to look forward to! A lot of testing, conferencing, meeting and learning to do!

This is the third and last part on the theme “how to become a software testing expert.” Part 1 “You can learn testing!” can be found here and Part 2 “What makes a good tester?” is here.

In part one I said that if you want to be an expert software tester, you must qualify yourself in many skills. That through feedback, actively seeking and making mistakes, helps you find out where you can improve. And that coaching is a great way to learn faster. In part two I stated that passion and attitude are most important. Then the skills, competencies and qualities such as proactivity, communication, social / emotional development, collaboration, fast learning, curiosity, but also the ability to apply test techniques. Knowledge to me is the least important. A good tester has test, technical and domain knowledge (in that order of importance).

Passion and attitude
“Without passion no change and no progress” said Ferry Bezem of Twynstra Gudde in this Dutch Article. “How passion for your job can lead to success” is one of the other many articles I found when I googled “passion in your work”. To become succesfull, you need to find out who you are and where you get energy. To become good, you need to have passion for your profession. This article explains how to “develop” passion. In addition attitude or mentality are important as well. With the right attitude, you will be successful for sure! And don’t forget: you can change your attitude!

Critical thinking
Testing for me is questioning a product in order to evaluate it. A tester does this by learning everything there is to learn about the product and analyze this information. Critical thinking is an essential competency of a tester. But how many testers train it? On a well known Dutch book site I searched for books on critical thinking. What struck me was that there are several books on critical thinking for medical personal to find. And that sounds actually quite logical: medics diagnose patients, testers do the same for their “patients”: the test object!

Waste

We write comprehensive test plans that are never read. We use extensive templates to make sure nothing is forgotten (and we do not have to think too much). We do product risk assessments but subsequently we don’t do anything with the risks identified. We often do not use any test techniques. Why?! I think because many people simply don’t know how. I often ask why test techniques are not used. The most common answer is: because there is not enough time!? But these techniques should make our testing more effective and efficient, don’t they? As a tester you should be dreaming these techniques. You should OWN them!

Adaptive?
Every novice tester in the Netherlands starts with TMap or ISTQB. With that fact in itself is nothing wrong. A three-day class where the basics of software testing are taught is a good start. But too often that’s it. We like to guide our testing with process models: ISTQB and TMAP are full of them. But the reality is often more complex and testers get in trouble when the situation is slightly different as they are used to. The choice of a particular tool, technique or method depends on the context. TMap Next claims to be an adaptive method, but do you remember how much time was spent on this topic in your class? And how adaptive are you yourself? Do you use the same template over and over? Do you simply copy the test plan for the next release using a search and replace?

Learn, practice and training
I learned very much by critical reading. There are many free software test magazines and there are many great books on software testing. The internet is an excellent source of (often free) information. There are many videos available of presentations at meetings and conferences. On my blog I keep a list of great resources for testers. Lynn McKee has a similar list. Or start reading blogs, twitter can inform you about new interesting blogs and other things worth reading.

Try weekend testing or a testing dojo to practice your skills. Join a local software test community or organize your own gathering with a group of testers who want to meet and learn. At several employers I introduced intervision meetings for testers. I also founded DEWT with a group of passionate colleagues: like-minded people who like to challenge and inspire each other. We spend many hours discussing our profession and we certainly do not always agree. We discuss and practice in a safe environment and learn from each other.

Try something different
Have you been a software tester for years and are you planning to spice up your resume with another certificate? Then maybe the BBST training is something for you. Let me warn you in advance: this training will give you no certificate and it requires you to study and do exercises almost daily for a month. If you really want to learn, you need to invest a lot of time. Malcolm Gladwell claims in his book Outliers that the key to success in any field is practicing 10,000 hours. Try a training that changes your view on testing: rapid software testing for example. This training has changed my view of my profession and inspired me tremendously. Visiting conferences can be very inspiring and instructive. Join TestNet or another (online) testing community like The Software Testing Club and get inspired. You have plenty of choice!

Learning from others
I enjoy working with others. As I observe, I ask questions or explain my view on the situation. We still can learn a lot from our colleagues in projects … and vice versa! And I’m not just talking about fellow testers. A programmer can build a tool or script in only a few hours that can save testers days of work. By doing unit tests together, we gain insight in what developers test and how they do it. Try working together: pair programming or pair testing can be a powerful tool. Unfortunately, it has a negative image, because it seems to double the effort. But I think it can be beneficial. The added value is mastering the details of a job easier, fewer mistakes, faster learning, team building, cooperation and fun.

Writing and presenting
Blogging, writing columns or giving presentations forces you to structure your thoughts. In addition, your stories or presentations will trigger reactions by others. By taking this feedback seriously, can you sharpen your thoughts and learn again.

Finally
Ask yourself what you can do better often. Evaluate! Ask for reviews on your products regulary. Also ask for feedback from your colleagues on the process, your skills and your performance proactively. Furthermore, my advice is simple: you need a lot of practice to become an expert. So what are you going to do tomorrow?

————

Huib Schoots sees himself as a context-driven tester. Currently he works as team manager testing at Rabobank International and he is board member of TestNet. He is a member of DEWT (Dutch Workshop on Exploratory Testing), student in the Miagi-Do School of Software Testing and maintains a blog on www.magnifiant.com

What makes a good tester?
This is the second of a series of three columns. The central themes of the columns is “how do I become a software testing expert?” Part 1 can be found here.

The question “what makes a good tester?” keeps us busy. This was demonstrated by the attention this subject received at different conferences. At EuroSTAR Susan Windsor gave a well attended presentation about this topic called “How to Create Good Testers”. During the Agile Testing Days, a group of passionate and renowned agilist and testers got together to discuss various test subjects while enjoying beer and pizza. After an inventory and a “dot-vote” the topic “Great Testers” received the most votes. That gave great input for this column, thanks guys!

In this Dutch article on talent, personal qualities, skills and competencies, Patrick Schriel says: “A skill is the ability to be able to perform an act or solve a problem. Competencies are knowledge and skills, they are not innate, but are caused by intense and deliberate practice “. With skills I think of being able to apply a particular test technique, or being able to work with certain systems, etc. But for a tester key qualities and characteristics are important and these are much harder to train. Think of pro-activity and creativity. In addition, attitude (and / or mindset) is important. What is your feeling about change, what are your beliefs, how open minded are you?

Attitude
What makes a good tester? It depends on the context. Every project is different, every team has its own dynamics and each test has different requirements. Lisa Crispin said during the meeting in Potsdam: “Most important is attitude, we will teach them the skills”. And I totally agree. Passion for the job to me is vital. In the attitude of a tester, I find curiosity also very important. Or as Richard Feynman put it: “The Pleasure of Finding Things Out“. A tester is always looking for information, how does this work? He constantly is asking questions to understand. I remember the following quotes from the rapid software testing training: “A tester’s responsibility to remain unsure when everybody is sure” and “Testing is about questioning and learning under conditions of fundamental uncertainty”. A tester knows that things can be different (Jerry Weinberg). And in Potsdam Michael Bolton added “a good tester is able to see the complexity of things that seem simple and the simplicity of things that appear complex.”

Passion
Passion provides drive for commitment and enjoyment. I think passion and skills enhance each other: the more joy you find in something, the more time you’ll spend, the more exercise and practice you get, the better you become. The better you get, the easier things are, the more you discover, it becomes more fun. The snowball starts rolling!

Competencies
A good tester is proactive and able to work together and knows that software development is a team sport. Something you do with a team and you as a tester are actively looking for opportunities to work together with your team. A good tester knows that he is even more effective when he works with developers for example. A developer can help him test faster and smarter. Obviously communication is important. But what is communication anyway? In Potsdam Michael Bolton shared his list with 27 (!) items that have to do with communication: conversation, presentation, argumentation, rhetoric and visualization are some of them. In addition to all above social and emotional development is important to collaborate effectively.

Knowledge
Of course knowledge is important. But curiosity and the ability to learn quickly, makes that a tester can quickly attain knowledge and therefore less makes it less important. A good tester has knowledge of the following (in order of importance) testing, IT and domain. But attitude, skills and qualities for a tester are far more important! It was Lasse Koskela who talked about the “Least qualified implementer” in his keynote at the Agile Testing Days. This is the principle that in an agile team someone with the right skills but the least knowledge picks up the work item in order to get the whole team as much as possible at the same level of knowledge. Interesting! I want to read more about this.

When I recruit testers, the behavior and attitude of the individual is most important: his competencies, motivation and attitude. Knowledge is also important for me, but is more easy to learn quickly … that is, if that tester is eager enough to make his work a success.

Note: in a reaction on the Dutch version of this column Derk-Jan de Grood mentioned that in the examples I cited I was limiting the tester to a error seeker, a developer and a critical questioner. It is certainly not my intention to confine the tester an error finder, developer and critical questioner. So if that is the message which you took away from my story, then I need to be clearer. Testing to me is: “questioning a product in order to evaluate it”. A tester is someone who provides information about the product. He does this by learning everything there is to learn about the product . It is possible that a tester does not find any errors (although we all know that they are in there for sure). While I was writing my reply to Derk-Jan I realized that I forgot a very important skill / attitude in my story: the ability to THINK! A good tester thinks! Systems thinking and critical thinking are skills that every tester should have and train.

The last part of this series looks at where and how you can improve your knowledge and experience.

Huib Schoots sees himself as a context-driven tester. Currently he works as team manager testing at Rabobank International and is board member of TestNet. He is a member of DEWT (Dutch Workshop on Exploratory Testing), student in the Miagi-Do School of Software Testing and maintains a blog on www.magnifiant.com

Jean-Paul and I love to discuss testing with other passionate testers. That is why we
both are in DEWT, participate at TestNet and some other initiatives. Zeger
van Hese, fellow DEWT (and Programme Chair EuroSTAR 2012. GRATS again
Zeger!) told us about the Rebel Alliance at EuroStar 2010 and Jean-Paul and I decided to try to organize something similar.

So we arranged a room, made a shortlist of special and interesting people from the
(agile) software testing scene and send out an email announcing PaTS: a get
together on Wednesday evening 16th of November 2011 in Potsdam. We defined our
event as an informal off-conference evening, with drinks and pizza to talk and
debate about testing, have fun and debate some more. It turned out to be a fun and interesting evening!

Rob Lambert, Rob van Steenbergen, Daniel Levy, Janet Gregory, Simon Morley, Brett L. Schuchert, James Lyndsay, Stevan Zivanovic, Jim Holmes, Bart Knaack, Lisa Crispin, Olaf Lewitz, Mike Scott, Jurgen Appelo, Thomas Ponnet, Cecile Davis, Michael Bolton, Jean-Paul Varwijk and me gathered in the test lab and we first ordered some jumbo pizza and beer. Thanks to Telerik for sponsoring the beer!

We made a list of interesting topics and conducted a “dot vote”. This is the list
and the dot ranking:

Great Testers – 10
Management of testers – 8
Acceptable level of risk – 8
DEWT / Peer groups – 6
Tool topic – 3
Coin game – 2
Retrospect ATD talks – 2
Bathtub – 1
Continuous delivery – 1
Cloud – 1
Testlab – 0

We agreed to give every topic 10 minutes and “Caesar vote” after the time box to see if the group wants to give the topic extra time. During the evening the 4 top topics were discussed. Rob Lambert made some great mind maps of each topic. He let me take pictures so a massive thanks to him! You can also find them here.

Great Testers

Lisa Crispin started the discussion: “Most important is attitude, we will teach them the
skills”. And I fully agree. The group also mentioned passion as very important. When somebody is passionate about his work, he wants to improve and learning will become an essential part of his daily routine. Curiosity and quick learning are skills which were mentioned here as well. Another characteristic of a great tester is to be able to see things different or as Michael Bolton said: a great tester is capable of seeing complexity in apparent simple things and simplicity in apparent complex things.

Of course communication was mentioned as an important skill to be able to exchange knowledge. Michael Bolton ask what was meant with communication and he summed up 27 different forms of communication. I have to study the list, but I think that will end up as a separate blogpost here.

There was also a discussiuon about structured vs. unstructured testing (scripted vs. exploratory testing). What the conclusion was of this skill I can’t remember. But for me I value testers who can do both and are not affraid of thinking of their own. Exploratory testing gives a tester freedom but also forces him to keep thinking.

Other characteristics/skills mentioned during the discussion: cultural fit, humility, empathy, honesty, domain knowledge and sense of humour. Good to see a lot of human factors discussed.

I will further work on the other 3 topics discussed. But the mind maps by Rob Lambert give you a nice overview what was discussed.

Manage / lead testers to become great

DEWT / Peer groups

Acceptable level of risk

You can find some other experience reports of PaTS by Rob van Steenbergen, Jean-Paul and Olaf Lewitz.

This is the first in a series of three columns. The central theme of the columns is “how do I become a software testing expert?”.

To become great in your profession, you need to learn a lot. This seems obvious. Jos van Rooyen wrote an article in Dutch entitled “Hoe goed zijn we als tester?” (How good are we as testers?). In this article he writes: “Many people call themselves professional tester without having a solid foundation. Yes, we follow the ISTQB Foundation, etc. and think that we are professional.” I fully agree with this. Lesson 272 in the book Lessons Learned in Software Testing: “If you can get a black belt in only two weeks, avoid fights”. You have to learn and practice a lot to become good at your profession. But that goes for everything: just think of sports or music.

Jos draws the conclusion that testers on average are good. I do not agree with his conclusion (besides from the fact that mathematically any population is average). I think testers can do much better! On my weblog I once wrote: “A lot of them claim that they are great testers. But are they? I think a lot of testers maybe aren’t that great…”

Knowledge and skills
What makes a great tester? The skills that make a great tester, I will discuss in Part 2. Testing is a profession, that is something I don’t need to explain. And it’s obvious that you need a lot of different skills to be a true professional. And skills, the learned capacity to carry out pre-determined results often with the minimum outlay of time, energy, need to be trained. To become an expert in a particular skill you must practice a lot, and improve yourself continuously. To be an expert in a particular field, such as software testing, you need to become proficient in many skills.

To become an expert, knowledge is important. Knowledge you can gain in many ways and you must never stop learning! “Stagnation means decline,” they say and especially in IT this is true for me. But applying this knowledge is often difficult. Experience is of great importance. James Bach said in his presentation Becoming a Software Testing Expert “Do not confuse experience with expertise.” You can have years of experience, but how do you know that you have gained the right experience? How do you know if you do it “right”? Because let’s face it: there is a lot to be improved in our projects. We have to do much better, but how do we achieve that? And how do we know what we can improve?

Learning
Looking at the different stages of competence in a learning process: you start unconsciously incompetent. So you need to find out where you can improve. Through feedback from others, but also by looking for new knowledge and experience, you find out what else you can learn. In Part 3, I will discuss where and how you can gain knowledge and experience. But we also learn by making mistakes. Preferably in a safe environment. We learn from feedback and evaluations. In the agile world, retrospectives are common and often used. In a retrospective the team identifies what went well and what can be improved.

Coaching
For juniors coaching is essential. But not only for newcomers, for anyone who wants to learn, who wants to develop, a coach has added value. Antony Marcano wrote a nice article in which he says: “One thing that I notice is that while the teams are being coached, they do amazing things. They are more happy, more productive, fast to improve as if there are no limits to what they can achieve”. In many organizations, I notice that coaching is not often used. Here Marcano says: “So, if you have a professional software team without a coach, consider, are you really helping your business save money by going it alone? Or, like the professional sports team, is having a professional development team without a coach another example of a false economy.”

I want to conclude with a tweet from Michael Bolton: “Great sports teams treat practice with the same seriousness as a game — and every game as practice and learning. Testers take note. “

Huib Schoots sees himself as a context-driven tester. Currently he works as team manager testing at Rabobank International and is board member of TestNet. He is a member of DEWT (Dutch Workshop on Exploratory Testing), student in the Miagi-Do School of Software Testing and maintains a blog on www.magnifiant.com

In his presentation, he focused on the question what makes a manager? He used the model of Quinn as the basis for all tasks/roles of a manager. Then he compares these tasks to the testing activities according to TMap. In this part of his talk he covers the role description, tasks in testing and its importance to the tester. Then he talked about the developments in the testing profession covering developments in approach, the testing craft itself and the systems under test. The latter coincided with the theme of this event “The Cloud”. In the last part of his talk Leon gives his view on the impact of these developments on the role of a test manager. I have summarized them in the table below.

So, is the test manager a dying breed or not? I think they are! With developments like agile it is obvious that the team will be more responsible to do planning, coordination and determine the test strategy. For that we no longer need test managers. I never really understood the role of a test manager in many projects. Why should we divide the role of the tester in test executer, test analyst and test manager? We don’t do this in the other disciplines in IT, do we?

I think it has to do two major reasons:
1. The immaturity of the testers and therefore the (wrong?) interpretation of the role tester
2. The career path in many organizations

Immaturity
A good tester IMHO “deals” with all aspects of his job, maybe in consultation with the project manager. The tester controls the entire process from writing test plans containing an appropriate strategy to the reporting to the Steering Committee. I know many testers who find it scary to facilitate a workshop (for example, product risk mapping) or to give a presentation (e.g. reporting to the steering committee). The unfamiliarity of the testing craft by other IT professionals makes it worse. Testing is a difficult discipline but most people in IT do not recognize that. A project manager is often unable to make a good estimate of the testing activites is his project. Let alone that he is capable of creating a proper test strategy. Acceptance criteria are very difficult to determine and test managers are often asked to take care of this.

Good testing is quite difficult. Traditionally, business analysts and developers have a relatively easy job. The analyst has only a few dependencies: he talks with stakeholders and writes that down. The developer only needs a development environment and he can do his work. Testing is often much harder: always at the end, started too late with fixed deadlines, organizing various test environments, the many procedures your organization has to prepare acceptance environments, different user groups who should be involved in testin, etc. A lot of arranging and organizing to do! Hiring a test manager is an easy thing to do. Especially if there are people you think the testing itself is not as interesting. Or even worse: if you are not so good at your craft… It is easy to grow (read: flee) towards coordination.

The interpretation of the test role
In a situation where dedicated testers are present, test managers are often needless. Some time ago I worked as a test manager at a customer. In that organization a group test managers were the only “testers”. Most of the actual testing was done by the functional application managers and the users. The test managers did the coordination, wrote test plans, made sure that the testing went as smoothly as possible and were supposted to coach the users. In my opinion this organization of testing is terrible. Sure, users are involved, but testing is a profession and that cannot be delegated to untrained users. Writing requirements or programming is also done by professionals! The users in this situation had a short training. Enough to do proper testing, right?

Test carreers
But who did invent the test managers role? And why? I do not know where the test manager role came from, but I have a suspicion. Testing in many places is still a role that “used” as a stepping stone to another role in IT (WRONG!). Because everybody can test and testers do not need a lot of training (WRONG AGAIN!) so he can focus on the next steps in his carreer. The knowledge and experience of the the systems he gains along the way may well be used in the rest of his career…

Of course a tester grows and his role will be different over the years. I see many junior testers who are doing far less than a senior tester. I often wonder why. The junior needs to learn the craft and he can learn it by just doing it! So let the junior tester do everything himself. Maybe under the guidance of a senior tester as coach. Learning is making mistakes and evaluating them with your (senior) colleagues.

There is only one role: Tester! Test coordinators are in my opinion just senior testers (foremen) responsible for a certain part of the project. One tester is happy to coordinate, the other likes the content. Ultimately, a good tester has mastered his craft in every aspect!

Imagine that after ten years you still want to grow as a tester. What do you do? This is very difficult in many organizations. The salary scales of a tester will not let you. Test manager is a common role in which testers grow. This is a curse for our profession: it makes people want to make money and grow quickly by leaving the role of “ordinary” tester and become test manager. Without focusing to become a great tester they are busy becoming managers. Too bad!

So, will the role of test manager disappear soon? I think not! The test manager is still needed in many places to fill the gaps created by bad testers not in control of their own job!

I do not think you’re a good tester if you have an (advanced) certificate in ISTQB or whatever. It tells me nothing about your motivation. Especially not when the certificate could (or even worse, should) be obtained during working time paid by your employer… I think that certification is not necessarily bad, but it is certainly no blessing to our profession. James Bach wrote a great blog post about it in 2005 (!). IMHO certification gives a kind of false security about testing skills. And unfortunately this is maintained by the whole market. The big companies (let’s just for convenience call them “demand side”) have difficulty selecting the right external hires. So they look for certificates which makes selecting easier. The “supply side” is more than happy to participate in the certification hype. Because they earn a lot of money by providing training. But also from a commercial interest because the “demand side” keep asking for these certificates. And if they want to sell their people, they must have certificates. Sadly a mechanism that keeps the certification alive!

Certification says very little about a tester. I know plenty of testers with lots of certificates that I would never hire. Why not? Because they are no good in testing! And the certificates do not make them any better.

The CAT website explains: to become a Certified Agile Tester you have to succeed in three different ways:

• A soft skills assessment on capacity for teamwork
• An exam, which requires free answering – no multiple choice questions
• A practical section where the examinee’s testing skills are put to the test.

This soft skill assessment makes me wonder. As a manager I find it difficult to assess my testers after some months or even a whole year, but the trainers of this course can in only 5 days?

The exam doesn’t prove the examinee is a good agile tester! How many exams have we taken during our lives? And do we still know everything we have learned? Like I said in my last blog post, you become a better tester by continous learning, not by taking exams!

The practical section sounds good. Although I cannot imagine that you can fail your certification on this part.  

The course itself looks okay: the subjects trained are interesting and on the reading list are books I have read and would recommend to others. But the whole idea of certification is bad! Agile is a mindset and how can a mindset be certified?

The testing/training industry has found another cashcowCAT!