blogs

Tester at the business intersection— how the testing role naturally expands

2026-07-20T14:18:18Z

I’ve been thinking about how to explain how testers naturally get drawn into other areas across the business and I’ve come up with this line

Tester at the business Intersection.

I feel this explains well that you are surrounded by topics such as process improvement, risk management, cross team collaboration, change management and continuous improvement.

Real life examples -

I get asked to facilitate a definition of ready workshop and help drive what refinement sessions look like. Or document what a Pen Test process looks like from requesting, scheduling, reviewing results, implementation to closure. (process improvement)
To ask the business if they want a change released with a particular bug (change management).
To educate another team how a product works and how to test the system (cross team collaboration).
Providing feedback in a retrospective on how to streamline processes to make us more efficient and less wasteful (Continuous improvement)

As you can see from my real life examples testing is not simply about testing a product and giving feedback. It involves collaboration, assessing risk and change management, refining processes and continually improving the as is.

For all of this to work what is needed is a Quality Management system — interconnected parts that all work together to meet customer and stakeholder requirements and to strive to exceed expectations. More on this soon!

Tester at the business intersection— how the testing role naturally expands

2026-07-20T14:18:18Z

I’ve been thinking about how to explain how testers naturally get drawn into other areas across the business and I’ve come up with this line

Tester at the business Intersection.

I feel this explains well that you are surrounded by topics such as process improvement, risk management, cross team collaboration, change management and continuous improvement.

Real life examples -

I get asked to facilitate a definition of ready workshop and help drive what refinement sessions look like. Or document what a Pen Test process looks like from requesting, scheduling, reviewing results, implementation to closure. (process improvement)
To ask the business if they want a change released with a particular bug (change management).
To educate another team how a product works and how to test the system (cross team collaboration).
Providing feedback in a retrospective on how to streamline processes to make us more efficient and less wasteful (Continuous improvement)

Playwright TypeScript Multiple Environments: A Complete Real-World Guide

2026-07-20T03:45:29Z

Learn how to configure multiple environments in Playwright TypeScript using projects, baseURL, environment variables, and dotenv.

Continue reading on Level Up Coding »

Playwright TypeScript Multiple Environments: A Complete Real-World Guide

2026-07-20T03:45:29Z

Learn how to configure multiple environments in Playwright TypeScript using projects, baseURL, environment variables, and dotenv.

Continue reading on Level Up Coding »

Speaking up is only half the story

2026-07-19T17:09:08Z

Something feels off

Imagine you’re in a planning or refinement meeting.

A senior engineer, lead or manager is explaining how they think the team should approach something. They sound confident, a few people are nodding, and everyone appears ready to move the conversation on.

But something doesn’t feel right to you.

Maybe there’s an assumption that hasn’t been explored. A dependency people are overlooking. Or a risk that could cause problems later.

You can’t fully explain it yet. You don’t have evidence or a better solution either. You just have a sense that something might have been missed.

Do you say something?

Speaking up could make you look like you haven’t understood. Like you’re being negative, slowing the team down or challenging someone more senior without a good enough reason.

But staying quiet could cause problems later, once more work has been built around the decision and the cost of changing direction is much higher.

Would you speak up, even though your concern isn’t fully formed?

Or stay quiet and hope you’re wrong?

Speaking up is only half the story

The thing about speaking up is that it’s only half the story. The other half is what happens next: the response.

That response teaches the person whether they will be judged, dismissed or embarrassed for taking the interpersonal risk of saying what they did.

But it also teaches everyone else watching what might happen if they took a similar risk.

Our responses in these moments, therefore, have consequences beyond the person who spoke. They influence what others may be willing to share in future.

And challenging authority isn’t the only situation where people may hold back.

It could be saying that you don’t understand something. Disagreeing with a decision or direction. Raising a concern. Or admitting that you’ve made a mistake.

Making uncertainty visible

When someone speaks up, they make uncertainty visible and bring new information into the system. While we don’t often think about it this way, a question, concern or disagreement can be a form of feedback.

A question can reveal missing shared understanding. A disagreement can expose different assumptions. A concern can highlight a potential risk. Admitting a mistake can draw attention to a problem within the wider system.

Speaking up does not necessarily reduce that uncertainty immediately. The concern may turn out to be unfounded, or the question may reveal a misunderstanding rather than a problem. But making it visible gives the team an opportunity to investigate, learn and decide what to do next.

Silence does not remove uncertainty either. It leaves it hidden, where it may later return as rework, defects, delays or surprises. The very things that unnecessarily slow teams down.

There is also interpersonal uncertainty.

