Each 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
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… 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?
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.
0 comments on “Why not document software development projects?”