Teste Baseado em Risco: Abordagem, Matriz, Processo e Exemplos

Teste Baseado em Risco

Teste Baseado em Risco (RBT) É um tipo de teste de software baseado na probabilidade de risco. Envolve a avaliação do risco com base na complexidade do software, na criticidade para o negócio, na frequência de uso e nas áreas com maior probabilidade de conter uma vulnerabilidade. defeitoO teste baseado em risco prioriza o teste dos recursos e funções do aplicativo de software que têm maior impacto e maior probabilidade de apresentar defeitos.

Risco é a ocorrência de um evento incerto com efeito positivo ou negativo sobre os critérios de sucesso mensuráveis ​​de um projeto. Pode ser um evento ocorrido no passado, um evento atual ou algo que possa acontecer no futuro. Esses eventos incertos podem impactar os custos, os objetivos comerciais, técnicos e de qualidade de um projeto.

Os riscos podem ser positivos ou negativos.

• Riscos positivos São consideradas oportunidades e contribuem para a sustentabilidade dos negócios. Exemplos incluem investir em um novo projeto, alterar processos de negócios e desenvolver...ping Novos Produtos.
• Riscos negativos São denominadas ameaças, e as recomendações para minimizá-las ou eliminá-las devem ser implementadas para o sucesso do projeto.

Como a técnica aloca esforço em vez de adicionar um novo nível de teste, ela se sobrepõe às demais. tipos de testes de software em vez de substituir qualquer um deles.

Quando implementar testes baseados em risco

Os testes baseados em risco podem ser implementados em

• Projetos com restrições de tempo, recursos ou orçamento.
• Projetos onde a análise baseada em riscos pode ser usada para detectar vulnerabilidades Ataques de injeção de SQL.
• Testes de segurança em ambientes de computação em nuvem.
• Novos projetos com altos fatores de risco, como falta de experiência com as tecnologias utilizadas ou falta de conhecimento do domínio de negócios.
• Modelos de entrega incrementais e iterativos.

Processo de Gestão de Risco

Vamos agora entender as etapas envolvidas no processo de gerenciamento de riscos.

Identificação de Risco

A identificação de riscos pode ser feita por meio de workshops de risco, listas de verificação, brainstorming, entrevistas, técnica Delphi, diagramas de causa e efeito, lições aprendidas em projetos anteriores, análise da causa raiz e contato com especialistas da área e especialistas no assunto.

Um Registro de Riscos é uma planilha que contém a lista de riscos identificados, respostas potenciais e causas raízes. É usado para monitorar e tracÉ fundamental avaliar os riscos (tanto ameaças quanto oportunidades) ao longo de todo o ciclo de vida do projeto. Estratégias de resposta a riscos podem ser utilizadas para gerenciar riscos positivos e negativos.

Uma Estrutura Analítica de Riscos (EAR) desempenha um papel importante no planejamento de riscos. Ela auxilia na identificação das áreas propensas a riscos e apoia a avaliação e o monitoramento eficazes dos riscos ao longo do projeto. Ajuda na alocação de tempo e recursos suficientes para as atividades de gerenciamento de riscos e na categorização das diversas fontes de onde os riscos do projeto podem surgir.

O exemplo abaixo mostra como uma Estrutura Analítica de Riscos agrupa os riscos do projeto em categorias, de forma que nenhuma fonte de risco seja negligenciada.

Análise de Risco (Inclui Análise Quantitativa e Qualitativa)

Uma vez identificada a lista de riscos potenciais, o próximo passo é analisá-los e filtrá-los por relevância. Uma das técnicas de análise qualitativa de riscos é a Matriz de Riscos (abordada em uma seção posterior). Essa técnica é utilizada para determinar a probabilidade e o impacto do risco.

Planejamento de Resposta a Riscos

Com base na análise, podemos decidir se os riscos exigem uma resposta. Por exemplo, alguns riscos exigirão uma resposta no plano do projeto, outros exigirão uma resposta no monitoramento do projeto e outros não exigirão resposta alguma.

O proprietário do risco é responsável por identificar opções para reduzir a probabilidade e o impacto dos riscos atribuídos.

