The Ultimate Guide to Risk Based Test: Risk Management in Software Testing

ultimate guide risk based testing

O guia definitivo para testes baseados em riscos, gerenciamento de riscos e sua abordagem com exemplos:

O que é teste baseado em risco?

O teste baseado em risco é para realizar testes ou para projetar e executar os cenários, de modo que os principais riscos de negócios que terão um impacto negativo sobre os negócios, conforme identificados pelo cliente, sejam descobertos em seu produto ou recurso no início do ciclo de vida e sejam mitigada pela implementação de medidas de mitigação.

=> Clique aqui para obter a série de tutoriais do plano de teste completo

O impacto negativo pode incluir impacto no custo, cliente insatisfeito, experiência ruim do usuário e até mesmo a ponto de perder clientes.

Em outras palavras, a abordagem RBT é para garantir que, o teste seja feito de tal forma que mesmo se um usuário encontra um bug na produção, isso não o impede de usar o software ou não impacta gravemente o negócio.

O RBT é um teste realizado com base nos riscos do produto. O RBT é saber com bastante antecedência qual é o risco de falha de determinado recurso ou funcionalidade na produção e seu impacto no negócio em termos de custo e outros danos, utilizando uma técnica de priorização para os casos de teste.

Portanto, o teste baseado em risco usa o princípio de priorizando os testes dos recursos, módulos e funcionalidades de um produto ou software. A priorização é baseada no risco da probabilidade de falha desse recurso ou funcionalidade na produção e seu impacto nos clientes.

O que você aprenderá:

• Teste baseado em risco e sua relevância para Agile e DevOps
  • Abordagem de teste baseada em risco
    • Quando usamos a abordagem RBT?
    • Exemplo de abordagem RBT
  • Maneiras de realizar análises de risco
  • Procedimento de Análise de Risco
  • Metodologia de Análise de Risco
    • Etapa # 1) Usando uma grade 3X3
    • Etapa 2) Probabilidade e impacto da falha
    • Etapa # 3) Teste da grade prioritária
    • Etapa 4) Detalhes do teste
  • Como o RBT é relevante para Agile e DevOps?
  • Benefícios da abordagem de teste baseado em risco
• Gerenciamento de risco durante o planejamento de teste
  • Processo de Gestão de Risco
    • # 1) Identificação de risco
    • # 2) Avaliação de Risco / Análise de Impacto de Risco
    • # 3) Mitigação de risco
  • Conclusão
• Gerenciamento de risco na fase de execução de teste (com exemplo)
  • Gestão de Risco - com foco no AUT
  • Como ocorre o teste de bases de risco?
  • Conclusão
  • Leitura recomendada

Teste baseado em risco e sua relevância para Agile e DevOps

Trezentas horas gastas no desenvolvimento de software podem se tornar inúteis em apenas 30 segundos com um único defeito identificado na produção.

Isso, por sua vez, pode arruinar o propósito de todo o produto, sem outra opção a não ser retirá-lo do mercado. E esse é o significado e a necessidade de ‘testes de qualidade’.

Com o rápido crescimento da tecnologia, o software é hospedado na nuvem com suporte a vários sistemas operacionais, várias plataformas, infraestruturas de TI complexas, etc., os usuários finais estão se tornando cada vez mais exigentes com os recursos, opções e nunca comprometem a satisfação do cliente .

Hoje em dia, ‘Qualidade’ está se tornando um fator crucial na entrega de software, onde melhorias contínuas estão acontecendo para melhorar a qualidade a fim de manter os clientes satisfeitos.

Freqüentemente notamos que é um problema comum para quase todos os Testadores estarem sob uma pressão tremenda que sua janela de teste seja comprimida e normalmente a compilação seja entregue a eles para teste no último minuto. Não há tempo e recursos suficientes para fazerem todos os testes que projetaram e a cobertura de automação nem sempre é 100% e tem seus próprios desafios.

O cronograma de entrega não pode ser perdido e, ao mesmo tempo, a qualidade também não pode ser comprometida. Qualquer que seja o plano B, adicionar recursos de teste adicionais retirando-se das outras equipes não está funcionando, o plano C, parar de fazer todas as outras atividades e desviar o esforço apenas para isso, não está realmente ajudando. Por mais que a adição de recursos de teste, no final, não esteja funcionando.

Não há outra opção a não ser executar testes limitados e importantes dentro do tempo e recursos disponíveis.

Então, como decidimos qual teste é importante neste estágio? O que quer que um testador considere importante pode não ser realmente importante para os clientes. De quem é a importância do recurso ou funcionalidade decidida? Quem decidirá quais são os testes importantes? E muitas outras questões continuam surgindo.

