Evolving Approaches

One approach is “first I will build n then I will test n”. Test-last thinking. Replace “n” with feature/story/requirement/behaviour/system/minimum viable product/product as required for your context.

Another approach is “first I will describe/run tests for n, then I will build n”. Test-first thinking. Increasingly we’ve seen the benefits of evolving n towards meaning “behaviour” at both micro- and macro levels. Not surprisingly, words other than “describe/run tests” have been suggested, most notably “describe/run examples of” and “describe/run executable specifications for” the desired behaviour. The desired behaviour has been – I believe in most people’s minds – a characteristic of the system under development/test. Testers ask questions like “how will the system respond if I do (this)”?

Many testers stop here.

Let’s not stop here.

Another approach is “if I want to test n, then I will build m” and to extend the behaviour to things other than the system under development. Like people. Or any other part of the whole system.

Not-so-traditional test-first thinking and a subtle difference. We identify a behaviour that we want to test, and ask, given that desirable behaviour, what do I need to build?

• I want to test potential orders turning into real orders on my web site. What do I need to build? (good)
• I want more potential orders to turn into real orders on my web site. What do I need to build? (better)

The second is highlighted as (better) since it’s more specific and provides insight as to what measures/monitors might be required. We need the function to create a real order, we need the monitor, and third – implied – we need the ability to parameterize aspects of this capability so that we can continue to optimize and improve the real order rate on an on-going basis, and do that easily.

There’s a pattern to this: (capabilities, monitors, parameters).

I want more people to sign up to do volunteer work. What capability do I need to build? What monitors do I need to build? What needs to be parameterized so that we can continue to improve the capability?

I want field office personnel to stop using email attachments when sending completed work orders back to head office for billing. What capabilities, monitors, improvement parameters do I need to build?

This is where we need to apply testing skills. Use our agile testing skills for getting the capabilities to done-done. Use our analysis skills for getting the right measures and monitors in place. Use our test design and execution skills to run the experiments that get the feedback to the right people in a timely way. Use our test management skills to smooth over that whole nested set of feedback cycles.

Exciting times.