Da Infraestrutura ao QA Automatizado: Como a Visão Sistêmica e o Playwright Elevam a Confiabilidade

Autor: Pedro Gomes Oliveira 

Programa: DIO Campus Expert #17 | Apoio: Santander 

Introdução: Por que pensar em qualidade desde o primeiro dia?

Em um cenário de desenvolvimento ágil e entregas contínuas, entregar software rápido deixou de ser o único diferencial competitivo. O verdadeiro desafio moderno é entregar com velocidade sem comprometer a estabilidade, a usabilidade e a segurança.

Muitos desenvolvedores no início de suas carreiras enxergam testes automatizados como uma etapa burocrática, realizada apenas após a implementação ou relegada a uma equipe isolada no final do sprint. No entanto, quando aliamos a visão de processos (negócio), a vivência em infraestrutura e redes e a engenharia de requisitos**, percebemos que um defeito (*bug*) em produção não é apenas um erro de sintaxe: ele representa perda de confiança do cliente, retrabalho e custos operacionais elevados.

Neste artigo, compartilho reflexões da minha jornada na graduação em Engenharia de Software na UnB e no programa DIO Campus Expert #17, demonstrando na prática como estruturar uma estratégia sólida de testes End-to-End (E2E) utilizando Playwright e o padrão arquitetural Page Object Model (POM).

---

🧭 1. A Visão Sistêmica: Da Infraestrutura ao Comportamento do Usuário

Antes de escrever qualquer linha de código de teste, é essencial entender o ecossistema no qual a aplicação opera. Minha experiência prévia com suporte técnico de TI, redes e sistemas operacionais (Windows e Linux) me ensinou algo fundamental: sistemas falham em pontos de transição.

As falhas mais críticas raramente estão em funções matemáticas puras; elas ocorrem:

1. Na comunicação entre camadas (front-end consumindo APIs lentas ou com payloads inesperados);

2. Em concorrência e integridade referencial no banco de dados (ex.: transações simultâneas em MySQL);

3. Em fluxos ponta a ponta reais vivenciados pelo usuário através do navegador.

É exatamente aqui que a pirâmide de testes ganha vida. Enquanto testes unitários garantem que blocos isolados funcionem e testes de integração validam contratos entre módulos, os testes E2E (End-to-End) simulam a interação humana real, validando o comportamento do sistema de ponta a ponta sob a ótica da regra de negócio.

---

🚀 2. Por que o Playwright se tornou uma referência em Automação E2E?

Historicamente, ferramentas de automação web enfrentavam problemas crônicos de instabilidade (*flaky tests*) devido a problemas de temporização e esperas explícitas (`sleep`). O * Auto-Waiting nativo:

*O Playwright aguarda automaticamente que os elementos estejam visíveis, estáveis e interativos antes de executar qualquer clique ou digitação.

* Execução Multi-Browser: Suporte nativo ao Chromium, Firefox e WebKit em um único motor.

* Isolamento via Browser Contexts: Cada teste é executado em uma sessão isolada, dispensando o overhead de recriar instâncias pesadas de navegadores.

* Testes de Acessibilidade e Network Mocking: Permite interceptar requisições HTTP e validar árvores de acessibilidade (crucial para conformidade WCAG).

---

🏛️ 3. Boas Práticas: O Padrão Page Object Model (POM)

Escrever testes E2E diretamente em scripts com seletores espalhados (`page.click('#btn-submit')`) é uma armadilha clássica. Quando um botão muda de classe ou ID, dezenas de testes quebram simultaneamente.

O padrão Page Object Model (POM) resolve isso ao encapsular a estrutura HTML e os comportamentos de uma página em classes dedicadas. O script de teste foca na intenção do negócio, enquanto a classe da página gerencia os detalhes de implementação da interface.

Exemplo Prático:

#### Passo 1: A Classe Page Object (`LoginPage.js`)


