When a decision maker asks “When will testing be done?”, in my experience, she really means is “When will I have enough information about the state of the product and the project, such that I can decide to release or deploy the product?”
There are a couple of problems with the latter question. First, as Cem Kaner puts it, “testing is an empirical, technical investigation of the product, done on behalf of stakeholders, that provides quality-related information of the kind that they seek”. Yet the decision to ship is a business decision, and not purely a technical one; factors other than testing inform the shipping decision. Second, only the decision-maker can decide how much information is enough for her purposes.
So how should a tester answer the question “When will testing be done?” My answer would go like this:
“Testing will be done when you decide to ship the product.
That will probably be when you feel that you have enough information about the product, its value, and real and potential risks—and about what I’ve covered and how well I’ve covered it to find those things out. So, starting right now, I will learn everything I can about the product, as quickly as possible, and I’ll continuously communicate what I’ve learned to you.
As I test, I will no doubt discover problems and risks about the product that no one anticipated. So I’ll also help you to identify anything that you might consider important influences on your decision to ship.
I will base my first estimate on how long we have before you and the developers intend to ship the product. I will continue testing throughout. If you decide to change that date — earlier because the product is looking startlingly good, or later because the product has problems that require resolution — I will abide by that.
If you’d like me to keep testing after deployment (for example, to help technical support), I’ll do thaIt too.
Testing will be done when you decide that you’re satisfied that you need no more information from testing, whereupon you’ll decide to ship, or delay, or cancel the project.”
That’s your very (or at least pretty) short blog post. For more, see:
“Test Estimation is Really Negotiation“
Test Project Estimation, The Rapid Way
Project Estimation and Black Swans (Part 5): Test Estimation: Is there really such a thing as a test project, or is it mostly inseparable from some other activities?
Got You Covered: Excellent testing starts by questioning the mission. So, the first step when we are seeking to evaluate or enhance the quality of our test coverage is to determine for whom we’re determining coverage, and why.
Cover or Discover: Excellent testing isn’t just about covering the “map”—it’s also about exploring the territory, which is the process by which we discover things that the map doesn’t cover.
A Map By Any Other Name: A mapping illustrates a relationship between two things. In testing, a map might look like a road map, but it might also look like a list, a chart, a table, or a pile of stories. We can use any of these to help us think about test coverage.
Testing, Checking, and Convincing the Boss to Explore: You might want to take a more exploratory approach to the testing of your product or service, yet you might face some difficulty in persuading people who are locked into an idea of testing the product as “checking to make sure that it works”. So, some colleagues came up with ideas that might help.
[…] Blog: Very Short Blog Posts (13): When Will Testing Be Done? – Michael Bolton – http://www.developsense.com/blog/2014/03/very-short-blog-posts-13-when-will-testing-be-done/ […]
[…] When Will Testing Be Done? Written by: Michael Bolton […]
[…] Michael Bolton blogged about shipping projects and test cases this week also. […]