Guia completo de teste funcional automatizado

Por Federico Toledo e Matías Fornara

Neste guia, vamos fundo no quem, no quê, no onde, no quando, no porquê e no como da automação de testes funcionais. Você vai descobrir os benefícios de TI e de negócio da automação de testes e entender os momentos certos para optar pela automação. Além disso, vamos compartilhar práticas e estratégias de alto nível para o seu esforço gerar resultados ótimos.

Ao terminar a leitura, você vai estar pronto para apresentar um plano sólido de automação de testes funcionais para a sua equipe e começar a execução.

O que é teste funcional automatizado?¶

Se você pegar a definição tradicional de automação da automação industrial, pode dizer que ela se refere a uma tecnologia capaz de automatizar processos manuais, o que traz várias outras vantagens:

• Melhoria da qualidade, porque há menos erros humanos.
• Melhoria do desempenho da produção, já que se consegue mais trabalho com a mesma quantidade de pessoas, em maior velocidade e em maior escala.
• Melhoria do desempenho da produção, já que você consegue mais trabalho com a mesma quantidade de pessoas, em maior velocidade e em maior escala.

Essa definição também se aplica perfeitamente ao teste funcional automatizado (ou à verificação).

Por que automatizar o teste funcional?¶

O teste funcional foca sobretudo no comportamento do software segundo os requisitos, enquanto o teste automatizado enfatiza as metodologias, as ferramentas e os scripts usados para executar esses testes de forma automática.

Agora, gostaríamos de trazer a teoria da “acumulação zero”.

Basicamente, as funcionalidades continuam crescendo com o tempo (de uma versão para a seguinte), mas os testes não crescem. Na verdade, não ouvimos falar de nenhuma empresa que contrate mais testadores à medida que desenvolve mais funcionalidades.

À medida que um produto cresce, você tem de escolher o que testar e o que não testar, e deixa muita coisa sem teste.

As execuções de teste não são cumulativas. Cada vez que uma versão nova do sistema é liberada, é necessário (bem, é desejável, mas deveria ser necessário) testar todas as funcionalidades acumuladas. Não só as da última adição. Isso porque algumas funcionalidades implementadas em versões anteriores podem mudar o comportamento esperado por causa das mudanças novas.

A boa notícia é que a automação é cumulativa. É o único jeito de tornar o teste constante. O desafio é testar com eficiência, de um jeito que compense.

Quando as pessoas dizem que fazem teste funcional automatizado, estão usando uma ferramenta de teste funcional automatizado para verificar automaticamente se o software funciona como esperado. É uma mistura dos dois mundos: melhora a funcionalidade e, ao mesmo tempo, economiza tempo e esforço.

As equipes usam ferramentas de automação de testes para otimizar o processo de teste funcional, tanto em aplicações mobile quanto web. Ao incorporar testes contínuos, a gestão de testes flui sem interrupção. Essa abordagem amplia a cobertura, faz com que todos os testes funcionais sejam completos e reflitam as necessidades dos usuários, e resulta em produtos de software mais confiáveis.

Além disso, à medida que o teste de desempenho cruza cada vez mais com o teste funcional em ambientes ágeis, garantir a correção funcional e a eficiência de desempenho se torna essencial.

A partir dessas ferramentas e desses processos no mundo do software, o teste de automação se tornou fundamental. Ele ajuda a validar que as aplicações funcionam corretamente em todos os navegadores e plataformas, graças ao teste entre navegadores. Tudo isso alinhado às especificações definidas.

Com uma ampla variedade de ferramentas de automação e de teste disponíveis no mercado, você pode escolher as ferramentas que melhor se encaixam nos requisitos do negócio e otimizar o processo de teste.

Essas ferramentas não só favorecem a precisão, como também aceleram o ciclo de teste, o que permite uma entrega de software mais rápida e eficiente. Nesse sentido, o teste funcional automatizado firma o seu lugar como pilar no cenário em evolução dos testes de software.

Quer saber mais sobre por que automatizar o teste funcional? Não perca este artigo.

Qual é a diferença entre teste funcional e teste automatizado?¶

