Testes automatizados x qualidade de software

Quando iniciei minha jornada como analista de qualidade, imaginava que a automação de testes poderia nos prevenir de todos os males referentes a falhas no software. Por conta de algumas incertezas, resolvi procurar mais informações sobre como a automação de testes era usada no processo de desenvolvimento de software, e como as pessoas da qualidade de software entendiam seu uso dentro desse sistema. Partindo desse ponto, fui em busca de conhecimentos que pudessem me ajudar a esclarecer minha percepção em relação aos testes automatizados e como isso poderia influenciar meu pensamento na condução das atividades de testes dentro da minha rotina de trabalho.

No syllabus, manual da ISTQB – International Software Testing Qualifications Board, utilizado como base de conhecimento para certificação em qualidade de software, não encontramos um conceito definido sobre automação de testes, mas conseguimos esboçar um entendimento, tomando como base algumas informações descritas neste documento. A automação de teste envolve a criação de um sistema de execução de testes, que abrange diferentes elementos, como o software, a documentação do projeto, casos de teste, ambientes de teste e dados de teste. Esses componentes são essenciais para a implementação, monitoramento e controle dos testes automatizados, bem como para a interpretação, reporte e registro dos resultados. Os objetivos da automação de teste são melhorar a eficiência do teste, ampliar a cobertura das funções testadas, reduzir os custos totais dos testes, diminuir o tempo necessário para a execução dos testes e aumentar a frequência dos testes ao longo dos ciclos de desenvolvimento (ISTQB, 2016).

Para Michael Bolton (2020; 2018; 2012), pensador da área de qualidade de software, a automação de testes não pode ser considerada como teste, pois a ação de testar faz parte de um processo cognitivo que implica conhecimento, exploração, experiência e experimentação do sistema sob teste. O que os scripts de testes automatizados fazem é um processo de verificação, tomando como base regras de negócios que podem ser expressas em algoritmos e executados por uma ferramenta, para fazer avaliação de aspectos de um produto de software. Dessa forma, a utilização de ferramentas automatizadas somente realizará funções para as quais foram programadas para executar, diferentemente da ação de testar, que é um processo estritamente advindo da mente humana e realizado por humanos.

Tomando como base os entendimentos discorridos previamente, penso que o processo de automatização de testes consiste na criação de rotinas de conjuntos de testes, que podem ser executadas por uma ferramenta de automação, com o propósito de validar os resultados obtidos e expressos em relatório gerado pelo sistema que testa, a partir da experiência exploratória do software realizada por uma pessoa que testa. Para automatizar testes, deduzimos que houve interação prévia do analista de testes com o software em busca de informações sobre o que deve ser validado pelo script, mas é preciso compreender que a atividade de testar vai muito além do que uma simples validação automatizada, tendo em vista que é necessário entender a influência dos resultados, os esperados e os não esperados, no funcionamento do sistema sob teste.

Testes automatizados – Ferramenta

A automação de testes é uma ferramenta que pode ajudar a monitorar o funcionamento de partes do software, avaliando se o comportamento dessas partes monitoradas continua como esperado após o sistema passar por atualizações de código. Como ferramenta, o processo de testes automatizados se mostra muito eficiente por oferecer retornos rápidos no processo de verificação da aplicação. A inspeção realizada pode cobrir diversos cenários, viabilizando, com isso, mais rapidez e confiabilidade nos entregáveis de software.

Lembremos que automatizar testes não significa que precisamos dispensar as pessoas que testam, pois o processo “automatizado” foi pensado e desenvolvido por um técnico capacitado e com experiência, a partir de um modelo cognitivo que visa garantir a integridade de partes do sistema. Para criar um script automatizado, pressupomos que houve um processo anterior de aprendizado, experimentação e análise para ser determinado da forma que é.

Mesmo que fosse possível tornar todo o processo de verificação automático, seria necessário que os desenvolvedores criassem um modelo mental para validar cada aspecto do sistema, e mesmo assim seria um desafio, pois sabemos que a aplicação não é estática e, com isso, a cada atualização do código precisaríamos realizar uma validação que levaria horas para ser executada. Isto pode ocasionar atrasos nas entregas com a espera dos relatórios gerados e a reexecução após ajustes de bugs encontrados, e sem revisão e manutenção do código, esse processo poderia ficar defasado, gerando falsos positivos para falhas, e com isso, haveria grande possibilidade de ser abandonado pelo time. Outro fator a ser considerado é o alto custo de manutenção com um processo extremamente complexo e pouco eficiente, pois sabemos que uma inspeção automatizada não previne contra bugs em partes do sistema não previstas em seu escopo.

Problemas no uso de testes automatizados como método único de teste

Os testes automatizados, quando não considerados como ferramenta, podem se tornar um problema quando acreditamos que essa abordagem pode oferecer cobertura para situações ainda não observadas ou quando ela passa a ser o único método de teste utilizado no processo de desenvolvimento de software.

O processo de teste é muito mais complexo do que somente a validação do sistema feita por uma ferramenta automatizada. Testar significa gerar hipóteses, e logo em seguida, realizar experimentos utilizando diferentes técnicas tais como: testes baseados em heurísticas, testes funcionais e não funcionais. Após isso, fazer a validação dos resultados obtidos, para que possam ser traçadas, pelo time envolvido no desenvolvimento, as estratégias para encontrar a resolução de possíveis problemas diagnosticados.

