Como funciona o QA do Firebird e por que ele precisa ser reforçado

9 de outubro de 2026 · Alexey Kovyazin, Firebird Foundation

Em resumo

O Firebird está arrecadando recursos para reformar o seu QA. O fluxo de mudanças no código cresce mais rápido do que o projeto consegue verificá-lo. Sem novos recursos, a qualidade das versões vai sofrer.

O Firebird é um banco de dados relacional de código aberto, desenvolvido e usado pela sua comunidade. Segundo estimativa do projeto, cerca de um milhão de desenvolvedores de software usam o Firebird em suas aplicações. Quatro branches são mantidos ao mesmo tempo: 3.0, 4.0, 5.0 e 6.0 (em desenvolvimento). Cada correção e cada melhoria passa por verificação obrigatória, manual e automatizada, antes do lançamento.

Em 2025, o repositório do Firebird recebeu 190 pull requests (PRs), 3,1 vezes mais do que em 2020, e 2026 já está à frente de 2025. As ferramentas de IA são uma das principais razões: escrever código ficou mais barato, mas verificá-lo, não. A complexidade também cresce. O Firebird 6.0 está em desenvolvimento, e no primeiro semestre de 2026 houve quase o dobro de PRs com mais de 200 linhas em relação ao ano anterior: 40 contra 21.

A ideia central da reforma é rodar o QA com mais frequência. Hoje a suíte de testes roda uma vez por dia e só depois do merge. Para PRs, ela não roda. Depois da reforma, cada PR aprovado passará por um subconjunto obrigatório de QA antes do merge, a cada atualização. PRs grandes também passarão pela suíte completa e por um teste de desempenho.

Para isso, precisamos de engenheiros de QA, máquinas na nuvem, um agente de IA para a análise inicial dos PRs e novos testes. Pedimos aos usuários do Firebird, e às empresas cujo negócio depende dele, que apoiem a reforma. O primeiro passo já foi dado: em 8 de outubro de 2026, a Firebird Foundation lançou uma campanha de financiamento coletivo de US$ 20.000 para o QA.

O Firebird em números

O Firebird é desenvolvido como projeto de código aberto há 26 anos. Hoje são quatro branches, 12 plataformas na versão 5.0.4 e cerca de 763 mil linhas de código. Uma suíte de 3.138 testes automatizados verifica esse código.

Contamos o código com a ferramenta cloc no diretório src da versão 5.0.4, sem linhas em branco e comentários. Cerca de 288 mil das 763 mil linhas são tabelas de conjuntos de caracteres nacionais. O código C/C++ do engine, da camada SQL, da camada de rede e dos utilitários soma cerca de 453 mil linhas. As plataformas foram tiradas dos arquivos da versão 5.0.4, de 17 de abril de 2026: Windows (x86, x64), Linux (x86, x64, ARM32, ARM64), macOS (x64, ARM64) e Android (x86, x64, ARM32, ARM64).

O fluxo de mudanças está crescendo

Desde 2020, o número de pull requests no Firebird cresceu 3,1 vezes. Nos primeiros nove meses de 2026, já houve quase tantos PRs quanto em todo o ano de 2025: 184 contra 190.

Além dos PRs, o tracker recebe relatórios de bugs e pedidos de melhoria. Em 9 de outubro de 2026, havia cerca de 1.800 issues e 92 PRs abertos. O número de autores também cresce: 19 pessoas abriram PRs em 2020, 30 em 2025 e já 32 em 2026. Cada relatório de bug precisa ser reproduzido. Cada PR precisa ser verificado e testado no seu branch e nos branches para onde a correção é portada.

Os relatórios de bugs chegam em ritmo estável: de 235 a 368 por ano, sem crescimento visível. O que cresce é o fluxo de mudanças no código: em 2026, os PRs superaram as issues pela primeira vez, 184 contra 173 até 9 de outubro. Juntos, são cerca de 440 itens de trabalho por ano, e cada um precisa ser verificado.

Como o QA funciona hoje

Hoje o QA roda só depois do merge. O CI no GitHub compila o código, mas não o testa. A suíte de testes roda uma vez por dia em servidores fornecidos pela IBSurgeon, e apenas para os branches que tiveram commits. Pessoas fazem a revisão, as verificações e a análise dos resultados, e essas etapas não escalam junto com o fluxo de mudanças.

