Refusing to do bad work…

I talked at TestBash about context-driven testing in agile. I my talk I said that I refuse to do bad work. Adam Knight wrote a great blog post “Knuckling Down” about this: “One of the messages that came up in more than one of the talks during the day, most strongly in Huib Schoots talk on Context Driven in Agile, was the need to stick to the principle of refusing to do bad work. The consequential suggestion was that a tester should leave any position where you are asked to compromise this principle.

Adam also writes: “What was missing for me in the sentiments presented at TestBash was any suggestion that testers should attempt to tackle the challenges faced on a poor or misguided project before leaving. In the examples I noted from the day there was no suggestion of any effort to resolve the situation, or alter the approach being taken. There was no implication of leaving only ‘if all else fails’. I’d like to see an attitude more around attempting to tackle a bad situation head on rather than looking at moving on as the only option. Of course we should consider moving if a situation in untenable, but I’d like to think that this decision be made only after knuckling down and putting your best effort in to make the best of a bad lot.

Interesting because I think I said exactly that: “if anything else fails, leave!” But maybe I only thought that and forgot to speak it out loud, I am not sure. Let’s wait for the video that will give us the answer. But in the meanwhile: of course Adam is right and I am happy that he wrote his blog post. Because if I was too firm or too distinct, he gave me a chance to explain. Because looking back, I have done many projects where, if I hadn’t tried to change stuff, I would have left many of them in the first couple of days. There is a lot of bad testing around. So what did I try to say?

Ethics again.

This topic touches very closely to ethics in your work! Refusing to do bad work is an ethical statement. Ethics are very important for me and I hope more testers will recognize that only being ethical will change our craft. Ethics help us decide what is right and what is wrong. Have a look at the ethics James Bach summed up in this blog post “Thoughts Toward The Ethics of Testing“. Nathalie pointed to an article she wrote on ethics in a reply to my last post.

Ethics and integrity go hand in hand. Ethics are the external “rules and laws” and integrity is your internal system of principles that guides your behaviour. Integrity is a choice rather than an obligation and will help you do what is right even if no one is watching.

I refuse to do bad work!

Bad work is any work that is deliberately bad. I think along the lines of restrictions in a context, demands placed on them that they don’t know how to handle. Or even worse: intentionally doing stuff you know can be done better, but it is faster, easier or because others ask you to do it like that. Of course there are novices in the field and they do work that can be done better. I do not call that bad work since they are still learning. Still there is a limit to that as well. If you have been tester for several years and you still do not know how to do more than 3 test techniques without having to look them up, I will call that bad work as well. I expect continuing professional development from everybody in the field. Simply because working in IT (but in any profession) we need to develop ourselves to become better.

Lying is always bad work. And I have seen many people lie in their work. Lying to managers to get off the hook, making messages sound just a little better by leaving out essential stuff. Also telling people what they what to hear to make them happy is bad work. What do you do when your project manager asks you to change your test report because it will harm his reputation? Or what do you tell the hiring manager in a job interview when he asks you if you are willing to learn? Many people tell that they are very willing to learn, but are they really?

Bad work is claiming things you can’t accomplish: like assuring quality or testing everything. It is also bad work when you do not admit your mistakes and hide them from your colleagues. Bad work is accepting an assignment when you know you do not have the right skills or the right knowledge. In secondment assignments this is an issue sometimes. I have taken on a project once where the customer wanted something I couldn’t deliver but because my boss wanted me on the position I accepted. That was wrong and the assignment didn’t work out. I felt very bad about it: not because I failed, but because I knew upfront I would fail! I won’t do that again, ever.

So how do I handle this?

I push back! Of course I do not run away from a project when I see or smell bad work. I do try to tackle the challenges I am faced with. I use three important ways trying to change the situation: my courage, asking questions and my ethics. Some examples: when a managers start telling me what I should do and explicitly tell me how I should do that, I often ask how much testing experience the manager has. When given the answer I friendly tell him that I am very willing to help him achieve his goals, but that I think I am the expert and I will decide on how I do my work. Surely there is more to it and I need to be able to explain why I want it to be done differently.