The person speaking up may not know how others will respond. Will their contribution be taken seriously? Will they be judged, dismissed or blamed? Or will their perspective be met with curiosity?

This creates two connected feedback loops.

The immediate loop is about what happens to the information. Does the team explore it, dismiss it or act on it?

The future loop is about what people learn from the response. Will they share similar information next time?

These loops compound in that dismissing one concern may not only hide that information. It may also discourage the next question, concern or admission of a mistake.

However, a productive response can send the loop in the other direction. When one concern is explored respectfully, others may become more willing to ask questions or reveal that they are unsure.

Psychological safety develops through these repeated interactions. People learn whether speaking up is worthwhile by seeing what happens when they or others do it.

Speaking up doesn’t mean agreeing with everything

Psychological safety isn’t about avoiding discomfort, it’s about making disagreement possible.

That doesn’t mean every concern is correct or every issue raised must be acted on. But reasonable concerns should be acknowledged, considered and responded to with respect.

We often conflate understanding as agreement, but taking the time to listen to someone does not require agreeing with them. It means making a genuine effort to understand their perspective before deciding what to do with the information.

What does a productive response look like?

The response will depend on the situation, but many interpersonal risks fall into four broad categories.

“I don’t know”

Make someone feel stupid, and they learn not to ask questions.

Thank them for slowing the team down at the right moment, and they learn that uncertainty can be shared.

“I disagree”, or “we may be missing something”

Dismiss someone as obstructive, and they learn to keep concerns to themselves.

Explore the concern, and they learn that different perspectives are valued.

“I made a mistake”

Respond with blame, and they learn to hide mistakes.

Focus on learning, and they learn that the team improves the system together.

“Someone senior might be wrong”

Talk down to someone, and they learn that hierarchy matters more than information.

Invite the challenge, and they learn that ideas can be examined regardless of who raises them.

Mindsets that support speaking up

This is where the core quality engineering mindsets of curiosity, humility, and empathy become important.

Curiosity helps us understand what the person has noticed.
Humility reminds us that our own perspective may be incomplete.
Empathy helps us recognise the risk they took by sharing it.

These mindsets matter most when we disagree or decide not to act on the information. That is when it becomes easiest to dismiss the contribution along with the idea.

Speaking up is part of the team’s quality system

Quality Engineers often focus on how information about the product moves through tests, monitoring, incidents and customer feedback. But information also moves through conversations.

Questions reveal missing understanding. Concerns can reveal risks. Disagreement can reveal different assumptions, and mistakes can reveal places where the system may need to improve.

A Quality Engineer cannot force people to share that information. But they can pay attention to the conditions that make sharing more or less likely.

Who asks questions? Whose concerns are explored? How are mistakes discussed? What happens when someone challenges a decision or shares a partially formed thought?

These interactions tell us something about the health of the team’s human feedback loops.

Quality Engineers can influence those conditions by modelling curiosity, inviting quieter perspectives and challenging responses that close down discussions.

Speaking up is only half the story.

It’s what happens after that that determines if people continue to.

What is your team teaching people to keep to themselves?

Furter reading

If you’d like to explore some of the ideas behind this post further:

Why is psychological safety important to software engineering teams?
A broader look at what psychological safety means and why it matters in engineering teams.
The Three Mindsets of a Quality Engineer
How curiosity, humility and empathy help us shape quality through everyday interactions.
Quality is Emergent Why quality cannot be forced through individual effort, but can emerge when we create the right conditions around the work.

93fd42c53a6e80da083403037e035f80.mp3

How QA Turns a Traffic Spike Into a Real Diagnosis

2026-07-19T15:47:35Z

Someone on your team drops a message: POST /api/checkout took 20,000 requests in a single hour. It reads like a performance bug, and it might be. But that number alone...

The Hidden Loop of Quality Engineering

2026-07-19T13:01:27Z

Quality engineering is a fun, nebulous concept. I’m into it because of that, not through any deep belief, just the freedom it affords. You can be a great exploratory tester and still be a quality engineer, as long as you have the skills to choose where to focus that skill and energy. I’m not scared of definitions with a bit of wiggle room either. The tighter you try and define something, the more of it slips through your fingers Governor Tarkin. Definitions miss the really good stuff, like the hidden loops that exist within quality engineering.

My favourite hidden loop is making speculative suggestions. This is the way it usually goes.

Ash thinks of a quality related activity, which is appropriate in the current context and will address a risk we have
Ash suggests said quality related activity, everyone says maybe and goes away and thinks about it. Maybe they think we don’t need it (yet or ever), need more time to ponder, or have other things on their mind.
Sometime later, some else on the team suggests said activity and adoption (or at least an experiment) follows.

