Evoluindo o teste tradicional para o teste ágil:
Um estudo de caso na África
1. Evoluindo de Teste Tradicional para o Teste Ágil
Para realizar o estudo de caso proposto foi selecionado uma empresa de pequeno porte que mostra a evolução do processo de desenvolvimento até a implementação da metodologia ágil SCRUM com o foco na equipe de teste.
3.1. A empresa
A empresa foco deste estudo, atua no seguimento de desenvolvimento de software sob medida, tendo como principais clientes empresas do setor governamental. Os produtos desenvolvidos por essa empresa englobam todas as fases do ciclo de desenvolvimento de software, desde o levantamento de requisitos junto ao cliente até a entrega e homologação do mesmo.
Por trabalhar sempre com o ciclo completo de desenvolvimento de software, a empresa possui um processo de desenvolvimento bastante maduro. Tal processo se baseava no modelo cascata, utilizando a grande maioria dos modelos de documentos sugeridos pelo processo, como: caso de uso, especificação técnica, especificação funcional, plano de testes e roteiro de testes.
A fim de conseguir atingir um nível de excelência neste processo, a equipe de desenvolvimento se subdividia em três perfis distintos: Analise de requisitos, desenvolvimento e testes. Este arranjo funcionava como uma linha de montagem, onde as peças (artefatos) se moviam de um setor a outro da linha de produção (Perfis da equipe de desenvolvimento).
3.2. Processo de desenvolvimento
Ao contrário do processo de desenvolvimento já descrito, o processo de teste ainda não havia atingido uma maturidade satisfatória, pois o papel da equipe consistia somente em criar casos de teste em planilhas Excel (Quadro 1), com sua posterior execução e validação, que gerava ao final do processo, um relatório.
Quadro 1 – Caso de teste inicial
| 1. Caso de teste
2. Descrição 3. Resultado Esperado 4. Resultado 5. Observação |
Contrariando a regra 10 de Myers (1979), não havia integração entre as atividades desenvolvidas pela equipe na fase de testes e as demais atividades do processo, limitando a atuação da mesma ao final do processo, conforme representando na Figura 3. Com isso, a equipe de testes não realizava a revisão dos artefatos gerados pela equipe de análise, postergando a detecção de eventuais incoerências no levantamento de requisitos, o que, inevitavelmente, contribuía significativamente para o aumento do custo da correção dos erros encontrados.
Este arranjo causou problemas de entendimento das funcionalidades e, juntamente com a falta de experiência e técnica, a equipe, não atingia as expectativas do cliente, entregando um produto sem qualidade assegurada.
Figura 3 – Processo inicial de desenvolvimento
3.3. Proposta de melhoria do Processo de desenvolvimento
Para definir uma proposta que possibilitasse a evolução do processo de desenvolvimento até a implementação da metodologia ágil SCRUM, com o foco na equipe de teste foram realizadas as seguintes etapas:
1) Capacitação da equipe de testes;
2) Descrição do processo;
3) Seleção de metodologia de gestão de projetos;
4) Aplicação da proposta;
5) Avaliação do desempenho do processo
3.3.1. Capacitação da equipe de testes
Diante desse cenário, a empresa decidiu reestrutrar sua equipe de teste, redefinindo os papéis dos integrantes da equipe e suprindo os pontos fracos de conhecimento: conceitos e técnicas de testes; e requisitos do sistema.
A primeira medida para essa reestruturação foi o refinamento das competências da equipe, introduzindo os principais conceitos de teste: Processos de teste, técnicas de teste funcional e estrutural, elaboração de testes, gestão de defeitos e de requisitos.
3.3.2. Descrição do processo proposto
O ajuste do processo de teste foi a próxima medida adotada, visando atender os requisitos mínimos de qualidade descritos na ISO/IEC 9126, (2001) (funcionalidade, usabilidade, manutenabilidade, confiabilidade, eficiência e portabilidade) assim como reduzir os custos provenientes da detecção tardia dos defeitos. Um dos principais ajustes foi a criação de novos artefatos: Plano de testes(Quadro 2), Roteiro de testes (Quadro 3), Documento de evidência (Quadro 4), e Termo de aceite (Quadro 5),. Além disso, tendo como objetivo atender também a IEEE 829 (2008), foram criadas novas etapas no processo de desenvolvimento, tais como: criação do plano de teste, revisão das especificações funcionais, criação dos casos de teste, execução dos casos de teste e homologação com o utilizador final (Figura 4 e Figura 5).
Quadro 2 – Plano de teste original
| 1 Visão Geral do Projeto
1.1 Papéis e Responsabilidades 2 Equipe e Infra-estrutura 2.1 Planejamento da Alocação de Pessoal 2.2 Equipamentos 3 Artefatos 4 Treinamentos 5 Acompanhamento do Projeto 5.1 Acordo de Nível de Serviço 6 Cronograma 6.1 Marcos Significativos do Teste 7 Categorias de Testes 8 Critério de Finalização 8.1 Critério de Conclusão de Testes 8.2 Critério de Aceitação 9 Gerência de Riscos 10 Termo de Aceite |
Quadro 3 – Roteiro de teste original
1.1 Escopo 1.2 Itens de Teste 1.3 Níveis de Teste 1.4 Tipo de Teste 1.5 Referências
2.1 Cenário: Pasta Controle De Demanda 2.1.1 Caso de Teste: 2.1.1.1 Descrição 2.1.1.2 Pré-condição 2.1.1.3 Procedimentos 2.1.1.4 Resultados Esperados 2.1.1.5 Pós-condição |
Quadro 4 – Documento de evidência
| 1 Finalidade
2 Evidências dos Testes 3 Caso de Teste: Nº do caso de teste 4 Prova: Imagem do teste (Print Screen) 5 Resultado de Teste: OK ou NOK |
Quadro 5 – Termo de aceite
|
Tais medidas tiveram um impacto altamente positivo sobre o processo de desenvolvimento ao reduzir o tempo necessário para a homologação dos produtos gerados. Esta redução se deu, diretamente, pelo aumento da qualidade dos testes e, indiretamente, pelo maior interação entre as equipes.
Figura 4 – Processo Pré SCRUM de desenvolvimento – Parte 1 de 2
Figura 5 – Processo Pré SCRUM de desenvolvimento – Parte 2 de 2
Estes dois fatores (aumento na qualidade dos testes e maior interação das equipes) podem ser observado de duas formas através do Quadro 1: etapas, responsáveis e artefatos de entrada e saída mais bem definidos; e envolvimento da equipe de teste desde o início do projeto, e não apenas no final do mesmo.
Quadro 1 –Responsáveis , entradas e saídas de cada etapa do processo de teste
| Etapa | Responsáveis | Entrada | Saída |
| Inicio do projeto | Analista de teste | plano de projeto, cronograma e listas de riscos. | Plano de teste |
| Analise de Requisito | Analista de teste | Especificação funcional | Relatório de revisão de requisito |
| Elaboração dos casos de testes | Analista de teste ou Testador | Especificação Funcional | Roteiro de teste |
| Executar testes | Testador | Roteiro de teste | Relatório de teste final e documento de evidência |
| Acompanhamento de homologação | Analista de teste ou testador | Roteiro de teste | Termo de aceite |
Os novos artefatos criados tiveram como base o padrão IEEE 829 (1998), o qual define um conjunto de mesmos a serem utilizados em cada fase do processo de desenvolvimento para se obter um processo de teste abrangente. O referido padrão define o formato de cada documento, entretanto não define sua obrigatoriedade, delegando a cada processo escolher aqueles que melhor se adequem à sua realidade.
Visando garantir a qualidade do produto final sem impactar excessivamente o esforço total necessário para produção do mesmo não eram utilizados no processo inicial todos os artefatos definidos pelo padrão IEEE 829, dos oitos existentes, três eram utilizadas, nomeadamente:
- Plano de teste;
- Roteiro de teste;
- Documento de evidência.
Alem desses artefatos foi criado o documento termo de aceite, para suprir uma lacuna existente por não existir evidências que comprovassem as entregas.
3.3.3. Seleção de metodologia de gestão de projetos
Seguindo pressões do mercado para obter melhores resultados, a empresa decidiu adotar uma nova metodologia de gestão de projeto. Após um profundo estudo de diversas metodologias concorrentes e complementares, o SCRUM foi aquela que melhor se adaptou a realidade de trabalho e as necessidades do cliente.
Em um primeiro momento, a nova metodologia realmente se mostrou aderente as expectativas, bem como altamente produtiva, entretanto, a equipe de testes apresentou dificuldades de se adaptar à nova metodologia de trabalho, devido a complexidade dos artefatos de testes usados no processo “pré – SCRUM”.
Esta complexidade, em contraposição à agilidade exigida, acabou por criar um enorme gargalo na etapa de elaboração dos planos e casos de testes, conforme demostrado na figura Figura 6.
Figura 6 – Processo Pós SCRUM de desenvolvimento
3.3.4. Aplicação do novo processo
O principal projeto da empresa é dividido em diversos subprojetos, cada qual com escopo, cronograma e arquitetura próprios, consonante o desafio a ser superado.
O subprojeto que serviu de laboratório para este estudo de caso possui uma arquitetura cliente-servidor, com o tamanho relativamente pequeno, mas de abrangência nacional.
A antiga forma de garantir a qualidade do produto não se moldou a nova metodologia. Dentre as dificuldades que levaram a não adequação pode-se citar:
- Resistência a mudança da equipe de teste;
- Detalhamento demasiado grande dos artefatos de teste;
- Maior dinamismo na execução das tarefas;
- Falta de maturidade da equipe.
Essas dificuldades fizeram com que a equipe de teste não conseguisse atender a demanda gerada pela equipe de desenvolvimento em tempo hábil sem comprometer a qualidade dos testes. Em resumo, o trinômio “Qualidade, Prazo e Escopo” ficou extremamente desequilibrado, já que o escopo era fechado e a equipe de testes não conseguia garantir a qualidade nos prazos estabelecidos.
A prática demonstrou que combinar uma nova metodologia de trabalho (SCRUM) com a metodologia tradicional de testes era inviável, por isso, algumas adaptações no processo se faziam necessárias e urgentes.
A primeira medida tomada foi a fusão da equipe de teste com a equipe de desenvolvimento (Figura 7), desta forma, os times de SCRUM passaram a ser constituídos por equipes realmente multidisciplinares, compostas de analistas de requisitos, desenvolvedores e analistas de testes. Essa decisão permitiu maior troca de conhecimento entre os analistas de testes e os demais integrantes da equipe, reduzindo, assim, os famosos “ruídos de comunicação”.
Figura 7 – Processo Atual de desenvolvimento
Outra adaptação primordial foi a redução do tempo investido na criação dos artefatos de teste para o bom funcionamento do novo processo, sendo necessário rever toda a documentação gerada, pois o tempo gasto na criação dos artefatos demonstrou ser um gargalo para o processo. Tal revisão levou a uma simplificação drástica dos artefatos, retirando o detalhamento desnecessário do mesmo. (Quadros 6 e 7).
Quadro 6 – Plano de teste adaptado
| 1. Visão geral do projeto
2. Recursos 3. Escopo dos testes 4. Fora do escopo dos testes 5. Novas funcionalidades 6. Testes de carga e desempenho 7. Teste de aceitação 8. Infra-estrutura 9. Criticidade dos defeitos 10. Premissas 11. Riscos 12. Atribuições |
Quadro 7 - Caso de teste adaptado
| 1. Caso de teste
2. Pré-condição 3. Procedimento 4. Resultado Esperado |
3.3.5. Avaliação do desempenho do processo
Para avaliar o real impacto das mudanças realizadas no processo ao longo do tempo foram definidas duas métricas: quantidade de erros encontrados pelo cliente e tempo de aceitação dos produtos.
A primeira métrica utilizada reflete indiretamente a satisfação do cliente, uma menor quantidade de erros encontrados pelo mesmo aumenta sua percepção de “qualidade do produto”, ou seja, para o cliente, um produto com menos problemas é um produto com maior qualidade.
A segunda visa avaliar a qualidade geral dos produtos gerados, assumindo que produtos com o tempo de aceitação demasiado grande têm qualidade inferior. Este aumento de tempo é conseqüência direta da quantidade de erros encontrados pelo cliente juntamente com o tempo gasto pela equipe para corrigi-los.
Como pode ser observado na Figura 8, a quantidade de erros encontrados pelo cliente em homologação/produção diminuiu gradativamente a medida que o processo evoluiu. Isso significa que a introdução do SCRUM e a posterior adaptação do processo de teste, teve como resultado direto produtos com uma quantidade menor de erros.
Figura 8 - Quantidade de incidentes abertos pelo cliente.
A visível diminuição da quantidade de erros, entretanto, nem sempre significou um menor tempo para a aceitação dos produtos pelo cliente. Essa situação é particularmente visível no cenário pós SCRUM. Como dito anteriormente, neste cenário, a produção dos artefatos de teste representou um gargalo para todo o processo, o que é claramente visível na Figura 9.
Figura 9 – Tempo de aceitação dos produtos
Quando comparadas as métricas (“Quantidade de incidentes abertos pelo cliente” e “tempo para aceitação”) percebe-se uma significativa melhora no processo a na satisfação do cliente, pois foi possível manter o tempo médio para aceitação do produto (menos de 30% dos incidentes resolvidos em mais de 90 dias) e, ao mesmo tempo, reduziu drasticamente em 60% a quantidade de erros que chegam ao cliente, aumentando, assim, a percepção de qualidade do produto.
4. Conclusão
Apesar da considerável melhora no processo, demonstrado por ambas as métricas supra-citadas, muitos aspectos ainda podem e devem ser melhorados.
Há algumas características do teste tradicional que podem ser adaptadas à nova metodologia, agregando ainda mais valor ao processo, aumentando a agilidade e qualidade do produto.
Conforme preconizado pelo manifesto ágil, o processo de teste deve ser automatizado sempre que possível. A proposta apresentada, entretanto, ainda não automatiza todas atividades como os testes de aceitação, o teste de desempenho e o TDD (Test Driven Development).
A automação do teste de aceitação atua sobre a fase de homologação do produto, tendo como principal vantagem a possibilidade de se reproduzir, a qualquer momento, os testes realizados, entretanto o teste de desempenho, tem como principal objetivo avaliar o desempenho dos sistemas diante de situações reais de estresse.
O maior desafio para qualquer equipe ágil, entretanto, é a implementação do desenvolvimento orientado a testes TDD (Test Driven Development).
. Essa quebra de paradigma traz mudanças profundas na cultura de trabalho, o que acaba por se tornar um grande entrave, dada a resistência natural das pessoas à mudança. Por outro lado, uma vez vencida essa resistência, é mais visível impacto positivo sobre os resultados finais, uma vez que permite reduzir, significamente, a incidência de problemas.
Para uma adaptação satisfatória dessas outras características, a experimentação, corroborada pela coleta das estatísticas, é a melhor estratégia a ser implementada, por permitir uma melhor moldagem do processo a esta nova realidade.
5. Referências Bibliográficas
BASTOS, Anderson et al. Base de conhecimento em teste de software. Niterói: Traços e Photo, 2006. 300p.
ISO/IEC 9126. International Organization for Standardization. Software engineering -
Product quality. Estados Unidos, 2001.
G. J. Myers. The Art of Software Testing. Wiley, 1979.
KNIBERG, Hernik. Scrum e XP direto das trincheiras: Como nós fazemos Scrum. In:
KNIBERG, Henrik. Scrum e XP direto das trincheiras. Eua: Infoq, 2008. p. 45.
IEEE829-1998 Starndar for Software Test Documentation Comitê de Padrões de Engenharia de Software da IEEE computer Society, Nova Iroque.
MARÇAL, Ana Sofia; PEREIRA, Paulo; TORREÃO, Paula. Entendendo Scrum para Gerenciar Projetos de Forma Ágil. Acesso em: 15 Out. 2010. Disponível em: http://www.cesar.org.br/files/file/SCRUM_MundoPM-Abril-Maio-2007.pdf
Pan, Jiantaoiam: 18-849b Dependable Embedded Systems. Instituto Carnegie Mellon University,1999.
RSI,Referência em Qualidade em TI, Acesso em: 05 FEV 2011. Disponível em: http://WWW.rsinet.com.br
QUEZADA, Gustavo. Papel do “Time de Teste” em Projetos SCRUM. Acesso em: 20 Nov. 2010.Disponível em: http://gustavoquezada.blogspot.com/.
Rios Emerson. Documentação de Teste de Software: Padrão IEEE 829. Imagem art studio. 2008
The Agile Alliance: Manifesto for Agile Software Development. Acesso em 21/11/2008Disponível em: http://agilemanifesto.org/.
SABBAGH, Rafael. Apostila de Agile Testing. Acesso em: 20 Nov. 2010.
Disponível em: http://scrumemacao.com.br/web/.
Kaner, Cem. XP, Iterative Development, and the Testing Community, 2002. –Instituto de Tecnologia da Flórida.













Touro: 21/04 a 20/05
Gêmeos: 21/05 a 20/06
Câncer: 21/06 a 21/07
Leão: 22/07 a 22/08
Virgem: 23/08 a 22/09
Libra: 23/09 a 22/10
Escorpião: 23/10 a 21/11
Sagitário: 22/11 a 21/12
Capricórnio: 22/12 a 20/01
Aquário: 21/01 a 19/02
Peixes: 20/02 a 20/03