Liderança em Testes: Testes Baseados no Risco

Os riscos, caso se concretizem, têm um efeito adverso nos nossos projetos. A gestão de riscos consiste em pensar sobre que riscos existem e tomar medidas para reduzir a sua probabilidade, eliminá-los ou reduzir o seu impacto nos objetivos das partes interessadas.

Em algumas empresas, a gestão de riscos é praticada com precisão de engenharia e matemática. No software, não é possível ser muito preciso. A maioria das organizações ainda não pratica testes baseados no risco de forma sistemática. Mas existe uma boa razão para isso: depois de identificados, os riscos dos produtos de software são muitas vezes extremamente difíceis de avaliar.

Do ponto de vista dos testes e da garantia, um risco é um «modo de falha que merece atenção». Os testes baseados no risco são a prática de modelar potenciais modos de falha do sistema como riscos do produto, para apoiar a definição do âmbito, o dimensionamento e a priorização dos testes.

Neste artigo, apresentarei um manifesto de testes baseados no risco. Analisaremos a gestão clássica de riscos e veremos como podemos ajustá-la para que seja útil aos profissionais de testes. Por fim, analisaremos alguns aspetos práticos e considerações que o ajudarão a aplicar o seu próprio método de testes baseados no risco.

• Risco do projeto, do processo e do produto
• Um manifesto de testes baseados no risco
• A abordagem clássica ao risco
• Risco do produto e testes
• Aspetos práticos
• Compreender o papel dos testes na gestão de riscos

Risco do projeto, do processo e do produto

Existem centenas de livros sobre risco e gestão de riscos que apresentam inúmeras abordagens à gestão de riscos ao nível do projeto. Normalmente, estas abordagens centram-se no que designaremos por riscos do projeto e do processo, talvez com um único risco denominado algo como «incumprimento dos requisitos». Ter um único risco relativo aos requisitos não é muito útil, uma vez que não é possível priorizar um único risco para os testes.

Existem três tipos de risco de software.

Risco do projeto: Estes riscos estão relacionados com o projeto no seu próprio contexto. Normalmente, os projetos têm dependências externas, como a disponibilidade de competências, a dependência de fornecedores, prazos fixos ou restrições como um contrato de preço fixo. As dependências externas são da responsabilidade da gestão do projeto.

Risco do processo: Estes riscos estão relacionados principalmente com os aspetos internos do projeto, sendo o planeamento, a monitorização e o controlo do projeto submetidos a análise. Os riscos típicos incluem a subestimativa da complexidade do projeto, do esforço ou das competências necessárias. A gestão interna de um projeto, como um bom planeamento, a monitorização do progresso e o controlo, são responsabilidades da gestão do projeto.

Risco do produto: O risco do produto é a principal área de risco relevante para os profissionais de testes. Estes riscos estão relacionados com a definição do produto, a estabilidade (ou a falta dela) dos requisitos, a complexidade do produto e a propensão da tecnologia para apresentar falhas. 

A partir de agora, iremos concentrar-nos nos riscos do produto. Utilizaremos o termo risco do produto da seguinte forma:

Um manifesto de testes baseados no risco

Nos projetos em que serão assumidos riscos (o que, na nossa opinião, acontece em todos), os profissionais de testes precisam de dar visibilidade dos riscos à gestão e propor métodos de teste fiáveis para abordar esses riscos ao longo de um projeto. 

Esta é a tarefa da gestão: realizar e/ou supervisionar as seguintes tarefas de testes baseados no risco:

A abordagem clássica ao risco

Existem muitas variações, mas a abordagem clássica ao risco tenta ser quantitativa.

Probabilidade, consequência e exposição

Para avaliar um risco do produto, precisamos de compreender qual é a consequência desse modo de falha. Se ocorrer uma falha, dizemos que o risco se concretiza. Depois perguntamos «quão grave é o risco?», também referido como exposição.

Para calcular a exposição, avaliamos o risco em duas dimensões:

• A probabilidade (ou verosimilhança) de um risco se concretizar. Este valor é normalmente expresso como uma percentagem entre (mas não incluindo) zero e 100 por cento.
• A consequência (ou impacto ou perda) da concretização de um risco. Este é o custo potencial dos danos caso ocorra este modo de falha.

A exposição de um risco – quão grave é um risco – é calculada como o produto da probabilidade e da consequência.

A abordagem clássica ao risco carece frequentemente do apoio tecnológico necessário para uma gestão eficiente. As modernas soluções de gestão de testes colmatam esta lacuna ao oferecerem funcionalidades adaptadas aos testes baseados no risco.

Avaliação quantitativa ou qualitativa

Atualmente, é frequentemente difícil prever o custo potencial de uma falha. Sem informações adicionais, é também praticamente impossível prever a probabilidade de uma falha com grande certeza. Por isso, a maioria dos profissionais adota escalas semiquantitativas ou qualitativas para a probabilidade e a consequência.

É comum utilizar intervalos numéricos de um a cinco para ambas as escalas, o que nos dá possíveis valores de exposição de um a vinte e cinco. Contudo, poucos testadores, programadores ou partes interessadas atribuem estes números com confiança, pelo que é comum classificar diretamente a exposição ao risco utilizando uma escala de 1 a 5 ou – ainda mais simplesmente – uma avaliação a vermelho, âmbar e verde. Alguns chegam ao ponto de dizer simplesmente que os riscos estão dentro ou fora do âmbito, mas sugerimos que isto é uma simplificação excessiva.

Quer quantifique os riscos ou utilize um código de cores para os representar na tabela, o aspeto fundamental das avaliações de risco não é a pontuação, mas as conversas e o debate que ocorrem ao atribuir e discutir as pontuações.

Se lhe pedirem para pontuar os riscos utilizando uma precisão superior à das escalas de um a três (ou cinco, no limite), deve ponderar seriamente se os números que atribui têm algum valor real.

A pontuação numérica pode dar uma impressão de rigor científico, mas, se os números forem baseados em palpites, está a enganar-se a si próprio. Se os números revelarem diferenças de opinião, por exemplo, um utilizador diz «cinco» e o programador diz «um!», há uma conversa a ter, pois as expectativas ou perceções são claramente diferentes.

Tenha cuidado ao utilizar um esquema simples de dentro/fora do âmbito para os riscos. Pode ser claro quais os riscos preocupantes que devem ser abordados pelos testes. No entanto, os projetos aprendem ao longo do tempo e sofrem frequentemente atrasos, pelo que é necessário fazer compromissos. Se os riscos não forem priorizados de alguma forma, terá de rever todos os riscos preocupantes para decidir quais poderão ter de ser retirados do âmbito ou nele incluídos.

Abordaremos o âmbito, a priorização e a escalabilidade com mais detalhe em artigos subsequentes, por isso, fique atento.

Risco do produto e testes

A discussão dos riscos (do produto) revelará os receios das partes interessadas relativamente à probabilidade de falha em áreas críticas do projeto ou sistema. Perante uma lista de riscos do produto, como a traduzimos em ações e planos específicos para os testes? Antes de podermos responder a essa pergunta, precisamos de compreender um pouco melhor como os testes afetam ou influenciam as nossas avaliações de risco.

Os testes não reduzem o risco – informam as avaliações de risco

É frequente ouvir pessoas afirmarem que «os testes reduzem o risco». Isso não é verdade — por vezes, os testes podem aumentar o risco. O mantra de que os testes reduzem o risco resulta de uma falta de compreensão tanto dos riscos como dos testes.

Digamos que identificámos um risco de uma funcionalidade poder falhar. Formulamos um teste e executamo-lo. O teste pode passar ou falhar. De que forma afetaria a nossa avaliação do risco o facto de um teste passar ou falhar?

Em primeiro lugar, os testes não têm qualquer efeito na nossa compreensão da consequência de uma falha. A consequência de uma falha é o que é, e os testes não a alteram.