This might be part of the strategy or not, might be something truly valuable that has emerged. Quality engineering is emergent by the way not to be set wholly and immutably at the beginning and at organisational level.

I can always tell those who talk about quality and testing but haven’t dipped their toes in reality for a while, as they don’t recognise the hidden loop.

Let me give you a recent example, for a system in its early days:

Ash suggests building a web-hook to post messages onto a queue. We can use this for exploratory testing, performance testing, essentially it democratises putting messages on queues for the whole team. Everyone with Postman and a little knowledge or training could use it.
The team says why would we need that, it’s too early and other reasons. Ash says fine, just think about it.
Fast forward a couple of months, the team says we need a way to enable performance testing and democratise the ability to post messages to the queue. Ash says that’s a great idea, let’s do it.

There is nothing in the quality engineering strategy that talks about this, why would there be? Its local to the team and its context. That one web-hook would be more valuable that any part of the strategy though.

Once you recognise the loops that hide in the spaces your strategy doesn’t reach, you’ll be a better quality engineer for it.

AI QA Portfolio Project: Build an Eval CI Gate

2026-07-18T04:35:38Z

Build an AI QA portfolio project that proves you can test LLM features, not just prompt ChatGPT. This Day 40 lab adds PromptFoo, DeepEval, and a CI gate to a real repo.

The post AI QA Portfolio Project: Build an Eval CI Gate appeared first on Software Testing & Automation.

Playwright Visual Regression Testing with TypeScript

2026-07-18T03:36:40Z

Learn Playwright visual regression testing with TypeScript: stable screenshots, CI diffs, masking dynamic UI, and a framework pattern teams can trust.

The post Playwright Visual Regression Testing with TypeScript appeared first on Software Testing & Automation.

PromptFoo vs DeepEval: QA Guide for LLM Evals

2026-07-18T03:35:38Z

PromptFoo vs DeepEval explained for QA engineers: when to use config-driven regression checks, Python metrics, CI gates, and both together.

The post PromptFoo vs DeepEval: QA Guide for LLM Evals appeared first on Software Testing & Automation.

Release Notes to Test Plan: QA Workflow That Works

2026-07-18T03:34:37Z

Turn Playwright and Selenium release notes into a prioritized test plan with owners, smoke coverage, CI gates, and rollback evidence.

The post Release Notes to Test Plan: QA Workflow That Works appeared first on Software Testing & Automation.

Multi-Environment Configuration in Playwright: Dev, Staging, Prod

2026-07-18T03:00:00Z

Clean Playwright multi-environment configuration: one flag flips your suite between dev, staging, and prod with typed profiles and per-env auth.

The post Multi-Environment Configuration in Playwright: Dev, Staging, Prod appeared first on Software Testing & Automation.

Exploratory Testing Charters: The Structured Approach to Finding Bugs AI Never Will

2026-07-17T22:00:00Z

Exploratory Testing Charters: The Structured Approach to Finding Bugs AI Never Will There is a persistent myth in the testing world that exploratory testing means opening the application and clicking around randomly until something breaks. This misconception has caused countless QA managers to dismiss exploratory testing as unprofessional, unrepeatable, and unnecessary in the age of...

The post Exploratory Testing Charters: The Structured Approach to Finding Bugs AI Never Will appeared first on Software Testing & Automation.

All about the people

2026-07-17T20:20:56Z

I’ve recently attended the National Software Testing Conference, with some really interesting talks and also conversations. Despite AI dominating the topics on stage, talking to fellow testers it is clear that our problems remain the same.

Domenico Vitale gave an incredible talk on “Building a High-Impact QA Function” and I loved his message on people then process. Issues in “testing” are really risk, feedback and decision problems. This made me reflect that in a world where we’re leveraging automation & AI to go faster and faster, the value of how we explore and discuss these problems are still essential.

The need to think was also well covered by Kiruthika Ganesan’s exploration of the brain and thinking. She highlighted how speeding things up have made it harder to have meaningful conversations. She asked do we have time to talk when everything takes seconds?

On the flip side there was talk on AI generated requirements, code and testing with human in the loop to review it but with this I ask, how are we getting the time to think about whether we’re implementing the right thing? Some of my favourite practices are built upon talking to our peers. I worry that the the push for AI & faster could lead to us skipping some of the practices that have helped us build quality software.

Shanmugapriya Sabapathy explored how AI is not a fix but an amplifier and the need to have engineering practices that are ready to adopt AI. I’ve seen similar shared by Craig Risi at Nordic Testing Days and Dan Llewyn at an Edinburgh Tech Meetup. With AI being an accelerator, if your processes have your teetering on the edge then you’re only going to go flying off a cliff.