Antes de tudo, precisamos conhecer essas diferenças cruciais. Embora o teste funcional (também chamado de teste manual) e o teste automatizado tenham propósitos diferentes no ciclo de desenvolvimento de software, os dois buscam garantir a produção de software de alta qualidade.

À medida que a automação se torna mais comum, é crucial distinguir essas duas abordagens de teste. Aprofunde-se neste artigo para saber mais sobre teste funcional versus teste automatizado.

Quais tipos de teste podem ser automatizados?¶

Como o foco deste guia é o teste funcional automatizado, precisamos falar de testes de regressão.

Teste de regressão¶

Os testes de regressão são um subconjunto de testes programados, escolhidos para serem executados periodicamente, por exemplo, antes de um lançamento do produto. O objetivo é verificar se o produto não sofreu regressões.

O teste de regressão é o processo de testar aplicações de software para garantir que mudanças recentes no código, como funcionalidades novas ou correções de bug, não tenham afetado de forma adversa as funcionalidades existentes. O objetivo principal é pegar efeitos colaterais indesejados que possam surgir depois de modificar o software.

Você pode fazer teste de regressão de forma manual ou com ferramentas automatizadas. É uma parte essencial do ciclo de desenvolvimento de software para manter a qualidade do software. Sempre que houver uma mudança no software, você deve rodar testes de regressão para verificar se o resto do sistema permanece intacto e funciona como esperado.

Embora seja um dos tipos de teste mais populares para automatizar, não é o único uso da automação de testes. Dê uma olhada neste artigo para conhecer todos os tipos de teste que podem ser automatizados!

Teste de regressão no Agile¶

O teste de regressão no Agile ajuda você a verificar se mudanças recentes no código não afetaram de forma adversa as funcionalidades existentes. À medida que as equipes adicionam ou modificam funcionalidades continuamente nos sprints do Agile, é necessário rodar testes de regressão para pegar efeitos colaterais indesejados. Essa prática tem um papel crucial para validar que o software permanece robusto ao longo do desenvolvimento iterativo.

As ferramentas de teste automatizado são essenciais para gerir e executar esses testes com eficiência, por causa da natureza recorrente dos ciclos do Agile.

Como escolher um parceiro de qualidade para automação de testes que se encaixe nas suas necessidades específicas? Clique aqui para descobrir os insights essenciais.

Benefícios do teste funcional automatizado¶

Entrar na jornada do teste funcional automatizado oferece mais do que a detecção de bugs. Embora muitos considerem a descoberta de erros a métrica principal, as vantagens começam a aparecer desde o início da modelagem e da especificação dos testes. Além disso, é fundamental lembrar que os insights extraídos dos resultados de teste são igualmente valiosos.

• Benefícios imediatos da modelagem de testes: ao contrário da crença de que o benefício principal só vem ao identificar um erro, as recompensas surgem no momento em que você começa a formalizar os testes.
• Verificação além da detecção de erros: descobrir um erro não é o único mérito. Verificar se os testes examinam os parâmetros certos e se funcionam como deveriam é igualmente vital. Como destaca um artigo em Methods and Tools, a automação muitas vezes revela um número significativo de bugs.
• Teste rigoroso durante a automação: o processo de automação exige mergulhar nas funcionalidades, experimentar dados variados e mais. Muitas vezes, isso significa que, enquanto você tenta automatizar, também executa um teste rigoroso sem perceber.
• Cuidado com o paradoxo do pesticida: se você automatizou testes de um módulo e acredita que isso basta, para de testar? Isso apresenta um risco: os testes automatizados podem não cobrir todas as funcionalidades, espelhando o paradoxo do pesticida.
• Qualidade acima da quantidade: é um equívoco achar que um número enorme de testes equivale a um teste abrangente. Você pode ter milhares de testes, mas, se eles não forem completos, se forem parecidos demais ou se deixarem de fora funcionalidades críticas, não são tão eficazes quanto você pensa.
• Valor real da automação: não se trata da quantidade de testes nem da frequência, e sim dos insights acionáveis que eles geram.

Saiba mais sobre os benefícios do teste funcional automatizado e quando é um bom momento para automatizar.

Qual porcentagem dos testes funcionais deve ser automatizada?¶

