Marco Valtas

Consideremos as seguintes situações:

• Tentando acessar o eDBV da Receita Federal através do Safari no iPhone resulta em "Um problema ocorreu no sistema.", já utilizando o Chrome o "sistema" funciona.

• Ao tentar pagar uma DARF (sob declaração de bens de viajantes) utilizando o aplicativo para iPhone do banco resulta em "Operação não permitida."

• Utilizando o site do banco ele deixa de funcionar no Chrome não permitindo acesso a conta, mas se carregarmos o site no Firefox então o acesso é permitido.

• Ao desembarcar no aeroporto e com a declaração de bens em mãos. A agente da Receita Federal está "sem sistema" portanto a declaração deve ser refeita utilizando outro sistema, que neste caso calcula a cotação do dólar com outro valor (mais alto) do que a declaração feita online na Receita Federal.

• Após 20 dias desligado, o computador é ligado e para importar as fotos das férias utilizamos a aplicação Aperture, que ao iniciar indica que a "Biblioteca está corrompida e precisa de reparos."

• Feito os reparos e fotos importadas, é melhor salvar um backup, o disco externo de backup é ligado e o sistema operacional notifica que não pode escrever nos discos e que devemos formatar o disco assim que possível.

O que estas situações tem em comum? Talvez você já deve ter adivinhado que todas ocorreram comigo assim que cheguei de férias, mas isso é apenas um detalhe, acredito que há muito mais a se explorar aqui.

As falhas e os rituais

Você já notou que softwares falham? Provavelmente sim, mas também percebeu o surgimento de diferentes rituais por conta disso?

Ao tentar passar o cartão de débito na máquina portátil do entregador de pizza, quando a operação falha, ele reinicia a máquina, por vezes até retira a bateria. Alguns erguem os braços com o intuito de pegar um melhor sinal.

Rituais e mais rituais para corrigir problemas em software. Abrir e fechar o aplicativo sendo o mais comum.

O que está por trás destes rituais?

Eu consigo pensar em dois fatores:

• A falha do software em comunicar a situação ao usuário com clareza.
• A falha em si, ou seja, uma situação cujo o software não conseguiu completar sua operação.

Falha de Comunicação

Uma mensagem de erro com detalhes incompreensíveis ao usuário é apenas desperdício de tempo. Mensagens de erros direcionadas aos usuários de software devem levar em conta o conhecimento e alcance de ação do usuário. De nada adianta mensagens crípticas e/ou sugestões de soluções fora do alcance do usuário.

Todas as mensagens de erro, se ocorrerem, devem ajudar a esclarecer a situação e orientar o usuário em ações que possam resolver o problema. Mas como isso é raro em nossos softwares, os usuários adotam a falácia lógica conhecida como correlação coincidente, ou seja, seja lá o que foi feito antes e o problema sumiu deve ter correlação com a solução do mesmo.

Falha do Software

Este é um tópico enorme e eu não tenho a pretensão nem o conhecimento para uma discussão aprofundada. Mas como desenvolvedor de software tenho algum conhecimento para abordar o assunto.

Primeiro, software é algo extremamente complexo. Desde da maneira que ele funciona até sua própria confecção. O primeiro desafio ocorre porque não somos capazes de provar que não existem defeitos no software. Podemos testar o software com intuito de demonstrar sua funcionalidade dado apenas um limitado número de fatores, mas a completa isenção de defeitos é demasiadamente complexa e cara de se atingir. Dado isso sabemos que o software possui pontos de falha, situações em que não será possível completar uma operação ou ação.

O que resta é saber balancear o quanto é investido em diversificar os cenários onde podem ocorrer falhas. Bons softwares só irão falhar em condições improváveis, os outros irão falhar em condições menos raras. Já os piores softwares requerem um contexto de execução tão específico que, para não falharem, existe um exército de pessoas mantendo-os.

O conto do meu software não pode falhar.

Toda vez que inicio uma conversa com alguém sobre Entrega Contínua surge a máxima, "Mas como assim? Entregar o software assim tão rápido? Não, não é possível no meu caso (que é sempre especial), meu software não pode falhar." E apesar desta máxima ainda o software falha e é claro que vai falhar. Por várias razões, mas a mais simples é porque suas mudanças não estão sendo utilizadas nas trincheiras junto aos usuários, todos seus cenários de uso são hipotéticos.

Em termos mais práticos, investir na prevenção de falhas é possível desde que este tempo não seja demasiado longo para corrigi-las quando elas ocorrem. Em outras palavras, um balanço entre o tempo de prevenção e tempo para uma ação corretiva deve ser atingido.

Uma forma rápida de descobrir se há falta de equilíbrio entre estes dois tempos é pensar sobre o processo de entrega do dia a dia e uma de emergência. Se há diferentes processos entre eles ainda há um desequilíbrio.

Teste de software e Caos.

A prática de testes automatizados ganha a cada dia mais força. Estamos mais e mais criando testes para nossas aplicações e nos certificando que...

Pois é, nos certificando do que? A verdade é que testes automatizados (unitários, funcionais, de integração e etc.) não são realmente testes, são especificações. Quanto melhor especificado seu software mais rápido o feedback sobre mudanças que introduzem inconsistências nestas especificações. De uma certa maneira estamos sim, de volta a era da especificação, mas desta vez a verificação é contra o código em si, ou seja, muito mais estrita e eficiente.

Se então testes automatizados são especificações, então o que podemos introduzir para realmente testar o software?

Caos.

Introduza caos ao software, um ótimo exemplo é o Simian Army da Netflix. A ideia é que os testes automatizados estão sujeitos ao domínio restrito dos programadores, e geralmente as variações de cenários são extremamente reduzidas se comparadas com o uso real do software. As falhas ocorrem quando uma situação em particular não foi prevista durante o desenvolvimento. O que nos deixa numa posição delicada, pois o software não deve falhar para nosso usuários, mas também não podemos predizer todas as situações em que este software será colocado.

Portanto, neste caso, cenários dos mais variados devem ser criados automaticamente, não planejados e controlados pelos desenvolvedores. Caos, que é introduzido pelo uso do software pode ser emulado até um certo grau e deve ser aplicado ao software em sua fase de testes e em produção.