It is important that organisations know that adopting AI isn’t about the end goal of using AI. It is about delivering with quality and without good people, practices and processes, that can’t happen. Everything that we know and understand about building quality software isn’t changing through AI. It is still People, Processes then tools. Just AI is changing the tools and tweaking processes…

Por que os engenheiros mais valiosos do mercado gastam mais tempo conversando do que codando

2026-07-17T20:12:32Z

Há uma cena que se repete em quase toda empresa de tecnologia: alguém recebe uma tarefa, abre o editor e começa a digitar antes de terminar de entender o problema. Duas semanas depois, o time descobre que construiu a coisa errada — com perfeição técnica. Este texto é sobre o profissional que faz o oposto.

Existe um mito silencioso na engenharia de software: o de que o valor de um profissional se mede pela velocidade com que ele produz código. É um mito confortável, porque código é visível, mensurável, versionável. Conversa não aparece no git blame.

Mas observe qualquer engenheiro sênior de verdade em ação — não o que tem mais anos de casa, mas o que as empresas disputam a peso de ouro — e você vai notar um padrão contraintuitivo: ele passa uma fração desproporcional do tempo perguntando, parafraseando, desenhando no quadro, discordando educadamente, até então abrir o editor. E quando abre, escreve rápido, porque já sabe exatamente o que está construindo e por quê.

O código é o efeito, não a causa

O que diferencia esse perfil não é talento de digitação. É que ele enxerga o fluxo de valor de ponta a ponta — do problema de negócio até o resultado que o usuário sente — e trata o código como um meio para chegar lá, não como o objetivo em si. Isso muda a ordem das operações: primeiro alinhar o que é valioso e por quê, depois desenhar o caminho técnico, só então escrever.

“Bons programadores escrevem código que os humanos conseguem entender.”

Martin Fowler — Refactoring: Improving the Design of Existing Code

Fowler escreveu isso pensando em legibilidade de código, mas a ideia vale um passo antes: escrever para ser entendido também é o que se faz numa conversa de alinhamento. Quem só escreve para a máquina compilar tende a pular a etapa de escrever — falado ou em texto — para as pessoas entenderem.

A pergunta que todo mundo já fez

Se conversar não gera commits, por que isso deveria contar como trabalho de verdade?

Porque comunicação malfeita é o maior gerador de retrabalho que existe — e retrabalho é código também, só que descartado. Frederick Brooks, arquiteto de software do IBM System/360 e autor de The Mythical Man-Month, mostrou que projetos grandes não falham por falta de gente digitando: falham porque o custo de coordenação cresce mais rápido que o número de pessoas. Ele chamou de “conceitual integrity” a ideia de que um sistema bom precisa vir de poucas mentes alinhadas — não porque comitês são burros, mas porque cada nova pessoa multiplica os caminhos de comunicação necessários para todo mundo entender a mesma coisa.

Na visão dele, publicada em 1975 e ainda citada hoje, “conceptual integrity is the most important consideration in system design” — a integridade conceitual é a consideração mais importante no design de um sistema. Conversa é como essa integridade se propaga entre pessoas antes de virar código.

O preço do mal-entendido

Barry Boehm estudou projetos reais na TRW e na IBM e chegou a uma conclusão que hoje parece óbvia mas continua sendo ignorada na prática: um mal-entendido descoberto na fase de requisitos custa uma fração do que custa descobri-lo depois do sistema estar em produção — em análises citadas por engenheiros da NASA, essa diferença chega à ordem de cem vezes. A curva ficou menos exponencial com práticas modernas de entrega contínua, mas a direção da seta nunca mudou: quanto antes você entende errado, mais barato é corrigir.

Kent Beck, criador do Extreme Programming, levou essa ideia a sério de um jeito diferente: em vez de tentar acertar tudo de uma vez no papel, ele propôs achatar a curva com ciclos de feedback curtíssimos — testes antes do código, integração constante, conversas frequentes no lugar de documentos grossos escritos uma única vez. A lição comum aos dois: o problema nunca foi documentar demais ou de menos, foi quando você descobre que entendeu errado.

“...é sempre um problema de pessoas.” - Kent Beck — Extreme Programming Explained

Beck escreveu isso sobre um contexto específico — não importa o que o cliente diga que é o problema técnico, na raiz costuma haver um desalinhamento entre pessoas. É por isso que times que conversam bem corrigem defeitos de entendimento antes que eles virem defeitos de código.