Pela nossa experiência, é seguro dizer que há um ROI alto na automação de testes. Vimos que o custo de um único defeito, na maioria das organizações, pode compensar o preço de uma ou mais licenças de ferramenta. Além disso, defeitos de código encontrados depois do lançamento podem custar até 5 vezes mais para corrigir do que os encontrados no teste unitário.

Embora não exista uma porcentagem única de quanto teste funcional você deve automatizar, a decisão depende do ROI e da repetitividade dos testes.

A automação oferece benefícios substanciais, inclusive o ROI alto, em que o custo dos defeitos pós-lançamento pode superar o custo das licenças de ferramentas. Ela traz valor ao melhorar a qualidade do software, reduzir problemas operacionais e diminuir o custo de correção de bugs. Ferramentas modernas, como Testim.io e mabl, permitem que até quem não programa automatize testes com eficiência.

Porém, o essencial é automatizar os testes executados com frequência e pesar o custo da automação contra o número previsto de execuções. Se você precisa rodar o mesmo caso de teste várias vezes, em versões e plataformas diferentes, muitas vezes é mais econômico automatizar.

Note que o custo de uma única repetição é maior no caso automatizado. A seguir, compartilhamos um gráfico que representa isso de forma hipotética. Onde as linhas se cruzam está o ponto de inflexão em que uma opção faz mais sentido de custo do que a outra.

Se você precisa executar o caso de teste menos vezes do que esse número, é melhor não automatizar. Por outro lado, se vai testar mais vezes do que esse número, então é melhor automatizar.

Leia mais sobre qual porcentagem dos testes funcionais deve ser automatizada e aprofunde-se na matemática por trás do ROI potencial da automação de testes.

Tipos de testes funcionais automatizados¶

Os testes funcionais automatizados podem mudar o jogo em ambientes ágeis, porque permitem um processo de desenvolvimento mais rápido e eficiente.

A pirâmide ágil de automação de testes, apresentada por Mike Cohn, destaca a importância de uma base sólida com testes unitários. Esses testes avaliam ‘unidades’ individuais de software, como funções ou métodos.

Há vários métodos para automatizar o teste unitário:

• A abordagem teste primeiro, ligada ao desenvolvimento orientado a testes (TDD)
• O método tradicional de teste por último
• Teste de fronteira para os extremos
• Mocks e stubs para simular dependências

Além dos testes unitários, o teste de API facilita a comunicação fluida entre sistemas de software. Então é preciso escolher entre soluções baseadas em código ou ferramentas de GUI como o Postman para isso. Por fim, o teste de UI foca na funcionalidade da interface.

Para ir mais fundo, confira o nosso guia de teste de API ponta a ponta.

Quando a automação se concentra sobretudo no nível de UI, o foco é a detecção de bugs. Porém, a pirâmide ágil promove a prevenção de bugs. Essa metodologia é mais benéfica, porque assenta uma base forte de testes unitários e se expande para as fases de integração e de UI.

Você pode alcançar a automação de UI por meio de gravação e reprodução. Isso ganha espaço graças a ferramentas novas com recursos melhores, ou por meio do teste scriptado mais tradicional, em que os testes são codificados.

Gravação e reprodução é uma abordagem amigável para quem está começando. Como gravar um vídeo, você executa uma série de ações na aplicação, e a ferramenta grava. Depois, você pode reproduzir essas ações para ver se a UI se comporta como esperado.

Outra técnica avançada é o teste baseado em modelo, que usa modelos para o desenho de testes, feitos sob medida para teste ou derivados dos processos de desenvolvimento. Essa abordagem permite trabalhar num grau maior de abstração, sem ter de lidar com dificuldades técnicas. Tudo isso com foco só no modelo do problema, o que torna os testes mais fáceis de entender e de manter.

Para quem busca melhorar o processo e os resultados de teste, é indispensável entender a fundo esses métodos de teste automatizado.

Neste post, vamos continuar falando sobretudo de automação com script, apoiada em ferramentas como gravação e reprodução. Essas ferramentas permitem que as equipes parametrizem as ações e sigam uma abordagem de teste orientado a dados.