A mitigação de riscos é um método de resposta a riscos utilizado para reduzir os impactos adversos de possíveis ameaças. Isso pode ser feito eliminando os riscos ou reduzindo-os a um nível aceitável. O diagrama abaixo posiciona o planejamento de resposta a riscos dentro do ciclo mais amplo de gerenciamento de riscos.

Contingência de Risco

A contingência pode ser descrita como a possibilidade de um evento incerto cujo impacto é desconhecido ou imprevisível. Um plano de contingência também é conhecido como plano de ação ou plano de reserva para cenários de pior caso. Em outras palavras, ele determina quais medidas podem ser tomadas quando um evento imprevisível se concretiza.

Monitoramento e Controle de Risco

O processo de controle e monitoramento de riscos é utilizado para tracOs processos envolvem: identificar os riscos identificados, monitorar os riscos residuais, identificar novos riscos, atualizar o registro de riscos, analisar as razões para qualquer mudança, executar o plano de resposta a riscos e monitorar os gatilhos de risco. Em seguida, avalia-se a eficácia dessas ações na redução de riscos.

Isto pode ser alcançado através de reavaliações de risco, auditorias de risco, análise de variações e tendências, medição de desempenho técnico, reuniões de atualização de status e reuniões retrospectivas.

A tabela abaixo fornece informações sobre as entradas, ferramentas e saídas do monitoramento e controle de riscos.

Precisamos lembrar que o risco aumenta com as mudanças na tecnologia, o tamanho do projeto, a duração do projeto (um cronograma mais longo), o número de agências financiadoras, as estimativas do projeto, o esforço e a escassez de habilidades adequadas.

Abordagem de teste baseada em risco

O processo de gerenciamento acima alimenta a abordagem de teste abaixo. Cada etapa numerada produz uma entrada que a próxima etapa consome.

1. Analise os requisitos.
   • Os documentos (SRS, FRS, casos de uso) são revisados. Essa atividade é realizada para encontrar e eliminar erros e ambiguidades.
   • A aprovação dos requisitos é uma das técnicas de redução de riscos para evitar a introdução de alterações tardias no projeto. Qualquer alteração em um requisito após a definição da linha de base do documento envolve um processo de controle de mudanças e aprovações subsequentes.
2. Avalie os riscos Calculando a probabilidade e o impacto que cada requisito pode ter no projeto, levando em consideração os critérios definidos, como custo, cronograma, recursos, escopo, desempenho técnico, segurança, confiabilidade e complexidade.
   • Identifique a probabilidade de falha e as áreas de alto risco. Isso pode ser feito utilizando uma matriz de avaliação de riscos.
   • Utilize um registro de riscos para listar o conjunto de riscos identificados. Atualize, monitore e track os riscos periodicamente em intervalos regulares.
   • O perfil de risco precisa ser feito nesta fase para compreender a capacidade de risco e os níveis de tolerância ao risco.
3. Priorize os requisitos com base na classificação.
   • O processo de teste baseado em risco está definido.
   • Riscos altamente críticos e médios podem ser considerados para o planejamento, implementação e monitoramento do progresso da mitigação. Riscos baixos podem ser mantidos em uma lista de observação.
   • A avaliação da qualidade dos dados de risco é feita para analisar a qualidade dos dados.
4. Planeje e defina os testes de acordo com a classificação.
   • Aplique uma abordagem de teste e técnicas de design de teste apropriadas para que os itens de maior risco sejam testados primeiro. Itens de alto risco podem ser testados por um profissional com bom conhecimento e experiência na área.
   • Diferentes técnicas de projeto de testes podem ser utilizadas — por exemplo, a tabela de decisão técnica em itens de teste de alto risco, e somente particionamento equivalente para itens de teste de baixo risco.
   • Casos de teste Também são projetadas para abranger múltiplas funcionalidades e cenários de negócios de ponta a ponta.
   • Prepare os dados de teste, as condições de teste e a plataforma de teste.
5. Revveja a documentação do teste — os planos de teste, a estratégia de teste, os casos de teste, os relatórios de teste e qualquer outro documento criado pela equipe de testes.
   • A revisão por pares é uma etapa importante na identificação de defeitos e na redução de riscos.
