Forem: Talking About Testing

Triggering Cypress End-to-End Tests Manually on Different Browsers with GitHub Actions

Talking About Testing — Fri, 19 Dec 2025 19:29:32 +0000

A Practical Guide to Cross-Browser Testing

One of the most practical features of GitHub Actions is the ability to manually trigger workflows and pass parameters at runtime. This is especially useful for end-to-end (E2E) testing, where you may want to select which browser to run the tests against rather than hard-coding that choice.

In this post, I'll walk you through a GitHub Actions workflow written in YAML that allows you to manually trigger Cypress tests and select the target browser directly from the GitHub UI.

The Full Workflow

Here's the workflow I'll be explaining:

name: End-to-end tests 🧪
on:
  workflow_dispatch:
    inputs:
      browser:
        description: "Browser to run tests"
        type: choice
        required: true
        default: chrome
        options:
          - chrome
          - edge
          - electron
          - firefox
          - safari
jobs:
  cypress-run:
    runs-on: ubuntu-24.04
    steps:
      - name: Checkout
        uses: actions/checkout@v6

      - name: Install WebKit system deps (Safari)
        if: ${{ github.event.inputs.browser == 'safari' }}
        run: npx playwright install-deps webkit

      - name: Cypress run
        uses: cypress-io/github-action@v6
        with:
          command: npm run test:${{ github.event.inputs.browser }}

      - name: Upload screenshots (selected browser, on failure)
        if: failure()
        uses: actions/upload-artifact@v4
        with:
          name: screenshots-${{ github.event.inputs.browser }}
          path: cypress/screenshots
          if-no-files-found: ignore

Naming the Workflow

name: End-to-end tests 🧪

This is the friendly name shown in the GitHub Actions UI. Adding an emoji is optional, but it makes workflows easier to scan—especially when you have many of them.

Manual Trigger with `workflow_dispatch`

on:
  workflow_dispatch:

The workflow_dispatch event enables manual execution of the workflow. This means:

The workflow won't run automatically on push or pull_request
A "Run workflow" button will appear in the Actions tab

This is ideal for:

Ad-hoc test runs
Debugging browser-specific issues
Running tests before a release

Defining Input Parameters

inputs:
  browser:
    description: "Browser to run tests"
    type: choice
    required: true
    default: chrome
    options:
      - chrome
      - edge
      - electron
      - firefox
      - safari

This is the heart of the workflow.

What's happening here?

browser is a required input
The user must select one value from a predefined list
The default option is chrome

On GitHub, this renders as a dropdown selector in the UI.

This prevents invalid values and makes the workflow safer and more user-friendly.

Defining the Job

jobs:
  cypress-run:
    runs-on: ubuntu-24.04

The workflow has a single job called cypress-run
It runs on the ubuntu-24.04 GitHub-hosted runner

Ubuntu runners are commonly used for Cypress because they're fast, stable, and well supported by the Cypress GitHub Action.

Step 1: Checking Out the Code

- name: Checkout
  uses: actions/checkout@v6

This step pulls your repository code into the runner so that:

Cypress tests
package.json
Configuration files

are available during execution.

This step is required in almost every CI workflow.

Step 2: Installing Safari (WebKit) Dependencies Conditionally

- name: Install WebKit system deps (Safari)
  if: ${{ github.event.inputs.browser == 'safari' }}
  run: npx playwright install-deps webkit

This is an excellent example of conditional execution in GitHub Actions.

Why is this needed?

Cypress runs Safari tests via WebKit
WebKit requires additional system dependencies on Linux
These dependencies are unnecessary for other browsers

What the condition does

The if expression ensures that this step:

Runs only when safari is selected
Is skipped for all other browsers

This keeps the workflow:

Faster
Cleaner
Easier to maintain

Notes:

It's worth mentioning that for Cypress to work with WebKit:

The experimentalWebKitSupport property has to be set to true in the cypress.config.js file
playwright-webkit has to be installed as a dev dependency (e.g., npm i playwright-webkit -D)

Pro tip: Make sure to version not only the package.json file, but also the package-lock.json.

Step 3: Running Cypress with the Selected Browser

- name: Cypress run
  uses: cypress-io/github-action@v6
  with:
    command: npm run test:${{ github.event.inputs.browser }}

This step uses the official Cypress GitHub Action image.

Key idea