Além disso, vamos fazer sugestões ligadas ao desenho de testes. Vamos cobrir aspectos diferentes do ambiente de automação, considerando que o desenho será feito de forma manual, não necessariamente com ferramentas de técnica baseada em modelo.

Como superar desafios comuns do teste funcional automatizado¶

Automatizar testes funcionais oferece uma série de benefícios, mas também traz desafios. O essencial é achar jeitos eficientes de atravessar esses desafios. Nesta seção, você descobre estratégias acionáveis para dominar o teste funcional automatizado.

Manutenção de testes¶

À medida que um produto evolui, manter os testes automatizados se torna fundamental. Sobretudo quando o número de testes cresce, uma estrutura organizada e clara torna essa tarefa bem mais fácil e menos caótica.

Nomenclatura¶

Escolher a convenção de nomes certa para os seus casos de teste e para as estruturas de organização é um passo pequeno que pode render resultados grandes. Busque nomes informativos e concisos, que façam sentido para a sua equipe e sigam as diretrizes de estilo.

Considere também uma estrutura de pastas que separe os casos de teste gerais dos módulos específicos, o que facilita reutilizar e integrar testes em outros lugares. De vez em quando, você também pode precisar de casos de teste temporários, que podem receber um prefixo uniforme para identificação fácil.

Comentários e descrições¶

É útil anexar uma descrição breve a cada caso de teste, com o objetivo. Além disso, anotar os passos do teste e os objetivos dos dados pode agilizar a execução e a revisão.

Arquivo “Leia-me”¶

Imagine entregar um aparelho complexo sem manual de usuário. É isso que acontece quando se pula um arquivo “Leia-me” no framework de teste. Equipe a sua equipe e os possíveis usuários com um guia completo que detalhe o propósito, as tecnologias, as dependências, as instruções e o processo de colaboração do framework de teste.

Casos de teste e scripts de teste¶

O debate eterno: um script por caso de teste ou um único script para vários casos de teste? As duas abordagens têm méritos. Uma abordagem modular, que divide um caso de teste em módulos menores e reutilizáveis, geridos por um único script, muitas vezes se mostra a mais eficiente. Isso permite mais flexibilidade, manutenibilidade e clareza.

A abordagem modular de script traz uma série de benefícios:

• Manutenção: simplifica atualizações e mudanças.
• Reutilização: você pode reutilizar módulos em cenários diferentes.
• Flexibilidade: é possível fazer ajustes em etapas diferentes sem afetar o script inteiro.
• Clareza: uma abordagem estruturada permite entender com mais clareza o fluxo e os objetivos do teste.

Para ampliar ainda mais a eficiência, manter uma matriz que ligue casos de teste aos scripts relacionados ajuda a acompanhar o impacto das mudanças de requisito nos testes e nos scripts.

Como evitar falsos positivos e falsos negativos¶

Resultados falsos na automação podem ser um pesadelo. O teste, em essência, deve dar resultados precisos. Então, como evitamos essas armadilhas no teste automatizado? A resposta está num desenho de teste cuidadoso, em revisões regulares e em entender as causas raiz dos resultados falsos.

Explicamos em detalhe neste post como evitar falsos positivos e negativos na sua automação de testes.

Teste de serviços de terceiros¶

Interações com serviços ou aplicações de terceiros podem acrescentar outra camada de complexidade. Seja com lógica intricada, integrações de serviço web ou o proverbial lançamento de foguete, lembre que o objetivo principal da ferramenta de automação é emular as interações do usuário. Isso significa que, em muitos casos, as complexidades de fundo importam menos do que garantir que a interface se comporte como esperado.

Para tarefas fora da interface gráfica de usuário, como consultas a banco de dados ou transferência de arquivos, a maioria das ferramentas oferece funcionalidades específicas ou permite programação personalizada. Porém, simular ou conectar de verdade a serviços externos pode ser complicado. Serviços simulados, como o SoapUI ou o Postman, podem replicar serviços externos e facilitar um teste eficiente.

Como fazer teste funcional automatizado¶