Os testes automatizados, nesse caso a simulação de um modelo de uso convertido num algoritmo que é executado por uma ferramenta, usado como uma inspeção do software para verificar seu funcionamento, é baseado nos critérios de aceitação do produto, enquanto testes exploratórios vão além, pois fornecem informações que expandem nossa visão de produto para além dos requisitos. A utilização de um modelo de uso não reflete o universo de usuários do sistema, essa característica reflete uma das limitações das ferramentas de testes automatizados.

No processo de desenvolvimento, precisamos estar atentos em como o produto deve se comportar a partir da interação do usuário com o sistema. Como sabemos, nem todo usuário executa os fluxos da mesma forma, e seria bem complexo simular comportamentos diferentes com um projeto de testes automatizado. A documentação de desenvolvimento do software pode descrever os requisitos de funcionamento da aplicação, mas os modelos de uso podem ser infinitos porque dependem dos usuários. Quando a utilização do software ocorre de maneira inesperada, é possível que essa ação crie dados incompatíveis com os esperados pela aplicação, e como consequência ocasione a inoperância do sistema, mesmo que de forma temporária, os impactos produzidos por essa ação são contabilizados como perdas para a companhia.

A automação de testes, como aqui foi descrita, deve ser pensada como uma ferramenta para monitorar partes e elementos do software. Não é recomendada a utilização de uma única ferramenta ou uma única abordagem em testes como garantia da qualidade do software, pois diferentes formas de interação com a aplicação podem fornecer importantes informações, não somente para prevenir falhas, mas para propor melhorias para determinadas funcionalidades do sistema.

A diversificação nas técnicas de testes

O produto, mesmo funcionando, pode apresentar problemas que possivelmente não podem ser comprovados apenas com processos de verificações automatizados. Não se deve confiar apenas nos relatórios fornecidos pela ferramenta indicando que o sistema está funcionando perfeitamente, pois esse pensamento é equivocado. O software pode estar funcionando conforme o esperado, porém, em determinadas condições e sem interferências externas, mas ainda não sabemos em quais situações ele pode se comportar de forma inesperada.

Faz-se necessário reservar mais tempo para explorar o software e investigar situações que indiquem problemas de maior complexidade. Os testes automatizados asseguram a integridade de partes do sistema, liberando tempo para a busca de conhecimentos mais aprofundados do produto, os quais podem evidenciar possíveis falhas e problemas complexos que possuem relevante impacto sobre o produto, mas não são facilmente capturados pelos scripts automatizados.

A exploração do software gera uma base de conhecimento, tais como limites de dados, tipo de dados, comportamento e informações importantes após erro e sucesso, noções sobre processos e várias outras evidências que podem influenciar na melhoria da qualidade do produto. O uso de ferramentas deve ser pensado para otimizar a realização das tarefas e, muitas vezes, para obter formas diferentes de interação com o software, pois podem garantir uma maior abrangência na realização de testes e, por conseguinte, obter entregáveis de software com melhor qualidade.

—

Conclusão

Considerando o que foi observado, temos que os testes automatizados são ferramentas que auxiliam, estendendo a capacidade dos profissionais da área de qualidade de software, na execução dos trabalhos para assegurar a integridade dos entregáveis de software. Assim sendo, não é possível eximir o profissional da responsabilidade de utilizar outros métodos para efetuar testes mais robustos e diversificados com o intuito de mitigar vulnerabilidades e evitar problemas complexos que possam afetar a operabilidade do sistema.

Portanto, devemos utilizar os testes automatizados como uma das várias ferramentas disponíveis para submeter a aplicação aos diversos cenários de testes, mas não é recomendado a sua utilização como método único para realizar testes em produtos de software, se assim fosse considerado haveria grande probabilidade de observarmos vários problemas de alta complexidade nos produtos de software que consumimos atualmente. Sabemos que a variedade na abordagem dos profissionais especializados em testes de software garante a atenuação de diversos problemas na fase de desenvolvimento, mas não deve ser limitado somente a essa fase, pois o software pode apresentar comportamentos inesperados em ambientes produtivos, e assim sendo, o monitoramento deve ser contínuo em todas as fases.

Referências:

BOLTON, Michael. Things Could Get Worse: Ideas About Regression Testing.Youtube, 12 de setembro de 2012. Disponível em: <Things Could Get Worse: Ideas About Regression Testing – EuroSTAR – Michael Bolton>. Acesso em 15 março. 2023

BOLTON, Michael.The logic of verification. Youtube, 3 de outubro de 2018. Disponível em: <Michael Bolton — The logic of verification>. Acesso em 15 março. 2023

BOLTON, Michael. What ‘s Wrong with Manual Testing?. Youtube, 6 de novembro de 2020. Disponível em: <PREMIER: Michael Bolton: What’s Wrong with Manual Testing?>. Acesso em 15 março. 2023.

ISTQB – International Software Testing Qualifications Board. Certified Tester Syllabus. Test Automation Engineer(Versão traduzida, adaptada e disponibilizada na Língua Portuguesa pelo WG-Traduções do BSTQB – Brazilian Software Testing Qualifications Board). versão 1.0. 2016.