I got some positive response about DET that I wrote on my blog and in my CAST session proposal, so I thought I would elaborate a little on where I think this could be going. I will probably cover more hands on aspects in the coming weeks, but I really want to explain a vision I have around it first.
How about including the business stakeholders?
In my current project, I started to involve our main business stakeholders in our test sessions from the start when I got involved. And they have gotten really excited about attending once a week. So during the past weeks when we have had the focus on our mobile client we had groups of three testing together, server dev, mobile dev and stakeholder. So we are having deep product knowledge on both backend and frontend together with the business knowledge testing together.
Mission is important!
Groups get a prepared session notes template with a mission statement and the prerequisites for it. We also discuss around the mission to make it clear what is important for that group to explore during that session. Usually it has been about some area that needs specific bug-catching-sort of testing. By stating mission explicitly there is at least some chance that it will get somewhat covered. I have seen that if this facilitation and coaching is not done, business people are quite good at distracting their groups, just as developers that get excited about a specific feature they are testing and forget all about the rest of the mission.
Output of sessions
Apart from the shared understanding of the quality status of the product, the most obvious output of test sessions are bug reports of course. Depending on the setting, there are also other things that are found and discussed after the session. In the current project I found it valuable to put demand on the notes taken mapping to the specific issue types in our bug reporting tool Jira. This little change made some discussions even more valuable since we could have a more mature discussion about Bugs, Improvements, User Stories, and New features. I actually think we have great stakeholders in that perspective, since there is an understanding about not everything being bugs.
What have we achieved?
Everyone gets something out of it. Business people get to interact with the product together with the developers in a structured fashion. Developers get input on what the business people feel about the product. Feedback is direct and face to face, discussing the solutions and how stakeholders actually want it with a standpoint in what is in front of them. Everyone involved gets the feeling of what the quality of the product is at the moment. By creating this common understanding together with our business stakeholders we are also managing the expectations of quality to be shown at the demo.
The next step?
While we are having fewer and fewer bugs found during our sessions, I am considering ways of changing the types of test missions to fit into the status of the project. What value does it add to continue having test sessions regularly together in the team? Of course, we will still get the common understanding on product quality status and collaborative environment. But lets shift the focus forward. Why dont we let the whole team drive development further through carrying out exploratory testing sessions?
Introducing Exploratory Test Driven Development – ETDD
While some sessions still need to focus on testing the current product, consider shifting the mission focus sometimes. Let the mission at hand to be about finding as many future possibilities as possible and to recognize where the system is going in the future. As I pointed out above, business people in particular really like elaborating on current product in a wide fashion. Explicitly setting a mission like this also enables developers to relax about the current status and envision extensions of the product we are building.
What about Specification by example and the output?
Purpose of testing is to provide information for decision makers. This approach will certainly be hands on testing informing decisions in a direct way. But this time it is not forming decision about the past development, what you have now. Testing will inform decisions about the future, thus will be driving development on an even higher level than with specification by example. Gojko Adzic describes specification workshops in Bridging the communication gap, where the point is to go from user stories to more defined examples. He also speaks about design workshops that deal with user stories in the long perspective. Test sessions will not create usable examples, but rather be a way to elicit new user stories to build examples about later on. In reference to where Gojko describes the scope being derived from business goals, having business stakeholders involved in the feedback activity of a test session will make the scope derivation easier to grasp with the current product at hand. Testing will also give some input on current prioritization, in discovering which already known user stories need that soon need to be refined with examples.
I made a simple sketch of it through modifying this really nice picture of ATDD from Janet Gregory.
I would really appreciate some comments on this. I might be way off, but I really think that this is a possible way to go in my current project. And through analyzing the other projects in my organization I really see the potential of this type of stakeholder involvement possible.