Digamos que você já tenha os casos de teste desenhados. Você começa conferindo o inventário de funcionalidades (ou o backlog, ou onde quer que guarde essa informação) e atribui um nível de prioridade a cada uma. Depois, deve atribuir prioridade a cada caso de teste preparado para cada uma das funcionalidades.

Essa organização e essa priorização ajudam a dividir o trabalho (caso seja um grupo de testadores) e a colocá-lo em ordem, já que agrupar os dispositivos de teste por algum critério é muito recomendado. Por exemplo, por funcionalidade.

Você se sai melhor se definir desenhos de caso de teste para teste automatizado em dois níveis de abstração.

De um lado, há o que vamos chamar de casos de teste abstratos ou paramétricos. Do outro, há os chamados casos de teste específicos, também conhecidos como casos de teste concretos.

Vamos revisar esses conceitos e aplicá-los a este contexto.

Casos de teste abstratos são scripts de teste que, ao indicar quais dados serão usados, não se referem a valores concretos. Em vez disso, se relacionam com classes de equivalência, ou com um conjunto válido de valores, como “número entre 0 e 18”, “string de comprimento 5” ou “ID de cliente válido”.

Do outro lado, há os casos de teste concretos, em que os casos de teste abstratos têm valores específicos. Por exemplo, usam o número “17” ou a string “abcde”, e “1.234.567-8”, que poderia ser considerado um identificador válido. Estes últimos são os que você de fato pode executar, e por isso também se chamam “casos de teste executáveis”.

É importante distinguir esses dois “níveis”, porque você vai trabalhar com eles em etapas diferentes do processo de automação. Isso é para seguir uma abordagem de teste orientado a dados, que difere bastante do script simples.

Para scripts de teste automatizado, o teste orientado a dados envolve testar a aplicação puxando informação de fontes externas, como bancos de dados ou planilhas. Em vez de codificar os dados direto nos scripts, esse método aumenta a flexibilidade. Ele permite acrescentar diversidade aos testes só estendendo o conjunto de dados.

Em outras palavras, você parametriza o caso de teste, o que permite rodá-lo com dados diferentes. O objetivo principal é poder acrescentar mais casos de teste só adicionando mais linhas ao arquivo de dados de teste.

Além disso, o conceito de oráculo de teste ajuda a distinguir resultados válidos e inválidos. Ao montar a suíte de teste, considere agrupar os casos de teste pela funcionalidade ou pelo nível de importância. E um conselho: se uma função faz a suíte tropeçar, mergulhar nos testes dependentes pode não ser o melhor uso do tempo.

Desenho da suíte de teste¶

As ferramentas em geral permitem agrupar casos de teste para organizá-los e rodá-los todos juntos. Você pode definir a organização por critérios diferentes, como módulo ou funcionalidade e criticidade. Pode até combinar essas abordagens com critérios cruzados ou aninhados.

Definir dependências entre suítes pode ser muito interessante, já que há funcionalidades que, se falham, invalidam diretamente outros testes. Não faz sentido perder tempo rodando testes que você sabe que vão falhar.

Ou seja, por que rodá-los se eles não trazem informação nova? É melhor parar tudo quando surge um problema, atacá-lo de frente e depois rodar o teste de novo até tudo funcionar direito (isso segue o Jidoka como metodologia).

Plano de automação de testes¶

Na era digital, o teste não é um pensamento posterior. É parte integrante do processo de desenvolvimento de software. Você deve pensar bem essa tarefa e planejá-la desde o início, até antes de planejar o desenvolvimento.

Se você está entrando na automação, o planejamento é o seu melhor aliado. Da configuração da automação à manutenção, e da detecção de bugs às correções, cada passo precisa de um planejamento cuidadoso.

Gestão de ambientes de teste¶

Gerenciar os seus ambientes de teste não é negociável. Pense nisso como montar o palco de uma peça. Você precisa de:

• Os fontes e os executáveis da aplicação.
• Dispositivos de teste e os dados deles.
• Informação de banco de dados atualizada, específica do ambiente de teste.
• Imagens ou arquivos Docker apropriados (se usar Docker).

Uma dica: você pode ter testes com requisitos diferentes. Em vez de criar muitos ambientes, considere ter backups de banco de dados feitos sob medida para testes específicos.