CI no GitHub: só compilação. Cada push e cada PR é compilado no GitHub Actions: 22–23 jobs de build para Linux (x64, x86, ARM, Alpine), Windows (x64, x86, ARM64), macOS e Android. A suíte de testes não faz parte do CI. A cada push, ela levaria horas de máquina, e o GitHub dá a um projeto gratuito no máximo 20 jobs simultâneos para toda a organização. O projeto já esbarra nesse limite: em 7 de outubro de 2026, 7 PRs foram abertos ao mesmo tempo, e os builds esperaram na fila por até 4 horas. No Actions, os testes só podem ser iniciados manualmente e só no Linux x64.
Revisão. Os desenvolvedores do núcleo leem a mudança, discutem no PR e pedem ajustes quando necessário. Muitas vezes a correção precisa ser portada para vários branches, e cada branch precisa ser verificado separadamente.
Verificação manual. Primeiro, um engenheiro de QA reproduz o bug em um snapshot compilado antes da correção. Depois, confirma que o bug sumiu em um snapshot com a correção. Só então o teste é publicado. A seção “O dia a dia do QA”, abaixo, descreve isso em detalhes. Mais de 1.500 arquivos de teste têm a anotação “Checked on” com os números dos builds verificados.
A suíte de testes firebird-qa. É um plugin para pytest com 3.138 testes. Desses, 1.962 são testes de regressão, cada um ligado a um bug específico (1.481 arquivos para bugs do antigo tracker CORE e 481 para bugs do GitHub). Outros 1.176 são testes funcionais: SQL, triggers, domínios, replicação, transações. O repositório tem 3.901 commits.
Execuções noturnas: só para branches alterados. O QA roda separado do CI, em servidores fornecidos pela IBSurgeon: uma vez por dia, no Windows e no Linux, e só para os branches que tiveram commits no dia. Para cada versão, a suíte roda duas vezes: nas duas arquiteturas do servidor, SuperServer e Classic. Os builds do HQbird são verificados da mesma forma. No firebirdtest.com, cada resultado é comparado com as 35 execuções anteriores: novas falhas, crashes com dumps e stack traces, e testes que ficaram mais lentos.
Desempenho. O OLTP-EMUL emula uma carga OLTP real (pedidos, notas fiscais, reserva de peças) em dezenas de sessões paralelas. Ele mede o número de operações de negócio bem-sucedidas por minuto. Uma medição leva cerca de uma hora. Os últimos resultados publicados no firebirdtest.com são de 20 de abril de 2026 e ainda não incluem o branch 6.0.

A regra é a mesma para todos os branches: se houve mudança, há execução de QA. Branches mais antigos mudam com menos frequência, por isso têm menos execuções. O tempo de execução cresce mais rápido do que o número de testes:

Branch	Testes	Execução, Linux	Execução, Windows	Execuções em 30 dias, Linux / Windows
6.0 (master)	≈3.090	4 h 39 min	2 h 28 min	13 / 7
5.0	≈2.880	2 h 30 min	1 h 41 min	11 / 7
4.0	≈2.690	2 h 19 min	1 h 35 min	6 / 8
3.0	≈2.230	1 h 31 min	52 min	4 / 4

O tempo de execução é a mediana das últimas 35 execuções no firebirdtest.com em 9 de outubro de 2026. É a soma de duas execuções, nos modos SuperServer e Classic. “Testes” é o número de testes que rodam nesse branch. Todos os branches usam as mesmas máquinas: o servidor Linux tem 2 CPUs e 7 GB, o servidor Windows tem 8 CPUs e 127 GB. O branch 6.0 tem 7% mais testes que o 5.0, mas a execução no Linux leva 86% mais tempo. O tempo depende não só do número de testes, mas também do que esses testes fazem.

Hoje o QA não roda para PRs. Uma regressão só aparece na manhã seguinte ao merge, junto com todos os commits do dia. Depois, alguém ainda precisa encontrar a mudança exata que a causou.

O dia a dia do QA: como uma correção é verificada

Verificar uma correção é uma pequena investigação. O teste só é publicado se o engenheiro de QA reproduziu o bug em um build anterior à correção e confirmou que o bug sumiu em um build com a correção.

