Quando bugs custam vidas…
O assunto é triste, eu sei, mas precisamos conversar sobre ele. Uma das métricas mais debatidas dentro do universo de testes de software é o custo integral do esforço de testes versus o custo de um bug alcançar o ambiente produção, é fácil criar uma estimativa monetária para tal situação, conseguimos mensurar o preço de cada hora, a insatisfação dos usuários, a decepção do cliente… Mas e quando testamos em produção e o preço a ser pago por um bug escapado em um fluxo específico custa uma (ou mais de uma) vida humana?
Esse é o cenário de um acidente com um carro do Uber que atropelou Elaine Herzberg enquanto ela atravessava uma rua no Arizona: Em uma condição de pouca luz (noite), durante uma travessia em uma área sem faixas de pedestre enquanto empurrava sua bicicleta, ela acabou entrando de uma forma triste para a história como o primeiro pedestre vítima fatal de um carro autônomo.
O software de detecção de objetos enxergou Elaine no primeiro momento, mas considerou o cenário como um falso-positivo e decidiu não ter a viagem interrompida. A linha tênue de validação de objetos e avaliação de impacto se dá por um motivo: Não é confortável para o passageiro que o carro autônomo acione os freios no primeiro sinal de um obstáculo na via, isso tornaria a viagem extremamente incômoda e o preço cobrado pela falta de refino na funcionalidade foi altíssimo no caso da fatalidade. Já existem valores de julgamento, assim como uma busca incessante para aprimorar os algoritmos que validam o que seria menos trágico em situações de escolha, porém em situações isoladas e fluxos alternativos não podem acomodar falhas, elas não podem ser toleradas.
Sob a perspectiva de quem testa, como estão os requisitos quando as situações de escolha acontecem, será que estamos nos preocupando em antecipar cada situação corretamente? Será a máquina capaz de pesar a vida dos passageiros de um veículo autônomo contra a vida de pedestres e outros motoristas? Os contratos precisam ser claros e estarem fundamentalmente baseados nas três leis da robótica de Asimov:
- Um robô não pode ferir um humano ou permitir que um humano sofra algum mal;
- Os robôs devem obedecer às ordens dos humanos, exceto nos casos em que tais ordens entrem em conflito com a primeira lei;
- Um robô deve proteger sua própria existência, desde que não entre em conflito com as leis anteriores.
Softwares críticos são testados o tempo todo, afinal, temos software em (quase) tudo hoje em dia, na área médica (com algumas variáveis que aceleram as possibilidades de validação. Sim, você pensou certo se pensou em guerras), nas viagens espaciais, na indústria aeronáutica, pois quem nunca pensou como testar a resistência de aviões comerciais e bélicos em cenários de queda? Maquetes e miniaturas? Também, mas fazem testes de queda com aviões inteiros controlados de forma remota:
Tendo essa perspectiva mais ampla da importância do nosso trabalho, acabamos por nos prender aos mínimos detalhes, ao número infinito de fluxos, à necessidade de validações alternativas, à capacidade de mensurar até o aleatório multiplicado, pois ele sempre vai nos aproximar do improvável, e esse é o ponto que precisamos exercitar: precisamos considerar o improvável o TEMPO TODO, claro que guardando as devidas proporções das consequências, que nesse quesito pontual do Uber foi a pior possível.
O ajuste do mindset é o que separa Testes de Software de Checagem de Software, a checagem faz parte do todo, mas precisamos ir bem além do 0 ou 1 binário, evitando assim que o improvável passe despercebido, e que acidentes em todos os níveis sejam evitados. A prevenção sempre, sempre mesmo, será melhor que a cura.