Pergunta seguinte

Então a solução é documentar tudo antes de sair codando?

Não exatamente — é pensar em prosa antes de pensar em sintaxe. A Amazon institucionalizou isso com o processo interno conhecido como Working Backwards: antes de qualquer linha de código, o time escreve um comunicado de imprensa fictício e uma lista de perguntas frequentes descrevendo o produto já pronto, do ponto de vista do cliente. Jeff Bezos resumiu a lógica dizendo que a empresa “start[s] with the customer and work[s] backwards” — começa pelo cliente e trabalha de trás para frente.

O caso mais citado é o da AWS: Bezos e Andy Jassy identificaram a oportunidade em 2004, mas os serviços fundacionais (S3 e EC2) só foram lançados em 2006 — mais de um ano foi gasto escrevendo, revisando e discutindo esses documentos antes de qualquer infraestrutura ser construída. A empresa também substituiu apresentações de slides por memorandos narrativos de até seis páginas nas reuniões de decisão, exatamente porque escrever em prosa força a explicitar relações de causa e efeito que um slide deixa passar batido.

Por que isso não é burocracia

Vale uma ressalva científica aqui. O próprio Brooks fez uma comparação reveladora: a física lida com sistemas tão complexos quanto o software, mas o físico trabalha com fé de que existem princípios unificadores por trás do caos — a complexidade da natureza é, em certo sentido, honesta. A complexidade de um sistema de software, ao contrário, é muitas vezes arbitrária: nasce de decisões humanas, de interfaces que mudam de equipe para equipe, de contexto que não está escrito em lugar nenhum a não ser na cabeça de quem participou da conversa original.

É por isso que engenheiros de alto nível conversam antes: não para seguir processo, mas porque a complexidade arbitrária do software só existe na cabeça das pessoas até alguém a transformar em linguagem compartilhada — falada, escrita ou desenhada. Código é a última tradução dessa cadeia, não a primeira.

Técnicas para não errar a especificação, o entendimento e os testes

Especificação

Reescreva o pedido com suas próprias palavras antes de abrir o editor, e mande de volta para quem pediu confirmar. Se a paráfrase não bater, o requisito não estava claro — só parecia estar.
Pergunte pelo que não deve acontecer, não só pelo que deve. Casos de borda e comportamento não-funcional (performance, segurança, limites) raramente aparecem no pedido original.
Escreva um mini “PR/FAQ” antes de uma POC: qual pergunta este experimento responde e o que provaria que ele falhou. Sem isso, toda POC “funciona” — porque ninguém definiu o que seria fracasso.

Entendimento

Em sistemas legados, mapeie o comportamento atual antes de mudar (testes de caracterização / golden master). Documente o que o sistema faz hoje, não o que a documentação diz que ele deveria fazer — raramente são a mesma coisa.
Traga alguém de fora da equipe técnica (produto, suporte, dados) para ouvir sua leitura do problema antes de estimar prazo. Se você não consegue explicar em termos simples, ainda não entendeu o suficiente para estimar.
Em reuniões de kickoff, seja o último a falar sobre solução. Alinhar o problema antes da solução evita que a primeira ideia técnica vire âncora da conversa inteira.

Testes

Escreva o teste que evidencia a intenção — dado, quando, então — antes ou junto da implementação, mesmo sem seguir TDD à risca. Um teste escrito depois tende a confirmar o código, não a intenção original.
Em MVPs, escreva por escrito o que deliberadamente não será testado (non-goals). Isso transforma débito técnico invisível em decisão explícita, revisável mais tarde.
Revisão de código deve avaliar se o código cumpre o que a conversa combinou, não só se está limpo ou idiomático. Sintaxe correta não é o mesmo que intenção correta.

3 práticas para levar à próxima conversa com seu gestor ou PM

Tudo isso pode soar abstrato se você ainda não tem uma década de bagagem para “simplesmente perceber” quando uma conversa evitaria um problema.

As três práticas abaixo não exigem experiência — só um script pronto e a coragem de usá-lo antes de abrir o editor.

1 · Antes de começar — traduza o pedido em uma frase que se responde com “sim” ou “não”

Você não precisa entender o negócio a fundo para fazer isso. Precisa só devolver o que ouviu, em uma frase curta, e esperar confirmação antes de escrever a primeira linha de código.

“Antes de começar, só confirmando: o objetivo é [o que você entendeu], para que [resultado que a pessoa quer] aconteça. É isso mesmo?”

Se a resposta vier rápida e direta, você entendeu. Se vier uma correção — “não bem, na verdade...” — você acabou de evitar dias de trabalho na direção errada, pelo custo de uma mensagem.