Passo a passo:

Rascunho do teste. Copiamos o cenário .sql do tracker ou escrevemos um rascunho de teste em pytest.
Snapshot antes da correção. Encontramos, ou compilamos nós mesmos, um snapshot do momento mais próximo do push da correção, mas anterior a ele.
Reprodução. Rodamos o cenário do tracker com o rascunho do teste e confirmamos que o bug existia naquele momento. Se o bug não se reproduz, em geral há três motivos:
- o bug sumiu antes, por causa de um commit anterior sobre o mesmo tema ou até sobre outro tema;
- a reprodução depende de algo que o ticket não descreve: um parâmetro de configuração, o sistema operacional ou, mais raramente, o tipo de build (debug ou release);
- o script de verificação no tracker é “fraco” demais; é raro, mas acontece;
- em qualquer desses casos, não seguimos adiante até reproduzir o bug por conta própria. Tentamos um snapshot de uma data ainda mais antiga, o dia em que o ticket foi criado. Se não houver saída, pedimos ajuda a um desenvolvedor do núcleo.
Snapshot com a correção. Encontramos ou compilamos um snapshot a partir do código-fonte que corresponde ao SHA do commit da correção. Se esse push foi o único do dia, basta o snapshot pronto, compilado automaticamente com a mensagem “Increment build number”.
Verificação da correção. Confirmamos que o bug sumiu nesse snapshot. Se sumiu, organizamos o rascunho do teste e o publicamos: git add, git commit, git push. Se o bug continua lá, verificamos o nosso teste várias vezes. Se o problema se confirma, alertamos os desenvolvedores do núcleo.

Regras para os testes:

Um push, um teste. Essa é a prática adotada. A exceção é uma alteração em grupo de algo pequeno em muitos testes ao mesmo tempo.
Um arquivo .py, uma função de teste, como def test_N(...). As outras funções do arquivo, exceto as internas, não podem se chamar test_*. É um requisito rígido: o processamento dos logs do pytest e o esquema do banco de dados que guarda os resultados de todas as execuções dependem disso.

Cada passo exige tempo do engenheiro e, muitas vezes, um build de snapshot separado. Por isso, o gargalo não é escrever código, e sim verificá-lo. É exatamente aí que a reforma acrescenta pessoas e máquinas na nuvem.

O que mudou: mais código do que pessoas para verificá-lo

As ferramentas de IA tornaram muito mais barato escrever código e relatórios de bugs, mas não tornaram a verificação mais barata. Para um banco de dados, isso é especialmente perigoso. Um patch que parece correto pode quebrar a concorrência, a recuperação após falhas ou o desempenho, e isso só aparece sob carga ou em outra plataforma.

A tendência é comum a todo o open source:

Segundo o GitHub Octoverse 2025, o número de pull requests criados no GitHub cresceu 20% em um ano, e o de PRs com merge, 23%. O GitHub associa esse crescimento ao lançamento do Copilot coding agent e da revisão automática de código.
O curl encerrou seu programa de bug bounty em 1º de fevereiro de 2026, por causa de uma enxurrada de relatórios de baixa qualidade, muitas vezes gerados por IA.
Em fevereiro de 2026, os mantenedores do Godot pediram financiamento publicamente para contratar mais pessoas para analisar PRs gerados por IA. Nos mesmos dias, o GitHub começou a discutir ferramentas para filtrar esses PRs.

No Firebird, o fluxo cresceu da mesma forma: 134 PRs em 2024, 190 em 2025 (+42%) e 184 até 9 de outubro de 2026, cerca de 238 no ritmo anual. Recebemos bem os novos colaboradores e não queremos limitar as contribuições. O objetivo é escalar a verificação, não fechar a porta.

Mas a complexidade importa mais do que os números. O Firebird 6.0 está em desenvolvimento, e cada vez mais PRs trazem recursos grandes. No primeiro semestre de 2025, 21 de 104 PRs tinham mais de 200 linhas; no primeiro semestre de 2026, 40 de 106. O número total de PRs quase não mudou, mas a fatia de PRs grandes subiu de 20% para 38%.

