This is the latest version of the commitments I make when I work with a programmer.
Dear Programmer,
My job is to help you look good. My job is to support you as you create quality; to ease that burden instead of adding to it. In that spirit, I make the following commitments to you.
Sincerely,
Tester
- I provide a service. You are an important client of that service. I am not satisfied unless you are satisfied.
- I am not the gatekeeper of quality. I don’t “own” quality. Shipping a good product is a goal shared by all of us.
- I will test your code as soon as I can after you deliver it to me. I know that you need my test results quickly (especially for fixes and new features).
- I will strive to test in a way that allows you to be fully productive. I will not be a bottleneck.
- I’ll make every reasonable effort to test, even if I have only partial information about the product.
- I will learn the product quickly, and make use of that knowledge to test more cleverly.
- I will test important things first, and try to find important problems. (I will also report things you might consider unimportant, just in case they turn out to be important after all, but I will spend less time on those.)
- I will strive to test in the interests of everyone whose opinions matter, including you, so that you can make better decisions about the product.
- I will write clear, concise, thoughtful, and respectful problem reports. (I may make suggestions about design, but I will never presume to be the designer.)
- I will let you know how I’m testing, and invite your comments. And I will confer with you about little things you can do to make the product much easier to test.
- I invite your special requests, such as if you need me to spot check something for you, help you document something, or run a special kind of test.
- I will not carelessly waste your time. Or if I do, I will learn from that mistake.
(This is cool! Yong Goo Yeo has created a Prezi of this.)
An Important Comment
This comment came in from Stuart Taylor. I think it’s important enough that I should add this to the post:
Hi James,
I’m not sure if this is meant to be a little tongue in cheek, but that’s how I read it. That said, I fell at point 1. “I provide a service” really?
Yes, really. This is not a joke. And point #1 is the most important point.
This implies there may be alternative service providers, and if my customer relationship management isn’t up to snuff, I could lose this “client”. Already I feel subservient, I’m an option.
Of course there are alternative service providers. (There are alternative programmers as well, but I’m not concerned with that, here. I’m making commitments that have to do with me and my role, here.) And yes, of COURSE you may lose your client. Actually that’s a lot of what “Agile” has done: fired the testers. In their place, we often find quasi-tester/quasi-programmers who are more concerned with fitting in and poking around tools than doing testing.
Testing is not programming. Programmers are not testers. If you mix that, you do a sorry job of both. In other words: I am a programmer and a tester, but not a good programmer at the same time that I’m a good tester.
Please meditate on the difference between service and subservience. I am a servant and I am proud of that. I am support crew. I spent my time as a production programmer and I’m glad I don’t do that any more. I don’t like that sort of pressure. I like to serve people who will take that pressure on my behalf.
This doesn’t make me a doormat. Nobody wipes their feet on me– I clean their feet. There’s a world of difference. Good mothers know this difference better than anyone.
Personally, when I work on a software project, I want to feel like I’m part of the team. I need the developer, and the developer wants me. We work together to bake quality in from the start, and not try and sprinkle it on at the end as part of a “service” that I offer.
What strange ideas you have about service. You think people on the same team don’t serve each other? You think services are something “sprinkled” on the end? Please re-think this.
I want to be on the same team, too. The difference, maybe, is that I require my colleagues to choose me. I don’t rap on the door and say “let me in I belong here! I like to be on the team!” (You can’t just “join” a team. The easier it is to join a team, the less likely that it is actually a team, I think. Excellent teams must gel together over time. I want to speed that process– hence my commitments) Instead, I am invited. I insist that it be an invitation. And how I get invited quickly is by immediately dissolving any power struggle that the programmers may worry about, then earning their respect through the fantastic quality of my work.
You can, of course, demand respect. Then you will fail. Then five years later, you will realize true respect cannot be demanded. (That’s what I did. Ask anyone about what a terror I was when I worked at Apple Computer. If you are less combative or more intelligent than I am, you may make this transition in less time.)
I may have actually agreed with your points before I was exposed to Continuous Integration, because that’s how my relationship used to be; hence me interpreting this as a light hearted piece. However I know that this kind of relationship still exists today (its here at this place). When I began working with continuous integration, the traditional role of the tester, with a discrete testing phase became blurred, as the test effort is pushed back up stream towards the source. If the tester and developer share a conversation about “how can we be sure we build the right thing, and how can we ensure we built it right” before the code gets cut, and the resulting tests from that are used to help write the code (TDD, BDD, SBE), then both of us can have a nice warm fuzzy feeling about the code being of good quality. The automation removes the repetition (and reduces the feedback) to maintain that assertion.
First, your experience has nothing to do with “continuous integration.” Continuous integration is a concept. Your experience is actually related to people. Specific people are collaborating with you in specific satisfying ways, probably because it is their pleasure to do so. I have had wonderful and satisfying professional relationships on a number of projects– mostly at Borland, where we were not doing continuous integration, and where testers and programmers cooperated freely, despite being organized into separate administrative entities.
(Besides, I have to say… Testing cannot be automated. Automation doesn’t remove repetition, it changes it. Continuous integration, as I see it, is another way of forcing your customers do the testing, while placing naive trust in the magic of bewildering machinery. I have yet to hear about continuous integration from anyone who seemed to me to be a student of software testing. Perhaps that will happen someday.)
In any case, nothing I’m saying here prevents or discourages collaboration. What it addresses are some of the unhealthy things that discourage collaboration between a tester and a programmer. I’m not sure if in your role you are doing testing. If you want to be a programmer or a designer or manager or cheerleader or hanger-on, then do that. However, testing is inherently about critical thinking, and therefore it always carries a risk (in the same way that being a dentist does) that we may touch a nerve with our criticism. This is the major risk I’m trying to mitigate.
[Note: Michael Bolton pointed out to me the “warm fuzzy” line. I can’t believe I let that go by when I wrote this reply, earlier. Dude! Stuart! If you are in the warm fuzzy business, you are NOT in the testing business. My goal is not anything to do with warm fuzzy thinking. My goal is to patrol out in the cold and shine my bright bright torches into the darkness. On some level, I am never satisfied as a tester. I’m never sure of anything. That’s what it MEANS to be a professional tester, rather than an amateur or a marketer. Other people think positively. Other people believe. The warmth and fuzziness of belief is not for us, man. Do not pollute your testing mentality with that.]My confusion over this being a tongue in cheek post is further compounded by point 2. Too many testers do believe that they own quality. They become the quality gate keeper, and i think they enjoy it. The question “can this go live” is answered by the tester. The tester may be unwilling to relinquish that control, because they perceive that as a loss of power.
Just as excellent testers must understand they provide a service, they must also understand that they are not “quality” people. They simply hold the light so that other people can work. Testers do not create quality. If you create quality, you are not being a tester. You are being an amateur programmer/designer/manager. That’s okay, but my commitment list is meant for people who see themselves as testers.
I guess what i’m fumbling about with here, is that some testers will read this, and sign up to it. Maybe even print it out and put it up on the wall.
I hope they do. This list has served me well.
Either way, you have written another thought provoking piece James, but i cant help wondering about the back story. What prompted you to write it?
Stuart – sat in the coffee shop, but with laptop and wifi, not a notepad 😉
This piece was originally prompted when I took over a testing and build team for SmartPatents, in 1997. I was told that I would decide when the software was good enough. I called a meeting of the programmers and testers and distributed the first version of this document in order to clarify to the programmers that I was not some obstacle or buzzing horsefly, but rather a partner with them in a SERVICE role.
That was also the first time I gave up my office and opted to sit in a low cubicle next to the entrance that no one else wanted– the receptionist’s cubicle. It was perfect for my role. Programmers streamed by all day and couldn’t avoid me.
I think this piece is also a reaction to the Tester’s Bill of Rights (the one by Gilb, not the one by Bernie Berger, although I have my concerns about that one, too), which is one of the most arrogant pieces of crap I’ve ever seen written on behalf of testers. I will not link to it.
And now that I think of it, I wrote this a year after I hired a personal assistant, and two months later had her promoted to be my boss, even though she retained almost the same duties. The experience of working for someone whose actual day-to-day role was to serve me– but who felt powerful and grateful as my manager– helped me understand the nature of service and leadership in a new way.
Finally, a current that runs through my life is my experience as a husband and father. I am very powerful. I can make my family miserable if I so choose. I choose to serve them, instead.
If I were a developer, I will test my own codes and make my testing commitments as follows:
1. Know The Test Mission: I know what kind of testing I need to make me satisfied about quality.
2. Know The Test Goal: Shipping a good product is always my final goal.
3. Test Early: I will test my code as eary as possible because I need my test results quickly (especially for fixes and new features).
4. Test Management: I will strive not to make testsing a bottleneck.
5. Test Altitude: I’ll make every reasonable effort to test, after all I know my product more than any one else.
6. Test Psychology: I will learn to observe my product critically and in a different way so as to test more objectively.
7. Risk Based Testing: I will test important things first, and try to find important problems. (I will also report things you might consider unimportant, just in case they turn out to be important after all, but I will spend less time on those.)
8. Know The Clients: I will strive to test in the interests of everyone whose opinions matter, including mine, so that we can make better decisions about the product.
9. Test Documentation: I will only write necessary problem reports.
10. Test Improvement and Testability: I will pay attention to the way I’m testing, and invite comments. And I will make every effort to make the product much easier to test.
11. Test Strategy: I will know what I can test can what I can’t test. I will tell the testers what they should test more thoroughly.
12. Cooperation: I will prepare to discuss any issues with testers about my codes.
Programmers can lose perspective and you can help us be better via letting us know about usability/design issues. Just be kind, sometimes our egos bruise easily and sometimes we’re in too much of a hurry to do things just right and good enough has to suffice. However, it can be very valuable that there are different points of view.
[James’ Reply: Every tester should spend a few hours of their career getting their work “tested” just to feel what it’s like to be on the receiving end.]
I like this list of commitments, and I’ve seen earlier versions of it, and knowing how you usually share your work I want to know if it’s ok to use this when I work with programmers?
I don’t want to presume anything so I ask.
I would of course make sure that it’s completly clear that it is your work, not mine.
[James’ Reply: Yes, please use it. Edit it as you see fit. The only attribution I would ask is that if you PUBLISH your version you say “based on A Tester’s Commitments by James Bach”]
Excellent James!
Many of these points are in your book “Lessons Learned in Software Testing”. But I think seeing them encapsulated into a “Letter to the programmer” format makes it very, very powerful!
Will you be following up with similar articles about commitment to the other stakeholders we serve?
Thank you!
[James’ Reply: Hmm. That’s a good idea. I should do that.]
Hi James,
I’ve seen your list somewhere before (I think you spoke about it in a video I saw posted on the STC website – sorry I can’t get ahold of the link at the moment) and I like it. I was wondering though, have your commitments ever landed you in a difficult situation? For example, are you asked to do “bad” work because that would satisfy the coder?
Cheers,
Vern
[James’ Reply: Yes, it can require some delicate footwork, at times. But you see, nothing in here says that I do what I’m told. Just because I will strive to fulfill any special requests does not mean that I dump my professional responsibility behind the desk and out of sight.]
Fabulous — I only wish I had organized my thoughts on the matter as well. I think this could serve as a model for our commitment to other stakeholders as well.
On Stuart’s comments about providing a service: The developers are providing a service too. As are the analysts, PMs, system administrators, coffee pot fillers, accountants, sales staff, and anyone else who doesn’t have significant ownership stake in the corporation that is paying the salaries for these services. This is something that many people I talk to seem to have either forgotten or never considered. Testers are not more or less important than developers, just like receptionists are not more or less important than VP’s of “I wanna make a lot of $”. We all serve the owners, the check writers, who serve those who write checks to them (namely investors and customers).
The question isn’t “am I a service provider”, the question is “am I providing a service that supports the compensation I am receiving for providing that service”. If the answer is “no”, I suggest either upgrading your service or seeking more balanced compensation (whether that means seeking higher compensation, or requesting your salary to be lowered is something you’ll have to answer for yourself.
—
Scott
James,
Thank you for articulating the testers role so well, I couldn’t agree with you more. We have been teaching these concepts for several years in our organization, and your blog here was just forwarded to my by one of our testers – that was great to see. Thank you!
jrw
Great post, James and I can’t agree with you more. If Testers and Developers understand and adhere to these commitments, I think the relationship between them will greatly improve and will eventually enhance productivity in the organization.
To start with, I’m going to stick these commitments on my office wall and forward this post to all the developers I directly work with.
A few more examples of service providers:
A doctor provides a service. I’ve never met a doctor who behaved as though (s)he was subservient to me.
A pilot provides a service. I’d have a hard time imagining a pilots who was subservient to me.
In my first career, I was a theater stage manager. You might not believe how this prepares a person to be a program manager for a software project. See Artful Making: What Managers Need to Know About How Artists Work by Robert D. Austin (who does) and Lee Devin (who helped him learn how). I was in service to the performers; no one came to the theatre or watched the touring show to see me. In the touring company, I drove the van, fixed the set, did the laundry, rewired the lamps when they broke, set up the technical equipment while the actors prepared for their performance. It was my job to make the actors look good. Yet I was the responsible representative for the company and the director. I made sure the curtains went up on time. I ran the show. I was responsible for company discipline. Note that that’s different from “disciplinarian” in the same way that being responsible for providing a service is different from being subservient. Or servile. And we were all in service to our audience.
Jon Bach has often mentioned to me that when he’s the manager of a testing team, he’s in service to the team. It’s their job to do work for which he is ultimately responsible (they serve him), but it’s his job, among other things, to get obstacles out of their way and to create an environment where they can all do their best work. You can lead and serve at the same time.
The great lesson of all this: we’re all here to serve each other, aren’t we?
—Michael B.
Hmm, my ramblings seem to have to been misinterpreted slightly (and that is my fault for being inarticulate), so i will follow up on my blog, post coffee. i don’t wish to pollute James’ work further.
With regard to my point about servitude, it was within the context of the opening statement of the letter “My job is to help you look good”. That statement suggested “subordination” to me. But then i’m interpreting James’ words within my experiences.
My job at this organisation is to help it make more money.
Stuart
[James’ Reply: You can say that. From a certain point of view, it is true. But when you say that, you are strangely obscuring other aspects of what you do for a living.
Here are some other things that are also true of your job, I hope:
– My job is to forge the working relationships that allow me to make more money for the company.
– My job is to make more money for the company without unnecessarily sacrificing my health or future capacity to make a living.
– My job is to make more money for the company by minimizing the chance that we will not know about important problems in the product.
– My job is to make more money for the company by using my working relationships with the programmers to help them to know the true status of the product, in a murky, volatile, complex, social environment, so that they can make better decisions about that product, such as by improving it in various ways, and to do that in a way that is accepted and respected by all involved.
Let me put it this way, if you actually believe that your job is to make the company more money, then you should present yourself to your colleagues in such a way as to maximize the probability of success in that mission. I have found that these commitments do that for me. Your mileage, may, of course, vary.]
“I think this piece is also a reaction to the Tester’s Bill of Rights, which is one of the most arrogant pieces of crap I’ve ever seen written on behalf of testers. I will not link to it.”
A while ago, I was experimenting with a Tester’s Bill of Rights…A quick Google search supports my hunch that you’re not talking about this:
http://bernieberger1.blogspot.com/2009/12/testers-bill-of-rights.html
-Bernie
[James’ Reply: Right, I’m not talking about that. I’m talking about Tom Gilb’s thing. I didn’t know there were any others.
Yours doesn’t strike me as arrogant… but I find them confusing. From what foundation do these rights derive? Whose rights are they? Do I have the right to test the software of a company that does not employ me?… probably not. Do I really have the right to make mistakes? Any mistake? Does having a right mean I can’t be penalized for exercising it? Can I be penalized for making a mistake?
This is why I have not created an alternative Bill of Rights. I don’t think testers have any special rights. But certainly I can make commitments on my own behalf.]
Wonderful discussion and a wonderful blog post!
Thanks to Stuart for firing off the debate and thanks to James for the wonderful insights.
It’s this kind of thinking that can get people off their high-horses and assume a healthily humble approach towards being a member of a team.
Thanks guys!
Ever since I read the Ongoing Revolution of Software Testing by Cem Kaner, where he talks about QA as in Quality Assistance, I’ve also promoted testing to be a service.
When a company has promoted a certain school of testing for a long time where the testers role has not been a service, but instead been more of policing, and where they now promote speed over rigidity, testing being a service becomes more natural. I think a letter of intent or commitment is a good way when considering that we need to change in our mindset on testing.
This post was so thought provoking for me, I’m still on point one with questions after my forth re-read and sleeping on it. As a consulting test practitioner, I’m conflicted. I’m hoping you can help me better think about point number 1 and explain some of what you mean by it.
1. I provide a service. You are an important client of that service. I am not satisfied unless you are satisfied.
In my own mind, I can think of times when a developer has expectations that aren’t reasonable, do not serve the project, and do not take into account context.
[James’ Reply: Yes, that’s not uncommon.]
I worked too many hours for free because of this, and have struggled to set the right boundaries. The intent of this developer is fantastic. He feels our code should be covered, and hours should be spent. The fact is, the level of risk isn’t his decision or my decision. There are only so many hours that will be paid for, and beyond that, it is no longer my choice. My desire to “do right” or “do good” has led to painful compromise, which I’m not proud of. My developer gets to help prioritize the tests. However, when one developer sends me an exact list of how I should test? That is insulting.
[James’ Reply: Nothing in the commitments says I will do exactly what I’m told (or for that matter *anything* I’m told). Let me put it this way. I provide service to my son, and I’m not satisfied unless he is satisfied. This was true when he was a newborn, and its true today. Sometimes that means I’m not satisfied, because I can’t find a way (that’s also okay with me) to satisfy him.
I provide service within my role. My role is to test. Testing requires independent judgment and action.
One way to deal with a developer who tells you exactly how to test is to sit down and have a long conversation with him about his plan. Either he won’t have the stomach for that, at which point you thank him for his ideas and do what you think is best, or he will have the stomach for it, in which case that’s great, you can talk through all the issues until you both are on the same page.]
I have more experience both testing AND with these projects than he does, and I expect collaboration. Just as I wouldn’t be so rude as to tell him exactly how to code and to be my code monkey, I expect him to inform my testing, not direct me like a puppet.
[James’ Reply: I don’t see why you are concerned about this. He can’t direct you like a puppet, can he? He doesn’t have the power to compel you to do anything, does he? The tester commitments are about you caring what he thinks and says. Well, DON’T you care? You should care very much. Don’t fear that.]
These human issues are the most complex. For me to provide informed, appropriate testing, I need room and trust to do my work. Let me decide what tests to run. I don’t want a list of confirmatory functional tests. I’ve tried working slowly to educate developers more about testing, to help lower the probability of needless iterations. I would love to add value in this way, but many developers aren’t aware that we can do that, or aren’t interested in improving.
[James’ Reply: Whether or not they are, my commitments to them still stand.]
I am satisfied even if the developer is not satisfied if what they need to be satisfied is unreasonable, misinformed, or harmful to me or the goals of the team. I agree with the intent of what you are saying in point 1, but it isn’t fair to assume that what all developers need to be satisfied is fair, benevolent, and in the best interest of the project.
[James’ Reply: To be satisfied when your clients are not satisfied indicates that you do not consider yourself to be on the same team, because if one person on a true team has a problem, everyone does.
I don’t believe you actually would be satisfied. You wouldn’t be smiling and content, knowing that your clients think your work sucks would you? You might accept that, but wouldn’t you hold out some hope to convince them that you are doing a good job?]
Great post James!
Great debate and thanks for sharing, to everyone that commented.
I’m a tester and I adhere to the attitude of being a service provider. Assuming that attitude to me it means that in every situation, in every interaction, I strive to deliver the most value my abilities allow me to deliver.
All my career I’ve worked with people who didn’t understand what testing is, how it benefits a product, a team, a business, who thought and spoke bad of testing and of testers, who had unreasonable expectations of testing.
It used to hurt me a lot, and I would consume huge amounts of time and energy trying to reason with them, arguing with them, trying to come up with ways to make them see things as I did.
In time, I came to realize that, most of the time, this was not the best way to use my time and energy.
Now, I approach all situations with this core attitude: how can I provide the most value in this situation? What action would yield the most return on investment, both short term and long term?
With this core attitude, I analyze each situation, I make my decisions and then I act on them.
Sometimes, I get good results, excellent results.
Sometimes, things turn differently than I expected. But even then, I’m not to hard on myself cause I know I analyzed the situation and did what I thought was the best thing I could do. And because I analyzed the situation now it’s easy for me to see what lesson is there for me to learn and I’m sure next time I’ll do better.
I like the idea of a document like this that is explicitly shared. One of my favorite developer interview questions is to ask what they like to get from testing. Often, they don’t appear to have really thought about it before – they seem to just take whatever they’ve been offered in the past and never considered their actual needs.
Other audiences could benefit from such a document given the uneven understanding of the test mission I have encountered in my career. What are a tester’s promises to project management, executive management, customer support, etc?
I like Lanette’s use of “inform”, especially if I get to pick the definition of “to give character to…”. In this sense both sides get to choose the “core” of what they are producing, but allow room for input from the other to enrich what they start with.
Hi,
I certainly agree with the ‘Service’ aspect of testing, hey even IT is a Service provider to the people that actually matter (the Business) and they can, if they wish, find another way of obtaining the service that we all provide. In our organisation I would envisage us needing to develop a similar charter for the a) Project, and b) Service Transition; as we serve both parties. We serve the Project by providing the testing service that is required to meet Service Transitions requirements to change the Production state. Obviously, this is missing out the Business but we’d get to that.
On the warm fuzzy comment, I used to believe that that was one of the byproducts of the testing service that we offered, however, it’s there’s a very thin line between ‘Warm and Fuzzy’ and ‘Fraudulent’…
I totally agree with you – testers are service providers, but I kinda squirmed when I read “Nobody wipes their feet on me– I clean their feet.” this description doesn’t sound much better than a doormat to me… for me it’s more like you make sure their shoes won’t fall apart after rigorous training.
[James’ Reply: Are you a parent? If so, then I will be able to point to many examples of your own experience where you are content, even joyful to do things that look to non-parents as if your children are taking advantage of you. I once stayed up an entire night rubbing my 10 year-old son’s back after he got a sun-burn and was itching too much to sleep. He didn’t ask me nicely to do that, and he didn’t thank me for it afterward. I’m pretty sure he doesn’t remember that I did it. But, I don’t need thanks. It’s one of those things a father does.
If you aren’t a parent, you may have to become a parent to begin to understand the tremendous difference between giving service and being someone’s slave.
I’m not saying that programmers are children or that I am their parent. I’m saying that service is noble and not the same thing as being used or abused. Parenting is merely a strong example of this.]
@Stuart: “My job at this organisation is to help it make more money.”
To me, statements like this always bear more nuance. For example, if it’s really true, why not rob banks and give the proceedings to the company?
(aside) I’m glad YOUR experience as a tester at Borland was as a warm & fuzzy relationship with the developers. We didn’t have that close a relationship in dBase V – and there were a few who got nasty with us. (/aside)
[James’ Reply: Yes, I talked with the dBase for Windows guys a few times while I worked there. That was a project from Hell.]
In my current contract at Nike I’m in a group that DOES have that Agile+TDD thingy going on and we DO like working with each other. A lot.
Funny thing happened today – we got around to starting to write test automation stories (finally) and where we (testers) have been writing tests for the dev’s to develop into, alluva sudden the shoe was on the other foot. There was a moment of stunned silence followed by a round of delighted chuckles when we discovered that we testers, writing code in jUnit, would be writing into tests written for us by the dev’s!
I guess my overall point here is that I am on the friendliest, funnest team I’ve ever been on, and I think we owe it to the collaboration between our teams and inside our teams that really following an agile model has given us. Course, perhaps the people who hired us were looking for fun people to work with, too.
Louie Gluefish
Brilliant list!
I think it captures nicely my own attitude to my role in a project. I have worked hard changing my own attitude from quality police to service provider – I was seriously mislead by the folklore and attitudes of experienced testers 15 years ago – Yes many of the same people that work with the certification scams today! I always tell the developers that one of my goals it to make them look good, actually to make us as a team look good. I never cram bug reports down their throats. If the code is an early stage a write an e-mail instead of entering a bug report. This approach more important than many think, it shows that our goal is not to find bugs and count them but to help solve the problem. – Then us testers are often invited to discussing how we can solve the things found in early testing.
We testers get respect because we treat others with respect. We get respect because we do whatever we can to handle our own test environment like creating our own test data, running batches, queries etc. We get respect beacause we find things that others are not aware of. Like one of your first slides in the RST class says – We are the lights of the project! Nowadays we are also general problem solvers. When we speak – they listen.
We are Testers 2.0 !
Hi James,
As a follow up to your comment about a Tester’s Bill of Rights, I don’t think I meant to speak for the entire testing community when I said you have the right to make mistakes, or any of the other things on that list. THAT would be arrogant. The general gist of what I wanted to say was that I want the freedom to continually improve myself at my job. I’ve laid it out in a new blog post:
http://bernieberger1.blogspot.com/2011/12/bill-of-rights-take-two.html
Just in case you’re interested in derived works:
http://richardontesting.blogspot.com/2011/11/test-leads-commitments-v-01.html
Richard
[James’ Reply: Cool!]
Hi James,
Thanks for the thought provoking post. Most of the commitments I agree with, but a few have got me slightly perplexed:
1. The commitments are aimed solely at the Programmer – isnt the Testers commitment to the whole development team?
[James’ Reply: The relationship between programmer and tester is special. I chose to focus on that. Feel free to make a commitment list that applies to others.]
2. I’m sure I’m not on the development team to help the Programmers look good – Am I not there to help the development team deliver great software?
[James’ Reply: Okay, you are sure. Personally, I am sure that I AM there to make the programmers look good. They will look good because their work is better because I helped them find problems before it’s too late because I was specifically hired to help find problems before it’s too late.
You have to ask yourself is whether it helps your relationship with programmers not to explain how it benefits them personally, directly, and vividly that you are there. Of course making them look good is not the ONLY thing you do, but it’s relevant, true, and useful to say so.]
3. I don’t feel I’m on a development team to wipe a Programmers feet – what if they forget how to wipe their own feet?
[James’ Reply: Then I guess they will need me all the more. Cha-ching. Job security. Just as it wouldn’t behoove me to convince my wife that she doesn’t need me, I would prefer NOT to convince my clients that they don’t need me.
I suppose you mean to say that “clean their feet” is a nasty job. Well, I guess you’d have to be more specific about that. There are some things I’d like programmers to do for me, sure. Especially if it’s easy for them and hard for me. For instance, I’d like a summary of changes made to the code I’m testing, instead of doing my own investigation. But I want to express the attitude that I can live without that, if there’s some sort of difficulty giving that information to me in some situation. I want to convey the attitude of cheerfulness and flexibility.]
4. The biggest question for me is testing a service & this is the one that really made me stop & think about how I operate. Thanks for getting me to think about it!
Anyway, I’ve written my response to your commitments & how I feel about them on my blog:
http://www.duncannisbet.co.uk/my-response-to-a-testers-commitments-from-james-bach#comment-60
Cheers,
Duncan
Thanks for the responses James.
I think I’ve missed a fundamental point that this open letter is aimed solely at the Programmers of a development team. This is a definite takeaway for me – Ensure I understand what I’m reading & respond appropriately.
I probably wouldn’t have used the feet wiping analogy, as to me that could be perceived as subservient in the software development context, but I get the point.
I appreciate what you’re trying to achieve with the commitments & as discussed, I’m going to give it a go myself & I’d like your feedback. It only seems fair!
In order to give context to how I feel about other relationships in software delivery I’m going to try & write commitments to other Testers, BAs, PMs & the Customer as well.
This may help me to have a stab at writing about what I expect from these other members of the development team – which I hope we could refine in an online coaching session.
Duncan…
…about what I expect from these other members of the development team
You’re probably not their manager. Even if you are, I’d suggest that you change that to what you’d like; what you’d desire. But even then, let me offer this:
Instead of telling them what you’d like, pause. Tell them what your own commitments are, and ask if there’s anything that needs changing in that set of commitments. Then ask (don’t declare) what their commitments are or should be, and if you see a difference between what they’re offering and what you believe you need, ask about that.
—Michael B.
Nice touch Michael, thanks for the follow up.
We’ve started running expectations workshops to determine what we believe each of us brings to the team.
It’s proven a great way to flush out where those expectations are likely to be unmet & address them there & then.
Duncs
Thanks James !
Your ideas and philosophy around testing shows totally new direction and light.
Seeign from the point of view of Ethics and Integrity and the most touching piece is your ” Service Leadership” this has to be Mission and vision of many organization. Inspiring stuff.