In my last blog post, I discussed “standard work”, gave some examples of it, and explained why it is important. Standard work often helps within a team, but what about across teams? The next step is to make sure we are communicating efficiently with those at each end of our point in the value chain. I think we’ve improved this first order of communication on most of our agile teams, but that there is probably more room for improvement, and there is definitely room for improvement both further up and down the value chain. Agile Testers probably have more insights into these issues than many other members on the team. Ideally, we are communicating with all of the programmers, product owner, and end customers. Usually we work better on the first two of these than with our actual end customers. This disconnect and how to improve it is the topic of this post,
I believe any Agile Tester will look as far up and down the value chain as visibility and time allow on their projects. We work closely with product owners to make sure features for our current iteration is clear and that in the end are implemented in a useful way. We create test cases for these features and add them to regression test suites. We hope the team’s implementation will meet the customers’ needs, but sometimes we’re still not sure whether we’ve “nailed it” correctly until the product succeeds or fails in the marketplace. I believe we can use our existing acceptance testing tools to a greater purpose in facilitating communication both up and downstream both within our organizations and outside to our customers and prospective customers.
I believe one of the biggest advantages with tools like FIT and Fitnesse is that we aren’t limited by the user interface into what we can test. This makes writing and automating testcases less work and allows testing to efficiently keep up with development. It also allows specification of more testcases at any time (including before, during, and after development). Testcases before development express the desired feature more richly and give developers a way to frame how their work is progressing. Testers and end-customers can add more detail to these tests in parallel with development, and can even add some “what-if” testcases after the fact to see if the program will support capabilities that were not thought of or communicate at the outset. This sort of flexibility means:
- Some important testcases that frame the problem concretely can be included in the user story at the beginning
- Testers are free to add additional testcases as they explore the feature
- If those accepting the feature think of more cases, adding them and seeing what happens is easy.
- Pre-sales teams are able to try additional testcases to see whether the product will meet needs of some new customer
- Customer support cases can easily be added to the mix in existing regression tests
I realize adding more testcases might seem like a scary thing to agile teams (or any team). I’ll counter by saying a smaller number of clear testcases in the beginning is more helpful in understanding the problem than an exhaustive set, but exhaustive sets of problems may exist in the field, just waiting to be found. Testcases should remain organized and understandable or they loose their value. They should be refactored into “equivalence classes” (a mathematical term) and sometimes they should even be refactored down into unit tests. My point here is that these testcases should serve as a communication tool. We hope that various domain experts will add testcases that matter to them and that such testcases will be shared and understood across the whole team.
Now I’d like to mention what prodded me to finally write on this topic. Rich Mironov (chief marketing officer at Enthiosys) gave a talk titled “Product Managers and Product Owners: Which Do We Need, and What Do They Do?” at Agile Bazaar’s February monthly meeting. Rich explained the difference between the job functions of product owners and product managers. Summarizing what he said: project owners are tightly integrated with an agile team while product managers are usually focused outward (both within, but more importantly, outside of the organization). They need to be evaluating business needs not only of existing customers, but also potential future customers. I never really understood the project manager job function very well, but some lights went off in my head as he described his duties. He showed about 21 different major areas of his job. I wasn’t concerned with all of these, but hearing him saying the equivalent of “you don’t get your testcases from enough places” rang very true with my experience. Rich’s talk was more focused on the role of the agile product owner, but I clearly saw a role for table driven functional testcases in facilitating the communication he said is often lacking.
I’ve also learned that I can amplify my effectiveness by writing programs that facilitate my daily work. If I can codify a body of knowledge for a task (think “standard work”) in a script, I can share the script with others and have them self-serve some of the requests they normally make to me. (The case that comes to my mind was copying selected images from the Helicsope DNA sequencers, but the general idea is transferable. I had to copy images as part of my quality assurance work, but other engineers needed these for advance scientific work and troubleshooting. By scripting this into standard work, others were able to see more and accomplish their jobs faster.) In essence, I was removing myself as the bottleneck in flows outside of my normal work, but important to the company.
We can use this same concept with Fitnesse testcases, but in this case, the collaboration among teams is much stronger (and two-way). Functional/Acceptance tests do not show the whole testing picture, but what they do show is important or more so outside of the development team than within. They communicate “intent” upstream and “behavior” downstream. Both of these are important, and they allow other stakeholders to determine both if the tests and the software under test are meeting their intended and actual needs. We need to use these tests as the communication tool they are meant to be. The effect will be software that better meets the needs of end-users and both internal and external stakeholders. Wikis are a great communication tool, and extending them with tests and sharing and improving these tests among the whole facilitates the communication issues I’ve addressed in this post. Agile Testers can greatly facilitate this communication by championing these tests within and across teams/stakeholders, and keeping the evolving testcases clean, documented, and understandable.
I’m interested in hearing your thoughts and experiences around these sorts of communication issues. Has this worked in your organization? Do you have additional ideas? Who do you see as the next set of stakeholders on each end of the value stream for your projects? Please share your thoughts and suggestions in the comment area of this blog post.
Sincerely,
–
Bob Clancy (http://agiletester.net)
