In the Agile-Testing list, Kevin Lawrence says “I share in the fantasy that my business people will write tests and am jealous of those who have turned fantasy into reality but, alas, I have not shared that experience.“
Wanting business people to write tests, to me, feels like a cook wanting the restaurant’s patrons to sauté their own mushrooms.
Dear Madam Business Person, I don’t want to stop you writing your own tests, if that’s what you really want to do, but I’m in the service business; tell me what you want and I’ll be happy to whip it up for you. It’s my speciality, and it’s my job to save you time and effort. I’m happy to collaborate closely, or for you to give me some fairly specific directions, if you like. However, giving you what you want while surprising and delighting and impressing you with information you and your programmers couldn’t quite have conceived on your own—that’s a good day for me.
Hello Michael,
Perhaps I’m wrong, though I see here a contradiction. Normally in Agile it is claimed to be a team effort were business is involved. I business is asked in fantasies to deliver the test cases; this activity is taken out of the team effort. Otherwise you would say: I would like the team to deliver the test cases.
In your example about the restaurant I could summarize it as: tell me what you want to eat and I will see if I can help you to get that food. This is in my opinion the same as: deliver me the requirements and I will help deliver the system.
If this will be the trend then the business is placed again out of the team and the introduction of a new colored waterfall is created. We only will continue when the people outside the team delivered their items/needs. Over time we might put criteria on the detailed level of those requirements.
I don’t think that the team should create the menu card were the customer can pick from because over time the menu card will be designed in such a way the restaurant can handle which might not always meets the customers needs.
Instead of running a restaurant it should be more like a house holding. As a family you define the roles and based on the circumstances you decide what to eat considering the available knowledge. If the need for something completely new is on the plate, try to support each other how to make it. If something new is wanted like Indian food or Dutch food, don’t hire a cook to make the dinner for you, find one who teach you how to do it your selves within the borders of your knowledge.
Having fantasies is good; fantasies might turn into new visions. Only don’t jump from vision to improvements. First you have to translate the vision into a mission and check if it fits together with the other missions and strategies of a company.
Honestly I’d be much happier if the business folks would just give me a little more help defining their version of what ‘good’ means. I can do all the tests myself but when I both determine the tests and what it means to be ‘good’ we are in dangerous waters…
🙂
To both Jeroen and Matt, thank you for your comments.
To Jeroen:
When I go to a restaurant, I particularly like an open kitchen, or a sushi bar. I like to see their skills in action, I like to observe the care with which they select and prepare the ingredients, and I like to be able to ask questions if they occur to me. But I don’t want to tend the grill; I don’t want to decorate the plate; I don’t want to plane the cucumber into a flat sheet on my own. (I once asked a sushi chef how he learned to do that so well; he told me that he did six months of doing pretty much nothing but planing cucumbers.)
To me, the point of paying for services and having teams at all is to take advantage of people’s different specialities and skills. Both programming and testing are services that we offer to other people who don’t specialize in those domains, just as I don’t specialize in banking or sales or animation or factory control systems.
The service of testing involves a particularly specialized skill: questioning the software and the systems that surround it. This is not exclusively our domain by any means; everyone else on the product is welcome, encouraged to do it too. But let’s extend the model a little farther: If we’re going to have business people write the tests, why not have them write the code for the product too? Why not have the programmers make the marketing decisions?
Collaboration on test ideas, yes, absolutely. Facility of some business people to write some tests, if that's what they really want, yes. Skills development and knowledge exchange, yes. The idea that test frameworks are so easy to use and to test that people outside the speciality can do it, maybe—if that's really what they want to do, and really the most efficient way to get the job done. But if, in our fantasy, business people write the tests, what services are we really offering?
To Matt: …when I both determine the tests and what it means to be ‘good’ we are in dangerous waters.
Yes. We can assist in the determination of what is good, and suggest other, more subtle dimensions of value. But the final determination of goodness comes from the business, and so the collaboration and guidance that we get from the business is essential. That partnership——in which the business is decidedly a senior partner—is essential in enabling us to make the most valuable discoveries for them.
As a matter of principle I agree with the approach you take, Michael, and it is exactly what I look for when I am interested in paying for a service. I struggle, however, when the customer/server relationship is blurred as it is in my company. I am working to provide a testing service for the company just as the business group is providing an analysis service for the company and the development team is providing a development service to the company. In each of those situations we are trying to provide the best service we can, but the business and development groups are internal customers also.
These internal customers don’t pay me for my services, however. They simply need quality feedback in order to do their job well; just as I need the code to be tested well and concise and clear documentation in order to do my job well. I think that in this context it is more reasonable to expect them to “cook their food”, but there is a delicate balance that I try to maintain.
It is in this context that I think a lot of people in testing (and I could speculate in development as well) make a critical error. They start to demand requirements before they’ll test, and they won’t make concessions on how they’ll write bugs or deliver information because the test team knows “the real way” to do things. The testing group can then come off as whiny and preachy and in the end fail to meet the objective that they set for themselves because none of the other groups want to work with them anymore.
Hi, Joe… thanks for writing.
I agree. Some people might argue that if you don't have exactly the right conditions, documents, environments, or what have you, then it's your prerogative to refuse to test. I'd contend that if you know that you don't have the right conditions, documents, environments… well, that's valuable testing information right there.
I have no objection to a closely collaborative relationships with the customer. Where I think some in the community straym—what prompted my initial post—is the idea that we want the customers to express their ideas in the language of code. Our typical customers hire software developers (that includes programmers, testers, business analysts, designers, and so forth–the whole technical team) specifically because they didn’t want to write software themselves. No matter how elegant the domain-specific language, no matter how simple the framework, I would prefer not to oblige my customer to use any language other than her own to express her requirements and her test ideas.
—Michael B.
My personal preference is to write the tests together with the customers *and* the development team. Whenever my team writes high level tests all together, we have the best results in terms of delivering what the business really needed. We always do this when we’re working on a risky or complex story. I don’t mind turning the customers’ test cases into executable tests.
Thanks, its a useful argument that could be extended to also use against those who push the idea of a business rules engine enabling the business to write the rules in a way that does away with code.