Menu

Análise de Modo e Efeitos de Falha (FMEA) - Como Analisar Riscos para Melhor Qualidade de Software e Clientes Satisfeitos!

failure mode effects analysis how analyze risks

Experimente Nosso Instrumento Para Eliminar Problemas

Modo de falha e análise de efeitos (FMEA) é uma técnica de gerenciamento de risco.

Se implementado corretamente, isso pode ser um ótimo complemento para o melhor Processos de garantia de qualidade para ser seguido. Neste artigo, nosso objetivo é apresentar a você esta técnica de Análise de Risco que, no final das contas, é muito útil para melhorar a qualidade do software.

Modo de falha e análise de efeitos (FMEA)

O que você aprenderá:

Análise de efeitos e modos de falha

FMEA é usado principalmente pela alta administração ou partes interessadas. Na prática, os testadores obtêm poucos insights sobre essa técnica. Mas agora a tendência está mudando e eu sinto que se os testadores entenderem esse conceito corretamente, eles podem conduzir seu processo de pensamento de escrever casos de teste para um nível acima, utilizando esta técnica para:

  • Entenda os objetivos das partes interessadas ao testar o aplicativo.
  • Entenda o negócio.
  • Derive os cenários de teste de alto nível com base nos interesses de negócios e gerenciamento.
  • Obtenha casos de teste eficazes que fornecem melhor cobertura para as áreas sujeitas a risco.
  • Priorize os casos de teste.
  • Decida o que testar e o que adiar em qualquer fase.

Fundo

ANÁLISE DE RISCO é um aspecto crucial da Gerenciamento de Teste . A questão então surge - O que é análise de risco? E por que isto é importante? Para entender isso, é vital entender - o que é RISK?

análise de risco

Veja também => Tipos de riscos em projetos de software.

RISCO, como seu significado literal, é uma possibilidade de um resultado ou evento negativo ou indesejável. Os riscos, se não tratados ou gerenciados adequadamente, podem levar a clientes insatisfeitos e de baixa qualidade e, às vezes, à perda de negócios.

O risco tem 2 atributos:

  • Probabilidade
  • Impacto

Probabilidade significa as chances de ocorrência de um risco específico e impacto significa a extensão do efeito do risco.

O que é análise de risco?

A Análise de Risco é um mecanismo pelo qual os riscos potenciais identificados são analisados ​​e estudados minuciosamente para encontrar a probabilidade e o impacto. É aconselhável medir os dois atributos e com base no resultado identificamos:

  • O que testar primeiro?
  • O que testar mais?
  • O que não testar (desta vez)?

Existem muitos métodos de fazer a Análise de Risco e eles são amplamente classificados em dois tipos:

  • Técnicas Informais : Estes são baseados na experiência, julgamento e intuição.
  • Técnicas Formais : Identificar e pesar atributos de risco.

F enfermidade M ode e É efeitos PARA análise (FMEA): Este é um método formal de fazer uma Análise de Risco. Nas seções a seguir, discutirei mais sobre FMEA e tente elaborá-lo com o exemplo.

adicionando valores a um array java

FMEA é uma técnica formal de fazer Análise de Risco. É uma ferramenta sistemática e quantitativa em forma de Planilha que auxilia os membros a analisar o que pode dar errado. Para fazer o FMEA, precisamos das pessoas certas na mesa. Requer um representante de todas as esferas da indústria, incluindo clientes.

Descrição

FMEA começa e continua com sessões de brainstorming. Os participantes precisam identificar todos os componentes, módulos, dependências, limitações que podem falhar em um ambiente de produção e, eventualmente, levar à baixa qualidade, confiabilidade e pode resultar em perda de negócios.

Durante o FMEA, não apenas identificamos a extensão da perda, mas também tentamos identificar a causa dessas falhas. Para medir FMEA, exigimos 3 atributos:

  • Gravidade da Falha (S)
  • Prioridade da Falha (P)
  • Probabilidade da Falha (L)