A fim de responder a todas essas perguntas e lidar com a situação acima de forma eficaz, uma abordagem de teste chamada 'Teste Baseado em Risco' , logo chamado 'RBT' , surgiu, onde a equipe planejou e identificou claramente os cenários de teste com base nos critérios de 'Risco do Projeto'.

Embora a equipe de QA tenha uma imagem clara dos testes importantes, o RBT é um método comprovado de identificar os testes cruciais e importantes da perspectiva do cliente e do negócio por meio de um 'Análise de risco' procedimento .

Portanto, agora em oposição à forma tradicional de simplesmente identificar os defeitos no software, a abordagem e objetivo de QA mudou com o tempo devido à mudança na tecnologia, aumento da concorrência no mercado para lançar um software de qualidade, introdução de 'Automatizar tudo', e na introdução total da prática Agile e DevOps de entregar o software em um período de poucas horas.

Portanto, a tendência atual do 'Princípio de Teste' não é apenas 'identificar os defeitos', mas também,

# 1) Concentre-se na área do produto onde há um alto impacto nos negócios devido a falha ou alta probabilidade de falha na produção.

#dois) Focando em identificando os defeitos o quanto antes e permitindo que uma equipe conserte o mais cedo possível e, portanto, permitindo que o software / produto ou recurso ‘Fail Fast’.

# 3) O aspecto mais importante do Serviço da equipe de QA agora é focar no cliente para agregar valor ao cliente, aumentando o foco em ‘Experiência de ponta a ponta do cliente’.

Abordagem de teste baseada em risco

É sempre como se preparar para um exame, que não se pode dizer que basta testar e que não há mais defeitos no software, mesmo que se desenhe e execute um amplo número de testes.

Chega um ponto em que a estabilidade do software não será duplamente garantida apenas pelo aumento do número de casos de teste. Neste momento, não se trata apenas de focar no número de testes, mas no que realmente o cliente espera do lançamento.

Portanto, é essencial encontrar um equilíbrio na otimização do teste, a fim de obter o máximo benefício com o esforço razoável de teste. E isso é mais importante quando os cronogramas de teste são muito apertados e não há recursos suficientes disponíveis para realizar testes suficientes.

Portanto, neste caso, a abordagem RBT desempenha um papel fundamental na otimização do esforço de controle de qualidade e maximização do benefício do teste com o mínimo de risco de negócios.

Portanto, se nos concentrarmos no aspecto acima, o trabalho de um QA será muito aliviado. Eles não precisam queimar seus finais de semana no escritório, testando continuamente o software e se preocupando com cada defeito S4 (Gravidade 4) e P4 (Prioridade 4) que saem do teste.

Bem, 4 é considerado a menor prioridade e gravidade dos defeitos no teste. Eles podem investir melhor seu tempo em outros aspectos úteis do projeto.

Para resumir os principais motivadores da abordagem de 'teste baseado em risco':

• Para permitir testar 'o que os clientes desejam' de uma perspectiva de negócios.
• Cumprir o cronograma com a qualidade esperada.
• Para otimizar o esforço de QA.

Quando usamos a abordagem RBT?

Isso é usado nos cenários abaixo:

• A abordagem RBT pode ser usada sempre que houver uma limitação ou restrição de tempo, custo e recursos de um projeto e sempre que houver necessidade de otimizar os recursos.
• A abordagem RBT é usada quando o programa é mais complexo e adapta novas tecnologias e, portanto, envolve muitos desafios.
• Quando o programa é um projeto de P&D e é de primeiro tipo, há uma série de incógnitas e riscos no projeto.

Exemplo de abordagem RBT

Diversas abordagens de análise com base em riscos são usadas na indústria de TI para superar os riscos enfrentados pela produção e seu impacto.

A seguir está uma dessas abordagens:

Esta abordagem de RBT inclui a identificação das 'Funcionalidades Vitais ou Características Principais' do produto e avaliação dos riscos aos quais cada uma dessas funcionalidades fica exposta na produção e implementação de medidas de mitigação adequadas para diminuir ou mitigar o risco.

Assim, a abordagem RBT inclui o teste das funcionalidades que apresentam probabilidade de falha e maior impacto nos negócios. Os tipos de falhas podem ser operacionais ou comerciais, técnicas, externas, etc.

Maneiras de realizar análises de risco

Não existe um processo padrão ou modelo definido como tal para realizar a análise de risco em testes de software para cada um dos recursos de um produto. Várias organizações usam sua própria abordagem para métodos de análise de risco.

A análise de risco pode ser realizada em vários itens do projeto para identificar os riscos e implementar uma abordagem RBT para análise. Esses itens incluem,

• Recursos
• Funcionalidades
• Histórias de usuários
• Requisitos
• Casos de Uso
• Casos de teste

Nesse caso, vamos nos concentrar apenas nos casos de teste para entender a implementação da abordagem de teste baseado em risco.

