Os sete pecados capitais da garantia de qualidade: erros que todo testador deve evitar!

Vi um artigo[1] há alguns dias. O título é um pouco interessante. Traduzi-o casualmente e achei-o pertinente no geral.

Luxúria: dependência excessiva da tecnologia

Sintomas: a maioria de suas atividades de teste se transforma em “lançar esta automação”, “lançar aquele pipeline de teste”, mas o mais importante é mantê-las.

É bom querer encontrar a melhor tecnologia para o seu projeto e automatizar o máximo de tarefas possível. Mas se você for muito teimoso, acabará com um monte de código que precisa ser mantido. Quando você está com o nariz enterrado no código, às vezes você esquece o que é mais importante.

Tratamento: Mantenha o equilíbrio: siga boas práticas de manutenção, baseie sua estratégia em uma pirâmide de testes... mas o mais importante, faça aqueles malditos testes manuais!

Ganancioso: Quer encontrar todos os bugs

Sintomas: seus testes demoram muito, você encontra muitos bugs sutis ou alguns casos de uso muito marginais e, na maioria das vezes, eles nunca são corrigidos.

Tentar encontrar bugs em todos os novos desenvolvimentos é uma batalha perdida. Você tem que aceitar o fato de que não será capaz de encontrar todos os bugs, mas pelo menos encontrar aqueles que têm maior probabilidade de serem detectados.

Além disso, testar avidamente é como testar sem método: você nunca melhorará suas habilidades de teste.

Tratamento: Obrigue-se a fazer o teste por um tempo limitado. Isso completará seus recursos de teste. Procure primeiro os erros mais óbvios. Se você ainda tiver tempo suficiente, finalmente procure alguns casos de uso complicados.

Não se preocupe com problemas não descobertos. Confie no processo. Um bom sistema de monitoramento e feedback do usuário permitirá detectar efetivamente bugs que não podem ser detectados durante a fase normal de teste.

Raiva: culpar um indivíduo

Sintomas: quando está sob pressão, é fácil culpar a equipe ou o indivíduo por escrever um grande bug. Quando há um problema óbvio, as pessoas tendem a apontar a pessoa que se acredita ser a culpada.

Lembre-se, esta situação geralmente é resultado de uma combinação de fatores: prazos apertados, falta de disciplina, falta de processos, software muito complexo para manter, etc. Portanto, nunca culpe os indivíduos – é ultrapassado e contraproducente.

Terapia: Concentre-se no problema, não na pessoa. Lembre-se de que todos os erros podem ser vistos como oportunidades para melhorar processos e entregar melhores resultados. Aprenda com isso. Mas também preste atenção à comunicação. A raiva geralmente vem de um desalinhamento entre suas expectativas e a realidade, portanto, compreenda as capacidades de sua equipe, mantenha linhas de comunicação abertas e estabeleça metas claras e alcançáveis.

Ganancioso: acumule todas as atividades de teste

Sintomas: Todas as tarefas relacionadas à criação e manutenção de testes são limitadas a uma pessoa ou a uma equipe muito pequena, especialmente devido ao tamanho de toda a equipe.

Isto resulta em:

• Gargalos no processo de teste. •A dependência excessiva de um pequeno grupo de pessoas cria riscos se algum membro não estiver disponível. •As pessoas que realizam essas tarefas correm maior risco de esgotamento.

Tratamento: Distribua as responsabilidades de teste dentro da equipe para obter vários insights e minimizar atrasos. Promover o trabalho em equipe e compartilhar conhecimento para melhorar a qualidade do processo de teste e do produto final.

Preguiçoso: ignorando a documentação

Sintomas: A equipe tem pouco conhecimento do que foi testado. Muitos recursos têm especificações pouco claras ou nenhuma especificação. Poucos erros são rastreados.

Os testadores preguiçosos verificam apenas os casos de teste escritos sem considerar outras partes do processo de teste, especialmente a documentação.

Sem documentação, as atividades de teste podem tornar-se bastante invisíveis. Simplesmente porque a documentação é uma parte inerente do processo de teste. Você testa, observa e escreve suas observações em um relatório de teste. Isto realiza a especificação, como gosto de dizer: especificando o inespecificável.

Tratamento: Crie um relatório de teste contendo as seguintes seções:

1. Descrição da função: Descreva as funções do teste. 2. Objetivo do teste: O objetivo principal do teste. 3. Etapas de teste: operações sequenciais repetíveis. 4. Resultados esperados versus resultados reais: resultados previstos versus resultados observados. 5.Bug/Problema: Um problema registrado, com uma referência (se registrado). 6. Ambiente de teste: detalhes de software, hardware e rede. 7. Anexos: Links para capturas de tela, registros ou arquivos relacionados. 8. Comentários: Notas ou observações adicionais do testador.

Ciúme: compare com outros projetos

Sintoma: a equipe de controle de qualidade se compara. Alguns executivos chegam a comparar o número de bugs encontrados nos diferentes produtos da empresa. Isso pode levar ao ciúme.

Cada projeto tem desafios diferentes e, portanto, necessidades de controle de qualidade diferentes. Esses projetos podem estar em diferentes estágios de maturidade, podem ter diferentes recursos, diferentes usuários, etc.

Tratamento: Todas as equipes precisam entender o contexto de cada projeto. Comemore os sucessos de cada equipe, mesmo os pequenos, e aumente a visibilidade dos projetos.

Arrogância: Ignorando os usuários

Sintomas: A equipe está muito confiante em testar a tecnologia por conta própria. Eles ficaram cegos por suas próprias métricas, o que provou que estavam certos.

Cada vez menos pessoas sabem como os usuários usam os produtos. Além disso, não há feedback real do usuário.

Este é provavelmente o mais perigoso de todos os pecados porque nem sempre é reconhecido imediatamente e, quando o é, muitas vezes é porque um bug óbvio surge e dispara o alarme.

R: Por que você não viu esse bug?

B: Eu não entendo. Todas as luzes estão verdes. Concluímos todos os testes com sucesso.

Chegou a hora de uma transformação completa do processo de controle de qualidade.

Tratamento: Erros graves também são aqueles com os quais mais aprendemos. Adapte-se a eles. Adapte os testes a cenários de usuários reais. O QA deve ter o conhecimento funcional necessário para conduzir os testes mais apropriados. Realize reuniões de rastreamento de usuários. Incorpore o feedback do usuário e cresça com cada experiência.


Agora é sua vez. Você já experimentou ou encontrou algum desses pecados em suas experiências anteriores? Como você os superou? Deixe seus comentários.

Finalmente: O vídeo tutorial completo de teste de software abaixo foi compilado e carregado. Amigos que precisarem podem obtê-lo sozinhos [garantido 100% gratuito]

Documento de entrevista de teste de software

Devemos estudar para encontrar um emprego bem remunerado. As perguntas da entrevista a seguir são os materiais de entrevista mais recentes de empresas de Internet de primeira linha, como Alibaba, Tencent, Byte, etc., e alguns chefes da Byte deram respostas confiáveis. Depois de terminar este conjunto Acredito que todos podem encontrar um emprego satisfatório com base nas informações da entrevista.

Acho que você gosta

Origin blog.csdn.net/AI_Green/article/details/133186139
Recomendado
Clasificación