Introdução

Uma das dificuldades para desenvolvedores é garantir a qualidade do programa. Vou passar aqui a abordagem de testes que utilizamos no laboratório para tentar garantir a qualidade dos programas aqui desenvolvidos.

A abordagem utilizada se baseia em cinco pilares principais, sendo eles:

• Processamento de dados
• Usabilidade
• Integração com hardware
• Escalabilidade
• Feed back dos usuários.

Embora os 5 itens sejam igualmente importantes, cada um é avaliado em um momento diferente do desenvolvimento. Com essa estratégia podemos minimizar atrasos que poderiam ocorrer se todos os testes fossem executados ao final de cada ciclo de desenvolvimento. Então os testes são executados quando?

• Sempre que uma nova função foi implementada, para os testes de processamento de dados e usabilidade.
• Antes do lançamento de uma nova versão para os usuários finais, para os testes de integração com hardware e escalabilidade.
• Após o lançamento de uma nova versão, para o feed back dos usuários finais.

Uma coisa que é preciso ter em mente para o sucesso dos testes de um programa é que o mesmo deve ser bem documentado. Isso pode ser facilmente percebido ao notar a seguinte relação de dependências:

Assim você só vai saber o que testar e como testar, se você conhece os requisitos do programa corretamente.

Com essa pequena introdução dada, vamos agora para uma visão geral sobre cada um dos cinco pilares de teste.

Processamento de dados

Os testes de processamento de dados visam garantir que os algorítimos implementados tratem e persistam os dados corretamente. Como pode-se notar, este pilar se divide em duas rotinas distintas de teste, testes de acurácia do processamento, e de persistência de dados. Segue agora uma visão de ambas.

Acurácia

Visa garantir que a saída do algoritmo sempre corresponda a saída esperada para a entrada dada. Para isso, usamos duas técnicas distintas e complementares conhecidas como teste caixa preta e teste caixa branca.

O teste caixa preta funciona fornecendo uma entrada entrada e observando a saída, sem necessariamente conhecimento do código. Ele é usado no primeiro estágio de testes de acurácia pela sua facilidade de automação e pela possibilidade de ser delegado a terceiros, uma vez que o código permanece oculto. O teste caixa branca, que será executado sempre que algum caixa preta falhar, se dá pela analise passo-a-passo da execução do algoritmo e exige conhecimento de como o mesmo funciona, por este motivo ele é executado pelos próprios programadores. Esta segunda etapa do teste de acurácia visa descobrir onde está o problema da implementação do algoritmo, permitindo a sua correção.

Persistência de dados

Visa garantir que todos os dados processados pelo programa sejam corretamente persistidos na memória e que não aja possibilidade de corrupção dos dados pelo próprio programa.

Estes testes são feitos de maneira braçal, sendo que para cada caso de teste o testador irá executar a ação e verificar se ela ocorreu corretamente. Também pode-se usar APIs que automatizem esses processos, mas a sequencia básica de ação (executar tarefa, verificar estado) permanece a mesma.

O ponto critico desta rotina está em testar a reação do programa a situações não ideais, como conexão instável com banco de dados e etc.

Usabilidade

Estes testes visam garantir que o usuário consiga executar as suas tarefas com facilidade, e com baixo índice de erros.

Para isso  foi adotada uma estratégia baseada em passeio cognitivo onde avaliamos: A necessidade de refazer passos devido a erro, facilidade de aprendizado e rapidez na realização da tarefa.

Os nossos testes consistem na utilização de uma versão compilada para gerar um log que contenha quantos passos foram necessários pra executar a tarefa, pontos de ambiguidade, necessidade de refazer passo e o tempo gasto; e a realização de uma entrevista com o usuário que está tentando realizar a tarefa.

Assim temos os dados obtidos de maneira automática, e uma impressão do usuário que nos leva a entender o por que ele errou o caminho para realizar a tarefa, por exemplo.

Integração com hardware

Estes testes visam garantir que o programa não use mais recursos do hardware do que deve, e que se integre bem ao mesmo em caso de sistemas embutidos.

Consiste basicamente na verificação do uso que o programa faz do hardware, para tanto pode-se usar uma versão compilada de testes, que executa chamadas ao sistema e gere um log contendo o uso de recursos como: processador, memória, bateria, uso da rede e etc.

Em situações mais criticas e/ou quando se dispõe de mais tempo pode-se usar hardwares que façam essa medição (Exemplo), obtendo assim, dados mais precisos que os fornecidos pelo sistema operacional.

Sistemas embarcados

Quando o programa é desenvolvido para sistemas embarcados, existe a necessidade de casos de uso que contemplem a interação do software com todas as interfaces providas pelo hardware que receberá o sistema.

Assim, deverão ser verificados caso existam, integração com teclado, com tela touch screen, interfaces de rede e etc.

Escalabilidade

Os sistemas devem ser capazes de suportar auto número de conexões simultâneas sem negar serviço (denial of service). E para tanto executamos testes semelhantes a ataques DDoS (Distributed Denial of Service) onde fazemos várias requisições simultâneas ao servidor e verificamos, qual a carga máxima que ele suporta. Assim podemos saber quais chamadas exigem mais recurso do servidor, otimiza-las e/ou escalonar o servidor para a demanda necessária.

Feed-back dos usuários

Não consiste em um teste propriamente dito, mas sim em avaliar a relação do usuário com o sistema, proporcionando assim informações complementares relativas a usabilidade, e algum erro que não previsto. Aproveitar a experiencia do usuário para melhorias no próximo ciclo de desenvolvimento é de grande utilidade, pois o mesmo sabe o que precisa fazer, e se o programa está satisfazendo as suas necessidades.

Conclusão

Esta breve explicação de como testamos os programas aqui desenvolvidos mostra principalmente que: é possível cobrir quase todos os pontos do programa, mas existe a chance de que em alguma situação não prevista o programa não reaja bem, assim o feed-back dos usuários é de grande valia. E que o sucesso dos testes está diretamente relacionado a um levantamento de requisitos bem feito,