Bellacosa Mainframe e o mago dos Testes de Software

☕ Um Café no Bellacosa Mainframe

🎩 Mandrake e o Grande Espetáculo dos Testes de Software

Manual Testing, STLC, Test Cases, Test Data, defeitos, regressão e a arte de descobrir que o sistema nunca fez exatamente aquilo que jurava fazer

“Senhoras e senhores, observem atentamente. O programa funciona. Agora começa o truque.”

Há algo profundamente mágico no desenvolvimento de software.

Um programador recebe requisitos, transforma ideias em código, compila aquilo, executa o programa e, finalmente, a tela responde:

PROCESS COMPLETED SUCCESSFULLY
RETURN CODE = 0000

A plateia aplaude.

O gerente respira aliviado.

O desenvolvedor fecha o notebook.

E, sentado discretamente na primeira fila, Mandrake não aplaude.

Ele observa.

Porque todo mágico conhece uma regra fundamental:

aquilo que você vê não necessariamente corresponde ao que realmente aconteceu.

E talvez essa seja uma das melhores maneiras de compreender Software Testing.

O tester profissional não está tentando provar que o programa funciona.

Está tentando descobrir em quais circunstâncias ele deixa de funcionar.

É aí que começa nosso espetáculo.

🎩 ATO I — O programa que jurava estar funcionando

Imagine um pequeno programa COBOL:

IF SALDO >= VALOR-COMPRA
    SUBTRACT VALOR-COMPRA FROM SALDO
    MOVE 'APROVADA' TO STATUS-COMPRA
ELSE
    MOVE 'NEGADA' TO STATUS-COMPRA
END-IF.

Executamos:

SALDO        = 1000
VALOR-COMPRA = 100

Resultado:

STATUS = APROVADA
SALDO  = 900

Fantástico.

O programa funciona!

Mandrake levanta uma sobrancelha.

— Funciona?

Experimentemos então:

SALDO = 1000
VALOR-COMPRA = 1000

Funciona.

Agora:

SALDO = 1000
VALOR-COMPRA = 1001

Negada.

Muito bem.

Mas Mandrake continua:

VALOR-COMPRA = 0

Depois:

VALOR-COMPRA = -100

Depois:

VALOR-COMPRA = 999999999999999

Depois uma transação duplicada.

Depois duas transações simultâneas.

Depois Db2 indisponível.

Depois MQ demora 30 segundos para responder.

Depois o programa sofre ABEND entre o débito e o COMMIT.

Depois o mesmo arquivo é submetido novamente pelo scheduler.

De repente, aquele simples:

IF SALDO >= VALOR-COMPRA

transformou-se numa investigação.

Bem-vindo ao teste de software.

O próprio currículo atual do ISTQB coloca os fundamentos, testes ao longo do ciclo de desenvolvimento, testes estáticos, técnicas de teste, gerenciamento de riscos, defeitos e ferramentas dentro da formação básica do profissional. Ou seja: testar está muito além de simplesmente executar uma tela e verificar se apareceu a mensagem correta. (ISTQB)

🪄 ATO II — QA, QC e Testing: três truques diferentes

Nas anotações que analisamos aparecem três conceitos importantes:

Quality Assurance, Quality Control e Testing.

Podemos imaginá-los no teatro de Mandrake.

QA — Quality Assurance tenta impedir que o truque seja preparado de maneira errada.

Pergunta:

Nosso processo permite produzir software de qualidade?

QA olha para padrões, processos, revisões, métodos, critérios e prevenção.

QC — Quality Control examina aquilo que foi produzido.

Pergunta:

Este produto possui a qualidade esperada?

E finalmente temos Testing.

O tester coloca o produto diante dele e pergunta:

O que acontece se eu fizer isto?

E então começa a puxar as cortinas.

Mas há uma sutileza importante: testing não significa apenas executar programas. O processo moderno também inclui testes estáticos, como revisão de requisitos, documentação, código e outros artefatos antes mesmo da execução do software. Isso aparece explicitamente no CTFL atual. (ISTQB)

Essa é uma das grandes mágicas econômicas da engenharia de software:

encontrar um problema antes de ele virar código.

🔮 ATO III — Error → Defect → Failure

Mandrake coloca três cartas sobre a mesa:

ERROR
DEFECT
FAILURE

Parecem semelhantes.