2 · Durante a conversa — pergunte pelo cenário de fracasso, não só pelo de sucesso

PMs e gestores costumam descrever o que a funcionalidade deve fazer. Raramente descrevem o que ela não pode quebrar, porque isso parece óbvio para quem pensa no produto o dia inteiro. Não é óbvio para quem está chegando agora — e perguntar por isso não exige jargão técnico.

"O que aconteceria se essa parte desse errado, ou se ela simplesmente não existisse? Isso me ajuda a saber o que eu não posso quebrar sem perceber."

Essa pergunta funciona em qualquer nível de senioridade porque desloca a conversa do “o que construir” para “o que importa de verdade” — que é exatamente o tipo de informação que normalmente só aparece depois, em produção.

3 · Depois da conversa — feche com um resumo escrito de três linhas

Não precisa ser um documento. Precisa existir, e precisa ser curto o bastante para alguém corrigir em quinze segundos, no mesmo dia — não descobrir o mal-entendido na revisão final.

Entendi: [o problema, em uma frase]
Vou fazer: [o que você vai construir]
Pode dar errado se: [a maior dúvida ou risco que você identificou]

Esse mini-resumo é a versão rascunho do memorando narrativo da Amazon citado antes: força você a organizar o pensamento em texto simples, e dá para quem pediu a tarefa uma chance barata de corrigir o rumo — exatamente o ponto da curva de custo em que a correção ainda é quase de graça.

“A única maneira de ir rápido é ir bem.”

Robert C. Martin — Clean Architecture

Vale para código, e vale para o que vem antes dele. Pular a conversa para “ganhar tempo” costuma custar mais tempo depois — só que espalhado, invisível, disfarçado de imprevisto.

O perfil mais disputado do mercado hoje não é o que escreve mais rápido. É o que entende o fluxo de valor de ponta a ponta — do problema de negócio ao resultado sentido pelo usuário — e usa o código como meio, não como fim. Conversar antes de codar não é perder tempo: é onde esse profissional realmente trabalha.

Obrigado por ler Crônicas de um Programador Pragmático! Inscreva-se gratuitamente para receber novas publicações e apoiar meu trabalho.

Sua vez

Qual foi a vez em que uma conversa de dez minutos evitou uma semana de retrabalho? Ou o contrário — o que aconteceu quando o time codificou antes de entender? Conte abaixo.

Deixe um comentário

Frederick P. Brooks Jr. — The Mythical Man-Month: Essays on Software Engineering (1975/1995)
Colin Bryar & Bill Carr — Working Backwards; processo PR/FAQ da Amazon (workingbackwards.com)
Barry Boehm — Software Engineering Economics (1981); síntese em relatório da NASA sobre custo de erro
Kent Beck — Extreme Programming Explained (2000), sobre o achatamento da curva de custo de mudança e mal-entendidos como problema de pessoas
Martin Fowler — Refactoring: Improving the Design of Existing Code (1999)
Robert C. Martin — Clean Architecture: A Craftsman’s Guide to Software Structure and Design (2017)

Build Your Own Local AI QA Engineer with Docker, Ollama, LibreChat, and Playwright MCP

2026-07-17T13:40:27Z

Learn how to build a completely local AI-powered QA Automation Engineer using Docker, Ollama, Qwen3:8b, LibreChat, and Playwright MCP…

Continue reading on Level Up Coding »

Build Your Own Local AI QA Engineer with Docker, Ollama, LibreChat, and Playwright MCP

2026-07-17T13:40:27Z

Learn how to build a completely local AI-powered QA Automation Engineer using Docker, Ollama, Qwen3:8b, LibreChat, and Playwright MCP…

Continue reading on Level Up Coding »

API Challenges with Swagger UI and Simulator Requests

2026-07-17T09:00:00Z

TLDR; API Challenges can now be used without installing any REST Clients.

A few things that changed for the API Challenges recently.

new repo
In Situ Requests for the Simulator
Swagger UI

My aim with the API Challenges was always to make API Testing easy to learn and experiment with. Hopefully all of this makes the API Challenges easier to use and work through.

API Challenges Repo

API Challenges was a ‘spin off’ project from my ‘Thingifier’ Entity Relationship Modelling tool.

I’ve now moved the API Challenges into a Repo of their own.

github.com/eviltester/apichallenges

New releases will be on the API challenges repo:

New API Challenges releases
Old API Challenges releases still on the Thingifier

This allows me to expand the features of the Thingifier without always updating the API Challenges.

New Simulation Mode Features

The API Simulator is a set of requests with canned responses.

