Menu

Como testar um aplicativo sem requisitos?

how test an application without requirements

Experimente Nosso Instrumento Para Eliminar Problemas

Tecnicamente, não existem aplicativos sem requisitos. Imagine um software que não faz nada específico, mas simplesmente linha após linha de código se estendendo. Será uma escada que leva a lugar nenhum.

Todo software tem requisitos e é direcionado a uma tarefa específica; especificamente, é uma solução para um problema. Então sem requisitos software não é uma possibilidade.

No entanto, software sem requisitos documentados é uma realidade que, infelizmente, a maioria de nós enfrenta com mais frequência que nós gostamos. A única coisa pior pode ser que a documentação é insuficiente, imprecisa ou terrivelmente desatualizada. Infelizmente, isso também acontece.

teste sem requisitos

Honestamente, não há realmente nenhum substituto para um documento de requisitos de sistema / funcional bem documentado com casos de uso elaborados e telas de simulação. Embora tenhamos que admitir que isso está se tornando uma raridade na indústria devido aos ciclos de desenvolvimento rápidos e uma mudança de paradigma em direção ao mínimo ou nenhuma documentação.

Portanto, este artigo é uma tentativa de algumas práticas que seguimos quando nos encontramos nessas situações.

Leia também:

baixar downloader de música mp3 para android

Vamos primeiro dar uma olhada em alguns razões pelas quais pode não haver documentação, para começar:

  1. Projeto arquivado sendo reaberto
  2. Documentação menos formato de trabalho - Processo
  3. A documentação pode existir, mas pode não ser detalhada ou completa
  4. Lançamentos contínuos e as informações relacionadas à versão mais antiga não foram arquivadas, resultando em uma lacuna na compreensão de como a funcionalidade existente reage com a nova

Todos esses são impedimentos que nós, testadores, temos que enfrentar bravamente e emergir com sucesso. Como exatamente, certo?

Aqui estão os três principais métodos para testar um aplicativo sem requisitos:

Método 1:

Trabalhe com qualquer pequena documentação que puder. Pode ser um backlog básico simples (em projetos ágeis), um arquivo de ajuda, um e-mail, uma versão mais antiga do BRD / FRD ou casos de teste antigos (verifique se há em suas ferramentas de ALM e você pode encontrá-los), etc.

Investigue, pergunte e sempre haverá algum teste documentado, mesmo que seja um teste ralo.

Quando isso não funcionar, não descarte sua experiência como usuário de software.Por exemplo, se você tiver que testar uma operação de transferência para uma conta bancária, ninguém precisa nos dizer como fazer isso, não é? Porque, como clientes de serviços bancários online, todos sabemos que precisamos de e para contas com vários fundos disponíveis para transferência.

Concordou que nem todas as situações serão tão simples, mas, novamente, podem ser.

Método 2:

Use a versão mais antiga / atual do aplicativo como referência para testar o lançamento futuro de um produto de software. Agora, eu admito que isso é uma negação da regra, “Nunca escreva casos de teste usando o aplicativo como referência”. No entanto, quando estamos trabalhando em uma situação que não é perfeita, temos que moldar as regras para atender às nossas necessidades.

Isso ajuda a manter os seguintes aspectos em perspectiva ao fazer isso:

  • O aplicativo pode conter bugs - portanto, se após o registro o sistema levar você diretamente para a Tela1 (uma determinada tela hipotética para o nosso exemplo) - Nunca presuma que esse é o comportamento correto. Além disso, se um campo leva caracteres alfanuméricos e é um número de telefone, uma pergunta e certifique-se de não tomar o aplicativo como um exemplo garantido para a funcionalidade esperada.
  • Nas situações acima, use seu julgamento e tenha a ajuda do aplicativo para dar um impulso, mas seja crítico para questionar se está funcionando.

Método # 3:

Fale com os membros da equipe do projeto:

  • Ofereça-se para participar de suas reuniões.
  • Pergunte se você pode participar das etapas de teste de unidade e integração.
  • Caso contrário, pergunte se a equipe de desenvolvimento pode compartilhar seus resultados de teste de unidade e integração.
  • Organize um horário para a transferência de conhecimento em um momento conveniente.

Agora, vamos aplicar os métodos em um exemplo:

Vamos supor que existe um site de compras onde você pode adicionar itens ao carrinho de compras. Idealmente, se houvesse documentação, ela precisa nos dizer como adicionar itens a ele, quantos itens pode ter em um determinado momento, o que acontece quando o item que você adicionou de repente fica sem estoque, qual é o número máximo dos mesmos itens que você pode comprar ao mesmo tempo, etc. Nossa situação é que NENHUM deles está disponível no momento.

Aplicar método nº 1:

Encontre qualquer documentação que você puder. Pergunte à sua equipe de desenvolvimento se eles têm telas de simulação / look na ferramenta ALM ou qualquer outra coisa. Se você encontrar algo, esse seria um bom ponto de partida. Mas se esse método não resultar em nada, você pode usar o seu julgamento / intuição do testador.

Todos nós sabemos como funcionam os carrinhos de compras, por isso faça suposições e chegue a alguns cenários básicos, como:

  • Os itens podem ser adicionados ao carrinho de compras após serem navegados ou pesquisados
  • Depois de adicionar itens ao carrinho de compras, a lista de itens deve ser atualizada
  • O usuário deve ser capaz de continuar comprando mesmo depois de adicionar alguns itens ao carrinho
  • Adicionar o mesmo item duas vezes fará com que a contagem dos itens adicionados seja incrementada
  • Os itens podem ser atualizados
  • Os itens podem ser removidos
  • O total deve ser equivalente à soma de todos os preços adicionados
  • Os impostos devem ser calculados com base no código postal inserido
  • Os custos de envio devem ser adicionados de acordo

Podemos continuar, mas tenho certeza de que você entendeu.

Aplicar Método 2:

Se houver uma versão mais antiga do aplicativo disponível, isso pode ser útil para escrever seus casos de teste, pois você terá que escrever as etapas exatas de onde clicar, onde inserir a entrada, o que verificar etc. Capturas de tela / maquetes / fios- quadros - se disponíveis, podem ser ótimos substitutos também.

Como você pode ver na tela abaixo, essas coisas são aparentes - os nomes dos campos, os botões ou outros elementos presentes, etc. (clique na imagem para ampliá-la)

teste sem requisitos

Agora, neste ponto, os testadores têm algumas perguntas como:

  1. O que acontece quando eu dou um char na caixa de valor?
  2. Quando adiciono muitos itens?
  3. Qual é o máximo não. de itens que isso pode levar? Etc.

Aplicar Método # 3 :

Leve sua lista de dúvidas ao BA, Desenvolvedor ou até mesmo ao cliente e busque esclarecimentos. Uma vez que o método 3 é feito, você deve estar equipado com todas as informações necessárias para escrever casos de teste detalhados e realizar seus testes com a mesma confiança que faria quando uma documentação elaborada estivesse disponível.

Concordou que são muito mais etapas e muito mais acompanhamento, mas para garantir os testes de qualidade, essas etapas são inevitáveis.

Para concluir, nem tudo está perdido quando a documentação não existe ou é insuficiente. Ainda há esperança! Por favor, compartilhe suas experiências em situações semelhantes.

Sobre o autor: Esta postagem útil foi escrita por nosso membro da equipe STH, Swati S.

Como sempre, seus comentários, perguntas e sugestões são muito bem-vindos.

Leitura recomendada

^