Faça um favor ao nosso mercado de teste – jogue seus casos de teste no lixo

@Samanta-Cicilia Esse post tem 3 anos de vida…ahahhah… (1 anos de java selenium e coca cola ( ou será que ja era keeptesting…) e 2 anos de at…) causou um fuzuê quando foi escrito… bons tempos :)

@Leonardo-Galani o bom é ver que 2 anos depois as coisas tem mudado bastante na área :D

Samy

Faz sentido. O caso de teste não vai para produção!

Já há algum tempo reflito muito com a ideia proposta no artigo. A atividade de elaboração de casos de teste não varia, você pode utilizar diversas ferramentas e modelos, mas todas elas circundam os (inúmeros) casos de teste.

Para uma tela de login, conforme exemplo do texto, posso imaginar no mínimo 6 cenários de teste, aumentando o número se a tela possuir além dos campos de usuário/senha e botão OK um “esqueci minha senha”, por exemplo.

A elaboração dos casos de teste em massa acaba cegando o tester e gerando muito retrabalho caso alguma palavrinha que passou batido acabe mudando o sentido dos testes.

As startups foram citadas como luz no fim do túnel por não se engessar a um formato de trabalho, metodologia ou linguagem de software específica, mas fica minha dúvida (depois de tanto texto!): como assegurar a cobertura dos testes em um grande projeto, diminuindo o número de casos de teste sem deixar de considerar determinadas situações que estes englobariam? A resposta seria criar um modelo de elaboração de casos de teste diferente do que temos hoje (inúmeros passo-a-passo e tudo o mais que um caso de teste possui)? Como seria este modelo?


Carol Ciola

Olha Carol… é meio que para isso escrevemos testes automatizados :)

Para que cenários repetitivos possam ter sua verificação garantida deixando tempo livre para que vc possa fazer mais exploração e mais cenários automatizados…

Eu Levo em conta os critérios de aceite do usuário + entrevista / conversa com desenvolvedores… e faco meio que um todo geral com cenários macro… nada mto fancy… :) por isso nao acho que um novo modelo é desnecessário…

Concordo contigo, Leonardo. Para cenários repetitivos e regressão não há nada melhor que a automatização.

O fato é que, na maioria das vezes temos que fazer testes pra ontem de um novo projeto ou de uma alteração de alto impacto, e em uma demanda desse tipo, elaborar os novos cenários automatizados acaba sendo inviável naquele momento por conta do prazo. Mais tarde, todo cenário automatizado vai se basear naquele monte de casos de teste manuais…

Acho que não fui muito feliz quando utilizei o termo “novo modelo”! A pergunta se refere à forma de como deixar um cenário mais enxuto sem que saia dos padrões e que continue completo, para que o tester não se perca em tudo aquilo… mais ou menos isso…


Carol Ciola

Quando você fala que alguém (tester) vai fazer os testes para você, não existe milagre.
Em modelos tradicionais onde as pessoas tentam salvar a bunda primeiro antes a fazer um bom trabalho, analistas de teste tentam cobrir todos os cenários com maior nível de detalhe possível e o que na maioria das vezes, testers não prestam atenção OU não é o suficiente para entenderem.

Porém quando vc tem pessoas que podem colaborar mutualmente para concepção de cenários e que tenha acesso as mesmas informações e pessoas que você para realIzação dos testes manuais de novas funcionalidades / regressivos, é possível usar técnicas como mind maps.

No meu tempo de locaweb onde a empresa exigia casos de teste MAS eles não precisavam ser tradicionais, usavámos um design de teste ± assim:

Funcionalidade de login

  • Validar que o processo de login deve respeitar credenciais disponíveis no banco
  • Login deve bloquear tentativas forçadas
  • Validar cookies e sessão

Se fosse um esquema tradicional, os 3 cenários acima poderiam dar fácil uns 12 casos de testes tradicionais.

Sempre que eu preciso escrever casos de teste para guiar uma regressão não passível de automação, eu faço nesse esquema… por isso escrevi o sherlock… :)

@CarolCiola disse em Faça um favor ao nosso mercado de teste – jogue seus casos de teste no lixo:

Concordo contigo, Leonardo. Para cenários repetitivos e regressão não há nada melhor que a automatização.

O fato é que, na maioria das vezes temos que fazer testes pra ontem de um novo projeto ou de uma alteração de alto impacto, e em uma demanda desse tipo, elaborar os novos cenários automatizados acaba sendo inviável naquele momento por conta do prazo. Mais tarde, todo cenário automatizado vai se basear naquele monte de casos de teste manuais…

Acho que não fui muito feliz quando utilizei o termo “novo modelo”! A pergunta se refere à forma de como deixar um cenário mais enxuto sem que saia dos padrões e que continue completo, para que o tester não se perca em tudo aquilo… mais ou menos isso…

Acho que vale aqui é o trabalho “antes de testar”… Se está trabalhando com metodologia ágil, tu consegue no planejamento passar alguns itens que sabe que vão ser críticos e como o app não vai ser feito somente em uma sprint, tu consegue progredir junto com ele. E usando automação, tu pode progredir essa parte também e ao explorar um pouco (Sabe aquele 10 min que acaba o café a gente fica sem norte? então…ehehhe) e gerar mais possibilidades…E assim tu vai construindo junto com app…
Depois com um pouco de experiencia a gente começa a entender certas coisas, certas regras e dai a coisa sai “automágico” hehehehe

@Ramses-Saccol-de-Almeida Concordo com você, quando fala da parte de metodologia ágil. Quando nós qa, já estamos trabalhando junto com o time de desenvolvimento fica muito mais fácil acompanharmos o que está sendo desenvolvido e nas estórias já está contemplado a nossa automatização sempre que essa for possível. Com isso, as features novas acabam já saindo com os testes automatizados, facilitando nossa vida no futuro. Hoje é muito difícil, eu escrever casos de testes, o mais perto (longe disso hahaha) é um checklist básico mesmo. Utilizamos muito como base os próprios testes automatizados.
E isso é muito que você falou, aos poucos vamos pegando experiência, e aprendemos fazendo na prática hahah

Olha… tenho um voto negativo no post :) 2017 e pessoas discordam com esse pensamento que deveria ser meio que padrão…rs

Pior que voto negativo e não justificar o porque ou não discutir sobre, mas tudo bem, pessoas sendo pessoas…

Olá, pessoal. Estava concordando com tudo até o momento das startups, nem é que está errado mas porque esperava no final do artigo uma solução mais palpável ou um pouco mais concreta sobre a extinção dos casos de testes. Mas em geral, muito interessante o artigo! Parabéns!

@felgluz

Você poderia escrever o mesmo teste, aumentar o escopo e economizar burocracia em apenas uma linha: “Validar os campos do formulário de cadastro, validando as restrições e mascaras dos inputs.”

Existem sistemas com regras de negócio complexas que precisam de vários cenários, consequentemente vários casos de teste detalhados (mas nada de passo a passo, por favor!), mas ai sim o “caso de teste” estará sendo utilizado para seu verdadeiro propósito e não pelo simples fato de fazer uma matriz com parâmetros que podem ser críticos ou não.

Quando escrevi esse post a um tempão atrás… não entendia o movimento lean / agile direito e não trabalhava 100% em uma equipe testando e programando… :)

Log in to reply

Looks like your connection to Agile Testers was lost, please wait while we try to reconnect.