Mudanças assim exigem verificações em vários níveis: testes funcionais no Linux e no Windows nos dois modos do servidor, desempenho sob carga e portabilidade para outros branches. E não só uma vez: um PR grande é atualizado depois dos comentários da revisão, e PRs com mais de 1.000 linhas passam, em média, por cerca de oito iterações desse tipo. Cada iteração precisa ser verificada de novo.

Reforma do QA: verificar com mais frequência e antes do merge

A ideia central da reforma é rodar o QA com mais frequência: não uma vez por dia depois do merge, mas para cada PR aprovado antes do merge, a cada atualização. A segunda parte é ter mais testes, incluindo um subconjunto obrigatório e rápido de QA para PRs.

As quatro frentes se apoiam no que já funciona: a suíte de testes, as execuções noturnas nos servidores da IBSurgeon e o CI. As execuções noturnas continuam: os commits diretos dos desenvolvedores do núcleo também passam por elas, e no master eles são cerca de três quartos de todas as mudanças.

Frente	O que fazemos	O que muda
Mais engenheiros de QA	Reproduzem relatórios de bugs, analisam os resultados das execuções de PRs e das execuções noturnas, escrevem testes e montam o subconjunto obrigatório de QA	Cada PR aprovado e cada relatório de bug é verificado em um prazo previsível; os desenvolvedores do núcleo se desviam menos do desenvolvimento
QA para PRs na nuvem	VMs temporárias na DigitalOcean (Linux) e no Azure (Windows): o subconjunto obrigatório a cada push de um PR aprovado; a suíte completa e o OLTP-EMUL antes do merge de PRs grandes	A regressão aparece no próprio PR, antes do merge; os servidores noturnos não ficam sobrecarregados
Agente de IA para análise inicial	Para um novo PR, verifica se é duplicado e se o problema foi confirmado, estima o tamanho e os riscos, sugere o escopo de testes e escreve uma recomendação	Uma pessoa decide em minutos se o PR entra no QA ou é rejeitado; PRs lixo são filtrados antes de qualquer execução
Cobertura e subconjunto obrigatório	Escrevemos testes para áreas pouco cobertas, medimos a cobertura de código e selecionamos testes para o subconjunto obrigatório: no máximo uma hora por sistema operacional	Verificação rápida a cada push e menos regressões nas versões

Alguns detalhes de cada frente:

Engenheiros de QA. Hoje a verificação depende de um grupo muito pequeno de pessoas; a reforma paga uma bolsa (grant) para um engenheiro de QA em meio período. As execuções de PRs vão acrescentar cerca de 140 resultados por mês aos 60 das execuções noturnas, e alguém precisa analisar cada falha.
Nuvem. Os servidores noturnos já estão ocupados: se todos os branches tiverem commits, a suíte completa leva 11 horas no Linux e 6,6 horas no Windows. Os PRs precisam de máquinas separadas, que sobem em paralelo e são apagadas depois da execução, e pagamos só pelo tempo em que elas funcionam.
Agente de IA. Ele não substitui o revisor e não aprova PRs sozinho. A tarefa dele é preparar a decisão: a pessoa vê um resumo pronto e gasta minutos, não uma hora.
Subconjunto obrigatório e cobertura. O subconjunto obrigatório é escolhido pelo tempo, não pelo número de testes: alguns testes pesados podem levar mais tempo do que cem testes leves. A meta é no máximo uma hora por sistema operacional, e a própria seleção é um trabalho à parte dos engenheiros de QA. Além disso, algumas áreas têm pouca cobertura: por exemplo, há 6 testes para BLOB, 4 para monitoramento e 2 para serviços.

Como o caminho de um PR muda depois da reforma: a análise e a aprovação vêm antes do QA, e os testes passam para antes do merge.

A campanha de financiamento coletivo de US$ 20.000 da Firebird Foundation foi anunciada para o tempo dos engenheiros de QA e para máquinas virtuais. O dinheiro arrecadado também paga o agente de análise inicial e a configuração do QA para PRs.

Como um PR entra no QA

Uma execução de QA só começa depois que uma pessoa a aprova. A execução roda o código do PR nas nossas máquinas, então o PR precisa ser revisado antes. Ele pode ser rejeitado de imediato como duplicado, sem sentido, problema não confirmado ou mudança intencionalmente destrutiva.

