SMART testing isn't smart

SMART is still around us: things we do has to be specific, measurable, assignable, realistic and time-related. All ingredient managers uses to get control of what is going to happen in the future. We all have written test plans for managers because they wanted to know: how many tests are you going to do and you need to predict the outcome so you can check if it is correct and of course how much it will take to perform all these activities. And these activities have to result in SMART defined results.

But aren't you not trying to predict the future?And control of the future, isn't that impossible? Yep it is and if you are talking about testing, this is even more the case! Because aren't we looking for information as testers to see if the product is good enough for our customers? And while looking at this information we can (and will !) find things that are not acceptable!? So we have to guard that too low quality products doesn't goes out. But do you know at the beginning what you will encounter? Of course not, but you need to know where to aim for: a system that in the ideal situation has value and/or will solve a lot of problems for someone out there. But the road to that situation can be covered with bugs, wrong interpretations, problems to be solved and tools to help you testing which needs to be developed, etc. etc. All kind of criteria you cannot predict: what will happen and how long it will take?

But this is unacceptable, that big goal, everyone is aiming for, must be delivered 'some time' and we can't wait for tester who can't tell when they are done?!

That is the reason why you have to outsmart SMART and use a more realistic approach: BSL which stands for "Big Achievements, Small steps, Logical flow". An approach I found on this Dutch website (sorry although I understood the approach comes from the US Navy) and I found this approach very applicable for testers:

Testers should have thought about a plan: based on the Big Achievement: working software. And as testers we need to understand the purpose of the working software: Which problem is going to be solved for the users/customers and when do our stakeholders find the quality 'good enough', have they thought about acceptance criteria? But acceptance criteria is not enough, we should also be aware of the threats to create that big achievement, the negative value we need to avoid which we mostly call, "risks'. Those (product)risks are fluid: every action, every line of code can continuous influence the likelihood and impact of the risks we identified or haven't identified yet. So we have to create of an agile environment; gathering enough information (over and over again) we can decide what the next small step should be: based on which risk has the highest importance. And that importance can or even, must be based on a logical flow. This means that we as tester must think (upfront) about testability! Testability defines how we want to eat the elephant (Small steps). And thinking about testability is a team effort in which a product owner needs to be involved: e.g. if we need to change the order of user stories so that for example testing is less complex or specific (test)data can be injected easier. This will define the logical flow you want to follow as a team to get things done. And of course, the route of your teststeps can be rerouted if you find interesting information: information that needs to be analyzed or information which means that software needs to be adjusted or information that reveals new risks which needs to be researched.

As testers we know that looking for the unknown unknown is our destiny but sometimes hard to understand for people around who look for certainty (utopia) but we have to find each other in the middle. So SMART doesn't help us (we can not predict the future) while BSL gives us a direction; we can explain what we are doing and BSL gives us agility. Because as every one testers also like to ship the software or product to production, but within acceptable risks (as far as we know ;-) )