Como evitar o “Testa aí”?

O tema da 12ª Mesa Redonda DFTestes foi “Como evitar o “Testa aí”?”, e a discussão teve 31 respostas e 12 participantes, sendo eles: eu, Camilo Ribeiro, Shmuel Gershon, Marcelo Andrade, Vicenzo Naves, Rafael Porfirio, Cristiano Fernandes, Felipe Silva, Luis Barros, Fermiano de Queiroz Filho, Jorge Diz e Edwagney Luz.

Abaixo segue o “resumo” do que foi discutido na mesa redonda, quem quiser acessar a discussão na íntegra e só acessar esse link.

Como evitar o “Testa aí”?

Segundo o Shmuel Gershon:

Não precisa evitar (!).

O que precisa é preparar os testadores e os outros colaboradores (programadores, administradores) para trabalhar no modo Testa aí.
“Testa aí” pode ser de muita utilidade em vários casos: Logo antes de publicar o programa, ou em quando o programador tem algumas versões intermediárias e quer saber se alguma tem problemas.

Mas todos devem saber os limites do “Testa Aí”, inclusive o testador.

Um “Testa Aí” bem feito leva em conta o conhecimento prévio e o tempo disponível, para decidir as áreas com mais necessidade de testes.

Para o Marcelo Andrade a participação ativa dos profissionais de Teste de Software é uma maneira de evitar o “Testa aí”:

Participando ativamente dentro do dia-a-dia do projeto. O testador deve vivenciar a equipe. Ele não deve ser uma pessoa estranha ao projeto.

Quais são os motivos que levam ao uso do “Testa aí”?

O Camilo Ribeiro acredita que vários motivos podem levar a empresa a usa o “Testa aí”:

Vários, mas o principal motivo é a falta de conhecimento do que um processo de testes pode agregar.

Muitas vezes, essa falta de conhecimento do valor é nossa culpa mesmo, pois não medimos o nosso trabalho, não aproveitamos o tempo livre para melhorar as nossas técnicas, não enviamos feedbacks como os gerentes precisam e focamos nossas melhorias em aquisição de ferramentas sem conhecer o nosso processo.

Segundo o Marcelo Andrade, são dois motivos:

Apenas duas coisas: o distanciamento e a falta de comunicação.

O Vicenzo Naves acredita que:

Eu creio que o que leva uma empresa a usar o testa ai é simplesmente o costume de não se testar e de alguns anos para cá a competitividade é tão grande que eles precisam tentar se assegurar o máximo possível (ou talvez o mínimo como se é feito em empresas mais antiga com sistema de legado) garantindo que as telas funcionam dentro do padrão, quando se fala em fluxo alternativo e fluxo de exceção pessoas ficam até com calafrios em empresas mais antigas, porque eles devem saber de bugs em fluxos alternativos que não conseguem corrigir por causa de POG utilizado em massa em sistemas muito antigos

O Felipe Silva listou os seguintes motivos:

  1. Falta de tempo
  2. Falta de necessidade
  3. Falta de conhecimento da importância de uma teste abrangente
  4. Planejamento de um Highlevel (teste exploratório) para achar defeitos óbvios nos primeiros instantes do testes (como dito pelo Rafael Porfírio)
  5. Falta de profissional qualificado
  6. Falta de informações básicas ao testes (requisito ou qualquer outra coisa que dê um norte da validação)
  7. Priorização de um outro teste de uma parte do sistema que ainda não está estável (highlevel de integração, em outras palavras um fast-regression)
  8. PS: Notem que citei casos onde o “Testa aí” ajuda e outros em que é prejudicial.

Segundo o Luis Barros:

Inicialmente a falta de um processo bem definido, não só de testes, mas no fluxo de desenvolvimento mesmo. Em seguida, a falta de visão geral, principalmente pelo time de desenvolvimento que ainda pensam que os testers são usuários sem noção e que os erros mesmo só vão aparecer em produção mesmo (sim, isso ainda existe).

Eu também acredito que vários motivos podem nos fazer usar o “Testa aí”:

  • A ignorância perante ao processo de Teste de Software;
  • Prazos apertados;
  • Problemas de comunicação;
  • Processos não humanos (onde ninguém pensa, tudo mundo já sai fazendo);
  • Imaturidade do time.

O Jorge Diz acredita que:

Acredito que falta ainda visibilidade da disciplina de testes entre os gestores de TI.

Ainda é difícil aprovar qualquer alocação de recursos financeiros (incluindo as horas das pessoas) específica para testes.