It is a ‘real’ API, in that it will respond with XML or JSON if you change the accept headers - but I don’t really advertise that because it is designed to be easy to use… but it’s a real API.

We’ve had an Open API spec file that you can upload into Swagger or REST Clients for a while. And that was basically the main suggested way to work with the API.

But I wanted to make working through the Simulator even easier.

So I’ve added in-situ request execution.

When you work through the Simulator instructions, which are step by step instructions, and you encounter a request that the simulator wants you to make. You can now make it directly from within the browser and see the results.

If you want to experiment with cURL or wget to make the requests then you can copy them from the page and paste them into your CLI.

This should make it a lot easier for first time walkthroughs of “what is an API?” and “What are API requests exactly?”

And… we’ve added a Swagger UI page so you can use the swagger UI to experiment. But more on that in a moment.

Swagger UI

We now have a Swagger UI page for all of the main APIs on the site.

Simulator
[Simple API]https://apichallenges.eviltester.com/simpleapi/docs/swagger-ui)
API Challenges

This means that you can use all the APIs without having to install a REST client and experiment with the API.

I do recommend using an API Client because it is the only way to really solve all the challenges and you will use a REST Client when you test APIs in the real world.

But… the Swagger UI is another ’easy next step’. Rather than forcing you to use a client you can start making requests in the browser and when you understand what you are doing you can move on to a REST Client.

Recommended Learning Steps for API Testing

Depending on where you are in your API Testing journey, you can start at different points in this list:

Walkthrough the instruction steps in the Simulator using the in browser request widget. Make request and see responses.
Learn more about APIs using the Learning Zone which has tutorials and reference information.
Experiment with the Simple API using the Swagger UI
Download one of the REST API Clients - you can find a list on the site
Experiment with your client using the Mirror mode to make sure the client is setup correctly.
Work through the API Challenges using the REST Client

Mix and match the Simulator if you want to experiment with different clients or start using CLI tools like cURL or wget.

Hopefully there is enough flexibility in learning style and information that you can learn and experiment with APIs at your own pace.

And if you want additional variety and more sites to test then we have a list of recommended Practice APIs

<p> <strong><a href="https://www.patreon.com/c/eviltester">Join our Patreon</a> from as little as $1 a month for early access to videos, ad-free videos, free e-books and courses, and lots of exclusive content.</strong> </p>

AI for QA Engineers: New Live Batch Starts 25 July

2026-07-17T08:56:01Z

A hands-on live course for working QA engineers who want to actually use AI in their testing work, not just talk about it.

Earlier this year, I ran the first batch of my live course, AI for QA. Working QA engineers from different companies and countries joined, sat through live sessions, built things hands-on, and presented their own projects on Demo Day.

The most common feedback I got was some version of this: “I had read about AI everywhere, but this was the first time I actually used it in my own testing workflow.”

That is exactly the gap this course exists for. And now the next batch is starting on 25 July.

This post covers everything: what the course teaches, how it runs, who it is for, and who it is not for.

Why this course exists

If you work in QA today, you have probably noticed two things happening at the same time.

First, every job description now mentions AI in some form. Teams expect QA engineers to know how to use AI tools, not just have an opinion on them.

Second, most of the content available online is either too shallow (generic “10 ChatGPT prompts for testers” lists) or too far from real QA work (ML theory courses built for data scientists).

There is very little in the middle: practical, hands-on training built specifically for QA engineers, using real testing scenarios, taught live so you can ask questions when you get stuck.

That middle is what this course is.

What you will learn

This is a live, hands-on course. Every topic is taught by doing, on screen, with real examples from QA work. The curriculum covers:

Foundations that actually matter

Tokens, context windows, and why your prompts behave the way they do
Context engineering: how to structure what you give an AI so you get reliable output instead of random output

Working with Claude for QA tasks

Using Claude for day-to-day QA work: test case generation, test data, bug analysis, documentation
Claude Projects and Skills, and how to set them up for your own testing context
Claude Code: using it hands-on for automation work

MCP (Model Context Protocol)

What MCP is and why it matters for testers
Using the official Playwright MCP server to drive browser automation through AI
Building your own custom MCP server, step by step

Testing the AI itself

Promptfoo: evaluating and testing prompts systematically, the QA way

Beyond one tool

GitHub Copilot in a QA workflow
Running local LLMs with Ollama, so you understand what runs on your machine versus in the cloud

Build your own practice environment

Building your own website from scratch to use as your personal practice ground for testing
Taking that website live, so you have a real deployed application to test against, not just localhost
Creating your own database and connecting it to your application

