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

https://www.youtube.com/watch?v=X1jWe5rOu3g

Desde o dia que eu assisti a abertura do google conference 2012 onde foi decretado a morte do teste, tenho pensado bastante a respeito. Nossa área de teste não evoluído como deveria junto com a evolução do desenvolvimento de software. Até fábricas de software tem utilizado algo parecido com ágil no seu processo de desenvolvimento mas o testes continuam iguais.

Para alivio de muitos, o teste de software não vai morrer tão cedo… mas algumas coisas precisam evoluir. Se você já mudou de residência ou emprego na vida, sabe que para seguir em frente, é preciso se desfazer de algumas coisas que não fazem mais sentido nessa nova etapa e isso acontece com um artefato singular que “rege” todo nosso mercado: Casos de Teste.

Amigo, pegue seus casos de teste e não recicle… jogue no lixo.

Pode xingar, pode espernear, pode me chamar de louco, pode não me aprovar no processo seletivo da sua empresa mas isso precisa ser feito. Criar e dar manutenção em casos de teste que são defendidos e utilizados pelo mercado é rasgar dinheiro.
Você já parou para pensar quanto tempo você gasta  para escrever uma suite de teste, para descrever passo a passo baseado em um wireframe e dar manutenção nos casos de teste porque na hora de desenvolver os desenvolvedores abandonaram o wireframe com consentimento do cliente e todos seus fluxos tem que ser revistos e corrigidos? Você gasta muito… muito tempo.

E para gerenciar esses vários casos de teste em um testlink da vida é preciso uma pessoa só para fazer isso, ou seja, um trabalho que é feito geralmente por um líder de teste que é um cargo bem caro só para fazer o papel de assistente de escritório.

Também acredito que você já olhou para o lado e viu sue colega analista de teste abrir o testlink e ficar pensando… “E agora que teste que faço?” (só pesquisar no #DFTESTE,  tem um monte de gente nessa situação).

É a mesma coisa que abrir o eclipse e começar a pensar como vai ser sua lógica, seu modelo de dados e seu fluxo, ao mesmo tempo que você começa a escrever métodos e classes que daqui a 20 minutos provavelmente vão para o lixo ou se tornará código morto.

A cereja do bolo é quando você abre o caso de teste de outro analista constata que o CT é pura cópia do caso de uso OU algum trecho da documentação, com a mesma pontuação e erros de português.

Alguns podem dizer que o problema é o profissional e não a metodologia e os artefatos que ela produz, mas eu discordo. Existem atitudes e atividades que nos induzem a errar e a nos acomodar.
Escrever casos de teste tradicionais é perda de tempo, até porque… você sabe dizer de bate e pronto o que é um caso de teste?

Tome um tempo para pensar, sem consultar nenhuma documentação ou Wikipédia e tente definir o que é um caso de teste sem usar palavras como “depende”, “escopo” ou qualquer outra que generalize a explicação.

pensando.jpg
.

.

.

.

Meio ambíguo né? A gente faz caso de teste por osmose e do jeito que aprendemos em nosso primeiro emprego, pois cada empresa tem uma forma de escrever seus casos de teste e isso não quer dizer que uma delas está correta OU que aquela forma de escrever os casos de teste é melhor para empresa.

A engenharia de software diz: “Caso de teste é um conjunto de condições usadas para teste de software”. A mesma engenharia de software também diz: “Um caso de uso representa uma unidade discreta na interação entre o usuário e sistema. Ele é uma unidade de um trabalho significante”.

Interessante constatar que é o caso de uso que é a unidade funcional de trabalho e o caso de teste é para definir um conjunto de condições. Então porque muitos profissionais de teste insistem em fazer casos de teste para testar valor limite de cada campo de um formulário? Esse tipo de teste e todos os outros testes que valida o comportamento dos campos de um formulário não poderiam estar contemplados em somente um caso de teste?

Já parou para pensar que você não precisa escrever:

“Sumário: Validar mascara do campo “Data”.

Premissa: Estar logado no sistema e possuir acesso ao formulário de cadastramento

Passo:

  1. Acessar o Sistema

  2. Clicar no botão de cadastramento no menu XYZ

  3. Preencher o campo data com números sem usar pontuação

  4. Preencher o restante do formulário com dados válidos

  5. Clicar em “Enviar Formulário”

Resultado:

  1. O sistema deve permitir o acesso

  2. O Sistema deve direcionar o usuário para o formulário de cadastramento

  3. O sistema deve aplicar automaticamente a mascara de data na medida em que o usuário digita a data.

4.  –

  1. O sistema deve enviar o formulário e salvar os dados."

Isso me lembra de quando comecei a trabalhar com teste… seis anos se passaram e continua a mesma coisa.

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.

E por que esse modelo de criação de caso de teste é amplamente utilizado no mercado?

Eu não vou discutir por que os casos de teste começaram a ser usados, por que se começou houve um motivo e uma necessidade e provavelmente fez sentido durante um bom tempo, mas hoje a história é outra.

O mercado não quer evoluir de propósito. Para vender consultoria de teste ou serviço de fábrica de teste é preciso justificar seu preço. Como se justifica um preço? Números infelizmente falam mais alto que propostas e métodos. Nada melhor para dar um show de números com métricas e de status de progressão do que os famosos casos de teste.

Então quer dizer que a indústria de teste é malvada e vende casos de teste que as empresas não precisam somente para aumentar seu lucro? Como se fosse fácil apontar o dedo só para a conseqüência…

A mesma empresa que contrata uma fábrica de teste que vende mil casos de teste e 2mil execuções é a mesma que pechincha ao extremo e não confia em consultoria de teste que trabalham de forma compacta e sem burocracia OU ela acha / entende que é mais barato contratar uma empresa terceira do que ter uma equipe interna que cuide da qualidade.

Também entra nessa equação a sensação de segurança e progressão do trabalho quando a fábrica manda números de casos de teste executados, erros abertos e a possibilidade de dividir casos de teste por dia e arrumar de forma burguesa o projeto no MS Project ….

A que ponto o mercado chegou onde o setor de compras define o destino do setor de tecnologia? Às vezes é necessário terceirizar teste e até desenvolvimento quando o núcleo do seu negócio não depende da área de tecnologia, mas quando depende, não existe desculpa para terceirizar.

Mas há luz no fim do túnel! Com o sucesso das “startups”, as novas empresas começaram a ficar menores, com equipes menores e multidisciplinares e com capacidade de se adaptar a cenários adversos, sem ficar engessadas a um formato de trabalho, uma metodologia ou a uma linguagem de software especifica.

E nesse novo tipo de empresa e equipe, infelizmente não tem espaço para os analistas de teste que se agarraram ao modelo tradicional de teste, gerando centenas de casos de teste e sem parar para pensar no valor agregado daquilo que produzem.

Vejo esse futuro com bons olhos, vejo o mercado mudando e um dia até as empresas dinossauro irão evoluir e botar o lixo pra fora e no meio desse lixo com certeza estará seus 100 casos de teste para testar um simples login .

Será que usaram como referência? :)

http://www.eventick.com.br/viradatecnologica

Será @Leonardo-Galani ??? rs

Samy

@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.