6. Realize testes a seco e verificações de qualidade nos resultados.
   • Os casos de teste são executados de acordo com a prioridade do item de risco.
   • Manter tracA capacidade de correlação entre os itens de risco, os testes que os abrangem, os resultados desses testes e os defeitos encontrados durante os testes é fundamental. Todas as estratégias de teste executadas corretamente reduzem os riscos de qualidade.
   • Os testes baseados em risco podem ser usados ​​em todos os níveis de avaliação — componente, integração, sistema. e testes de aceitação.
   • Em nível de sistema, precisamos nos concentrar no que é mais importante na aplicação. Isso pode ser determinado analisando a visibilidade das funções, a frequência de uso e o possível custo de falha.
   • Avaliação dos critérios de saída: todas as áreas de alto risco foram totalmente testadas, restando apenas pequenos riscos residuais.
7. Relate os resultados dos testes baseados no risco. e analisar as métricas.
   • Reavaliar eventos de risco existentes e novos eventos de risco com base em Indicadores Chave de Risco.
   • Atualize o registro de riscos.
   • Os planos de contingência funcionam como um plano de recurso ou de emergência para riscos de alta exposição.
   • A análise de defeitos e a prevenção de defeitos são utilizadas para eliminar os defeitos.
   • Reteste e Teste de regressão Valide as correções de defeitos com base na análise de risco pré-calculada, sendo que as áreas de alto risco devem receber a cobertura mais intensiva.
   • Testes de automação baseados em risco, se viáveis.
   • Cálculo do risco residual.
8. Monitorar e controlar os riscos.
   • Os critérios de saída ou de conclusão podem ser definidos separadamente para diferentes níveis de risco. Todos os riscos principais foram abordados com ações apropriadas ou planos de contingência, e a exposição ao risco está em um nível igual ou inferior ao considerado aceitável para o projeto.
   • Reavaliação do perfil de risco e feedback do cliente.

Abordagem de teste baseado em risco para o teste do sistema

1. Teste Técnico do Sistema — Isso é conhecido como teste de ambiente e teste de integração. O teste de ambiente inclui testes nos ambientes de desenvolvimento, teste e produção.
2. Teste Funcional do Sistema — Teste de todas as funcionalidades, recursos, programas e módulos. O objetivo deste teste é avaliar se o sistema atende aos requisitos especificados.
3. Teste de sistema não funcional — Testando os requisitos não funcionais: desempenho, testes de carga, testes de estresse, testes de configuração, testes de segurança, backup e recuperação Procedimentos e documentação (documentação do sistema, operação e instalação).

O diagrama abaixo oferece uma visão geral clara do processo mencionado acima.

Os testes de sistema incluem tanto testes funcionais quanto testes não funcionais.

Teste funcional Garante que o produto ou aplicativo atenda aos requisitos do cliente e da empresa. Por outro lado, testes não funcionais É feita para verificar se o produto atende às expectativas do cliente em termos de qualidade, confiabilidade, usabilidade, desempenho e compatibilidade.

Como realizar testes baseados em risco: processo completo

Esta seção aborda o processo de teste baseado em risco, que se desenvolve em cinco fases.

1. Identificação de Risco
2. Análise de risco
3. Resposta ao Risco
4. Teste Scoping
5. Definição do processo de teste

As cinco fases se inter-relacionam, conforme mostrado abaixo.

1. Nesse processo, os riscos são identificados e categorizados, um registro preliminar de riscos é preparado e a classificação dos riscos é realizada para identificar os riscos significativos.
2. A resposta ao risco envolve a formulação dos objetivos do teste a partir dos riscos e a seleção de técnicas apropriadas para que a atividade ou técnica de teste atenda a esses objetivos.
3. Para calcular a pontuação de eficácia do teste, são consideradas as dependências documentadas, os requisitos, o custo e o tempo necessário para o teste de software.
4. Pontuação do testeping É uma atividade de revisão que exige a participação de todas as partes interessadas e da equipe técnica. É importante respeitar o escopo de riscos acordado. Esses riscos precisam ser mitigados por meio de testes, e todos os membros devem concordar com as responsabilidades que lhes são atribuídas e com o orçamento alocado para essas atividades.
5. Após a definição do escopo dos testes, os objetivos, as premissas e as dependências de cada etapa devem ser compilados em um formato padrão.

O exemplo prático abaixo relaciona cada requisito ao risco associado e ao objetivo do teste que o aborda.