Existem quatro resultados relevantes de um teste e respetivo impacto na probabilidade do risco. Estes estão resumidos nesta tabela:

A execução de testes que associamos a um determinado risco fornece-nos cada vez mais informações para aperfeiçoar a nossa avaliação de risco. Se os testes falharem, a nossa escolha é validada. Quando corrigimos e voltamos a testar, à medida que os testes passam, a nossa avaliação do risco deve diminuir. Mas, se continuarmos a encontrar novos erros ou mais erros, poderemos reavaliar o risco como sendo mais elevado.

Agora que compreende o potencial dos testes para fundamentar a nossa avaliação de risco, podemos analisar a especificação de testes a partir de descrições de riscos.

Planeamento de testes baseado no risco

Enquanto testadores, depois de identificarmos um risco relevante num produto, precisamos de formular um conjunto de testes que demonstre que esse modo de falha é menos provável. Obviamente, a nossa abordagem de teste consistirá em estimular o modo de falha de tantas formas quanto possível e, ao fazê-lo, iremos:

Coletivamente, os nossos testes centram-se nas formas como um determinado modo de falha pode ocorrer. Suponhamos, por exemplo, que o risco era «falha no cálculo correto de um prémio de seguro automóvel». Neste caso, um objetivo de teste adequado poderia ser «demonstrar, utilizando a técnica de todos os pares para as variáveis de entrada, que o sistema calcula corretamente o prémio automóvel». Este objetivo de teste pode ser fornecido a um testador para que este derive, por exemplo, um conjunto abrangente de casos de teste utilizando todos os pares.

Aspetos práticos

Vejamos agora algumas considerações práticas relacionadas com os testes baseados no risco.

E se as partes interessadas não estiverem interessadas em ajudar na avaliação de risco?

Poderá descobrir que é difícil obter tempo das partes interessadas para o ajudarem a identificar e avaliar riscos e a formular o seu plano de testes. 

E se existirem várias opções de teste para um risco do produto?

É claro que este é quase sempre o caso. Por exemplo, para testar uma funcionalidade que suscite preocupação, poderia utilizar qualquer uma de várias técnicas de conceção de testes, ou modelar a funcionalidade de uma forma única e derivar testes a partir desse modelo. Existem várias medidas de cobertura que poderá utilizar para definir um objetivo. Poderá testar uma funcionalidade manualmente ou utilizando uma ferramenta ou outra tecnologia.

Veremos como poderá fazer escolhas no próximo artigo, «Quanto é suficiente testar?».

E se os testes (para abordar um risco) custarem demasiado?

Uma vez que existem quase sempre opções e não há limite para a quantidade de testes que se pode aplicar para explorar um risco e fundamentar uma avaliação de risco, é necessário fazer uma escolha. Escusado será dizer que algumas opções serão consideradas demasiado dispendiosas. Por isso, quando apresentar opções às partes interessadas, terá de incluir pelo menos uma opção acessível e outra que poderá não ser acessível.

Mais uma vez: veremos como poderá fazer escolhas no próximo artigo, «Quanto é suficiente testar?»

Se testarmos mais as funcionalidades de alto risco, testamos menos as outras funcionalidades, não é?

Se o orçamento para testes estiver previamente definido para uma equipa, ou se a dimensão da equipa e o número de testadores forem fixos, então a quantidade de testes que as pessoas podem realizar é limitada (em qualquer período de tempo fixo ou delimitado). Assim, se dermos mais ênfase a algumas funcionalidades, os testes às outras terão de diminuir. A cobertura, ou pelo menos o esforço aplicado às funcionalidades, varia consoante o risco.

A forma de analisar esta situação é considerar que, quando um teste falha e é encontrado um erro no sistema, a gravidade atribuída ao erro estará provavelmente estreitamente relacionada com a consequência dessa falha (em produção). Os erros mais graves são corrigidos porque são simplesmente mais importantes para as partes interessadas. 