Não são.

Imagine que alguém escreve um requisito:

Clientes com saldo >= valor da compra
podem realizar a transação.

O programador interpreta errado e escreve:

IF SALDO > VALOR-COMPRA

em vez de:

IF SALDO >= VALOR-COMPRA

O engano humano está na origem.

Esse engano produz um defeito no software.

Quando alguém possui:

SALDO = 100
COMPRA = 100

e o sistema responde:

TRANSACTION DECLINED

temos a manifestação observável do problema: uma falha.

Portanto, conceitualmente podemos imaginar:

ERRO HUMANO
     ↓
DEFEITO INTRODUZIDO
     ↓
CONDIÇÃO ESPECÍFICA
     ↓
EXECUÇÃO
     ↓
FALHA OBSERVÁVEL

E aqui existe um princípio precioso.

Um defeito pode permanecer escondido durante anos.

Ele somente aparece quando determinadas condições o ativam.

O código pode ter sido executado milhões de vezes sem problema.

Até que chega:

29/02

ou:

31/12 23:59:59

ou um campo com valor máximo.

Ou um registro duplicado.

Ou alguém finalmente passa pelo caminho lógico esquecido.

O coelho sempre esteve dentro da cartola.

Apenas ninguém havia olhado direito.

🎭 ATO IV — SDLC: preparando o palco

Antes do espetáculo existe toda uma produção.

No desenvolvimento clássico temos algo semelhante a:

REQUISITOS
    ↓
DESIGN
    ↓
DESENVOLVIMENTO
    ↓
TESTES
    ↓
DEPLOYMENT
    ↓
MANUTENÇÃO

Isso é uma representação simplificada do Software Development Life Cycle — SDLC.

Mas cuidado com uma ilusão muito comum:

CODING → TESTING

pode sugerir que testing começa depois da programação.

Em engenharia moderna isso é uma simplificação perigosa.

Testes podem começar no requisito.

Mandrake recebe:

“O sistema deverá responder rapidamente.”

Ele imediatamente pergunta:

Quanto é rapidamente?

200 milissegundos?

Dois segundos?

Dez?

Sob qual volume?

Com quantos usuários?

Em qual infraestrutura?

Perceba o truque.

Acabamos de testar um requisito sem executar uma única linha de código.

Essa integração entre testing e diferentes modelos de desenvolvimento é justamente parte da abordagem atual do CTFL, que considera Waterfall, Agile, DevOps e Continuous Delivery. (ISTQB)

🪄 ATO V — Waterfall, V-Model, Iterative, Incremental e Spiral

As anotações apresentam vários modelos.

No Waterfall, as etapas parecem uma escada:

Requirements
      ↓
Design
      ↓
Development
      ↓
Testing
      ↓
Deployment

É fácil de compreender e administrar quando requisitos são relativamente estáveis.

O problema aparece quando descobrimos tarde que o requisito inicial estava errado.

O V-Model melhora a conversa entre desenvolvimento e teste.

De um lado:

Requirements
System Design
Architecture
Coding

Do outro:

Acceptance Testing
System Testing
Integration Testing
Component Testing

A ideia essencial é poderosa:

cada nível de construção deve possuir alguma forma correspondente de verificação ou validação.

Já abordagens iterativas e incrementais quebram a entrega em pedaços menores.

Mandrake prefere pequenos truques verificáveis a esperar dois anos pelo desaparecimento completo do elefante.

E o Spiral Model acrescenta explicitamente algo fundamental:

risco.

Quanto maior o risco, maior deve ser nossa atenção.

Isso nos conduz ao Risk-Based Testing.

Um botão que altera a cor de um avatar e uma rotina que liquida R$ 500 milhões não deveriam receber exatamente a mesma prioridade de testes.

Probabilidade × impacto muda completamente a estratégia.

O gerenciamento de riscos também está explicitamente presente no currículo contemporâneo do ISTQB. (ISTQB)

🎩 ATO VI — STLC: o espetáculo dentro do espetáculo

Se SDLC organiza o desenvolvimento, o Software Testing Life Cycle organiza o trabalho de testing.

Uma representação didática é:

Requirement Analysis
        ↓
Test Planning
        ↓
Test Case Development
        ↓
Environment Setup
        ↓
Test Execution
        ↓
Defect Reporting
        ↓
