testesauto
Share on facebook
Share on twitter
Share on linkedin

Poka-Yoke e testes automatizados: qual a importância do que eles têm em comum?

Um dispositivo à prova de idiotas erros. Conceito desenvolvido pelo “gênio da engenharia” Shigeo Shingo e adotado no Lean Manufacturing (ou Sistema Toyota de Produção), a ideia de Poka-Yoke consiste em construir dispositivos que evitem erros ou defeitos na produção ou utilização de produtos. Tomadas que só podem ser conectadas na posição correta, a chave do carro que só pode ser retirada em ponto-morto ou até mesmo a tampa redonda de um bueiro que, graças ao seu formato, evita problemas de encaixe e impede que a mesma, literalmente, vá pelo ralo, são exemplos práticos de Poka-Yoke.

poka yoke

Mas o que isso tem a ver com os testes automatizados?

Na metodologia ágil de desenvolvimento de softwares, os requisitos funcionais são divididos e executados ao longo do tempo, de maneira que é possível implantar um sistema com funcionalidades priorizadas e, de acordo com o andamento das etapas, fazer alterações – ou evolutivas – no projeto. Entretanto, é preciso ficar atento ao fato de que o desenvolvimento de novas funcionalidades pode causar impacto no desempenho daquilo que foi anteriormente construído.

Por isso, os testes automatizados, que fazem parte da metodologia ágil, são responsáveis por  garantir de forma eficiente um primeiro nível de testes para verificar se tudo o que está implementado continua operando de forma correta. O roteiro básico para escrevê-los consiste em partir de um cenário inicial, efetuar uma operação do sistema e checar se o resultado está de acordo com o esperado.

O maior desafio do desenvolvedor de testes automatizados é manter sua validade ao longo do tempo, pois dessa forma o resultado de uma determinada operação, quando feita a partir de um mesmo cenário, será sempre igual. No entanto, o cenário para testes muitas vezes parte de um banco de dados “vivo”, ou seja, que está sendo utilizado para outras finalidades, tornando difícil garantir o mesmo ponto de partida da base desse banco.

Para contornar a utilização do banco de dados, são implementadas soluções de mock que podem ser diretamente em código, em arquivos (“*.csv” por exemplo) ou em bancos de dados light. A definição da estratégia de mock depende da forma de implementação do sistema.

Na prática

Para o desenvolvimento de um sistema de Gestão de Fretes de uma grande locadora de ativos foi utilizada uma arquitetura envolvendo injeção de dependências e inversão de controle. A partir da injeção de dependências as camadas do sistema são desacopladas do núcleo de negócio e é possível, por exemplo, alterar a fonte de dados que alimenta o sistema.

 

testesauto
Exemplo de arquitetura na qual os clientes executam as regras de negócio e podem escolher se será utilizado o banco de dados real ou mocks em CSV.

 

Sendo assim, para os testes automatizados do sistema, a fim de garantir um cenário equivalente capaz de gerar o mesmo resultado em todas as execuções, foi utilizada a estratégia de mocks através de arquivos CSV: criamos um repositório para os arquivos CSV contendo os cenários pré-definidos. Sendo assim, quando for necessária a execução dos testes, os desenvolvedores têm apenas que criar uma cópia do repositório e executar os testes em cima deles, garantindo o resultado desejado.

Baseado na ideia de Poka yoke, os testes automatizados eliminam erros e impedem o desperdício de tempo – e esforço – na correção de problemas que podem ser evitados. Essa solução já existe na sua empresa? Compartilhe sua experiência com a gente!

Por: André Mayer e Jéssica Saliba

Tá na dúvida?

[email protected]

R. Antônio de Albuquerque, 330 – 14° andar
Savassi, Belo Horizonte – MG, 30112-010