Arquiteturas de Automação

🔺 Pirâmides de Teste

FUNDAMENTOS

As pirâmides de teste definem estratégias para distribuir diferentes tipos de testes. Entender esses conceitos é fundamental para aplicar qualidade de software de forma eficiente, otimizando custo, velocidade e confiabilidade.

Verde - Unitários (Base)

Azul - Integração (Meio)

Laranja - E2E (Topo)

🔺 Pirâmide Tradicional

E2E (Topo)

Integração

Unitários (Base)

Base larga de testes unitários, menos integração e poucos End-to-End. Abordagem clássica e equilibrada.

Rápida execução e feedback
Baixo custo de manutenção
Fácil paralelização
Ideal para projetos bem estruturados

🔺 Pirâmide Moderna

UI / E2E (~10%)

API / Serviços (~20%)

Unit Tests (~70%)

Foco maior em unitários (70%), integração robusta por APIs (20%) e mínimo de E2E (10%). Recomendada pelo ISTQB.

Prioriza rapidez e confiabilidade
Perfeita para CI/CD
Releases frequentes
Cobertura otimizada

🔺 Pirâmide Front-end

E2E (Fluxos críticos)

integração (API mocks)

Unit (Componentes)

Componentes como base, integração para juntar peças, E2E para fluxos críticos de usuário.

Testa isolamento de componentes
Mocks para integrações externas
Evita excesso de testes UI
Feedback rápido no desenvolvimento

🔺 Pirâmide Back-end / APIs

E2E multi-serviços

Contrato / Integração

Unit (Domínio / Regras)

Unit tests para lógica de negócio, contratos para integração e E2E para verificação completa.

Contract Testing fundamental
Testa regras de negócio isoladas
Integração entre microsserviços
Validação de contratos de API

💎 Diamante

Unit (Topo)

integração (Centro)

Unit (Base)

Maior foco em integração (centro robusto) com suporte de unit tests acima e abaixo.

Usado quando integração é crítica
Sistemas altamente acoplados
Microsserviços com muitas dependências
Valida comunicação entre serviços

⚠️ Pirâmide Invertida (Anti-padrão)

UI / E2E (muitos)

Integração (poucos)

Unit (poucos)

EVITAR! Inverte a recomendação — muito frágil, lento e custoso de manter.

Execução muito lenta (horas)
Testes frágeis e instáveis (flaky)
Difícil identificar causa raiz
Alto custo de manutenção

⚠️ Relógio de Areia

E2E (muitos)

integração (poucos)

Unit (muitos)

ATENÇÃO! Cobertura de integração fraca — problemas entre serviços passam despercebidos.

Falhas em produção por integração
Gargalo na camada de integração
Defeitos não detectados entre módulos
Dificulta refatoração

⚠️ Cone de Sorvete

Manual Testing (muito)

E2E Automated (muito)

integração

Unit (pouco)

PROBLEMA! Excesso de testes manuais e E2E no topo, base fraca de automação.

Dependência excessiva de testes manuais
Lançamentos lentos
Feedback tardio sobre defeitos
Custo alto de recursos humanos

BOAS PRÁTICAS

✔ Fazer

✔ 70% de testes unitários rápidos
✔ 20% de testes de integração/API
✔ 10% de testes E2E críticos
✔ Execução em menos de 10 minutos
✔ Testes confiáveis e determinísticos
✔ Feedback rápido no CI/CD

✗ Evitar

✗ Excesso de testes E2E lentos
✗ Testes frágeis (flaky tests)
✗ Dependência de testes manuais
✗ Pouca cobertura de integração
✗ Execução que leva horas
✗ Testes não-determinísticos

REFERÊNCIAS

ISTQB Foundation Level • ISTQB CTAL-TA (Test Automation Engineer) • ISTQB CTAL-TTA (Technical Test Analyst)

📦 Page Object Model (POM)

LEGENDA DE CORES

Roxo - Page Objects (Abstração UI)

Laranja - Sistema (SUT)

Amarelo - Configuração

Verde - Piloto

FLUXO DE EXECUÇÃO

Test Spec

Arquivo de teste
Cenários e assertions

→

Page Object

Abstração de UI
Elementos e ações

→

Sistema

Auto Avaliar
Aplicação real

Test Spec

Onde os cenários de teste são escritos

Describe/It blocks
Assertions (expect)
Setup e teardown

Page Object

Abstração da interface do usuário

Locators encapsulados
Métodos de ação
Reutilização de código

Sistema (SUT)

Aplicação real sendo testada

Auto Avaliar
Ambientes (DEV/HML/PROD)
Interface real

HIERARQUIA DE PROJETO

AUTO AVALIAR

