Testes de Caixa Cinza existem?
A abordagem de caixa cinza é amplamente descrita como um híbrido das abordagens de testes de caixa branca e de caixa preta, onde o testador possui algum conhecimento da estrutura/código do sistema que está sendo testado. E alguns textos ainda complementam esta definição dizendo que os testes de caixa cinza são processos para depurar softwares a partir de entradas pelo frontend e verificações e validações das saídas a partir do backend.
Para analisarmos estas definições de testes caixa cinza, precisamos conhecer os conceitos das abordagens de testes de caixa preta e de caixa branca.
- Teste de caixa branca: também conhecidos como testes não funcionais ou testes estruturais, são geralmente escritos pelos próprios desenvolvedores e servem para testar diretamente as estruturas do código. São baseados num minucioso exame dos detalhes procedimentais onde os caminhos lógicos do software são testados.
- Testes de caixa preta: também conhecidos como testes funcionais, são baseados nos requisitos funcionais do software, possuem dados de entrada e saída esperada, ambos controlados, e são baseados na abstração do código, nas ações dos usuários e nas respostas do sistema.
Vamos analisar a definição de caixa cinza com os conceitos das abordagens de caixa branca e de caixa preta
“Os testes de caixa cinza são amplamente descritos como um híbrido das abordagens de testes de caixa preta e de caixa branca…”
As abordagens caixa branca e caixa preta são bem definidas e bem distintas entre si. Caixa branca testa as estruturas de código a nível de componente enquanto caixa preta testa a funcionalidade de forma controlada, abstraindo o código e possuindo entradas definidas e saídas esperadas.
“…onde o testador possui algum conhecimento da estrutura/código do sistema que está sendo testado.”
Pressman, sobre caixa branca, afirma que “os caminhos lógicos do software e as colaborações entre componentes são testados exercitando conjuntos específicos de condições e/ou ciclos” (engenharia de software uma abordagem profissional, roger s. Pressman, 7a edição – 2011). Possuir conhecimentos da estrutura ou do código do sistema que está sendo testado e não testar as estruturas a nível de componentes não gera nenhuma relação com a abordagem de caixa branca.
“…os testes de caixa cinza são processos para depurar softwares…”
O teste aponta erros, enquanto depuração aponta no código, onde estes erros se encontram, logo, ou é depuração ou é teste.
“…a partir de entradas pelo Frontend e verificações e validações das saídas a partir do backend.”
A definição de caixa preta não nos restringe de coletarmos o resultado obtido diretamente no backend. Testar a partir do frontend sob a ótica da funcionalidade, ainda caracteriza a realização de testes funcionais, independentemente da coleta dos resultados ser feita no backend. E mesmo sabendo que ao testar os caminhos positivos, alternativos e negativos estamos também testando as estruturas de controle, não consideramos caixa branca pois não estamos testando a nível dos componentes.
Conclusão
As abordagens de caixa preta e de caixa branca são responsáveis por encontrar tipos de erros específicos. Caixa branca, por exemplo, encontraria variáveis não inicializadas ou estruturas do código nunca acessadas, enquanto caixa preta, encontraria uma divisão por zero ou divergências na interface. Não existe um tipo específico de erro que a “abordagem” de caixa cinza seja responsável por encontrar e isso por si só já a desqualifica como abordagem.
Com base nesta análise, podemos concluir que não existe confluência das abordagens caixa branca e caixa preta que justifique a definição de uma nova abordagem teste híbrida, pois as definições de caixa cinza descrevem de forma “romantizada” uma abordagem de testes funcionais(caixa preta) onde temos massas de teste controladas na entrada, via frontend, e a verificação e validação dos resultados sendo obtida diretamente no backend.