Test Closure

Mas não devemos imaginar isso obrigatoriamente como uma ferrovia em que o trem nunca volta.

Na prática:

Requirement
     ↓
Test
     ↓
Defect
     ↓
Requirement reconsidered
     ↓
Code changed
     ↓
New test
     ↓
Regression

O próprio ISTQB observa que os níveis de teste podem se sobrepor temporalmente em modelos iterativos. (ISTQB)

Testing é muito mais uma espiral de descoberta do que uma simples linha reta.

🃏 ATO VII — Os níveis do teste

Nas anotações encontramos:

Unit
Integration
System
Acceptance

Excelente modelo mental inicial.

Mas aqui Mandrake tira outra carta da manga.

O CTFL atual descreve formalmente cinco níveis:

Component
Component Integration
System
System Integration
Acceptance

(ISTQB)

Isso é particularmente interessante para quem trabalha com mainframe.

Imagine:

COBOL PROGRAM
     ↓
Db2
     ↓
CICS
     ↓
MQ
     ↓
z/OS Connect
     ↓
API
     ↓
Mobile App

Testar apenas o COBOL não testa o sistema.

Talvez o COBOL esteja perfeito.

Talvez a API esteja perfeita.

Mas:

API JSON
   ↓
z/OS Connect
   ↓
COMMAREA

pode estar convertendo incorretamente:

100.50

para:

Cada componente funciona.

A integração está errada.

Esse é um dos defeitos mais traiçoeiros da computação.

Todos os mágicos fizeram seus truques corretamente.

Mas o espetáculo fracassou.

🪄 ATO VIII — Functional e Non-Functional Testing

Agora Mandrake coloca duas caixas no palco.

Na primeira:

O QUE O SISTEMA FAZ?

Na segunda:

COMO O SISTEMA FAZ?

A primeira nos conduz ao Functional Testing.

Exemplo:

COMPRA = R$ 100
LIMITE = R$ 500

Esperado:

APROVADA

Estamos verificando uma regra funcional.

Mas suponha que a autorização leve:

37 segundos

Funcionalmente está correta.

Operacionalmente talvez seja desastrosa.

Entramos então no Non-Functional Testing:

performance, segurança, usabilidade, confiabilidade, escalabilidade, compatibilidade, acessibilidade e outras características de qualidade.

O CTFL atual trata tipos de teste como grupos de atividades ligados a características específicas e observa que eles podem aparecer em diferentes níveis de teste. (ISTQB)

Ou seja:

nível e tipo são dimensões diferentes.

Essa distinção vale ouro.

🧙 ATO IX — Black Box: Mandrake não quer saber como funciona

Temos uma máquina.

Entrada:

AGE = 30

Saída:

ACCEPTED

Mandrake não vê o código.

Ele conhece apenas a especificação:

18 <= AGE <= 60

Podemos então usar Equivalence Partitioning.

Em vez de testar todos os números possíveis, dividimos o universo:

< 18       INVALID
18..60     VALID
> 60       INVALID

Selecionamos representantes:

10
30
70

Três testes cobrem conceitualmente três classes.

É uma maneira elegante de reduzir uma quantidade praticamente infinita de possibilidades.

🎩 ATO X — Boundary Value Analysis: o mágico encontra um erro nas próprias anotações

E aqui acontece algo maravilhoso.

Temos:

IDADE PERMITIDA = 18 até 60

Uma análise de fronteira típica poderia testar:

Porque bugs adoram morar nas fronteiras:

<
<=
>
>=

Mas uma das imagens das nossas próprias anotações apresenta a sequência:

17  18  19  60  61

e ainda associa incorretamente os rótulos próximos ao máximo.

🎩 ABRACADABRA!

Encontramos um defeito num material que ensina como encontrar defeitos.

Esse será nosso Easter Egg.

🐇 Easter Egg Bellacosa #03:17: o primeiro bug do curso estava escondido justamente no capítulo sobre Boundary Value Analysis.

Não poderia existir demonstração melhor.

O tester precisa testar até mesmo aquilo que lhe ensina a testar.

🃏 ATO XI — Decision Table

Agora imagine autorização de cartão:

Cartão ativo?
Senha correta?
Limite disponível?
Suspeita de fraude?

Temos combinações.