This part matters more than it sounds. Most testers practice on the same public demo sites everyone else uses. In this course, you build and deploy your own application with its own database. That gives you a real system you fully control, to practice UI testing, API testing, and AI-assisted workflows on.

Demo Day

The course ends with a Demo Day where you present what you built. Not a certificate for attendance. An actual project you made yourself.

Everything taught in this course is based on official documentation and hands-on verified workflows. No secondhand claims, no “AI can probably do this” content.

How the batch runs

Start date: 25 July
Schedule: Saturday and Sunday, weekend-only
Time: 8:00 to 9.30:00 AM IST (1.5-2 hours per session)
Format: Live sessions on screen share, fully hands-on
Recordings: Every session is recorded, so if you miss a live class, you do not fall behind

The weekend-morning format is deliberate. Most people joining are working professionals. Two consecutive weekend sessions keep the momentum going without eating into your work week.

Who this course is for

QA engineers (manual or automation) who want to add AI skills to their real work, not just their resume
Testers who have used ChatGPT casually but never gone beyond basic prompting
Automation engineers curious about Claude Code, MCP, and AI-assisted test development
Anyone in QA who keeps seeing “AI” in job descriptions and wants hands-on ability, not just awareness

You do not need any AI or ML background. You do need to be willing to do the hands-on work between sessions.

Who this course is NOT for

I would rather be honest here than have someone join and feel it was not for them.

If you want deep machine learning theory or model training, this is not the course
If you want a recorded, watch-at-your-own-pace course, this is live and structured around live participation
If you expect AI to replace your testing skills, this course teaches the opposite: AI as a tool in the hands of a skilled tester

Common questions

Do I need to know coding? Basic familiarity helps for the automation-focused sessions, but the course is built for QA engineers, including manual testers. Every hands-on exercise is walked through live, step by step.

What if I miss a session? Recordings are provided for every session.

What tools do I need? Everything you need is covered in the setup session at the start. You will not be asked to buy a stack of paid tools.

Is this the same as Batch 01? The core curriculum is the same practitioner-focused approach, updated wherever the tools themselves have changed since the last batch.

How to join

The new batch starts Saturday, 25 July.

Registration link: https://forms.gle/TfAjJQ1EU3xtxu3x9

If you have questions before registering, drop them in the comments or reach out to me directly.

See you in class.

I run ABAutomationHub, where I create content on QA, automation, and AI for testers. This course is the live, hands-on version of everything I have been building and teaching in that space.

STeP-IN 2026: My Proposal for the Conference Theme

2026-07-17T08:04:36Z

I submitted a theme proposal for the STeP-IN Summit 2026. Below is the theme I proposed, along with the abstract explaining why I believe it is the need of the hour.

To enable AI and Agents to truly help us across the SDLC, engineers and businesses must restructure and realign the way they work. This change is critical and necessary.

Simply introducing AI and Agents into an organization is not enough. Their adoption requires a cultural shift in the organization and a change in the way engineers work.

Unless this shift happens, AI and agents cannot effectively understand and respond to the context in which they are being used. This is what I am learning.

My theme proposal is not selected, but I congratulate the person whose proposal is chosen.

See you at STeP-IN 2026!

Theme

"Restructuring and Orchestrating Myself and Tests with AI and Agents"

Abstract

The AI solution and tooling is everywhere in the SDLC for an engineer and business.

How do the AI and Agents influence the below factors in my work and organization?

The confidence in release
The confidence in code and tests generated and written with assistance
The speed of release
The cost of going wrong in production

For an engineer, using AI and Agents is about efficient productivity and personal upskilling. For an engineering leader it is about the velocity and displacement in business. The same AI and Agents but the two different expectations and interpretations!

To achieve, both the engineer and engineering leader have to restructure and orchestrate themselves individually and as a team with AI and Agentic solutions. If not, above mentioned factors will get impacted and derail the delivery.

Anytime the answer to above said factors is not confident, then incorporation of AI and Agentic solutions in SDLC is not working. Then, it is just bragging – do you know how our engineers spend the whole day using AI to code, test and ship? That’s it. It is not serving the business and engineer.

This is where, this theme is critical and a need – Restructuring and Orchestrating Myself and Tests with AI and Agents.

Most of us are using AI and Agents without asking,

How it has impacted the releases cycle compared to last year?
How confident and fast we are in coding and testing compared to last year?
Has it cut down the time of testing and automation compared to last year?

If there is no confident answer, you know it – one has to restructure and orchestrate the self with AI.

How to do it? The test engineers, SDETs & engineering leaders to share and talk on how they are doing it in their work and org.