Metodologias Ágeis X Firmware

    Firmware Ágil?

Assim como no desenvolvimento de software, conseguimos aplicar apenas algumas práticas ágeis no desenvolvimento de firmware, por existir limitações citadas no último post.

  

Pensando com uma visão de um testador ágil, durante a definição das "estórias" já atuamos ajudando com perguntas, questionando, levantando o máximo de dúvidas possíveis fazendo com que o time entenda melhor o real desejo do usuário, além de servir de apoio para um melhor planejamento das atividades. Em si tratando de firmware é muito importante já ir pensando como um testador irá testar a funcionalidade em questão, pois existe durante os testes muitas vezes a manipulação de um hardware na qual o firmware é embarcado.

Por muito tempo conversando com os desenvolvedores de firmware, pensamos que não era possível fazer TDD no desenvolvimento de firmware, pois existia algumas preocupações como conseguir emular através da IDE de desenvolvimento o comportamento do firmware já embarcado.

Até que um dos desenvolvedores fez alguns testes com Unity e percebeu que o emulador usado, atendia a simulação do comportamento do firmware embarcado. O Unity é um framework de teste unitário escrito totalmente em C, é leve e possui recursos especiais para sistemas embarcados.

Voltando as atividades do testador, durante o TDD cabe a ele, ajudar o desenvolvedor a pensar nos diferentes cenários de testes para aumentar a cobertura de testes no código, no desenvolvimento de firmware o TDD fica mais "confiável" nas mãos do desenvolvedor, uma vez que muitas vezes um parâmetro passado num método por ser até uma posição de memória.

void test_ShowSomeSillyExamples(void)
{
TEST_ASSERT_NOT_EQUAL(0, -1);
TEST_ASSERT_EQUAL_INT(1, 1);
TEST_ASSERT_EQUAL_HEX16(0x1234, 0x1234);
TEST_ASSERT_EQUAL_STRING("These Are The Same", "These Are The Same");
TEST_ASSERT_BITS(0x1111, 0x5555, 0x7175);
TEST_ASSERT_INT_WITHIN(5, 100, 102);
}

Na linha do Unity temos o Cmock que é uma framework que trabalha junto com o Unity para ajudar na criação de Mocks e Stubs de interfaces para simplificar os testes.

A integração continua é possível para a compilação do firmware , mas o desafio ainda é o embarque do firmware no hardware, mas até o momento que participei do projeto já existia possíveis contornos para este desafio.

A automação encontrava-se bem evoluida com os primeiros casos de teste automatizados já sendo executados, com o auxílio de geradores de sinais e um framework desenvolvido para o apoio da automação.

Livros para apoio:

http://www.lulu.com/spotlight/mvandervoord

http://pragprog.com/book/jgade/test-driven-development-for-embedded-c

 

Este post é o último relacionado a a testes de firmware e hardware, uma vez que nesta semana iniciei minhas atividades em uma nova empresa, onde estou tendo a oportunidade de trabalhar com testes ágeis voltados para aplicações.

Pretendo escrever a partir de agora sobre meu dia a dia atuando em times ágeis, assim como ferramentas de BDD e automação, além das novas experiências com Agile Testing.

Créditos: Felipe Provenzano