how classify positive
Você pode fazer algo da maneira fácil ou da maneira mais difícil - o importante é que você faça. Existem poucas coisas simples do dia a dia, mas sem confiança, algo sobre elas não se encaixa perfeitamente em nossas mentes e a extensão do sucesso é um sucesso ou um fracasso.
Vamos pegar um exemplo simples hoje e encontrar atalhos que não só irão esclarecer os conceitos, mas também garantir que você sempre acertará.
Classificação positiva ou negativa de cenários / casos de teste
O processo de design de teste é 3 vezes:
- Identifique os requisitos
- Escreva cenários de teste (indicações de uma linha do que testar)
- Projete instruções detalhadas sobre como testar (casos de teste)
Ao escrever cenários de teste, nós os classificamos em condições positivas e negativas. (Quando você pensa sobre isso, é realmente importante fazer essa classificação? Se sim, a que propósito isso serve? Temos que testar todos eles de qualquer maneira, não é?) Isso me bate também, na maior parte. Mas acho que é uma tentativa de estabelecer uma cobertura adequada e ajuda a estabelecer que estamos testando os caminhos felizes e alternativos que o sistema deve tratar. Comente abaixo, se você souber de quaisquer outros motivos pelos quais isso é feito.
Agora, vamos ver alguns requisitos, escrever cenários de teste e realizar a classificação.
# 1) Login :Um usuário que insere as credenciais corretas entra no sistema. Se as credenciais estiverem incorretas, o acesso será negado e uma mensagem de erro será exibida.
# 2) Ver produtos: Suponhamos que haja um catálogo online de todos os produtos disponíveis no sistema e ele os exibe em uma lista quando o link “Ver produtos” é clicado.
# 3) Logout: Ao clicar neste link, o usuário é desconectado.
Vou escrever alguns cenários de teste para esses requisitos.
Tabela A:Caminho certo
| ID do cenário de teste | Descrição do cenário de teste | Positivo negativo |
|---|---|---|
| TS_login_01 | Valide se o usuário efetua login com sucesso se as credenciais inseridas estão corretas | Positivo |
| TS_login_02 | Valide se o usuário não tem permissão para acessar quando as credenciais inseridas estão incorretas | Negativo |
| TS_ViewProduct_01 | Valide se todos os itens estão listados quando o link Exibir produtos é clicado | Positivo |
| TS_logout_01 | Valide se o usuário já conectado é desconectado do sistema quando o logout é clicado | Positivo |
No entanto, às vezes vejo o cenário de teste escrito assim.
Tabela B: Inscrições marcadasInternetsão cenários de teste inválidos.
| ID do cenário de teste | Descrição do cenário de teste | Positivo negativo |
|---|---|---|
| TS_login_01 | Valide se o usuário efetua login com sucesso se as credenciais inseridas estão corretas | Positivo |
| TS_login_02 | Valide se o usuário não tem permissão para acessar quando as credenciais inseridas estão incorretas | Negativo |
| TS_ViewProduct_01 | Valide se todos os itens estão listados quando o link Exibir produtos é clicado | Positivo |
| TS_ViewProduct_02 | Valide se todos os itens não estão listados quando o link visualizar produtos é clicado | Negativo |
| TS_logout_01 | Valide se o usuário já conectado é desconectado do sistema quando o logout é clicado | Positivo |
| TS_logout_02 | Valide se o usuário não faz logout quando o link de logout é clicado | Negativo |
Para o caso de login bem-sucedido, há um caso igual e oposto em que não será bem-sucedido. Nem todos os requisitos devem ser assim e, para eles, não há realmente nenhuma compulsão para escrever um cenário negativo.
Resumindo: nem todo requisito deve ter casos negativos.
Neste ponto, se você está pensando 'Como vou saber' ou 'Ainda não tenho certeza', aqui está uma folha de referências simples que o ajudará.
5 principais aplicativos espiões para Android
Se há uma generalização que podemos fazer sobre os aplicativos, é que eles são dinâmicos. A entrada (dados, cliques, etc.) que fornecemos fará com que o aplicativo seja de uma determinada maneira e gere uma determinada saída.
Uma correlação simples entre as variáveis de entrada e saída tornará isso fácil de compreender.
Vamos tentar o seguinte para login:
| Entrada | Resultado | Positivo negativo |
|---|---|---|
| Correto (informações de login corretas) | Correto (usuário conectado) | Positivo |
| Incorreto (informações de login incorretas) | Correto (uma mensagem de erro) | Negativo |
| Correto (informações de login corretas) | Incorreto - Falha no login | Bug / Defeito |
| Incorreto (informações de login incorretas) | Incorreto (o sistema faz o login) - “Que horror!” :) | Bug / defeito |
Portanto, como você pode ver na tabela acima, podemos dizer que categorizamos o fluxo primário como positivo e o fluxo alternativo (também o comportamento correto do aplicativo) é marcado como negativo.
Os dois últimos casos em vermelho são, na verdade, bugs. O teste é sobre a validação de requisitos e quando eles não funcionam conforme o esperado, encontramos bugs. Como não vamos validar para defeitos, os dois últimos casos são inválidos.
Seguindo a mesma linha de pensamento e aplicando-a para fazer logout e visualizar produtos, aqui está o que você receberá.
| Entrada | Resultado | Positivo negativo |
|---|---|---|
| Logout (clique) | Correto - Sai | Positivo |
| Logout (clique) | Incorreto - Permanece conectado | Bug / defeito |
| Ver produtos (clique) | Correto - Exibe produtos | Positivo |
| Ver produtos (clique) | Incorreto (não lista ou exibição de lista incorreta) | Bug / defeito |
Como você pode ver, para esses requisitos, não há a possibilidade de fornecer uma entrada incorreta. Portanto, não é necessário que haja cenários / casos de teste negativos gravados.
Considerações finais:
O sistema pode estar sujeito a entradas positivas ou negativas. De qualquer forma, o sistema deve gerar uma saída correta. Os casos que tendem a lidar com a entrada correta são positivos. Os que estão quase corretos, mas com entrada negativa, são negativos.
Algumas dicas:
# 1) Quando um casos de teste ponta a ponta são escritos para UAT ou até mesmo para testes de sistema, são sempre os casos de teste positivos que entram no fluxo.
#dois) Às vezes, a classificação é subjetiva.Por exemplo, se eu estiver excluindo algo em um site e receber uma mensagem de confirmação que me pergunta “Tem certeza de que deseja excluir esta entrada?” com as opções OK e Cancelar - para mim clicar em cancelar é um caso positivo. Mas alguns pensam que é negativo, pois a intenção principal da opção 'Excluir' é excluir e não cancelar a operação. Portanto, o julgamento de um testador também desempenha um papel na classificação.
# 3) Para cada caso positivo, nem sempre há um caso negativo igual e oposto.
O método acima sempre garante a classificação correta. Experimente você mesmo e me diga, se não funcionar. :) “Um atalho geralmente é um corte errado.” - Mas então, pode não ser neste caso!
Para obter uma explicação mais formal do teste negativo, verifique => O que é teste negativo e como escrever casos de teste negativos?
Sobre o autor: Este artigo foi escrito pelo membro da equipe STH Swati S. Junte-se ao curso de treinamento de controle de qualidade ao vivo aqui: “ O melhor treinamento de teste de software que você já teve! '
Informe-nos se gostou deste artigo e deseja ver quaisquer conceitos básicos explicados facilmente nos próximos artigos.
Seus comentários, perguntas, feedback e leitores são muito apreciados e valorizados aqui na STH. Bom teste!
Leitura recomendada
- Teste positivo: significado e méritos explicados com cenários de teste reais
- Como escrever casos de teste para uma página de login (exemplos de cenários)
- O que é teste negativo e como escrever casos de teste negativos?
- Como escrever casos de teste para máquina ATM (cenários de exemplo)
- Scripts Eficientes do Selenium e Cenários de Solução de Problemas - Tutorial # 27 do Selenium
- Tipos de teste de migração: com cenários de teste para cada tipo
- Tutorial de QTP nº 24 - Usando objetos virtuais e cenários de recuperação em testes QTP
- Testando aplicativos de saúde - dicas e cenários de teste importantes (parte 2)