Produto Principal

🇦🇷 Argentina

Futuro

🇲🇽 México

Futuro

PILOTO

🇧🇷 Brasil

Implementação Inicial

🇵🇹 Portugal

Futuro

🇪🇸 Espanha

Futuro

ADM-New

pages/adm-new/

ADM-Legado

pages/adm-legado/

B2B

pages/b2b/

Car Invest

pages/car-invest/

Auto Sync

pages/auto-sync/

LoginPage

Comum a todos

DashboardPage

Comum a todos

DIAGRAMA DE CLASSES

«interface»

IPage

Métodos

+ navegar(): void

+ aguardarCarregamento(): void

+ obterTitulo(): string

implements

«abstract»

BasePage

Atributos

# page: Page

# url: string

# timeout: number

Métodos

+ navegar(): void

+ aguardarCarregamento(): void

+ obterTitulo(): string

+ capturarTela(): void

# clicar(locator): void

# preencher(locator, valor): void

# obterTexto(locator): string

extends

LoginPage

Atributos

- inputEmail: Locator

- inputSenha: Locator

- btnEntrar: Locator

- msgErro: Locator

Métodos

+ realizarLogin(email, senha): void

+ validarMensagemErro(): string

+ estaLogado(): boolean

DashboardPage

Atributos

- textoBoasVindas: Locator

- menuLateral: Locator

- cardResumo: Locator

Métodos

+ obterMsgBoasVindas(): string

+ navegarParaMenu(item): void

+ obterTotalCards(): number

ESTRUTURA DE PASTAS

📁 autoavaliar-pom/
│
├── 📁 src/
│   │
│   ├── 📁 pages/                         ← Page Objects
│   │   │
│   │   ├── 📁 common/                   ← Páginas compartilhadas
│   │   │   ├── BasePage              
│   │   │   ├── LoginPage
│   │   │   └── HeaderComponent
│   │   │
│   │   ├── 📁 adm-new/
│   │   │   └── DashboardPage
│   │   │
│   │   ├── 📁 adm-legado/
│   │   │   └── DashboardPage
│   │   │
│   │   ├── 📁 b2b/
│   │   │   └── DashboardPage
│   │   │
│   │   ├── 📁 car-invest/
│   │   │   └── DashboardPage
│   │   │
│   │   └── 📁 auto-sync/
│   │       └── DashboardPage
│   │
│   ├── 📁 specs/                         ← Arquivos de teste
│   │   ├── 📁 adm-new/
│   │   │   ├── login.spec
│   │   │   └── dashboard.spec
│   │   │
│   │   ├── 📁 adm-legado/
│   │   │   ├── login.spec
│   │   │   └── dashboard.spec
│   │   │
│   │   ├── 📁 b2b/
│   │   │   ├── login.spec
│   │   │   └── dashboard.spec
│   │   │
│   │   ├── 📁 car-invest/
│   │   │   ├── login.spec
│   │   │   └── dashboard.spec
│   │   │
│   │   └── 📁 auto-sync/
│   │       ├── login.spec
│   │       └── dashboard.spec
│   │
│   ├── 📁 support/                       ← Helpers e utilitários
│   │   ├── api-client
│   │   ├── db-utils
│   │   └── test-helpers
│   │
│   └── 📁 utils/                         ← Funções auxiliares
│       ├── date-helper
│       ├── string-helper
│       └── validation-helper
│
├── 📁 config/                            ← Configurações por ambiente
│   ├── dev.config
│   ├── hml.config
│   └── prod.config
│
├── 📁 fixtures/                          ← Dados de teste (massa)
│   ├── usuarios.json
│   └── produtos.json
│
└── README.md

EXEMPLO DE EXECUÇÃO

// Estrutura de um teste POM
describe('Login - B2B', () => {
let loginPage: LoginPage;

let dashboardPage: DashboardPage;
beforeEach(() => {
loginPage = new LoginPage(page);
dashboardPage = new DashboardPage(page); });
it('deve realizar login com sucesso', async () => {

// Arrange
await loginPage.navegar();
// Act
await loginPage.realizarLogin('usuario@email.com', 'senha123');
// Assert
const mensagem = await dashboardPage.obterMsgBoasVindas();

expect(mensagem).toContain('Bem-vindo');
}); });

PRINCÍPIOS DO POM

✔ Princípios

✔ Uma classe por página/componente
✔ Encapsular locators como privados
✔ Métodos públicos representam ações do usuário
✔ Herança para comportamentos comuns
✔ Composição para componentes reutilizáveis
✔ Nomes descritivos e significativos

✗ Anti-padrões

