“Testes automatizados significam, primeiramente, monitoramento constante.”
A palavra teste pode enganar. O teste de software automatizado pressupõe um monitoramento constante da funcionalidade testada. Ou, pelo menos, tão frequente quanto se desejar.
O teste pode ser disparado das seguintes formas:
Crônico – Independente de qualquer ação do desenvolvedor ou dos usuários.
Arbitrário – Com base em um disparo arbitrário, a qualquer tempo.
Em resposta ao uso (TRU) – Em virtude de ações dos usuários do sistema a ser monitorado. Por exemplo: para aferir se a inserção de um certo conteúdo ou funcionamento do sistema como um todo.
Em resposta ao desenvolvimento (TRD) – O teste é disparado cada vez que novo código é acrescentado ao sistema.
“Testes de software não podem identificar todos os problemas”
Ao invés disso, os cenários mais sensíveis para a aplicação devem ser monitorados. A escolha das funcionalidades e cenários a serem monitoradas é tão importante, que algumas vezes, cenários de teste são chamados de oráculos.
Cobertura básica – Todas as funcionalidades de um sistema devem estar corretas. Porém, algumas são bastante básicas. Se o sistema separa usuários anônimos, então, no mínimo, a autenticação deve estar funcionando. Falha na autenticação pode representar um problema que impede o uso de todas as demais funcionalidades.
Cobertura sensível – Há funcionalidades que não são indispensáveis ao projeto, mas que, devido à complexidade, são uma potencial fonte de erros. Ou que são uma parte importante do produto, embora não impeçam a utilização de todo o produto. Em um portal de conteúdo, por exemplo, a busca pode ser um exemplo de funcionalidade para cobertura sensível, principalmente se for um dos requisitos do sistema, e não apenas uma funcionalidade acessória.
Cobertura seletiva – Dada uma funcionalidade sensível, é necessário cobrir seletivamente seus cenários. Espera-se de um sistema de busca,por exemplo, uma certa quantidade de resultados para cada termo utilizado. Variações inesperadas nesses valores podem representar uma falha no sistema.
“Testes estáticos ficam na caixa-branca. Testes dinâmicos e monitoramento vão para a caixa-preta”
Caixa-branca – Testes unitários são escritos pelo desenvolvedor do programa a ser testado. Embora não sejam indispensáveis para a realização da tarefa, são uma prática tão boa quanto manter a coluna reta ao escrever em papel. E alguém pode, até, escrever textos melhores por isso! O fluxo de desenvolvimento baseado em testes permite ao programador ter sempre em mente qual é o próximo passo. O teste é escrito antes do programa a ser testado, propriamente dito. Assim, a primeira execução do programa, no momento em que o programa ainda não existe, é reprovada no teste, obviamente. Quando o programa é aprovado, se ainda resta algo a ser feito, o teste é reescrito para englobar essa funcionalidade remanecente, e assim sucessivamente. Testes unitários são uma boa prática, mas não são indispensáveis, exceto em contextos em que está incluída, entre as especificações do sistema, a garantia de compatibilidade em diferentes ambientes. Se o programa precisará funcionar instalado em diferentes máquinas com arquitetura variada, sob diversos sistemas operacionais, então nesse caso, pode-se dizer que a existência de testes unitários é indispensável ao produto. Os testes de caixa-branca também são conhecidos como testes estáticos, uma vez que não existe uma interface, facilitada, para sua edição, porque editá-lo corresponde a editar o próprio sistema que esteja sendo testado. É um teste estático em relação ao programa objeto.
Caixa-preta – Os testes automatizados de caixa-preta, por outro lado, devem ser agnósticos ao sistema que está sendo testado. São metaprogramas cujo objetivo é simular o uso final dos programas objeto. Se a aplicação em desenvolvimento é acessada através de um navegador web, então, o teste automatizado fará exatamente isso, sem compartilhar informações privilegiadas (variáveis, funções ou banco de dados) com o programa objeto. É um teste realizado do ponto de vista do usuário final para quem o sistema está sendo desenvolvido, privilegiando as principais funcionalidades do sistema. Além disso, o teste de caixa-preta, automatizado, satisfaz a necessidade de teste de regressão. Ao longo do tempo, o produto pode adquirir novas funcionalidades. A satisfação dessas novas funcionalidades não pode, porém, impedir o funcionamento das funcionalidades anteriores. O objetivo do teste automatizado, de caixa-preta, não é saber se o programa funcionou. É saber se o programa funciona, agora, e, no limite, se o programa continuará funcionando, no futuro, quaisquer que sejam os cenários de uso ou os incrementos ao desenvolvimento.
Preferencialmente, o teste de caixa-preta deve ser rodado em uma máquina diferente daquela que roda o sistema objeto. Isso deve ser possível sempre que o sistema objeto estiver acessível externamente, através de uma rede.