Vamos considerar os requisitos funcionais F1, F2 e F3, e os requisitos não funcionais N1 e N2.

F1 — Requisito Funcional, R1 — Risco associado a F1

• Objetivo do teste 1 — Demonstrar, por meio de um teste, que os recursos e funcionalidades esperados do sistema funcionam corretamente e que o risco R1 pode ser mitigado por meio de testes funcionais.
• Teste — O teste de páginas do navegador é realizado para executar tarefas importantes do usuário e verificar se R1 (o risco associado a F1) pode ser mitigado em uma variedade de cenários.

F2 — Requisito Funcional, R2 — Risco associado a F2

• Objetivo do teste 2 — Demonstrar, por meio de um teste, que os recursos e funcionalidades esperados do sistema funcionam corretamente e que o risco R2 pode ser mitigado por meio de testes funcionais.
• Teste — O teste de páginas do navegador é realizado para executar tarefas importantes do usuário e verificar se o R2 pode ser abordado em uma variedade de cenários.

F3 — Requisito Funcional, R3 — Risco associado a F3

• Objetivo do teste 3 — Demonstrar, por meio de um teste, que os recursos e funcionalidades esperados do sistema funcionam corretamente e que o risco R3 pode ser mitigado por meio de testes funcionais.
• Teste — O teste de páginas do navegador é realizado para executar tarefas importantes do usuário e verificar se o R3 pode ser abordado em uma variedade de cenários.

N1 — Requisito não funcional, NR1 — Risco associado a N1

• Objetivo de teste N1 — Demonstrar, por meio de um teste, que as características operacionais do sistema funcionam corretamente e que o risco NR1 pode ser mitigado por testes não funcionais.
• Teste — O teste de usabilidade é uma técnica usada para avaliar a facilidade de uso das interfaces de usuário e para verificar se o NR1 poderia ser resolvido por meio de testes de usabilidade.

N2 — Requisito não funcional, NR2 — Risco associado a N2

• Objetivo de teste N2 — Demonstrar, por meio de um teste, que as características operacionais do sistema funcionam corretamente e que o risco NR2 pode ser mitigado por testes não funcionais.
• Teste - Testes de segurança É uma técnica usada para verificar se o aplicativo é seguro ou vulnerável a ataques, se há vazamento de informações e para verificar se o NR2 pode ser resolvido por meio de testes de segurança.

Objetivos específicos do teste: Os riscos e objetivos dos testes listados são específicos para os tipos de teste, conforme resumido abaixo.

Procedimento para projetar o processo de teste baseado em risco

• Elabore um registro de riscos. Este registro documenta os riscos derivados de uma lista genérica de riscos, de uma lista de verificação existente e de sessões de brainstorming.
• Inclua os riscos associados aos requisitos funcionais e não funcionais do sistema (usabilidade, segurança, desempenho).
• A cada risco é atribuído um identificador único.

As colunas 1 e 2 desse registro contêm o identificador e a descrição do risco. As demais colunas são descritas abaixo.

A probabilidade (1 baixa, 5 alta) e as consequências (1 baixa, 5 alta) de cada risco são avaliadas, conforme os dois registros ex.tracts abaixo mostram.

• A exposição ao teste é calculada.
• O analista examina cada risco e avalia se ele é testável ou não.
• Os objetivos dos testes são definidos para os riscos testáveis.
• O testador especifica a atividade de teste que deve ser realizada de forma planejada para atingir o objetivo do teste (revisões estáticas, inspeções, testes de sistema, testes de integração, testes de aceitação, validação de HTML, testes de localização e assim por diante).
• Essas atividades de teste podem ser classificadas em etapas (teste de componentes ou teste de unidade, testes de integração, testes de sistema, testes de aceitação).
• Em alguns casos, um risco pode ser abordado por mais de uma etapa de teste.
• Identificar as dependências e pressupostos (disponibilidade de competências, ferramentas, ambientes de teste e recursos).
• A eficácia do teste é calculada. A eficácia do teste relaciona-se ao nível de confiança do avaliador de que o risco será definitivamente mitigado pelo teste. A pontuação de eficácia do teste é um número entre um e cinco (5 = alta confiança, 1 = baixa confiança).
• Estime o esforço, o tempo necessário e o custo para preparar e executar esses testes.