✗ Assertions dentro das Page Objects
✗ Locators expostos publicamente
✗ Classes muito grandes (God Object)
✗ Duplicação de código entre páginas
✗ Lógica de teste na Page Object
✗ Dependências circulares entre páginas

REFERÊNCIAS

ISTQB Foundation Level • ISTQB CTAL-TA (Test Automation Engineer) • ISTQB CTAL-TTA (Technical Test Analyst)

🥒 BDD - Behavior Driven Development

LEGENDA DE CORES

Verde - Features (Gherkin)

Azul - Steps (Definições)

Roxo - Page Objects

Laranja - Sistema (SUT)

FLUXO DE EXECUÇÃO

Feature

Cenários Gherkin
PO/QA escrevem

→

Steps

Definições
QA implementa

→

Pages

Page Objects
Abstração UI

→

SUT

Sistema
Auto Avaliar

Features

Cenários em linguagem natural (Gherkin)

Dado/Quando/Então
Legível pelo negócio
Documentação viva

Steps

Implementação dos passos

Given/When/Then
Conecta Gherkin ao código
Reutilizável entre features

Page Objects

Abstração da interface

Mesma estrutura do POM
Encapsula elementos
Métodos de ação

Sistema

Aplicação sendo testada

Auto Avaliar
ADM, B2B, Car Invest...
Ambiente real

HIERARQUIA DE PROJETO

AUTO AVALIAR

Framework BDD

Features

Cenários Gherkin

Steps

Implementação

Pages

Page Objects

Support

Hooks & Config

PILOTO

🇧🇷 Brasil

features/brasil/

ADM-New

dashboard.feature

ADM-Legado

dashboard.feature

B2B

dashboard.feature

Car Invest

dashboard.feature

Auto Sync

dashboard.feature

ESTRUTURAS BDD - EXEMPLOS

1 Cenário Simples ▼

# language: pt
@tagExemplo
Funcionalidade: Login no Sistema
Como um usuário do sistema
Eu quero realizar login
Para acessar o dashboard

Cenário: Login com credenciais válidas
Dado que estou na página de login
Quando eu informo o email "usuario@email.com"
E eu informo a senha "Senha@123"
E eu clico no botão "Entrar"
Então devo ser redirecionado para o dashboard

2 Cenário com Contexto (Background) ▼

# language: pt @tagExemplo
Funcionalidade: Dashboard do Sistema
Como um usuário autenticado
Eu quero visualizar o dashboard
Para acompanhar as informações do sistema

Contexto:
Dado que estou logado no sistema
E estou na página do dashboard

Cenário: Visualizar cards de resumo
Então devo ver os cards de resumo
E devo ver o menu lateral

Cenário: Navegar pelo menu
Quando eu clico no menu "Relatórios"
Então devo ser redirecionado para a página de relatórios

3 Esquema do Cenário (Data-Driven) ▼

# language: pt
@tagExemplo
Funcionalidade: Login com múltiplos usuários

Esquema do Cenário: Login em múltiplos ambientes
Dado que estou no ambiente "<ambiente>"
Quando eu faço login com "<email>" e "<senha>"
Então devo acessar o dashboard
E devo ver a mensagem "<mensagem>"

Exemplos:

                                Ambiente |
                                Email |
                                Senha |
                                Mensagem


                                DEV |
                                dev@autoavaliar.com |
                                Dev@123 |
                                Bem-vindo, Dev


                                HML |
                                hml@autoavaliar.com |
                                Hml@123 |
                                Bem-vindo, HML


                                PROD |
                                prod@autoavaliar.com |
                                Prod@123 |
                                Bem-vindo, Prod

                            

4 Cenário com Tabela de Dados ▼

# language: pt @tagExemplo
Funcionalidade: Validação de Dashboard

Cenário: Verificar informações do dashboard
Dado que estou logado como administrador
Quando eu acesso o dashboard
Então devo ver os seguintes cards:

                                Card |
                                Valor
                                    Esperado

                                Total de Usuários |
                                Maior que 0

                                Vendas do Mês |
                                Maior que 0

                                Tickets Abertos |
                                Qualquer

                                Avaliações |
                                Maior que 0

5 Cenário com DocString (Texto Longo) ▼

# language: pt @tagExemplo
Funcionalidade: Integração com API

Cenário: Enviar dados para API
Dado que estou autenticado na API
Quando eu envio uma requisição POST com o payload:

"""
{
"usuario": "teste@autoavaliar.com",
"acao": "criar_avaliacao",
"dados": {
"veiculo_id": 12345,
"valor": 50000
}
}
"""
Então devo receber status code "201"
E a resposta deve conter "sucesso"

ESTRUTURA DE PASTAS