Porém, permitir a sincronização entre esses elementos é fundamental. Afinal, quando um teste sinaliza um erro, deve ser por um problema real, não por um descompasso de ambiente.

Quando e onde rodar testes automatizados¶

Com que frequência você deve rodar testes automatizados? Embora “com frequência” pareça o ideal, a praticidade muitas vezes manda o contrário. Lembre:

• Se os testes são rápidos, rode todos.
• Se demoram, priorize com base no risco e nas mudanças recentes da aplicação.

Quanto a onde rodar esses testes, você tem opções:

• Ambiente de desenvolvimento: para quem desenvolve, a velocidade é essencial. Ciclos rápidos de feedback aqui ajudam a resolver problemas depressa.
• Ambiente de integração e teste: aqui, testes de regressão mais extensos garantem que problemas já encontrados continuem resolvidos.
• Ambiente de pré-produção e produção: antes de entregar ao cliente, a aplicação passa por testes num ambiente que espelha a configuração real de produção. Os testes automatizados podem ser de grande valor aqui, e deixam o produto final o mais polido possível.

Não esqueça: embora os testes de UI sejam valiosos, eles levam tempo. Por isso, maximizar os testes no nível de API pode economizar um tempo significativo durante a regressão.

Convidamos você a aprender como melhorar a sua estratégia de teste de API com as heurísticas mais conhecidas e uma heurística nova proposta pela nossa equipe neste artigo.

Ferramentas de teste funcional automatizado¶

Ao entrar no universo das ferramentas de teste funcional automatizado, há uma infinidade de opções, cada uma desenhada para atender a níveis de teste diferentes, seja unitário, de API ou de UI.

Ferramentas populares de teste unitário¶

1. JUnit: usado sobretudo em aplicações Java, o JUnit é um framework simples para escrever testes repetíveis.
2. NUnit: é para aplicações .NET. Parecido com o JUnit na abordagem, mas feito para o ambiente .NET.
3. TestNG: evoluiu a partir do JUnit e foi desenhado para execução paralela de alto nível.

Ferramentas populares de teste de API¶

1. Postman: uma escolha popular para muita gente, o Postman torna o desenvolvimento de API mais rápido e fácil.
2. Insomnia: um aplicativo desktop gratuito e multiplataforma que simplifica a interação e o desenho de APIs baseadas em HTTP.
3. SoapUI: feito tanto para teste de API SOAP quanto REST, o SoapUI é uma ferramenta abrangente.
4. Rest-Assured: para quem desenvolve em Java, o Rest-Assured simplifica o processo de testar e validar APIs RESTful.

Conheça as nossas 15 principais ferramentas de automação de API neste artigo.

Ferramentas populares de teste de UI¶

1. Selenium: provavelmente uma das ferramentas mais conhecidas para automatizar navegadores web. Seja testando uma página simples ou uma aplicação web complexa, o Selenium é uma ferramenta de código aberto, versátil e amplamente adotada.
2. Appium: para aplicações mobile, o Appium é uma das principais escolhas como ferramenta de código aberto. Permite testar nas plataformas Android e iOS, e ajuda os apps mobile a brilharem em qualquer dispositivo.
3. Cypress: desenhado para aplicações web modernas, oferece recarga em tempo real e espera automática, o que torna o teste de UI mais fluido e intuitivo.
4. Mabl: uma solução low-code, com autocorreção e SaaS, que busca simplificar a criação e a manutenção de testes, torná-los escaláveis e gastar menos tempo corrigindo testes.
5. Protractor: feito para aplicações Angular, o Protractor roda testes num navegador real e interage com a aplicação como um usuário faria.
6. Testim.io: o Testim usa inteligência artificial para acelerar a autoria, a execução e a manutenção de testes automatizados.
7. Reflect: o Reflect oferece testes ponta a ponta na nuvem, sem script. Você não precisa escrever scripts de teste. Em vez disso, executa ações no seu site, e o Reflect grava e reproduz.
8. GhostInspector: esta ferramenta permite criar ou gravar testes automatizados de navegador e depois rodá-los de forma contínua a partir da nuvem.

