Testando o seu software como se fosse um avião

Published in

thiagobarradas

6 min readSep 30, 2020

Como a aviação pode nos inspirar nos testes de software?

Viajar é um dos meus hobbies favoritos (aproveito para deixar o convite para seguir meu instagram sobre minhas viagens hehe @viagemdoida) e para ter esse hobbie é necessário superar o medo de voar. Para deixar meu coração mais calmo, sempre leio sobre aviação e como são feitos seus testes. Depois de muita leitura sobre isso, percebi que poderia ficar mais tranquilo nas minhas viagens e ainda percebi que poderia usar a aviação como inspiração no meu dia-a-dia para testar meus softwares.

Como a maioria já sabe, o avião é considerado o meio de transporte mais seguro do mundo, e pra chegar nesse patamar, seus testes são exaustivos, projetados e executados de forma detalhista e prolongada. Vamos falar um pouco mais sobre como esse planejamento e esses testes são feitos, mas primeiro vamos falar alguns números da aviação.

Alguns números

1,6 aviões a cada 1M apresentam algum problema;
10 aviões a cada 40M tem incidentes fatais, na proporção, 0,25 a cada 1M;
Anualmente acontecem cerca de 68M de voos;
Diariamente acontecem cerca de 180 mil de voos;

Tentando reescrever em “SLA”, teriamos:

SLA incidentes comuns: 99,99984
1 incidente comum a cada 4 dias
SLA incidentes fatais: 99,999975
1 incidente fatal a cada 23 dias

Digamos que se uma pessoa voasse todos os dias, experimentaria um acidente catastrófico em algum momento dentro dos próximos 2,7 mil anos.

Se tivessemos uma empresa aérea que garantisse o mesmo SLA que o Azure, AWS ou GCP (considerando georedundância) teriamos:

SLA: 99,99 para incidentes comuns
Passível de18 incidentes comuns por DIA!
Proporcionalmente, teríamos 3 incidentes fatais por DIA!
SLA 72x menor que a aviação

Considerando o uso de recursos sem georedundância temos um cenário ainda mais catastrófico:

SLA: 99,95 para incidentes comuns
Passível de 90 incidentes comuns por DIA!
Proporcionalmente, teríamos 15 incidentes fatais por DIA!
SLA 360x menor que a aviação

Aspecos básicos do planejamento e da produção

Desde a decisão da criação de um novo avião até seu primeiro voo, o trajeto todo dura anos. Na fase inicial, de projeto, os engenheiros irão detalhar cada pecinha que compõe o avião: suas estruturas, nervuras, tanque de combustível, o sistema hidráulico, etc.

O projeto de um novo modelo exige um tempo maior somente no desenho, que pode levar outros longos anos. Mas, na replicação de um modelo já projetado e já construído anteriormente, o desenho é reaproveitado, sempre respeitando os ajustes que surgem. Na prática, a construção em si pode ser feita em apenas 10 dias.

Durante a construção, os times são totalmente integrados. Imagine vários grupos de especialistas pensando suas áreas separadamente: o time de sistema hidráulico, a equipe de sistema elétrico, os responsáveis pelo combustível, etc. Todos “disputam” espaço dentro da mesma aeronave, pois os sistemas precisam coexistir e também conseguem usar recursos comuns.

Os sistemas em si, não existem de forma única dentro de uma aeronave. Eles podem ser repetidos duas, três e até quatro vezes no avião. Dessa forma, se um sistema falhar, a sua redundância assume seu lugar, garantindo a segurança do voo.

Os voos de testes (ensaios) podem chegar a 2.000 horas (365 dias voando 5h30m todos os dias). Dado que um ensaio constuma durar entre 1 e 2 horas e não ocorrem diariamente, o tempo real é um tanto maior.

Quanto tempo é gasto no desenho da solução? Quanto tempo é gasto no desenvolvimento (construção)? Quanto tempo é gasto somente em testes?
Perceba que a proporção na qual você divide essas etapas está bem diferente, né? (sem dúvidas estou acertando).

Como o avião é testado?

Na aviação os testes são de fácil associação com o mundo do software. Podemos separar os testes principalmente em testes de componentes (teste unitários), ensaios de voo (integração), testes de sobrecarga e situações extremas (stress/capacity) e teste de tolerância à falhas (chaos engineering).