Procedimento de Análise de Risco

A análise de risco inclui o envolvimento das partes interessadas relevantes do programa tanto de Equipe Técnica e Equipe de Negócios ’ , que inclui, Proprietário do Produto, Gerentes de Produto, Analistas de Negócios, Arquitetos, Testadores e Representantes do Cliente.

Sessões de brainstorming envolvendo essas partes interessadas seriam organizadas para conduzir a discussão para identificar a importância de cada recurso de um produto e priorizá-los com base no risco de falha e seu impacto sobre os usuários finais na produção.

Vários ‘Documentos do Projeto’, como Documento de Requisitos, Documentos de Especificação Técnica, Documentos de Arquitetura e Design, Documento de Processo de Negócios, Documento de Caso de Uso, etc., se tornarão a entrada para a sessão de brainstorming.

O conhecimento das partes interessadas sobre o produto e o produto existente no mercado também será um fator de entrada para a discussão.

Algumas outras fontes de entradas também podem incluir,

• Para reunir informações sobre a funcionalidade mais usada.
• Entradas de consultar um especialista de domínio.
• Dados da versão anterior do produto ou produto similar no mercado.

Durante o debate sessão, os riscos relativos a cada um desses recursos são identificados. Os tipos de riscos podem ser operacionais, técnicos ou comerciais. Os testes e cenários relacionados a eles são ponderados e os valores de risco são avaliados com base na probabilidade de ocorrência do risco e no impacto do risco.

A 'probabilidade de ocorrência de risco' pode ser devido a:

• Má compreensão do recurso pela equipe de desenvolvimento do produto.
• Arquitetura e design inadequados.
• Tempo insuficiente para projetar.
• Incompetência da equipe.
• Recursos inadequados - pessoas, ferramentas e tecnologia.

O ‘Impacto do Risco’ é o efeito da falha para os usuários e negócios, se ocorrer. O impacto pode ser,

• Impacto no custo, resultando em perda.
• Impacto nos negócios resultando na perda de negócios ou participação no mercado, processos judiciais, perda de licença.
• Impacto na qualidade, resultando no lançamento de produto abaixo do padrão ou incompetente.
• Experiência do usuário ruim, resultando em insatisfação e perda de um cliente.

A área de foco da avaliação do risco de um recurso ou produto pode ser,

• Criticidade da funcionalidade na área de negócios.
• Recursos mais usados ​​e funcionalidades importantes.
• Áreas propensas a defeitos
• Funcionalidade com impacto na segurança e proteção.
• Área de Arquitetura e Projeto Complexo.
• Alterações feitas a partir de versões anteriores.

Metodologia de Análise de Risco

Vamos entender a ‘metodologia de teste baseada em risco’ em detalhes agora.

A abordagem de teste com base em risco usa RISK como o critério em todas as fases de teste do ciclo de teste, ou seja, planejamento de teste , design de teste, implementação de teste, execução de teste e relatórios de teste. Idealmente, pode-se projetar um grande número de combinações possíveis de cenários de teste.

Assim, a abordagem RBT inclui uma classificação dos testes com base na gravidade dos riscos para descobrir a área de falha mais defeituosa ou arriscada, que causa um grande impacto no negócio.

O principal objetivo da análise de risco é distinguir entre os 'Valor alto' itens como recursos do produto, funcionalidades, requisitos, histórias de usuários , e casos de teste, e ‘ Baixo valor' alguns e, portanto, mais tarde para focar mais em casos de teste de 'alto valor', focando menos em casos de teste de 'baixo valor' Esta é a etapa inicial da análise de risco antes de iniciar o teste baseado em risco.

A principal tarefa de categorização ou agrupamento de casos de teste em alto valor e baixo valor e atribuir o valor de prioridade a cada um desses casos de teste inclui as seguintes etapas:

Etapa # 1) Usando uma grade 3X3

A análise de risco é realizada usando uma grade 3X3, onde cada funcionalidade, não funcionalidade e seus casos de teste relacionados são avaliados por uma equipe de partes interessadas para seu ‘Probabilidadede falha 'e' Impacto da falha '.

A probabilidade de falha de cada funcionalidade na produção é geralmente acessada por um grupo de 'Especialistas Técnicos' e são categorizados como 'Prováveis ​​de falhar, bastante prováveis ​​e improváveis' ao longo do eixo vertical da grade.

configurando o eclipse para c ++

Da mesma forma, o 'impacto da falha' desses recursos e funcionalidades na produção é experimentado pelo cliente final, se não testado é avaliado por um grupo de ' Especialistas em negócios ”e são categorizados nas categorias‘ Menor, Visível e Interrupção ’ao longo do eixo horizontal da grade.

Etapa 2) Probabilidade e impacto da falha

