Plataforma
QA automatizado para a entrega séria de software com IA
Cada alteração escrita por IA é testada da forma como um utilizador a experienciaria — num navegador real, antes de ser lançada e depois de chegar.
O QA do Ciao é a camada de testes automatizados da plataforma: repetições determinísticas em navegador, testes autocuráveis, smoke gates antes da publicação e verificações de produção depois da publicação. Ao contrário de suites de testes que apodrecem à medida que a aplicação muda, os testes do Ciao reparam-se a si próprios quando a interface evolui — para que a cobertura acompanhe o ritmo do desenvolvimento à velocidade da IA em vez de ficar para trás.
Publicado 2026-07-03 · Última atualização 2026-07-03
A IA escreve mais depressa do que os humanos conseguem testar
O desenvolvimento assistido por IA desloca o estrangulamento. Código que costumava demorar um sprint chega numa tarde — e cada uma dessas alterações pode quebrar o checkout, o login ou o relatório que um diretor lê todas as segundas-feiras. Clicar manualmente pela aplicação não escala a esse ritmo, e as suites de testes tradicionais degradam-se no momento em que a interface muda debaixo delas.
O QA do Ciao é construído para esse ritmo. Executa repetições determinísticas em navegador, testes autocuráveis, smoke gates antes da publicação e verificações de produção depois da publicação — automaticamente, em cada alteração, como parte do mesmo ciclo que escreveu o código.
Como funciona o QA
O QA corre como parte do ciclo de entrega — nada aqui é uma ferramenta separada para adotar ou um pipeline para manter.
1. Os fluxos são capturados como repetições
As jornadas-chave do utilizador — iniciar sessão, criar um registo, fazer checkout — são capturadas como repetições determinísticas em navegador: os mesmos passos, os mesmos inputs, os mesmos resultados esperados, em cada execução.
2. Os testes correm num navegador real
As repetições executam-se contra a aplicação real, da forma como um utilizador a experienciaria — renderização real, rede real, autenticação real — não contra componentes simulados.
3. Os testes curam-se em vez de apodrecer
Quando a interface muda legitimamente — um botão move-se, um rótulo é reformulado — os testes autocuráveis atualizam-se para corresponder à nova realidade, em vez de falharem num seletor desatualizado e serem eliminados.
4. Os smoke gates seguram a porta
Antes de qualquer publicação, os smoke gates executam as repetições críticas. Um gate a falhar interrompe a publicação, para que a versão avariada não seja lançada através dele.
5. As verificações de produção fecham o ciclo
Depois da publicação, as verificações correm contra a aplicação ao vivo para confirmar que o lançamento se comporta em produção, onde a configuração e os dados são reais.
6. As falhas voltam como trabalho
Uma verificação falhada volta ao ciclo com contexto — qual passo falhou e o que era esperado — onde a correção pode ser construída e reverificada.
Porque é que isto importa
O determinismo importa porque testes instáveis ensinam as equipas a ignorar o vermelho. Quando uma repetição falha, algo realmente mudou — o que torna o sinal digno de ação e o gate digno de confiança.
A autocura importa porque a alternativa é uma suite que morre em silêncio. Uma cobertura que se mantém a si própria acompanha o ritmo de mudança à velocidade da IA, para que a centésima alteração seja testada tão minuciosamente quanto a primeira. E gates em ambos os lados da publicação significam que "funcionou na pré-visualização" e "funciona em produção" são ambos verificados, não assumidos.
O hábito que isto constrói é o ponto principal. Quando cada publicação tem um gate e cada lançamento é verificado em produção, lançar deixa de ser um ato de coragem. As equipas fazem mais alterações, em peças mais pequenas, porque o custo de estar errado é uma publicação parada em vez de uma segunda-feira avariada — e o registo de auditoria mostra todos os gates que cada lançamento passou.
Quem o usa
O QA é uma das seis funções na organização de software com IA do Ciao, e pessoas diferentes apoiam-se nele de forma diferente.
- Não-engenheiros a lançar apps reais — Pessoas de quem não se pode esperar que escrevam suites de testes obtêm uma na mesma — capturada a partir dos fluxos que a sua app realmente tem.
- Líderes de engenharia — Gates em vez de promessas: uma publicação que falhou o seu smoke gate não sai, independentemente de quem a pediu.
- Agências — Cada aplicação de cliente obtém jornadas protegidas sem um orçamento de QA por projeto ou uma suite mantida manualmente por cliente.
- Equipas de operações e suporte — As verificações de produção apanham regressões na app ao vivo, para que os problemas surjam como resultados em vez de tickets de suporte.
Notas de segurança e governança
- ✓ Os smoke gates correm antes de cada publicação; as verificações de produção correm depois.
- ✓ As repetições são determinísticas — os mesmos passos, os mesmos dados, o mesmo resultado esperado em cada execução.
- ✓ A autocura mantém a cobertura viva à medida que a interface evolui.
- ✓ Os resultados do QA alimentam o estado do projeto no Conductor, visível em toda a frota.
- ✓ Os resultados dos testes juntam-se ao registo de auditoria apenas de acréscimo, ao lado de merges e deploys.
Uma suite mantida manualmente vs QA do Ciao
O contraste com uma suite mantida manualmente é estrutural, não cosmético.
| Suite de testes mantida manualmente | QA do Ciao | |
|---|---|---|
| Autoria | Engenheiros escrevem e atualizam scripts | Fluxos capturados como repetições à medida que a app é construída |
| Alterações de interface | Os seletores quebram; os testes são saltados | Os testes autocuram-se para corresponder à nova interface |
| Antes do lançamento | O CI corre se alguém o tiver configurado | Os smoke gates travam uma publicação a falhar |
| Depois do lançamento | Monitorização, se configurada | As verificações de produção verificam a app ao vivo |
| Falhas instáveis | Reexecutar e esperar | Repetições determinísticas — vermelho significa que algo mudou |
Perguntas frequentes
O que significa determinístico aqui?
As repetições correm os mesmos passos com os mesmos inputs e as mesmas expectativas de cada vez. Uma falha significa, portanto, que a aplicação mudou, não que o teste oscilou — o que torna razoável usá-lo como gate de uma publicação.
Tenho de escrever os testes eu próprio?
Não. As jornadas-chave são capturadas à medida que a aplicação é construída, e pode acrescentar os fluxos mais importantes para o seu negócio. Os engenheiros podem inspecionar e estender o que corre — é parte do projeto, não uma caixa negra.
O que acontece quando um smoke gate falha?
A publicação para. A falha volta com contexto — o passo, a expectativa, o que aconteceu em vez disso — para que a correção possa ser feita e reverificada. Quando o gate está verde, a publicação prossegue.
O que são verificações de produção, e porque correr depois da publicação?
A pré-visualização e a produção diferem: a configuração, os dados, as integrações e o tráfego só são reais numa delas. As verificações de produção correm contra a aplicação ao vivo depois de cada lançamento para confirmar que se comporta onde importa, e os resultados fluem para o Doctor e o SysOps para diagnóstico e resposta.
Isto substitui os engenheiros de QA?
Não — muda aquilo em que gastam o tempo. O trabalho mecânico de manter os testes de navegador vivos é automatizado; os humanos decidem quais jornadas são críticas, revêm o que os gates apanham e sobem a fasquia ao longo do tempo.