📁 autoavaliar-bdd/
│
├── 📁 features/                          ← Arquivos feature
│   │
│   └── 📁 brasil/                        ← PILOTO - Brasil primeiro
│       │
│       ├── 📁 adm-new/
│       │   ├── login.feature
│       │   └── dashboard.feature
│       │
│       ├── 📁 adm-legado/
│       │   ├── login.feature
│       │   └── dashboard.feature
│       │
│       ├── 📁 b2b/
│       │   ├── login.feature
│       │   └── dashboard.feature
│       │
│       ├── 📁 car-invest/
│       │   ├── login.feature
│       │   └── dashboard.feature
│       │
│       └── 📁 auto-sync/
│           ├── login.feature
│           └── dashboard.feature
│
├── 📁 steps/                             ← Definições de Passos
│   │
│   ├── 📁 common/                        ← Steps reutilizáveis
│   │   ├── login.steps
│   │   └── navegacao.steps
│   │
│   ├── 📁 adm-new/
│   │   └── dashboard.steps
│   │
│   ├── 📁 adm-legado/
│   │   └── dashboard.steps
│   │
│   ├── 📁 b2b/
│   │   └── dashboard.steps
│   │
│   ├── 📁 car-invest/
│   │   └── dashboard.steps
│   │
│   └── 📁 auto-sync/
│       └── dashboard.steps
│
├── 📁 pages/                             ← Page Objects (padrão POM)
│   ├── 📁 common/
│   │   ├── BasePage
│   │   ├── LoginPage
│   │   └── HeaderComponent
│   │
│   ├── 📁 adm-new/
│   │   └── DashboardPage
│   │
│   ├── 📁 adm-legado/
│   │   └── DashboardPage
│   │
│   ├── 📁 b2b/
│   │   └── DashboardPage
│   │
│   ├── 📁 car-invest/
│   │   └── DashboardPage
│   │
│   └── 📁 auto-sync/
│       └── DashboardPage
│
├── 📁 support/                           ← Configuração e Hooks
│   ├── world                             ← Contexto global
│   ├── hooks                             ← Before/After hooks
│   └── reporter                          ← Configuração de relatórios
│
├── 📁 fixtures/                          ← Dados de teste
│   ├── usuarios.json
│   └── produtos.json
│
├── 📁 config/                            ← Configurações por ambiente
│   ├── dev.config
│   ├── hml.config
│   └── prod.config
│
└── README.md

EXEMPLO DE EXECUÇÃO


// Step Definition - login.steps

import { Given, When, Then } from '@cucumber/cucumber';
import { LoginPage } from '../pages/common/LoginPage';
import { DashboardPage } from '../pages/common/DashboardPage';

let loginPage: LoginPage;
let dashboardPage: DashboardPage;

Given('que estou na página de login', async function() {
    loginPage = new LoginPage(this.page);
    await loginPage.navegar();
});

When('eu informo o email {string}', async function(email: string) {
    await loginPage.preencherEmail(email);
});

When('eu informo a senha {string}', async function(senha: string) {
    await loginPage.preencherSenha(senha);
});

When('eu clico no botão {string}', async function(botao: string) {
    await loginPage.clicarBotao(botao);
});

Then('devo ser redirecionado para o dashboard', async function() {
    dashboardPage = new DashboardPage(this.page);
    await dashboardPage.aguardarCarregamento();
    expect(await dashboardPage.estaVisivel()).toBe(true);
});

REFERÊNCIAS

ISTQB Foundation Level • ISTQB CTAL-TA (Test Automation Engineer) • ISTQB CTAL-TTA (Technical Test Analyst)

⚡ Framework Híbrido: BDD + POM

LEGENDA DE CORES

Verde - Features (Gherkin)

Azul - Steps (Definições)

Roxo - Page Objects

Laranja - Sistema (SUT)

Amarelo - Configuração

FLUXO DE EXECUÇÃO

Features

Cenários em Gherkin
Linguagem de Negócio

→

Steps

Definições de Passos
Implementação

→

Page Objects

Abstração de UI
Elementos e Ações

→

SUT

Sistema em Teste
Auto Avaliar

Features

Cenários escritos em Gherkin

Linguagem natural
PO/QA/DEV colaboram
Documentação viva

Steps

Conecta Gherkin ao código

Given/When/Then
Reutilização entre features
Orquestração de ações

Page Objects

Abstração da interface

Locators encapsulados
Métodos de ação
Reutilização máxima

Sistema

Aplicação sendo testada

Auto Avaliar
DEV / HML / PROD
Todos os projetos

HIERARQUIA DE PROJETO

AUTO AVALIAR

Produto Principal

Framework Híbrido

FUTURO

🇦🇷 Argentina