Os próximos dois extracts mostram as colunas de registro restantes e a pontuação de eficácia do teste em seus respectivos lugares.

• O número de prioridade do teste é calculado. É o produto das pontuações de probabilidade, consequências e eficácia do teste.
• 125 (máximo) — um risco muito sério que poderia ser detectado com testes.
• 1 (mínimo) — um risco muito baixo que não seria detectado com testes.
• Com base no número de prioridade do teste, a importância do teste pode ser classificada como Alta (vermelho), Média (amarelo) e Baixa (verde). Os itens de maior risco são testados primeiro.
• Atribua as atividades de teste às etapas de teste. Designe o grupo que realizará os testes para cada objetivo nas diferentes etapas de teste (teste de unidade, teste de integração, teste de sistema, teste de aceitação).

A distribuição entre as fases de teste é mostrada abaixo.

O que está dentro e fora do escopo dos testes é definido no escopo de testes.ping Estágio.

• Para cada etapa, são definidos os objetivos do teste, o componente em teste, a responsabilidade, o ambiente, os critérios de entrada, os critérios de saída, as ferramentas, as técnicas e os resultados esperados.

Objetivos genéricos do teste — esses objetivos genéricos são aplicáveis ​​a múltiplos projetos e aplicações.

• O componente atende aos requisitos e está pronto para uso em subsistemas maiores.
• Os riscos associados aos tipos de testes específicos são abordados e os objetivos do teste são alcançados.
• Os componentes integrados são montados corretamente e a compatibilidade de interface entre os componentes é garantida.
• O sistema atende aos requisitos funcionais e não funcionais especificados.
• Os componentes do produto atendem às necessidades do usuário final em seu ambiente operacional pretendido.
• Uma estratégia de gestão de riscos é utilizada para identificar, analisar e mitigar riscos.
• O sistema atende aos requisitos das normas regulamentares do setor.
• O sistema atende ao contracobrigações reais.
• Institucionalização e a consecução de outros objetivos específicos, como custos, cronograma e qualidade.
• Sistemas, processos e pessoas atendem aos requisitos de negócios.

É possível definir objetivos genéricos para os diferentes estágios do teste.

• Teste de componentes
• Teste de integração
• Teste do sistema
• Teste de aceitação

Vamos considerar a fase de teste do sistema.

1. G4 e G5 demonstram que o sistema atende aos requisitos funcionais (F1, F2, F3) e aos requisitos não funcionais (N1, N2).
2. Demonstrar, por meio de testes, que as características e funcionalidades esperadas do sistema funcionam corretamente e que os riscos associados a F1, F2 e F3 podem ser mitigados por meio de testes funcionais.
3. Demonstrar, por meio de testes, que as características operacionais do sistema funcionam corretamente e que os riscos associados a N1 e N2 podem ser mitigados por testes não funcionais.
4. Com base no número de prioridade do teste, a importância do teste pode ser classificada como Alta (vermelho), Média (amarelo) e Baixa (verde).

Matriz de Priorização e Avaliação de Riscos

A matriz de avaliação de riscos é uma matriz de probabilidade-impacto. Ela fornece à equipe do projeto uma visão rápida dos riscos e da prioridade com que cada um deles precisa ser abordado.

Risk rating = Probability x Severity

Probabilidade é a medida da chance de um evento incerto ocorrer, com base na exposição em termos de tempo, proximidade e repetição. É expressa em porcentagem.

Isso pode ser classificado como Frequente (A), Provável (B), Ocasional (C), Remoto (D), Improvável (E) e Eliminado (F).

• Freqüente — Espera-se que ocorra várias vezes na maioria das circunstâncias (91 – 100%).
• Provável — Provavelmente ocorrerá várias vezes na maioria das circunstâncias (61 – 90%).
• Ocasional — Pode ocorrer em algum momento (41 – 60%).
• Remote — Improvável de ocorrer, embora possa ocorrer em algum momento (11 – 40%).
• Improvável — Pode ocorrer em circunstâncias raras e excepcionais (0 – 10%).
• Eliminado — Impossível de ocorrer (0%).

A gravidade é o grau de impacto do dano ou da perda causada pelo evento incerto. Ela é classificada de 1 a 4, sendo: Catastrófica = 1, Crítica = 2, Marginal = 3 e Negligenciável = 4.

