Falando Sobre Cobertura

Texto original de: Michael Bolton, disponível aqui
Traduzido por: Rafael Bandeira

Há um tempo, escrevi um post falando sobre cobertura. De fato, escrevi alguns posts a respeito, mas estou falando especificamente deste aqui. Uma pergunta surgiu no LinkedIn e me ajudou a perceber que eu deixei passar algo importante.

No post, ao me referir sobre cobertura como “a proporção do produto que foi testado”, eu disse:

Um produto de software não é algo estático, tangível; é um conjunto de relacionamentos. Com o que se parece 100% de um produto, de um conjunto de relacionamentos? Essa é uma pergunta importante, porquê, a não ser que saibamos o que é 100%, a ideia de “proporção” não tem peso algum.

E também disse:

No glossário de termos do Rapid Software Testing, quando falamos sobre cobertura de maneira geral, cobertura é o quão minuciosamente examinamos um produto em relação a algum modelo.

Para alguns, isso levanta a questão “como mensuramos cobertura?”, o que é a mesma coisa que perguntar “como mensuramos o quão minucioso foi o nosso teste?”

A resposta para essa pergunta começa de maneira simples: na maior parte das vezes, não mensuramos. Na maior parte das vezes, não podemos mensurar cobertura de maneira objetiva, válida e confiável, porquê, diferente de comprimento, votos ou bolas, cobertura não tem uma unidade de medida. Por exemplo:

• Contar o número de casos de teste não nos diz nada sobre as condições ou fatores ou observações em que esses casos de teste focavam.
• Contar a quantidade de linhas do código do produto que foram exercitadas por alguma verificação automatizada não nos diz o que essas verificações avaliavam.
• Contar o número de elementos numa lista de riscos não leva em consideração a relevância destes riscos.
• Se certificar de que existe “um caso de teste positivo” e “um negativo” para cada “requerimento” não só levanta a questão do que é um caso de teste positivo e negativo, como também a questão de como por uma unidade de medida em um requerimento.

Certos momentos, conseguimos contar algumas coisas que têm algum peso na cobertura. “Há 8 perfis de usuários disponíveis neste sistema. Para quantos destes nós performamos testes que avaliam se as permissões e restrições apropriadas estão em funcionamento?”. Se a resposta for menos que oito, sabemos alguma coisa sobre a incompletitude de nossa cobertura. A quantidade de perfis que foram cobertas sugerem algo, talvez, mas não dizem sobre o quão profundamente ou minuciosamente foram examinadas. Não diz se o teste foi simples ou complexo, empático ou agressivo, trivial ou importante.

Particularmente, a “porcentagem de casos de teste que foram automatizados” é uma forma de medida seriamente vazia. Um “caso de teste que foi automatizado” pode se referir a uma única chamada de função ou uma única asserção, ou uma chamada a dúzias de funções com milhares de asserções. Um “caso de teste automatizado” pode se referir a uma simples verificação de unidade ou um conjunto de verificações dentro de um conjunto complexo de transações representando algum fluxo. “83% de nossos exemplos estão sendo verificados por máquina; o resto é feito manualmente” levanta vários questionamentos sobre o que está nesses exemplos. Isso também ignora o fato de que a interação humana e observação do produto é profundamente diferente de uma verificação automatizada de algum tipo de saída.

Como James Bach fala, quando alguém diz “nós temos 61 casos de teste”, eles comumente querem dizer que eles têm 61 entradas em alguma ferramenta de gestão de caso de teste. Isso pode ter algum tipo de apelo simplista para alguns gestores porquê, como alguns testers dizem, a gestão “quer ver números”.

Não estou convencido de que seja verdade. Acredito que é mais provável que a gestão queira ver. Isso é, eles querem ser capazes de observar e avaliar e racionalizar. Ajudá-los a fazer isso com coisas como cobertura começa com sumarizar nosso trabalho, nossos modelos mentais e pensamentos a respeito disso, e torná-los legíveis.

Legibilidade é uma ideia importante, com vários bugs e funções associadas. Para uma perspectiva orientada a bugs, dê uma olhada no post de Venkatesh Rao sobre o assunto, e o excelente livro de James C. Scott, Seeing Like a State. Legibilidade é uma razão pela qual ferramentas de gestão de casos de teste descoladas são tão apelativas para pessoas gestoras; gráficos e tabelas provêm uma reconfortante e visível ilusão de entendimento. “Tá vendo?”