I also ask a lot of questions that start with “why”. Why do you want me to write test cases? What problem will that solve? I found out that often people ask for things like test cases or metrics because it is “common practice” or folklore not because it will serve a certain purpose. Also when I know the reasons behind the requests, it makes it easier to discuss them and to push back. A great example of this is the last blog post “Variable Testers” by James Bach.

Adam talks about changing peoples minds: “One of the most difficult skills I’ve found to learn as a tester is the ability to justify your approach and your reasons for taking it, and being able to argue your case to someone else who has a misguided perspective on what testing does or should involve. Having these discussions, and changing peoples minds, is a big part of what good testing is.

I fully agree. In my last on blog post “heuristics for recognizing professional testers” my first heuristic was: “They have a paradigm of what testing is and they can explain their approach in any given situation. Professional testers can explain what testing is, what value they add and how they would test in a specific situation.” To become better as testers and to advance our craft, we should train the skills Adam mentions: justify approach and being able to argue our case.

It will make you better and happier!

Jerry Weinberg listed his set of principles in a blog post “A Code of Work Rules for Consultants“. In this blog post he says: “Over the years, I’ve found that people who ask these questions and set those conditions don’t wind up in jobs that make them miserable. Sometimes, when they ask them honestly they leave their present position for something else that makes them happier, even at a lower fee scale. Sometimes, a client manager is outraged at one of these conditions, which is a sure indication of trouble later, if not sooner.

It will make you a happier person when you know what your limits are and you are able to clearly remind people you work with. It will prevent you from getting into situations that make you miserable. “That’s the way things are” doesn’t exist in my professional vocabulary. There is always something you can do about it. And if the situation you end up in, after you tried the best you can, isn’t satisfying to you: leave! Believe me, it will make you feel good. I have got the t-shirt! And… being clear about your values also will make you better in your work. Maybe not directly, but indirectly it will.