The browser input is injected dynamically into the command:

npm run test:chrome
npm run test:firefox
npm run test:safari

This implies that your package.json contains scripts like:

{
  "scripts": {
    "test:chrome": "cypress run --browser chrome",
    "test:firefox": "cypress run --browser firefox",
    "test:safari": "cypress run --browser webkit"
  }
}

This pattern keeps:

The workflow generic
Browser-specific logic inside your project configuration

Step 4: Uploading Screenshots on Failure

- name: Upload screenshots (selected browser, on failure)
  if: failure()
  uses: actions/upload-artifact@v4
  with:
    name: screenshots-${{ github.event.inputs.browser }}
    path: cypress/screenshots
    if-no-files-found: ignore

This step runs only if the job fails.

What it does

Uploads Cypress screenshots as workflow artifacts
Names the artifact based on the selected browser
Avoids failing the workflow if no screenshots exist

Why this matters

When an E2E test fails:

Screenshots provide visual context
Browser-specific issues are easier to diagnose
Artifacts are preserved for later analysis

Final Thoughts

This workflow demonstrates a clean and scalable way to:

Manually trigger Cypress tests
Select the target browser at runtime
Handle browser-specific dependencies
Collect meaningful artifacts on failure

It's a powerful pattern for teams that care about cross-browser confidence without overloading their CI pipelines with unnecessary runs.

More than just automation, this approach puts control and observability back in the team's hands—exactly where quality belongs.

For the complete implementation, take a look at the cross-browser-testing-gha GitHub repository.

Would you like to learn E2E Testing with Cypress from scratch until your tests are running on GitHub Actions and integrated with the Cypress Cloud?

Consider subscribing to my course: "Cypress, from Zero to the Cloud."

Software Engineering Principles and Ethics

Talking About Testing — Tue, 09 Dec 2025 22:31:44 +0000

What are the principles that any professional software engineer should comply with?

That’s the question I will try to answer in this blog post.

But first, let me tell you a story.

Once upon a time, there was a small team working on a critical application. The deadline was tight, and management was pushing for a release “as soon as possible.” One of the engineers hesitated: some of the automated tests were failing — minor edge cases, nothing too urgent, they argued. “We’ll fix them later,” they said. The pressure to deliver trumped the red test suite. The code was shipped. In production, the very edge cases that those failing tests covered caused a subtle bug that corrupted user data. It took weeks to identify and resolve the issue, which cost the company significant reputational damage and eroded user trust. Ultimately, the “minor” failing tests cost far more than the extra time needed to get them green.

That engineer’s hesitation — and ultimately the team’s decision to ship with failing tests — was not just a matter of expediency. It was a failure of professional ethics.

Why accepting red or failing tests is unethical

A professional software engineer does more than “just write code.” According to Robert C. Martin (often referred to as “Uncle Bob”), programming is an act of responsibility, and professionals must take full ownership of the consequences of their work. In The Clean Coder, he makes it clear that professionalism is not about compliance, but about ethics: doing the right thing even when it is uncomfortable.

Accepting a failing test — even “just for now” — violates that responsibility. It knowingly delivers sub-par or unsafe software, relying on the hope that the missing fix will come “later.” That violates the very core of professionalism, because:

It destroys the guarantee that the code works as expected. Martin strongly argues that professionals must be confident about all the code they release, and that tests are the foundation of that confidence.
It erodes trust — among team members, between engineers and stakeholders, and between software and its users. By shipping with red tests, you implicitly communicate that quality is negotiable. That is not what a professional does.
It encourages a dangerous culture of “debt by default,” where shortcuts become acceptable and technical debt silently becomes the norm.

When you accept failing tests, you are not just betting on luck — you are betraying the craft.

What other thought leaders say about responsibility

This ethical stance is not unique to one author.

Kent Beck, the creator of Extreme Programming, placed “Respect” at the core of XP. Respect for your teammates means never checking in code that breaks the build or leaves tests failing. If your changes cause others pain, you are not acting professionally.

Martin Fowler has consistently argued that working software is not enough if the internal quality of the system is decaying. He emphasizes that design and refactoring are continuous responsibilities — not something to postpone indefinitely in favor of “temporary” defects.

John Ousterhout, in A Philosophy of Software Design, strongly warns against “tactical programming,” where engineers optimize for speed today and leave complexity and fragility behind for tomorrow. He argues that real engineering is strategic: reducing complexity over time and refusing to accept unstable or fragile systems.

