Desde o final do ano passado, eu estou atuando em um projeto de desenvolvimento de uma Solução voltada a rastreadores veiculares. Chamei de solução porque é um conjunto de aplicações Web e Desktop somado a um Firmware embarcado num Hardware, onde os testes não se resumem apenas em testes das aplicações desktop e Web.

Descrevendo melhor o cenário em forma de arquitetura, imagine em alto nível 5 grandes blocos, formados por uma aplicação Desktop(configuração de parâmetros no firmware [Delphi]), uma WEB (Interface para visualizar a localização do equipamento [Adobe-Flex]), Equipamento(Rastreador), Firmware (Escrito em C - C puro mesmo) e ainda um Gateway (Escrito em C e C++).

Nos primeiro dias revivi meus tempos de técnico de eletrônica e telecomunicações, onde manipulava fontes de alimentação, osciloscópios, geradores de sinais e etc...

Mas o desafio maior era, desde o início, pensar em como automatizar os testes da solução e em como aplicar as diferentes técnicas de teste para agregar qualidade ao produto.

O primeiro passo no projeto foi melhorar o processo de teste, que quase não existia e deixava gerentes e diretoria insatisfeitos pela quantidade de bugs encontrados em produção (em clientes). Feito isso, demos continuidade ao projeto melhorando a especificação dos casos de teste e a atuação dos analistas de teste, desde o nascimento dos requisitos até a fase de homologação da solução.

Com um olhar mais técnico, é um ambiente que se ouve muito mais sobre bits e bytes como parâmetros de métodos do que variáveis do tipo string. A preocupação com o armazenamento é constante uma vez que se tratando de desenvolvimento de firmware os recursos são mais "limitados" em função do hardware a qual é destinado.

Partindo para um simples detalhamento das aplicações além do firmware, irei resumir o funcionamento da aplicação Desktop, WEB e o Gateway da solução.

A aplicação desktop é voltada para a configuração do comportamento do firmware. Por exemplo, nesta aplicação é possível configurar o tempo de transmissão de dados para o Gateway (via GPRS ou Satélite), ou cadastrar um telefone que seria usado como "alvo" de um comando que realiza uma chamada a partir do módulo para utilização de comandos via DTMF.

A aplicação WEB tem como principal função criar uma interface amigável para o usuário final para que ele possa monitorar um veículo com um rastreador instalado, desde sua posição atual sobre um mapa até o status do equipamento (e.g.: após acionar um botão de pânico – uma das funcionalidades do rastreador – a flag correspondente ao pânico mudará de cor na interface do usuário, alertando o usuário de uma possível situação de perigo).

O Gateway é instalado na máquina local e tem como função receber "pacotes de dados" do firmware que, após processador pelo mesmo, são transformados em arquivos .xml com as informação de localização, status das entradas e saídas do equipamento, quantidade de quilômetros rodados, a velocidade do veículo entre outras informações. É possível também utilizar o gateway para realizar o envio de comandos para o módulo, tanto via GPRS quanto satélite, para configurar determinados parâmetros de funcionamento do firmware de uma maneira similar à aplicação desktop.

As funcionalidades do rastreador são inúmeras e, durante a execução de testes exploratórios, me deparei com uma funcionalidade que usava linguagem LUA para acessar diretamente alguns métodos do firmware e estender ainda mais suas funcionalidades. Fazendo uma breve análise, o LUA é uma linguagem criada no Brasil e bastante eficaz para estender outras linguagens, motivo este que leva muitos desenvolvedores a utilizarem-na como um plus em jogos e firmware. Por ser simples, robusta, interpretada e portátil, o LUA acabou sendo o escolhido para agregar ainda mais valor ao produto.

Aprendi bastante testando funcionalidades relacionadas à linguagem e não demorou para perceber que o LUA poderia auxiliar em alguns casos de testes automatizados da solução.
 

Partindo agora para as técnicas de testes que utilizamos no dia a dia, imagine tentar usar Análise do valor limite para testar um campo na aplicação Desktop que configura o DNS no firmware. Durante a definição de requisitos, foi decidido que o tamanho máximo do campo para o firmware seria de 64Bytes. E aí? Ok! Para os testes via aplicação Desktop, o campo correspondente foi limitado a 64 caracteres para que não fosse possível para o usuário enviar mais bytes para a variável do que o esperado.

Mas como o firmware se comportaria caso fosse possível enviar um DNS com 65 ou mais caracteres? Entre uma pergunta e outra a explicação daquilo veio. O firmware aloca na memória os primeiros 64 bytes e os demais são ignorados. Sendo assim, mesmo que você possa enviar 100 caracteres, apenas os 64 primeiros serão levados em consideração e os demais serão simplesmente descartados. Com isso surgiu a discussão sobre quais testes entrariam na técnica para assim conseguirmos aproveitar melhor o tempo para realizar outros tipos e técnicas de teste em cada funcionalidade.

O que eu aprendi com esta experiência? Aprendi a analisar arquitetura de sistemas em um nível mais baixo, onde para alguns bugs encontrados no firmware a solução era alterar uma instrução Assembly. Entendi melhor o por quê de aplicações 64bits não serem executadas em sistemas operacionais 32 bits.

Tratando-se de baixo nível, a arquitetura é quem manda. De acordo com a arquitetura utilizada muda-se a forma como os bits são alocados na memória e isso pode causar um grande transtorno. Termos como Little Endian e Big Endian são comuns e depois posso escrever um post relacionado a isto.

Pela falta de ferramentas de automação que se encaixassem na realidade do projeto, acabamos optando pelo desenvolvimento de uma ferramenta própria. Os desenvolvedores ficaram com a responsabilidade de desenvolver toda uma API para uso em Python que pudesse simular a interação do usuário com o firmware embarcado, podendo assim automatizar os testes direto no rastreador sem a necessidade de utilizar emuladores. Atualmente, o projeto de automação continua crescendo e parece cada dia mais promissor. Os primeiros casos de testes já puderam ser desenvolvidos e os próximos passos já foram definidos.

Para felicidade de alguns e tristeza de outros estou deixando o projeto para uma oportunidade desafiadora que recebi, mas saio contente com a experiência e com o progresso alcançado no que diz respeito à automação de testes. Em breve eu pretendo postar algo sobre os desafios de automatizar soluções como esta.

A intenção desse primeiro POST é tentar mostrar um pouco do mundo dos testes além das aplicações e tentar mostrar para vocês que existe uma área promissora para ser explorada com um imenso potencial. A área de firmware e microcontroladores, que diferente do mercado de software, não possui um profissional de testes especializado. Os testes são feitos pelos próprios desenvolvedores e engenheiros, as vezes sem processo, sem o uso de técnicas, sem pensar em padrões e muito menos em automação.

Imaginem que atualmente sua TV passa por um processo de boot quando você liga ela, que para corrigir bugs é atualizado o firmware, que um decodificador de TV via satélite(e.g.: Sky) sofre constantes atualizações de firmware para correção de bugs. Ou o próprio Google Glass que deve ter um firmware rodando por trás hardware.

Acredito que assim como os testes de aplicativos e sistemas operacionais presentes em celulares tem ganhado forças bem consideráveis atualmente, testes em soluções que envolvem hardware e firmware irão num futuro próximo necessitar de um profissional de testes que consigam agregar valor ao produto.

Este foi meu primeiro post de muitos que serão publicados. Vamos lá, dê sua opinião, faça suas perguntas, me desafie com novos temas e fique a vontade para criticar. Estou aqui para contribuir e aprender com vocês. 

Até a próxima!