Um dos problemas existentes com a documentação de sistemas é que esta documentação é uma representação simbólica. Apenas o código é a documentação verdadeira do que o software faz (executa).
É comum a documentação ficar obsoleta, pelos mais diversos motivos que ocorrem em projetos de desenvolvimento de software. Um dos males desta desatualização da documentação é que ela pode levar a entendimentos errados do que o algoritmo esta programado a executar. A muito se ouve a frase: Pior que a inexistência de documentação é a documentação que esta desatualizada.
Eu tenho aplicado junto a equipe de teste de software a materialização da documentação em testes automatizados, onde o teste automatizado realiza a execução de cenários principais e alternativos dos requisitos implementados. O teste passa a ser a documentação do sistema e neste caso eu não estou falando de testes unitários e sim testes de funcionalidades.
Eu tenho utilizado em meus projetos a ferramenta Selenium, que permite a captura da interação humana com o sistema e materializa em um script que pode ser executado de maneira automatizada.
Cada teste do Selenium capturado e adicionado ao projeto recebe um cenário de execução explicativo, em forma de JavaDoc (Pode ser RubyDoc, PHPDoc, etc).
Quando desejamos saber o que um domínio forte de informação faz, basta abrirmos os testes que ele possui. Cada domínio possui um conjunto de classes de teste, que representam as regras e comportamentos esperados deste domínio.
Para que o entendimento destas regras não fique em algoritmo, o que é restritivo para o entendimento de profissionais não familiarizados com algoritmo é criado métodos com o nome o mais próximo possível a funcionalidade esperada e o cenário de execução da funcionalidade.
Um exemplo de como representamos este cenário de execução é:
O ator faz...
O sistema faz...
O ator faz...
O sistema faz...
O sistema faz...
Com esta técnica podemos gerar a qualquer momento um relatório com as funcionalidades que um domínio possui e ainda executar estas funcionalidades para saber se os resultados obtidos são os resultados esperados.
Sempre que realizamos uma manutenção corretiva ou evolutiva em uma funcionalidade do sistema, podemos provocar efeitos colaterais a outros módulos do sistema. A única maneira de saber se estes efeitos indesejados provocaram um efeito colateral ao sistema é a realização dos testes necessários.
Com esta técnica de captura de testes pelo Selenium, nos podemos realizar testes de regressão a qualquer momento.
A nova funcionalidade deve ser registrada nos programas de teste, para que os algoritmos de testes de software mais os textos explicativos fiquem em conformidade ao algoritmo testado. É software testando software e a documentação explicando o que esta sendo testado.
Como os algoritmos de testes são pequenos, ate mesmo um cenário desatualizado fica de fácil entendimento pela equipe de TI, permitindo a sua correção. O esforço de uma correção de um cenário de teste é bem menor que o esforço da correção de uma documentação mais abrangente, pois podemos rapidamente validar se o algoritmo de teste faz o que ele deveria fazer, ao contrario de uma documentação mais abrangente como um Use Case.
Este post fica como uma lição aprendida minha.
Abraços,
Abu
Obs.: Muito obrigado pela ajuda Dona Patroa (Neilza)
Postagens
Um comentário:
Olá Abu.
Existem outras formas de fazer com que a documentação do sistema represente sempre O QUE o sistema faz. A que mais gosto é MDA, que faz com que a documentação passe por um processo de 'compilação'. E para quem nao gosta de UML, MDA não precisa necessariamente se basear nela.
Em minha opinião a boa documentação envolve MDA + TDD.
[]s
Postar um comentário