Why not document software development projects?

Jose_Luis_AntonEach time I visit a new client to offer our QA and Testing services, I get the same answer: “we don’t keep track of our systems; our business specialists are the ones who know how it works”. We were ready to present Testing solutions (such as the Model Based Testing, Automation, etc.) that would reduce costs, time or production mistakes, and now we have to go back to basics.

Our clients know our testing services aim at spotting errors, as early as possible in the development lifecycle and thus improve internal processes and eventually the quality of their products. But where should we start when there is no documentation available? The usual way to deal with this kind of situation is the “reverse engineering” approach that testers are familiar with though that is not always clearly stated as part of their work and that has them develop a deep understanding of how the system works. Why then wouldn’t we go one step further?

Why not building an environment that would automatically assist us during the testing phase for iterative generation and ongoing validation of functional models and system documentation based on the tests? This way, we would have something to answer when our clients give us the traditional ‘no documentation’ answer: ‘we generate and validate your system documentation and we use it for our advanced testing technics such as the Model-Based Testing, while taking full advantage of their potential.’ Not to mention improvement of the general communication among team members, and not only the testing team…

José Luis Antón


Jose Luis is currently the Director of the Testing Practice within Sogeti Spain, being responsible for defining technology and solution strategy and helping organizations designing and realizing their future strategies around QA and testing activities. He is part of the Spanish ISTQB Board.

More on José Luis Antón.

Related Posts

Your email address will not be published. Required fields are marked *

9 + 6 =

  1. jos punter October 9, 2013 Reply

    Really like your way of thinking. The software on production environment is the reality and suits the best to create “documentation” in some way. How would you tackle the problem if there are bugs found on the production environment ? Is the bug or error that what you document or is it something you adress later on ?