Professional Documents
Culture Documents
Resumo
Os métodos usados para testar software evoluíram à medida que os sistemas tornaram-se
maiores, mais complexos e destinados a variados ambientes. Os testes passaram a ser
executados por equipes especializadas e as empresas criaram áreas dentro da sua estrutura
organizacional para cumprir esse papel. Passamos a ter projetos e processos de teste, que
como tal são passíveis de melhorias. Há diversos modelos de maturidade de teste,
entretanto o autor os considera desnecessários, propondo que seja utilizado o MPS.BR
como modelo de maturidade e explicando como cada processo se aplica em uma unidade de
teste de software.
Introdução
Até a década de 90, quase todas as empresas ou organizações que desenvolviam software
tratavam o teste como uma atividade inserida no ciclo de vida do desenvolvimento. Quando
o software terminava a etapa de construção ele passava para a etapa de teste. Os testes eram
executados pelos desenvolvedores e em algumas situações pelos usuários. Os primeiros
faziam o que atualmente chamamos de teste unitário e teste de integração e os segundos
executavam o teste de aceitação. Os desenvolvedores testavam se a aplicação estava
funcionando e os usuários se ela atendia aos seus requisitos. Esse modelo servia
adequadamente, mesmo com ressalvas, desde que os primeiros computadores foram
instalados. O advento da Internet e das aplicações para ambiente web, tornaram os
softwares complicados e difíceis de serem testados. Uma aplicação pode envolver centenas
ou até milhares de componentes, além de ter que funcionar em diversos ambientes, muitos
deles completamente heterogêneos. Os desenvolvedores e os usuários não conseguiam mais
garantir que uma aplicação tinha sido suficientemente testada para ser liberada para a
produção. Alguns defeitos passaram a aparecer quando as aplicações estavam em produção,
justamente quando a sua correção é mais cara. Os custos de manutenção aumentaram e a
qualidade caiu a níveis inferiores ao das décadas anteriores. O escopo dos problemas
causados pelos defeitos deixou de ser restrito ao ambiente da empresa e envolvia o próprio
negócio da empresa.
Apesar desta realidade ainda permanecer na maioria das empresas até os dias atuais, foi em
1979 que Glenford Myers publicou aquele que atualmente ainda é considerado um dos
melhores livros de teste de software existentes no mercado, sob o título de “The Art of
Software Testing” (publicado por John Wiley and Sons Inc. em edição revisada em 2004).
Este livro continua sendo a bíblia de muitos dos testadores do século 21. Myers
basicamente lembrava que testar era procurar defeitos e não provar que o software estava
funcionando. Com isso estava quebrando um paradigma que já existia e continuaria a
existir durante muitos anos.
Um artigo publicado na revista Communications of the ACM sob o título “The Growth of
Software Testing” (Gelperin, D. and B. Hetzel. “The Growth of Software Testing.” -
Communications of the ACM 31 (June 1988): 687-95), escrito por David Gelperin e Bill
Hetzel, descrevia um processo de evolução dos testes e lançava um documento que chamou
de Plano de Testes. Esse documento, base de todas as metodologias de teste que usamos
hoje em dia, segundo o artigo citado, deveria ser escrito a partir dos requisitos do sistema e
por si só já ajudava a reduzir a quantidade de defeitos dos sistemas, dando aos testadores os
objetivos a serem alcançados durante a atividade de teste. Isso nos leva a uma conclusão
óbvia, que reporta à existência do documento Plano de Testes há mais de 20 (vinte) anos,
ainda que a popularização do seu uso seja mais recente.
Embora desde a década de 70, como vimos nos parágrafos anteriores, já existissem
trabalhos mostrando que o teste precisava ser re-estruturado, essa mudança só começou a
ocorrer de fato no final da década de 90. Decidiu-se então tratar o teste de software não
mais como uma atividade do processo de desenvolvimento, mas sim como um processo
independente. Desta forma o teste passaria a ser executado por uma equipe de especialistas
com o objetivo de diminuir o número de defeitos que estavam sendo passados para a
produção. Essa solução vem sendo gradativamente adotada pelas empresas, com os
resultados esperados, qual seja, softwares com índices de qualidade melhores. No entanto
essa mudança organizacional inesperada, e ainda não completamente absorvida, trouxe
também novos problemas a serem tratados. Não adianta apenas testar, mas sim testar bem.
Os custos podem cair na etapa final, mas inicialmente os investimentos são maiores. Se a
área de teste não estiver bem organizada os defeitos vão continuar a ocorrer num estágio
onde os custos são maiores. Cogitou-se então em modelos que permitissem à área de teste
de software atingir níveis de maturidade, melhorando, desta forma, os resultados esperados.
A lógica passou a ser a seguinte, além de implantar a área de teste de software, que por si
só trará resultados imediatos, ainda vamos criar um processo de melhoria contínua, com
resultados cada vez melhores.
Alguns desses modelos partiram do CMM e depois foram adaptados ao CMMI, porém
apesar desse pressuposto, possuem atualmente, pouca ou nenhuma ligação com eles. Se
tomarmos como exemplo o TMM, cuja base original é o CMM, mas a equivalência é hoje
muito pequena. Ou seja, ficaram a separação por estágios e talvez nada mais.
2 Fase de definição
3 Integração
4 Gestão e medições
Tabela 1
A busca por modelos alternativos surgiu porque os técnicos entenderam que modelos
pesados como o CMMI não serviam para a área de teste em razão de o seu tamanho ser
muito menor do que o da área de desenvolvimento. O MPS.BR surgiu no Brasil para
atender as empresas desenvolvedoras de software com uma estrutura menor. O que vamos
mostrar neste documento é que não há necessidade de buscar um modelo alternativo para
testes, pois eles terão um grande problema para se impor no mercado, principalmente
devido a grande quantidade de modelos que foram surgindo no decorrer dos anos. A melhor
solução é usar o próprio modelo adotado pelas áreas de desenvolvimento de software.
Quando uma empresa alcança o nível G, por exemplo, a área de teste poderá atender aos
processos de gerência de projetos e gerência de requisitos. Ou seja, a área de teste também
poderia ser credenciada nesse nível, desde que também mostrasse as evidências de que
estaria usando esses dois processos. Alguma dificuldade poderia surgir nos momentos em
que a área de teste resolvesse buscar um nível acima da área de desenvolvimento, e isso
será discutido neste documento.
Para facilitar o entendimento vamos analisar cada um dos níveis do MPS.BR e mostrar
como a área de teste poderia também ser implementada no mesmo nível,
independentemente da área de desenvolvimento estar ou não nesse nível. Evidentemente, se
ambas caminharem juntas, o custo da preparação será muito menor.
Nível G
Os mesmos requisitos que servem para desenvolver o software também servem para criar
os artefatos de teste, inclusive com uma ressalva, pois muitas empresas ainda produzem
requisitos de teste a partir dos requisitos do usuário. Devemos aceitar que a área de teste
precisa de uma gerência de requisitos.
Nível F
A área de processo de Aquisição com toda certeza pode ser usada pela área de teste pois os
seus projetos envolvem aquisições, principalmente na parte de automação específica. De
qualquer forma essa também não é uma área obrigatória.
Cada projeto de teste de software produz inúmeros artefatos, tais como Planos de Teste,
Procedimentos de Teste, Casos de Teste e diversos Relatórios de Teste. Nunca é demais
lembrar que os casos de teste podem chegar aos milhares num único projeto, e, além disso,
devem ser passíveis de reastreabilidade a partir do requisito. Não temos nenhuma dúvida
que a gerência de configuração deve contemplar a área de teste.
Não existe uma distinção sobre quem está cumprindo os processos mas sim se os processos
estão sendo cumpridos, o que nos leva a concluir que essa área também atende aos projetos
de teste de software.
Sabemos que um ativo reutilizável é qualquer artefato relacionado a software que esteja
preparado ou empacotado para ser reutilizado pelos processos da organização. A definição
é bastante abrangente para cobrir também os artefatos criados pelos projetos de teste de
software. Um bom exemplo para isso é a possibilidade de criarmos um banco de Caso de Teste
(Validação de CPF, Campos Obrigatórios, Validação de data e etc..) para reutilização em outro
projeto.
Nivel D
Este talvez seja o nível mais difícil de ser entendido pela área de teste de software, pois
possui algumas sutilezas que iremos discutir adiante. Não há dúvida que a área de
Desenvolvimento de Requisitos é importante também para os projetos de teste de software.
A elicitação dos requisitos de teste, aqueles que serão usados na elaboração dos testes, é um
trabalho que com toda certeza vai envolver a gerência e o desenvolvimento dos requisitos.
Por outro lado, convém lembrar que a mesma área de processo poderá suportar os projetos
de desenvolvimento e os projetos de teste de software, e que, muitas vezes, uma
caracterização mais específica dos requisitos deverá ser utilizada.
Nivel C
Nivel B
O nível B exige as seguintes áreas de processo:
Gerência de Projetos (evolução)
Nivel A
Conclusões
De todas as áreas de processo avaliadas e estudadas apenas três delas poderiam gerar algum
tipo de discussão quanto a sua aplicabilidade à área de teste de software que são as
seguintes:
Integração de Produto
Validação
Verificação
Bibliografia:
Rios, E. & Moreira T. Teste de Software. Rio de Janeiro, AltaBooks, 2006.
Institute of Electrical and Electronics Engineers, IEEE Std 829, Standard for Software
Testing Documentation, Nova Iorque, IEEE Computer Society, 1998.
Rios, E. Análise de Riscos em Projetos de Teste de Software, Rio de Janeiro, AltaBooks,
2005.
Pol M, Teunissem R, Veenendaal E. Van. Software Testing: A guide to the TMap
Approach. Boston, Addison Wesley, 2002.
Softex. MPS.BR – Melhoria de Processo do Software Brasileiro – Guia de Implementação.
Brasília. 2007.