Daniel Pink speaks about the self-determination theory in his book “Drive“. The three keywords in his book are: Autonomy, Mastery and purpose: “human beings have an innate drive to be autonomous, self-determined and connected to one another, and that when that drive is liberated, people achieve more and live richer lives” (source: http://checkside.wordpress.com)

But but but….

Of course I know there is the mortgage and the family to support. Maybe it is easy for me to refuse bad work. Maybe I am lucky to be in the position I am. But think again… Are you really sure you can’t change anything? And if your ethics are violated every day do you resign yourself? Your ethics will act as heuristics signalling you that there is a problem and you need to do something. I didn’t say you have to leave immediately and if you are more patient than I am, maybe you do not have to leave at all… But remember: for people who are good in what they do, who are confident in what they will and will not do and speak up for themselves, there will always be a place to work.

Now you!

Have you even thought about integrity? What are your guiding principles, values or ethics? What would you call bad work? And what will you do next time when somebody asks you something that conflicts with your ethics?

 


 

While reading stuff online about (refusing) bad work I ran into this blog post by Cal Newport about being bad at work: “Knowledge Workers are Bad at Working (and Here’s What to Do About It…)“Interesting enough Cal Newport wrote a book called “So Good They Can’t Ignore You: Why Skills Trump Passion in the Quest for Work You Love” about the passion hypothesis in which he questions the validity of the hypothesis that occupational happiness has to match per-existing passion. In several recent talks and blog posts I did I talk about passion. Also in the talk discussed in this blog post I claim that passion is very important and I show a fragment of the Stanford 2005 commencement speech by Steve Jobs. Exactly the passage I showed in my talk, Cal uses in the first chapter of his book. “You’ve got to find what you love. And that is as true for your work as it is for your lovers. Your work is going to fill a large part of your life, and the only way to be truly satisfied is to do what you believe is great work. And the only way to do great work is to love what you do. If you haven’t found it yet, keep looking. Don’t settle. As with all matters of the heart, you’ll know when you find it. And, like any great relationship, it just gets better and better as the years roll on. So keep looking until you find it. Don’t settle.” Anyway. Interesting stuff to be researched. I bought the book and started reading it. To be continued…

 

 

 

Heuristics for recognizing professional testers

Via Twitter Helena Jeret-Mäe asked this question: “What are your criteria for professionalism for testers in CDT community?”. Later via Email she updated her question to: “So the updated version of my question is what are the heuristics for recognizing professional testers in your opinion? I changed “criteria” to heuristics… it’s less categorical. And I’ll leave the term “professionalism” up to you as well – I don’t know exactly what you meant by it.”

In my talk “How to become a great tester” at ContextCopenhagen last January I talked about testers and their skills. I said that most testers don’t know what they’re doing and can’t explain effectively what value they add. I have seen many testers who use the same approach over and over again. If I ask them to name test techniques, they can only name a few. If I ask them to explain techniques to me or show how they work, I get no answers. I find that shocking and I cannot understand why testers who call themselves professionals know so little about their craft and do not study their craft.

That is why I make a distinction between professional testers (of which I think there are only few) and testers by profession. Of course I know and understand that there will always be people who have a 9 to 5 mentality, do not read books or blogs and only want to do courses when the boss pays for them. I accept that reality, but that d oesn’t mean I want to work with them!

Let me now answer the questions asked, have done enough ranting for now…

Professionalism is what it means to be a professional and what is expected of them. Professional testing is complex and diverse and has several dimensions: knowledge, skills, experience, attitude, ethics and values. I wrote a blog post “What makes a good tester?” in 2011 on this topic and I have a broader view on this topic now although everything I wrote then still counts. In my earlier blog posts I didn’t mention values and ethics and I now think they are extremely important. James Bach writes about them in his blog post “Thoughts Toward The Ethics of Testing”. A great practical example of ethics and values is Rapid Testing. Look at the “the premises of Rapid Testing” and “the themes of Rapid Testing” both can be found in the slides of Rapid Software Testing.

It is hard to recognize professional testers. Every tester is unique and brings different characteristics to the table. Every project is different too and to be successful in finding the right professional tester for your project different characteristics may be important. There are many characteristics to be considered so to be able to recognize professional testers heuristics can be used. Heuristics are fallible methods for solving a problem or making a decision, shortcuts to reduce complex problem or rules of thumb. They are used to determine good enough feasible solutions for difficult problems within reasonable time. On Wikipedia I found this definition: “Heuristics are experience-based techniques for problem solving, learning, and discovery that give a solution that is not guaranteed to be optimal. Where the exhaustive search is impractical, heuristic methods are used to speed up the process of finding a satisfactory solution via mental shortcuts to ease the cognitive load of making a decision.

My heuristics for recognizing professional testers:

1) They have a paradigm of what testing is and they can explain their approach in any given situation.
Professional testers can explain what testing is, what value they add and how they would test in a specific situation.

2) They really love what they do and are passionate about their craft.
Testing is difficult and to be successful, testers needs to be persistent in learning and in their work. Passion helps them to be become real professionals. Watch this video where Steve Jobs talks about passion

3) They consider context first and continuously.
To be effective testers need to choose testing objectives, techniques and by looking first to the details of the specific situation. They recognize that there are no best practices but only good practices in a given context.

4) They consider testing as a human activity to solve a complex and difficult problem that requires a lot of skill.
Testers recognize testing is not a technical profession. Testing has many aspects of social science since software is built for humans by humans.

5) They know that software development and testing is a team sport.
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. A great tester knows how to work with developers and other stakeholders in any situation.

6) They know that things can be different.
Professional testers use heuristics, practice critical thinking and are empirical. They know that time to test is limited, systems are becoming increasingly complex and thinking of everything is hard. Therefore heuristics are a very helpful “tool” for testers. They also know that biases and logical fallacies can fool them. They practice critical thinking to deal confidently and thoughtfully with difficult and complex situations. Testers have to accept and deal with ambiguity, situational specific results and partial answers.

7) They ask questions before doing anything.
Testing depends on many things and what is the context of the stuff I am looking at? What is the information we need to find? What is the testing mission? Giving a tester an exercise in an interview can easily test this. If he or she starts working on it or gives you an answer without asking questions, this tells you something.

8) They use diversified approaches.
There is no approach or technique that will find all kinds of bugs or fulfil all test goals. Different bugs are found using different techniques. In order to be able to do this, testers need to know many techniques and approaches. This demands training, practice and some more practice.

9) They know that estimation is more like negotiation.
Have a look at some blog post by Michael Bolton:

10) They use test cases and test documentation wisely.
The context determines what test documentation you should make and what kind of documentation is useful. Quite recently a great (and long) article by James Bach and Aaron Hodder was published in Testing Trapeze “Test cases are not testing: Toward a culture of test performance”. Also Fiona Charles has written some interesting stuff about test documentation in her article the Breaking the Tyranny of Form.

11) They continuously study their craft seriously, practice a lot and practice “deliberate practice”.
Deliberate practice is a structured activity with the goal of improving performance. According to K. Anders Ericsson, there are four essential components of deliberate practice. It must be intentional, aimed at improving performance, designed for your current skill level, combined with immediate feedback and repetitious.

12) They refuse to do bad work, never fake and have the courage to tell their clients and the people they work about their ethics and values.
Testing is often underestimated and many believe “everybody can test”. I have experienced project managers who tell me how to do my work. Professional testers know how to push back and are able to explain why they do what they do.

13) They are curious and like to learn new things.
Testers find pleasure in finding things out. A good read is the curious behaviour by Guy Mason: “a curious mind is one that could be described as an active, engaged and inquisitive mind. Such a mind frequently seeks out new information, enjoys discovering what there is to discover and enjoys the process that comes along with this goal.“

14) They could have any of the important interpersonal skills mentioned in the list below. As stated earlier it depends on the context which skills are most important.

  • Writing skills (like reporting, note taking and concise messages)
  • Communication skills (many different like listening, story telling, presentation, saying no, verbal reporting, arguing and negotiating)
  • Social and emotional skills (like empathy, inspiring, networking, conflict management and consulting)
  • Problem solving skills
  • Decision making skills
  • Coaching and teaching skills
  • Being proactive and assertive

15) They have excellent testing skills:

  • Thinking skills (critical, lateral, creative, systems thinking)
  • Analytical skills
  • Modelling
  • Risk analysis
  • Planning and estimation
  • Applying many test techniques
  • Exploring
  • Designing experiments
  • Observation

Have a look at the Exploratory Testing Dynamics in the RST appendices where several lists of skills are listed.

16) They have sufficient technical skills.
There are many technical skills a tester needs like being able to use tooling, coding skills or willingness to learn what they need to know about the technical structure of the application they are testing. Test automation skills like scripting and SQL skills to work with databases, being able to configure and install software, knowledge and skills to work with the platform the system under test is on (Windows, Linux, Mobile, etc.).

This list is probably not complete. It is very well possible that I have made some mistakes. So please let me know if you have any contributions or improvements. Also: being a professional doesn’t mean you are an expert on all mentioned skills. Have a look at the Dreyfus model to learn more about expert level. A real professional knows what he or she can do and when to ask for help. They do not fear to learn and they are not afraid to make mistakes. I guess that would be the 17th heuristic in the list.

BTW: I googled “code of ethics software testing” and found the ISTQB Code of Ethics for test professionals. I wonder if people who pass the exam know about these AND more important practice them… What about you?


More information

Some more posts that discuss great testers:

And last but not least: have a look at the Testers syllabus by James Bach. An awesome document which lists many important skills and areas of knowledge. It inspired me read about and study different areas.

Why I am context-driven!

Wanna know why I am context-driven? Published on the DEWT blog: Why I am context-driven!

“Because testing (and any engineering activity) is a solution to a very difficult problem, it must be tailored to the context of the project, and therefore testing is a human activity that requires a great deal of skill to do well. That’s why we must study it seriously. We must practice our craft. Context-driven testers strive to become the Jedi knights of testing”. James Bach

So you think you can test ….

Recently I saw this tweet: “a lot of testers don’t consider alternatives because they don’t know them”. It was a reaction in a discussion about a Dutch article with the title „The days of the ‘Dutch school of testing’ are over”. Jan Jaap claims that Dutch testers suffer from “Law of the handicap of a head start“. Really? I don’t think it is the handicap of a head start. Did we (Dutch testers) ever had a head start? I think it is something that is called “The Dunning-Kruger effect“.