Todos os casos de teste são posicionados nos quadrantes da grade 3 X 3 com base nos valores identificados de uma probabilidade de falha e impacto da falha que são mostrados como pontos na imagem abaixo.

Obviamente, alta probabilidade de falha e alto impacto de falha (interrupção) são agrupados no canto superior direito da grade, o que é de alta importância e, portanto, é identificado que os testes de 'Alto valor' e os testes de 'Baixo valor' estão agrupados no canto inferior esquerdo que é de menor ou nenhuma importância para o cliente, onde um foco menor pode ser dado a esses recursos ou casos de teste.

Etapa # 3) Teste da grade prioritária

Com base no posicionamento acima dos casos de teste na grade, os testes são priorizados e rotulados com as prioridades 1,2,3,4 e 5 e são marcados em relação a cada uma delas. Os testes mais importantes são posicionados em 1^stgrades que são atribuídas com prioridade 1 e outras menos importantes são classificadas como 2, 3, 4 e 5.

Finalmente, todos os casos de teste são classificados com base em seus números de prioridade e são selecionados para execução na ordem de prioridade. Os de alta prioridade são selecionados para execução primeiro e os de baixa prioridade são executados mais tarde ou têm o escopo reduzido.

Etapa 4) Detalhes do teste

A próxima etapa é decidir sobre o nível de detalhes de teste para o escopo de teste definido. A profundidade do escopo do teste pode ser decidida com base na classificação acima de acordo com a grade abaixo.

Testes de alta prioridade com classificação 1 são testados 'mais completamente' e, portanto, especialistas são implantados para testar esses recursos de alta criticidade e seus casos de teste relacionados. Casos de teste semelhantes com prioridade 2, 3 e 4. Uma decisão de diminuir o escopo de recursos e testes de prioridade 5 com base no tempo e recursos disponíveis pode ser tomada.

Portanto, a abordagem do Nível de Detalhe de Teste de priorizar os recursos e seus casos de teste não só ajuda os Testadores a identificar os 'Testes de Alto Valor', mas também os orienta a decidir sobre seu 'nível de detalhe de teste' com base nessas classificações de prioridade e os ajuda a realizar melhores testes e reduz o custo dos testes por meio do processo de otimização.

Como o RBT é relevante para Agile e DevOps?

Agora, depois de compreender a abordagem de Teste com Base em Risco de realizar o teste com base na priorização de testes dependendo do 'Risco de Falha' de um recurso específico e seu 'Impacto para o Cliente' ao vivo, obviamente alguém levantaria a questão de a relevância da abordagem de teste com base em risco nas práticas Agile e DevOps.

‘Automatizar tudo’, ‘Testar tudo’, ‘Testar continuamente’, ‘Testar repetidamente’ são os conceitos-chave dessas práticas.

Cada vez, quando há uma mudança no código ou há uma liberação, todos os testes projetados são executados através do sistema automatizado Integração Contínua (CI) / Entrega Contínua (CD) pipeline rápida e repetidamente, independentemente de sua priorização.

Então, qual é a relação entre RBT e DevOps? Onde o RBT se encaixaria e se tornaria relevante no Agile e DevOps ???

# 1) Sim, como eu disse antes, não é que todo setor e todo produto tenha 100% de cobertura de automação para suas execuções de teste. Portanto, se a equipe tem que fazer a escolha da priorização para execução do teste a partir da escolha dos casos de teste manuais e deseja poupar a energia e o esforço dos recursos de teste para outras atividades, então o RBT é a melhor escolha.

A abordagem baseada em risco também é uma aposta melhor para executar testes automatizados com aqueles de alta prioridade e testes no mínimo.

#dois) A equipe de QA pode adotar a abordagem RBT de forma mais eficaz durante a Análise de Requisitos ao analisar os requisitos e fornecer um relatório antecipado dos prováveis ​​riscos dos produtos e os recursos para que as ações apropriadas possam ser tomadas de forma proativa pela equipe do programa para mitigá-los.

# 3) A abordagem RBT pode ser usada de forma eficaz no projeto de casos de teste e cenários baseados em alto risco, para que mais foco possa ser dado a recursos e funcionalidades de alto risco.

# 4) Identificar as áreas de 'alto risco' permite que a equipe de QA concentre seus esforços de teste nessas áreas para testar 'de forma mais completa' usando 'Testadores altamente qualificados'.

# 5) 'Fail Fast', como todos sabemos, é o conceito de 'Agile' e 'DevOps', para o qual a abordagem RBT ajuda a identificar as áreas de 'alto risco' no software, identificar os defeitos antecipadamente e permitir que falhem rapidamente e falhem primeiro e deixe a equipe consertar.

