Introdução

Como testar um software que pode voar 
- um guia prático para um software de qualidade -

Atrás da simplicidade deste título encontra-se a mentalidade deste material: trazer a complexidade do assunto para níveis mais fáceis de discutir. Quando as pessoas se especializam em determinado assunto elas vão perdendo a capacidade de transmitir o seu conhecimento para pessoas que são iniciantes no assunto. Elas se esquecem ou ignoram que os outros não conhecem os detalhes que ela domina. É uma desatenção no ato de comunicar que põe a perder todo o potencial de transferência de conhecimento, por uma simples questão de didática, ou melhor, pela falta dela.

Este material poderia se entitular "Metodologia para execução do processo de verificação de software crítico", mas para reforçar o compromisso de priorizar a simplicidade da comunicação, ele ficará como está.

E comecemos por onde toda explicação deve ser começada: pelo contexto.

O autor trabalhou por pouco mais de 10 anos com testes de software aeronáutico, se familiarizando com as normas que regem o desenvolvimento de um software que pode causar estragos significativos caso não funcione adequadamente. Não significa que as explicações que serão dadas servem apenas para esta indústria, mas é provável que os exemplos sejam mais polarizados para os casos em que ele teve contato. Os conceitos aqui apresentados são técnicas e boas práticas que se aplicam a qualquer software de que se deseje garantir a qualidade, principalmente (mas não restrito a) softwares críticos.

Então vamos dividir o mundo do software em duas partes: os críticos e os não-críticos. Softwares críticos são aqueles que não podem falhar, pois são essenciais para o funcionamento de um sistema importante, normalmente relacionado à manutenção da vida, como softwares de aparelhos médicos, de aviões, carros autônomos, ou mesmo relacionados a outras funções importantes para o ser humano, como o software que manipula uma conta bancária. Em todos os casos, o mal funcionamento do software pode causar desastres ou prejuízos incalculáveis.

Mas nem sempre é possível separar todas as possibilidades de aplicação em dois grupos, e existem casos em que ela se enquadra em uma classificação intermediária. Suponha, por exemplo, o travamento de um software de controle de voo que tenha um backup manual onde o controlador de voo terá que fazer manualmente todos os cálculos de rotas, sujeito a erros humanos que poderiam comprometer a segurança daqueles aviões. Aquele software, que suportava a atividade não era essencial para a função, portanto não era crítico, porém a sua falha criou uma condição de maior risco.

Por esta razão, existem classificações intermediárias de criticidade. Na indústria aeronáutica existem 5 classes, baseadas nos impactos que a falha do software pode causar: catastrófico, ameaçador (hazardous), significativo (major), insignificativo (minor) ou sem impacto.

Por outro lado, a qualidade de um software não pode ser classificada simplesmente como software seguro ou software não-seguro. Mesmo porque não existe um software que seja totalmente livre de erros, pois é impossível prever todas as condições em que ele terá que funcionar, principalmente quando ele interage com outros softwares ou sistemas. O que se pode fazer então, é testar o máximo necessário, de uma maneira sistemática e utilizando um critério, para garantir que todos os erros que forem encontrados sejam corrigidos e que o software não possua nenhum problema conhecido. Percebam que é necessário limitar o teste dentro algum critério que diga o quanto é suficiente testar. Isto porque não existiriam limites quanto a todas as combinações que se pode testar, considerando que a ordem temporal em que as ações do testes são executadas podem constituir testes diferentes.

Até agora foi falado apenas de teste, por simplificação e por saber que os testes são os meios mais conhecidos de se avaliar a qualidade de um software. Porém tenham em mente que existem outros métodos, que serão igualmente abordados ao longo deste material. A palavra para englobar todos os métodos (testes, análises, inspeções, revisões) é verificação. Portanto um software de qualidade não passa apenas por testes, mas por todos os métodos de verificação.

Outras classificações dizem respeito ao ambiente de execução do software e à necessidade de garantir uma resposta temporal. Um software que roda em ambiente especializado, como uma placa micro-processada com função específica em um sistema é chamado de um software embarcado (embedded software) em oposição àquele software que roda em PC, normalmente com interface gráfica no monitor e que recebe comandos de teclado e mouse. Entre os softwares embarcados, ainda existe a divisão entre real-time e non-real-time. Os primeiros são aqueles que precisam agir de maneira correta e dentro de um limite de tempo. Não adianta que ele dê uma resposta extremamente precisa se ela for enviada com atraso. Muitas vezes é preferível abrir mão de um pouco da precisão numérica para garantir que a resposta seja dado no tempo certo. Deve haver um balanço, pois responder no tempo certo é tão importante como dar a resposta certa. Imaginemos, por exemplo, um software que comanda um airbag ou um freio de automóvel.

Esta foi uma introdução para familiarizar o leitor com o ambiente no qual os testes, ou melhor, as verificações serão realizadas. A partir deste momento iremos mergulhar no assunto da verificação em si, que é o tema principal deste material, portanto vamos direto ao assunto pois há muito o que discutir.