Nos testes de componentes, todas as partes do avião são testadas individualmente. O “core” (fuselagem, asas, motores e sistema de pressurização) recebe o maior esforço e investimento. Os testes, mesmo de componentes isolados, tentam reproduzir a realidade e testam diversos cenários.

Os testes dos componentes individualizados são muito importantes e devem ter testes considerando os diversos cenários de sucesso e fracasso da vida real. As partes críticas do seu sistema, que coloquem sua ‘vida’ em risco, precisam de esforço dobrado.

Para os ensaios de voo, um espaço aéreo exclusivo é reservado para os testes, em muitos cenários esse espaço é fixo. Cada ensaio costuma durar até 2 horas. A bordo: um piloto, um copiloto e um ou dois engenheiros de voo. São necessários diversos ensaios para executar todos envelopes de testes.

Todos os testes devem ser feitos em um ambiente segmentado e exclusivo para a sua homologação. Importante: quem “desenvolve” também testa, auxiliado por outras pessoas. Antes de executar os testes, sempre temos os “planos de testes”.

Para os testes de situações extremas, podemos citar alguns:

Water Spray: O avião faz testes de corrida de pista, decolagem e pouso em uma pista encharcada;
Nas asas são aplicados testes de fadiga, onde a ponta da asa é levantada até 5,5m do ponto original;
O motor é submetido a temperaturas extermas (negativas e ao calor extremo). A temperatura pode chegar a 800 ºC;
Geração de enormes quantidades de pressão com potência suficiente para simular o efeito de uma bomba explodindo dentro da aeronave;
Flutter Test: Coloca-se o avião em velocidade superior a velocidade máxima suportada, testando as vibrações e deformações causadas pelas ondas nas asas e fuselagem;

Os testes que estressam o sistema garantem que caso algo saia do normal, o sistema está confiável para suportar até certo nível, com total segurança. Nesse ponto é necessário uma análise profunda dos cenários (um pouco de criatividade também) para elaborar os cases. Todo agente “externo” ao teste precisa ser simulado de alguma maneira próximas da realidade.

Já nos testes de tolerância à falhas é preciso, acima de tudo, coragem hehe. Exemplo:

Stall: o piloto diminui a velocidade para causar perda de sustentação e fazer a aeronave cair praticamente na posição horizontal;
Os motores também são desligados no meio do voo;
O controle fly-by-wire (protegido) são desativados testando o controle da aeronave via direct-law (modo manual);

Forçar a falha de “parte” do sistema é fundamental para garantir a resiliência do sistema, e que mesmo com os recursos parciais, toda parte ‘crítica’ foi feita com baixo acoplamento e funciona independente do resto do sistema.

Para validar os testes, milhares de métricas são coletadas:

São instalados mais de 12 mil sensores no avião para coletar dados dos testes;
Um equipamento é usado para fazer a endoscopia dentro dos motores das aeronaves. Com ele, é possível ver o movimento preciso das engrenagens.
Produtos químicos e luz ultravioleta são usados para constatar se há trincas ou rachaduras nas peças.

Se você não for capaz de coletar métricas, todo esforço anterior será em vão. É obrigatório que seus testes gerem métricas, que seu sistema tenha um APM, Logs etc. Só assim você poderá enxergar além alcance!

Principais aprendizados

O tempo gasto no planejamento / desenho da solução deve ser consideravelmente maior do que o tempo de desenvolvimento;
O tempo gasto nos teste também deve ser consideravelmente maior do que o tempo de desenvolvimento;
Quem desenvolve, testa!
Ambiente exclusivo para homologação;
Testes unitários obrigatório e exaustivo em todos os componentes que põe em risco a “vida” na sua aplicação;
Testes de integração e funcionais devem ser capazes de reproduzir a realidade em bons e maus momentos;
Testes de stress e capacity devem ser feitos de maneira exaustiva, desafiando todos os números e situações extremas;
Testes de tolerância a falha / chaos engineering são os testes que vão garantir a resiliência;
Colete métricas dos seus testes o tempo todo, seus resultados, sua performance e todos dados necessários para avalia-lo o todo;

Referências:

Testando o seu software como se fosse um avião

Alguns números

Aspecos básicos do planejamento e da produção

Como o avião é testado?

Principais aprendizados

Written by Thiago Barradas