Como o Bloqueio do Implícito pode atrapalhar o teste da sua aplicação

Quando temos um problema para resolver, nos deparamos com uma definição deste problema que muitas vezes não está clara o suficiente, pois tem pontos que ainda estão implícitos. Do ponto de vista de teste de software, isto acontece na etapa de entendimento dos requisitos da aplicação. Neste artigo, vamos falar sobre o que é o Bloqueio do Implícito, o impacto que ele pode causar nas atividades de Teste de Software e, por fim, apresento algumas sugestões do que fazer durante a análise de requisitos para termos requisitos mais claros e assertivos.

O Bloqueio do Implícito

O termo “Bloqueio do Implícito” foi cunhado por Murilo Gun, Palestrante e Professor de Criatividade, que estudou sobre futuro, inovação e criatividade na Singularity University, NASA Research Park, Silicon Valley.

Coisas implícitas podem ser de dois tipos: pressupostas ou subentendidas. Enquanto o pressuposto surge na forma que o emissor transmite a informação, o subentendido tem mais a ver com a forma que o receptor recebe e como ele associa as partes que ele não entendeu com as coisas que ele acha.

Podemos dizer que um problema tem vários elementos que o compõe.

De maneira ilustrativa, vamos considerar esta imagem abaixo como um problema, que é composto por vários elementos, que consideramos lacunas, pois inicialmente, elas ainda não foram clarificadas.

Figura 01: Problema composto por elementos que ainda não foram clarificados

Um problema tem elementos que são explícitos, verdadeiros e que estão muito bem claros em sua descrição.

Figura 02: Problema com alguns elementos explícitos já clarificados (em preto)

Um problema possui também elementos que são implícitos pressupostos, são elementos que não estão explícitos, porém a gente pressupõe que é isso, pois o emissor faz a gente pensar desta forma. Não está óbvio, está implícito, mas pressuposto, e a gente preenche estas lacunas do problema com estes entendimentos pressupostos.

Figura 03: Problema complementado com elementos implícitos pressupostos (em azul)

Aí vem o questionamento: e o restante das lacunas que sobraram em nosso problema, o que a gente faz com elas? É aí que nos deparamos com o maior obstáculo na resolução de problemas, que são os elementos implícitos subentendidos. É neste momento que você pega as últimas lacunas do problema e, ao invés de buscar entender e conhecer profundamente, você simplesmente substitui pelos seus achismos, pelo que você acha que é.

Figura 04: Problema complementado com os elementos implícitos subentendidos (em laranja)

A solução para isso é bem simples: você precisa analisar criticamente tudo que está implícito pressuposto e subentendido.

Como seria isso na prática?

Você se deparou com um problema e ele tem os explícitos verdadeiros.

Figura 05: Problema com alguns elementos explícitos já clarificados (em preto)

Alguns elementos estão pressupostos! Para você não pecar por omissão, vale a pena fazer uma análise crítica para transformar o implícito pressuposto em verdade absoluta. Confira, verifique, cheque. Está OK? É isto mesmo? Ótimo!

Figura 06: Problema composto por elementos implícitos pressupostos que foram analisados criticamente (lacunas que eram brancas e agora estão em preto)

O problema continua com lacunas e, ao invés de preenchê-las com coisas subentendidas, faça uma análise crítica também, investigue, pesquise, pergunte, para que você possa trocar estas lacunas por verdades que te darão exatamente a clareza sobre o que é o problema.

Figura 07: Problema composto por elementos implícitos pressupostos que foram clarificados e explicitados (lacunas restantes que eram brancas e agora estão em preto)

Na maioria das vezes que as pessoas dão soluções não tão satisfatórias para os problemas e algo dá errado, as pessoas costumam dizer que “imaginaram isso ou aquilo”…

Como assim você imaginou um problema?

Um problema não é para imaginar, um problema é para investigar.

Bloqueio do Implícito e o Teste de Software

Certo, mas, o que isto tem a ver com teste de software? Tudo!

Uma das atividades mais importantes de uma pessoa que testa aplicações é o entendimento do problema do cliente e do requisito do sistema a ser testado.

É neste momento que muitas vezes os integrantes do time se deparam com um requisito onde há elementos explícitos, implícitos pressupostos e implícitos subentendidos.

Caso estes requisitos implícitos não sejam tratados de maneira adequada, os cenários de teste, testes automatizados e até a estratégia de testes estará comprometida. E a depender de com qual sistema estivermos lidando, podemos comprometer inclusive o negócio do cliente ou vidas.

Como não deixar que o Bloqueio do Implícito impacte as atividades de Teste de Software?

Pare de preencher as lacunas dos requisitos com os seus padrões pessoais, com os seus achismos, com as coisas que você imagina que estejam certas.

Busque sempre a clareza dos requisitos!

Se existe algo que não ficou claro, pergunte, tire suas dúvidas, use exemplos para tentar clarificar, valide com o Product Owner, valide com o cliente…

Além de clarificar os itens que estão faltando nos requisitos (as lacunas), busque por:

• regras conflitantes;
• pré-requisitos não definidos;
• dependências não definidas;
• informações ambíguas;
• informações duplicadas;
• informações incompletas;
• impactos esperados em outras funcionalidades da aplicação não documentadas.

Afinal, não é possível garantir a aderência da aplicação a um requisito se este requisito não estiver totalmente claro e bem definido, não é?

Se puder escolher hoje uma das atividades que você realiza para se dedicar a evoluir, escolha a etapa de entendimento dos requisitos. Ela é a etapa base para que todo o processo de testes possa ter sucesso!

Clarifique! Isto vai elevar bastante a qualidade do produto que você testa e vai te fazer evoluir como profissional da área de qualidade de software!