Menu

6 habilidades básicas que todo testador (principalmente mais recente) deve ter

6 basic skills that every tester should have

Experimente Nosso Instrumento Para Eliminar Problemas

O teste de software ou QA é a melhor plataforma para os novatos entrarem no setor de TI, apesar dos equívocos de que é um trabalho com menor ou menor remuneração.

A habilidade mais importante que um testador precisa é a capacidade de encontrar bugs . E, se você é o tipo de pessoa que adora encontrar insetos, então vai amar e crescer neste campo.

Dito isso, existem mais algumas habilidades que podem ajudá-lo a encontrar bugs e trabalhar melhor com os processos de controle de qualidade.

Este é o artigo que mostrará o processo de QA como ele é seguido na maioria das empresas e fornecerá esclarecimentos sobre os testes aos novos testadores.

Em detalhes, você aprende o processo de documentação e os padrões, o pré-trabalho do testador, o teste baseado em restrições, o teste durante o desenvolvimento parcial e, finalmente, o processo de aprovação.

habilidades básicas de teste

Vamos começar.

O que você aprenderá:

melhor conversor de vídeo para windows 7

# 1. Documentação

A documentação é essencial para o teste. A maioria das empresas atribui essa tarefa aos recém-chegados. Para ter sucesso, você deve ter bom vocabulário porque o resto das coisas, como padrões de documentação, etc., não estão sob seu controle e dependem dos processos da equipe e da empresa.

Além disso, certifique-se de ver o valor do processo de documentação. As vantagens são muitas - ajudam a rastrear mudanças de requisitos, rastrear suas etapas de teste, registrar seu trabalho, etc.

Leitura recomendada=> Por que a documentação é importante no teste de software

# 2. Preparação de Teste

De todos os documentos disponíveis, o seguinte não pode ser negligenciado. Eles também são chamados de documentos de entrega e fazem a ponte entre o cliente, o desenvolvedor e o entendimento do testador.

a) Plano de Teste: Mapeia o fluxo de teste do início ao fim .

O plano de teste retrata o escopo e as atividades da fase de teste. Criada pelo líder de QA, a equipe deve contribuir e se manter atualizada sobre tudo o que está escrito no plano de teste.

Algumas equipes têm vários níveis de planos de teste: plano mestre e planos de fases.

Um plano de teste deve ter:

  • Nome e versão do projeto
  • Identificadores do plano de teste - criador, rascunho nº, data de criação, etc.
  • Introdução - Visão geral do projeto, objetivo e restrições
  • Referências - lista de referências usadas como entrada. (Certifique-se de usar as versões precisas e mais recentes)
  • Itens de teste - Módulos, versão, escopo, fora do escopo, etc.
  • Abordagem geral de teste / estratégia de teste - ferramentas a serem usadas, processo de rastreamento de defeitos, níveis de teste a serem executados, etc.
  • Critérios de item de aprovação / reprovação - diretrizes de execução de teste
  • Critérios de suspensão e retomada
  • Produtos de teste - caso de teste, relatórios de teste, relatório de bug, métricas de teste, etc.
  • Detalhes do ambiente de teste
  • Lista da equipe com informações do ponto de contato. para cada módulo ou tipo de teste
  • Estimativas de teste - Tempo e esforço. Os detalhes do orçamento são confidenciais e você não os encontrará aqui
  • Riscos e planos de mitigação
  • Aprovações
  • Outras diretrizes

Ler também=>

b) Cenários de teste:

Ponteiros de uma linha sobre 'o que testar' com base em cada requisito e geralmente documentados e rastreados por meio de planilhas.

A maioria deles contém:

  • Nome do módulo / componente / função (login, admin, registro, etc.)
  • O ID do cenário é para referência (por exemplo: TS_Login_001)
  • Descrição do cenário - ‘O que testar’ Por exemplo: Validar se o login permite que usuários com credenciais válidas façam login com sucesso
  • Importância do cenário - Priorizar em caso de tempo insuficiente - Alta / Média / Baixa
  • ID do requisito - para rastreabilidade

Leitura adicional=>

c) Casos de teste:

Casos de teste precisos fornecem resultados de teste precisos. Planilhas ainda são o meio popular para escrever casos de teste, especialmente para iniciantes, embora algumas empresas adaptem ferramentas de gerenciamento de teste. A base para a escrita do caso de teste é o documento SRS / FRD / Req. Porém, geralmente não é suficiente, então você terá que usar muitas suposições e discussões com as equipes BA / Dev.