PR aberto. O CI o compila, como hoje. Um PR de um novo colaborador nem inicia o CI até que um mantenedor o aprove. Essa é a configuração padrão do GitHub, e ela também protege contra a geração em massa de PRs lixo.
Análise inicial. O agente de IA lê o PR e a issue relacionada e escreve uma recomendação no PR: deixar entrar no QA ou rejeitar, qual é a classe de complexidade do PR e quais testes são necessários.
Aprovação. Um desenvolvedor do núcleo ou um engenheiro de QA aprova ou rejeita o PR. A decisão é sempre de uma pessoa.
QA a cada push. Depois da aprovação, cada push passa automaticamente pelo subconjunto obrigatório de QA no Linux e no Windows. Cada execução usa uma VM temporária, sem acesso aos segredos do projeto.
Antes do merge. PRs grandes passam pela suíte completa, e os maiores também passam pelo OLTP-EMUL, comparado com o build de base.
Depois do merge. A execução noturna, como hoje.

Como funcionam as execuções em paralelo

Na nuvem, quatro VMs em paralelo custam o mesmo que uma máquina em sequência. Mas o resultado fica pronto quando termina o branch mais demorado: depois de 4 h 39 min, em vez de 11 horas.

Veja a execução noturna da suíte completa no Linux para os quatro branches: o 3.0 leva 1 h 31 min, o 4.0 leva 2 h 19 min, o 5.0 leva 2 h 30 min e o 6.0 leva 4 h 39 min. Em um único servidor são 11 horas seguidas; em quatro VMs, 4 h 39 min. A nuvem cobra pelo tempo real de uso, então nos dois casos pagamos pelas mesmas 11 horas-máquina.

Com os PRs é igual: a suíte completa no Linux e no Windows e duas medições do OLTP-EMUL rodam ao mesmo tempo, e um PR grande recebe resposta em cerca de 5 horas, e não em 11.

Linux: DigitalOcean, droplet de 16 GB

Desde 1º de janeiro de 2026, a DigitalOcean cobra os droplets por segundo, com mínimo de 60 segundos, então pagamos exatamente pelo tempo de execução. Os preços são da página de preços da DigitalOcean em 9 de outubro de 2026.

Droplet de 16 GB	vCPU	Preço, US$/h	Suíte completa 6.0, 4 h 39 min	Os 4 branches, 10,98 horas-máquina
Basic	8 compartilhadas	0,143	US$ 0,66	US$ 1,57
General Purpose	4 dedicadas	0,1875	US$ 0,87	US$ 2,06
CPU-Optimized	8 dedicadas	0,25	US$ 1,16	US$ 2,75

Para testes de desempenho usamos o General Purpose: os núcleos dedicados não são compartilhados com vizinhos no servidor, então as medições são repetíveis. Suíte completa 6.0 no Linux: US$ 0,1875/h × 4,65 h ≈ US$ 0,87. O servidor Linux da IBSurgeon é mais fraco (2 CPUs e 7 GB), então na nuvem a execução provavelmente será mais rápida; nos cálculos, usamos o tempo medido como está.

Windows: Azure, VM D4s v5 (4 vCPU, 16 GB)

A DigitalOcean não oferece droplets Windows, por isso as execuções no Windows vão para o Azure. Os preços são da região West Europe, com pagamento por uso, da Azure Retail Prices API em 9 de outubro de 2026. A licença do Windows está incluída no preço; discos e tráfego não estão incluídos.

VM D4s v5, 16 GB	Preço, US$/h	Suíte completa 6.0, 2 h 28 min	Os 4 branches, 6,6 horas-máquina
Windows, normal	0,414	US$ 1,02	US$ 2,73
Windows, Spot	0,0765	US$ 0,19	US$ 0,50
Linux, normal (para comparação)	0,23	US$ 0,57	US$ 1,52

Suíte completa 6.0 no Windows: US$ 0,414/h × 2,47 h ≈ US$ 1,02. O servidor Windows da IBSurgeon é mais potente que a VM na nuvem (8 CPUs e 127 GB), então na nuvem a execução pode demorar mais; a reserva para execuções repetidas cobre isso. As VMs Spot são mais de cinco vezes mais baratas, mas o Azure pode retomá-las a qualquer momento. Elas servem para testes funcionais, mas não para medições de desempenho.

