Liderança nos Testes: Modelação e Cobertura

No mundo dos testes de software, uma liderança eficaz sabe definir uma orientação clara sobre a forma como as estratégias de teste se alinham com os objetivos de desenvolvimento. À medida que os sistemas de software se tornam cada vez mais complexos, os métodos de teste tradicionais têm dificuldade em acompanhar esse ritmo.

É aqui que abordagens inovadoras, como a modelação de testes e a análise da cobertura, se tornam cruciais. Estas práticas garantem que as equipas abrangem os percursos críticos e os casos-limite, permitindo uma melhor colaboração, um risco reduzido e uma entrega mais rápida.

Neste artigo, vamos explorar o que significa liderar tendo em consideração a modelação e a cobertura. Iremos abordar a forma como os líderes de testes podem tirar partido destas estratégias para otimizar os seus processos, melhorar a qualidade do produto e garantir uma cobertura de testes abrangente — tudo isto enquanto promovem uma cultura de excelência e responsabilização. Quer seja gestor de QA, líder de equipa ou simplesmente queira aprofundar os seus conhecimentos sobre liderança em testes, este guia irá fornecer-lhe informações práticas e técnicas para elevar o nível dos seus testes.

Vamos começar.

O que é um modelo de teste?

Os testes são um processo no qual criamos modelos mentais do ambiente, do programa, da natureza humana e dos próprios testes. Cada modelo é utilizado até aceitarmos que o comportamento está correto ou até o modelo deixar de ser suficiente para o objetivo pretendido.

Boris Beizer, Técnicas de Teste de Software, 1990

A conceção de testes é o processo através do qual selecionamos, entre a infinidade de opções disponíveis, os testes que acreditamos serem mais valiosos para nós e para as partes interessadas. Os modelos de teste ajudam-nos a selecionar testes de forma sistemática e são fundamentais para os testes.

A forma como os profissionais de testes utilizam os modelos:

1. Identificamos e exploramos fontes de conhecimento para criar modelos de teste.
2. Utilizamos estes modelos para questionar e validar as nossas fontes, melhorando tanto as fontes como os modelos.
3. Utilizamos estes modelos para orientar os testes e também o desenvolvimento.

Dada uma missão de teste, a nossa primeira tarefa consiste em identificar fontes de conhecimento. Estas podem ser:

• Documentação: especificações, conceções, requisitos, normas, orientações, entre outros.
• Pessoas: partes interessadas, utilizadores, analistas, designers, programadores e outros.
• Experiência: os seus próprios conhecimentos e experiência com sistemas semelhantes (ou diferentes), as suas preferências, preconceitos, suposições, intuições, convicções e enviesamentos.
• Sistema novo: o sistema sob teste, caso exista, esteja disponível e seja acessível.
• Sistema antigo: o sistema que será substituído é obviamente uma fonte — pode, em algumas áreas de funcionalidade, fornecer uma referência para o comportamento esperado.

É importante salientar que todas as nossas fontes de conhecimento são falíveis e incompletas, tal como os nossos modelos. Os profissionais de testes utilizam experiência, competências e discernimento para analisar estas fontes, compará-las, contrastá-las e questioná-las, chegando assim a um consenso. 

Todos os modelos estão errados; alguns são úteis

George Box, economista.

Um modelo de teste pode ser uma lista de verificação ou um conjunto de critérios. Também pode ser um diagrama derivado de um documento de conceção ou de uma análise de texto narrativo. Muitos modelos de teste nunca são passados para o papel — podem ser modelos mentais construídos especificamente para orientar o profissional de testes enquanto explora o sistema sob teste.

O objetivo dos modelos é simplificar situações complexas, omitindo detalhes que não são relevantes naquele momento. Utilizamos modelos para simplificar um problema — selecionando, por exemplo, os elementos a testar. O modelo orienta o nosso raciocínio e selecionamos testes identificando ocorrências de algum aspeto fundamental do modelo.

Podemos selecionar ramificações num fluxograma ou num diagrama de fluxo de controlo, transições de estado num modelo de estados, limites num modelo de um domínio de entrada (ou saída) e cenários derivados de histórias de utilizador escritas na linguagem específica de domínio Gherkin.

Mas atenção: por vezes, os modelos fazem omissões que não são seguras — talvez o modelo simplifique excessivamente uma situação — e temos de prestar atenção a isso. Para tornar os seus modelos de teste mais eficientes, é essencial utilizar software especializado de gestão de testes.

Se não tivermos modelos diretamente provenientes das nossas fontes, temos de os criar. Por exemplo, quando os requisitos são apresentados sob a forma de texto narrativo, precisamos de utilizar a linguagem dos requisitos para derivar as funcionalidades e a lógica do seu comportamento. Isto pode ser difícil para programadores e profissionais de testes e, frequentemente, é um esforço colaborativo, mas temos de perseverar.

Utilizar modelos para testar

Utilizamos modelos de teste para:

• Simplificar o contexto do teste. Os detalhes irrelevantes ou insignificantes são ignorados no modelo.
• Concentrar a atenção numa perspetiva do comportamento do sistema. Estas podem ser funcionalidades críticas ou arriscadas, aspetos técnicos, operações do utilizador de interesse ou aspetos da construção ou arquitetura do sistema.
• Gerar um conjunto de testes únicos (dentro do contexto do modelo) e diversificados (em relação a esse modelo).
• Permitir que os testes sejam estimados, planeados, monitorizados e avaliados quanto à sua completude (cobertura).

Do ponto de vista do testador, um modelo ajuda-nos a reconhecer aspetos do sistema que podem ser objeto de um teste.

Modelos e cobertura

Cobertura é o termo que utilizamos para descrever o rigor ou a completude dos nossos testes relativamente ao nosso modelo de teste. Um item de cobertura é algo que queremos exercitar nos nossos testes.

Idealmente, o nosso modelo de teste deve identificar os itens de cobertura de forma objetiva. Quando planeámos ou executámos testes que abrangem os itens identificados pelo nosso modelo, podemos quantificar a cobertura alcançada e, como proporção de todos os itens do modelo, expressá-la em percentagem.

Qualquer modelo que permita identificar itens de cobertura pode ser utilizado.

Os modelos são frequentemente gráficos, incluindo exemplos como fluxogramas, casos de utilização, diagramas de sequência, entre outros. Estes e muitos outros modelos têm elementos (ou formas) ligados por linhas ou setas. Normalmente, são designados por grafos orientados. 

Imagine um modelo gráfico composto por formas e setas. Poderiam ser definidos, pelo menos, dois objetivos de cobertura:

• Cobertura de todas as formas
• Cobertura de todas as setas
• E assim por diante

Assim, qualquer modelo que seja um grafo orientado pode ser tratado da mesma forma.

Os modelos informais tendem a ser listas de verificação ou critérios utilizados para gerar ideias e criar uma lista de itens de cobertura, desencadear ideias para testa gem ou para testes numa sessão de testes exploratórios. Estas listas ou critérios podem ser predefinidos ou preparados como parte de um plano de testes ou adotados numa sessão de testes exploratórios.

Os modelos informais diferem dos modelos formais porque a derivação dos itens de cobertura depende da experiência, intuição e imaginação do profissional, pelo que a cobertura utilizando estes modelos nunca pode ser quantificada. Nunca podemos saber o que significa uma cobertura completa relativamente a estes modelos.

Os modelos simplificam, por isso utilize mais do que um

Um bom modelo proporciona uma forma de compreender a complexidade e consegue-o, em parte, através da exclusão de detalhes que não são relevantes. O seu modelo pode utilizar o conceito de estado, modos de falha ou fluxos, combinações de entradas, valores de domínio, entre outros. 

Um único modelo nunca é suficiente para testar completamente um sistema. Todos os modelos implicam compromissos, pelo que precisamos de vários modelos. Este conceito é normalmente designado por «meias-medidas diversificadas». Isto significa que precisamos de uma diversidade de modelos parciais para testar corretamente um sistema.

Embora normalmente não sejam descritas nestes termos, as fases de teste num projeto em cascata utilizam modelos de diferentes perspetivas. Os testes unitários, de integração de subsistemas, ao nível do sistema e de utilizador têm objetivos diferentes; cada um utiliza um modelo e uma perspetiva diferentes – é daqui que provém a diversidade.

Utilizar modelos para gerir

Os modelos estão no centro dos testes e também da gestão de testes. Existem quatro aspetos fundamentais:

• Envolvimento das partes interessadas
• Âmbito
• Cobertura
• Estimativa e monitorização do progresso

Envolvimento das partes interessadas

Quando planeamos e definimos o âmbito dos testes e explicamos o progresso e o significado da cobertura às partes interessadas, temos de utilizar modelos que sejam compreensíveis e relevantes para os objetivos dessas partes.

Se planearmos um teste de utilizador, iremos provavelmente adotar o fluxo do processo empresarial como o nosso modelo e como um modelo para rastrear percursos que permitam exercitar as funcionalidades do sistema importantes para o utilizador. Se estivermos a testar a integração de componentes de serviço em nome de um arquiteto técnico, utilizaremos o modelo arquitetónico, os diagramas de colaboração, as especificações de interface e assim por diante como base dos nossos testes. Se estivermos a testar funcionalidades definidas pelos utilizadores, utilizaremos as histórias de utilizador que resultaram do trabalho colaborativo de requisitos realizado anteriormente.

Se as partes interessadas não compreenderem os seus modelos, não compreenderão, confiarão nem investirão nos seus testes. Podem nem sequer confiar em si.

Gestão do âmbito