# 6) O objetivo final do Agile / DevOps é 'o foco no cliente' e, portanto, a abordagem RBT permite que o controle de qualidade se concentre na experiência do cliente e não apenas em encontrar defeitos.

Benefícios da abordagem de teste baseado em risco

Já entendemos o propósito e o uso da abordagem RBT para analisar os requisitos, projetar e executar os cenários de teste. Existem vários benefícios do RBT.

Podemos consolidar e listar os benefícios dos testes baseados em risco como:

• Ajuda no uso mais eficiente e otimizado dos Recursos de Teste.
• Ajuda a facilitar o trabalho de QA, teste, design e desenvolvimento de teste e atividades de preparação de teste priorizando.
• Ajuda a gerenciar melhor os recursos de QA, alocando os recursos-chave em áreas de alto foco.
• Ajuda na utilização eficaz dos recursos e desvia seu tempo e energia em coisas melhores no projeto.
• Ajuda a equipe de QA no planejamento dos esforços de teste com base na avaliação de risco e na identificação de áreas voláteis e de alto risco.
• Ajuda a equipe a otimizar os testes a serem realizados em função da importância e, portanto, diminuir o escopo dos testes de baixo valor de acordo com as partes interessadas.
• No geral, ajuda na redução de custos por meio de atividades de teste otimizadas e reduzidas.
• A abordagem RBT permite que a equipe de QA teste as áreas de alto risco primeiro e permite que o produto 'falhe rápido' e conserte rapidamente.
• A abordagem RBT ajuda a trazer clareza na Cobertura de teste ' e o ‘Escopo do Teste’ para todo o grupo de Partes Interessadas.
• A equipe pode aumentar seu foco nas áreas de alto risco e manter menos foco nas áreas de baixo risco.
• O RBT permite que a Equipe decida com bastante antecedência sobre a implementação da forma mais eficaz de mitigação dos riscos do produto.
• O RBT ajuda a evitar o efeito da implementação inadequada de mitigações.
• O teste baseado em risco permite que a equipe tome as medidas adequadas para mitigar ou planejar a contingência ou posicionar qualquer solução alternativa para superar a falha ou reduzir seu impacto se o risco ocorrer no Live.
• RBT ajuda a minimizar o risco residual na liberação.
• Ajuda a alcançar a ‘Qualidade melhorada’ através de defeitos menos onerosos na produção.
• Em última análise, ajuda na ‘experiência do cliente melhorada’ e ‘Cliente satisfeito’.

A seguir, aprenderemos como gerenciar riscos nas fases de Planejamento e Execução de Teste do Ciclo de Vida de Teste de Software.

Gerenciamento de risco durante o planejamento de teste

Como gerenciar riscos durante a fase de planejamento de teste:

A vida está cheia de riscos, assim como um projeto de software. Qualquer coisa pode dar errado a qualquer momento. Estamos sempre prontos para consertar as coisas - mas que tal garantir que nada dê errado e que, quando isso acontecer, saibamos exatamente o que fazer? Entra na gestão de riscos - esta é uma parte de um projeto de teste de software que nos prepara para prevenir, compreender, localizar e superar os riscos.

Um risco é simplesmente um problema que provavelmente ocorrerá e, quando ocorrer, causará uma perda.

A perda pode ser qualquer coisa - dinheiro, tempo, esforço ou um comprometimento da qualidade. A perda nunca é boa. Não importa o quanto tentemos, não é positivo - e nunca será. Portanto Gerenciamento de riscos é parte integrante dos projetos de software para garantir que lidamos com riscos e prevenir / reduzir perdas.

Teste baseado em risco : Como somos uma comunidade de controle de qualidade, vamos nos manter específicos quanto aos riscos e ao processo relacionado a eles em nosso mundo de controle de qualidade exclusivamente. Os riscos são avaliados e gerenciados aproximadamente em 2 fases de nosso Ciclo de vida de teste de software . O STLC pode ser categorizado em 3 fases - planejamento de teste, design de teste e execução de teste.

O processo de gerenciamento de risco ocorre duas vezes, durante:

1. Planejamento de Teste
2. Projeto de caso de teste (final) ou às vezes na fase de execução de teste

É obrigatório no caso 1, mas com o caso 2 é mais uma situação de 'necessidade'.

Série de artigos em duas partes:

Mesmo que o processo subjacente seja o mesmo, o tipos de riscos abordadas em ambas as áreas são completamente diferentes. Para fazer justiça a eles individualmente, vamos tratá-los de maneira diferente como uma série de duas partes.

Esta seção será sobre “Gerenciamento de risco durante o planejamento de teste”.

Processo de Gestão de Risco

O processo genérico de gerenciamento de riscos envolve 3 etapas importantes:

1. Identificação de Risco
2. Análise de impacto de risco
3. Mitigação de Risco