Ativo	Senha	Limite	Fraude	Resultado
S	S	S	N	Aprovar
N	S	S	N	Negar
S	N	S	N	Negar
S	S	N	N	Negar
S	S	S	S	Revisar/Negar

Isso é perfeito para Decision Table Testing.

Em COBOL poderíamos encontrar:

EVALUATE TRUE
    WHEN CARTAO-BLOQUEADO
         PERFORM NEGAR-COMPRA

    WHEN SENHA-INVALIDA
         PERFORM NEGAR-COMPRA

    WHEN SEM-LIMITE
         PERFORM NEGAR-COMPRA

    WHEN SUSPEITA-FRAUDE
         PERFORM ANALISAR-COMPRA

    WHEN OTHER
         PERFORM APROVAR-COMPRA
END-EVALUATE.

Cada WHEN é praticamente Mandrake dizendo:

“Mostre-me sua próxima carta.”

🔮 ATO XII — State Transition

Existem sistemas nos quais o resultado depende não apenas da entrada atual, mas do estado anterior.

Cartão:

ACTIVE
  ↓
3 senhas erradas
  ↓
BLOCKED

Agora tente a senha correta.

O sistema deveria desbloquear automaticamente?

Provavelmente não.

Então temos:

STATE + EVENT → NEW STATE

Isso é State Transition Testing.

Em mainframe isso aparece por toda parte:

NEW
AUTHORIZED
CAPTURED
SETTLED
REVERSED
CANCELLED

Uma transação SETTLED talvez não possa simplesmente voltar para NEW.

O tester procura transições permitidas e, principalmente, transições proibidas.

🪄 ATO XIII — Error Guessing: a experiência entra no palco

Depois de alguns anos trabalhando com sistemas, desenvolvemos algo curioso.

Vemos:

PIC 9(5)

e imediatamente pensamos:

99999?
00000?
SPACE?
-1?
100000?

Vemos:

DIVIDE A BY B

e pensamos:

B = ZERO?

Vemos:

SQL INSERT

e pensamos:

DUPLICATE KEY?

Vemos arquivo batch:

INPUT-FILE

e perguntamos:

arquivo vazio?
registro truncado?
layout errado?
duplicado?
EBCDIC/ASCII?
campo COMP-3 inválido?

Isso é experiência transformada em técnica.

É o velho programador olhando para a cartola e dizendo:

“Eu conheço esse truque.”

🎭 ATO XIV — O Test Case

Um bom test case deveria permitir que outra pessoa reproduzisse nossa experiência.

Por exemplo:

TC-CARD-017

Objetivo:
Validar compra exatamente no limite disponível.

Precondition:
Cartão ACTIVE
Limite disponível = R$ 1.000

Input:
Compra = R$ 1.000

Expected:
Authorization = APPROVED
Available Limit = R$ 0
Transaction recorded once

Actual:
...

Status:
PASS / FAIL

Repare no detalhe:

Não basta escrever:

Expected = SUCCESS

Precisamos saber o que significa sucesso.

Esse é o conceito do test oracle: de onde vem nossa certeza sobre o resultado esperado?

Pode ser uma regra de negócio, requisito, cálculo independente, especificação, sistema anterior ou conhecimento validado do domínio.

Porque existe uma situação deliciosamente cruel:

o software pode produzir exatamente o resultado descrito no test case e ambos estarem errados.

🧪 ATO XV — Test Data: os objetos escondidos na manga

Um teste maravilhoso com dados ruins continua sendo um teste ruim.

Para idade 18–60 podemos preparar:

VALID
25
30
45

INVALID
-5
70
ABC

BOUNDARY
17
18
19
59
60
61

No mainframe a brincadeira fica muito mais interessante.

Imagine:

05 WS-AMOUNT PIC S9(9)V99 COMP-3.

Mandrake começa imediatamente a imaginar:

ZERO
NEGATIVO
MÁXIMO
CENTAVOS
SINAL INVÁLIDO
PACKED DECIMAL CORROMPIDO
CAMPO TRUNCADO

E alguém na plateia grita:

S0C7!

Exatamente.

Agora estamos conversando.

🏰 ATO XVI — Test Environment

Um teste não acontece no vazio.

Temos:

DEV
 ↓
QA
 ↓
STAGING
 ↓
PRODUCTION

Mas “funcionou em QA” não significa necessariamente:

funcionará em PROD

