Category: Learning (Page 3 of 3)

Experiential learning: learning from experience

January 26, 2013 / / 3 Comments

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

Unfortunately last year AYE (Amplifying Your Effectiveness) was organized for the last time. AYE was a conference in Albuquerque in the U.S. hosted by Jerry Weinberg, Esther Derby, Johanna Rothman and Don Gray. I have never been there and very much wanted to go. But alas: too late!

What appeals to me most in this conference is the focus on experiential learning. They want no powerpoints presentations with barely any room for questions. They want participants who will participate, ask questions, share their experiences, be part of experiential exercises and contribute to the session designs and content.

Fiona Charles does a lot of workshops in this way. Last year I attended Let’s Test conference near Stockholm where I experienced a workshop “Inspiring Test Leadership”. Not been in or done, but experienced! Let me give you a brief report of the workshop. We were with a group of 25-30 people, we sat in a circle and we introduced ourselves briefly. Everyone gave their motivation for being in this workshop. Upon hearing the wide variety of reasons for choosing this particular session, I asked myself just how Fiona could give us all what we were looking for…

During the day, we did a number of interesting exercises in groups. All exercises were discussed and debriefed extensively. During those debriefs Fiona keeps asking the questions. These questions helped us to tell our story about what happened, how we experienced it and why we did what we did. Others are encouraged to respond with their own stories. Meanwhile Fiona facilitates the discussion with questions like “do you know why that happened?” or “how would you use it?”.

In one of the exercises we were divided into two groups. Each group was given 45 minutes time to create a leadership challenge for the other group. After that both groups got 45 minutes to solve the problem. A very interesting exercise it was! You experience the group process while generating ideas under time pressure. After 45 minutes you have to deliver something to work with enabling the other group to get started. It is basically an exercise in an exercise! You learn to think about leadership and it’s challenges. But the process itself is also very interesting and instructive. Leaders step forward, group dynamics occur and all sort of things happen. You do not learn about aspects of leadership, you are the object of the exercise! Did everyone get what they were looking for? No idea, I think so. That’s the beauty of this teaching method: all participants take away what is in there for them. Each participant is responsible for their own learning.

After EuroSTAR, on the way to the hotel, I discussed experiential learning with Fiona. EuroSTAR was great and there is more and more room for workshops and hands-on stuff. While walking Fiona told me that she has an idea to organize a conference with only experiential workshops inspired by the AYE conferences. I was excited immediately. Currently Fiona and I are brainstorming about the possibilities for such a conference, specifically aimed at testers.

What do you think? Would you participate? Who has experience with experiential learning? And what are your experiences? What would you want to learn in such workshops? I’m curious about your reactions.

Basic training for software testers must change

June 18, 2012 / / 21 Comments

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

On this blog I recently wrote about my meeting with James Bach with the provocative title: “What they teach us in TMap Class and why it is wrong“. Mid July I go to San Jose for the CAST conference. During the weekend preceding I participate in Test Coach Camp. The title of the post is the title of a proposal that I submitted to discuss at Test Coach Camp.

In the past I have been a trainer for quite a few ISTQB and TMAP courses. The groups attending the training were often a mix of inexperienced and experienced testers. The courses cover topics like: the reason for testing, what is testing, the (fundamental) processes, the products that testers create, test levels, test techniques, etc. In these three-day courses all exercises are done on paper. Throughout the whole training not once actual software is tested!? I wonder if courses for developers exist where no single line of code is written.

In San Jose at Test Coach Camp I want to discuss the approach of these courses with my peers. How can we improve them? I feel these courses are not designed to prepare testers to test well. Let alone to encourage testers to become excellent in their craft.

During my dinner with James, I asked him what he would do if he would train novices to become good testers. He replied that he would let them test some software from the start. He would certainly not start with lectures on processes, test definitions and vocabulary. During a session the student will (unknowingly) use several techniques that will be named and can be further explained when stumbled upon. A beautiful exploratory approach I would like to try myself: learning by doing! But there are many more opportunities to improve testing courses. People learn by making mistakes, by trying new things. Testing is much more about skills than about knowledge. Imagine a carpenter doing a basic training. His training will mainly consist of exercises! My neighbour is doing a course to become furniture maker. She is learning the craft by many hours of practice creating work pieces. Practice is the biggest part of her training!

One of the comments on my blog opposed to the suggestion by James Bach. Peter says: “I have been both a tester and trainer in ISTQB and TMap. Yes we can make testing fun but without a method that testing has no structure and more importantly has no measurable completion. How will those new people on “more practical” course know when they have finished? What tests did they do? What did they forget? What defect types did they target? Which ones did they not look for? What is the risk to the system? My view after 40 years as a developer and tester is that this idea might be fun but is not just WRONG but so dangerously wrong that I am sad that no one else has seen it.”

What do you think?

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.

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?

Newer posts »

My website

http://www.huibschoots.nl

© 2024 Magnifiant: exploring software testing

Theme by Anders Noren — Up ↑