These authors approach the topic from different angles, but they converge on the same principle: professionals think long-term rather than short-term.

A non-negotiable rule for professionals: never accept red tests

Based on both ethics and practice, there is a rule that should be treated as non-negotiable:

A professional software engineer must never accept or ship code with failing (red) tests — under any circumstances.

Red tests are a signal of broken promises. They tell you the system is not behaving as expected. To ignore that signal is to normalize dishonesty in your own work.

Robert C. Martin describes professionalism as the courage to say “no” — even to managers — when quality is at risk. Refusing to ship with broken tests is not stubbornness; it is ethical courage.

Ethics in software engineering is real

Software increasingly controls critical aspects of our lives: money, health, safety, communication, transportation, and many other domains. The idea that it is “okay for now” to ship broken software is not just naive — it is dangerous.

Accepting failing tests teaches teams to accept uncertainty as normal. It teaches them to postpone discipline. It teaches them to gamble with other people’s safety.

That is not engineering.
That is not craftsmanship.
That is not professionalism.

Professionalism is a daily choice

Professional software engineering is not about being brilliant. It is about being disciplined.

It is about refusing to lower the bar, even when deadlines are tight.
It is about refusing to normalize brokenness.
It is about choosing integrity over convenience.

If you want to call yourself a professional, then this is the standard:

Never accept red tests.

Never ship with red tests.

Never normalize brokenness.

Demand green tests. Ship only with green tests. Do it always.

Uma hipótese para os layoffs do Itaú

Talking About Testing — Sun, 05 Oct 2025 15:04:29 +0000

Isenção de responsabilidade

As ideias expressas neste texto são apenas hipóteses, discutidas com o intuito de analisar um acontecimento por outro ponto de vista, não discutido em outras publicações sobre o mesmo acontecimento.

Setembro de 2025

Nos últimos dias, tenho visto uma enxurrada de publicações no LinkedIn sobre os recentes layoffs do Itaú, estimados em aproximadamente mil pessoas afetadas.

Os motivos sugerem falta de produtividade de profissionais trabalhando na modalidade remota, na qual, como uma das medidas, usava-se monitoramento de atividades nos computadores da empresa.

No entanto, outro possível motivo seria o seguinte.

O Itaú é uma empresa listada na bolsa de valores (BOVESPA).

Ações de empresas listadas em bolsa valorizam (ou desvalorizam), dentre outras coisas, devido ao seu resultado financeiro.

O Itaú já entrega ótimos resultados financeiros aos seus acionistas. Ainda assim, pessoas ainda são um dos maiores custos da maioria dos negócios, e uma forma de melhorar o resultado financeiro de uma empresa (seja ela listada ou não) é o corte de custos.

Façamos uma "conta de padeiro" pra você ter idéia de quanto dinheiro pode-se tratar.

Os valores usados abaixo são totalmente hipotéticos.

Imagine um funcionário que ganha em média R$5.000,00 (cinco mil reais) brutos mensais.

E digamos que para a empresa, o funcionário custa o dobro, ou seja, R$10.000 (dez mil reais) mensais.

Ou seja, em 13 meses (12 meses trabalhados + o décimo terceiro), tal funcionário custaria aproximadamente R$130.000 (cento e trinta mil reais).

E visto que a estimativa é de mil pessoas afetadas, o banco teria uma redução de custos de aproximadamente 130.000.000 (cento e trinta milhões de reais).

Não sei pra você, mas pra mim, isso é muito dinheiro.

Um parêntesis.

(E se algumas das pessoas afetadas pelos layoffs realmente não entregavam a produtividade esperada?

Neste caso, a empresa ganha duas vezes. Uma, pois "elimina" pessoas não produtivas, as quais podem ser futuramente substituídas, ou por pessoas mais produtivas, ou até mesmo por agentes de IA e outras tecnologias. E dois, pois não tem mais este custo afetando seu resultado financeiro, podendo elevar ainda mais o preço de suas ações.)

Fecha parêntesis.

Não quero entrar no mérito de se o que ocorreu é certo ou errado. Até mesmo, pois acredito que não temos que romantizar relações de trabalho. Sua empresa não é sua mãe, nem seu pai, portanto, temos que estar preparados para que tal relação acabe (seja por decisão da empresa, como por sua escolha própria).

