Existem muitas convenções e padronizações para definir certos termos de testes de software, mas para alguns desses termos a padronização não é seguida rigidamente por todas as comunidades. Alguns de- les são usados rotineiramente em nossas conversas diárias com significados diferentes dependendo do contexto, o que dificulta a fixação dos padrões e consequentemente a interpretação dos estudos técni- cos. Abaixo está a descrição de alguns desses termos e algumas observações referente à terminologia utilizada por este trabalho.
Engano/Defeito/Falha/Erro/Não conformidade: Existem padrões que diferenciam esses termos [111, 114], onde cada um possui um significado específico. No entanto, este texto interpreta todos como sinônimos, e para distinguir os diferentes tipos de erros é utilizado explicitamente um texto adicional autoexplicativo, por exemplo: “Erro de distração do programador.” Apesar do termo ficar mais longo, evita problemas de ambiguidades e também não fere convenções definidas por ferramentas e outras comunidades.
Verificação: Atividade que verifica se o produto está sendo desenvolvido corretamente [29]. A maioria dos tipos de testes é de verificação, tais como os testes de unidade, de interface, de sanidade entre outros.
Validação: Tarefa para avaliar se o software que está sendo desenvolvido é o esperado, isto é, se atende à especificação [29]. Os testes de aceitação, ou testes do cliente, apontam para os desenvolve- dores quais os requisitos que devem ser implementados e quais cenários devem ser satisfeitos, facilitando a validação do sistema por parte do cliente e indicando para os programadores quando uma interação do desenvolvimento foi finalizada.
Testes Caixa Branca ou Caixa Transparente ou Caixa de Vidro: Também conhecido como teste es- trutural, são os testes que fazem verificações baseadas na implementação [95].
Testes Caixa Preta: Também conhecido como testes funcionais, são aqueles que verificam funcionali- dades sem conhecer a implementação [21].
Testes Caixa Cinza: É uma mistura dos testes caixa branca e preta, isto é, envolve os dois conceitos dentro de um mesmo cenário de verificação.
Erros e Testes de Regressão: Quando um erro é identificado em um trecho de código que estava fun- cionando corretamente em versões anteriores do sistema, dizemos que é um erro de regressão, isto é, um erro que foi adicionado durante alguma manutenção. Pensando em verificações manuais, dizemos que testes de regressão são aqueles que buscam encontrar este tipo de erro. Contudo, com testes automatizados esses termos são raramente utilizados, pois todos os testes passam a ser testes de regressão, já que todos ajudam a evitar esse tipo de erro.
Testes de Correção: São tipos de verificações que buscam erros no sistema, tais como os testes de unidade, integração, interface de usuário e aceitação. O teste de longevidade também é verifica a correção, mas é específico para verificar erros que só tendem a ocorrer depois de um certo tempo de execução do sistema.
Versões Alfa e Beta: Quando uma versão do software está finalizada e aparentemente estável, dizemos que sua versão é alfa, pois ele é liberado para uso por um grupo específico de usuários de homolo- gação. Já o software que está em ambiente de produção real e permite que qualquer usuário o utilize para testes, dizemos que a sua versão é beta.
Caso de Falso Positivo: Caso de teste que teve sucesso apesar do que está sendo verificado conter erros. Normalmente isso ocorre por uma falha do teste que não fez todas as verificações esperadas, mas também pode ser por erros no próprio código da bateria de testes.
Caso de Falso Negativo: Caso de teste que falha apesar do que está sendo verificado estar correto. Qualquer erro de implementação nos testes pode criar este cenário.
Padrões: Descrevem soluções para problemas recorrentes no desenvolvimento de sistemas de software. Este termo surgiu dos Padrões de Projeto (Design Patterns) de sistemas orientados a objetos [61]. Também existem padrões relacionados com testes automatizados [99], que são soluções comuns para organizar os casos de testes, para criar verificações mais robustas etc.
Antipadrões: Antipadrões são erros recorrentes, comumente realizados em diferentes contextos. Um Antipadrão descreve o erro e formas de evitá-lo.
Indícios de Problemas: Também conhecido como “cheiros”, são características do software, do código-fonte ou até mesmo da forma de desenvolvimento que dão indícios que alguma solução equivocada foi utilizada.
Testabilidade: É uma característica que indica o quão fácil de ser testado é um sistema. Um sistema com alta testabilidade é fácil de ser testado.
Os termos testes funcionais e estruturais (testes de caixa branca, preta e cinza) não serão utilizados neste trabalho, e sempre que necessários serão substituídos por termos que explicitem o objetivo do teste. Isso por dois motivos: não faz parte dos objetivos do trabalho estudar e comparar essas diferentes técnicas de testes pois já existem outros trabalhos sobre isso [95]; e também para evitar problemas de má interpretação durante a leitura desta dissertação ou durante o uso de ferramentas de testes que utilizam convenções diferentes. Por exemplo, o famoso arcabouço para desenvolvimento Web Ruby on Rails define testes funcionais como os de unidade referente a camada dos controladores, do padrão arquitetural MVC [32].
Será recorrente neste trabalho o uso de siglas que são habitualmente utilizadas pelas comunidades ágeis de testes automatizados. Algumas vezes, existe mais de uma sigla para a mesma ideia, ou duas muito parecidas que podem ser confundidas durante a leitura. Por isso, abaixo segue uma breve descrição daquelas mais comuns, sendo que algumas delas serão mais aprofundadas pelo trabalho enquanto outras só serão citadas.
SUT System Under Test, ou Sistema em Teste: É a aplicação que está sendo exercitada e verificada pelos testes automatizados.
AUT Application Under Test, ou Aplicação em Teste: Análogo SUT.
DDD Domain-Driven Design, ou Design Dirigido pelo Domínio: simplificadamente, é uma abordagem de desenvolvimento de software que propõe que o design do sistema seja fortemente conectado ao modelo de negócios, não simplesmente em arquiteturas definidas exclusivamente por desenvolve- dores ou por ferramentas [8].
TAD Test After Development, ou Testes Após a Implementação: Técnica de escrever testes automatiza- dos depois da implementação (Seção 9.1).
TFD Test First Development, ou Testes Antes da Implementação ou Testes a priori: Técnica de escrever testes automatizados antes da implementação (Seção 9.2).
TDD Test-Driven Development, ou Desenvolvimento Dirigido por Testes: Técnica de desenvolvimento baseada em iterações curtas do ciclo: escrita de um teste de unidade, implementação da mínima porção de código de produção que seja suficiente para o teste passar e, por último, refatoração do código caso seja necessário. Apesar de os testes serem escritos antes da implementação, esta técnica não é o mesmo que TFD (Seção 9.3).
BDD Behavior-Driven Development, ou Desenvolvimento Dirigido por Comportamento: É um apri- moramento da linguagem de TDD para criar uma linguagem ubíqua entre cliente e equipe de desenvolvimento, que segue o mesmo princípio dos testes de aceitação. BDD sugere o uso dos conceitos de DDD para substituir o vocabulário tradicional de testes de TDD por um vocabulário que seja próximo de uma especificação. Dessa forma, BDD pode ser utilizado tanto para os testes de unidade quanto para os testes de aceitação (Seção 9.4).
ATDD Acceptance-Test Driven Development, ou Desenvolvimento Dirigido por Testes de Aceitação: Técnica que sugere que o desenvolvimento siga um ciclo semelhante ao de TDD, mas que envolve os testes de aceitação e os de unidade. O ciclo sugere que sejam escritos primeiramente os testes de aceitação de uma história (conjunto de requisitos), que guiarão a implementação com TDD dos primeiros testes de unidade para a história correspondente. Após os testes de unidade estarem finalizados, deve ser feito os ajustes finais do teste de aceitação e então executá-los. Quando o teste de aceitação obtém sucesso, a história pode ser finalizada. Dessa forma, os testes de aceitação também são indicadores de quando uma história foi finalizada.
STDD Story Test-Driven Development, ou Desenvolvimento Dirigido por Testes da História: Mesmo que ATDD e que Customer Test Driven Development.
TDDD Test-Driven Database Design, ou Modelagem do Banco de Dados Dirigido por Testes: A ideia é aplicar as práticas de TDD na criação de um esquema de banco de dados [2].
CT Continuous Testing: É a prática de executar os testes automatizados continuamente, através de um programa que detecta qualquer alteração de código [124]. Ela foi originada a partir de TDD, que requer que os testes sejam executados muitas vezes em poucos minutos. Uma ferramenta de CT fica observando os arquivos de código-fonte do sistema e dos testes, se algum deles for modificado e salvo, a ferramenta automaticamente executa uma bateria de testes que ela julgar pertinente. Este processo diminui a necessidade de intervenção humana no manuseio de ferramentas e acelera a obtenção de feedback.