Quanto custa o QA para PRs em seis meses

O QA para cada PR aprovado vai custar cerca de US$ 477 em seis meses. Isso usa 2,8 vezes menos tempo de máquina do que a suíte completa com OLTP-EMUL a cada push. A economia vem do subconjunto obrigatório e do fator de complexidade.

A previsão é de 127 PRs nos próximos seis meses: 114 PRs nos últimos seis meses, com crescimento de 25% ao ano, a média desde 2020: 114 × 1,25^0,5 ≈ 127. As issues não entram nas execuções na nuvem: um engenheiro de QA reproduz o relatório de bug em snapshots, e a correção chega como PR ou commit.

Há três tipos de execução. Todos foram calculados para o branch 6.0, para onde vai a maioria dos PRs e onde a suíte é a mais longa. Somamos 15 minutos de preparação a cada início de VM:

Subconjunto obrigatório: 1 h no Linux e 1 h no Windows: 2,5 horas-máquina, US$ 0,75.
Suíte completa: duas execuções, SuperServer e Classic, juntas 4 h 39 min no Linux e 2 h 28 min no Windows: 7,6 horas-máquina, US$ 2,04.
OLTP-EMUL: o build do PR e o build de base em paralelo, 1,5 h cada no Linux: 3,5 horas-máquina, US$ 0,66.

O que rodar, e quantas vezes, depende do PR. Um PR de 5 linhas e um de 5.000 linhas diferem tanto no número de atualizações quanto na profundidade das verificações. Por isso usamos um fator de complexidade: o tempo de máquina por PR comparado com a classe mais simples.

Classe do PR, linhas alteradas	Fatia dos PRs	Pushes por PR	O que rodamos	Horas-máquina por PR	Fator
S, até 20	42%	1,5	subconjunto obrigatório a cada push	3,8	1
M, 21–200	24%	2	subconjunto obrigatório a cada push	5,0	1,3
L, 201–1.000	22%	3	o mesmo + suíte completa antes do merge	15,1	4
XL, acima de 1.000	12%	8	o mesmo + 2 suítes completas e OLTP-EMUL	38,7	10

As fatias das classes e o número de pushes vêm de 214 PRs dos últimos 12 meses. Estimamos os pushes pelo número de dias com novos commits em um PR: em média 1,2, 1,6, 2,1 e 8,0 por classe. É um limite inferior, porque o force-push esconde parte das iterações; por isso os valores da tabela foram arredondados para cima.

Dos 127 PRs previstos, 53 são da classe S, 30 da M, 28 da L e 16 da XL. Um PR custa US$ 1,13, US$ 1,50, US$ 4,30 e US$ 10,76, conforme a classe. Acrescentamos mais 20% para execuções repetidas, por causa de testes instáveis e falhas de VM.

(53 × US$ 1,13 + 30 × US$ 1,50 + 28 × US$ 4,30 + 16 × US$ 10,76) × 1,2 ≈ US$ 477

Compare com hoje e com a opção “tudo a cada push”:

Cenário	Tempo de máquina por mês	Total em relação a hoje	Nuvem em 6 meses
Hoje: execuções noturnas dos branches alterados nos servidores da IBSurgeon	153 horas-máquina	1×	—
Reforma: subconjunto obrigatório a cada push, suíte completa conforme a classe do PR	+232 horas-máquina	2,5×	US$ 477
Suíte completa e OLTP-EMUL a cada push de cada PR	+651 horas-máquina	5,3×	US$ 1.139

O tempo de máquina atual foi calculado com base nos últimos 30 dias: 34 execuções no Linux e 26 no Windows. Nos dois cenários o custo é pequeno. O tempo de espera importa mais: com o subconjunto obrigatório, o autor recebe resposta para cada atualização em cerca de 1 h 15 min; com a suíte completa, só depois de 5 horas.

Se os PRs crescerem mais rápido do que o previsto, no ritmo de 2025 (+42% ao ano), serão cerca de 136, e as execuções custarão cerca de US$ 511. A reserva cobre a diferença.

Ampliação dos testes para o 6.0 e maior intensidade