Expansão

FUTURO

🇲🇽 México

Expansão

PILOTO

🇧🇷 Brasil

Implementação Inicial

FUTURO

🇵🇹 Portugal

Expansão

FUTURO

🇪🇸 Espanha

Expansão

ADM-New

ADM-Legado

B2B

Car Invest

Auto Sync

Features

dashboard.feature

Steps

dashboard.steps

Pages

LoginPage

DashboardPage

ESTRUTURA DE PASTAS

📁 autoavaliar-automation/
│
├── 📁 features/                          ← Cenários em BDD
│   │
│   └── 📁 brasil/                        ← PILOTO
│       │
│       ├── 📁 adm-new/
│       │   ├── login.feature
│       │   └── dashboard.feature
│       │
│       ├── 📁 adm-legado/
│       │   ├── login.feature
│       │   └── dashboard.feature
│       │
│       ├── 📁 b2b/
│       │   ├── login.feature
│       │   └── dashboard.feature
│       │
│       ├── 📁 car-invest/
│       │   ├── login.feature
│       │   └── dashboard.feature
│       │
│       └── 📁 auto-sync/
│           ├── login.feature
│           └── dashboard.feature
│
├── 📁 steps/                             ← Definições de Passos
│   │
│   ├── 📁 common/                        ← Steps reutilizáveis
│   │   ├── login.steps
│   │   └── navegacao.steps
│   │
│   ├── 📁 adm-new/
│   │   └── dashboard.steps
│   │
│   ├── 📁 adm-legado/
│   │   └── dashboard.steps
│   │
│   ├── 📁 b2b/
│   │   └── dashboard.steps
│   │
│   ├── 📁 car-invest/
│   │   └── dashboard.steps
│   │
│   └── 📁 auto-sync/
│       └── dashboard.steps
│
├── 📁 pages/                             ← Page Objects
│   │
│   ├── 📁 common/
│   │   ├── BasePage                      ← Classe abstrata base
│   │   ├── LoginPage
│   │   └── HeaderComponent
│   │
│   ├── 📁 adm-new/
│   │   └── DashboardPage
│   │
│   ├── 📁 adm-legado/
│   │   └── DashboardPage
│   │
│   ├── 📁 b2b/
│   │   └── DashboardPage
│   │
│   ├── 📁 car-invest/
│   │   └── DashboardPage
│   │
│   └── 📁 auto-sync/
│       └── DashboardPage
│
├── 📁 support/                           ← Configurações e Hooks
│   ├── world                             ← Contexto global
│   ├── hooks                             ← Before/After
│   └── reporter                          ← Relatórios
│
├── 📁 fixtures/                          ← Dados de teste (massa)
│   ├── usuarios.json
│   └── produtos.json
│
├── 📁 config/                            ← Configurações por ambiente
│   ├── dev.config
│   ├── hml.config
│   └── prod.config
│
└── README.md

EXEMPLO DE EXECUÇÃO


Fluxo completo: Feature → Step → Page Object → Sistema


1. FEATURE (login.feature)
Cenário: Login com sucesso
Dado que estou na página de login
Quando eu informo credenciais válidas
Então devo acessar o dashboard


2. STEP DEFINITION (login.steps)
Given('que estou na página de login', async function() {
    await loginPage.navegar();
});

When('eu informo credenciais válidas', async function() {
    await loginPage.realizarLogin(usuario, senha);
});

Then('devo acessar o dashboard', async function() {
    expect(await dashboardPage.estaVisivel()).toBe(true);
});


3. PAGE OBJECT (LoginPage)
class LoginPage extends BasePage {
    async realizarLogin(email, senha) {
        await this.preencher(this.inputEmail, email);
        await this.preencher(this.inputSenha, senha);
        await this.clicar(this.btnEntrar);
    }
}

REFERÊNCIAS

ISTQB Foundation Level • ISTQB CTAL-TA (Test Automation Engineer) • ISTQB CTAL-TTA (Technical Test Analyst)

⚖️ Comparativo das Arquiteturas

LEGENDA DE CORES

Roxo - POM

Azul - BDD

Amarelo - Híbrido

VISÃO GERAL

Page Object Model

✔ Código limpo e organizado
✔ Ideal para times técnicos
✔ Menor overhead de arquivos
✔ Debug mais direto
✔ Curva de aprendizado menor
✗ PO não consegue ler testes
✗ Documentação separada

BDD

✔ Documentação viva em BDD
✔ PO/QA/DEV colaboram
✔ Testes legíveis por não-técnicos
✔ Ótimo para testes de aceitação
✗ Mais arquivos para manter
✗ Steps podem virar "spaghetti"

Híbrido (BDD + POM)

