Friday, May 13, 2011

Working with Business Testers

From Nancy Kelln’s presentation at STPCon,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.

Thursday, May 05, 2011

Whatever In a Flash

If you enjoyed Agile in a Flash: Speed-Learning Agile Software Development by Jeff Langr and Tim Ottinger and were burning to create your own whatever-in-a-flash as a result, then here’s a template for you in Word 2010 format.

I print on card or cover stock and then if it’s low volume, cut it myself. For volume cutting, it’s easier to take it to a print shop with one of those guillotine cutters. For my 35-card stack of 15 sets, it cost me less than $5 for this service and it would have taken me hours to do myself…

Sunday, May 01, 2011

Strategy vs. Plan

The strategy survives multiple iterations, multiple releases, multiple projects for the same, albeit evolving, solution.

The plan implements the strategy by naming names, specifying dates, and identifying the risks that guide the investigation for that iteration or  release.

This way, we can use the lessons learned during each investigation to continually improve the strategy and not get lost in the concern about deadlines.