acceptance testing documentation with real time scenarios
Documentação de Teste de Aceitação (Parte II):
Tutorial Anterior | PRÓXIMO Tutorial
Este tutorial é a continuação de nosso tutorial anterior, onde discutimos o que é teste de aceitação, quando deve ser feito, quem o faz, sua importância, tipos, processo, impacto em diferentes equipes, etc.
ferramenta de verificação e reparo de pc windows 10
Os documentos desempenham um papel muito importante no Teste de Aceitação e quaisquer problemas relacionados ao documento têm um grande impacto negativo. Quando uma verificação adequada não é realizada, pode até levar à Falha do Produto.
=> Clique aqui para obter a série de tutoriais do plano de teste completo
Neste tutorial, aprenderemos mais sobre as diferentes documentações envolvidas no Teste de Aceitação, ou seja, Plano de Teste de Aceitação, Lista de Verificação de Revisão do Plano de Teste, Modelo de Teste de Aceitação, exemplos baseados em cenários em tempo real, como identificar e escrever testes de aceitação, etc. em detalhes .
O que você aprenderá:
- Plano de Teste de Aceitação
- Modelo de plano de teste de aceitação
- Revisão do plano de teste de aceitação
- Testes de aptidão
- Revisão de testes de aceitação
- Conclusão
- Leitura recomendada
Plano de Teste de Aceitação
Como qualquer outro plano de teste, o plano de teste de aceitação também inclui alguns componentes como escopo, abordagem, ambiente de teste, recursos, responsabilidades, referências de testes de aceitação, critérios de entrada, critérios de saída, ferramentas, etc.
A única coisa que diferencia o plano de teste de Aceitação de um plano de teste regular são seus fatores que resultam em Decisão de Negócios. O Plano de Teste de Aceitação é uma das documentações vitais que fornece orientação sobre como realizar o teste de aceitação para um projeto específico.
O plano de teste de aceitação deve ser revisado e aprovado antes da execução do teste de aceitação. Todas as alterações subsequentes devem passar por um processo de revisão e aprovação e devem estar em andamento.
A revisão do plano de teste de aceitação geralmente é feita por gerentes / analistas de negócios / clientes.
Pontos-chave a serem considerados ao projetar o Plano de Teste de Aceitação:
- Deveria ser Detalhado e específico. Deve incluir apenas o que é necessário para o teste e quais informações são necessárias para a equipe realizar o teste.
- Deveria ser Claro e conciso . Sem ambigüidade. Se houver algo que possa causar confusão, elabore-o, mas seja breve e eficaz.
- Cada um dos componentes no documento deve ser escrito tendo apenas os requisitos de negócios em mente.
- Confiável e adaptável - Deve ser atualizável conforme necessário nas versões futuras.
- Consistente - Não deve haver mais mudanças no futuro.
- Siga o modelo fornecido pela Organização ou Cliente.
Modelo de plano de teste de aceitação
Aqui, daremos uma olhada em um modelo comum para o Plano de Teste de Aceitação, que pode ser ainda mais ajustado de acordo com os requisitos do projeto.
Título
Objetivo
Histórico de revisão / registro de alterações
< Deve ser em forma de tabela com as informações abaixo:
- Encontro - A data em que o documento foi modificado.
- Modificado por - Quem alterou o conteúdo do documento.
- Propósito - Por que o documento foi modificado.
- Versão - Versão atual do documento após as modificações (vai como 1.0, 1.1, 1.2, 1.3, ... para uma versão específica. A próxima versão começará a partir de 2, 2.1, 2.2, 2.3, ..., A lista continua).
- Aprovado por - Quem aprovou as alterações feitas (implicitamente significa que o documento foi revisado e aprovado).
A primeira linha nesta tabela deve ser os detalhes do documento criado. Em seguida, segue os detalhes das alterações feitas.>
Índice
Referências
Escopo
Introdução
Itens de teste
Recursos a serem testados
Recursos que não devem ser testados
Aproximação
Detalhes do ambiente de teste
Critério de entrada
Testes - Se não houver testes de aceitação escritos separados
Cada teste deve incluir:
- Teste #.
- Uma descrição do que está sendo testado ( Exemplo : Verifique se um usuário é capaz de criar uma conta com sucesso).
- Requisito de negócios para o qual este teste mapeia ( Matriz de rastreabilidade ) - Muito importante.
- Pré-condições:
- Estado do produto antes de iniciar o teste (o usuário deve ser registrado com sucesso, mas não ativou a conta, o usuário deve ter acessado o produto pelo menos 30 dias atrás, etc.)
- Quaisquer condições do servidor - deve o servidor ficar inativo por algum tempo.
- Etapas do teste: Fluxo numerado detalhado ( Exemplo: ver abaixo
- Abra o aplicativo.
- Tente fazer o login com credenciais válidas com a caixa de seleção Lembrar de mim marcada).
- resultado esperado : Qual é o comportamento esperado da etapa>
Testes de Aceitação - Se houver testes de Aceitação separados escritos
Critério de saída
Recursos
Papéis e responsabilidades
Ferramentas
Fatores de decisão de negócios
Procedimento de assinatura
Ponto de contato
O plano de teste de aceitação é considerado como o Plano de teste mestre para a fase .
Revisão do plano de teste de aceitação
Assim que o plano estiver pronto, ele deve ser revisado quanto à integridade, não ambiguidade, clareza, qualidade, etc. Sem dúvida, todo o conteúdo do plano de teste de Aceitação deve ser revisado minuciosamente para obter informações adequadas, mas, deve ser revisto em relação a alguns outros pontos, digamos, pontos da lista de verificação.
Aqui, vamos categorizar o conteúdo e ver os pontos da lista de verificação em relação a ele.
| Categoria | Pontos da Lista de Verificação |
|---|---|
| Testes de aptidão | Os testes são numerados As pré-condições são numeradas As etapas do teste são claras para entender As etapas do teste estão concluídas O resultado esperado está completo Existe alguma questão em aberto nos testes (se houver, acompanhe e conclua) A referência aos testes de aceitação (se escritos separadamente) é válida e existente A rastreabilidade está correta Existe algum requisito de negócio que não foi abordado para o teste |
| Título | O título corresponde ao título do projeto, conforme referido em todos os lugares O título segue as convenções de nomenclatura do projeto |
| Histórico de revisão, índice | Todas as modificações de versão são rastreadas adequadamente para o plano Todas as alterações de versão passaram por revisão adequada e são mencionadas A convenção de controle de versão está correta O índice corresponde ao conteúdo real do plano O número da página para cada conteúdo está correto? O número da página é atualizado se as modificações feitas no plano mudaram o número da página do conteúdo |
| Referências | As referências são existentes e válidas Eles combinam com o escopo Eles estão completos e considerados para identificação de testes |
| Itens de teste, recursos a serem testados, recursos a não serem testados | Eles são numerados Cada recurso / módulo / sub-módulo está dentro do escopo O cronograma planejado pode cobrir todos os itens de teste identificados dentro |
| Critérios de entrada, critérios de saída | Eles são numerados Todos os critérios são mencionados em detalhes |
| Detalhes do ambiente de teste | É ter todas as configurações necessárias mencionadas A versão de cada configuração é específica ou mais recente a ser considerada Faça as VMs, ambiente existe (se não, cite data possível para sua disponibilidade) O método de compartilhamento de credenciais para acesso a um ambiente específico foi mencionado? |
| Recursos, funções e responsabilidades | As responsabilidades de cada função são numeradas As responsabilidades podem ser cumpridas O recurso identificado é capaz de lidar com as responsabilidades mencionadas |
| Ferramentas | Todas as ferramentas são mencionadas Todas as ferramentas são numeradas Todas as ferramentas têm versão Alguma ferramenta precisa de licença ou a licença existente é válida durante a fase A orientação para o uso da ferramenta é correta e suficiente |
| Fatores de decisão de negócios | Tem todos os fatores mencionados Todos os fatores são numerados |
| Procedimento de assinatura | O procedimento é válido O procedimento é aceitável O procedimento é claro para entender |
| Ponto de contato | É o recurso identificado como ponto de contato disponível na organização durante a fase O recurso identificado é capaz de lidar com a fase |
Qualquer plano de teste que satisfaça o documento da lista de verificação acima também servirá como um documento forte para auditorias internas.
Testes de aptidão
Os testes de aceitação eram conhecidos anteriormente como testes funcionais. A fim de tornar o nome mais adequado para a fase de teste de Aceitação e atender ao propósito, ele foi renomeado como Testes de aptidão. Às vezes, também é denominado como Testes do cliente.
Os testes de aceitação são sempre derivados de histórias de usuários, critérios de aceitação e casos de uso. Esses são testes de sistema de caixa preta e representam apenas os testes de negócios que precisam ser verificados. Elas devem ser destinadas principalmente ao comportamento, uso e fluxos do produto.
Os testes de aceitação projetados também podem ser levados em consideração para a fase de teste do sistema nos ciclos de regressão para ganhar confiança no produto antes de transferi-lo para a fase de teste de aceitação.
Pontos-chave a serem lembrados antes de escrever os testes de aceitação:
- Mantenha todos os documentos de referência no lugar: Especificação de requisitos de software, documento de requisitos de negócios, casos de uso, histórias de usuários, matriz de dados (no caso de lógica envolvida) etc.
- Concentre-se apenas nos requisitos de negócios (requisitos de negócios testáveis).
- Limpe todas as dúvidas, consultas sobre os requisitos do negócio, o mais rapidamente.
- Certifique-se de que não haja mudanças nos requisitos para a versão atual, pelo menos.
Modelo geral e simples para escrever testes de aceitação:
Este modelo pode ser novamente ajustado de acordo com as necessidades do projeto e com mais informações a serem incluídas.
Agora, vamos pegar alguns cenários comuns e ver como os cenários de teste de aceitação podem ser escritos neles.
Caso 1: tratamento da conta do usuário
Este é o cenário onde os usuários têm permissão para criar, visualizar, atualizar e desativar suas contas. Em geral, é uma operação CRUD (Criar, Ler, Atualizar e Excluir). Então, diretamente, teremos 4 cenários principais para testar.
Junto com isso, no tratamento de contas de usuário em tempo real, temos muitas áreas quando se trata de visualização e atualização.
Prosseguindo com a escrita de testes de aceitação:
Teste 1: registro / inscrição / criação de conta, verifique se um usuário é capaz de:
- Crie a conta.
- Ative a conta.
- Ative a conta apenas uma vez (aqui, o link de ativação deve ser testado para 2WLEmbora seja um teste negativo, é um dos principais pontos de verificação a serem considerados).
Teste 2: para acessar e visualizar as informações da conta, verifique se um usuário é capaz de:
- Faça login na conta.
- Visualize diferentes seções no Perfil (se a seção Perfil for categorizada, todas as categorias devem ser visualizadas).
- Verifique se os dados exibidos no Perfil estão corretos de acordo com a entrada do usuário.
Teste 3: para atualizar as informações da conta, verifique se um usuário é capaz de:
- Atualizar informações da conta (perfil):
- Atualize cada uma das categorias do Perfil.
- Verifique se as informações de atualização estão refletidas corretamente no Perfil.
- Verifique se o usuário não é capaz de atualizar as informações no perfil (em alguns aplicativos, o nome, o sobrenome, o nome de usuário, etc. não terão permissão para atualizar. Embora seja um teste negativo, é um dos principais pontos de verificação Para ser considerado).
- Cancele o fluxo de atualização (embora seja um teste negativo, é também um dos principais pontos de verificação a serem considerados).
Teste 4: se a desativação da conta for permitida, verifique se um usuário é capaz de:
- Desative a conta.
- Cancele o fluxo de desativação (embora seja um teste negativo, é um dos principais pontos de verificação a serem considerados).
- Acesse a conta após cancelar a desativação.
Teste 5: se forem necessárias verificações para um endereço de e-mail ou números de telefone, verifique se um usuário é capaz de:
wow em qual servidor jogar
- Atualize o endereço de e-mail para outro válido.
- Verificar ”endereço de e-mail atualizado.
- Verifique se o endereço de e-mail atualizado e “verificado” é considerado posteriormente - Envie alguns e-mails do aplicativo e verifique sua chegada ao endereço de e-mail atualizado. O antigo não deve receber e-mails.
- Adicione o novo número de telefone.
- Verifique o número de telefone adicionado por meio de Chamada.
- Verifique o número de telefone adicionado por SMS.
- Verifique se o número de telefone adicionado e “verificado” está refletindo na conta.
- Atualize o número do telefone.
- Verifique o número de telefone atualizado por meio de Chamada.
- Verifique ”número de telefone atualizado por SMS.
- Verifique se o número de telefone atualizado e “verificado” está refletindo na conta.
Caso 2: Compra de Produto
A compra do produto geralmente segue o fluxo geral.
Alguns cenários gerais para os quais os usuários finais olham estão listados aqui:
Condição prévia: O usuário deve estar conectado ao aplicativo.
Teste 1: Detalhes do produto, verifique se um usuário é capaz de:
- Visualize a página de detalhes do produto.
- Visualize todas as subseções na página de detalhes do produto (descrição, recurso, informações da marca, etc.).
- Selecione a quantidade do produto, cor, tamanho, etc. conforme disponível na página de detalhes do produto.
- Navegue até as páginas de categoria e subcategoria na página Detalhes do produto (se disponível na página Detalhes do produto).
- Navegue até a página de detalhes do outro produto (se fornecida a seção de produtos relevantes).
- Veja comentários e avaliações sobre o produto.
- Classifique os comentários do produto com base nas avaliações.
- Veja a classificação geral do produto.
- Adicione um comentário sobre o produto.
- Atualize seu comentário sobre o produto.
- Exclua seu comentário sobre o produto (se fornecido).
Teste 2: Adicionar ao carrinho, verifique se um usuário é:
- Capaz de adicionar o produto ao carrinho:
- Por meio da página de detalhes do produto.
- Por meio da página da lista de produtos.
- Capaz de adicionar a quantidade necessária ao carrinho (1 ao limite máximo definido).
- Não é possível adicionar o produto ao carrinho se estiver esgotado.
Teste 3: na página do carrinho, verifique se um usuário é capaz de:
- Visualize o produto no carrinho com os detalhes do preço para a quantidade adicionada.
- Quantidade de atualização (1 para conjunto de limite máximo).
- Remova o produto do carrinho.
- Navegue de volta para fazer compras.
- Continue para o checkout.
- Ver carrinho vazio quando nenhum produto for adicionado,
Teste 4: na página de detalhes da conta, verifique se um usuário é capaz de:
- Continue com os detalhes de envio existentes.
- Atualizar endereço de envio.
- Adicione um novo endereço de entrega.
- Continue com o número de telefone existente.
- Atualize o número de telefone do pedido.
- Adicione um novo número de telefone para o pedido.
- Navegue de volta para a página do carrinho.
- Navegue até a página Pagamento.
Teste 5: na página de pagamentos, verifique se um usuário é capaz de:
- Verifique a exatidão do valor a ser faturado.
- Processe o pedido com todas as opções disponíveis (uma opção para cada pedido separado).
- Transação de processo com sucesso. Vá para a página de confirmação do pedido.
- Falha na transação (mesmo que seja um teste negativo, deve ser considerado um cenário principal).
- Aplicar cupons:
- Cupons válidos - sucesso. Verifique aqui a variação do valor a ser faturado.
- Cupons inválidos - Falha
- Cupons expirados - Falha.
- Navegue de volta para a página de detalhes da conta.
Revisão de testes de aceitação
A revisão dos testes de aceitação é uma tarefa importante, pois precisa ser correta e precisa com relação aos requisitos de negócios. Como podem ser conduzidos pelos próprios Clientes e / ou usuários finais, é muito necessário ser completo, não ambíguo, correto e detalhado o suficiente para que qualquer pessoa possa entender e executar.
A revisão dos testes de aceitação deve ser feita por analistas de negócios, clientes e quaisquer comentários de revisão devem ser incorporados em alta prioridade.
No nível de teste individual, a revisão deve ser feita em relação ao seguinte:
- Se o teste cobre os requisitos do negócio ou não.
- As pré-condições são claras?
- As etapas do teste são fáceis de entender e detalhadas?
- O resultado esperado está correto e claro?
- Ele está mapeado para os requisitos de negócios para rastreabilidade?
- O teste está completo o suficiente para cobrir o fluxo ou uso específico?
- O teste específico é exigido como parte do teste de aceitação.
- Existe algum ponto de verificação que não é necessário para o teste de aceitação.
- É puramente funcional ou qualquer GUI é abordada (deve ser apenas funcional).
- Os dados de entrada especiais são necessários? Em caso afirmativo, é fornecido para detalhes?
De modo geral, toda a análise do conjunto de testes de aceitação deve abranger:
- Rastreabilidade bidirecional: Requisitos de negócios para testes E testes para requisitos de negócios.
- Todos os requisitos de negócios são atendidos?
- Todos os requisitos de negócios são cobertos por um ou mais testes?
- As regras de negócios estão cobertas?
- O caso de dados especial é tratado?
- Quantos testes são escritos para cobrir cada requisito ou regra?
- Os testes podem ser agrupados e classificados para fluxos.
- Os testes estão sequenciados corretamente para que a execução seja eficiente?
Conclusão
Em suma, como mencionado anteriormente, os documentos desempenham um papel muito drástico nos testes de aceitação.
Portanto, qualquer teste de aceitação escrito deve ser bem estruturado e em conformidade com seu uso, de modo que mantenha os testadores de aceitação interessados no que estão testando e em como o estão fazendo. Isso, por sua vez, traria automaticamente o sucesso.
=> Visite aqui para obter a série de tutoriais do plano de teste completo
Tutorial Anterior | PRÓXIMO Tutorial
Fique ligado e assista ao próximo tutorial de Teste de Aceitação para saber mais sobre Relatórios de Teste de Aceitação junto com alguns modelos genéricos. Além disso, deixe-nos saber se você tiver alguma dúvida.
Leitura recomendada
- Melhores ferramentas de teste de software 2021 (QA Test Automation Tools)
- Teste positivo: significado e méritos explicados com cenários de teste reais
- Download do e-book do Testing Primer
- TimeShiftX lançado para simplificar os testes de mudança de horário
- O que é teste de aceitação (um guia completo)
- Modelo de amostra para relatório de teste de aceitação com exemplos
- Você é um especialista em testes manuais ou de automação? Trabalhe a tempo parcial para nós!
- Teste de carga com tutoriais HP LoadRunner