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…
Huib,
Thanks for a great read and a clear explanation of your principles.
In terms of my post, one thing that is worth making clear is that I was not writing in response to your talk alone, but a combination of your talk and other statements and anecdotes from the day relating to moving between testing projects. Your “refusing to do bad work” statement was the most explicit so it would have been strange for me not to mention you, however my post was written from the perspective of someone attending the whole day and the combination of talks and stories related.
Regarding your statement
‘I think I said exactly that: “if anything else fails, leave!”’
I’m happy to accept that you did say that. I appreciated whilst writing my post that I did not have the benefit of session recordings to check exactly what was said in each talk. I initially considered waiting to see recordings to check, however I think this actually would have undermined my position. I was writing based on my recollections of the key points that I took from the day, as that was my primary concern when writing the post. I’m sure that the message of doing everything that you can to add value was not missing completely, however I don’t recall it being one of the key messages that was repeated. Based on Chris’ comment I was not alone in this. People attending didn’t have the benefit of a full transcript from the talks when discussing TestBash the following week around the coffee machine at work with their fellow testers. In such conversations, based on my own recollections, I think that the moving on message would have been prominent and the knuckling down one much less so.
I’m glad both for your talk, which I enjoyed and for the most part agreed with, and this post which allows people to read and share your principles with others. As I expected the principles that you outline here are very much in line with my own. I am also a great believer in taking an approach based on integrity, as I write about this year http://www.a-sisyphean-task.com/2014/01/integrity-and-pragmatism.html. One thing that I am not in alignment with is this statement “I think along the lines of restrictions in a context, demands placed on them that they don’t know how to handle.” – for me working in a restricted context and striving to elicit change, expose valuable information and add value wherever you can is an opportunity to demonstrate good testing work by adopting exactly the type of ‘knuckling down’ attitude that I was referring to when I wrote my post.
Adam.
Thanks for your reply Chris. As you said, it is a grey area. There are many examples of people “faking” knowledge or pimping their resume. That is more the thing I was thinking of.
Of course knowledge is important. But curiosity and the ability to learn quickly, makes that a tester can quickly attain knowledge and therefore less makes it less important (quote form an old blog post: “What makes a good tester?” https://www.huibschoots.nl/wordpress/?p=433).
Many thanks for taking the time to write this blog entry Huib. I was present at your talk at TestBash, and, like Adam, I came away with the impression that that the recourse to suggestions of bad work was to leave. Middle age is setting in, so I can’t recall your exact words, and I’m glad that you’ve taken the trouble to clarify your message.
My only slight quibble with what you have to say is the grey area between taking on a job where you don’t have the knowledge, as opposed to having faith in your tester skills to gain the knowledge when you’ve taken on the job. Where is the line here? There’s a certain degree of risk when you plunge into the unknown. I recall a James Bach talk when he recalled being asked to supply professional evidence for a legal dispute, for a product he had no initially knowledge of, but was able to put together a lab, conducting experiments etc to get the evidence the client required. Seems ethical enough to me.
I’d say integrity comes about when your actions match up to your ideals of how you should act, according to your own ethical compass. I’d also say that your projection of yourself should be true to the person you really are. Integrity is an issue not just with how you behave towards your client, but also how you relate to others in the test community. For example, I agree with what you and other CDT’ers have to say about the ISTQB, but its not really a big issue for me, so I don’t bang on about it because I don’t feel that’s what I’m really about.
I’d also say that doing the right thing is about more than not doing bad work, but acting up on matters which could be better. I’m thinking here about the edge cases of what we do as testers :
What do we do when we come across a third party tool that has faults?
What do when we see other projects outside our remit going badly?
Do we go out of our way to contact and encourage someone who has made a constructive contribution to the community, or do we just read it and nod silently?
What do we do when we come across published views we don’t agree with?
To actually answer your final question about what I’d do if I was tasked with a tricky issue. I have worked as an independent contractor for 20 years, and I don’t have dependents. So it’s easy for me to say I’d stand my ground. I just don’t think you can separate the views you take from the person you are, and that depends on your history and circumstances.