Exploratory testing and documentation
First published 30/06/2011
Scale, extended timescales, logistics, geographic resource distribution, requirements/architectural/commercial complexity, demand for documented plans and evidence are the gestalt of larger systems development. “Large systems projects can be broken up into a number of more manageable smaller projects requiring less bureaucracy and paperwork” sounds good, bur few have succeeded. Iterative approaches are the obvious way to go, but not many corporates have the vision, the skills or the patience to operate that way. Even so, session-based/exploratory testing is a component of almost all test approaches.
The disadvantages of documentation are plain to see. But there are three apsects that concern us.
- Projects, like life never stand still. Documentation is never up to date or accurate and it's a pain to maintain – so it usually isn't
- Processes can be put in place to keep the requirements and all dependent documentation in perfect synchronisation. The delays caused by the required human interventions and translation processes undermine our best efforts.
- At the heart of projects are people. They can rely on processes and paper to save them and stop thinking. Or they can use their brains.
Number 3 is the killer of course. With the best will and processes and discipline in the world, all our sources of knowledge are fallible. It is our human ability and flexibility and dare I say it agility that allows us to build and test some pretty big stuff that seems to work.
Societal and corporate stupor (aka culture) conspire to make us less interested in tracking down the flaws in requirements, designs, code, builds and thinking. It is our exploratory instincts that rescue us.
Tags: #ALF
Paul Gerrard My linkedin profile is here My Mastodon Account