Colocamos cada um desses atributos em uma escala mostrada abaixo:

Escala de gravidade:

Descrição Aula Escala
Perda de dados, hardware ou problemas de segurança Urgente 1
Perda de funcionalidade sem solução alternativa Alto dois
Perda de funcionalidade com uma solução alternativa Médio 3
Perda parcial de funcionalidade Baixo 4
Cosmético ou trivial Nenhum 5

Escala de prioridade:

Descrição Aula Escala
Perda total do valor do sistema Urgente 1
Perda inaceitável de valor do sistema Alto dois
Possivelmente redução no valor do sistema Médio 3
Redução aceitável do valor do sistema Baixo 4
Uma redução insignificante no valor do sistema Nenhum 5

Escala de verossimilhança:

Descrição Aula Escala
Certo para afetar todos os usuários Urgente 1
Provavelmente afetará alguns usuários Muito alto dois
Possível impacto em alguns usuários Alto 3
Impacto limitado a alguns usuários Baixo 4
Inimaginável no uso real Nenhum 5

Todos esses três atributos (gravidade, prioridade e probabilidade) são medidos individualmente em escala e, em seguida, multiplicados para obter um Número de prioridade de risco (RPN).

ou seja, Número de emergência ( RPN) = S * P * L

Com base neste valor RPN, determinamos a extensão do teste. Quanto menor é o RPN, maior é o risco.

Vamos tentar entender com um exemplo:

Exemplo de análise do efeito do modo de falha

(Este é um exemplo hipotético apenas para fins de compreensão. A implementação real e os recursos podem variar)

Vamos considerar um exemplo simples de um aplicativo bancário que possui 4 recursos.

  • Recurso 1: Retirar
  • Recurso 2: Depósito
  • Recurso 3: Emprestimo à habitação
  • Recurso 4: Depósitos fixos.

Uma equipe de Análise de Risco é formada, composta pelo gerente do Banco, UAT Gerente de teste (representando o usuário final), arquiteto técnico, arquiteto de teste, administrador de rede, DBA e gerente de projeto.

Após uma série de sessões de brainstorming, a equipe surgiu com o seguintes riscos:

  • Lógica de negócios complexa no caso de cálculo da taxa de juros do empréstimo à habitação.
  • O sistema falha em 200 usuários simultâneos.
  • O sistema não consegue lidar com documentos com mais de 6 MB.

Agora, vamos tentar calcular a gravidade, prioridade e probabilidade desses riscos identificados.

Gravidade:

Recurso Aula Escala
Lógica de negócios complexa no caso de cálculo da taxa de juros do empréstimo imobiliário Muito alto dois
Sistema falha em 200 usuários simultâneos Alto 3
O sistema não consegue lidar com documentos com mais de 6 MB Muito alto dois

Prioridade:

Recurso Aula Escala
Lógica de negócios complexa no caso de cálculo da taxa de juros do empréstimo imobiliário Muito alto dois
Sistema falha em 200 usuários simultâneos Alto 3
O sistema não consegue lidar com documentos com mais de 6 MB Alto 3

Probabilidade:

Recurso Aula Escala
Lógica de negócios complexa no caso de cálculo da taxa de juros do empréstimo imobiliário Alto 3
Sistema falha em 200 usuários simultâneos Alto 3
O sistema não consegue lidar com documentos com mais de 6 MB Baixo 4

Agora, vamos colocar todos esses atributos juntos:

Recurso

Gravidade

Prioridade

abrindo um arquivo eps no windows

Probabilidade

Lógica de negócios complexa no caso de cálculo da taxa de juros do empréstimo imobiliário dois dois 3
O sistema falha em 200 usuários simultâneos 3 3 3
O sistema não consegue lidar com documentos com mais de 6 MB dois 3 4

Agora vamos calcular o número de prioridade de risco (RPN = Gravidade * Prioridade * Probabilidade)