Riscos de teste e exemplos de mitigação:

# 1) Identificação de risco

Como se costuma dizer, o primeiro passo para resolver um problema é identificá-lo. Esse estágio envolve fazer uma lista de tudo o que pode surgir e interromper o fluxo normal de eventos.

O principal resultado desta etapa é uma lista de riscos.

Essa etapa de teste com base em risco é geralmente conduzida pelo líder / gerente / representante de QA. No entanto, o lead sozinho não será capaz de fornecer a lista inteira - a contribuição de toda a equipe de QA causa um grande impacto. Podemos dizer que esta é uma atividade coletiva liderada pelo líder de QA.

Além disso, os riscos identificados durante a fase de planejamento de teste são mais 'gerenciais' na orientação - ou seja, vamos olhar para qualquer coisa que possa impactar o cronograma, esforço, orçamento, mudanças de infraestrutura do projeto de QA, etc. O foco aqui é não o AUT, mas a forma como a fase de QA continuará.

Riscos durante o planejamento de testes: exemplos de testes baseados em riscos

A seguir está uma lista de amostra de riscos que podem ser listados durante a fase de planejamento de teste. Observe que o AUT e sua funcionalidade não são o foco aqui.

1. O cronograma de testes é apertado. Se o início do teste for atrasado devido a tarefas de design, o teste não pode ser estendido além da data de início programada do UAT.
2. Recursos insuficientes, integração de recursos tarde demais (o processo leva cerca de 15 dias).
3. Os defeitos são encontrados em um estágio final do ciclo ou no final do ciclo; os defeitos descobertos tardiamente são provavelmente devido a especificações pouco claras e demoram para serem resolvidos.
4. Escopo não definido completamente definido
5. Desastres naturais
6. Indisponibilidade de Independent Ambiente de teste e acessibilidade
7. Teste atrasado devido a novos problemas

Nesse ponto, você pode optar por ser o mais meticuloso que desejar, dependendo do tempo disponível.

Depois que todos os riscos são listados, avançamos para a avaliação de risco / análise de impacto de risco.

# 2) Avaliação de Risco / Análise de Impacto de Risco

A sua análise de risco é algo assim? :)

Análise de risco em teste de software : Todos os riscos são quantificados e priorizados nesta etapa. A probabilidade de cada risco (a chance de ocorrência) e o impacto (quantidade de perda que ele causaria quando esse risco se materializasse) são determinados sistematicamente.

Alto - médio-baixo , os valores são atribuídos à probabilidade e ao impacto de cada risco. Os riscos com “alta” probabilidade e “Alto” ​​impacto são atendidos primeiro e, em seguida, a ordem segue.

Tabela de análise de impacto de risco:

Seguindo essas etapas, a tabela de análise de impacto de risco para os riscos listados acima seria semelhante a esta (todos os valores são hipotéticos e apenas para fins de compreensão):

# 3) Mitigação de risco

A etapa final neste processo de Teste Baseado em Risco (RBT) é encontrar soluções para planejar como lidar com cada uma dessas situações. Esses planos podem variar de empresa para empresa, projeto para projeto e até mesmo de pessoa para pessoa.

Técnicas de mitigação de risco:

Aqui está um exemplo do que a tabela de risco se transforma quando esta fase é concluída:

Alguns pontos a serem observados:

1. Quanto mais cedo o gerenciamento de riscos começar em uma fase de planejamento de projeto de QA, melhor.
2. De todas as 3 etapas, Identificação de risco é o mais importante . Se alguma coisa não estiver listada e considerada para as etapas seguintes, o risco não será tratado.
3. Tente encontrar um período de tempo ideal para esta atividade. Lembre-se de que muito planejamento deixa muito pouco tempo para a execução.
4. Além disso, após o processo de gerenciamento de riscos, se uma nova situação surgir, o plano de gerenciamento de riscos pode ser alterado ou atualizado para refletir a condição mais atual.
5. Data histórica pode ser muito útil para o sucesso desse processo.

Conclusão

Isso nos leva ao fim do gerenciamento de risco na fase de planejamento de teste. Mesmo que as etapas e os princípios subjacentes sejam semelhantes, o processo de gerenciamento de risco é mais concentrado no AUT quando ele ocorre na fase de design / execução do teste.

Em nossa próxima seção, abordaremos - Gerenciamento de riscos na fase de execução de testes.

Gerenciamento de risco na fase de execução de teste (com exemplo)

Em nossa jornada para compreender o processo de gestão de risco, falamos sobre como ele funciona exclusivamente no Fase de planejamento de teste de teste baseado em risco . Também entendemos o processo genérico que envolve - Identificação de riscos, avaliação de riscos e plano de mitigação de riscos.

Como gerenciar o risco na fase de concepção ou execução do teste:

Existe uma outra forma de Gerenciamento de riscos (também às vezes referido como, Teste baseado em risco ) que ocorre durante a fase de concepção ou execução do teste, dependendo da situação. Agora, de que situação estamos falando? Vamos tentar entender isso primeiro.

Todos nós sabemos que nosso trabalho de teste é reativo. Sem requisitos (ou escopo definido), não podemos realizar uma análise de viabilidade e escrever cenários de teste ou plano para atividades de teste.

Da mesma forma, quando o código não está pronto, não temos nada para testar, não importa quanto trabalho de preparação possamos estar prontos em termos de casos de teste, dados de teste, etc. Além disso, o teste é a única etapa restante antes de o produto ser lançado ao vivo.

equipe base servidor gerenciamento ágil de projetos

Gestão de Risco - com foco no AUT

Vamos entender isso melhor com um exemplo:

Se o teste fosse começar nessa data, 1º de janeiro^ste teve que ir até 14 de janeiro^º- quando o teste é feito, a data de ativação do produto geralmente é fixada imediatamente. Digamos - 15 de janeiro^ºpara simplificar. Agora, no mundo perfeito, as coisas aconteceriam exatamente como planejado. Mas todos nós conhecemos a realidade.

Neste caso, vamos supor que, por algum motivo, o teste não começou até 7 de janeiro^º, o que significa que perdemos metade do nosso tempo de teste. Mas precisamos de 14 dias para testar o produto completamente. Poderíamos adiar a data de ativação para mais 7 dias - no entanto; isso geralmente não é uma opção. Porque o produto tem a promessa de chegar ao mercado em uma determinada data e qualquer atraso não é bom para o negócio.

Então, normalmente, nós, equipes de teste, temos que absorver os atrasos, compensar de alguma forma, trabalhar com o tempo disponível e garantir que o produto seja bem testado. Trabalho difícil, não é?

É aqui que o processo de gerenciamento de risco é novamente empregado.

• Agora se atrasos são antecipados com antecedência antes mesmo de o teste começar - o processo ocorre na fase de design do teste.
• E se atrasos acontecem durante um Fase de execução de teste que começou normalmente - o processo é seguido durante a fase de execução do teste.
• As etapas e o método são os mesmos, não importa em que estágio aconteça.

Qual é o processo?

O gerenciamento de riscos ocorre para determinar quais áreas do AUT (Aplicação em Teste) precisam de foco máximo. Normalmente, essas são as áreas funcionais (módulos ou componentes) que são críticas para o sucesso do produto final e estão mais sujeitas a falhas.

Leia também=> Análise de modo e efeito de falha (FMEA) é uma técnica de gerenciamento de risco

Quem o realiza?

Por se tratar do AUT, o conhecimento sobre ele não é apenas com o QA, mas com todas as outras equipes - Dev, BA, Cliente, equipes de gerenciamento de projetos, etc. Portanto, é um esforço coletivo, impulsionado pela equipe de testes.

Como ocorre o teste de bases de risco?

Passo 1) Identificação de Risco

Identifique todas as áreas funcionais do AUT. Isso incluirá simplesmente fazer uma lista.

Passo 2) Avaliação de risco

Todos os riscos são quantificados e priorizados nesta etapa. Quantificar é simplesmente atribuir um número a cada risco da lista que dará uma indicação da prioridade com que deve ser tratado.

A probabilidade de cada risco (a chance de ocorrência) e o impacto (quantidade de perda que ele causaria quando este risco se materializar) são decididos.

O método típico é atribuir as classificações. Por exemplo, A probabilidade pode assumir os valores de 1 a 5. 1 sendo a probabilidade de ocorrência baixa (provavelmente não acontecerá) e 5 sendo alta (com certeza acontecerá).

Da mesma forma, o Impact também pode receber uma classificação de 1-5. 1 sendo de baixo impacto (mesmo que esse risco se materialize, a perda é mínima) e 5 sendo de alto impacto (grandes perdas quando ocorrem).

Etapa 3)

Faça um formato de tabela e divulgue para todos os representantes da equipe - Dev, BA, Cliente, PM, QA e qualquer outra pessoa relevante.

Passo 4)

Instrua cada equipe a preencher os valores com base em sua classificação de probabilidade e impacto.

Uma vez que os valores de probabilidade e impacto são numéricos, isso tornará o cálculo do valor do “Fator de Risco” fácil.

Fator de risco = Probabilidade X Impacto. Quanto maior o fator de risco, mais sério é o problema.

Um exemplo:

Observe que, neste ponto, este é simplesmente o resultado da classificação de uma equipe. Para um projeto em que 5 equipes diferentes estão envolvidas, a equipe de QA acabaria com 5 tabelas diferentes.

Etapa 5)

