Starting a project seems to be one of the most under-rated steps when it comes to describing critical success factors for projects. A project well-launched is like a well-designed set play that comes together on the field during a game. It’s not launch effort but launch effectiveness that is important. In Agile Testing and Quality Strategies: Discipline Over Rhetoric Scott Ambler specifically describes requirements envisioning and architecture envisioning as key elements of initiating a project (he specifies this for launching an agile project, and I’ve come to believe now that it’s true for any project with stakeholders).
In a classic standing on the shoulders of giants manner, “yes, and” … we could also spend some of that project initiation time envisioning what the testing is going to look like. It is Iteration 0, after all so there is a large landscape of possible conversations that we could have. And increasingly I’ve seen misconceptions about how the project testing will be conducted as one of those “wait a second” moments. People just weren’t on the same page, and they needed to be.
It’s a fundamental part of the working agreement that Iteration 0 is intended to create – who will test what, when? Will the developers use test-first programming? Will they also use higher level test automation such as one of the BDD tools? Will they do build verification testing beyond the automated tests? If the solution provider is a remote, out-sourced team, what testing will the solution acquirer organization do? When will they do it? How will they do it? Will they automate some tests too? Is there formal ITIL release management going on at the acquiring organization that will demand a test-last acceptance test phase? Will the contract require such testing?
You see my point. There are a lot of alternate pathways, a lot of questions, and it’s an important conversation. Even if some of the answers are unknown and require some experimentation, at least everyone should agree on the questions. Context matters.
I come back to the point about test envisioning. The result of such envisioning is a working agreement on how testing might be conducted. That working agreement might well be called a test strategy, albeit a lean one. That’s why I promote it as a poster first, document second (and only if it helps to resolve some communication need). What you put on that poster is driven by what conversations need to take place and what uncertainties exist.
To build on Scott’s description of Iteration 0 then, the work breakdown structure for Envisioning may include the following:
Iteration 0: Envisioning
- Requirements Envisioning
- Architecture Envisioning
- Test Envisioning
and the result might very well be three big visible charts – one for each. Talking about testing upfront lets everyone listen, understand and contribute to the mental model melding that must take place for the team to be effective.
