Para garantir a qualidade do produto da informação nos setores de medicina, seguros, bancos e outras indústrias, juntamente com outros métodos de teste, é importante usar testes baseados em risco. Para verificação, as áreas mais arriscadas do software que está sendo criado são selecionadas. Isso nos permite antecipar cenários negativos e implementar com sucesso as metas de negócios do cliente.
No artigo, contaremos como trabalhamos na SimbirSoft com riscos (usando o sistema de aquisição da Internet e outros projetos como exemplo) e quais métodos de avaliação e gerenciamento de riscos usamos nos projetos dos clientes.
Riscos no início do projeto
Para começar, damos um exemplo de nossa prática no desenvolvimento para o setor bancário.
Proposta do cliente: focar na versão web do banco para pessoas físicas.
O risco que identificamos: uma possível perda de público devido à baixa demanda da versão web para indivíduos, em contraste com o banco de clientes móvel.
Nossos argumentos: estatísticas das preferências do usuário com base em análises e distribuição do público-alvo por versões para celular e web.
Conclusões: para indivíduos, a versão móvel é mais conveniente, pois o telefone está sempre à mão. As operações são rápidas, o sistema de autorização permite acessar todos os serviços convenientes. Nesse caso, é importante o acesso rápido a um conjunto limitado das funções mais populares.
Para entidades legais, é importante a integridade das funções fornecidas, a capacidade de carregar, imprimir e trabalhar com uma grande quantidade de informações. Para isso, a versão web é mais conveniente.
Nossa solução: focar no banco de clientes móveis para pessoas físicas.
No início do trabalho com um projeto, é importante escolher a estratégia de teste corretamente. Vejamos exemplos de por que é importante e como escolhê-lo.
A estratégia de teste deve atender aos objetivos de negócios
Cedo ou tarde, todas as empresas enfrentam a necessidade de organizar o processo de teste e passam a entender que a construção de sua estratégia é uma etapa importante no desenvolvimento de software. Às vezes - através de sua própria experiência amarga. É especialmente perigoso subestimar o papel dos testes e da seleção de estratégias no desenvolvimento de projetos de grande escala. O processo de teste deve ser selecionado de acordo com as metas de negócios e as especificidades do projeto, caso contrário não resultará em resultados positivos em um mês ou em um ano.
Por exemplo, considere testar aplicativos móveis e da Web para um banco. No início do projeto, selecionamos uma estratégia baseada em requisitos com baixo nível de detalhe. Usamos listas de verificação para reduzir o tempo de teste e dar suporte à base de teste. Com o aumento da funcionalidade, a adição de aquisição, autorização por sms e notificação, sistemas mais complexos, as listas de verificação não lidam mais com a tarefa. Com o tempo, mais e mais especialistas em controle de qualidade se juntaram à equipe, foi necessário transmitir informações e coordenar suas ações. Com a complicação do produto, qualquer alteração pode afetar as funções relacionadas, ou seja, o risco de regressão aumenta. A necessidade de automação dos testes de regressão estava se formando, então mudamos para os casos de teste.
Conclusão: dependendo do projeto, suas especificidades ou estágio de desenvolvimento, a estratégia de teste muda.
A estratégia deve ser selecionada para as metas do projeto, a fim de garantir a melhor qualidade do produto. Ela responde às perguntas "o quê", "onde" e "quando" serão testadas. A qualquer momento, você sabe em que ponto está e de onde virá no futuro - de acordo com a estratégia.
Um objetivo comercial pode ser garantir a segurança dos dados do cliente, bem como do próprio software no estágio de produção. A segurança começa com o processo de desenvolvimento e continua na fase de teste.
Por exemplo, em um dos projetos, criamos um ambiente seguro para desenvolvimento e teste, implantamos uma infraestrutura que atendia a todos os requisitos e ajudava a proteger os dados. Solicitamos tokens certificados e unidades flash baseadas em nome para cada especialista em controle de qualidade para acessar a infraestrutura de teste. Assim, garantimos a meta de negócios do projeto em segurança de software e mantivemos em sigilo os dados do cliente e do usuário.
Devido à estratégia de teste, é possível enfatizar aspectos realmente importantes para um projeto específico. É lógico que o lançamento de um jogo para celular ou de um complexo sistema bancário de CRM exija abordagens diferentes para o teste.
Estratégia de teste bancário
Em nossa prática, na SimbirSoft, usamos toda a gama de metodologias de desenvolvimento, mas tecnologias flexíveis sempre permanecem nossa prioridade. E mesmo quando, por várias razões, não é possível usá-las, a equipe adota as melhores práticas e as aplica no trabalho diário. O teste se torna parte integrante de todo o processo e se funde no fluxo de trabalho geral. Nesse caso, é responsável não apenas pela qualidade do produto, mas também pela qualidade de todo o processo de trabalho.
Quais tecnologias usamos:
- planejamento e preparação flexíveis de releases internos;
- preparação da história do usuário;
- realização de comícios;
- realização de retrospectivas.
Com força total, a estratégia de teste se revela em projetos com lógica de negócios complexa. Por exemplo, software para suporte de informações de bancos, a construção de um sistema de aquisição da Internet, uma plataforma de negociação automatizada. Nesses projetos, é importante aplicar uma estratégia de teste adequada, pois o preço de alguns erros pode levar a perdas reais e afetar muito a reputação da empresa para pior.
Além disso, os principais objetivos do teste - pesquisa de defeitos e verificação de conformidade do software - podem ser adicionados a mais. Por exemplo, é importante que os bancos implementem rapidamente os novos requisitos do Banco Central. Isso significa que testes oportunos com a qualidade necessária para tarefas críticas serão adicionados ao objetivo principal.
Recentemente, em um projeto bancário, enfrentamos uma mudança na lei federal - um aumento na taxa de IVA de 18% para 20%. Muito trabalho preliminar foi feito para se adaptar à mudança de legislação, uma vez que a mudança dizia respeito não apenas à substituição de formulários, interfaces, mas também à alteração da lógica de várias fórmulas de cálculo. Era necessário garantir a exibição correta em muitas plataformas. Além disso, na função de pagamento diferido, era necessário levar em consideração o período de transição com taxas de 18% e 20%.
Agora, falaremos mais detalhadamente sobre como construímos nossa estratégia e por que geralmente escolhemos testes baseados em risco.
Profissionais de testes baseados em risco
Existem várias estratégias de teste selecionadas para fins específicos:
- com base em requisitos;
- metódico;
- estratégias reativas;
- estratégias consultivas.
No caso de trabalhar com projetos com lógica de negócios complexa, é necessário determinar requisitos rigorosos no design de sistemas nos quais os testes se baseiam. Uma ferramenta adequada é o teste baseado em requisitos.
Um tipo de estratégia baseada em requisitos é o teste baseado em risco. Além disso, as partes da funcionalidade do sistema mais expostas a riscos são testadas primeiro. O risco é uma possível consequência negativa de um sistema com defeito. A consequência é um risco na presença de dois componentes, como oportunidade e negatividade.
Existem dois tipos de riscos:
1. Risco do produtoPode ser gerenciado e não gerenciado. No exemplo acima, enfrentamos um risco gerenciável: rápido crescimento e complexidade da funcionalidade, o que aumentou a probabilidade de regressão. Aqui, resolvemos o problema com uma base de teste compreensível e automação subsequente. O risco que não podemos afetar é a dependência de sistemas externos e sua falha no processo de integração. Aqui, estabelecemos as medidas que reduzirão seu impacto em nosso sistema. Por exemplo, usando backup, manipulando casos excepcionais, exibindo avisos para o usuário.
2. Risco do projetoPor exemplo, em um projeto, fomos confrontados com o fato de o cliente não ter trabalhado anteriormente com uma equipe distribuída e, portanto, o fluxo de trabalho usado não atender aos requisitos e criar problemas adicionais de comunicação: falta de entendimento, duplicação de tarefas, desempenho de tarefas mutuamente exclusivas e assim por diante. Concordamos na reestruturação e melhoria do processo - revisamos o fluxo de trabalho, apresentamos todos os membros da equipe, realizamos comícios, apresentações e retrospectivas. Como resultado, o trabalho foi na direção certa.
A abordagem baseada em risco permite compor um certo número de riscos, por um curto período de tempo, para testar os riscos com alta prioridade e fornecer ao cliente métricas sobre o quão bem eles foram testados, mostrando o número de casos planejados e concluídos e o número de defeitos.
A implementação de uma abordagem baseada em risco em um projeto ocorre em quatro etapas:
Identificação de riscos - nesta fase, você precisa identificar os riscos e obter uma lista deles.
Avaliação de risco - aqui analisamos a lista e a classificamos por prioridade.
Mitigação de Riscos - nesta fase, determinamos com que profundidade testaremos os riscos.
Gerenciamento de riscos - aqui decidimos como continuaremos a trabalhar com eles e passar por eles, identificar novos riscos.
Os riscos são identificados e avaliados por um grupo de partes interessadas durante as sessões de brainstorming. A equipe deve incluir analistas de negócios ou portadores de conhecimento sobre o sistema do cliente, desenvolvedores, gerente ou gerente de projeto, arquitetos, especialistas em controle de qualidade. Envolvemos especialistas em segurança da informação, funcionários que trabalham diretamente com o sistema atual e analistas de negócios que estão imersos em processos para identificar e avaliar riscos.
Considere a abordagem baseada em risco no exemplo de teste do sistema de aquisição da Internet.
Trabalhar com riscos (no exemplo de um sistema de aquisição da Internet)
Destacamos os seguintes requisitos:
D1.Fornece 1000 conexões simultâneas ao sistema por segundo.
D2 Segurança de transação.
D3 O acesso à transação deve estar disponível apenas para a pessoa que faz a transação.
D4 Fornecer e dar suporte ao padrão SET (Secure Electronic Transaction).
Como risco do produto, podemos distinguir:
RP1. Falha no sistema com conexões simultâneas.
RP2. Usando injeção SQL durante a transação.
RP3. Acesso à transação de outra pessoa ao alterar parâmetros no URL.
RP4. Perda de dados quando a conexão com o banco é perdida no momento da transação.
RP5. O uso de certificados inválidos ao fornecer o sistema SET (Secure Electronic Transaction).
Como riscos organizacionais:
RO1. A queda do sistema desenvolvido devido à inacessibilidade de sistemas externos.
RO2. A presença de casos difíceis de reproduzir que não podem ser detectados em um ambiente de teste.
Assim, cada risco segue logicamente dos requisitos que estão no sistema, mas não está limitado a eles. Os riscos complementam os requisitos e identificam casos adicionais que podem surgir ao trabalhar com o sistema.
Os riscos podem ser reduzidos ou compensados, dependendo dos objetivos do projeto e dos requisitos do sistema. Aceita-se que o risco seja coberto pelo caso de teste pelo menos uma vez:
1. Para cada risco de produto, um conjunto de casos de teste RP1-RP4 é preparado com a condição de que cada requisito e cada risco sejam cobertos por pelo menos um caso de teste. Dependendo dos objetivos do teste, o conjunto de casos de teste é expandido para um determinado nível de detalhe.
2. Para cada risco organizacional, é preparada
uma lista de atividades que podem reduzir o impacto do risco no produto que está sendo desenvolvido.
Técnicas de avaliação e gestão de riscos
Existem vários métodos para avaliar e gerenciar riscos: métodos leves (PRAM, PRISMA) e mais formais (FMEA, FTA).
Com o modelo FMEA, a equipe do projeto identifica todos os processos, componentes, módulos do sistema nos quais pode ocorrer uma falha ou erro no sistema que pode levar à degradação da qualidade do produto. Durante o brainstorm, os riscos do sistema são determinados por três indicadores: gravidade, prioridade, probabilidade. Em seguida, o número de prioridade do risco é calculado para cada risco e, dependendo dos indicadores, a profundidade do teste é estabelecida.
Com o modelo FTA, todas as causas que podem levar a defeitos nos processos de negócios do sistema são determinadas em estágios. A análise vai do nível mais alto ao mais baixo. A diferença entre FMEA e FTA é que a primeira abordagem se concentra na funcionalidade do sistema e a segunda nos processos de negócios.
Além dessas abordagens formais e pesadas, existem outras mais flexíveis e informais. Por exemplo, os métodos PRAM (Análise Pragmática e Gerenciamento de Riscos) e PRISMA (Gerenciamento de Riscos do Produto). Eles combinam com sucesso e facilidade estratégias baseadas em riscos e requisitos. Basicamente, essas abordagens usam especificações de requisitos como entrada, mas as partes interessadas também podem estar envolvidas.
Os métodos leves de análise de risco são muito semelhantes aos formais. Eles se concentram nos riscos técnicos ou comerciais, ponderando a probabilidade de ocorrência do risco e os fatores que afetam essa probabilidade.
No entanto, os únicos dois fatores usados por esses métodos são a probabilidade de risco e seu impacto. Além disso, essas abordagens usam julgamentos qualitativos simplificados e escalas para tomar decisões.
Nossas equipes usam métodos leves e flexíveis e adaptam as abordagens PRAM e PRISMA a seus objetivos.
Como trabalhamos com testes baseados em risco
Por exemplo, em um dos projetos, identificamos os riscos do projeto e do produto que podem funcionar. Para fazer isso, analistas, desenvolvedores e controle de qualidade participam da análise - um representante da equipe.
Uma tabela de risco é formada com os produtos. Eles determinam a avaliação da probabilidade de ocorrência de um risco e seu possível impacto no sistema em uma escala de cinco pontos. Na tabela 1 - a influência mais forte, 5 - a mais fraca. Também para probabilidade 1 - alta probabilidade, 5 - baixa probabilidade.
Como continuamos a trabalhar com riscos do produto
Além disso, para cada um deles, a cobertura de riscos do produto é rastreada com casos de teste.
Selecionamos as seguintes verificações:
TC1. Verificação de carga com mais de 1000 conexões com o sistema
TC2. Teste de carga com 1000 conexões do sistema
TC3. Inserir injeção SQL durante a transação
TC4. Insira injeção SQL na página da transação bem-sucedida, substituindo outros dados
TC5. Inserir scripts XSS (Cross-Site Scripting) nos campos disponíveis para entrada ao fazer uma transação
TC6. Simulação de uma conexão à Internet desconectada durante uma transação
TC7. Saindo de uma sessão de transação na etapa de verificação
TC8. Validação de certificados expirados durante a transação
Assim, as verificações de prioridade são TC2, TC4, TC5.
TC6 e TC8 têm um alto impacto, mas com menor probabilidade, portanto, a prioridade de verificação é menor, mas também são necessárias verificações.
O TC7 não se aplica a nenhum dos requisitos, mas estende o teste para um cenário negativo, o que é possível com a operação estável do sistema.
Como continuamos a trabalhar com os riscos do projeto
Também determinamos ações para os riscos do projeto, pelas quais atribuímos medidas e decisões adicionais.
Em risco “RO2. A presença de casos difíceis de reproduzir que não podem ser detectados no ambiente de teste ”, você pode fazer o seguinte:
- Prepare um estande de pré-produção, o mais próximo possível do ambiente real do aplicativo, em conjunto com todos os sistemas externos;
- escreva scripts de teste de ponta a ponta que passam por todos os sistemas adjacentes e fornecem verificação de transação;
- depois de realizar todas as verificações prioritárias, use as técnicas de adivinhação de erros de acordo com os requisitos básicos do sistema e scripts para verificações adicionais na função de "cracker do sistema".
Plano de emergência
É importante ter um plano de ação caso um dos riscos do produto ou projeto funcione. Às vezes, pode salvar a configuração de um sistema de backup do projeto. Nem sempre é possível reduzir o risco a um nível mínimo, mas deve ser possível reduzir pelo menos suas conseqüências. Nosso post
“Christmas Story” foi sobre este tópico: como um risco pode funcionar, cuja probabilidade tende a zero.
Por exemplo, devemos eliminar completamente a perda de dados durante uma transação, mas considerar todos os casos trabalhosos demais. Portanto, você precisa ter maneiras de lidar com esses casos. Uma das opções de segurança é o desenvolvimento de logs mais detalhados. Isso fornecerá um ponto de reversão permanente para a ação anterior, se algo der errado durante a transação.
Conclusão
O teste baseado em risco permite cobrir as áreas mais arriscadas com casos de teste, reduzindo assim o impacto e a probabilidade de serem acionados. Essa é a estratégia mais vencedora para sistemas com lógica de negócios complexa e alto custo de erro. A solução é adequada para o setor bancário, seguradoras, sistemas internos complexos de CRM de um perfil médico. Com uma abordagem baseada em riscos, também trabalhamos com os riscos do projeto, o que melhora o processo geral de teste e gerenciamento de projetos.