Atenção: esse artigo tem um vídeo complementar. Clique e assista!
Este artigo apresenta uma maneira simples e objetiva para reportar os resultados dos testes funcionais, sejam eles diários ou finais, assim como os benefícios que podem ser extraídos a partir das informações e estatísticas geradas por um resultado ou por um conjunto deles.
Para que serve:
O artigo poderá auxiliar, de uma maneira prática, os profissionais de testes que necessitam reportar os seus resultados, apresentando exemplos simples e de fácil implementação, para que possam agregar ao seu processo. Serve também para mostrar os motivos e benefícios do reporte dos resultados.
Em que situação o tema é útil:
Para empresas e profissionais que possuem interesse em criar mecanismos (ou apenas complementá-los) para reportar os resultados das atividades de testes, juntamente com a definição do conteúdo necessário e suficiente.
Para todas as atividades planejadas e executadas dentro de um projeto, seja ele de desenvolvimento de software, ou de qualquer outra natureza, existe a necessidade de que o progresso das atividades seja reportado e os resultados finais ou parciais sejam apresentados às pessoas envolvidas. São vários os interessados nessas informações, entre eles, o cliente, o gerente do projeto, o patrocinador e as equipes responsáveis pelas demais etapas do processo de desenvolvimento do software. Com as informações do progresso, seja um status report diário, semanal, ou com alguma outra periodicidade que seja interessante para o projeto (a periodicidade ideal irá depender da duração do projeto e do custo do controle, pois quanto maior o controle maior o custo), os envolvidos terão base para a tomada de decisões, uma vez que será possível comparar o status atual com o planejado. Já as informações referentes aos resultados servirão como lições aprendidas (positivas ou negativas) para os próximos projetos ou para as próximas fases do projeto.
Para as atividades de Teste de Software não é diferente. De acordo com o Quality Assurance Institute [QAI] os testadores devem possuir habilidades para reportarem suas atividades de forma clara e precisa. Eles devem se basear no Plano de Testes, pois as informações apresentadas não podem estar soltas, e sim dentro de um contexto, que envolve algumas variáveis importantes, como prazo, esforço, complexidade, ambiente, escopo, equipe etc. Essa questão é reforçada por [MARICK] no seu artigo “Classic Testing Mistakes”, que classifica como um erro clássico os gráficos e relatórios que são apresentados fora de um contexto.
Um exemplo trivial é apresentado através da comparação entre dois projetos, A e B. Ambos apresentam percentual de conclusão igual a 80%. Mas esse valor não diz nada sozinho. De nada adianta apresentar o percentual de conclusão dos testes se não sabemos qual o prazo para conclusão, pois nada indica se essa data será ou não cumprida. Para ajudar a encontrar um indício das chances de sucesso, os gráficos da Figura 1 apresentam duas novas variáveis: a data final e o histórico do progresso dos testes. Com essas informações a chance de se “prever o futuro” aumenta. É possível deduzir que o projeto A não cumprirá o prazo, pois resta apenas um dia e o histórico do progresso é de 5% ao dia. Já o projeto B, de acordo com o mesmo histórico de progresso de 5% ao dia, será possível chegar aos 100% no dia 16/12.
Figura 1. Progresso dos testes para os projetos A e B.
Mas existem outras variáveis que não são apresentadas no gráfico e que podem mudar todo o diagnóstico realizado. Por exemplo, pode ser que os casos de uso a serem testados no projeto B ainda não estejam liberados para testes, ou seja, ainda não foram construídos. Só serão liberados na manhã do dia 16/12. Considerando as mesmas condições de esforço de execução dos testes (número de testadores) e o progresso de 5% ao dia, este cenário indicará um atraso para o projeto B. Desta forma, é interessante que esse gráfico seja apresentado juntamente com as informações de liberação de casos de uso para testes. Outra variável é o esforço de execução dos testes. Para o projeto A foram disponibilizados mais três testadores. Assim, será possível atingir os 100% no dia 13/12, levando em consideração que é possível dividir os testes entre os testadores.
Outras variáveis ainda podem influenciar os prognósticos, como por exemplo, a complexidade e a qualidade dos casos de uso a serem testados. Nada impede que os casos de uso do Projeto B a serem liberados sejam triviais e possam ser testados rapidamente, principalmente se nenhuma falha for encontrada. O inverso poderá se revelar no Projeto A, que mesmo com muitos testadores, não conseguirá finalizar os testes no prazo definido devido à complexidade dos casos de uso.
A mensagem principal aqui é que os relatórios e gráficos devem estar dentro de um contexto muito bem definido, apresentando o maior número de informações (variáveis) possíveis.
De acordo com o [QAI] existem duas categorias principais de relatórios que podem ser apresentados: relatórios correntes dos testes e relatórios finais dos testes. A primeira categoria trata-se da apresentação do andamento atual dos testes, ou seja, resultados apresentados durante as atividades de testes. Já a segunda, como o próprio nome diz, no final de uma atividade de testes. Cada uma das categorias será apresentada nos próximos itens.
Relatório Corrente dos Testes
Esta categoria de relatórios é bastante importante para o gerenciamento do projeto. Os responsáveis pela tomada de decisões precisam ser munidos de informações do andamento e da qualidade do projeto. Nada mais interessante do que obtê-las através da perspectiva dos testadores. Esses relatórios devem ser gerados com uma periodicidade que seja interessante, servindo como ferramenta pró-ativa para o projeto. O status report não precisa ser complexo, mas precisa ser claro, objetivo e, como já dito, contextualizado. As sugestões e os exemplos apresentados a seguir consideram uma frequência diária.
Antes de seguir, é bom frisar que, apesar de estarem inseridos dentro desta categoria, os relatórios individuais sobre as falhas encontradas durante a execução dos testes que estão em processo de análise/correção não serão abordados nesse artigo. Apenas um resumo geral do conjunto das falhas é informado no status report. Boas práticas para o registro e acompanhamento das falhas rendem assunto suficiente para outro artigo inteiro.
Status Report Diário
Como já informado, o objetivo principal desse status report é munir os líderes, gerentes e demais envolvidos de informações sobre a situação atual da atividade. É um retrato da atividade. Com ele torna-se possível comparar a situação atual com a planejada. Caso exista uma longa distância entre elas, ou a presença de sintomas de potenciais problemas, ações de modo a contorná-los e eliminá-los devem ser tomadas. Abaixo, são apresentados e exemplificados alguns itens sugeridos para a composição do status report. Tudo que será apresentado são sugestões, que podem ou não serem aceitas, ou adaptadas em outros processos.
...