Dunning KrugerThe Dunning-Kruger effect, named after David Dunning and Justin Kruger of Cornell University, occurs when incompetent people not only perform a task poorly or incompetently, but lack the competence to realize their own incompetence at a task and thus consider themselves much more competent than everyone else. Put more crudely, they’re too stupid to realize they’re stupid. The inverse also applies: competent people tend to underestimate their ability compared to others. (Source: Rational Wiki)

In the words of Dunning and Kruger: this overestimation occurs, in part, because people who are unskilled in these domains suffer a dual burden: Not only do these people reach erroneous conclusions and make unfortunate choices, but their incompetence robs them of the metacognitive ability to realize it.

I think many testers don’t realize that they actually know very little about testing at all. And that is why they don’t do anything to get better. They are also not encouraged much by their colleagues. Testing is often underestimated. I guess everyone has examples of managers who do not value testing as much as we would want them to. Testing is often devalued as “pushing buttons” and “everybody can test” is believed by many. I have seen companies who use testing as education, a first step in an IT career…

But there is more… I have worked as a selling and hiring manager and I experienced that there is a lack of competence in spotting talented testers. If you have the right certificates, people believe that you are a good tester. Because they simply do not know how to spot an excellent tester. In my recent job search nobody asked me to SHOW them my testing skills. We only talked about it.

 

Context-driven (presentation) heuristics

James BachOctober 23 DEWT and James Bach met in Dordrecht to talk about testing. The subject was “What is context-driven testing?” and more specific “How do you recognize a context-driven presentation?”.

They came together to prepare for the TestNet Autumn Event which was fully dedicated to context-driven testing and had the theme: “Exploring context-driven testing – a new hype or here to stay?”.

DEWT decided earlier this year to write an article about the event to reflect on context-driven testing in the Netherlands. What does the TestNet community have to say about context-driven testing? What can we learn from the event? What can we do to help the community learn? How context-driven is the Dutch Testing community? While discussing this the DEWTs found it hard to find heuristics to “measure” (maybe “recognize” is a better word here) the presentations at the TestNet event.

DEWTs

What is context-driven?

Often context-driven testing is “only” seen as an approach, but it can be more. Actually there are 3 different things that are called context-driven. Testers can be part of one, without necessarily being part of the other.

  1. Paradigm (world view)
  2. Community
  3. Approach

For example: you can use an context-driven approach without being part of the context-driven community. To be in a paradigm you need to have a world view of testing.

Testing People evaluating a product by learning about it through experimentation
driven by is a matter organized and motivated by a systematic consideration of
context all the factors that significantly influence the problems and solutions that lie within the scope of their mission
  • Attitude: context-driven testing allows to change the approach. An example is “Huib’s Rapid Software Testing”. This Huib’s way of doing testing, inspired by Rapid Software Testing, but he changed his approach to his context. Changing anything he sees fit. Often factory school testers do not want to change their approach and apply their approach the same in every situation.
  • Principles: context-driven testing is NOT (only) the seven basic principles, but there is much more. Look what lies behind them, learn about the implicit principles. See slide 9 of this presentation by James Bach.
  • Mentality: context-driven testing is about skills, humanity, science, critical thinking, problem solving, non-linearity, investigation, learning, etc.
  • Metrics: you can use only those metrics if you understand them and if they solve a certain problem.
  • Critical thinking: do you know how? How do you know that you know? How do you get better?

Science is the Belief in the Ignorance of Experts” — Richard Feynman

Presentations

Good stuff to look for:

  • Heuristics over commandments
  • Learning curves
  • Compare alternative methods, trying other methods
  • To be truly context-driven you have studies and tried the practices you say you do not like
  • Discussion of causes and effects assuming open systems. Reject the believe that a project a well defined game that is predictable. Also reject the assumption that a process is unhackable
  • Acknowledgement there are people with different opinions, not speaking from authority
  • Social science
  • Humanism
  • Practitioner responsibility
  • Craftsmanship
  • Refuse to do bad work
  • Problem solving
  • Skill based work