Escrevendo casos de teste eficazes é a qualificação mais importante que um testador deve ter. Normalmente, todos os casos de teste são classificados como positivos / negativos. Caso de teste positivo está dando entradas válidas e obtendo resultados positivos. Caso de teste negativo está fornecendo entradas inválidas e recebendo a mensagem de erro exata.

Para obter mais informações sobre isso, verifique:

Alguns dos atributos comuns que todos os casos de teste têm são:

  • ID do cenário - tirado do documento do cenário de teste
  • ID do caso de teste - para identificação e rastreamento exclusivos. Ex .: TC_login_001
  • Descrição do teste - Breve explicação da condição de teste testada
  • Etapas para executar - instruções detalhadas passo a passo sobre como testar
  • Dados de teste - dados fornecidos para as etapas de teste
  • Resultado esperado - resultado conforme esperado
  • Resultado real - Resposta do AUT quando o teste é executado
  • Status - Aprovado / Reprovado / Sem execução / Incompleto / Bloqueado - Descreve o resultado do teste
  • Comentários - para detalhes adicionais
  • Executado por - nome do testador
  • Data de execução - Data em que o teste é executado
  • ID de defeito - Defeito registrado em relação ao caso de teste, em caso de falha do teste
  • Detalhes de configuração - sistema operacional, navegador, plataforma, informações do dispositivo (opcional)

Leitura recomendada=>

# 3. Processo de teste - quais testes realizar?

Há um grande número de tipos de teste, mas nem todos podem ser executados nesse AUT. Tempo, orçamento, natureza do negócio, natureza do aplicativo e o interesse do cliente são os principais jogadores na escolha de quais testes fazer no aplicativo.

Por exemplo: Se for um portal de comércio online, os testes de estresse e de carga são obrigatórios. No entanto, alguns dos tipos de teste que não devem ser perdidos são:

# 4. Teste no estágio de desenvolvimento parcial

Geralmente, com empresas de nível médio e start-up, o tempo e os recursos são limitados. Os testadores aqui podem iniciar seu processo de teste antes da integração do módulo, o que significa que podemos estar fazendo testes de integração de unidades e intermediários.

É importante observar que os resultados desses estágios não podem ser considerados precisos, portanto, pode ser necessário planejar um teste geral da caixa preta quando tudo estiver pronto para uso. Ignorar essa parte pode ser caro e os testes, ineficazes.

# 5. Documento de relatório de bug

Prático, este é o documento de controle de qualidade mais importante que você fará.

A seguir estão os campos que um bom relatório de bug deve ter:

  • ID de defeito - geralmente um número de série
  • Descrição do defeito - explicação de uma linha do problema
  • Localização - Módulo / área do AUT onde o problema é encontrado
  • Número da versão - Versão e código da versão no.
  • Etapas para reproduzir - lista das etapas que o levam ao problema
  • Gravidade - Defina um nível para descrever a gravidade do problema - baixo, médio, alto, bloqueador, etc.
  • Prioridade - Definida pelos desenvolvedores para determinar a ordem em que o defeito será corrigido (P1, P2, P3, etc. P1- mais alto)
  • Atribuído a - Proprietário do defeito naquele momento
  • Relatado por - nome do testador
  • Status - Status diferente para representar o estágio do ciclo de vida do bug
    • Novo - Bug foi encontrado e acabou de ser relatado
    • Aberto - validado pelo líder de QA
    • Atribuído - Enviado ao líder de desenvolvimento para atribuição ao respectivo desenvolvedor
    • Em andamento / Trabalho em andamento - Dev começou a trabalhar nisso
    • Fixo / Resolvido - o desenvolvedor concluiu o trabalho nisso
    • Verificado / fechado - A equipe de QA testou novamente e encontrou o bug corrigido
    • Reteste - a equipe de QA não concorda com a resolução do Dev e prossegue com o bug para retrabalho
    • Duplicar - bug semelhante já existe
    • Adiado - bug válido, mas será corrigido em versões posteriores
    • Inválido - Não é um bug ou não é reproduzível ou não há informações suficientes

Leitura adicional=>

# 6. Processo de aprovação

cancelar assinar e o envio da documentação final é tarefa do líder / gerente de QA. No entanto, a equipe deve enviar os documentos acima (cenário de teste, caso de teste e documento de registro de defeito) para revisões finais e auditoria.

Certifique-se de revisar todos eles e enviar as versões finais.

Ler também=>

Conclusão

Este é o processo que testemunhei e experimentei em primeira mão quando era um testador e espero que isso tenha lhe dado algumas dicas úteis.

Por fim, uma carreira de teste tem sido uma alegria absoluta para mim e espero que seja para você também.

Tudo de bom para sua carreira!

Leitura recomendada

^