A preparação da versão 6.0 e uma execução mais intensa dos testes vão acrescentar cerca de US$ 150 às execuções na nuvem em seis meses, cerca de 30% a mais sobre o QA para PRs. O principal custo da ampliação não são as máquinas, e sim o tempo dos engenheiros de QA para escrever novos testes.

Segundo o roadmap do Firebird 6, a versão alfa sai no 4º trimestre de 2026, a beta no 2º trimestre de 2027 e a versão final no 4º trimestre de 2027. A suíte cresce junto: os testes que rodam só no 6.0 passaram de 93 para 225 em um ano; 91 deles foram adicionados nos últimos seis meses e 49 no último trimestre. Os novos recursos (schemas, tablespaces, funções JSON, o tipo ROW, o cache de metadados compartilhado) exigem testes novos e muitas vezes pesados.

O que se acrescenta	O que planejamos	Horas-máquina em 6 meses	Nuvem em 6 meses
Mais PRs e mais PRs grandes	depois da alfa, 15% mais PRs: 146 em vez de 127; 38% dos PRs com mais de 200 linhas, como no primeiro semestre de 2026	207	US$ 72
Verificação dos builds alfa e beta	6 builds; para cada um: suíte completa no Linux, no Windows x64 e no Windows x86, OLTP-EMUL 6.0 contra 5.0 e um teste de estresse de 24 horas no Linux	234	US$ 62
A suíte do 6.0 cresce	até abril de 2027, a suíte completa fica 20% mais longa; em média, 10% mais longa no período	51	US$ 16
Total		492	US$ 150

As horas-máquina aparecem sem repetições; o custo inclui a reserva de 20% para execuções repetidas, como acima.

Com a ampliação, o tempo de máquina cresce cerca de três vezes em relação a hoje: 153 horas-máquina de execuções noturnas, 232 para o QA dos PRs e mais 82 para a ampliação, cerca de 467 por mês no total. Os servidores noturnos não têm essa capacidade. E depois da beta surgirá um branch 6.0 separado, então haverá cinco execuções noturnas em vez de quatro.

A principal ampliação é o trabalho das pessoas. Se o ritmo do último trimestre continuar, cerca de 100 testes só para o 6.0 serão adicionados em seis meses, e mais ainda com a alfa e os relatórios de bugs dos testadores. Cada um desses testes passa pelo caminho descrito em “O dia a dia do QA”. A bolsa do engenheiro de QA paga esse trabalho. Se houver mais testes, o restante do dinheiro arrecadado e a reserva podem pagar mais horas de QA.

Orçamento para seis meses

Seis meses de reforma custam cerca de US$ 18.402, ou seja, US$ 1.598 a menos que a meta da campanha, de US$ 20.000. O restante pode ficar na reserva para o crescimento dos PRs ou pagar mais horas de QA. Cerca de 83% do dinheiro vai para o trabalho das pessoas; nuvem e agente de IA juntos custam cerca de 7%.

Item	Como foi calculado	Por mês	Em 6 meses
Bolsa de engenheiro de QA, meio período	plano do projeto	US$ 2.133	US$ 12.798
Configuração do QA para PRs: início após aprovação, VMs temporárias, relatório no PR e no firebirdtest.com	uma vez	—	US$ 1.500
Desenvolvimento do agente de análise inicial: integração com o GitHub, regras do projeto	uma vez	—	US$ 1.000
Reserva: discos e tráfego na nuvem, aumento de preços, crescimento dos PRs	5% da meta	—	US$ 1.000
Agente de IA: assinatura de serviço de IA	assinatura fixa	US$ 100	US$ 600
Taxas de pagamento	4% da meta	—	US$ 800
Execuções Windows para PRs: Azure D4s v5 Windows	subconjunto obrigatório e suíte completa por classe de PR, +20% para repetições	US$ 50	US$ 299,26
Execuções Linux: DigitalOcean General Purpose 16 GB	execuções de PRs por classe, +20% para repetições, e OLTP-EMUL noturno para 5.0 e 6.0	US$ 37	US$ 224,86
Ampliação dos testes para o 6.0 e maior intensidade: Linux e Windows	builds alfa e beta, mais PRs, crescimento da suíte, +20% para repetições	US$ 25	US$ 150,14
Armazenamento de logs, crash dumps e bancos: DigitalOcean Spaces	250 GB e 1 TB de tráfego	US$ 5	US$ 30
Total			US$ 18.402,26

