Therac-25: O Bug de Software que Colocou Vidas em Risco e Mudou a História dos Testes de Software

Imagine entrar em um hospital para realizar um tratamento contra o câncer.

Você confia na equipe médica.

Confia na tecnologia.

Confia que cada equipamento foi desenvolvido para salvar vidas.

Agora imagine que, durante esse tratamento, um erro de software faça com que o equipamento aplique uma dose de radiação centenas de vezes maior do que a prevista.

Infelizmente, isso realmente aconteceu.

Entre 1985 e 1987, diversos pacientes sofreram acidentes graves envolvendo o equipamento de radioterapia Therac-25.

Alguns sobreviveram com sequelas permanentes.

Outros perderam a vida.

O caso se tornou um dos maiores exemplos da história sobre como falhas de software podem ter consequências muito além da perda financeira.

Para profissionais de Qualidade de Software (QA), o Therac-25 representa um lembrete permanente de que testar software não é apenas encontrar bugs.

Em muitos casos, é proteger vidas.

O que era o Therac-25?

O Therac-25 era um equipamento de radioterapia desenvolvido pela empresa canadense Atomic Energy of Canada Limited (AECL).

Sua função era aplicar radiação controlada em pacientes com câncer.

Na época, era considerado extremamente moderno.

Ao contrário de equipamentos anteriores, o Therac-25 utilizava muito mais software para controlar seus mecanismos internos.

Essa mudança trouxe benefícios importantes.

Também aumentou significativamente a responsabilidade do software.

Enquanto versões anteriores possuíam diversas proteções físicas (hardware), o Therac-25 passou a confiar quase totalmente nas decisões tomadas pelo programa.

Essa escolha teria consequências devastadoras.

O que aconteceu?

Entre 1985 e 1987 ocorreram diversos acidentes.

Em diferentes hospitais, pacientes relataram uma sensação intensa de queimadura imediatamente após o tratamento.

Alguns descreveram como se tivessem recebido um choque elétrico.

Inicialmente, os operadores acreditaram que o equipamento estava funcionando corretamente.

Afinal, nenhuma mensagem indicava uma falha grave.

Dias depois surgiram queimaduras severas.

Em alguns casos ocorreram lesões irreversíveis.

Investigações posteriores confirmaram que pacientes haviam recebido doses extremamente superiores às prescritas.

Em alguns episódios, estima-se que a radiação tenha ultrapassado centenas de vezes o valor esperado.

Como um bug causou isso?

O problema não era apenas um erro isolado de programação.

Na verdade, vários fatores contribuíram para os acidentes.

Entre eles:

• condições de corrida (race conditions);

• falhas na sincronização entre processos;

• reutilização de código sem validação adequada;

• ausência de mecanismos independentes de segurança;

• excesso de confiança no software.

Em determinadas situações, operadores digitavam comandos muito rapidamente.

Isso fazia com que determinadas rotinas fossem executadas fora da ordem prevista.

O sistema interpretava incorretamente o estado do equipamento.

Como consequência, liberava radiação mesmo quando componentes mecânicos ainda não estavam posicionados corretamente.

O resultado era uma overdose de radiação.

O erro não estava apenas no código

Durante muito tempo acreditou-se que bastava corrigir o software.

Mas as investigações mostraram algo muito mais preocupante.

O processo de desenvolvimento possuía diversas fragilidades.

Entre elas:

• poucos testes independentes;

• documentação insuficiente;

• ausência de revisão formal;

• excesso de confiança na reutilização de código;

• falta de redundância em sistemas críticos.

Hoje sabemos que sistemas que podem colocar vidas em risco precisam ser desenvolvidos considerando múltiplas camadas de proteção.

Nenhuma delas deve depender exclusivamente do software.

O que um QA faria hoje?

Esse é o ponto mais importante para quem trabalha com testes de software.

Se um projeto semelhante fosse desenvolvido atualmente, diversas práticas modernas poderiam reduzir significativamente os riscos.

Entre elas:

Testes de limites

Validar situações extremas.

Entradas inesperadas.

Valores máximos.

Valores mínimos.

Eventos simultâneos.

Testes de concorrência

Avaliar como o sistema responde quando múltiplas ações acontecem praticamente ao mesmo tempo.

Hoje esse tipo de cenário faz parte de diversos sistemas críticos.

Testes de integração

Verificar constantemente se software, sensores e componentes físicos permanecem sincronizados.

Testes de regressão