Provavelmente isto já dá para iniciar outra trilha de discussões, mas vejo alguns motivos para isso:

-> A falta de visibilidade do teste de software para o público em geral (o que inclui a alta gestão)
-> A ocupação de “mindshare” por parte da área de qualidade (entendida como institucionalização de processos) que, por motivos históricos, também não dá importância devida ao teste de software
(e, em muitos casos, nem àquilo que de fato promove a qualidade em geral). “Já estamos gastando em implantação de CMMi, deixa testes para depois”
->  A cultura de desenvolvimento sob medida no Brasil, em oposição ao software produto. Os riscos de software produto puxam antes a importância de testes para a gestão.

Qual conselho você daria para um pessoa que é vítima dessa “metodologia”? É possível alcançar bons resultados com ela?

O Camilo Ribeiro destacou a importância da mudança de postura do profissional de Teste de Software:

Pró-atividade.

Enquanto a pessoa que passa a maior parte do tempo no “testa aí” não gritar “Processo de teste ou morte” ela vai continuar no “testa aí”. Claro que não mudamos o mundo do dia para a noite, mas se gastar um pouco mais de energia desenvolvendo um processo, criando casos de teste, pesquisando e mostrando resultados, com certeza um dia os gerentes que diziam “testa aí” vão dizer “Quanto tempo precisa para testar?”. Outra coisa importante. Quando essa oportunidade aparecer, se for desperdiçada, existem poucas chances de uma nova oportunidade de mostrar o valor do teste novamente. O velho ditado: “Você não tem uma segunda chance de deixar uma boa primeira impressão”.

Sobre os bons resultados, se você for um excelente testador, pode conseguir resultados satisfatórios em projetos de pequeno porte (CRUDs e relatórios), mas na maioria das vezes é quase impossível, ainda porque, não existe forma de provar que teve um bom resultado com o “testa aí”.

O Shmuel Gershon lembrou da metodologia Rapid Software Testing, dizendo:

A metodologia chamada “Rapid Software Testing”, desenvolvida por Michael Bolton e James Bach é um dos métodos usados para “Testar Aí” de maneira eficiente, usando métodos puramente exploratórios e sendo 100% transparente com as partes aonde falta testes, conhecimentos ou mais tempo.
James Bach descreve seu curso assim: “Quando alguém te dá um programa e diz ‘você tem uma hora para testar isto’, você consegue fazê-lo? Você se sente confiante no trabalho feito? Pode explicar o que fez e por que?” (isto me parece bem ‘testa aí’), e continua “Rapid Software Testing é a arte de testar qualquer software, a qualquer momento, baixo quaisquer condições, de modo que o trabalho possa enfrentar um olhar examinador”. As traduções são minhas e ficaram horríveis de novo🙂.

Eu não sou um Rapid Software Tester oficial e profissional.

Mas em alguns casos meu time teve que testar um programa com pouco aviso prévio e curto prazo final. O modo como organizei isso foi deixando todos experimentarem um pouco com o software e logo organizando uma ou mais reuniões para identificar as áreas de ‘ataque’. Acredito que tivemos sucesso, mas não tenho como comparar isso a outra metodologia, então aceitem meu conselho com cautela e reserva.

O Marcelo Andrade respondeu dizendo:

Testador: converse mais, interaja mais, participe mais. A equipe precisa do seu feedback para desenvolver melhor. Você precisa do feedback da equipe para testar melhor.

O Felipe Silva deu o seguinte conselho:

Eu aconselho que a pessoa garanta que o “Testa aí” cobre a qualidade que exigem desta pessoa, se não cobrir ou essa pessoa tem que dar um jeito de lutar para mudar isso ou pode perder o emprego sendo acusado de não “testar direito”.

O Luis Barros disse o seguinte:

Quando possível forçar que o processo seja seguido, mesmo que para muitos ele seja “burocrático demais!” (10 minutos para liberar uma Release Formal)

Na minha opinião a primeira coisa a ser feita é conhecer melhor o processo de Teste de Software, as atividades, etc.

Depois converse com o seu líder/gerente a respeito do processo atual e dos problemas enfrentados, não precisa tentar convencer ele, às vezes só apresentar os fatos e as possibilidades de melhoria, já farão que ele mesmo perceba que algo precisa ser mudado.

Deixe claro que a mudança será benéfica a todos.