• Catastrófico — Consequências graves que tornam o projeto completamente improdutivo e podem até levar ao seu encerramento. Isso deve ser uma prioridade máxima durante a gestão de riscos.
• Críticas — Grandes consequências que podem levar a enormes prejuízos. O projeto está seriamente ameaçado.
• Marginal — Danos de curto prazo que ainda são reversíveis por meio de atividades de restauração.
• desprezível — Danos ou perdas mínimos ou insignificantes. Isso pode ser monitorado e gerenciado por meio de procedimentos de rotina.

A prioridade é classificada em quatro categorias, que são relacionadas à gravidade e à probabilidade do risco, conforme mostrado na imagem abaixo.

• Grave
• Alto
• Suporte:
• Baixo

Sério: Os riscos que se enquadram nesta categoria estão marcados em amarelo. A atividade deve ser interrompida e medidas imediatas devem ser tomadas para isolar o risco. Controles eficazes devem ser identificados e implementados. Além disso, a atividade não deve prosseguir a menos que o risco seja reduzido a um nível baixo ou médio.

High: Os riscos que se enquadram nesta categoria estão marcados em vermelho e exigem ação imediata ou uma estratégia de gestão de riscos. É necessário agir imediatamente para isolar, eliminar ou substituir o risco e implementar controles de risco eficazes. Caso esses problemas não possam ser resolvidos imediatamente, prazos rigorosos devem ser definidos para a sua resolução.

Meio: Os riscos que se enquadram nesta categoria estão assinalados a amarelo. Devem ser tomadas medidas razoáveis ​​e práticas para minimizar os riscos.

Low: Os riscos que se enquadram nesta categoria estão assinalados a verde e geralmente podem ser aceites, uma vez que não representam qualquer problema significativo. No entanto, é imprescindível uma revisão periódica para garantir que os controlos se mantenham eficazes.

Lista de verificação genérica para testes baseados em risco

A matriz define como um risco é avaliado. A lista de verificação abaixo determina quais candidatos entram na matriz.

• Funcionalidades importantes no projeto.
• Funcionalidade visível ao usuário no projeto.
• A funcionalidade que tem o maior impacto na segurança.
• Funcionalidades que têm o maior impacto financeiro nos usuários.
• Áreas de código-fonte altamente complexas e propensas a erros.
• Recursos ou funções que podem ser testados no início do ciclo de desenvolvimento.
• Características ou funcionalidades que foram adicionadas ao projeto do produto no último minuto.
• Fatores críticos de projetos anteriores semelhantes ou relacionados que causaram problemas.
• Principais fatores ou problemas de projetos similares ou relacionados que tiveram um grande impacto nas despesas de operação e manutenção.
• Requisitos inadequados levam a projetos e testes deficientes, o que pode afetar os objetivos e os resultados do projeto.
• Na pior das hipóteses, um produto pode ser tão defeituoso que não pode ser retrabalhado e precisa ser completamente descartado, o que causaria sérios danos à reputação da empresa. Identifique quais tipos de problemas são cruciais para os objetivos do produto.
• Situações ou problemas que poderiam causar reclamações persistentes no atendimento ao cliente.
• Testes de ponta a ponta que podem facilmente focar em múltiplas funcionalidades do sistema.
• O conjunto ideal de testes que pode maximizar a cobertura de risco.
• Quais testes terão a melhor relação entre cobertura de alto risco e tempo necessário?

Relatórios e métricas de resultados de testes baseados em risco

1. Preparação do relatório de teste. A elaboração de relatórios sobre o status dos testes consiste em comunicar eficazmente os resultados aos stakeholders do projeto, proporcionando uma compreensão clara e mostrando a comparação dos resultados com os objetivos dos testes.
   • Número de casos de teste planejados versus executados.
   • Número de casos de teste aprovados ou reprovados.
   • Número de defeitos identificados, bem como seu estado e gravidade.
   • Número de defeitos críticos ainda não identificados.
   • Tempos de inatividade do ambiente, se houver.
   • Quaisquer obstáculos que impeçam o espetáculo.
   • Relatório de resumo do teste e cobertura de teste relatar.