Be aware of people:

  • talking about ‘success’ and ‘failure’ without explaining why and describing the context
  • talking about ‘structure’ and ‘chaos’ (often meaning: I am out of control)
  • showing no evidence (or using sentences like: “research shows that…”)
  • relying on folklore
  • using numbers without context
  • who are ignorant of social science
  • uncritically apply the manufacture metaphor (IT is like a factory)
  • apply premature automation
  • assuming other people read and follow what is written
  • contempt humanism
  • trying stuff once and over generalize that to the whole company/world
  • who fear variation
  • over simplify (approach the world as if it was linear)
  • misuse of statical analysis
  • who use averages without variance
  • who do narrow research
  • say or do stuff because their clients want it
  • demonize tacit knowledge and idealize explicit knowledge

This is the summary I have made of what we discussed. You could consider this as a heuristic for context-driven presentations. I used this heuristic in my presentation “What is context-driven testing?” at the TestNet event.

Heuristics Success / Failure
Learning Chaos / Structure
Compare alternative methods Lack of evidence / Narrow research
Cause and effect Folklore
Open systems Numbers without context
Social science Ignorance of social science
Humanist view Contempt of humanism
Craftsmanship IT & testing is like manufacturing
Explain context No context mentioned
Worldview of testing Generalizing after one try
Different opinions Use of averages without variance
Allows to change approach Linearity

Popular blogs for testers

blogsTo 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 :-D

Rank # votes Name URL
1 26 Michael Bolton http://www.developsense.com/blog
2 23 James Bach http://www.satisfice.com/blog
3 12 Huib Schoots http://www.huibschoots.nl/wordpress/
4 11 Cem Kaner http://kaner.com/
5 10 Michael Larsen http://www.mkltesthead.com/
6 9 Markus Gartner http://www.shino.de/blog/
  9 Elisabeth Hendrickson http://testobsessed.com/
8 8 Alan Page http://angryweasel.com/blog/
9 7 Andy Glover http://cartoontester.blogspot.com/
  7 The Test Eye http://thetesteye.com/blog/
  7 Zeger van Hese http://testsidestory.com/
12 6 Pradeep Soundararajan http://testertested.blogspot.com/
  6 Matt Heusser http://xndev.com/creative-chaos/
14 5 Iain McCowatt http://exploringuncertainty.com/blog/
15 4 Jurgen Appelo http://www.noop.nl/
  4 Keith Klain http://qualityremarks.com/
  4 Pete Walen http://rhythmoftesting.blogspot.com
  4 Rob Lambert http://thesocialtester.co.uk/
19 3 Adam Goucher http://adam.goucher.ca
  3 Adam Knight http://www.a-sisyphean-task.com
  3 Anne-Marie Charrett http://mavericktester.com
  3 Bob Marshall http://flowchainsensei.wordpress.com
  3 Eric Jacobson http://www.testthisblog.com
  3 Gojko Adzic http://gojko.net
  3 James Christie http://clarotesting.wordpress.com/
  3 James Lyndsay http://workroomprds.blogspot.com/
  3 Ministry of Testing http://www.ministryoftesting.com/testing-feeds/
  3 Parimala Hariprasad http://curioustester.blogspot.in/
  3 Seth Godin http://sethgodin.typepad.com/

180 different blogs where mentioned by 41 participants. The full list of blogs can be found here. An overview of all participants and their personal lists can be found here.

If this isn’t enough, you can check these listings of tester blogs:

ISST launch!

The International Society for Software Testing has launched – lets start putting the common sense & humanity back into testing!

ISST_logo_website

 

I was fortunate enough to be asked to be one of the founding members of the ISST. Looking down the list of members, I know most of them personally & can vouch for all of them.

The society is still in its infancy & there are many questions to be answered but one thing is for certain, there are many exciting times ahead & I am really glad to be onboard.

Go & check it out for yourself & let me know what you think:

http://www.commonsensetesting.org/

Popular books for testers

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.

testerbooksOne 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 :-D

Anyway, this is the top 10 of most mentioned books:

  1. Lessons Learned in Software Testing – Cem Kaner, James Bach, Brett Petticord (31 votes)
  2. Perfect Software and other Illusions about Software Testing – Gerald M. Weinberg (19 votes)
  3. Agile Testing – Lisa Crispin and Janet Gregory (14 votes)
  4. Thinking fast and slow – Daniel Kahneman (12 votes)
  5. How to Break Software – James A. Whittaker (11 votes)
  6. Tacit and Explicit Knowledge – Harry Collins (10 votes)
  7. 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)
  8. 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.