Boas práticas de teste funcional automatizado¶

Padrão Page Object¶

Na nossa jornada de automação, percebemos uma coisa: código sustentável vale ouro. É a diferença entre correr atrás de atualizações o tempo todo e saber, com confiança, que os seus testes vão se sustentar. Padrões de desenho, em especial o Page Object, têm sido o nosso guia.

Pense assim: se um botão muda na sua aplicação, você prefere refazer 100 testes ou ajustar uma única referência? Essa é a mágica do encapsulamento.

O padrão Page Object propõe uma camada de adaptação formada por objetos específicos para gerir a interação entre os casos de teste e a aplicação sob teste. Para isso, você precisa guardar os localizadores de elementos de um jeito bem organizado. Se quiser ver bons exemplos, confira isto.

Qual problema você resolve com código sustentável? Se você tem 100 casos de teste que interagem com um certo botão e o desenvolvimento mudou o localizador do elemento, então você precisaria manter 100 casos de teste ou, pelo menos, 100 linhas de código!

A solução é muito simples: encapsulamento. Você precisa ter o localizador do elemento definido num único lugar e referenciar o elemento a partir dos 100 casos de teste. Então, se a mudança acontecer, você só precisa manter uma linha de código e todos os casos de teste vão funcionar direito.

Dando um passo além, você pode acrescentar ainda mais encapsulamento e abstração à arquitetura de testes. Por exemplo, é possível definir métodos de teste diferentes nos page objects, inclusive ações comuns.

Embora você possa confiar no padrão Page Object como um aliado confiável, outros padrões, como o Screenplay, esperam ser explorados. Além disso, você pode usar qualquer outro padrão de desenho dentro do framework para melhorar a manutenibilidade do código.

Desenho de testes segundo os objetivos¶

Definir objetivos claros é fundamental. Na automação de testes, ter um mapa é essencial. Você vai ter de tomar certas decisões sobre ir por um caminho ou por outro, selecionar certos casos de teste em vez de outros e desenhá-los com uma abordagem ou estratégia.

Você busca um teste consistente ou pretende detectar mais cedo aqueles erros de regressão difíceis de pegar? Definir os objetivos de antemão economiza tempo e evita armadilhas mais adiante.

Teste baseado em risco¶

Com os objetivos definidos, como decidimos as prioridades? É aqui que o teste baseado em risco brilha. Ele nos orienta para os casos de teste realmente cruciais. Consideramos fatores como a relevância para o negócio, as possíveis implicações financeiras e aqueles SLAs que obrigam. Às vezes, as implicações são significativas, sobretudo com dados sensíveis em jogo. Com o teste baseado em risco, não estamos só testando. Estamos fazendo escolhas informadas.

Para saber mais sobre teste baseado em risco, confira este post.

Agora, hora de automatizar!¶

Depois desta leitura, esperamos que você se sinta confiante para começar os esforços de automação de testes funcionais. Gostaríamos de compartilhar um último pensamento…

Concordamos plenamente. A automação não pode substituir o trabalho de um testador, mas pode torná-lo melhor e mais abrangente.

Você não deve automatizar tudo, e não deve tentar substituir por completo o teste manual. Algumas coisas não podem ser automatizadas e, às vezes, é mais fácil fazer algo de forma manual do que automatizar.

Na verdade, se fosse possível rodar todo o teste de forma manual, talvez fosse bem melhor, porque essa execução manual pode revelar outros problemas ao mesmo tempo. Lembre que os testes automatizados verificam, mas não testam. O problema é que algumas coisas levam mais tempo para verificar de forma manual. Essa abordagem não combina com a pressão incessante da nossa indústria de entregar o tempo todo releases e produtos melhores.

No cenário dinâmico de entrega e integração contínuas, o teste manual sozinho fica curto. Falta a eficiência, a velocidade e a escalabilidade necessárias para acompanhar as ambições de desenvolvimento rápido e lançamentos frequentes. Por isso a automação é tão crítica.

Esperamos que este guia ajude você no esforço de automatizar testes funcionais. Fique à vontade para entrar em contato e comentar abaixo, compartilhando a sua experiência com teste funcional automatizado.