Uma análise dos riscos do produto destaca as áreas onde os erros, por serem importantes, têm maior probabilidade de ser corrigidos. Assim, utilizar uma análise de risco para destacar onde ocorrem os testes e/ou onde são aplicados mais testes significa que teremos maior probabilidade de encontrar erros importantes e menor probabilidade de encontrar erros em funcionalidades que poderão ser menos relevantes para as partes interessadas.

Seria bom pensar que, por vezes, podemos testar tudo de forma mais equilibrada. Mas quando os recursos e o tempo são limitados (e são sempre, não é verdade?), uma abordagem baseada no risco ajuda a utilizar o tempo dos testadores de forma mais eficaz e eficiente. 

E se testar não for a resposta certa?

Antes de dedicar tempo a definir detalhadamente uma abordagem de testes para um risco do produto, é importante considerar também opções que não envolvam testes. Por exemplo, suponha que exista uma grande preocupação de que um componente do sistema possa não ter um desempenho suficientemente bom em produção e que os tempos de resposta ou a fiabilidade sejam fracos. É claro que poderia realizar testes de carga e tentar resolver os problemas através da depuração. Mas outras opções poderiam ser:

• Comprar o componente a terceiros, em vez de o desenvolver e assumir o risco.
• Reestruturar a arquitetura da solução para distribuir as cargas por várias instâncias do componente.
• Transferir o processamento para um sistema de processamento em lote numa cópia dos dados.
• Em vez de implementar tudo de uma só vez para todos os utilizadores, adotar uma abordagem faseada para implementar os clientes região a região e monitorizar de perto o desempenho.
• E assim por diante.

Muitas vezes, uma ação diferente para evitar que os problemas ocorram é mais eficaz e económica do que testar para encontrar esses problemas mais tarde. 

Compreender o papel dos testes na gestão de riscos

Os testes podem reduzir o risco do lançamento. Se utilizarmos uma avaliação de riscos para orientar a nossa atividade de testes, o objetivo dos testadores passa explicitamente a ser conceber testes que detetem defeitos para que estes possam ser corrigidos e, desse modo, reduzir o risco de um produto defeituoso. 

A deteção de defeitos reduz o risco residual de falhas em produção, onde os custos aumentam muito rapidamente. Quando um teste encontra um defeito e este é corrigido, o número de defeitos diminui e, consequentemente, a probabilidade geral de falha também diminui.

Também se poderia analisar a questão desta forma: o «microrisco» causado por esse defeito é eliminado. Mas é preciso recordar que os testes não conseguem encontrar todos os defeitos, pelo que existirão sempre defeitos latentes que permanecem intocados e sobre os quais os testes não forneceram qualquer informação direta.

No entanto, se nos concentrarmos nas funcionalidades críticas e encontrarmos defeitos nelas, será menos provável que existam defeitos não detetados nessas funcionalidades críticas. Os defeitos que permanecem nas funcionalidades não críticas do sistema terão consequências menos graves.

Uma última nota: o próprio processo de análise de riscos é arriscado. A análise de riscos pode tanto sobrestimar como subestimar os riscos, conduzindo a decisões longe de perfeitas. A análise de riscos também pode contribuir para uma cultura de culpabilização se for levada longe demais. 

Entre outras potenciais dificuldades da análise de riscos, é necessário compreender que não existe um risco absoluto que possa ser calculado depois de o projeto terminar. A natureza dos riscos é serem incertos. Tal como acontece com a eficácia dos testes, o valor de uma análise de riscos só pode ser determinado retrospetivamente, depois de o projeto terminar.

E é tudo quanto ao nosso manifesto de testes baseados no risco. O conceito voltará a surgir ao longo da série Liderança em Testes, por isso fique atento aos próximos artigos!

Subscreva a newsletter The QA Lead para receber uma notificação quando forem publicados novos capítulos da série. Estas publicações são excertos do curso de Liderança em Testes do Paul, que recomendamos vivamente para aprofundar este e outros temas. Se o fizer, utilize o nosso código de cupão exclusivo QALEADOFFER para obter um desconto de $60 no preço total do curso!