Gerenciamento de riscos

As principais atividades do gerenciamento de riscos são:

Identificação – identificar (ou as vezes imaginar) quais são/serão os riscos de projeto e de qualidade
Analise – classifica-los dentro de um nível, normalmente caracterizado por uma relação de impacto e probabilidade
Controle – abrange o conjunto de atividade de mitigação, contingência, transferência e aceitação de riscos

Um pouco mais de cada uma...:

IDENTIFICAÇÃO DE RISCOS

Como identificar riscos? Algumas sugestões:
-Entrevista com especialistas (na tecnologia e no negócio – pessoas diferentes, provavelmente)
-Checklists
-Analisar projetos similares já realizados
-Workshops, brainstorms

Pode ser interessante manter separadamente os riscos de projeto e os riscos de qualidade já que as pessoas que detém o conhecimento para elencá-los podem ser diferentes. O levantamento, entretanto pode ocorrer simultaneamente.

É possível detectar riscos estudando a documentação do projeto, nessa prática, essa revisão pode ajudar a encontrar erros na documentação.

As reuniões de identificação podem parar na detecção dos riscos, ou na própria reunião pode ser possível classificá-los ou mesmo detectar seu impacto. O acúmulo de atividades na reunião depende do andamento e produtividade dela.

ANÁLISE/AVALIAÇÃO DE RISCOS

Depois de identificá-los, deve ser feito um estudo emcima de cada risco categorizando-os e atribuindo-les um nível.

Sobre atribuir um nível, já foi mencionado que isso pode ser feito através da relação de impacto e probabilidade. Mas como definir isso? Probabilidade está normalmente relacionada a fatores técnicos e Impacto a fatores de negócio.

Exemplos de fatores técnicos:
-Complexidade da tecnologia
-Conhecimento do time
-Incompatibilidade de tecnologia legada com a aplicada
-Falta de quality assurance
-Ausência de testes em fases iniciais
E vários outros

Exemplos de fatores de negócio:
-Frequencia/Sazonalidade de uso de uma funcionalidade
-Possibilidade de sanções criminais
-Potenciais perdas de lucros
Entre outros

Pode-se atribuir o nível de risco quantitativamente ou qualitativamente. Quantitativamente pode-se considerar a probabilidade como um percentual e o impacto como um valor financeiro e assim teríamos exatamente o que representa o risco em números.

O mais comum é vermos essa atribuição qualitativamente, isso porque é difícil ter a base estatística necessária para pontuar quantitativamente. Qualitativamente os endereçaríamos como riscos de nível alto, médio ou baixo.

Sobre categoria, pode-se usar por exemplo as características descritas na ISO9126 (Funcionalidade, Confiabilidade, Usabilidade, Eficiência, Manutenibilidade, Portabilidade e suas sub caracteristicas). E pra que serve isso? No geral, para determinar os responsáveis (ou áreas responsáveis) pelos grupos de riscos. Isso, claro, se houver um motivo prático para categoriza-los.

MITIGAÇÃO/CONTROLE DE RISCOS

Os riscos podem ser controlados através das atividades de:
-Mitigação
-Contingência
-Transferência
-Aceitação

A mitigação consiste na definição de atividades que possam diminiur o impacto ou a probabilidade de um risco ocorrer.
A contigência é utilizada como uma ação caso o risco venha a ocorrer (quando um risco acontece, deixa de ser um risco, passa a ser um fato ou issue).
A tranferência consiste em transferir para outra parte o risco. E não interpretar isso como um jogo de culpas entre times. Nesse processo, no caso de uma empresa prestando serviço para um cliente, o risco pode ser assumido pelo cliente ao invés da empresa ou vice-versa, entre outras situações.

A abordagem analítica de teste baseado em riscos foca na criação de ações de mitigação, especialmente de riscos de qualidade, para o time de teste. O teste mitiga os riscos de qualidade durante todo o ciclo de desenvolvimento.

Alguns riscos de projeto também podem ser controlados, como:
Preparação adequada de ambiente de teste e ferramentas
Baixa qualidade de inputs para o teste
Falta de padrões, regras e tecnicas para o teste

Apesar de ser papel do gerente de controlar esses riscos, são riscos que afetam os analistas e estes devem controlá-los também.

Testes preventivos são parte da estratégica de testes baseados em riscos. A idéia é mitigar os riscos de qualidade antes mesmo da execução dos testes preparando bem o ambiente de testes, fazendo um pre teste antes de começar formalmente uma fase de testes, participando em reuniões e revisão/inspeção, monitorando o progresso e a qualidade do projeto, etc.

Oportunidades de aplicação de testes preventivos:
-Escolher a tecnica de testes adequada
-Realizar revisões e inspeções
-Revisar os projetos de teste
-Definir estratégias de testes de confirmação e regressão

Perceba que as atividades do teste preventivo não são as que comumente lembramos quando falamos de teste. Se os requisitos parecem não estar bem definidos, então o ideal é realizar revisões e inspeções, ao invés de postergar essas correções para a fase de testes.

Existem duas formas de priorizar os testes: depth-first ou breadth-first.

Depth-first: Todos os testes dos riscos mais altos são rodados primeiros e os riscos mais baixos por último.
Breadth-first: São selecionadas amostragens em todos os níveis de riscos, usando esses níveis para ponderar as seleções (são selecionados mais testes de níveis de risco mais alto, que de nivel mais baixo).

A melhor cobertura depende de uma análise do seu projeto.

E a famosa pergunta: quando parar de testar? Nessa abordagem a resposta é; Quando o risco residual for considerado aceitável.

Supondo que não tenhamos mais tempo para testar ou que o tempo foi reduzido e não será possível cumprir o planejamento inicial. Como realinhar a estratégia? Repriorizando os testes de acordo com os resultados obtidos. Mas exatamente o que olhar nesses resultados?
-Novos riscos de produtos
-Áreas muito modificadas
-Áreas instaveis descobertas durante os testes
-Riscos associados a defeitos
-Descoberta de bug clusters inesperados
-Descoberta de áreas críticas de negócio

Aproveite para atualizar o seu planejamento de riscos inicial.

IV EBTS

Já está aberto o prazo de submissão de artigos para o IV Encontro Brasileiro de Testes de Software em Recife/PE

Os interessados podem submeter seus trabalhos até o dia 29 de dezembro, em formato PDF, através do e-mail ebts@gotest.biz. Os artigos devem conter entre quatro e seis páginas e seguir o modelo da ACM SIG Proceedings, disponível gratuitamente no site www.acm.org/sigs/pubs/proceed/template.html.


Os artigos a serem submetidos ao IV EBTS devem oferecer um melhor entendimento sobre boas práticas de testes de software, além de se reportar a lições aprendidas, inovações e aplicações práticas. No dia 25 de janeiro, será divulgada a relação dos artigos aceitos. Os selecionados terão até o dia 15 de fevereiro para entregar a versão final e o material de apresentação a ser usado durante o evento.


O EBTS é um evento que visa promover o intercâmbio de idéias entre empresas e academia com o objetivo de estimular debates e discussões sobre testes de software, promovendo, assim, a troca de conhecimentos e a integração entre academia e o mercado.

O encontro acontecerá entre os dias 23 e 24 de abril e terá, em sua programação, palestras técnicas, mini-cursos, convidados renomados da área de testes, competições e premiações. A iniciativa é promovida pela GOTEST e conta com apoio do C.E.S.A.R e do Porto Digital.


Mais informações através do site http://www.gotest.biz/ebts2010/