Teste de software

Teste de Software e Melhoria de Processos por Mauricio Aguiar
Foi no início da década de 80 quando, pela primeira vez, deparei-me com um problema que exigia uma abordagem estruturada para o teste de software. Nossa equipe vinha desenvolvendo, havia mais de um ano, um sistema que seria distribuído a 32 clientes, que utilizavam diferentes tipos de mainframe - IBM com MVS, IBM com DOS/VS, Burroughs, etc. Isso foi antes da revolução do IBM-PC, da arquitetura cliente/servidor e, é claro, da web.
O desenvolvimento do sistema, que iria substituir aquele utilizado por nosso clientes, tinha sofrido os usuais atrasos, decorrentes de estimativas incorretas, mudanças de gerentes, de analistas, dificuldades técnicas, mau gerenciamento de projetos (ainda não existia o PMI) e tudo o mais que, infelizmente, contribui até hoje para que os projetos de TI continuem a desafiar os prazos.
Agora estava chegando o limite de atraso suportado pelos clientes e, finalmente, o sistema teria que ser entregue e implantado. Nós sabíamos, contudo, que as condições sob as quais o desenvolvimento havia sido efetuado eram totalmente incompatíveis com o nível de qualidade requerido pelos usuários e pela natureza do sistema. Surgiu a idéia de realizar um teste abrangente do sistema, com a finalidade de identificar e sanar todos os erros que suspeitávamos ocultos sob os milhares de linhas COBOL. Como nossos recursos eram limitados - principalmente o tempo - era preciso algum critério para uma alocação ótima desses mesmos recursos.
Estávamos na época da Revolução Estruturada, quando nossos gurus eram Yourdon, Constantine, DeMarco e Page-Jones, autores dos primeiros livros sobre análise e projeto estruturados. Um outro pesquisador contemporâneo dedicara-se ao teste de software: Glenford Myers, autor de The Art of Software Testing [MYER79], hoje um clássico que pode ser adquirido na Amazon.com pelo salgado preço de US$ 97.00. Busquei auxílio na obra de Myers e produzi uma pequena apostila. Com