Magnifiant: exploring software testing

Page 7 of 8

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

April 1, 2012 / / 15 Comments

Yesterday I had diner with James Bach, Pascal Dufour and my testing buddy Jean-Paul. After picking James up from Schiphol airport, we took him to his hotel and after that we had diner. An enjoyable evening with great conversations and some testing challenges.

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.

Testing Dojo

February 1, 2012 / / 7 Comments

Last week I organized a Testing Dojo. I wanted to try a dojo for a long time and I was quite disappointed that Markus Gärtner was ill at Agile Testing Days so the testing dojos were cancelled. What do you do when you want to experience a testing dojo? Right! You just get a bunch of people in a room and try it yourself! To make this dojo a success I read the website Testingdojo.org from start to finish and scanned testing-challenges.org for a good challenge. I also skyped with Markus for an hour to discuss the dojo. For me the goals of the dojo were:

  • 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:

 

Happy New Year! Busy New Year!

January 10, 2012 / / 2 Comments

I know, I am way too late to wish you a happy new year. But I wish you a very happy new year anyway! This year will be a very busy one for me. To create some overview for myself, I created a mindmap of my testing ambitions for 2012…

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

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

How to become a software testing expert?

January 4, 2012 / / 3 Comments

This blog post was originally written as an column for www.testnewsonline.com (English) and www.testnieuws.nl (Dutch).

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?

December 7, 2011 / / 4 Comments

This blog post was originally written as an column for www.testnewsonline.com (English) and www.testnieuws.nl (Dutch).

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 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

Part 3: How to become a software testing expert?

Agile Testing Days: a gathering called PATS

November 27, 2011 / / 0 Comments

November 14-17 I attended Agile Testing Days in Potsdam. It was a great experience! In a series of experience reports on my blog I will reflect this conference. I want to start with the gathering of testers Jean-Paul Varwijk and I organized called PaTS (Potsdam agile Testers Session).

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.

You can learn testing!

November 11, 2011 / / 5 Comments

This blog post was originally written as an column for www.testnewsonline.com (English) and www.testnieuws.nl (Dutch).

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

Second part: What makes a good tester?

The final exit of the test manager?

October 8, 2011 / / 10 Comments

Last week I attended the autumn event by TestNet. This was an awesome event (as always!) where Leon Bosma did a interesting talk on the role of the test manager in the future with the title “Test Manager: the final exit”. His slides can be found here (in dutch).

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.

Role From To
Director He determines what I should do I’ll decide what to do in consultation
Producer He makes sure I can do my job The team make sure we can our job
Innovator He comes up with new solutions We come up with new solutions
Broker He makes the stakeholders happy The actors make each other happy
Facilitator He inspires the team We inspire and build the team
Mentor He teaches me the craft I learn from other specialists
Coordinator He decides what to do when I decide in coorperation the team what to do when
Monitor He sees to it that I do the right things The team ensures that I do what is needed

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!

A new cash CAT?

September 23, 2011 / / 7 Comments

Two weeks ago I had a discussion with an account manager of a testing consulting company about CAT: Certified Agile Tester. His company sells this training and he told me he sees a certification training as a driving license: once you obtain it, you still need to learn how to drive like an expert. I do not believe that ISTQB or TMap certification makes anybody a better tester. And this agile tester certification is even worse… How can you give somebody a certificate for a mindset?

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!

Preparing a talk: so you think you can test?

August 27, 2011 / / 17 Comments

I am asked to do a talk at a test consultancy company. To prepare for this talk I want to share my thoughts with you. Hope you can challenge me to rethink or sharpen them.

As a test consultant I have worked for numerous companies and have met or worked with hundreds of testers. A lot of them claim that they are great testers. But are they? I think a lot of testers maybe aren’t that great…

Being a great tester takes a lot of practice. I like this “Becoming a Software Testing Expert” talk by James Bach a lot. The video by the way can be found here. And I see a lot of testers do not study their craft or read books about it. They do not learn or experiment at all. As a matter of fact they claim that they improved by doing their job: after years of doing my job I have a lot of experience! But as James says in his slides: “Don’t confuse experience with expertise”

In this post I like to address three topics what I have experienced that could be helpful become a better tester:
1) Adapt to the context
2) Collaborate
3) Learn & practice!

Everthing is context, context is everything!
Testers in the Netherlands are often trained with the V-Model and methodologies like TMap, TestFrame or ISTQB. Although I do not agree with everything they claim, there is “nothing” wrong with these test methodologies. Not if you don’t take them literally and see them as a practice. We need to become more “agile” in using these methodologies. Since the value of any practice depends on its context. Testers should to be able to adapt to changing situations. Doing so they are able to provide the most value to their stakeholders. Testers should focus on their skills instead of focus on procedures and processes.

Collaborate
Being passionate is contagious! By being passionate you will get your team test infected. Showing your testing skills can help the others in your team. My experience is that even developers will participate in testing if you can show them your skills. They love to build handy test tools and automated scripts which can help the team being more effective in testing! Start using your testing skills and teach others to do better testing. Testers should teach their team members how to test better! I like the way Gojko Adzic descibes it in his presentation “Sleeping with the enemy“: our role in teams will change: from testing everything ourselves, we will also be advisers in our projects. Ensuring that the team does the testing right. Our value is getting the testing right. Of course we’ll still be testing ourselves, the critical, complex testing will always be our job. In exploratory testing or paired testing we can demonstrate our testing skills. Good software testing is a challenging intellectual process.

Times are changing and so is the way we do projects. Collaboration is the key in becoming more effective and efficient in testing. Software development is a team sport: people, working together, are the most important part of any project’s context. So why do we introduce lots of test levels and quality gates? Separate the different disciplines in our projects? Create bulky test plans individually which no one will read?

Learn & Practice
Have you ever seen TV series like Benelux’ next top model or X-factor? People battle to become the best model or singer and win the show. Of course testing is not about beating your colleagues in a match. But this might be the only difference… In the TV shows the models and singers need to show their quality in different areas, every week they are trained in boot camps or by very experienced gurus. These coaches come from different disciplines. To be the best you need to learn all aspects of your job. How do we testers learn?

We need to practice continuous learning. Become skilled in various ways of testing. Practical tips to become a top tester:

  • Take testing classes: Rapid Software Testing or BBST are good examples.
  • Learn and gather ideas from reading books, online magazines and blogs
  • Learn by visiting conferences, participate in online conferences or watch the video’s that have been put online
  • Practice in Testing Dojo’s, weekend testing, software testing clubs, or organize it yourself in your organisation or team.
  • Meet with enthusiastic colleagues and discuss your experiences: peer mentoring, intervison, peer conferences, SIG’s, workgroups, etc.
  • Collaborate, learn from other disciplines: writing/reviewing requirements, coding scripts, using tools, etc.
  • Try different (open source) tools
  • Start writing and presenting about your work and thoughts, get feedback and discuss your thought to improve and discover new ideas.
  • Coach and get coached! Even professional tennis players or soccer players have coaches and trainer to get better and stay on the top.
  • Evaluate often! Make sure you get feedback from your colleagues but also keep evaluating your own work: your processes and your products. Always keep asking yourself the question: how can I do better next time??

Markus Gärtner has written a great article about this stuff called Alternative Paths for Self Education in Software Testing in the July issue of Testing Planet.

Update: slides of the talk can be found in the download section or here.

« Older posts Newer posts »

My website

http://www.huibschoots.nl

© 2024 Magnifiant: exploring software testing

Theme by Anders Noren — Up ↑