Talvez QA tenha:

1.000 registros

e produção:

800 milhões.

Talvez QA tenha uma LPAR praticamente ociosa.

Produção possui WLM disputando recursos.

Talvez QA utilize outra configuração de Db2.

Outro RACF.

Outra versão de copybook.

Outra configuração MQ.

Outro timeout.

Outra quantidade de initiators.

Outra definição CICS.

Esse fenômeno possui um inimigo conhecido:

environment drift.

Quanto maior a diferença entre os ambientes relevantes, maior a possibilidade de o teste produzir confiança falsa.

🐇 ATO XVII — Defect Management

Finalmente Mandrake captura o coelho.

Agora precisamos documentá-lo.

Um fluxo possível:

NEW
 ↓
ASSIGNED
 ↓
OPEN
 ↓
IN PROGRESS
 ↓
FIXED
 ↓
RETEST
 ↓
VERIFIED
 ↓
CLOSED

Se ainda falhar:

REOPEN

Mas isso não é uma lei universal.

Cada organização pode possuir seu próprio workflow.

O mesmo vale para:

P0
P1
P2
P3

Aliás, as próprias anotações analisadas usam convenções diferentes em páginas distintas: numa delas P1 aparece como crítico; em outra, P0 é crítico.

Outro pequeno coelho escondido.

Isso demonstra algo importante:

Priority é convenção organizacional.

Já a distinção conceitual é mais importante:

SEVERITY
= qual o impacto do defeito?

PRIORITY
= quão urgentemente queremos resolvê-lo?

Um erro ortográfico na página inicial de um grande banco pode ter baixa severidade técnica e prioridade altíssima.

Um defeito grave em funcionalidade raramente utilizada pode possuir severidade alta e prioridade temporariamente menor.

🔁 ATO XVIII — Retest não é Regression

Mandrake quebra uma carta.

O desenvolvedor cola.

Mandrake verifica a carta.

Isso é confirmation/retest:

O defeito específico foi corrigido?

Mas Mandrake pergunta:

E ao colar esta carta você rasgou outra?

Isso é regression testing.

O currículo atual do ISTQB trata confirmation testing e regression testing como conceitos distintos justamente por essa razão. (ISTQB)

Imagine:

BUG:
cálculo de juros incorreto.

Correção realizada.

Retest:

juros agora corretos.

Excelente.

Regression:

parcelamento?
estorno?
fatura?
pagamento mínimo?
limite?
contabilidade?
extrato?

O bug morreu.

Agora precisamos descobrir se ele levou algum vizinho junto.

🖥️ ATO XIX — Mandrake entra numa LPAR

E aqui nosso espetáculo chega ao território Bellacosa Mainframe.

Mandrake encontra:

JCL
 ↓
COBOL
 ↓
VSAM
 ↓
Db2
 ↓
CICS
 ↓
MQ
 ↓
APIs

E percebe imediatamente que o RC=0000 é apenas o começo.

Um tester de mainframe deveria aprender a procurar evidências em coisas como:

RETURN-CODE
SQLCODE
CICS RESP
RESP2
ABEND CODE
JESMSGLG
JESJCL
JESYSMSG
SYSOUT
CEEDUMP

Imagine um JOB:

STEP01 → SORT
STEP02 → COBOL
STEP03 → Db2
STEP04 → REPORT

O JOB termina:

MAXCC=0000

Tudo certo?

Mandrake responde:

Quantos registros entraram?

1.000.000

Quantos foram processados?

999.998

Quantos foram rejeitados?

Então onde estão dois registros?

🎩 Eis o truque.

🧮 ATO XX — Reconciliation: a mágica que salva dinheiro

Em sistemas financeiros existe uma forma particularmente poderosa de testing:

reconciliação.

Podemos estabelecer invariantes:

INPUT =
PROCESSED +
REJECTED

ou:

SALDO ANTERIOR
+ CRÉDITOS
- DÉBITOS
= SALDO FINAL

Agora imagine:

INPUT      = 10.000
PROCESSED  = 9.997
REJECTED   = 2

Temos:

10.000 ≠ 9.997 + 2

Um registro desapareceu.

Não sabemos ainda onde.

Mas sabemos que há alguma coisa atrás da cortina.

Isso é extraordinariamente importante em cartões, pagamentos, bancos, seguros e processamento batch.

