Automação Funcional – A aliada na entrega do produto

É relevante, nesse tema, trazer as experiências vividas na área, nem tanto  a parte técnica, apesar de ter atuado alguns anos como automatizador, que não é o foco deste texto; mas sim de uma automação que agrega valor otimizando a entrega.

Vamos bater um papo acerca do mercado de automação no que tange a instrumentos que facilitam o dia-a -dia.  A gama de ferramentas no mercado é muito grande, hoje muitos falam de “selenium” e “ruby for test“, outros observam o mercado pago com “HP – Quick Test” e “Silk – Test”. No entanto, a pergunta que paira é qual a necessidade da empresa? O desconhecimento acerca dessas soluções faz a diretoria, muitas vezes, optar por algo que não é ideal, acredito que por falta de uma análise mais apurada. É importante termos a cultura que todas as ferramentas tem o mesmo objetivo, proporcionar performance para a entrega do produto. Assim, uma solução “free” proporciona recursos semelhantes, muitas vezes o mesmo que uma ferramenta paga.

Tomando como base os dois últimos períodos do parágrafo anterior, logo podemos dizer que a questão é o conhecimento do profissional que está operando a solução. Até hoje não conheci pessoas que dominam por completo uma ferramenta, ou seja, sabem tudo. Tive oportunidade de trabalhar com pessoas muito boas e que resolviam, mas não sabiam tudo e, acredito, que não existe profissional, em qualquer área de atuação, que tenha o completo conhecimento de um certo recurso.Mas aonde entra esse negócio de pago ou de graça ? A facilidade de aprendizado de uma ferramenta paga é maior que uma solução free. Por exemplo, um profissional de “skill” júnior que é, praticamente, um curioso em automação, ao se deparar com configurações complexas e código, muitas vezes, pesado; a curva de aprendizado dele será alta. Ao contrário de uma solução que já venha com configuração “default” e uma linguagem menos pesada para se trabalhar ou que programe pouco, logo o aprendizado deve ser mais rápido. não estou querendo dizer que a solução paga é melhor que a “free”, assim volto a ressaltar, as ferramentas são todas iguais, pois o objetivo é o mesmo já falado no início deste texto. As ferramentas free resolvem e muito, pois quando o automatizador que opera a ferramenta tem conhecimentos avançados da mesma, praticamente, não existe curva de aprendizado. Assim, a complexidade de configuração e programação é quase zero, já que o profissional já conhece o caminho das pedras. A seguir podemos observar dois gráficos que resumem a curva de aprendizado diante dessas soluções do mercado:

Pontuação por Skill – Ferramenta Free

Pontuação por Skill – Ferramenta Paga

Agora seria bom focarmos na entrega e planejar. Independente da metodologia utilizada, sempre teremos que entregar o produto ao cliente. Algo que funcione de acordo com o quê o cliente esperava. A automação pode ser uma grande aliada na entrega, pois evitamos regressões de testes imensas e trabalhamos somente com a entrega atual.

Antes de entrarmos no assunto do parágrafo anterior, logo seria de grande importância temos a base de um conceito primordial em automação, não se faz automação de funcionalidade com erro ! Todos os cenários de testes manuais, que serão automatizados, deverão estar já testados e com status de Ok. Dizer isso soa estranho, pois a idéia não é, justamente, pegar erro em sistemas com problemas ? Sim. Bom, vamos nos decidir logo, senão vira um monólogo e não é isso que queremos. Vamos pensar assim, tivemos 5 entregas dentro de um determinado projeto, destas foram abstraídos 500 casos de testes, somente um exemplo; sendo que conseguimos automatizar 420 casos (depois explicarei por que nem tudo pode ser automatizado). Esses 420 casos devem estar ok, em automação com status de “passed”. Na entrega atual, temos 80 casos de testes que serão feitos manualmente, isso por que não é possível confiar 100% em algo que acabou de ser feito, logo não é passivel de automação; não podemos esquecer que existem 80 casos que não foram automatizados, assim 160 serão executados de forma manual. Então, executamos os manuais primeiro e observamos que 10 deles não passaram; rodamos o script de automação e no relatório a ferramenta colocou que 20 não passaram. Perceberam o que pode ter acontecido ? As novas implementações do sistema fizeram com que funcionalidades que já foram testadas e estavam “ok” tivessem como resposta erro ou erros em uma de suas partes. Ou seja, os 20 casos que funcionavam e estavam automatizados, já não funcionam mais. Essa diferença que deve ser percebida. As novas implementações, as modificações no sistema serão responsáveis por erros naquilo que já funcionava corretamente ? Ah, não esquecendo de explicar a frase do parágrafo anterior “regressões de testes imensas”, com o script pronto e um clique no “play” evitamos horas de trabalho !

Agora vamos imaginar que está tudo azul, trocando miúdos aqui, ou seja, não existiram erros na execução manual. Dessa forma, o nosso próximo passo, é rodar o script de automação; pois não é por que as novas implementações não estão erradas é que estamos seguro de que nada quebrou, ou seja, tudo que existe ainda continua funcionando ou existindo. Ao rodar o script com 420 casos todos resultaram em “passed”, isto é, ok. Um script desses pode levar cerca de 5 a 10 minutos para ser finalizado após iniciar sua execução, isso depende dos elementos que estão sendo navegados e os delays existentes nas páginas (termos técnicos). Vamos levar em consideração que os 160 manuais foram executados em 3 horas. Assim, temos um total de 3 horas e uns 20 minutos de execução. Para um tempo de 5 dias reservado para testes, assim a entrega é antecipada e todos ficam felizes.

Pessoal, agradeço pela leitura e logo teremos mais “posts” sobre assuntos de qualidade dentro do âmbito de projetos de TI. Um grande abraço e sucesso a todos nós!

[Crédito da Imagem: Automação – ShutterStock]