Como escrevi no título, esta é só uma hipótese. E escrevi esta hipótese para instigar o pensamento sob outra perspectiva, mesmo que a hipótese esteja errada.

Eu imagino que algumas pessoas perderam seus empregos, quem sabe, de forma injusta. Mas é do jogo.

Minha dica é: bola pra frente! E prepare-se para o pior, pois essa é a melhor forma de uma situação como essa não te afetar tanto no futuro.

Obrigado por ler até aqui.

E aí, gostou? Continue essa conversa deixando um comentário.

E por favor, seja educado(a), seja lá se você concorda ou não com o que escrevi, pois a intenção é simplesmente levantar uma possibilidade, não ser uma verdade absoluta.

E aos/às afetados/as pelo layoff, boa sorte no que vem por aí. E lembre-se, "a males que vem para o bem".

Simulando navegação por teclado com as novas teclas do comando cy.press na versão 15.1.0 do Cypress

Talking About Testing — Thu, 04 Sep 2025 00:34:30 +0000

`TAB`, `SPACE` e muito mais agora fazem parte da sua estratégia de testes automatizados

A versão 15.1.0, o Cypress introduziu uma melhoria importante para quem testa acessibilidade e navegação por teclado: o comando cy.press agora suporta novas teclas, como ENTER, SPACE e outras, além da tecla TAB (disponível desde a versão 14.3.0). Essa mudança, destacada no changelog oficial, amplia o leque de cenários que conseguimos cobrir com testes end-to-end.

Se antes precisávamos de workarounds para simular o pressionamento de teclas específicas, ou mesmo de testes manuais, agora podemos testar fluxos completos de interação apenas com o teclado, garantindo que pessoas que dependem dessa forma de navegação também tenham uma boa experiência. E tudo isso de forma automatizada!

Vejamos um exemplo.

O cenário de teste

No exemplo abaixo, criamos um teste que valida a navegação por um messenger de uma aplicação fictícia, utilizando apenas TAB para avançar entre os campos e SPACE para acionar os botões:

Para digitar nos campos, utilizamos a conhecido comando cy.type(), existente desde as primeiras versões do Cypress.

// cypress/e2e/spec.cy.js

describe('TAB navigation', () => {
  beforeEach(() => {
    // Set a cookie before visiting the page to prevent it from showing up
    cy.setCookie('cookieConsent', 'accepted')
    // Visit the app
    cy.visit('/')
    cy.get('table').should('be.visible')
    // Press TAB 20 times to reach the open messenger button
    Cypress._.times(20, () => {
      cy.pressTAB()
    })
    // Make sure the open messenger button is focused
    cy.get('[aria-label="Open messenger"]')
      .should('be.focused')
    // Open the messager by pressing SPACE on the focused button
    cy.pressSPACE()
  })

  it('navigates through the messenger using the TAB key', () => {
    // Ensure the messenger opens with its first field pre-focused (i.e., the name field), and types the required info in it
    cy.get('#messenger-name')
      .should('be.focused')
      .type('John Doe')
    // Press TAB to move to the email field
    cy.pressTAB()
    // Make sure the email field is focused and type a valid email in it
    cy.get('#email')
      .should('be.focused')
      .type('johndoe@example.com')
    // Press TAB to move to the message textarea
    cy.pressTAB()
    // Make sure the textarea field is focused and type a message in it
    cy.get('#message')
      .should('be.focused')
      .type('The client with ID 5 has no contact info available.')
    // Press TAB to move to the send button
    cy.pressTAB()
    // Make sure the button is focused
    cy.contains('button', 'Send')
      .should('be.focused')
    // Press SPACE to submit the form
    cy.pressSPACE()
    // Ensure the success message is displayed (which could be read by a screen reader)
    cy.contains('Your message has been sent.').should('be.visible')
    // Press TAB to move to the close messenger button
    cy.pressTAB()
    // Ensure the closed button is focused
    cy.get('button[aria-label="Close messenger"]')
      .should('be.focused')
    // Press SPACE to close the messenger
    cy.pressSPACE()
    // Ensure the messenger was closed by checking that the open messenger button is now visible
    cy.get('button[aria-label="Open messenger"]').should('be.visible')
  })
})

Os comandos customizados

