One Test Case is All You Need

[Originally on Ministry of Testing, November 20, 2013: One Test Case is All You Need. Reposted from the web archives]

When good enough is the perfect fit

Similar to scope creep we may also experience “test creep“. Test Creep is when the tester adds more tests than what is in scope. Just as well as more business functionality is added during scope creep, more testing is added in test creep. Both aren’t necessarily bad, but in time-boxed or similar (budgeted) constraint projects creeping isn’t necessarily value adding. This is probably easier to understand in an agile project focusing on minimal viable product , but may happen in other contexts too.

It is test creep, when the tester feels an obligation to run an extra drill down into browser and OS configurations, when scope is less broad. It is creeping the scope of testing, if the testers feels a “/need/ to write testcases for this first” when exploratory sessions fits the mission. Consider test creep like gold plating, in that way that it tries to refine and perfect the product – when good enough is the perfect fit.

Test creep can happen intentionally, happen by management or by product owner request. It may happen unintentionally, and usually it is with the best intentions – as more testing always is better testing – right? (But it Depends) Sometimes yes, we as testers are to blame that we add more scenarios, rigor and details, because a testing mindset drives us to investigate the product.

In discussing this with Mohinder and Darren, we found that – it’s not only a matter of removing wait time for testers. This may add more time, to test but the scope creep in testing may happen none the less. A Lean mindset with focus on what adds value to the business and a discussion on the minimum viable testing will assist the project in avoiding test creep.

 

To scale even agile needs governance

Key takeaways from [ “Why Agile doesn’t scale, and what you can do about it” | Dan north (@tastapod) | GOTO Aarhus 2013 ] If you want the full version see the full slide deck here.

Being agile is about getting something out the door – it’s very good in doing SHIP IT – Tweak it – think it build it. Wax on – wax off. Being agile is about people and tools  and is a great approach for problems that allows to be solved with these borders.

The challenge is in the more complex  domains with a bigger solution, a bigger problem, a bigger program with many people, many dependencies, many teams. In these (NP?) problem domains other factors come into play: Governance, Customers, Money and the organization as a whole (see slides regarding Agile Adoption Patterns).

In the later contexts agile as a delivery model doesn’t scale without project governance and portfolio management to oversee and prioritize based on strategic returns on investment. Shipping any minimum viable product from time to time in a larger context requires more oversight on “are we nearly there?” “are we ensuring delivery?” “are we ensuring credibility?” .. are the many global teams going agile in each their direction?

The same goes for the testing efforts – agile scales to a certain point, and at that point the scrums, the state-models and so on are a part of the solution engine. It’s what’s tests something, but with size comes the need to know why we make the decisions we make – and  are we there yet?

Disclaimer: GOTO Aarhus 2013 is sponsoring my attendance as a blogger.