Ótima sexta-feira a todos, amigos! No final de junho, lançaremos um novo grupo no curso de
Especialista em controle de qualidade , que será o foco da publicação de hoje.
Existem muitos indicadores pelos quais você pode medir a eficácia da equipe de testadores. Um deles é a taxa de defeitos rejeitados ou o número de relatórios de erros rejeitados dividido pelo número total de relatórios recebidos. Você deve estar pensando que, se o número de relatórios rejeitados for zero, isso é bom, mas não é tão simples. Vamos examinar os tipos de erros rejeitados, ver como eles afetam a taxa de erros rejeitados e calcular a proporção correta para sua equipe.
Existem três categorias de erros rejeitados:
- Erros irreprodutíveis;
- Erros incorretos
- Erros duplicados.
Vamos começar com os próprios erros.
Erros irreprodutíveis
Existem dois tipos de erros irreprodutíveis. O primeiro é um erro que é realmente difícil de reproduzir. Pode ser um erro resultante da interação de vários parâmetros, alguns dos quais você nem conhece.
Suponha que você tenha realizado vários testes seguidos e um dos testes alterou o parâmetro de configuração do valor padrão A para outro valor B. O erro ocorre apenas quando o parâmetro de configuração contém o valor B e o valor de entrada é C. Quando Ao tentar reproduzir o erro, provavelmente você desejará começar com um estado conhecido para inicializar o sistema (ou, possivelmente, executar uma instalação limpa). Nenhum erro ocorrerá porque o parâmetro de configuração agora novamente contém o valor padrão A.
Outra variante desse tipo de erro irreprodutível é quando o teste realmente encontrou um defeito, mas não há dados nas informações de reprodução: uma etapa, um valor de entrada específico ou um entendimento de que o erro ocorre apenas com um determinado procedimento. Como resultado, as tentativas de reproduzir o erro não levam a nada.
Nos dois casos acima, no entanto, existe realmente um defeito no próprio produto.
O segundo tipo de erro irreprodutível é quando o erro não pode ser repetido porque não existe. O testador pode ter notado algo, mas mal interpretado, ou o sistema usado para o teste pode ter algum tipo de problema, como um componente de hardware com defeito, driver incompatível ou configurações de acesso incorretas. Tentativas de reproduzir o erro em um sistema configurado corretamente falham.
Esses dois tipos de erros geralmente são sinalizados nos sistemas de relatório de erros como "rejeitados - não podem ser reproduzidos".
Erros incorretos
Esse tipo de erro ocorre se o testador decidir que o produto deve se comportar de uma certa maneira e relatar um erro quando o comportamento não atender às suas expectativas. No entanto, um estudo mais detalhado dos requisitos mostra que as expectativas do testador eram errôneas e o produto realmente funcionava corretamente. Ou seja, o produto testado funcionou corretamente e o testador, que não estava suficientemente familiarizado com os requisitos, cometeu um erro.
Esses erros geralmente são sinalizados nos sistemas de relatório de erros como "rejeitados - não com erros" ou "rejeitados - pela arquitetura" (ou seja, o comportamento é consistente com a arquitetura).
Erros duplicados
Erros repetidos são aqueles que já foram relatados e o próximo informa depois. Um erro é repetitivo apenas se os "sintomas" de sua aparência forem os mesmos. E se a causa raiz do erro for a mesma, mas os “sintomas” forem diferentes, isso não é uma repetição do erro!
Esses erros geralmente são sinalizados nos sistemas de relatório de erros como "rejeitados - duplicados / repetidos".
Como erros rejeitados afetam uma equipe
Obviamente, um erro incorreto é um tipo de perda de tempo que o testador gasta em reproduzir e relatar o erro, o tempo que aqueles que classificam os erros passam lendo e compreendendo-os e o tempo que os desenvolvedores gastam tentando reproduzir um erro improdutível ou corrigir (e funcionar mal) algo que não precisava dessa correção.
Além do fato de que a taxa de erro rejeitada ou RDR é uma medida da ineficiência da equipe de testadores, ele também fala sobre o profissionalismo dos testadores em geral. Um erro que não pode ser reproduzido devido à falta de informações necessárias no relatório indica que os testadores não foram meticulosos e não trabalharam o suficiente para reproduzir esse erro usando as etapas descritas acima. Além disso, para erros que são reproduzidos com pouca frequência, os testadores geralmente não observam a baixa frequência de reprodução no relatório.
A aparência de um erro incorreto indica que os testadores não entendem completamente os requisitos do produto. Erros repetidos indicam que os testadores não realizaram uma pesquisa mínima no banco de dados de erros local para verificar se isso ocorreu anteriormente. Ou significa que o especialista que relatou esse erro não foi o primeiro a incluir as palavras-chave corretas no nome para facilitar a pesquisa por outros colegas.
Por sua vez, se o erro que encontrei for rejeitado, fico ressentido porque fui considerado um leigo. Por um lado, isso significa que defenderei os erros encontrados. Quando meu relatório é rejeitado, procedo da seguinte maneira:
- Verifico novamente se o erro está sendo reproduzido no meu sistema e adiciono as etapas de reprodução, se perdi alguma coisa;
- Se meu mal-entendido sobre os requisitos foi causado por um requisito ambíguo ou documentação incorreta, insistirei para que o erro seja marcado como um erro de documentação e fechado somente quando a documentação for corrigida;
- Se eu acredito que o comportamento do produto ao cumprir o requisito está incorreto, falarei sobre os requisitos com arquitetos e desenvolvedores, tentarei convencê-los de que os requisitos precisam ser atualizados (no final, represento a opinião do cliente!);
- Se o erro for rejeitado como duplicado, assegurarei que ele não tenha sido marcado da mesma maneira ou que não apareça "de acordo com o mesmo cenário".
Por outro lado, uma certa probabilidade de rejeição de erros me torna cauteloso. Se não tiver certeza absoluta de que encontrei um bug, passarei mais tempo verificando antes de relatar. Costumo perguntar a um colega se interpreto os requisitos corretamente ou verifico se o erro é reproduzido no sistema de outra pessoa.
Parecer contra a total ausência de erros rejeitados
A equipe de teste deve monitorar e se esforçar para reduzir o nível de RDR. A única pergunta é: qual RDR deve ser considerado bom?
À primeira vista, parece que 0% é o resultado ideal, mas eu discordo totalmente disso. Acredito que, quando o RDR é mantido em um nível saudável, isso é normal, porque, se estiver próximo de zero, a equipe de teste obviamente não terá problemas menos sérios do que, digamos, um RDR muito alto.
A equipe de teste deve fazer grandes esforços para alcançar um RDR extremamente baixo. Cada erro rejeitado será analisado para entender o que deu errado, e cada testador que relatou um erro que foi rejeitado terá que explicar o que realmente aconteceu e como essa situação pode ser evitada no futuro. Como resultado, os testadores reportarão erros nos quais eles têm certeza absoluta.
Se eles perceberem um comportamento que acham que prejudicará a usabilidade do produto, preferirão considerar esse comportamento como garantido, em vez de justificar que encontraram um erro que, de fato, não é um erro com base nos requisitos. Se eles tiverem evidências de que ocorreu um erro, mas não houver um bom cenário para reproduzi-lo, eles preferirão não denunciá-lo; eles realmente não querem se aborrecer. Se eles encontrarem um bug frívolo, poderão decidir não denunciá-lo, porque os erros menores nem sempre o corrigem. Por que correr o risco e ter medo de que o erro encontrado seja rejeitado?
Em resumo, a busca por um RDR muito baixo gera estresse e comportamento prejudicial na equipe de teste e também aumenta a probabilidade de que alguns erros passem despercebidos.
Precisamos de testadores que não apenas relatem erros óbvios, mas também avisem sobre qualquer comportamento suspeito no projeto. Acreditamos que os testadores que atribuem grande importância à garantia de que o erro não escapa, mesmo ao custo de relatórios duplicados, são melhores do que os testadores que passam horas verificando se um bug já foi relatado nos relatórios ou não, com medo de que faça uma duplicata. Queremos que os testadores se sintam à vontade para questionar a palavra de um arquiteto de sistema ou a especificação de requisitos, mesmo que isso signifique que alguns de seus erros serão sinalizados como rejeitados.
Precisamos de testadores que não tenham medo de cometer erros de tempos em tempos. Isso significa que é necessário equilíbrio, portanto, um pequeno RDR é considerado aceitável.
Encontrar o coeficiente ideal de defeito rejeitado
Minha regra geral é que o RDR deve ser de 15%. Esse valor é baseado na minha experiência com a equipe de testadores, que, segundo todas as contas, era uma equipe boa e eficaz. Foi o nosso RDR durante vários projetos que foram um após o outro, enquanto a outra equipe, que trabalhou nos mesmos projetos e em paralelo conosco, embora tenha menos conhecimento do produto e seja considerada menos eficaz, teve um RDR de 30% .
Não creio que haja outra justificativa para esse significado além do meu sentimento interior. Definitivamente, isso não é científico. Não discutirei com uma equipe que visa 10 ou 20%, mas acho que aguentar 30% ou estabelecer uma meta de 5% já é um problema.
No final, essa é uma decisão que deve ser tomada pela equipe de teste com base nos recursos do produto, no nível de conhecimento da equipe, no modelo de desenvolvimento, na experiência da equipe de desenvolvimento e muito mais. Eu recomendo que você fique de olho no RDR e pense se precisa fazer algo com ele. E se for muito alto ou baixo, medidas apropriadas devem ser tomadas.
Por tradição, aguardamos seus comentários e convidamos você para um
seminário on-line gratuito , que será realizado em 14 de junho. Até breve!