Para simplificar a leitura do teste, criamos dois comandos customizados no arquivo cypress/support/commands.js:

Cypress.Commands.add('pressTAB', () => {
  cy.press(Cypress.Keyboard.Keys.TAB)
})

Cypress.Commands.add('pressSPACE', () => {
  cy.press(Cypress.Keyboard.Keys.SPACE)
})

Esses comandos são carregados automaticamente pelo arquivo cypress/support/e2e.js:

import './commands'

O que mudou no `cy.press`?

Antes (entre as versões 14.3.0 e 15.0.0), o suporte era limitado somente a tecla TAB. Agora, podemos acessar atalhos e teclas especiais como ENTER, BACKSPACE, SPACE, entre outras.

Isso abre espaço para testes de:

Acessibilidade: garantir que os elementos da página são alcançáveis por TAB e ativáveis por SPACE ou ENTER.
Fluxos reais de formulários: preencher campos apenas com navegação por teclado.
Interações avançadas: menus suspensos, modais e tooltips acionados por teclas específicas.

Conclusão

Com o suporte expandido do comando cy.press, fica mais simples criar testes que refletem o uso real da aplicação por usuários que dependem de navegação por teclado.

Essa evolução do Cypress não só melhora a cobertura de testes, mas também reforça o compromisso com experiências inclusivas e acessíveis.

👉 Confira a documentação oficial do comando cy.press e explore suas possibilidades para seus próximos testes.

Quer aprender mais sobre testes de acessibilidade com Cypress? Conheça o curso Cypress Simulator da Escola Talking About Testing.

Cypress v15: A Better User Experience

Talking About Testing — Tue, 19 Aug 2025 23:45:47 +0000

Streamlined Features and Improvements for Modern Testing

Cypress v15 is just around the corner, and one of the exciting changes is an improved user experience in the command logs of the test runner. If you’ve spent time debugging tests in v14, you’ll immediately notice how v15 makes test execution logs easier to scan, parse, and act upon.

In this post, we’ll walk through the key UX improvements.

At the end of this post, screenshots will illustrate the differences between v14 and v15.

Hierarchical Grouping

In v15, the test log is segmented into clear sections with borders to distinguish between: SESSIONS, BEFORE EACH, and TEST BODY.
In v14, although SESSIONS, BEFORE EACH, and TEST BODY also appear, there's no border to differentiate and isolate them better.

Cleaner Visual Density

The v15 layout introduces tighter grouping and spacing, so related blocks are easier to scan. The result is less eye travel compared to v14’s list.

Final Thoughts

Cypress v15 isn’t just a version bump—it’s a thoughtful step forward in how developers and testers interact with their test runner. By rethinking the command log experience with hierarchical grouping and cleaner visual density, Cypress reduces cognitive load and makes debugging more intuitive.

If you’ve ever found yourself lost in the flat logs of v14, v15 will feel like a breath of fresh air. These changes may seem subtle, but they directly improve day-to-day productivity and test clarity. And when it comes to testing, minor UX improvements often translate into big wins for speed, focus, and confidence.

As Cypress continues to evolve, v15 is a reminder that great tooling isn’t just about raw features—it’s about delivering a user experience that helps teams ship quality software faster.

Illustrations comparing Cypress versions 14 and 15

v14 session collapsed

v15 session collapsed

v14 session expanded

v15 session expanded

Would you like to learn more about web testing with Cypress?
Check out the "Cypress, from Zero to the Cloud" course from the Talking About Testing online school, and happy testing!

Uma alternativa de processo seletivo para contratar melhores QAs

Talking About Testing — Fri, 21 Mar 2025 01:35:54 +0000

A indústria de qualidade de software está estagnada. Precisamos mudar isso!

Aqui vai um exercício de pensamento.

Imagine um mundo onde:

Em vez de você filtrar candidatos(as) por terem (ou não) a certificação CTFL, você os/as filtra por terem (ou não) projetos públicos no GitHub (ou GitLab, etc), os quais podem ser usados para demonstrar suas habilidades.

Ao usar uma certificação como filtro para eliminar candidatos(as) da participação no processo seletivo, você elimina a chance de empresas conhecerem possíveis excelentes profissionais.

Imagine uma QA que estudou a literatura recomendada para tal certificação, fez cursos a respeito do assunto, e na hora da prova, não passou. Digamos que a nota mínima para passar era 7.5 e a QA atingiu 7.4.