✔ Melhor dos dois mundos
✔ Documentação + Organização
✔ Escalável para grandes projetos
✔ Reutilização máxima de código
✔ Colaboração entre áreas
✗ Complexidade inicial maior
✗ Requer mais treinamento

QUANDO USAR

POM

Time 100% técnico
Projetos menores
Prototipagem rápida
Foco em velocidade
Sem documentação de negócio

BDD

Colaboração com PO/negócio
Documentação é prioridade
Testes de aceitação
Cenários data-driven
Auditorias e compliance

Híbrido

Projetos corporativos
Times mistos
Escalabilidade necessária
Múltiplos produtos/países
Auto Avaliar ✓

FLUXO DE EXECUÇÃO COMPARATIVO

POM

Test Spec

→

Page Object

→

Sistema

BDD

Feature

→

Steps

→

Sistema

Híbrido (Recomendado)

Feature

→

Steps

→

Page Object

→

Sistema

REFERÊNCIAS

ISTQB Foundation Level • ISTQB CTAL-TA (Test Automation Engineer) • ISTQB CTAL-TTA (Technical Test Analyst)

🍊 Orange Testing - Arquitetura Proposta

LEGENDA DE CORES

Verde - Features/Cenários

Azul - Steps/Ações

Roxo - Predefinições (Page Objects)

Laranja - Sistema (SUT)

CATEGORIZAÇÃO DE TESTES (ISTQB)

🔥 Smoke Tests

Objetivo: Validar inconsistências em PRODUÇÃO após deploy

Quando: Após cada deploy em produção
Cobertura: 5-10% dos casos (críticos)
Tempo: < 10 minutos
Escopo: Fluxos críticos do negócio

Exemplos: Login, Dashboard principal, Transações críticas

🔄 Regression

Objetivo: Garantir que nada quebrou no sistema

Quando: Diariamente (execução automática)
Cobertura: 60-70% dos casos
Tempo: 4-8 horas
Escopo: Todos os fluxos principais

Exemplos: Todos os módulos, CRUDs, Validações, Integrações

🔗 Integration

Objetivo: Testar integrações entre módulos e APIs

Quando: Por demanda ou pré-deploy
Cobertura: 20-30% dos casos
Tempo: 2-4 horas
Escopo: Comunicação entre sistemas

Exemplos: APIs, Sincronizações, Webhooks, Microserviços

HIERARQUIA DE PROJETO NO ORANGE TESTING

🍊 AUTO AVALIAR

Produto Principal

🇦🇷 Argentina

País / Região

PILOTO

🇧🇷 Brasil

País / Região

🇲🇽 México

País / Região

📦 B2B

Módulo

📊 USBI

Módulo

🏢 ADM-New

Módulo

🏛️ ADM-Legado

Módulo

📄 Predefinição Login

Page Object

📄 Predefinição Dashboard

Page Object

📄 Predefinição Common

Componentes Compartilhados

✅ Casos de Teste

Cenários executáveis

FLUXO DE EXECUÇÃO NO ORANGE TESTING

Caso de Teste

Orange Testing
Cenário BDD

→

Predefinição

Page Object
Ações encapsuladas

→

Sistema

Auto Avaliar
Aplicação real

Caso de Teste

Criado no Orange Testing com nomenclatura BDD

[Tipo] - [Módulo] - [Cenário] (ID)
Smoke/Regression/Integration
Passo-a-passo sequencial

Predefinição

Page Objects reutilizáveis

[Módulo] - [Página] - [Ação]
Biblioteca de componentes
Ações encapsuladas

Sistema (SUT)

Aplicação sendo testada

Auto Avaliar (todos os módulos)
Ambientes (DEV/HML/PROD)
Execução via bot

NOMENCLATURA PADRÃO

✔ Casos de Teste

✔ Sempre incluir: [ID] - [Tipo] - [Módulo] - [Descrição]
✔ ID único por módulo: [ADM-001], [USBI-001], [B2B-001]
✔ [ADM-001] - [Smoke] - [B2B] - [Login com credenciais válidas] (ADM-001)
✔ [USBI-001] - [Regression] - [USBI] - [Visualizar dashboard principal]
✔ [ADM-001] - [Integration] - [ADM] - [Sincronizar dados com API X - Y]

✔ Predefinições (Page Objects)

✔ Sempre incluir: [Módulo] - [Página] - [Ação]
✔ Common para componentes compartilhados
✔ [ADM] - [Login] - [Preencher Credenciais]
✔ [USBI] - [Dashboard] - [Validar Cards]
✔ [Common] - [Header] - [Realizar Logout]

EXEMPLO PRÁTICO - PADRÃO AAA (ARRANGE / ACT / ASSERT)