Agora sobre se é possível alcançar bons resultados, depende do que são bons resultados na sua realidade, acredito que a curto prazo até é possível, utilizando por exemplo testes exploratórios para aprender sobre o sistema, buscando se aproximar do desenvolvedor, etc. Mas a médio e longo prazo o “Testa aí” não é nenhum um pouco saudável.

O Jorge Diz deu as seguintes sugestões:

Tentar deixar claros os riscos de não haver testes apropriados dentro daquele contexto. Se isto falhar, o que normalmente acontece, procurar usar técnicas de teste exploratório focadas nas áreas de maior risco para o negócio. Lembro do Brateste do ano passado: na palestra do Ricardo Cristalli foi apresentado um cenário de pesadelo no qual, se lembro bem, ele tinha apenas janelas de tempo dentro de um confcall para instruir alguém a realizar testes exploratórios remotamente: ele trabalhou com o conceito de “test ideas” e conseguiu ser eficaz dadas as limitações do contexto.

Sempre se pode testar. Não adianta brigar com o que não podemos mudar no curto prazo: é necessário  dançar conforme a música e procurar baixar as expectativas de quem pede o “testa aí”. Obviamente, a eficácia fica comprometida: “bons resultados” devem ser relativizados pelo contexto.

Como convencer a empresa a parar de usa o “Testa aí”?

Mais uma vez, o Camilo Ribeiro acredita que a pró-atividade é uma importante característica que deve ser exercida:

Acho que a pró-atividade continua sendo o importante aqui. Nós somos o fator de mudança e essa mudança é conquistada com tempo e muito esforço. O conselho acima continua valendo: Feedbacks sobre qualquer melhoria e sua causa. Ser claro com os líderes sobre as condições do projeto. Tentar ser o mínimo técnico no sentido de ficar mostrando livros ou artigos sem mostrar resultados reais. Se conseguir mostrar resultados reais, com certeza haverá espaço para novas melhorias. Muita calma, mudanças são uma das coisas mais complicadas para os humanos.

Para o Shmuel Gershon não é preciso parar de usar o “Testa aí”, o que é preciso é usá-lo de modo correto:

De acordo com o que escrevi antes, a empresa não deve /parar/ de usar o “Testa Aí”, apenas deve usar o “Testa Aí” de modo correto. A maior parte do trabalho para isso recai sobre a equipe de testes, que deve ganhar a confiança do resto da organização.

O Marcelo Andrade disse:

Todos sabem que quanto antes um erro for descoberto, mais barato é corrigí-lo. Na prática, se é uma empresa 1.0🙂, esse convencimento é paulatino e só pode se dar quando os resultados aparecem. Feedback constante é essencial.

Para o Felipe Silva:

Mostrando dados, gráficos, números, dinheiro investido, para os dois casos (com “Testa aí” e sem “Testa aí”).

PS: Considerando que a minha colocação acima só é válida ao “Testa aí” prejudicial.

O Luis Barros lembrou que essa é uma questão cultural da empresa:

Cultura! Quando todos (do diretor ao próprio tester) derem o devido valor à disciplina de Testes as coisas, certamente mudam.

Eu vejo que você precisa apresentar informações relevantes e possibilidades de melhoria, converse primeiro com as pessoas que você acredita que irão concordar com você, e busque apoio.

Segundo o Jorge Diz:

De novo, mostrando os riscos e o impacto financeiro / de imagem. Mostrar para o gestor que ele também será visto como (ir)responsável caso Murphy decida dar o ar da graça;

O “Testa aí” pode acontecer mesmo quando já temos um processo definido?

Para o Camilo Ribeiro:

Processo definido != Processo institucionalizado.

O simples fato de ter um processo definido CMMi 5 ou ISO 9000/9001 não faz com que os problemas da empresa desapareçam, muito pelo contrário. Da mesma forma que agente não pode “mostrar menos” quando temos a oportunidade de “testar de verdade”, não podemos mostrar menos valor quando usamos o processo que está definido, pois se esse processo fracassar, mesmo que passe no SCAMPI dificilmente será usado com facilidade.

Sendo mais direto, o processo definido não significa nada, mas se o processo estiver institucionalizado, dificilmente haverão ocasiões de “testa aí”.

Segundo o Shmuel Gershon:

Sim, acho que um processo definido pode incluir o Testa Aí. Isso vai fazer o Testa Aí ficar mais fácil, pois em vez de aparecer de surpresa, a equipe de testes pode se preparar a tempo e escolher os testadores mais apropriados.

Já para o Marcelo Andrade:

Primeiro, sempre há um processo definido, mesmo quando ele não está escrito em lugar nenhum.

Processos devem refletir a cultura, os costumes e os valores daqueles que com ele trabalham. Se as pessoas são obrigadas a seguir um processo que não lhes parece natural, “faz aí porque está no processo” ou “testa aí porque está no processo” acaba sendo tudo a mesma coisa.

O Felipe Silva também acredita que é possível:

Sim pode, ver na resposta da primeira pergunta que muitas respostas se encaixam em uma situação de processo definido, tudo depende de como o processo foi definido, se permite ou não o “Testa aí”.

Segundo o Luis Barros:

Sim. Principalmente quando existe a falta de tempo: Todo mundo está “apagando incêndio” tudo vira prioridade. Aí entra o “Testa aí pelo amor de Deus!”, então a culpa, caso as coisas não funcionem, é do tester que não encontrou o(s) bug(s).

Também acredito que é possível, principalmente se o “Testa aí” já foi utilizado antes pelas pessoas, pois caso ocorra algum aperto, a primeira coisa que costuma ser feito é utilizar o “Testa aí”, e o grande problema é quando ele ocorre e apenas quem participa (famoso: fulano eu fiz só uma pequena alteração de nada, você poderia verificar ela aí?), geralmente desenvolvedor e testador, sabem disso e não reportam isso para outros profissionais, exemplos líderes e gestores.

O Jorge Diz fez o seguinte comentário:

Concordo com o Marcelo: processo definido não significa que seja o processo que está sendo usado. Aliás, cansei de ver processos de gaveta, que foram definidos por alguém externo (consultoria ou área de qualidade sem vivência no processo real) e que são impraticáveis.

O que já vi acontecer nesses casos é que os “desvios de processo” acabam virando o próprio processo. É a confirmação da teoria da janela quebrada: ninguém se sente obrigado a seguir qualquer processo.

Toda organização tem seus processos, escritos ou não, e as melhorias são feitas a partir dali, com a participação daqueles que usam os processos.

Mudanças em processos são complicadas, e são necessárias ações inteligentes para promove-las. Escrever um documento, convencer o gestor a assinar embaixo e desfilar  por ai com um chicote não é uma estratégia que costume promover melhorias sustentáveis.

O que afinal é o “Testa aí”?

Durante a discussão um ponto que não ficou muito claro foi o entendimento sobre o que é o “Testa aí”. Abaixo, explico o meu entendimento sobre essa “metodologia” e também trago alguns comentários do Camilo Ribeiro e do Shmuel Gershon.

Para mim o “Testa aí” tem as seguintes características:

  • O testador não tem informações sobre o sistema;
  • O prazo é apertado;
  • As pessoas esperam resultados rápidos do “Testa aí”;
  • Não há planejamento dos testes;
  • A comunicação entre desenvolvimento e testes é ruim;
  • O testador age de forma reativa.

Resumindo, seria um cenário de caos para o Teste de Software!

Um exemplo:

  • O desenvolvedor libera uma nova versão para o testador, passando a mesma por MSN (agh!);
  • O testador vai fazer alguns” testes que até a minha mãe faria”, pois o prazo para a entrega da versão já está estourado e não tem muito conhecimento sobre o sistema.

O Camilo Ribeiro disse o seguinte sobre o “Testa aí”:

O que eu entendo como “testa aí” é a entrega de uma demanda para uma pessoa realizar smoke tests e testes exploratórios sem o mínimo de planejamento, correndo contra o tempo e sem nenhuma garantia de cobertura. Desculpe a franqueza, mas não vejo nada de positivo nessa abordagem.

Concordo com o que o Camilo disse, também não vejo nenhuma vantagem no seu uso, e vejo que o mesmo só ocorre por uma série de fatores. Ou seja, ninguém deve usar o “Testa aí” por escolha, e sim por necessidade da situação, mas sempre tendo em mente os efeitos colaterais que o uso pode trazer.

O Shmuel concorda com as características que citei e faz alguns ressalvas:

Concordo com todas (informação, prazo, resultados rápidos…) , com estas ressalvas:
-> A comunicação entre desenvolvimento e testes é ruim — não necessariamente.
-> Não há planejamento dos testes — o planejamento acontece durante os testes, não antes.
-> O testador age de forma reativa — ele pode proativamente se preparar para ser um bom testador de “testa aí”🙂
O que muda não é a situação ou as condições. O que muda é a atitude🙂.
Em minha opinião, essas situações são momentos em que o testador pode adicionar valor ao produto assim como outras. Mas concordo que não é fácil.
Já o Jorge Diz tem uma visão diferente sobre “Testa aí” e disse:
“Testa aí” me parece diferente de “Estamos nos 45 do segundo tempo e precisamos testar: vamos fazer o melhor dadas as circunstâncias”. No primeiro caso, o gestor não tem noção. No segundo, não tem opção.
Teste exploratório tem técnica, não é a mesma coisa que testar de qualquer jeito. Estamos falando aqui de teste exploratório sob condições extremas de prazo e recursos. Falta de tempo não é desculpa para falta de planejamento: atividades curtas e críticas são mais eficazes se feitas sem afobação. Mesmo que tenhamos uma hora de prazo, precisamos pensar como fazer o melhor uso possível desse tempo.
O papel dos testes é apontar riscos. Nessas circunstâncias, a capacidade de comunicação do profissional de testes com o gestor é colocada à prova. O resultado de uma atividade de testes nessas circunstâncias deve ser apresentado com clareza e sem a pretensão de ser um parecer bem fundamentado: o risco para o negócio vai ser grande de qualquer maneira.
Para encerrar o “resumo” segue um comentário bem legal feito pelo Edwagney Luz sobre o “Testa aí”:
Esse tal do “Testa aí”, é uma maneira clara de dizer: “Não tô nem aí pro que vai acontecer, quero embolsar a grana desse projeto e a equipe pós-projeto que se dane pra resolver a parada depois.” Sejamos lúcidos e francos. Quem usa “metodologia” do “Testa aí”, não está muito preocupado com qualidade. Se estivesse, daria mais atenção a alguns procedimentos antes da elaboração do termo de abertura do projeto. O erro vem lá de trás. O erro vem do planejamento e para mim, alguém chegar dizendo que o projeto não tem tempo hábil para um teste planejado, é porque não dá a mínima para qualidade. Desculpem-me a sinceridade, mas melhor doer de uma vez do que ficar sofrendo aos poucos.🙂
Outra fator decisivo, é o fato de querermos dizer que estamos fazendo engenharia de software, sem usar procedimentos de engenharia. De novo, me desculpem as empresas desenvolvedoras que dizem fazer engenharia de software e não reservam tempo para teste, procedimentos de garantia de qualidade e etc. Elas estão apenas programando algum tipo de produto, mas fazendo engenharia não. Peguem qualquer livro de qualquer autor sobre engenharia de software e verão claramente todos os pontos da construção de um software usando conceitos de engenharia de software. Se não fossem necessários, não estariam ali. O fato é que alguém, um dia, disse que não precisava de qualidade, teste, e pulou toda essa parte e tudo bem… Hoje sofremos com isso e nossos clientes ainda mais.
Uma equipe de teste e qualidade deveria questionar sempre é: Se é pra usar o “testa aí”, o que “EU tô fazendo aqui?”
Bem pessoal é isso. Continuem de olho na lista do DFTestes, pois sempre há assuntos bem interessantes lá, e poderão haver novas respostas nessa mesa redonda.
Fique por dentro das novidades, assine o feed do QualidadeBR.
Pró-atividade.

Enquanto a pessoa que passa a maior parte do tempo no “testa aí” não gritar “Processo de teste ou morte” ela vai continuar no “testa aí”. Claro que não mudamos o mundo do dia para a noite, mas se gastar um pouco mais de energia desenvolvendo um processo, criando casos de teste, pesquisando e mostrando resultados, com certeza um dia os gerentes que diziam “testa aí” vão dizer “Quanto tempo precisa para testar?”. Outra coisa importante. Quando essa oportunidade aparecer, se for desperdiçada, existem poucas chances de uma nova oportunidade de mostrar o valor do teste novamente. O velho ditado: “Você não tem uma segunda chance de deixar uma boa primeira impressão”.
Sobre os bons resultados, se você for um excelente testador, pode conseguir resultados satisfatórios em projetos de pequeno porte (CRUDs e relatórios), mas na maioria das vezes é quase impossível, ainda porque, não existe forma de provar que teve um bom resultado com o “testa aí”.

2 comentários sobre “Como evitar o “Testa aí”?

  1. A prática do “testa ai” é o barato que sai caro: parece que será mais rápido, e no final sai caro e ainda com um produto de baixa qualidade. Teste é processo, e sem processo não se obtem a qualidade necessária.

    Responder

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s