From Nancy Kelln’s presentation at STPCon, “Leading Business Testers”, business testers:
- are not testers
- do not want to be testers
- require guidance and support
- require their expectations to be managed
- may be working part-time on the project
and all of these things need to be considered when creating the test strategy/approach on a project that will utilize them.
My last two projects as QA/test lead launched for 3500 and 7500 users respectively, and I can say that we only used a smattering of professional testers on those projects (not counting the professional testers that might have been working for the vendors). The end-of-cycle testing was all done by business testers, that is, people that would be classified as full-time end-users of the solution.
I can add the following to Nancy’s list:
- business testers tend towards happy-day scenarios; adjust your coaching so they get a sense of what exploring means
- avoid technical testing terms like boundary value analysis, equivalence class partitioning, etc. in your coaching; introduce the concepts but using examples
- removing obstacles to their testing is critical, especially since they rarely differentiate between a test environment problem and a problem with the solution – it’s all the same to them
- you can use session-based testing and call sheets as a way of managing part-time testers; a call sheet tells them what to investigate, when and gives them space to report back in. I populate the call sheets with items from a main checklist everyone is working from.
- as a test lead, avoid becoming a test enforcer – you won’t be able to convince them to test in a timeline that actually helps you. Instead, make them aware that they are driving the investigation in their area and that how much they test is their decision; then communicate, communicate, communicate what they have told you and what they end up doing.
- business testers can absolutely use exploratory testing even in projects with stringent audit and control requirements; you do need to state that this is the process you will follow, and then be able to demonstrate that you followed that process. You will need to instruct the testers on what evidence they need to gather for you.
- another risk is what I refer to as cloister vision – the business testers get too good at using the system under test and are no longer adequate proxies for the end-users that will soon be required to adopt the solution; mix it up a bit if you can. A core of business testers is a good idea when they are providing test data for downstream workflows but for investigating solution adoption concerns, work with the training people to get some additional testers that have been trained on the solution involved so that you can observe the “unboxing” first-hand.
That last one – cloister vision – was largely responsible for go-live complications that involved call centre software. Yeah. My customer’s customers noticed, and that hurt, big-time. It’s why I keep writing about solution adoption considerations and have started using “deployment is not done” as a mantra.
