escola superior aberta do brasil – esab pós-graduação em ...

Tanto a qualidade quanto os testes devem estar presente em todo o processo de
construção da aplicação, mas a qualidade se estende por todas as outras
disciplinas, sendo seu escopo mais abrangente em diversos aspectos se comparado
ao de testes.
O estudo da qualidade se aperfeiçoava por meio dos processos industriais (qua.2)
antes mesmo de se imaginar o conceito de software. O estudo dos testes de
software tem pouco mais de 50 anos, mas só começou a ganhar uma maior atenção
do mercado nos últimos 10 anos. Veja o quadro a seguir:
Quadro 1 – Histórico dos testes de software
1957 O teste de software torna-se um processo
1970 Com a engenharia de software aumenta a importância da disciplina de testes
1972 Ocorre a primeira conferência sobre testes na Universidade da Carolina do Norte
1979 Myers produz um dos primeiros trabalhos sobre o processo de testes
Primeiros conceitos de qualidade de software, criação dos padrões:
1980
•
•
IEEE (Institute of Electrical and Electronics Engineers)
ANSI (American National Standards Institute)
• ISO (International Standards Organization)
1990 Começam a ser desenvolvidas as ferramentas de teste
Fonte: Bartié (2002, p.3-4)
O interesse pela qualidade só começou a se intensificar devido ao crescimento
exponencial dos programas em linhas de código e também pelos níveis de
complexidade que estavam sendo alcançados a cada dia.
Quadro 2 – Evolução dos conceitos de qualidade
1900 Inspeção pós-produção Avalia o produto final, depois de pronto
1940 Controle estatístico da produção Avalia os subprodutos das etapas de produção
1950 Procedimento de produção Avalia todo o procedimento de produção
1960 Educação das pessoas Avalia as pessoas envolvidas no processo
1970 Otimização dos processos Avalia e otimiza cada processo
1980 Projeto robusto Avalia o projeto de produção
1990 Engenharia simultânea Avalia a própria concepção do produto
Fonte: Oshiro (2007, p.148-149)
A principio, técnicas foram utilizadas para separar os códigos em módulos menores,
mas em pouco tempo os analistas estavam se vendo envolvidos com centenas,
algumas vezes até milhares, de módulos que dificultavam a “visão do todo” (qua.3).
Com o tempo ficou difícil prever se uma simples alteração na funcionalidade de um
dos módulos, causaria problemas em cascata em outras.
16