Menu

Como lidar com requisitos inadequados como testador

how deal with bad requirements

Experimente Nosso Instrumento Para Eliminar Problemas

A sala de conferências silenciosa estava sufocando e todos dentro dela estavam confusos. Como poderíamos perder isso , foi a pergunta que o rosto de todos refletiu.

Afinal, não aparecer nenhum erro relevante quando o usuário tenta duplicar o registro existente e permitir que ele faça isso não foi um bug pequeno- Isso também para uma seguradora.

Depois de decidir resolver o problema, todos se dispersaram. E durante a escavação, foi observado que o cliente nunca mencionou nada sobre duplicidade de registros no documento de requisitos e, portanto, ninguém fez perguntas relevantes ou pensou sobre isso.

requisitos ruins

Este foi apenas um exemplo.

Em uma carreira de mais de 10 anos , Observei muitos casos em que os projetos sofreram devido a requisitos inadequados ou inadequados.

Mas, como se costuma dizer, nada é perfeito neste mundo e você terá que lidar com isso, e lidar com projetos sem requisitos ou com requisitos insuficientes é uma espécie de pesadelo.

Deixe-me explicar -

O que você aprenderá:

Como os requisitos ruins, insatisfatórios e conflitantes criam aborrecimentos:

# 1) Sem requisitos - Nenhum requisito implica suposições e suposições e, portanto, não há confiança. É muito difícil testar um produto / aplicativo sem qualquer linha de base. E isso resulta em mais trabalho, mais bugs do cliente e mais sofrimento para o projeto.

  • Como você relatar um problema sobre a falha do sistema quando não há definição de como o comportamento deve ser tratado está disponível?
  • Como você transmitiria que o tempo de carregamento de 100 segundos para a página inicial é inaceitável quando não há requisitos relevantes de desempenho?

Mais informações sobre Sem requisitos e como lidar com a situação durante o teste podem ser encontradas no artigo publicado anteriormente - Como testar um aplicativo sem requisitos?

# 2) Requisitos insuficientes - A citação, Saber algo incompleto é perigoso do que não saber de todo , é muito verdadeiro quando se trata de lidar com um requisito insatisfatório.

Interpretar um requisito insatisfatório e implementá-lo é um grande risco.

  • Como você confirmaria se o pop-up que mostra os resultados da pesquisa é válido ou não quando o único requisito mencionado era - os resultados da pesquisa devem ser adequados e você não tem certeza de quais critérios devem ser considerados durante a pesquisa.
  • Como você interpretaria isso - Esqueci a senha deve ser implementado para facilitar ao usuário a regeneração / redefinição da senha esquecida. Sem saber qual fluxo de trabalho o cliente deseja para o esquecimento da senha, o desenvolvedor implementa o que acha melhor e os conflitos começam.

# 3) Requisitos conflitantes - Pedir a alguém para fazer duas coisas diferentes ao mesmo tempo está apenas deixando-o confuso e o sistema também não é uma exceção.

  • Como você testaria um aplicativo com os requisitos mencionados abaixo:
    • O aplicativo deve sempre abrir na página inicial.
    • Espera-se que os usuários façam login para acessar o aplicativo.
  • O que você decidiria a prioridade quando o documento de requisitos fosse o seguinte:
    • O aplicativo de jogo deve promover o usuário para o próximo nível se ele marcar 1000.
    • O usuário deve ser redirecionado para a página de inscrição gratuita assim que marcar 1000.

E é assim que os requisitos ruins, ruins e conflitantes criam aborrecimentos.

Estar na indústria de software, deve ser parte do projeto, pois às vezes até mesmo o cliente não tem certeza do que exatamente deseja e como formular.

Do ponto de vista do teste, embora seja difícil lidar com esses requisitos ambíguos ou vagos, não é completamente impossível.

Vejamos as soluções possíveis:

Requisitos ruins e como lidar com eles como testador:

Método 1)Explorar e aprender:

Explorar outros aplicativos, aprender sobre o comportamento geral esperado, entender o fluxo de trabalho, pensar na conveniência do usuário e aplicar a lógica é uma maneira de lidar com a situação. Além disso, contando com testes exploratórios seria útil neste tipo de situações em que os requisitos não são claros.

Na maioria das vezes, é uma boa aposta priorizar a experiência do usuário e a conveniência quando os requisitos não são claros.

Método # 2)Utilize a experiência:

Utilize a experiência

Experiência de domínio , experiência geral de teste, problemas enfrentados no passado e percepções pessoais podem ajudar a resolver situações e requisitos confusos.

Método # 3)Referir wireframes:

Wireframes são um tipo de requisito visual onde você pode encontrar pequenos detalhes e esses detalhes podem ser muito úteis na criação da imagem esperada do produto ou aplicativo e auxilia na cobertura de aspectos de teste de uma maneira melhor.

Consulte Mais informação => Wireframes - Eles deveriam realmente ser testados? E se sim, como?

Método # 4)Discussão entre pares:

perguntas da entrevista de teste de software para candidatos experientes

Discussão entre pares

Não importa qual seja a confusão, se discutido com o grupo certo de pessoas, as coisas ficam esclarecidas. Todos carregam experiências, expectativas, olhos do usuário e visão de análise diferentes, e discutir esses requisitos insatisfatórios com os colegas servirá como um benefício para cristalizar a compreensão e aumentar a autoconfiança.

Método # 5)Esclarecimento do cliente:

O cliente é o proprietário do produto / aplicativo e é sempre aconselhável abordá-lo quando se trata de clareza de requisitos. Mas lembre-se, não é aconselhável atacar o cliente com centenas de perguntas. Antes de fazer isso, alguns trabalhos de casa são necessários.

Tente descobrir as melhores práticas disponíveis, entenda os benefícios da implementação e entre em contato com o cliente com perguntas e possíveis soluções.

Conclusão

Finalmente, requisitos vagamente definidos ou indefinidos fazem parte da vida do testador e precisamos aceitá-los, mas vamos tentar ser otimistas e determinar soluções para isso. Afinal, somos testadores, ajudamos a manter os aplicativos nos trilhos e evitamos que caiam. BEM para nós :)

Sobre o autor: Esta postagem inspiradora foi escrita pelo membro da equipe STH Bhumika M. Ela é líder de projeto, com mais de 10 anos de experiência em testes de software.

Bons testes, como sempre ... Aguardando seus pontos de vista, comentários e opiniões.

Leitura recomendada

^