📋 Informações do Caso de Teste

Nome: Regression - B2B - Login com sucesso

Identificador: B2B-001

Módulo: Brasil > B2B

Padrão de Qualidade: 🔄 Regression Test

Objetivo: Validar login em Homologação com sucesso

📚 Predefinições (Page Objects)

🌐 B2B - Login - Navegar

Abre o navegador e acessa URL do B2B

▶️ B2B - Login - Preencher Credenciais

Preenche email e senha nos campos de login

🎯 B2B - Dashboard - Validar Acesso

Verifica se o resultado esperado foi carregado com sucesso

🧪 ESTRUTURA DO CASO DE TESTE (AAA Pattern)

ARRANGE (PREPARAR)
Preparar o ambiente e os dados necessários para o teste

📝 PASSO 1: ARRANGE (Preparar)

1.1 - Predefinição: ADM - Login - Navegar
→ Abre o navegador
→ Acessa: https://exemplo@exemplo.com/
→ Aguarda página carregar completamente

1.2 - Massa de Dados:
→ Email: "user@user.com.br"
→ Senha: "user@123"
→ Ambiente: Homologação (Brasil)

ACT (EXECUTAR)
Executar a ação que está sendo testada

⚡ PASSO 2: ACT (Executar)

2.1 - Predefinição: B2B - Login - Preencher Credenciais
→ Localiza campo "Email"
→ Preenche: "user@user.com.br"
→ Localiza campo "Senha"
→ Preenche: "user@123"
→ Localiza botão "Entrar"
→ Clica no "Botão"
→ Aguarda redirecionamento

ASSERT (Verificar)
Verifica o resultado esperado

✅ PASSO 3: ASSERT (Verificar)

3.1 - Validações: B2B - Dashboard - Validar Acesso
→ Verifica se URL contém: "/dashboard"
→ Verifica se elemento "Menu Lateral" está visível
→ Verifica se texto contém: "Bom dia User,"

3.2 - Validações Adicionais:
→ Status HTTP = 200 OK
→ Token de autenticação foi gerado
→ Menu lateral carregou 5 itens

✅ RESULTADO ESPERADO:
Login realizado com sucesso, usuário redirecionado para dashboard e todas as validações passaram.

GUIDELINES E BOAS PRÁTICAS

✔ FAZER

✔ Criar UMA predefinição por página/componente
✔ Reutilizar predefinições entre casos de teste
✔ Usar nomenclatura BDD nos passos (Dado/Quando/Então)
✔ Manter predefinições Common para componentes compartilhados
✔ Incluir ID único em cada caso de teste
✔ Documentar massa de dados necessária
✔ Organizar por: Produto → País → Módulo → Casos

✗ NÃO FAZER

✗ Duplicar predefinições com nomes diferentes
✗ Criar casos de teste sem padrão de qualidade
✗ Misturar lógica de negócio nas predefinições
✗ Usar nomes genéricos (Teste1, Teste2)
✗ Criar testes sem reutilizar predefinições
✗ Ignorar a hierarquia Produto/País/Módulo
✗ Colocar validações fixas nas predefinições

BIBLIOTECA DE PREDEFINIÇÕES (PAGE OBJECTS)

📁 Orange Testing - Auto Avaliar/
│
├── 📁 Brasil/
│   │
│   ├── 📁 B2B/
│   │   ├── 📁 ADM-New/
│   │   │   ├── 🔐 ADM - Login - Navegar
│   │   │   ├── 🔐 ADM - Login - Preencher Credenciais
│   │   │   ├── 🏠 ADM - Dashboard - Validar Menu
│   │   │   ├── 👤 ADM - Usuários - Criar Usuário
│   │   │   └── 👤 ADM - Usuários - Validar Cadastro
│   │   │
│   │   └── 📁 ADM-Legado/
│   │       ├── 🔐 ADM-Legado - Login - Preencher
│   │       └── 🏠 ADM-Legado - Home - Validar
│   │
│   └── 📁 USBI/
│       ├── 🔐 USBI - Login - Autenticar
│       ├── 🏠 USBI - Home - Navegar
│       └── 📊 USBI - Avaliações - Filtrar
│
├── 📁 Argentina/
│   └── 📁 B2B/
│       └── ← Mesma estrutura do Brasil
│
└── 📁 Common/ (Compartilhado)
    ├── 🔧 Common - Header - Abrir Menu
    ├── 🔧 Common - Header - Logout
    ├── 🔧 Common - Modal - Confirmar
    ├── 🔧 Common - Modal - Cancelar
    ├── 🔧 Common - Toast - Validar Sucesso
    └── 🔧 Common - Toast - Validar Erro