2. Preparação de métricas. Uma métrica é uma combinação de duas ou mais medidas usadas para comparar processos, projetos e produtos de software.
   • Variação de esforço e cronograma.
   • Produtividade na preparação de casos de teste.
   • Cobertura do projeto de teste.
   • Produtividade na execução de casos de teste.
   • Eficiência na identificação de riscos (%)
   • Eficiência da mitigação de riscos %.
   • Eficácia do teste %.
   • Cobertura de execução de testes.
   • Produtividade na execução de testes.
   • Vazamento por defeito %.
   • Eficiência na detecção de defeitos e densidade de defeitos.
   • Índice de estabilidade dos requisitos.
   • Custo da qualidade.

Essas medidas são então analisadas em relação aos riscos:

• Analise os riscos em categorias não funcionais (desempenho, confiabilidade e usabilidade) com base no status dos defeitos e no número de resultados de aprovação ou reprovação nos testes, em relação aos riscos.
• Analise os riscos em categorias funcionais usando métricas de teste, status de defeitos e status de aprovação ou reprovação nos testes, em relação aos riscos.
• Identificar indicadores-chave de desempenho (antecedentes e consequentes) e criar indicadores de alerta precoce.
• Monitorar e reportar indicadores de risco de liderança e defasagem (Indicadores-Chave de Risco) através da análise de padrões de dados, tendências e interdependências.

Avaliação de Risco Inerente vs. Risco Residual

A identificação e análise de riscos devem incluir também os riscos inerentes, os riscos residuais, os riscos secundários e os riscos recorrentes.

• Risco inerente: Os riscos que foram identificados ou já estavam presentes no sistema antes da implementação dos controles e das respostas. Os riscos inerentes também são conhecidos como riscos brutos.
• Risco residual: Os riscos que permanecem após a implementação dos controles e das respostas. Os riscos residuais são conhecidos como riscos líquidos.
• Risco Secundário: O novo risco causado pela implementação do plano de resposta ao risco.
• Risco de recorrência: A probabilidade de os riscos iniciais se repetirem.

A medição dos resultados dos testes com base no risco ajuda a organização a conhecer o nível residual de risco de qualidade durante a execução dos testes e a tomar decisões de lançamento mais informadas.

Perfil de risco e feedback do cliente

A análise de perfil de risco é um processo para encontrar o nível ideal de risco de investimento para o cliente, considerando o risco necessário, a capacidade de risco e a tolerância ao risco.

1. Risco exigido É o nível de risco que o cliente precisa assumir para obter um retorno satisfatório.
2. Capacidade de risco É o nível de risco financeiro que o cliente pode se dar ao luxo de assumir.
3. Tolerância de risco É o nível de risco que o cliente prefere assumir.

Feedback do cliente: Reunir feedback e avaliações de clientes para melhorar o negócio, o produto, o serviço e a experiência.

Benefícios dos testes baseados em risco

Os benefícios dos testes baseados em risco são apresentados a seguir.

• Aumento da produtividade e redução de custos.
• Melhoria das oportunidades de mercado (tempo de lançamento no mercado) e entrega dentro do prazo.
• Melhoria no desempenho do serviço.
• Qualidade aprimorada, pois todas as funções críticas do aplicativo são testadas.
• Informações claras sobre a cobertura dos testes. Com essa abordagem, a equipe sabe o que foi e o que ainda não foi testado.
• A alocação de esforços de teste com base na avaliação de riscos é a maneira mais eficiente e eficaz de minimizar o risco residual após a liberação.
• A medição dos resultados dos testes com base na análise de riscos permite à organização identificar o nível residual de risco de qualidade durante a execução dos testes e tomar decisões de lançamento informadas.
• Testes otimizados com métodos de avaliação de risco claramente definidos.
• Melhoria na satisfação do cliente, devido ao envolvimento do cliente, à boa comunicação de informações e ao acompanhamento do progresso. tracrei.
• Detecção precoce de potenciais áreas problemáticas, para que medidas preventivas eficazes possam ser tomadas.
• O monitoramento e a avaliação contínuos de riscos ao longo de todo o ciclo de vida do projeto ajudam a identificar e resolver riscos, bem como a lidar com problemas que possam comprometer o alcance dos objetivos gerais do projeto.

Perguntas Frequentes