O resultado bonito na tela não basta.

Precisamos provar que os números fecham.

💥 ATO XXI — O teste favorito de Mandrake: quebrar no meio

Agora imagine processamento:

READ TRANSACTION
      ↓
UPDATE ACCOUNT
      ↓
WRITE HISTORY
      ↓
SEND MQ
      ↓
COMMIT

Mandrake desliga alguma coisa exatamente aqui:

UPDATE ACCOUNT
      ↓
       💥

E pergunta:

O que acontece agora?

Rollback?

Commit parcial?

Registro inconsistente?

Mensagem perdida?

Duplicação durante restart?

É aqui que testing deixa de ser simplesmente “clicar na tela”.

Em sistemas críticos precisamos testar:

RESTART
RECOVERY
ROLLBACK
REPROCESSING
DUPLICATE DELIVERY
TIMEOUT
DEADLOCK
PARTIAL FAILURE

Porque produção possui um talento extraordinário para criar condições que ninguém imaginou durante a happy path.

🧙‍♂️ ATO XXII — O S0C7 escondido na cartola

Considere:

05 WS-AMOUNT PIC S9(7)V99 COMP-3.

Tudo funciona durante meses.

Até chegar um registro corrompido.

O programa tenta executar uma operação aritmética.

💥

S0C7

O defeito talvez não esteja exatamente na instrução que sofreu o ABEND.

Pode ter começado muito antes:

arquivo
 ↓
layout incorreto
 ↓
campo deslocado
 ↓
dados inválidos
 ↓
operação decimal
 ↓
S0C7

O tester não pode perguntar apenas:

Onde explodiu?

Precisa perguntar:

Onde começou a cadeia causal que permitiu a explosão?

Isso é pensamento investigativo.

🔐 ATO XXIII — Segurança também faz parte do espetáculo

Suponha:

USER = VAGNER
ROLE = VIEWER

Ele deveria consultar relatório.

Mas consegue alterar registros.

Funcionalmente o botão funciona perfeitamente.

O problema é justamente esse.

Ele não deveria funcionar para aquele usuário.

Portanto testamos:

AUTHENTICATION
       ↓
Quem é você?

AUTHORIZATION
       ↓
O que você pode fazer?

No mundo mainframe isso imediatamente lembra RACF e os controles existentes ao redor de datasets, transações, recursos e identidades.

O verdadeiro teste negativo seria:

Mostre que Vagner consegue acessar aquilo que deve acessar.

e também:

Mostre que Vagner não consegue acessar aquilo que não deve acessar.

A segunda parte frequentemente é mais valiosa.

🤖 ATO XXIV — Manual Testing versus Automation

E chegamos à falsa guerra:

MANUAL
   VS
AUTOMATION

Não existe necessidade dessa guerra.

Automação é fantástica para:

regressão repetitiva
grandes massas
execuções frequentes
CI/CD
comparações
APIs
checks determinísticos

O ser humano continua excelente em:

exploração
investigação
ambiguidade
usabilidade
novos comportamentos
descoberta

A automação executa rapidamente aquilo que alguém ensinou a procurar.

O tester humano pode perguntar:

E se fizermos algo que ninguém colocou no script?

Essa pergunta continua perigosíssima.

O próprio CTFL inclui benefícios e riscos da automação como parte da formação fundamental, em vez de tratá-la como substituta universal do testing humano. (ISTQB)

🔍 ATO XXV — Exploratory Testing: Mandrake abandona o roteiro

Existe ainda uma atividade que merece espaço especial.

Mandrake recebe o sistema sem um roteiro de cinquenta páginas.

Ele começa a explorá-lo.

Aprende enquanto testa.

Testa enquanto aprende.

Observa uma resposta estranha.

Segue aquela pista.

Encontra outra.

Isso é a essência do exploratory testing.

Não significa sair clicando aleatoriamente.

Um bom explorador possui objetivo, conhecimento, heurísticas, observação e documentação.

É jazz.

Não ausência de música.

📊 ATO XXVI — “97% dos testes passaram!”

Mandrake olha para o dashboard:

10.000 TEST CASES

PASS = 9.700
FAIL = 300

PASS RATE = 97%

O gerente comemora.

Mandrake pergunta:

Quais foram os 300 que falharam?

Resposta:

Transferência bancária
Autorização
Liquidação
Recovery
Login administrativo

Então os 97% significam quase nada.

Métricas sem contexto também fazem ilusionismo.

Podemos possuir:

99,9% PASS

e ainda assim ter um sistema impossível de colocar em produção.

Por isso testing baseado em risco é tão importante.

Não contamos apenas testes.

Precisamos saber o que eles protegem.

🎩 ATO XXVII — O verdadeiro Testing Pyramid

A famosa pirâmide costuma aparecer assim:

           /\
          /UI\
         /----\
        / API  \
       /--------\
      / UNIT     \
     /____________\

Muitos testes pequenos e baratos próximos aos componentes.

Menos testes grandes e caros no topo.

É uma heurística útil.

Não uma lei da física.

Em mainframe talvez nossa realidade tenha:

UNIT / COMPONENT
       ↓
BATCH PROGRAM
       ↓
DB2 / VSAM
       ↓
CICS / MQ
       ↓
SYSTEM INTEGRATION
       ↓
END-TO-END

A arquitetura deveria orientar a estratégia.

Não um desenho bonito encontrado num PowerPoint.

🕯️ ATO XXVIII — Shift Left e Shift Right

Mandrake agora realiza seu último truque.

Move testing para a esquerda:

REQUIREMENT
DESIGN
CODE
BUILD
TEST
DEPLOY

Shift Left significa encontrar problemas mais cedo.

Revisar requisitos.

Testar regras.

Executar análise estática.

Criar testes junto com desenvolvimento.

Mas Mandrake também olha para a direita.

Depois do deployment podemos aprender com:

monitoring
telemetry
synthetic transactions
canary releases
observability
production feedback

Isso é parte da mentalidade de Shift Right.

Não significa transformar produção num laboratório irresponsável.

Significa reconhecer uma realidade:

nenhum ambiente reproduz completamente o mundo real.

🧠 ATO FINAL — O tester não caça bugs; caça confiança falsa

Depois de tudo isso, podemos resumir o aprendizado das anotações numa transformação mental.

O iniciante olha para:

INPUT → PROGRAM → OUTPUT

O tester começa a enxergar:

                 REQUIREMENT
                     ↓
INPUT → VALIDATION → BUSINESS RULE
                     ↓
                   DATA
                     ↓
                INTEGRATION
                     ↓
                 OUTPUT
                     ↓
              SIDE EFFECTS
                     ↓
              AUDIT / LOG
                     ↓
                RECOVERY

E pergunta:

O requisito está certo?

O dado está certo?

A fronteira está certa?

A regra está certa?

O resultado está certo?

O banco foi atualizado?

A mensagem foi enviada?

A mensagem foi enviada uma vez?

O rollback funciona?

O restart duplica alguma coisa?

O usuário possui autorização?

A evidência é suficiente?

Outro componente foi quebrado?

O que acontece sob carga?

O que acontece quando algo falha?

Esse é o momento em que Manual Testing deixa de ser uma coleção de definições e passa a ser engenharia.

O ISTQB moderno reforça exatamente essa amplitude: testing dentro do ciclo de desenvolvimento, técnicas black-box, white-box e baseadas em experiência, testes estáticos, risco, defeitos e automação fazem parte de um mesmo corpo de conhecimento. (ISTQB)

Mandrake finalmente fecha a cartola.

O gerente pergunta:

— Então conseguimos provar que o sistema não possui bugs?

Mandrake sorri.

Não.

Mas conseguimos algo muito mais útil.

Descobrimos onde procurá-los, quais riscos realmente importam, quais evidências sustentam nossa confiança e, principalmente, aprendemos a nunca confundir:

RC=0000

com:

TUDO ESTÁ CERTO.

Porque no mainframe, como num espetáculo de mágica, o perigo não está necessariamente naquilo que vemos acontecer.

Está também naquilo que aconteceu atrás da cortina enquanto todos estavam olhando para outro lado.

E às 03:17, quando aquele JOB que funcionou perfeitamente durante 4.327 execuções finalmente encontrar o registro que ninguém imaginou testar...

...talvez algum velho tester sorria diante do SYSOUT e diga:

“Eu sabia que havia um coelho nessa cartola.” 🎩🐇

ISTQB Certified Tester Foundation Level 4.0

Translate

sexta-feira, 8 de novembro de 2019