Agora, imagine um QA que estudou a mesma literatura, fez os mesmos cursos e passou na prova com a nota 7.6.

Você segue o processo seletivo com o QA que tirou 7.6 e elimina a QA que atingiu 7.4.

No entanto, na próxima fase do processo seletivo, você tem um exercício de codificação para analisar se tal QA sabe automatizar testes.

Tal QA não possui experiência prévia em codificação, pede ajuda pro ChatGPT, entrega algo que ele nem mesmo entende e submete seu exercício para análise.

Agora, alguém da empresa contratante tem que revisar tal código, que nem mesmo foi criado pela pessoa aplicando para a vaga, mas por uma IA Generativa. Neste caso, não seria melhor contratar o ChatGPT em vez desse QA? :D

Agora, imagine que você soubesse o seguinte sobre a QA que atingiu 7.4 na prova do CTFL, a qual não conseguiu a certificação.

Ela possuía vasta experiência prática em garantir a qualidade de diferentes softwares por meio de scripts de testes automatizados de alto-nível.

Quando digo alto-nível, me refiro a testes automatizados que, além de testarem as partes mais importantes do sistema, também:

Usam as melhores práticas do mercado
Seguem as convenções definidas pela comunidade
São fáceis de manter, entender e extender
São rápidos, robustos e confiáveis

Agora, imagine que seu filtro fosse diferente.

De agora em diante, seu filtro é: projetos públicos no GitHub (ou qualquer outro lugar onde seja possível compartilhar código publicamente).

Voltamos aos mesmos QAs.

O QA que tirou 7.6 na prova da CTFL nem mesmo tem um perfil no GitHub, no entanto, como "campo" perfil no GitHub é um pré-requisito para aplicação para a vaga, o QA cria uma conta na hora e coloca lá o link.

Ao abrir o link de perfil de tal QA, você não só consegue ver que ele acabou de criar a conta, como não possui nenhum projeto para demonstrar seu conhecimento de forma prática.

No entanto, a QA tem conta no GitHub desde 2012, tem diversos repositórios públicos, tem uma evolução de commits de ano em ano, e mais importante, tem um histórico de sua evolução, assim como diversos projetos que possam ser avaliados de antemão pelo possível contratante.

A partir daí, o processo poderia ser algo como o seguinte.

O QA, foi eliminado.

Já a QA, passou para a próxima fase.

Agora, uma pessoa sênior da empresa contratante seleciona 3 projetos públicos aleatórios na conta do GitHub dessa QA, de preferência de momentos distintos de sua carreira (para avaliar sua evolução) e analisa:

Como ela codifica
Quão abrangentes e efetivas são suas suítes testes
Suas habilidades de escrita de documentações
Etc.

Passando nesse filtro, ou seja, seguindo os padrões técnicos mínimos exigidos para a vaga, ela passa para a próxima fase, com uma entrevista comportamental/de fit cultural, e por fim, uma entrevista com alguém da gestão, para alinhamento de expectativas.

Pergunte-se agora.

"Qual dessas abordagens parece mais efetiva para seguir adiante (ou eliminar) o/a candidato(a)?"

Pense antes de responder!

Venho dizendo isso faz algum tempo, mas vou repetir.

A indústria de qualidade software está estagnada. Precisamos mudar isso!

E pra mudar isso, é preciso re-pensar processos que atrasam nossa indústria.

Você já parou para pensar em quanto dinheiro empresas que emitem certificações (e empresa que treinam pessoas para passarem em tais certificações) ganham?

Agora, imagine uma pessoa que estudou para a certificação, passaria com 10, mas decidiu não gastar o dinheiro com tal certificação.

O conhecimento que ela adquiriu você não tira dela, independente se ela tem (ou não) a certificação.

Ou seja, a certificação não prova nada.

No entanto, a experiência prática, seja através cursos práticos, contribuições com projetos open-source, hackathons, bootcamps, etc, isso pode ser avaliado (tanto tecnicamente, como subjetivamente).

Nos dias de hoje, automação de testes é o mínimo esperado de profissionais de QA.

Fazer trabalho que pode ser automatizado de forma manual é simplesmente um desperdício.

No entanto, não adianta fazer testes de qualquer jeito.

