 |
| Bellacosa Mainframe e os testes em software mainframe |
☕
Um Café no Bellacosa MainframeO Mágico de Oz Entra no CPD — O Dia em que Dorothy Descobriu que “Funcionou na Minha Máquina” Não Vale como Evidência de Teste
Ou: como Requirements, Unit Test, Integration, System Test, UAT, Test Data, Boundary Value, Bug Report, Severity, Priority, Regression e um programador COBOL iniciante seguiram pela Estrada de Tijolos Amarelos até descobrir que, atrás da cortina, qualidade não é mágica — é método
Há uma cena clássica em O Mágico de Oz: Dorothy e seus companheiros atravessam perigos, florestas, campos de papoulas, bruxas e criaturas estranhas para finalmente chegar à Cidade das Esmeraldas.
Todos esperam encontrar um ser extraordinário.
Uma entidade quase divina.
O Grande e Poderoso Oz.
Então Toto puxa uma cortina.
E atrás dela existe apenas um sujeito comum operando alavancas.
No mundo dos testes de software acontece algo parecido.
Durante muito tempo, especialmente para quem começa a programar, parece existir uma espécie de magia chamada:
“QA testou.”
O programador entrega o código.
Alguém misterioso em outro andar executa alguma coisa.
Alguns dias depois chega um chamado:
“Bug encontrado.”
E então começa o ritual.
— Aqui funciona.
— Em QA não.
— Qual ambiente?
— QA.
— Qual massa?
— A massa de QA.
— Qual erro?
— Deu erro.
Nesse momento, Toto deveria entrar no CPD e puxar a cortina.
Porque software testing não é mágica.
Não há fumaça.
Não há espelhos.
E, principalmente, não existe prestidigitação capaz de transformar código não testado em software confiável.
Existe método.
Existe planejamento.
Existe risco.
Existe evidência.
Existe engenharia.
E é exatamente isso que vamos explorar.
Prólogo — Dorothy recebe seu primeiro programa COBOL
Imagine Dorothy recém-contratada como programadora COBOL.
Ela recebe uma especificação:
Clientes com idade entre 18 e 60 anos podem aderir ao produto.
Ela escreve:
IF WS-IDADE >= 18 AND WS-IDADE <= 60
MOVE 'S' TO WS-ELEGIVEL
ELSE
MOVE 'N' TO WS-ELEGIVEL
END-IF
Compila.
Executa com:
IDADE = 30
Resultado:
ELEGIVEL = S
Dorothy sorri.
— Pronto.
O Espantalho, representando aquele colega que ainda procura um cérebro para requisitos, pergunta:
— Você testou?
— Sim.
— Quantas idades?
— Uma.
O Homem de Lata olha para o código, sente uma pequena dor no coração que ainda não possui e pergunta:
— E 18?
Dorothy testa.
Funciona.
O Leão Covarde pergunta:
— E 60?
Funciona.
Toto late.
Alguém resolve testar:
17
19
59
61
-1
999
ABC
vazio
E eis que começa a verdadeira história.
Porque testar não é escolher um exemplo que funciona.
Testar é procurar sistematicamente condições nas quais a solução pode deixar de funcionar.
Esse é o primeiro tijolo amarelo da nossa estrada.
1. O que é software testing de verdade?
Software testing é o processo de avaliar um software para verificar se ele atende aos requisitos esperados e para identificar defeitos, comportamentos incorretos e riscos.
Uma definição parece simples.
Mas existe um detalhe quase filosófico:
Testing não prova que software não possui defeitos.
Testing encontra evidências de que determinados comportamentos funcionam — ou não funcionam — sob determinadas condições.
Imagine um programa com bilhões de combinações possíveis de entrada.
Você jamais testará todas.
Portanto testing é também uma disciplina de amostragem inteligente de riscos.
Um bom tester pensa:
Onde esse negócio provavelmente vai quebrar?
Um excelente programador pensa assim também.
2. QA, QC e Testing — três personagens diferentes na mesma estrada
As notas que a
nalisamos fazem uma distinção importante entre Quality Assurance, Quality Control e Testing.
QA — Quality Assurance
QA olha predominantemente para o processo.
Pergunta:
Estamos trabalhando de uma maneira que reduz a chance de produzir defeitos?
Isso envolve:
padrões;
processos;
revisões;
métodos;
governança;
critérios;
documentação.
QA tenta evitar que Dorothy saia caminhando pela estrada errada antes mesmo da viagem começar.
QC — Quality Control
Quality Control olha para o produto entregue.
Pergunta:
Aquilo que foi construído está correto?
É inspeção e controle.
Testing
Testing é a atividade prática de exercitar o sistema buscando evidências.
Podemos resumir:
QA → evitar defeitos
QC → detectar defeitos no produto
Testing → executar verificações sobre o sistema
Não são exatamente sinônimos.
3. Error, defect, bug e failure — a família que ninguém quer conhecer
Aqui temos outra distinção extremamente útil.
Imagine que Dorothy deveria escrever:
IF SALDO >= VALOR
Mas escreveu:
IF SALDO > VALOR
Isso é um erro humano.
O erro gerou um problema no código.
Esse problema é um defect.
Quando o cliente possui saldo exatamente igual ao valor do saque e o sistema rejeita a operação, temos uma failure, isto é, a manifestação observável do defeito.
Simplificando:
ERROR
↓
DEFECT
↓
FAILURE
“Bug” é frequentemente usado como sinônimo de defect.
Curiosidade: a história popular associa o termo bug ao inseto encontrado no Harvard Mark II em 1947. Mas engenheiros já usavam “bug” para falhas técnicas décadas antes. Grace Hopper ajudou a tornar o episódio famoso, não a inventar a palavra.
Easter egg mainframe número 1: qualquer programador que já caçou um abend às três da manhã sabe que alguns bugs realmente parecem vivos.
4. SDLC — o software não começa no COBOL
Outro erro clássico do iniciante é imaginar:
Especificação
↓
COBOL
↓
Produção
Na realidade, existe um ciclo maior, o Software Development Life Cycle.
De maneira simplificada:
Requirements
↓
Design
↓
Development
↓
Testing
↓
Deployment
↓
Maintenance
O código é apenas uma parte.
Em mainframe isso é ainda mais evidente.
Você pode alterar 20 linhas COBOL que dependem de:
Copybook;
JCL;
Db2;
VSAM;
CICS;
MQ;
RACF;
scheduler;
arquivos recebidos;
programas chamados;
programas chamadores.
O código parece local.
O impacto pode ser interestelar.
5. Waterfall, V-Model, Iterative, Incremental, Spiral e Prototype
As imagens apresentam vários modelos de desenvolvimento.
Não precisamos transformar isso numa aula acadêmica infinita, mas vale entender o espírito.
Waterfall
Modelo sequencial.
Requirement
↓
Design
↓
Coding
↓
Testing
↓
Deployment
Funciona bem quando requisitos são estáveis.
Problema:
Se você descobre no final que o requisito estava errado, o custo da correção pode ser enorme.
V-Model
Esse merece atenção especial.
De um lado:
Requirements
System Design
Architecture
Module Design
Coding
Do outro:
Unit Test
Integration Test
System Test
Acceptance Test
A ideia central é espetacular:
o teste correspondente deve ser pensado junto com a etapa que o originou.
Por exemplo:
Business Requirement ←→ Acceptance Test
System Design ←→ System Test
Architecture ←→ Integration Test
Module Design ←→ Unit Test
Isso antecipa o conceito moderno de Shift Left.
Ou seja:
Não espere terminar tudo para pensar em qualidade.
6. STLC — a estrada de tijolos amarelos dos testes
O Software Testing Life Cycle normalmente passa por etapas semelhantes a:
Requirement Analysis
↓
Test Planning
↓
Test Case Development
↓
Test Environment Setup
↓
Test Execution
↓
Defect Reporting
↓
Test Closure
Parece burocrático.
Mas cada etapa responde uma pergunta.
Requirement Analysis
O que precisamos verificar?
Test Planning
Como vamos verificar?
Test Case Development
Quais cenários serão usados?
Environment Setup
Onde vamos executar?
Test Execution
O que realmente aconteceu?
Defect Management
Como registrar e acompanhar problemas?
Closure
Quando podemos declarar que o ciclo terminou?
Isso é tudo menos prestidigitação.
7. A primeira grande armadilha: requisitos ambíguos
Imagine a regra:
Cliente pode transferir até R$ 10.000 por dia.
Parece clara.
Não é.
Um tester imediatamente pergunta:
Por CPF ou conta?
Dia civil ou últimas 24 horas?
PIX e TED compartilham limite?
Transferência agendada conta quando é criada ou executada?
Limite inclui tarifa?
R$ 10.000 exatamente é permitido?
Cliente PJ possui a mesma regra?
Aí percebemos uma coisa linda:
um bom tester encontra defeitos antes do software existir.
Ele encontra defeitos no requisito.
E defeito encontrado cedo costuma custar muito menos.
8. Entry Criteria e Exit Criteria
Outro conceito essencial.
Entry Criteria
Antes de começar os testes, certas condições precisam estar atendidas.
Por exemplo:
build disponível
ambiente ativo
database carregado
massa pronta
requisitos aprovados
Se o Db2 está indisponível, o teste talvez fique:
BLOCKED
Isso é diferente de:
FAILED
O sistema não falhou.
O teste não pôde ser executado.
Exit Criteria
Também precisamos definir quando parar.
Exemplo:
100% testes críticos executados
0 blockers abertos
0 critical defects abertos
95% dos casos aprovados
riscos residuais aceitos
Sem isso, “terminamos os testes” significa apenas:
Alguém cansou.
9. Pirâmide de testes — não coloque tudo no topo
A pirâmide clássica sugere:
E2E
Integration
Unit Unit Unit
Ou:
Por quê?
Testes unitários tendem a ser:
rápidos;
baratos;
estáveis;
fáceis de automatizar.
Testes E2E geralmente são:
Imagine testar um PIX apenas através do aplicativo final.
Se falhar, onde está o problema?
Mobile?
API?
Gateway?
MQ?
CICS?
COBOL?
Db2?
Rede?
RACF?
Agora imagine testes menores cobrindo cada camada.
Diagnóstico fica muito mais fácil.
10. Unit Testing — teste a peça antes da máquina inteira
Em COBOL, uma unidade pode ser um programa, rotina ou lógica isolada.
Exemplo:
COMPUTE WS-JUROS =
WS-CAPITAL * WS-TAXA / 100
Teste:
Capital = 1000
Taxa = 10
Esperado = 100
Depois:
Capital = 0
Taxa = 10
Esperado = 0
Depois:
Taxa = 0
E assim por diante.
O objetivo é testar a lógica sem depender do universo inteiro.
11. Integration Testing — onde os monstros geralmente moram
Integração é onde módulos conversam.
No mainframe isso pode significar:
COBOL ↔ Db2
COBOL ↔ VSAM
CICS ↔ COBOL
CICS ↔ MQ
MQ ↔ Java
API ↔ z/OS Connect
Muitos defeitos aparecem exatamente nas fronteiras.
Exemplos:
tamanho de campo diferente;
packed decimal interpretado incorretamente;
copybook desatualizado;
encoding ASCII/EBCDIC;
commit inconsistente;
timeout;
JSON mal formado;
campo obrigatório ausente.
Dois módulos podem funcionar perfeitamente isolados e falhar miseravelmente juntos.
O Espantalho chamaria isso de “falta de cérebro”.
Nós chamamos de integração.
12. System Testing
Agora testamos o sistema integrado.
Exemplo bancário:
Login
↓
Consulta saldo
↓
PIX
↓
Autenticação
↓
Débito
↓
Registro
↓
Comprovante
Não estamos mais testando apenas uma rotina COBOL.
Estamos testando comportamento de negócio.
13. Acceptance Testing e UAT
Aqui entra o usuário ou área de negócio.
A pergunta muda.
QA pergunta:
O sistema atende à especificação?
Negócio pergunta:
Isso serve para trabalhar?
Um sistema pode estar tecnicamente correto e operacionalmente ser um desastre.
Por isso UAT é crucial.
Easter egg número 2: Oz pode dizer que a máquina funciona perfeitamente. Dorothy ainda precisa descobrir se ela realmente consegue levá-la de volta ao Kansas.
14. Functional Testing — o que o sistema faz?
Functional testing verifica WHAT.
Exemplo:
Usuário correto + senha correta
→ login deve funcionar
Outro:
Saldo = 1000
Saque = 200
→ saldo final = 800
Estamos testando comportamento esperado.
15. Positive e Negative Testing
Positive Testing
Usamos entradas válidas.
idade = 30
Esperamos sucesso.
Negative Testing
Usamos entradas inválidas.
idade = -10
idade = ABC
campo vazio
Aqui existe um ponto muito importante.
O objetivo não é simplesmente provocar erro.
É verificar se o sistema trata o erro corretamente.
Bom software não é aquele que nunca recebe entrada ruim.
É aquele que sabe lidar com ela.
16. Non-functional Testing — quão bem funciona?
Aqui muda tudo.
Functional pergunta:
Faz?
Non-functional pergunta:
Faz bem?
Exemplos:
performance;
segurança;
confiabilidade;
escalabilidade;
usabilidade;
compatibilidade;
acessibilidade.
Login funcionar é funcional.
Login demorar 47 segundos é problema não funcional.
17. Performance, Load, Stress, Spike e Volume
Esses termos frequentemente são confundidos.
Performance Testing
Avalia comportamento de desempenho.
Métricas:
response time
throughput
latency
CPU
memory
I/O
No z/OS podemos acrescentar:
CPU time
elapsed time
service units
EXCP
Db2 getpages
lock waits
CICS response time
WLM behavior
Load Testing
Carga esperada.
Exemplo:
10.000 transações/minuto
Stress Testing
Carga acima do esperado.
Objetivo:
Onde quebra e como quebra?
Spike Testing
Carga sobe abruptamente.
Black Friday é o exemplo perfeito.
Volume Testing
Muito dado.
Uma query maravilhosa com 5 mil registros pode virar carvão com 500 milhões.
18. Security Testing
Segurança não é apenas verificar se o usuário certo entra.
É verificar se o usuário errado fica fora.
Exemplo:
Usuário autorizado → permitido
Usuário não autorizado → negado
No mainframe:
RACF profiles
dataset access
CICS transactions
Db2 privileges
USS permissions
started tasks
Um teste de autorização deve testar allow e deny.
Testar apenas aquilo que deveria funcionar deixa metade da segurança invisível.
19. Black Box Testing
Black box trata o sistema como caixa fechada.
INPUT
↓
SYSTEM
↓
OUTPUT
O tester não precisa conhecer implementação.
Exemplo:
saldo 100
saque 30
esperado 70
Pode existir COBOL, Java, PL/I ou um anão verde calculando lá dentro.
Para black box pouco importa.
20. White Box Testing
Agora conhecemos o código.
Queremos verificar caminhos internos.
Considere:
IF SALDO >= VALOR
IF CONTA-ATIVA = 'S'
PERFORM EFETUAR-SAQUE
END-IF
END-IF
Temos combinações:
saldo suficiente / conta ativa
saldo suficiente / conta inativa
saldo insuficiente / conta ativa
saldo insuficiente / conta inativa
Isso envolve:
statement coverage;
branch coverage;
condition coverage;
path testing.
E aqui vale um alerta:
100% de cobertura não significa ausência de bugs.
21. Equivalence Partitioning — teste representantes
Suponha:
idade válida = 18 até 60
Temos três grandes classes:
<18
18–60
>60
Em vez de testar todos os números, podemos inicialmente testar representantes:
10
30
70
Isso reduz drasticamente quantidade de testes sem jogar cobertura pela janela.
22. Boundary Value Analysis — é nas bordas que os gremlins moram
A técnica favorita de quem já viu muito bug.
Para:
18 ≤ idade ≤ 60
teste:
17
18
19
59
60
61
Por quê?
Porque humanos escrevem:
>
quando deveriam escrever:
>=
E vice-versa.
Aliás, nas próprias notas havia uma inconsistência divertida no exemplo de limite superior.
Um dos quadros rotulava valores máximos de maneira incorreta.
O que nos entrega o melhor easter egg deste artigo:
até uma apostila sobre testes precisa de teste.
Toto aprovou.
23. Decision Table Testing
Excelente para regra de negócio complexa.
Imagine aprovação:
Cliente ativo?
Score bom?
Renda suficiente?
Tabela:
| Ativo | Score | Renda | Aprovar |
|---|
| S | S | S | S |
| S | S | N | N |
| S | N | S | N |
| N | S | S | N |
Isso ajuda a enxergar combinações esquecidas.
24. State Transition Testing
Alguns sistemas têm estados.
Exemplo:
ATIVO
↓
BLOQUEADO
↓
DESBLOQUEADO
↓
CANCELADO
Agora precisamos testar transições.
Pode existir:
ATIVO → BLOQUEADO
válida.
Mas talvez:
CANCELADO → ATIVO
seja proibida.
Isso aparece muito em:
cartões;
contas;
pedidos;
contratos;
tickets;
workflows.
25. Error Guessing — experiência com cicatrizes
Essa técnica parece informal, mas é poderosa.
O tester experiente pensa:
Já vi isso explodir antes.
Então testa:
zero
null
vazio
duplicado
máximo
mínimo
29/02
31/12
arquivo vazio
registro duplicado
caractere especial
É conhecimento acumulado através de incidentes.
O Leão ganha coragem.
O Homem de Lata ganha coração.
O tester ganha trauma produtivo.
26. Test Case — roteiro da investigação
Um caso de teste deve conter coisas como:
ID
Title
Objective
Preconditions
Test Data
Steps
Expected Result
Actual Result
Status
Remarks
Exemplo:
TC-PIX-001
Objetivo:
Validar PIX com saldo suficiente.
Pré-condição:
Conta ativa.
Saldo = 1000.
Entrada:
PIX = 200.
Esperado:
Saldo final = 800.
Transação registrada.
Comprovante emitido.
O segredo está no Expected Result.
27. Nunca teste sem saber o que deveria acontecer
Esse é um erro impressionantemente comum.
O sujeito executa algo e diz:
Vamos ver o resultado.
Isso é experimento exploratório.
Pode ser útil.
Mas não é um caso formal de validação.
Se você não sabe previamente o esperado, como saberá se o resultado está correto?
28. Test Data — massa de teste não é detalhe
Massa de teste determina qualidade do teste.
Pode ser:
válida;
inválida;
limite;
extrema;
normal;
sintética;
mascarada.
Uma coisa importante:
muito dado não significa boa massa.
Um milhão de registros iguais cobre pouco.
Cinquenta registros cuidadosamente escolhidos podem cobrir enorme variedade de risco.
29. Production Data — cuidado com Dorothy carregando o banco inteiro para QA
Copiar produção para teste pode parecer tentador.
Mas pode existir:
CPF;
telefone;
endereço;
cartão;
dados financeiros;
informações pessoais.
Por isso entram:
masking
anonymization
tokenization
synthetic data
Usar dados reais sem proteção pode transformar um projeto de testing em incidente de segurança.
E essa bruxa ninguém quer encontrar.
30. Test Environment — o ambiente também é parte do teste
Um ambiente inclui muito mais que servidor.
Pode envolver:
hardware
software
network
database
tools
data
people
documentation
No mainframe:
LPAR
z/OS
CICS
Db2
MQ
RACF
VSAM
LOADLIB
PROCLIB
JCL
scheduler
TCP/IP
O programa pode estar certo e falhar porque a STEPLIB aponta para versão antiga.
Não é lenda urbana.
É terça-feira.
31. Dev, QA, UAT, Staging, Production
Fluxo comum:
DEV
↓
QA
↓
STAGING
↓
PROD
Empresas reais inventam variações:
DEV
SIT
INT
QA
UAT
PREPROD
PROD
O importante é isolamento, rastreabilidade e controle.
Quanto mais próximo de produção, maior deveria ser a fidelidade do ambiente.
32. Test Execution
Chegamos ao momento em que o teste roda.
Fluxo:
Select Test
↓
Prepare Data
↓
Execute
↓
Compare Expected vs Actual
↓
Report Defect
↓
Update Status
↓
Retest
Estados comuns:
Not Executed
Pass
Fail
Blocked
Skipped
Retest
Fail não é Blocked.
Essa diferença pode evitar uma tarde inteira de reunião inútil.
33. Defect Life Cycle
Bug não nasce e desaparece instantaneamente.
Fluxo típico:
New
↓
Assigned
↓
Open
↓
In Progress
↓
Resolved
↓
Retest
↓
Verified
↓
Closed
Se continuar:
Reopen
“Fixed by developer” não significa “Closed”.
A correção precisa ser verificada.
34. Severity versus Priority
Esse conceito merece tatuagem temporária de projeto.
Severity mede impacto técnico.
Priority mede urgência de correção.
Imagine um erro ortográfico na home.
Severity:
LOW
Mas o CEO vai demonstrar o sistema em dez minutos.
Priority:
CRITICAL
Outro caso:
Bug grave numa funcionalidade que será desativada amanhã.
Severity alta.
Priority talvez baixa.
Portanto:
Severity ≠ Priority
Nas páginas analisadas havia também duas convenções:
P0-P3
e:
P1-P4
Ambas existem no mercado.
A empresa precisa definir sua escala.
35. Bug Reporting — “não funciona” não é relatório
Bug ruim:
Sistema não funciona.
Isso é quase poesia abstrata.
Bug bom:
BUG-5832
Título:
PIX acima de R$5.000 falha após autenticação.
Ambiente:
UAT / Build 2026.09.05
Pré-condição:
Conta ativa com saldo de R$20.000.
Passos:
1. Login
2. PIX
3. Informar R$6.000
4. Confirmar
5. Informar token
Esperado:
Transação aprovada.
Atual:
HTTP 500.
Evidência:
Timestamp 21:43:17
Transaction ID ABC123
Log anexado.
Agora temos material investigativo.
36. Regression Testing — o fantasma dos sistemas antigos
Regression pergunta:
Aquilo que funcionava antes continua funcionando depois da alteração?
Em sistemas legados isso é vital.
Você muda:
3 linhas COBOL
e quebra:
12 rotinas
4 jobs
2 relatórios
1 processo escrito em 1997
Não porque COBOL é ruim.
Porque software grande acumula dependências.
37. Smoke Test — primeiro veja se Oz ainda está respirando
Smoke test é verificação rápida.
aplicação sobe?
login funciona?
Db2 conecta?
transação básica passa?
Se falhar, não execute quatro mil testes.
Você já sabe que a build não está pronta.
38. Sanity Test
Depois de uma alteração pequena, execute testes focados.
Exemplo:
Corrigiu cálculo de juros?
Teste:
juros;
arredondamento;
limites;
casos relacionados.
Depois execute regressão adequada.
39. Manual versus Automation
Manual funciona muito bem para:
exploração;
UX;
ad-hoc;
cenários novos.
Automação é excelente para:
regressão;
repetição;
API;
unit tests;
CI/CD.
Mas automatizar tudo não faz sentido.
Se um caso roda uma única vez:
manual = 5 minutos
automação = 4 horas
Talvez não compense.
Se roda mil vezes:
a matemática muda.
Automação é investimento, não religião.
40. Shift Left — encontre o bug antes da Cidade das Esmeraldas
Shift Left significa trazer testing para mais cedo.
Em vez de:
Code
↓
Testing
pensamos:
Requirement
↓
Testing mindset
Design
↓
Testing mindset
Code
↓
Automated tests
Build
↓
Integration tests
O melhor bug é aquele impedido antes de nascer.
41. Shift Right — produção também fala
Depois do deploy, qualidade continua.
Entram:
observabilidade;
logs;
métricas;
tracing;
synthetic monitoring;
canary releases;
incident analysis.
Produção não é simplesmente o ponto em que testing termina.
É onde o software encontra o mundo real.
E o mundo real é um tester brutal.
42. Testabilidade — software que esconde erro é inimigo
Imagine dois programas.
Programa A:
ERROR 0001
Programa B:
Transaction ABC123 failed.
Reason: customer status = CLOSED.
Module: PGPIX001.
Timestamp: ...
Qual será mais fácil de investigar?
Testabilidade depende de:
logs;
mensagens claras;
interfaces;
observabilidade;
controle de dados;
isolamento.
Design também influencia testing.
43. Cobertura não é prova de perfeição
Imagine:
COMPUTE TOTAL = VALOR / QUANTIDADE
Você executa essa linha em vários testes.
Cobertura:
100%
Mas nunca testa:
QUANTIDADE = 0
Então:
coverage ≠ correctness
Cobertura informa onde passou.
Não prova que todos os comportamentos importantes foram verificados.
44. O paradoxo final
Testing consegue provar facilmente:
Existe um defeito.
Basta encontrar um.
Mas provar:
Não existe nenhum defeito.
é praticamente impossível em sistemas não triviais.
Há combinações de:
dados;
estado;
concorrência;
timing;
ambiente;
integrações;
versões.
Portanto testing trabalha com risco.
A meta não é testar tudo.
É testar as coisas certas com inteligência.
45. Dorothy chega finalmente ao mainframe
Vamos juntar tudo num exemplo.
Requisito:
Permitir aumento do limite diário PIX para R$20.000.
Passo 1 — Requirements
Precisamos esclarecer:
por conta?
por cliente?
dia civil?
inclui agendado?
Passo 2 — Unit
Teste cálculo e validação.
Passo 3 — Equivalence Partitioning
<0
0–20.000
>20.000
Passo 4 — Boundary
-0,01
0
0,01
19.999,99
20.000
20.000,01
Passo 5 — Integration
CICS
COBOL
Db2
MQ
API
Passo 6 — Security
cliente autorizado
cliente bloqueado
conta encerrada
usuário sem permissão
Passo 7 — Performance
10.000 transações/minuto
Passo 8 — Regression
PIX normal
PIX agendado
estorno
comprovante
consulta
Passo 9 — UAT
Negócio confirma comportamento.
Passo 10 — Production
Monitoramos.
Agora sim temos engenharia.
Epílogo — Toto puxa a cortina
Depois de atravessar todo o caminho, Dorothy finalmente encontra o Mágico.
Ela espera aquele ser sobrenatural que garante:
“Software aprovado.”
Toto puxa a cortina.
Atrás dela encontramos:
Requirements
Test Plan
Test Cases
Test Data
Environment
Automation
Execution
Defects
Logs
Metrics
Regression
UAT
Monitoring
Nada de truque.
Nada de fumaça.
Nada de prestidigitação.
A grande revelação é justamente esta:
qualidade não é algo adicionado ao software no fim.
Qualidade começa quando alguém pergunta:
“O que exatamente esse requisito quer dizer?”
Continua quando o programador pergunta:
“O que acontece nos limites?”
Amadurece quando o tester pergunta:
“Como faço isso falhar?”
E chega ao nível profissional quando toda a equipe pergunta:
“Como podemos construir algo que seja verificável, observável, seguro e resistente a mudanças?”
O Espantalho queria um cérebro.
No testing ele descobriu análise.
O Homem de Lata queria coração.
Descobriu que alguém precisa se importar com o usuário que encontra o bug.
O Leão queria coragem.
Descobriu que é preciso coragem para colocar 61, NULL, -1, arquivo vazio e concorrência pesada na aplicação que o desenvolvedor jurou estar pronta.
Dorothy queria voltar para casa.
E o programador COBOL iniciante?
Esse descobre algo ainda mais útil:
há muito tempo ele já possuía uma das melhores ferramentas de testing disponíveis — a capacidade de desconfiar do próprio código.
Porque no fim da Estrada de Tijolos Amarelos existe uma placa pregada na porta do CPD:
NÃO EXISTE
“FUNCIONA NA MINHA MÁQUINA”
COMO STATUS
DE HOMOLOGAÇÃO.
E em letras menores, provavelmente adicionadas por algum sysprog depois de um abend noturno:
Expected Result != Actual Result
abre chamado.
☕ E se Toto aparecer perto da cortina da produção, talvez seja uma boa ideia verificar a STEPLIB antes de culpar a Bruxa Má do Oeste.