O problema é que cobertura, assim como qualidade, não se submete bem ao tipo de mensuração que Cem Kaner e Pat Bond falam a respeito nesse artigo extremamente importante. “Mensuração”, eles dizem, “é uma delegação empírica e objetiva de números, de acordo com a regra derivada de um modelo ou teoria, aos atributos de objetos ou eventos com a intenção de descrevê-los”. Esse artigo levanta várias questões. Para nós, elas podem incluir:

• O que é o modelo, a construção, que forma a base da sua mensuração? (O que é um caso de teste, na real? O que pode ser mais ou menos que um caso de teste? Qual é a unidade de cobertura?)
• Qual é a operação que você usa para atribuir um número à observação? (Nós contamos as linhas de asserção em algum código de teste ou as linhas no arquivo do Excel e pronto?)
• Como — e o quão bem — o número que você está usando mapeia o atributo para a descrição? (Tudo o que chamamos de caso de teste é equivalente em termos de minuciosidade de nosso teste?)
• Quais são as ameaças à validade dessa construção? (Como podem as formas com que contamos cobertura não realmente representar a minuciosidade de nosso teste, logo nos enganar?)

Assim como qualidade não é uma propriedade do seu produto, cobertura não é uma propriedade do seu teste. Qualidade e cobertura são conjuntos complexos de relacionamentos entre produtos, pessoas, modelos, observações e avaliações. Eles estão sujeitos à Lei Relativa. Não dá pra verdadeiramente contar essas coisas. Ainda assim, o desejo de um gestor ocupado de modelar coisas complexas em termos simples não é, necessariamente, irracional. Seria bom, para nós, ajudá-los a fazer isso de uma maneira que seja assertiva e informativa, em vez de errônea e perigosa.

Como qualidade, não dá para mensurar cobertura, mas ela pode ser avaliada e discutida. Como você pode iniciar a discussão plausível e sensível de maneira a evitar as armadilhas da construção de validade?

Aqui está uma maneira: podemos escolher um modelo e representar cobertura de maneiras que podem ser assertivas sem serem precisas. Quando buscamos assertividade e reconhecemos sua imprecisão, nossa história sobre assertividade pode ser questionada. Esse questionamento traz análises, discussões e avaliações, o que é exatamente o que a gestão precisa para fazer decisões informadas quanto a riscos.

Então: considere enquadrar a cobertura de determinados modelos e áreas do produto em termos de uma escala nominal que tenha alguns aspectos de uma escala ordinal:

LEVEL 0

Nós não sabemos muito sobre essa área. Nós sabemos que essa área existe, mas sua maior parte é uma caixa-preta para a gente, até então. Quaisquer atividades de teste que houveram aqui, nós não confiamos muito nelas.

LEVEL 1

Estamos começando a conhecer essa área. Fizemos o reconhecimento básico; inspecionamos; fizemos alguns testes de fumaça e de sanidade. Podemos ter alguns artefatos que representem nossos modelos emergentes, o que irão nos ajudar a falar sobre eles e ir mais fundo. Se o produto estivesse completamente quebrado, nós saberíamos.

LEVEL 2

Aprendemos bastante sobre essa área. Olhamos o núcleo e os aspectos críticos. Estamos coletando e diversificando nossas ideas sobre como cobrir mais profundamente. Fizemos alguns testes substanciais focados nos padrões comuns de uso, nos riscos suspeitados de maior significância e os mais importantes critérios de qualidade. De qualquer maneira, ainda há outras formas em que podemos buscar por problemas ou lugares que ainda não olhamos.

LEVEL 3

Temos um entendimento plausível sobre essa área. Olhamos profundamente de várias perspectivas e aplicamos múltiplas técnicas de teste diferentes. Fizemos testes agressivos, complexos e desafiadores numa variedade de critérios de qualidade. Se houvesse um problema ou uma função não reconhecida nessa área que nós não soubéssemos, seria uma grande surpresa. Além disso, qualquer problema que escape apresentará uma oportunidade para nós de aprendermos algo profundo e importante (em vez de ser evidência de que não tentamos direito).

Com isso, você pode ser capaz de dizer “nós sabemos bem pouco sobre essa area do produto; sabemos bastante sobre essa área” e pode ser capaz de dizer “nós cobrimos essa parte do produto mais minuciosamente que aquela parte”. E então deixar a discussão começar.