Testes Manuais X Testes automatizados

Olá!

Então pessoal….tive um problema com o post do Specflow 02 (deletei o rascunho sem querer….e uso shif+del) então como é um post que leva mais tempo e trabalho, e ainda estou reescrevendo ele… decidi trazer essa discussão de volta pra  o blog, anteriormente comentei um pouco por cima em outros posts, mas agora tenho um pouquinho mais de conhecimento na rotina de testes (automatizados e manuais) então posso comentar de uma forma menos superficial, abordar alguns pontos positivos e negativos de cada esforço.

Agora sem mais enrolação (tirando uma romantização durante o post rs) , vamos ao post:

Os nossos competidores:

boxer 1
Nosso lutador ortodoxo

“O teste manual é (normalmente) a nossa porta de entrada para o mundo do QA.

Treinos constantes, rotinas, tombos, aprendizados vão nos moldando em um atleta (tester) cada vez mais eficiente, temos a visão do combate, sabemos reagir contra imprevistos e nossos reflexos aumentam cada  vez mais a cada golpe que levamos!!!

 Não se pode tornar um atleta sem treinar, não se pode tornar um tester sem testar… claro que temos pessoas com intuição muito forte que tem mais facilidade que outras, mas o treino pode compensar e tornar qualquer um em um verdadeiro profissional!

Mas até um profissional pode ficar exausto e ser nocauteado em uma luta de vários rounds….”

O teste manual é uma skill que é aprimorada com o passar do tempo, ela requer um esforço contínuo para ser realmente lapidada. Nós vamos aprendendo onde erros costumam acontecer, aprendemos a ter um olhar mais crítico quando ao impacto de um bug no sistema, conseguimos analisar a UX (“experiência do usuário”) da aplicação, aprendemos até mesmo qual o esforço que uma função requer dos desenvolvedores, conseguimos estudar a cobertura da área de testes e melhora-la .

Mas temos um problema com trabalho contínuo e re-trabalho…. Vamos pensar numa aplicação com 10 telas e aproximadamente 10 funções em cada tela… se formos ignorar integrações e cenários diversos, fossemos fazer o menor número possível de cenários….teríamos pelo menos 100 testes, e nós podemos fazer eles sem problema nenhum.

Mas digamos que vai ter uma mudança nessa aplicação, e que pode quebrar ela inteira…..nós temos que fazer os mesmos 100 testes e mais alguns testes novos… e numa nova mudança teremos que rodas os mesmos 100 testes, os testes novos (que não são mais novos) e mais testes novos…  e assim por diante.

Além de cansar o analista (ninguém gosta de ficar repetindo o mesmo cenário toda hora), poder ter um problema de vícios (a pessoa entra no automático e não percebe que um ícone não está mais lá)…tem o problema de tempo, pensa que cada teste gasta um minuto, toda vez que tem regressivo você vai gastar  pelo menos 100 minutos só pra repetir testes antigos, utilizando um tempo que poderia ser melhor aproveitado com melhorias para o projeto.

Ou seja, é um processo que garante muita coisa, os profissionais estão sempre melhorando (pelo menos deveriam) e tem uma visão mais próxima do usuário, mas a longo prazo pode se tornar um processo que utiliza muito tempo e esforço

 

Boxer2
A tecnologia a favor da tecnologia (e sim, eu sei que esse robô que joga ping-pong….mas ele é badass)

“O terror de muitos que estavam despreparados,  uma máquina que  derruba seus oponentes com  sua agilidade e precisão, ela é incansável e mesmo com seus movimentos repetitivos, impressiona quem está assistindo a luta (Quando ela participa de uma luta o ibope aumenta imediatamente).

Poucos ainda conseguem lidar com ela, não são todas as lutas que conseguem colocar ela no ringue… seja por falta de investimento ou de pessoas que saibam manuseá-la, sem contar que muitas vezes pode ser derrotada por não ter tido  a sua manutenção entre as lutas.

Existe uma resistência por parte de alguns competidores, que dizem que não deveria ser permitida a participação de máquinas em combates com humanos”

E aqui pessoal, temos os testes automatizados… e a primeira vista eles podem assustar bastante, mas não se desesperem… ao observar melhor vocês podem perceber muitas vantagens neles.

Primeiro ponto de destaque, ele já atinge o maior ponto fraco do teste manual “Retestes”,  ao invés de ficar rodando os mesmo 100 testes toda vez que tem uma regressão, vamos deixar o automatizado fazer isso, ele não vai cansar, ele não vai ficar desatento… e vai ser muito mais rápido que o tester que for fazer os cenários na mão ( que pode inclusive fazer outra coisa enquanto os testes rodam)

Mas não caiam no marketing furado que alguns vendedores de ingresso fazem, não é só apertar play em um botão para os testes acontecerem… alguém tem que ir lá e colocar a mão no código, preparar os testes, um por um…e isso também requer tempo, esforço e conhecimento técnico (melhor aproveitado caso exista também o conhecimento sobre QA), e mesmo que não precise rodar todos os testes a cada mudança no projeto, você precisa dar manutenção nos testes…e isso também requer tempo, mas ainda assim costuma levar muito menos tempo do que rodar cada teste manualmente (até por que ele digita mais rápido, valida mais rápido….faz tudo mais rápido, sem perder a qualidade das validações feitas)

Um grande problema dos automatizados, é que ele valida as funcionalidades, mas não como elas interferem com o usuário, e também não investigam a causa do problema…só sabem dizer que ele aconteceu sem contar que qualquer imprevisto faz com que o teste quebre (por exemplo um time out), enquanto um tester sabe lidar com imprevistos e quando acha um erro, pode investigar a causa dele e onde isso pode refletir

Ou seja, ganha-se muito em agilidade a longo prazo, mas ao mesmo tempo é necessário um preparo para ter testes automatizados no projeto, mas o teste faz apenas aquilo para o que foi programado, o que é uma grande limitação, afinal testamos aplicações para humanos, e não para máquinas… e humanos enxergam as coisas diferentes de máquinas. (não acreditem se te falarem o oposto)

RESULTADO

 

DEPENDE! rs

Não acredito que testes manuais > testes automatizados e nem vice-versa.

Cada um tem seus pontos fortes e atendem melhor necessidades diferentes, ambos tem um custo de tempo e dinheiro e ambos podem falhar….

A questão é saber como, onde e quando aproveitar cada tipo de teste, e entender que os testes automatizados servem para ajudar a equipe (tester e desenvolvedor) a garantirem a qualidade da aplicação, eles não servem para substituir os testes manuais.

Não podemos substituir a experiência de uma pessoa, e muito menos a curva de aprendizado dela, isso é algo que a máquina não vai conseguir fazer (mesmo que nós melhoremos os testes automatizados, essa responsabilidade é de quem codifica o mesmo… uma melhoria da pessoa que reflete numa ferramenta), e não adianta uma pessoa querer fazer algo tão rápido quanto uma máquina, principalmente sem perder a qualidade do que está sendo feito.

Estamos num momento onde devemos perceber que a curva do aprendizado de um tester,  vai  passar por testes automatizados, isso está incluso no desenvolvimento ágil =]

Ao invés de bater na tecla do VERSUS, vamos aproveitar e lutar lado-a-lado (nossa que clichê isso…desculpem).

E vamos aprender a escolher as melhores decisões, ver onde se aplica um teste automatizado ou manual, sem aumentar desnecessariamente o custo do projeto, facilitando a vida de todo mundo, incluindo do cliente!

 

 

 

 

 

Anúncios

2 comentários sobre “Testes Manuais X Testes automatizados

Deixe um comentário

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