Não adianta escrever scripts de testes que passam na primeira vez, mas com o passar do tempo, se mostram frágeis e não-confiáveis.

Não adianta escrever testes que quando falham, não tem nada errado com a aplicação sendo testada.

Além disso, não adiante escrever os testes errados, ou seja, testes que apesar de existirem, deixam bugs importantes passarem.

A tecnologia está toda à nossa disposição.

Lembre-se! Escrever scritps de testes é codificar, e se exigimos que times de desenvolvimento escrevam códigos de alta qualidade, por qual motivo não exigimos o mesmo de times de QA?

Contratamos QAs para encontrarem bugs nas aplicações sendo construídas, mas quem encontra os "bugs" nos scripts de testes escritos por esses/essas QAs?

Tá na hora de subir a régua!

Esse papo de "basta conhecer o básico de programação para começar a automatizar" não pode mais ser aceito.

É simplesmente contraditório contratar pessoas para garantirem a qualidade dos softwares sendo construídos se elas nem mesmo sabem o básico de como softwares são construídos.

E se você não concorda com o que está lendo, fico feliz que ao menos chegou até aqui. Se não quiser, não precisa mais ler.

Já se você concorda com essas idéias, continua comigo.

Ao conhecer com profundidade uma linguagem de programação; ou uma ferramenta; ou um framework de automação de testes, você saberá como fazer bom uso destes para garantir a qualidade dos softwares sendo construídos. Você saberá escrever testes com um bom design.

Você vai focar na simplicidade em vez da complexidade.

Você vai focar na legibilidade do código em vez de somente no princípio DRY (Don't Repeat Yourself).

Você vai focar nas abstrações extremamente necessárias, em vez de abstrações superficiais.

Você vai se preocupar em testes desacoplados de detalhes de implementação da aplicação em teste.

Você vai se preocupar em escrever testes rápidos, efetivos e que gerem confiança nos times. Testes que quando estão verdes (passando), a nova versão pode ir pra produção. E que quando estão vermelhos (falhando), é por que um problema real foi encontrado, a tempo de correção, antes de chegar no usuário final.

Quer aprender como chegar nesse próximo nível?

Te convido a começar com os cursos de automação de testes da Escola Talking About Testing.

Depois, venha participar da Test Design Masterclass, uma experiência que oferece benefícios significativos para profissionais que desejam aprimorar suas habilidades em design de software com foco em testes automatizados e aumentar suas senioridades para evoluírem em suas carreiras.

Ou então, venha fazer uma mentoria individual focada em suas necessidades específicas.

Gostou desse conteúdo? Me diga o que achou nos comentários.

👋

Forem: Talking About Testing

Triggering Cypress End-to-End Tests Manually on Different Browsers with GitHub Actions

A Practical Guide to Cross-Browser Testing

The Full Workflow

Naming the Workflow

Manual Trigger with workflow_dispatch

Defining Input Parameters

What's happening here?

Defining the Job

Step 1: Checking Out the Code

Step 2: Installing Safari (WebKit) Dependencies Conditionally

Why is this needed?

What the condition does

Step 3: Running Cypress with the Selected Browser

Key idea

Step 4: Uploading Screenshots on Failure

What it does

Why this matters

Final Thoughts

Software Engineering Principles and Ethics

What are the principles that any professional software engineer should comply with?

Why accepting red or failing tests is unethical

What other thought leaders say about responsibility

A non-negotiable rule for professionals: never accept red tests

Ethics in software engineering is real

Professionalism is a daily choice

Uma hipótese para os layoffs do Itaú

Setembro de 2025

Simulando navegação por teclado com as novas teclas do comando cy.press na versão 15.1.0 do Cypress

TAB, SPACE e muito mais agora fazem parte da sua estratégia de testes automatizados

O cenário de teste

Os comandos customizados

O que mudou no cy.press?

Conclusão

Cypress v15: A Better User Experience

Streamlined Features and Improvements for Modern Testing

Hierarchical Grouping

Cleaner Visual Density

Final Thoughts

Illustrations comparing Cypress versions 14 and 15

Uma alternativa de processo seletivo para contratar melhores QAs

A indústria de qualidade de software está estagnada. Precisamos mudar isso!

Manual Trigger with `workflow_dispatch`

`TAB`, `SPACE` e muito mais agora fazem parte da sua estratégia de testes automatizados

O que mudou no `cy.press`?