Recurso

Gravidade

Prioridade

Probabilidade

RPN

Lógica de negócios complexa no caso de cálculo da taxa de juros do empréstimo imobiliário dois dois 3 12
Sistema falha em 200 usuários simultâneos 3 3 3 27
O sistema não consegue lidar com documentos com mais de 6 MB dois 3 4 24

Agora a chave é: Menor é o RPN - Maior é o risco.

Portanto, neste exemplo específico, o recurso 1 (lógica de negócios complexa no caso de cálculo da taxa de juros do empréstimo imobiliário) tem o risco mais alto e o recurso 2 (falha do sistema com 200 usuários simultâneos) o risco mais baixo.

Como usar isso para derivar casos de teste?

Desde a Recurso 1 é o característica mais arriscada , os casos de teste devem ser rigorosos e mais aprofundados. Escreva os casos de teste para cobrir a funcionalidade completa e os módulos que afetam o recurso. Use todos os tipos de técnicas de escrita de casos de teste ( Particionamento de Equivalência e BVA , Gráfico de causa e efeito , Diagrama de transição de estado ) para derivar os casos de teste.

Os casos de teste não devem ser apenas funcionais, mas também não funcionais ( Teste de carga , Teste de estresse e volume, etc.). Basicamente, precisamos fazer testes exaustivos desse recurso específico, portanto, baseie seus casos de teste adequadamente. Além disso, considere todos os módulos dependentes deste importante recurso.

Recurso 2 é o Recurso MENOS RISKY , portanto, baseie seus casos de teste na funcionalidade principal. Apenas casos de teste de alto nível para validar se o recurso funciona conforme o esperado devem ser suficientes.

Recurso 3 é um Recurso de RISCO MODERADO , então baseie seus casos de teste para cobrir todas as funcionalidades principais e dependentes. Escreva alguns casos de teste BVA para validar alguns cenários negativos também. A extensão dos casos de teste deve estar entre alto risco e fator de baixo risco. Se necessário, inclua alguns casos de teste não funcionais também.

FMEA e grau de teste

Com base no valor RPN, determinamos a extensão ou grau de teste a ser feito.

Normalmente se:

  • RPN está entre 1-10, fazemos testes extensivos (cobrindo dentro e fora do recurso / módulo)
  • RPN está entre 11-30, fazemos testes balanceados (cobrindo todas as principais funcionalidades do recurso / módulo)
  • RPN está entre 31-70, fazemos teste de oportunidade (cobrindo a funcionalidade básica do recurso / módulo)
  • RPN é superior a 70 - Sem testes ou quando o tempo permite, apenas relatórios de anomalias.

Esses intervalos ou números não se restringem aos que mencionei acima. Eles podem variar de acordo com a natureza do projeto.

Recursos: Download Software FMEA e Modelo FMEA .

Conclusão

Análise de risco usando FMEA requer tempo e experiência. Os resultados desejados só podem ser alcançados com a participação igual de todos os membros responsáveis ​​da equipe. Embora essa técnica seja formal, ela requer uma série de sessões de brainstorming e é igualmente importante documentar todos os riscos identificados.

como construir uma rede segura

Uma vez que a maioria dos aplicativos é exclusiva, a escala para medir os parâmetros de FMEA (ou seja, Prioridade, Gravidade e Probabilidade) também depende do aplicativo. Se feito de maneira adequada, a técnica FMEA oferece muitas vantagens. Ele pode ser usado para identificar riscos potenciais e, com base nessa equipe, pode planejar uma estratégia de mitigação eficaz.

Sobre o autor: Este é um artigo convidado de Shilpa Chatterjee Roy. Ela está trabalhando na área de teste de software nos últimos 8,5 anos em vários domínios.

Se você já usou essa técnica, sinta-se à vontade para comentar sobre sua experiência abaixo.

Leitura recomendada

^