```javascript
// pages/LoginPage.js
class LoginPage {
/
 * @param {import('@playwright/test').Page} page
 */
constructor(page) {
  this.page = page;
  this.emailInput = page.locator('input[type="email"]');
  this.passwordInput = page.locator('input[type="password"]');
  this.submitButton = page.locator('button[type="submit"]');
  this.errorMessage = page.locator('[role="alert"]');
  this.welcomeBanner = page.locator('h1.welcome-title');
}


async navegar() {
  await this.page.goto('/login');
}


async realizarLogin(email, senha) {
  await this.emailInput.fill(email);
  await this.passwordInput.fill(senha);
  await this.submitButton.click();
}


async obterMensagemErro() {
  return await this.errorMessage.textContent();
}
}


module.exports = { LoginPage };

// tests/login.spec.js
const { test, expect } = require('@playwright/test');
const { LoginPage } = require('../pages/LoginPage');


test.describe('Funcionalidade de Autenticação de Usuário', () => {


  test('Deve realizar login com credenciais válidas com sucesso', async ({ page }) => {
    const loginPage = new LoginPage(page);


    await loginPage.navegar();
    await loginPage.realizarLogin('usuario.teste@unb.br', 'SenhaSegura#2026');


    // Validação da transição de estado e feedback ao usuário
    await expect(loginPage.welcomeBanner).toBeVisible();
    await expect(page).toHaveURL(/.*\/dashboard/);
  });


  test('Deve exibir alerta ao inserir credenciais inválidas', async ({ page }) => {
    const loginPage = new LoginPage(page);


    await loginPage.navegar();
    await loginPage.realizarLogin('usuario.invalido@unb.br', 'SenhaErrada');


    const mensagem = await loginPage.obterMensagemErro();
    expect(mensagem).toContain('Credenciais inválidas');
  });
});

Perceba como o arquivo de teste é legível tanto para um desenvolvedor quanto para um analista funcional de requisitos. Se a interface mudar, alteramos apenas o locator na classe `LoginPage`.

📊 4. Conectando Qualidade, Acessibilidade e Métricas

Na Engenharia de Software, qualidade vai além de apenas "não dar erro". Ela abrange conformidade técnica e inclusão.

Durante investigações práticas de código e análise de projetos abertos (como o projeto *Cboard* de comunicação assistiva), fica evidente que a acessibilidade digital não é um adorno, mas um requisito essencial. Com o Playwright, podemos integrar bibliotecas como `@axe-core/playwright` para validar violações de contraste, atributos ARIA e navegabilidade por teclado no mesmo pipeline em que rodamos os testes de regressão.

Além disso, relatórios de cobertura (*code coverage*) e rastreabilidade de defeitos fornecem insumos objetivos para que o time decida com confiança se uma nova versão está pronta para implantação.

---

5. Conclusão e Principais Aprendizados

Integrar visão de processos, infraestrutura computacional e qualidade de software me permitiu compreender que **testar não é procurar bugs, mas sim garantir que a solução entregue resolve o problema certo da forma mais robusta possível**.

Para quem deseja iniciar ou se aprofundar na área de Qualidade e Engenharia de Software:

1. **Comece com a regra de negócio:** Entenda o que o usuário realmente precisa realizar antes de automatizar o fluxo.

2. **Priorize a manutenibilidade:** Aplique padrões como o Page Object Model para evitar código frágil e duplicado.

3. **Pense sistemicamente:** Considere o ambiente, a latência de rede, os estados de erro da API e o comportamento do banco de dados.

4. **Construa um portfólio baseado em evidências:** Demonstre seus testes em repositórios abertos no GitHub com documentação clara, scripts reproduzíveis e relatórios de execução.

Agradeço à comunidade da **DIO** e aos mentores do **DIO Campus Expert #17** por incentivarem essa cultura de aprendizado contínuo e protagonismo tecnológico!

---

💬 Vamos trocar experiências?

Como você estrutura os testes na sua equipe ou nos seus projetos pessoais? Costuma utilizar Playwright, Cypress ou focar em testes de unidade? Deixe seu comentário abaixo!

Conecte-se comigo e acompanhe meus projetos no GitHub - https://github.com/pedroG0.