To help the Dutch community evolve to learn, think and do more skilled testing I want to advocate interesting stuff to read to the community. But what should a tester read? Earlier I published a list of popular books for testers. In my search for good books to read, some people replied that they only read blogs and other on-line content. On this blog I recommend great articles and on-line stuff in my great resources list. For testers blogs you can check my colleagues list.
But what do other testers recommend? My curiosity kicked in again and I sent out another email to my tester friends around the world to ask for their favourite blogs.
This is the “top 19” of most mentioned blogs. In the list are all blogs that got more that 2 votes. I am thrilled to be in this list at all. But it must have been the “availability heuristic” that got me on the 3rd place! Thanks guys 😀
I love to read and I own many books on testing, software, management and other stuff that relates to my work.
But what should a tester read? On this blog I recommend several books in my great resources list. And what do other testers recommend? My curiosity kicked in and I sent out an email to my tester friends around the world.
Every year the Dutch association for software testers TestNet organizes two one-day conferences. This year TestNet has chosen context-driven testing as the theme for their autumn event in October (call for papers is here). To help the Dutch community evolve to learn, think and do more skilled testing I want to advocate some interesting books to the community.Here I need your help! Please send me your personal top 10 of best books testers should read. It can be any book, it doesn’t have to be a book on testing… I will collect the submissions and create a list of most popular books amongst testing professionals.Please send me your list of favourite books! Hope to hear from you soon.
One of the testers replied that he could not send a list. “What you should be reading depends on what you are ready to learn about next, and that varies from person to person”. And I agree with this statement. This list of books can be useful when used as a list to inspire. Another tester replied: “the reading that has been most helpful in my career has been centered around blogs and twitter far more than it has been around books”. For testers blogs you can check my colleagues list. Maybe creating a list of most popular testers blog will be my next project 😀
Anyway, this is the top 10 of most mentioned books:
Lessons Learned in Software Testing – Cem Kaner, James Bach, Brett Petticord (31 votes)
Perfect Software and other Illusions about Software Testing – Gerald M. Weinberg (19 votes)
Agile Testing – Lisa Crispin and Janet Gregory (14 votes)
Thinking fast and slow – Daniel Kahneman (12 votes)
How to Break Software – James A. Whittaker (11 votes)
Tacit and Explicit Knowledge – Harry Collins (10 votes)
Explore It! – Elisabeth Hendrickson (9 votes)
Secrets of a Buccaneer-Scholar – James Bach (9 votes)
A Practitioner’s Guide to Software Test Design – Lee Copeland (9 votes)
An introduction to general systems thinking – Gerald M Weinberg (6 votes)
Peopleware: Productive Projects and Teams – Timothy Lister & Tom DeMarco (6 votes)
Quality Software Management Vol. 1 Systems Thinking – Gerald M. Weinberg (6 votes)
Secrets of Consulting – Gerald M. Weinberg (6 votes)
Testing Computer Software – Cem Kaner, Jack Falk, Hung Q. Nguyen (6 votes)
The Black Swan – Nassim Nicholas Taleb (6 votes)
180 different books where mentioned by 43 participants. 15 (!) different books by Jerry Weinberg where mentioned. The full list of books can be found here. An overview of all participants and their personal lists can be found here.
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.
In the last edition of Testkrant (in Dutch) I published an article on context-driven testing called “I am a context-driven tester! Huh? Really? So?“. In this article I (try to) explain what context-driven testing means and why I think I am context-driven. Jan Jaap Cannegieter reacted via email asking an interesting question which has crossed my mind several times already. The following quote is from his email but translated and slightly changed:
“Isn’t everyone context-driven to some extend? And I mean that on a sliding scale. People who always use the same method and implements this method slightly different every time are maybe 2% driven context (I have combined context-driven and context-aware, sorry for simplification). The Jedi tester using dozens of test methods that he blends to a unique test approach to apply in a specific situation is perhaps 98% context-driven.”
Jon Bach presented a “freedom” scale in his presentation Telling Your Exploratory Story at Agile 2010 Conference. Jon contrasts scripted testing and exploratory testing by plotting them in the freedom scale above.
Could such a scale also be applied to being a context-driven tester? Contrasting “Context-oblivious” with “Context-driven”? Maybe putting “context-aware” somewhere in the middle of the scale? Context-driven, context-oblivious and context-aware are explained on the website www.context-driven-testing.com.
I am not totally happy with this model yet, but can’t put my finger on it how to improve it. There is more to being context-driven as only applying methods and techniques. I also ask myself what is the added value of such a scale? I think it helps testers understand the differences between context-oblivious, context-aware and context-driven better. It might also make it easier to bridge the gap between the extremes or even advocate that everybody is or can be context-driven in some extend?
Did you have a chance to see the webinar “Thinking Visually in Software Testing” by Alan Richardson at the EuroStar Virtual Conference May 16th last? If not I suggest you do that now before you read this column. Also very interesting is the great blog post Fiona Charles has written about this topic with the beautiful title “Breaking the Tyranny of Form”.
Alan explains that simple techniques and tools you can make your thinking visual. It makes your thoughts visible what benefits the feedback to yourself, but also the communication of your thoughts to others. In the webinar Alan shows some simple drawings that made his thought process transparent. The webinar also shows some simple tools that can help you.
Fiona is annoyed by documents where the form is more important than the content. These documents are driving and constraining our work. She explains that templates limit thinking and creativity. In her article she shows some examples of visual representations that helped her in her work.
Text is boring and not very creative. It lets your brain run at half power, only the left part of the brain is put to work. Using images will also put the right part of your brain to work. People remember images easier. In addition, images often impress us more. A text normally needs many pages to describe what a single picture can say. The saying “a picture is worth a thousand words” is really true! A single image can transfer a complex idea fast and easy. Visualization allows us to quickly absorb large amounts of information.
Collaboration through effective communication
Visualization makes your work easier! Through visualization, communication is richer and that makes our work easier. Understanding each other is often the first step to successful collaboration. To clarify the added value of different forms of communication, I often show this picture:
This picture makes clear that communication is enriched with visualization. For who ever bought a new house, you know: graphics were the deciding factor. The plans and artist impressions gave, before only one stone was built, an impression of how the future house was going to look like. The visualization of the house to be built, informed your decision. Could text do the same?
But why do testers still produce so much text in their work? The creation of “traditional” test plans, test reports and test cases is very time consuming. And I think they do not add a lot of value. Have you ever wondered how many people actually read your test plans arising from the use of a 21-page template? And if somebody would have read it, how much useful information is in there for the reader? And what will he ultimately remember?
Nowadays mind maps are very popular. I use them almost daily for various purposes: insight into situations, problem solving, summarizing, making records, creating plans, develop ideas or report status. I even created a mind map of my resume. The possibilities of mind maps are endless. The theory behind mind maps is fairly simple and making them stimulates the creative side of our brains through visualization.
On the back of a napkin
The drawing of (simple) images can be of great value. In my search for literature on creativity and visualization a few weeks ago, I walked into a book by Dan Roam called “The back of a napkin, Solving Problems and Selling Ideas with Pictures“. In this book Dan Roam describes how a simple drawing can help. I’m not a great artist and the simple drawings in this book appealed to me immediately. Ultimately it just requires drawing of simple shapes: lines, rectangles, smiles and stick figures.
His philosophy is that every problem can be solved with a simple drawing. In his book he introduces four steps of visual thinking, five questions that help focus and six ways of seeing. Try it and see if it helps you.
I hope these examples inspired you to try to use more visualization. Try writing a test plan with a mind map or visualize your test strategy and scope with images. Why not put your thoughts on paper using a few sketches? Don’t let the thought that you can’t draw stop you. The creative process is much more important than the final result. Furthermore, you will see that it isn’t really that bad!
Awesomeexamples Finally, I want to share some great examples of visualizations, two beautiful animations. The first is Steven Johnson – Where Good Ideas Come From:
And the second is Dan Pink – Drive. The surprising truth about what motivates us:
This Dutch example by Avans Hogeschool also shows how powerful visualization can be:
Gojko Adzic uses simple but very powerful pictures in his presentations that help me understand and remember his message easy.
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:
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