PLANO DE IMPLEMENTAÇÃO

🎯 Fase 1: Criação da Base

1.1 Limpeza de base mantendo apenas o que está sendo executado atualmente
1.2 Criar hierarquia: Produto → Países → Módulos no Orange Testing
1.3 Criar predefinições de Login para cada módulo (B2B, USBI, ADM)
1.4 Criar predefinições Common (Header, Modal, Toast, Navegação)
1.5 Criar weebhooks para jira e teams para reports e criação de cards com criticidade (Definir)
1.6 Configurar padrões de qualidade (Smoke, Regression, Integration)

🔥 Fase 2: Smoke Tests

2.1 Criar 5-10 casos Smoke críticos por módulo
2.2 Validar execução em produção (< 10 min)
2.3 Configurar alertas para falhas em Smoke
2.4 Treinar time sobre estrutura Smoke

🔄 Fase 3: Regression

3.1 Criar casos Regression por módulo (Entender e difinir cenários)
3.2 Expandir biblioteca de predefinições conforme necessário
3.3 Configurar execução diária automática
3.4 Eliminar duplicidades e padronizar nomenclatura

🔗 Fase 4: Integration

4.1 Identificar integrações críticas (APIs, Webhooks)
4.2 Criar casos Integration para sincronizações
4.3 Validar comunicação entre módulos
4.4 Configurar execução sob demanda

✅ Fase 5: Governança

5.1 Revisar casos de teste mensalmente
5.2 Atualizar predefinições conforme mudanças no sistema
5.3 Monitorar métricas (cobertura, tempo de execução, falhas)
5.4 Evoluir arquitetura conforme necessidade do negócio

REFERÊNCIAS

ISTQB Foundation Level • ISTQB CTAL-TA (Test Automation Engineer) • ISTQB CTAL-TTA (Technical Test Analyst) • Orange Testing Platform

Melhor Experiência em Desktop

Pirâmide Tradicional

Camadas da Pirâmide de Testes

1. Base: Testes Unitários (Muitos e Rápidos)

2. Meio: Testes de Integração (Menos que Unitários)

3. Topo: Testes E2E (End-to-End) (Poucos e Lentos)

Pirâmide Moderna

Camadas da Pirâmide Moderna

1. Base: Unit Tests (~70%)

2. Meio: API / Serviços (~20%)

3. Topo: UI / E2E (~10%)

Pirâmide Front-end

Camadas da Pirâmide Front-end

1. Base: Unit (Componentes)

2. Meio: Integration (API mocks)

3. Topo: E2E (Fluxos críticos)

Testes Específicos para Front-end

Pirâmide Back-end / APIs

Camadas da Pirâmide Back-end

1. Base: Unit (Domínio / Regras)

2. Meio: Contrato / Integração

3. Topo: E2E multi-serviços

Diamante

Estrutura do Diamante

1. Topo: Unit (Moderados)

2. Centro: Integration (Maioria - Foco Principal)

3. Base: Unit (Moderados)

Quando Usar o Padrão Diamante

Pirâmide Invertida (Anti-padrão)

Por que é um Anti-padrão

❌ Problemas Principais

Como Corrigir

Relógio de Areia (Anti-padrão)

Por que é um Anti-padrão

❌ Problemas Principais

Como Corrigir

Cone de Sorvete (Anti-padrão)

Por que é um Anti-padrão

❌ Problemas Principais

Como Corrigir

🔺 Pirâmides de Teste

🔺 Pirâmide Tradicional

🔺 Pirâmide Moderna

🔺 Pirâmide Front-end

🔺 Pirâmide Back-end / APIs

💎 Diamante

⚠️ Pirâmide Invertida (Anti-padrão)

⚠️ Relógio de Areia

⚠️ Cone de Sorvete

✔ Fazer

✗ Evitar

📦 Page Object Model (POM)

✔ Princípios

✗ Anti-padrões

🥒 BDD - Behavior Driven Development

⚡ Framework Híbrido: BDD + POM

⚖️ Comparativo das Arquiteturas

Page Object Model

BDD

Híbrido (BDD + POM)

POM

BDD

Híbrido

POM

BDD

Híbrido (Recomendado)

🍊 Orange Testing - Arquitetura Proposta

🔥 Smoke Tests

🔄 Regression

🔗 Integration

✔ Casos de Teste

✔ Predefinições (Page Objects)

📋 Informações do Caso de Teste

📚 Predefinições (Page Objects)

✔ FAZER

✗ NÃO FAZER

🎯 Fase 1: Criação da Base

🔥 Fase 2: Smoke Tests

🔄 Fase 3: Regression

🔗 Fase 4: Integration