Faça uma média dos valores do fator de risco. Por exemplo, se houver 5 equipes, para cada módulo, some todos os valores dos fatores de risco e divida por 5. Esses são os valores finais com os quais vamos lidar. Digamos que estes são os fatores de risco médios:

Quanto maior o fator de risco, mais esse módulo precisa ser testado.

Portanto, os Módulos 5 e 2 são os mais cruciais para o sucesso do negócio. Compartilhe os resultados com todas as equipes.

Etapa # 6)

Plano de Mitigação de Risco : Agora, esta é a etapa que muda de Projeto para Projeto. Identificamos que os módulos 5 e 2 são os que mais precisam ser concentrados.

Exemplosdo plano pode ser:

1. Os módulos 5 e 2 serão testados exaustivamente, garantindo que todos os casos de teste relacionados a eles sejam testados. Os outros módulos serão testados de forma exploratória.
2. Os módulos 5 e 2 serão testados primeiro e depois, dependendo do tempo disponível, os demais serão atendidos.

Feito o planejamento, todas as equipes chegam a um acordo e seguem para testar o produto levando em consideração o fator de risco.

É isso!

Alguns pontos importantes a serem observados:

• Uma vez que esta é uma atividade coletiva que leva a opinião de todos em consideração ; as chances de ser preciso e eficaz são maiores.
• Isto é não é um método formal e não precisa fazer parte de todos os projetos de controle de qualidade.
• Às vezes, mesmo que a equipe opte por não desenhar tabelas e atribuir valores- a sessão de brainstorming simples com todos os presentes pode dar à equipe de QA uma boa orientação sobre como proceder.
• O entrada da equipe de desenvolvimento é muito importante porque são eles que criam o produto, portanto, eles saberão o que pode funcionar e o que pode precisar de verificação adicional. Esteja atento a isso.
• Mesmo que haja várias etapas no processo, não leva muito tempo para realizá-los . Especialmente se todas as equipes puderem sentar-se juntas e trabalhar simultaneamente.
• Lembre-se deste processo e seu resultado é apenas a alternativa . Conseguir o tempo planejado para o teste é a melhor maneira de realizar a atividade de controle de qualidade.

Conclusão

A abordagem do Teste com base em risco indica claramente que o foco do testador não é apenas continuar explorando os defeitos, independentemente da gravidade e da prioridade. Agora as coisas mudaram e os testadores precisam trabalhar de forma inteligente e precisam entender a clara 'necessidade do cliente e desejos do usuário'.

Eles precisam estudar o produto completamente e entender qual é o recurso usado com mais frequência na produção, qual é o caminho mais crítico para a geração de receita e como proteger e salvaguardar os clientes de problemas de produção e ameaças aos negócios.

Conseqüentemente, a abordagem RBT educa claramente os 3 testadores de que apenas testar tudo ou testar extensivamente não significa que o teste foi concluído ou que não há defeitos no produto. Testar com eficácia em um tempo estipulado e garantir que os impactos comerciais importantes e críticos sejam anulados e isso é muito importante para o testador.

Portanto, o teste baseado em risco é a ferramenta mais eficiente para a equipe de QA orientar as partes interessadas do projeto com base nos riscos do projeto. A abordagem RBT ajuda a equipe de QA na identificação contínua de riscos e sua resolução que podem colocar em risco a realização das metas e objetivos gerais do projeto e ajuda a alcançar o objetivo final do Grupo de QA.

P.S. As palavras QA e Teste foram usadas alternadamente em todo o documento.

Sobre o autor: Este artigo foi escrito por vários membros da equipe STH - Gayathri Subrahmanyam e Swati S.

Gayathri é um SME de teste de software com mais de 2 décadas de experiência em teste de software e adotou extensivamente a abordagem de ‘Teste baseado em risco’ como parte da industrialização de teste em vários projetos e percebeu o benefício da otimização de recursos de teste e testes de qualidade.

O teste baseado em risco foi um desafio para você? Você tem algum fato interessante para adicionar ao nosso tutorial? Sinta-se à vontade para expressar suas opiniões na seção de comentários abaixo !!

=> Visite aqui para obter a série de tutoriais do plano de teste completo

Leitura recomendada

• Processo de Integração Contínua: Como Melhorar a Qualidade do Software e Reduzir Riscos
• Análise de Modo de Falha e Efeitos (FMEA) - Como Analisar Riscos para Melhor Qualidade de Software e Clientes Satisfeitos!
• The Ultimate Guide to Risk Based Test: Risk Management in Software Testing
• Dez principais ferramentas e técnicas de avaliação e gerenciamento de riscos
• Tipos de riscos em projetos de software
• Algumas perguntas interessantes da entrevista de teste de software
• Escolhendo o teste de software como sua carreira
• Comentários e análises do curso de teste de software