This post is a digest of my “Lets Taste” session from Let’s Test 2013 with some additions based on the feedback I received from the session. Retrospective on the session will come in a later post…
I like to test software sooner rather later, like a chef tasting their food as they prepare it
I get frustrated if I know there are features ready to be tested, but I have to wait for those features before I can start testing (e.g. to be included in a release).
I have a model which I use to help me get my head around the structure of a development team:
Kitchen Brigades agree on a range of meals contained in a menu to be eaten by customers in the restaurant
Development teams agree on a range of features contained in a product to be used by customers on their digital devices
But remember George EP Box:
I see development teams as being made up of people fulfilling software development roles & tasks.
E.g. Programmers write code which Testers help to reduce the uncertainty in (test it). We’re both helping to deliver software to a customer. Without either of us, the software the customer is hoping for is not likely to be delivered.
Liken this to the chefs in the kitchen - they are all chefs preparing one element of a dish. E.g. Fish Chef prepares the fish, the Saucier prepares the sauce to compliment the fish. How good is the sauce without the fish?
The metaphor also goes on to compare those people that enable the development team to deliver features. E.g the DBAs & Sys Admins are likened to the food suppliers & delivery folk- without them there would be no food to serve. (I also include the potwash & cleaning folk who keep the kitchen running, but I’ve found the analogy has negative connotations when applied to the development team)
Ultimately, I see those who write the code & those who ask questions of the code both as developing the software. I focus on the roles of the people, not their title. Like the kitchen brigade, those people preparing the food are all chefs.
Take aways
In that they fulfill a role on a development team, as do Programmers - like chefs fulfill roles in a kitchen brigade.
Programmers are Developers. Testers are Developers. We work together to deliver software.
I cut this statement out of the session as when I was trying out the session on my work colleagues it distracted to much from the main focus of the session. I now keep it as meta rule & talk to people about it who want to have that discussion.
Testers are Developers
The key take away from the session is that Testers are not food critics - we’re not the customer in the restaurant, we didn’t order the food. It’s not up to us to say whether the food is good enough for our customer
Some great feedback I got from this statement was that although we shouldn’t say if the software is not/good enough, we can bring our knowledge & experience to provide a more informed response.
This ties in with another take away that we can provide more value sooner if we are in the kitchen when providing the response - i.e. helping to create the menu & dishes
I took the example of tasting food for it’s salt content - we wouldn’t say the food was too salty or not salty enough. We could say that there is more salt compared to the same dish prepared last week. Is there a reason for the extra salt? Is the extra salt a problem? Was the reduced salt a problem?
We could also compare the salt content to the recipe - the recipe states add 5 grams of salt. There is more than 5 grams of salt in that dish.
This is how I shoe horn the 3 environments I test in to my model of a restaurant:
Sauce Code
Focus is on taste. Does the flavour of the food or sauce work by itself? Bugs found here can be scooped out of the pot & squashed quickly & easily - the customers should have no idea this bug ever existed.
Focus is on functionality. Does the feature work as expected independently of other features (if applicable). Bugs found here are cheaper (& easier?) to fix - the customers should have no idea this bug ever existed.
Integration
Focus is on how the foods work together - is the sauce covering the fish suitable for fish, or is it a beef gravy? There is also an element of how the food looks on the plate - is it appealing to the eye? Bugs found here (on the plate) might result in the food on the plate being thrown in the bin at extra cost & time to the kitchen & a delay in serving up the food to the customer
Focus is on integration - how does the feature work with other new & existing features? Bugs found in this environment might require another version of the product being released to this environment at extra cost & time to the dev team & a delay in delivering the product to the customer
Production
Focus is on feedback from the customers - did the food arrive in a timely manner? Was it warm enough? Was it what they even ordered?
Focus is on feedback from the customers - did the product arrive in a timely manner? is its performance good enough? Was it what they even wanted?
As I mentioned earlier, I prefer to start my testing sooner & I don’t mind if the feature is not 100% complete. In fact I find value in being able to test chunks of the feature as opposed to all of it in 1 go.
Who Says 3’s a Crowd?
A tool I’ve used to help me when testing sooner is closer working with Programmers & Business Stakeholders to help ensure we build the right thing in the first place. Julian Harty calls this “Trinity Testing” & George Dinwiddie calls it “The 3 Amigo’s”. I’ve spoken about it in more detail in this post
Advantages of testing sooner
A key advantage I’ve found of testing sooner includes faster feedback, with the Business Stakeholders when agreeing what the thing is or with Programmers who wrote the code minutes or hours ago as opposed to days or weeks ago. To the Business, this speedy feedback enables to make crucial decisions sooner. Dare I say it helps them to pivot if needs be?
Other advantages include less time in an integration environment (as the majority of functional bugs should have already been found) & better communication - people actually talk to each other as opposed to long email chains where the original context may easily get lost & information gets mis-interpreted.
I’ve also found testing out of an integration helps to provide more accurate estimates (if that’s what you have to do). You are not waiting for a release to an integration environment, or for that environment to be available. If you find a bug testing in a dev environment, bugs can be turned around quicker - you don’t need to pull the build out of a dev environment like you may have to an integration environment. So 3 days test effort = 3 days, rather than 3 days test effort over 7 days due to waiting for an environment or multiple releases to that environment.
Here’s a quick mindmap I put together when preparing for the session outlining some of the advantages I’ve noticed to my testing:
Several people have commented that it appears that the Programmers will get lazy as they believe the Testers will clear up after them. I have found the opposite to be true; I am having conversations with the Programmers in their language, earning their respect & building rapport. With a joint understanding of the thing being developed & the reasons why, we have a common goal which we both want to achieve. It is a lot less us & them.
Finally
I found another context for my metaphor - cooking a meal at home for your family:
It’s Sunday & your folks are visiting for the weekend. You are preparing a meal for 6 (if you include your wife & 2 kids). You take time peeling & chopping the potatoes, preparing & steaming the veg and hours basting & cooking your meat of choice.
After a 3 hour marathon in the kitchen, you serve up your food to be greeted with quizzical expressions, disgruntled moaning & reluctant forks pushing peas around the plate.
What do you say? I know what I’d say:
“If you think you can do any better, get in the kitchen & do it yourself!”