Como calculamos as execuções. Execuções de PRs na nuvem: 127 PRs previstos, por classe de complexidade, com o subconjunto obrigatório a cada push e a suíte completa antes do merge de PRs grandes; os detalhes estão em “Quanto custa o QA para PRs em seis meses”. A linha do Linux também inclui o OLTP-EMUL noturno para 5.0 e 6.0 nos dias com commits: cerca de 24 medições por mês, US$ 47,25 em seis meses. A ampliação para o 6.0 é uma linha separada: US$ 78,18 no Linux e US$ 71,95 no Windows; veja “Ampliação dos testes para o 6.0 e maior intensidade”. As execuções noturnas da suíte de testes continuam nos servidores da IBSurgeon e servem de base de comparação.

O agente de IA cabe em US$ 100 por mês. A análise de um PR (cerca de 200 mil tokens de entrada e 10 mil de saída) custa cerca de US$ 1, mesmo no modelo mais poderoso. Isso dá cerca de US$ 80 por mês: uma análise de cada novo PR e outra depois das atualizações. Com mais PRs depois da alfa, cerca de US$ 90.

O valor da bolsa, US$ 2.133 por mês, segue o plano do projeto. As linhas de nuvem foram calculadas com os preços atuais e os tempos reais de execução. Para o subconjunto obrigatório, que ainda será selecionado, usamos o tempo-alvo de 1 hora por sistema operacional.

Financiamento coletivo para melhorar o QA

O primeiro passo da reforma já começou: em 8 de outubro de 2026, a Firebird Foundation anunciou uma campanha de financiamento coletivo para melhorar o QA. A meta é arrecadar mais US$ 20.000 em seis meses.

O dinheiro vai para duas áreas:

o tempo dos engenheiros de QA;
máquinas virtuais para as execuções de QA, principalmente para os testes de desempenho.

No lançamento, em 8 de outubro de 2026, 93 pull requests abertos aguardavam verificação e testes de QA. A regra do projeto não muda: nenhuma mudança entra sem revisão e testes. Doações de qualquer valor são aceitas na página da campanha.

O que você ganha e como ajudar

Investir em QA é um seguro para todos que guardam dados no Firebird. Um bug encontrado antes do lançamento custa horas de trabalho de um engenheiro. Um bug que passa despercebido custa tempo de parada e perda de dados para milhares de usuários.

O que usuários e patrocinadores ganham:

regressões aparecem no próprio PR, antes do merge, e não na manhã seguinte;
versões estáveis dos branches 3.0–5.0 e do futuro 6.0, sem regressões nem lentidão;
um caminho mais rápido do relatório de bug até a correção, porque a verificação deixa de ser o gargalo;
a possibilidade de aceitar com segurança mais mudanças externas, inclusive as preparadas com IA;
transparência: os resultados de todas as execuções continuam públicos no firebirdtest.com, e haverá um relatório de gastos.

Como ajudar:

Apoie a campanha de financiamento coletivo do QA com qualquer valor. É a forma mais direta de ajudar a reforma do QA.
Apoie o projeto pela Firebird Foundation, uma vez ou com assinatura (Associate: €100 por ano, Partner: €400 por ano).
Torne-se um patrocinador corporativo: as condições são discutidas individualmente com a Firebird Foundation.
Ofereça recursos ou créditos de nuvem na DigitalOcean, no Azure ou na AWS para as máquinas de teste.
Ajude com pessoas: designe um engenheiro para verificar PRs ou escrever testes no firebird-qa.

Fontes

Os dados de issues e pull requests foram calculados para o repositório FirebirdSQL/firebird: número de PRs e issues pela GitHub Search API, por data de criação; autores, tamanho dos PRs e número de iterações pelo histórico dos branches refs/pull; classes de PR a partir de 214 PRs em 12 meses; a fatia de commits diretos pelo histórico do master. O número de testes e seu crescimento vêm do histórico do repositório firebird-qa; tempos e frequência de execução vêm dos relatórios do firebirdtest.com. Dados de 9 de outubro de 2026.