test coverage software testing
Guia completo de cobertura de teste de teste de software: Como testar mais, economizar tempo e obter melhores resultados de teste:
O teste de software é uma atividade essencial no desenvolvimento de software e nos ciclos de vida de manutenção. É uma prática frequentemente usada para decidir e melhorar a qualidade do software.
O desenvolvimento é mais sistemático hoje em dia e as organizações buscam medidas de integridade e eficácia do teste para mostrar os critérios de conclusão do teste. De todos eles, a cobertura é considerada especialmente valiosa.
O que você aprenderá:
- O que é cobertura de teste?
- Cobertura de teste e cobertura de código
- Minha experiência
- Significado da cobertura do teste
- Como adotar um método de cobertura de teste adequado?
- Como ter certeza de que tudo foi testado?
- Áreas críticas e métodos para testes eficazes
- Vantagens da conscientização da cobertura de teste para um testador:
- Conclusão
- Leitura recomendada
O que é cobertura de teste?
Simplificando, a cobertura é “O que estamos testando e quanto estamos testando?”
A cobertura de teste ajuda a monitorar a qualidade do teste e auxilia os testadores a criar testes que cobrem áreas que estão faltando ou não foram validadas.
A maioria das equipes baseia seus cálculos de cobertura apenas nos requisitos funcionais. Também é justo porque, antes de mais nada, um aplicativo deve fazer o que deve fazer. Caso contrário, sua velocidade, segurança ou facilidade de uso - nada disso importa.
No entanto, se dedicado e independente teste não funcional as equipes estão trabalhando em desempenho, segurança, teste de usabilidade, etc., então eles terão que rastrear seus requisitos todo o caminho até a execução por meio de análises de cobertura de teste.
Cobertura de teste e cobertura de código
A cobertura de teste costuma ser confundida com a cobertura de código. Mesmo que os princípios básicos sejam os mesmos, eles são duas coisas diferentes.
Cobertura de código realmente fala sobre as práticas de teste de unidade que devem visar todas as áreas do código pelo menos uma vez e são feitas por desenvolvedores.
A cobertura de teste, por outro lado, é testando todos os requisitos pelo menos uma vez e é obviamente uma atividade da equipe de QA.
O que realmente se qualifica para ser um requisito coberto depende da interpretação de cada equipe.
Por exemplo , Algumas equipes consideram um requisito coberto se houver pelo menos um caso de teste contra ele. Às vezes, ele é coberto se pelo menos um membro da equipe for atribuído a ele. Ou, se todos os casos de teste associados a ele forem executados.
- Se houver 10 requisitos e 100 testes criados - quando esses 100 testes visam todos os 10 requisitos e não omitem nenhum - chamamos isso de cobertura de teste adequada no nível de design.
- Quando apenas 80 dos testes criados são executados e visam apenas 6 dos requisitos. Dizemos que 4 requisitos não são cobertos, embora 80% dos testes sejam concluídos. Estas são as estatísticas de cobertura em um nível de execução.
- Quando apenas 90 testes relacionados a 8 requisitos têm testadores atribuídos e o restante deles não, dizemos que a cobertura da atribuição de teste é de 80% (8 em 10 requisitos).
Também é importante quando calcular a cobertura.
Se você fizer isso muito cedo no processo, verá muitas lacunas porque as coisas ainda estão incompletas. Portanto, geralmente é aconselhável espere até a última compilação ou seja, Compilação de regressão final. Isso dará uma cobertura correta dos testes realizados para os requisitos dados.
Leia também => Processo de gerenciamento de liberação e implantação
Minha experiência
Cena 8 anos atrás: Quando eu tinha 2 anos de experiência na indústria de teste de software, pensava que tudo bem se eu não conhecesse alguns fundamentos sobre teste de software como algo que se pode aprender com a experiência e eu também o farei.
Eu estava certo - e errado também.
Certo porque com a experiência, você aprende a ver uma imagem maior, entende o significado real de “Situação crítica” e entende mais o usuário final.
Errado porque nenhuma das coisas mencionadas exige experiência, mas sim um aprendizado precoce, que entendi muito tarde. Esse é o fator encorajador para escrever este post.
Aqui está minha experiência de uma das entrevistas na época:
Como você se certifica de que a cobertura do teste é completa ou máxima? Eu fui questionado.
Ummmm ... Certifico-me de testar todas as funcionalidades , Eu disse.
S o você está dizendo que depois de testar todas as funcionalidades, você sente que cobriu um máximo de aplicação / produto, em termos de teste , o tiro saiu pela culatra.
Ummm ... bem ... hummm ... sim, porque quando você testa todas as funcionalidades, fica confiante sobre o comportamento do aplicativo / produto, Apoiei minha resposta .
Eu concordo, mas minha pergunta é - isso lhe dará a confiança de que sua cobertura de teste é máxima ou completa? o entrevistador não estava com vontade de me deixar ir.
Agora, eu estava ficando impaciente, desconhecido sobre o fato de que aprenderia um dos tópicos mais importantes sobre teste de software - ' Cobertura de teste ” .
Em vez de reproduzir os trechos da entrevista, estou resumindo aqui o que aprendi sobre a Cobertura de Teste, naquele dia. Mas antes disso, vamos ser claros em um ponto - a cobertura de teste nunca significa saber se você está testando o suficiente ou não, nem significa que você está testando perfeitamente ou não.
Significado da cobertura do teste
A cobertura de teste pode ter um significado diferente em contextos diferentes. Vamos descobrir esses contextos um por um:
Cobertura do produto - quais aspectos do produto você observou?
Sim, quando a cobertura de teste está sendo medida em termos de produto, a principal área de foco é - quais áreas do produto você testou e quais permanecem não testadas?
Exemplo 1:
Se “faca” for um produto, você está testando; apenas não se concentre em verificar se ele corta os vegetais / frutas corretamente. Há outros aspectos a serem observados, como - o usuário deve ser capaz de lidar com isso confortavelmente.
Exemplo # 2:
Se o “notepad” for um aplicativo, você está testando, verificar os recursos relevantes é uma coisa obrigatória.
Mas outros aspectos a serem tomados são - o aplicativo responde adequadamente ao usar outros aplicativos simultaneamente, o aplicativo não trava quando o usuário tenta fazer algo incomum , o usuário recebe mensagens de aviso / erro adequadas, o usuário é capaz de compreender e usar o aplicativo facilmente, o conteúdo de ajuda está disponível quando necessário.
Se você não olhar para os cenários mencionados, você não pode alegar que a cobertura de teste para o aplicativo está completa.
Cobertura de risco - quais riscos você testou?
A cobertura de risco é outro aspecto para ter uma cobertura de teste completa. Você não pode marcar o produto ou aplicativo como 'testado' até testar os riscos associados também. A cobertura dos riscos associados é um fator importante na cobertura geral dos testes.
Exemplo 1:
Durante o teste de um avião, se um testador disser que ele / ela testou totalmente o sistema interno do avião e está funcionando bem, mas apenas a capacidade de voo do avião não foi coberta durante o teste - qual seria sua reação?
Bem, é isso que significa cobertura de risco. Identificar o risco de acordo com a aplicação / produto e testá-lo completamente é sempre uma boa prática.
Exemplo # 2:
Ao testar um site de e-commerce, o testador considerou todos os fatores efetivos, mas não considerou o risco do número de usuários acessando o site simultaneamente e no dia da Super OFERTA, o risco não considerado provou ser um grande erro.
Leitura recomendada =>
Cobertura de requisitos - quais requisitos você testou?
Se um produto ou aplicativo é desenvolvido muito bem, mas não está de acordo com os requisitos do cliente, então não adianta. A cobertura de requisitos durante o teste é tão importante quanto a cobertura do produto.
Exemplo 1:
Animada com a função familiar, você pediu ao alfaiate que costurasse seu vestido e colocasse aqueles botões de show em azul pavão no decote.
Enquanto fazia a costura do vestido, o alfaiate pensou que colocar aqueles botões no decote não ficaria bem, então ele costurou uma borda dourada. No dia do teste, definitivamente, o cliente insatisfeito gritou com o alfaiate por não cumprir os requisitos.
Exemplo # 2:
Ao testar um aplicativo de bate-papo, o testador cuidou de todos os pontos importantes, como vários usuários conversando em um grupo, dois usuários conversando independentemente, todos os tipos de emoticons disponíveis, atualizações enviadas ao usuário imediatamente, etc., mas esqueceu de olhar o documento de requisitos, que claramente mencionou que quando dois usuários conversam independentemente, a opção de chamada de vídeo deve ser habilitada.
O cliente comercializou o aplicativo de chat alegando que permitiria chamadas, enquanto dois usuários conversavam de forma independente. Você pode imaginar o que teria acontecido com o aplicativo de bate-papo.
Além disso leitura => Como Criar Matriz de Rastreabilidade de Requisitos
Como adotar um método de cobertura de teste adequado?
Conscientização é tudo:
Em primeiro lugar, a equipe de QA deve saber quanto trabalho está envolvido e onde estão as tarefas de design. Dessa forma, eles saberão se mais testes serão adicionados. Para fazer isso, você pode usar um RTM como é a prática típica.
=> Confira este artigo para saber mais sobre ele e como usá-lo: Como Criar Matriz de Rastreabilidade de Requisitos - Processo Exato com Modelo de Amostra
Em segundo lugar, verifique a atribuição de recursos e processo de execução de teste para ver se tudo é testado da maneira mais eficaz.
Uma tabela como a abaixo pode ser útil:
Tipo de Teste | Total de Casos | Casos Executados | Status | Comentários |
---|---|---|---|---|
Funcional | 100 | 80 | 50 aprovadas, 30 reprovadas | |
Compatibilidade | 100 | cinquenta | 45 aprovadas, 5 reprovadas | |
Usabilidade | 100 | 100 | 98 aprovadas, 2 reprovadas | |
Regressão Final | 100 | 100 | 99 passa, 1 falha |
Como ter certeza de que tudo foi testado?
- Cada testador deve estar ciente dos requisitos e métodos de teste
- Priorize seus requisitos e concentre sua energia onde é mais necessária
- Esteja informado sobre como uma determinada versão é diferente da anterior para que você possa identificar os requisitos críticos com mais precisão e se concentrar na cobertura positiva máxima
- Adapt Test Automation
- Use ferramentas de gerenciamento de teste para sempre ficar por dentro
- Atribuição de trabalho inteligente - canalize seus melhores recursos para tarefas críticas e deixe novos testadores explorarem mais para uma nova perspectiva
- Manter um lista de verificação para todas as tarefas e atividades diversas
- Interaja mais com suas equipes Dev / Scrum / BA para obter insights sobre o comportamento do aplicativo
- Acompanhe todos os seus ciclos de construção e correções
- Identifique os problemas mais impactantes nas próprias compilações iniciais (quando possível) para que as últimas possam trabalhar para uma melhor estabilidade e alcançar as áreas bloqueadas por problemas anteriores
Áreas críticas e métodos para testes eficazes
# 1)Mistura de recursos: Troque tarefas entre os membros da sua equipe. Isso ajuda a melhorar o envolvimento e evitar a concentração de conhecimento.
#dois)Cobertura de compatibilidade: Certifique-se de estar ciente e incluindo o navegadores diferentes e plataformas para testar seu aplicativo.
# 3)Propriedade: Torne os testadores responsáveis e dê-lhes rédea solta (com monitoramento e suporte, é claro) para o módulo / tarefa em que estão trabalhando. Isso ajuda a construir responsabilidades e permite que eles tentem maneiras criativas, em vez de seguir o que já foi derrotado.
# 4)Prazos: Saber os prazos de lançamento antes do início da fase de teste ajuda no planejamento eficaz
# 5)Comunicação : Fique em contato com o desenvolvedor e outras equipes entre os ciclos de lançamento para saber o que está acontecendo.
# 6)Manter um RTM: Atua como um bom derivado para o Partes Interessadas ou Clientes , com base no qual a programação de lançamento pode ser confirmada
Vantagens da conscientização da cobertura de teste para um testador:
- Isso ajuda principalmente na priorização de tarefas de teste
- Ajuda a atingir 100% de cobertura de requisitos ou em outras palavras, evita vazamento de requisitos
- Análise de Impactos fica mais fácil
- Útil para determinar o Critério de saída
- Habilita um líder de teste para preparar um claro relatório de fechamento de teste
Conclusão
A cobertura do teste não termina com os contextos mencionados. Existem muitos outros pontos que devem ser considerados quando se trata de cobertura de teste.
Nem sempre é verdade que, quando você testa mais, os resultados são melhores. Na verdade, quando você testa mais sem nenhuma estratégia aparente, provavelmente acabará investindo muito tempo.
Com uma abordagem mais estruturada, um objetivo de cobertura de 100% dos requisitos e métodos de teste eficazes, você não comprometerá a qualidade.
usando eclipse para c ++
Esperamos que as técnicas descritas neste artigo forneçam algumas dicas.
Despeje seus comentários e opiniões sobre a postagem. Como sempre, adoramos ouvir de você.
Leitura recomendada
- Melhores ferramentas de teste de software 2021 (QA Test Automation Tools)
- Trabalho de assistente de controle de qualidade de teste de software
- Curso de Teste de Software: Qual Instituto de Teste de Software devo ingressar?
- Escolhendo o teste de software como sua carreira
- Trabalho de freelancer de redator de conteúdo técnico de teste de software
- O teste de software é uma tarefa emocional?
- Algumas perguntas interessantes da entrevista de teste de software
- Comentários e análises do curso de teste de software