A primeira atividade numa disciplina de pensamento sistémico consiste em definir os limites de um sistema. Nos testes, o primeiro modelo que definir ajudará a delimitar o âmbito dos testes. O diagrama abaixo é um esquema da arquitetura do sistema – um «sistema de sistemas» – numa organização.

Cada sistema (os círculos concêntricos) está inserido numa área de aplicação, como CRM, contabilidade ou o sítio Web. Todos os sistemas e áreas de aplicação estão dentro do «sistema de sistemas». Naturalmente, não existem pormenores no modelo, mas é fácil ver como cada sistema se enquadra na arquitetura geral.

Poderíamos facilmente definir o âmbito dos nossos testes como sendo, por exemplo, os sistemas ERP.

No segundo diagrama abaixo, acrescentámos mais alguns pormenores à arquitetura do sistema e sugerimos três formas de definir o âmbito de modo mais específico.

• Os sistemas sombreados a amarelo são os chamados sistemas de registo. Estes sistemas podem, por exemplo, partilhar uma base de dados, e as alterações ao esquema da base de dados podem afetar negativamente qualquer um destes sistemas – e fazer parte do âmbito dos testes.
• Os sistemas delimitados pela linha roxa podem partilhar alguma funcionalidade ou infraestrutura comum – talvez utilizem todos um conjunto comum de serviços Web, o mesmo sistema de mensagens ou sejam executados no mesmo servidor.
• A linha azul tracejada representa um percurso do utilizador que utiliza os sistemas ligados pela linha. Talvez o percurso do utilizador tenha sido alterado e o nosso foco esteja na consistência e precisão do fluxo de dados entre estes sistemas.

Um modelo ajuda a definir o âmbito de um teste e também a explicar o âmbito às partes interessadas em termos que compreendam, valorizem e (esperemos) aprovem.

Gestão da cobertura

A medição da cobertura pode ajudar a tornar os testes mais geríveis. Se não tivermos uma noção da cobertura, poderemos não conseguir responder a perguntas como «o que foi testado?», «o que não foi testado?», «já terminámos?», «quantos testes faltam?». Isto é particularmente incómodo para um gestor de testes.

A cobertura que planeamos alcançar é o passo seguinte natural depois de definido o âmbito.

Os modelos de teste e as medidas de cobertura podem ser utilizados para definir objetivos quantitativos ou qualitativos para a conceção e execução dos testes. Em diferentes graus, podemos utilizar esses objetivos para planear e estimar. Também podemos medir o progresso e inferir o grau de profundidade ou a completude dos testes que planeámos ou executámos. No entanto, precisamos de ter muito cuidado com quaisquer medidas ou percentagens quantitativas de cobertura que utilizemos.

Uma medida de cobertura (baseada num modelo formal de teste) pode ser calculada objetivamente, mas não existe nenhuma fórmula ou lei que indique que uma cobertura X significa uma qualidade Y ou uma confiança Z. Todas as medidas de cobertura fornecem apenas perspetivas indiretas, qualitativas e subjetivas sobre o grau de profundidade ou a completude dos nossos testes. Não existe uma relação significativa entre a cobertura e a qualidade ou aceitabilidade dos sistemas.

Os objetivos quantitativos de cobertura são frequentemente utilizados para definir critérios de saída para a conclusão dos testes, mas estes critérios são arbitrários. Um objetivo de cobertura mais rigoroso pode gerar o dobro dos itens a abranger. No entanto, o dobro dos testes, com o dobro do custo, não torna um sistema duas vezes mais testado nem duas vezes mais fiável. Essa interpretação não tem sentido e é absurda.

Por vezes, os modelos formais utilizados para definir e construir um sistema podem ser impostos aos testadores, para que estes os utilizem na definição dos objetivos de cobertura. Noutras ocasiões, os testadores podem dispor de pouca documentação e ter de criar os seus próprios modelos. A seleção de qualquer modelo de teste e objetivo de cobertura é, em certa medida, arbitrária e subjetiva. Consequentemente, os modelos de teste informais e as medidas de cobertura podem ser tão úteis como os modelos formais estabelecidos.

Exercício rápido de criação de modelos

Um rápido exercício para terminar. Nos exemplos seguintes, esboce o aspeto que pensa que o modelo poderá ter – apenas a sua forma –, seja como imagem/diagrama, tabela ou lista:

• Os utilizadores estão preocupados com os percursos completos no sistema.
• Um serviço de mensagens pode estar em quatro estados: desligado, em execução, a iniciar e a encerrar.
• Uma calculadora de prémios de seguro tem 40 valores de entrada que, em conjunto, influenciam o cálculo; existem dependências entre algumas entradas.
• Um processo de extração/transformação/carregamento tem sete fases. Após a extração, cada fase rejeita registos, envia-os para um ficheiro de pendentes ou transforma-os e encaminha-os para a fase seguinte. A última fase é um processo de carregamento que trata das rejeições. Teste se todos os registos extraídos são contabilizados.

Subscreva a newsletter do The CTO Club para obter mais informações sobre testes!