Toda alteração deve garantir que funcionalidades antigas continuem funcionando corretamente.

Análise de riscos

Nem toda funcionalidade possui o mesmo impacto.

Quando vidas estão envolvidas, o nível de exigência precisa ser muito maior.

O legado do Therac-25

O caso provocou mudanças importantes na indústria.

Organizações passaram a investir muito mais em:

• Engenharia de Software;

• Qualidade de Software;

• Testes independentes;

• Revisões formais;

• Certificações para softwares críticos;

• Normas internacionais de segurança.

Hoje, áreas como medicina, aviação, indústria automotiva e sistemas ferroviários possuem processos extremamente rigorosos justamente para evitar que tragédias semelhantes aconteçam novamente.

O que todo profissional de QA deve aprender

O Therac-25 mostra que um bug nem sempre representa apenas um inconveniente para o usuário.

Em determinados contextos, um defeito pode causar prejuízos financeiros, danos ambientais ou colocar vidas em risco.

Por isso, profissionais de QA precisam desenvolver uma mentalidade baseada em prevenção.

Cada caso de teste executado representa uma oportunidade de identificar riscos antes que eles cheguem ao usuário final.

Essa é uma das maiores responsabilidades da profissão.

Conclusão

O caso Therac-25 permanece atual porque demonstra que tecnologia, por si só, não garante segurança.

Sistemas modernos podem utilizar Inteligência Artificial, automação e arquiteturas altamente sofisticadas.

Ainda assim, continuarão dependendo de processos bem definidos, revisões rigorosas e testes de qualidade.

Para quem trabalha com QA, a maior lição é simples:

Nunca assuma que um software está correto apenas porque "sempre funcionou".

Qualidade é construída por meio de validação contínua, pensamento crítico e atenção aos detalhes.

Em alguns projetos, essa diferença pode significar muito mais do que evitar um bug.

Pode significar salvar vidas.

Principais lições para profissionais de QA

✅ Nunca dependa apenas de testes felizes (happy path).

✅ Sistemas críticos precisam de múltiplas camadas de proteção.

✅ Reutilização de código exige nova validação.

✅ Bugs podem ter impactos muito além do ambiente digital.

✅ Testar software é também proteger pessoas.

Perguntas Frequentes (FAQ)

O que foi o Therac-25?

Foi um equipamento de radioterapia utilizado na década de 1980 que sofreu falhas de software responsáveis por acidentes graves envolvendo pacientes.

Qual foi a principal causa do acidente?

Uma combinação de bugs de software, condições de corrida, falhas de engenharia e ausência de mecanismos independentes de segurança.

Por que o caso Therac-25 é importante para QA?

Porque demonstra que testes de software e processos de qualidade podem ser decisivos para evitar acidentes em sistemas críticos.

O Therac-25 ainda é estudado?

Sim. O caso é amplamente utilizado em cursos de Engenharia de Software, Segurança de Sistemas e Qualidade de Software como exemplo clássico de falha em sistemas críticos.

Continue a série "Casos Reais em QA"

Se você gostou deste artigo, confira também:

• Ariane 5: como um erro de conversão destruiu um foguete de aproximadamente US$ 370 milhões.

• Knight Capital: o bug que gerou um prejuízo de US$ 460 milhões em apenas 45 minutos.

• Mars Climate Orbiter: a sonda perdida por causa de uma falha de conversão de unidades.

• Facebook 2021: quando uma configuração incorreta tirou bilhões de usuários do ar.

Artigos relacionados:

• Preciso aprender automação antes da primeira vaga em QA?

• Como responder à pergunta "Como você testaria um elevador?" em entrevistas de QA

• 10 atitudes que podem acelerar sua carreira em Tecnologia

• Como conseguir o primeiro emprego em QA

• Processo Seletivo para QA. Etapa para Conquistar sua Vaga em Testes de Software

Continue sua jornada com o Universo QA

Se você quer acelerar sua evolução, acompanhe nossas publicações e inscreva-se na newsletter QA na Prática para receber novos conteúdos diretamente no seu e-mail.

Se este artigo ajudou você, acompanhe os conteúdos publicados no Contexto em Foco. Todas as semanas compartilho materiais práticos sobre carreira em QA, entrevistas, testes manuais, automação, certificações e desenvolvimento profissional.

Se você está se preparando para conquistar sua primeira oportunidade, conheça também o Guia QA do Zero, criado para orientar cada etapa dessa jornada.