69.3%, OK?

The Association for Software Testing is crowd-sourcing a book, Navigating the World as a Context-Driven Tester, which aims to provide responses to common questions and statements about testing from a context-driven perspective.

It's being edited by Lee Hawkins who is posing questions on Twitter,  LinkedIn,  Slack, and the AST mailing list and then collating the replies, focusing on practice over theory.

I've decided to contribute by answering briefly, and without a lot of editing or crafting, by imagining that I'm speaking to someone in software development who's acting in good faith, cares about their work and mine, but doesn't have much visibility of what testing can be.

Perhaps you'd like to join me?

 --00--

"What percentage of our test cases are automated?"

There's a lot wrapped up in that question, particularly when it's a metric for monitoring the state of testing.

It's not the first time I've been asked either. In my experience, it comes when someone has latched onto automating test cases because (a) they've heard of it, (b) test cases are countable, and (c) they have been tasked with providing a management-acceptable figure for the "Testing" value in a Powerpoint deck of several hundred slides mailed monthly to a large number of people who will not look at it. 

If that sounds cynical ... well, I suppose it is. But any cynicism over this particular measure doesn't mean I'm not interested in understanding your need and trying to help you get something that fulfils it. Can we talk about what you're after and why?

We can? Great!

I'll start. Some of the issues I have with the question as it stands are:

• it seems to be perceived a measure of our testing
• such a number would say nothing about the value of the testing done
• the definition of a test case is moot
• ... and, whatever they are, test cases are only a part of our testing
• there's an implicit assumption that more automation is better
• ... but automation comes with its own risks
• ... and, whatever automation means, automated test cases are only a part of our test automation

If I look at how we test, and what we might call test cases, I can think of three ways I could answer your question right now:

1. We don't have test cases in the sense I think the question intends. All of our ongoing testing is exploratory and, while we might document the results of the testing with automation, there is no sense in which a manual or scripted test case existed and was then automated. We score 0%.
2. For the purposes of this exercise, I would be prepared to describe each assertion in our regression test suites a test case. As they would be our only test cases, all of them are automated. 100%!
3. OK, we do have some items in a test case management system. These are historical release-time checks that (mostly) people outside the test team run through before we ship. I like to think of them more as checklists or jumping off points, but I'm realistic and know that some of my colleagues simply want to follow steps. Relative to the number of "automated test cases" there are few of them but if we include them in our calculation we'd bring the score down to, say, 99%.

Those answers don't seem very satisfactory to either of us do they? 

To me, at very best, this kind of metric covers a small slice of what we do and the assumptions underlying it are very questionable. To you, the metric matters less than some plausible number representing how well the testing is going to include in that monster Powerpoint deck.

I have some thoughts on that too:

• testing, for me, is knowledge work and so notoriously hard to measure in simple numbers
• testing does not exist in isolation from other product development activities
  
• good testing can be done without the creation of artefacts such as test cases
• metrics imposed without conversation and justification are likely to be viewed with suspicion
• metrics are likely to be gamed when (perceived to be) used as a target, or to judge
• starting with a list of artifacts (test cases, bug tickets, etc) is cart-before-horse
• ... it's much better to ask first what you want to measure and why
  

So, for example, is the desire to measure customer satisfaction with the product? Is it to measure the testing contribution to that? Is it to see where time is being spent on certain kinds of activities that the business wants to stop? Is it to look for bottlenecks? Or something else?

If we do agree some kind of metrics, how can we reassure testers that they are not being judged, and that they should not pervert their working practices just to make the numbers look good?

We'll need something more than glib words.  Imagine you were told your performance would be judged on how many emails you sent. How would you react? Would you scoff at it but send more emails anyway? Would you send emails instead of having conversations? Would you care about the potential detrimental effects to you, others, the business? How could someone convince you to behave differently?

Finally, is there a real desire from you to look into sensible metrics with good intent and to act on the findings?

If so, then I will do all that I can to assist in getting something that is justifiable, that has explicit caveats, that is equitable, that is transparent, that acknowledges the messiness involved in its collection, that can be derived efficiently from data that we have, that sits within agreed error margins, and that reflects the work we're doing.

If not, then I'll ask you what kind of number will pass the cursory level of inspection that we both know it will receive, and I'll simply give you that: let's say 69.3%, OK?