Anlise de Riscos em Teste de Software

Emerson Rios
Diretor do Instituto de Teste de Software - iTeste Presidente da Associao Latino Americana de Teste de Software - ALATS emersonrios@alats.org.br

Abstract. This article describes a proposal to deal with risks in projects of software tests. We consider tests as a parallel project to the project of development of software. This way its treated in the same manner the PMI stipulates in its PMBOK, with life cycle as well as a plan for managing risks. In the tradicional models, tests continue to be treated as an activity or one step in the project of development of software.The article also shows that the tests of software can be one process with its own process of management of risks as the CMMI defines in its methodology. Resumo. Este artigo descreve uma proposta de tratamento de riscos em projetos de testes de software. Consideram-se os testes como um projeto paralelo e aderente a um projeto de desenvolvimento de software, sendo desta forma tratado da mesma forma que o PMI apregoa no seu PMBOK, com ciclo de vida e um plano de gerencia de riscos. Nos modelos tradicionais o teste continua ainda a ser tratado como uma atividade, ou seja, uma etapa dentro do projeto de desenvolvimento de software. O artigo mostra tambm que o teste de software pode tambm ser um processo com uma rea de processo de gerncia de riscos, conforme define a metodologia do CMMI.

1. O que risco
Para entendermos corretamente o conceito de risco teremos que levar em considerao alguns elementos envolvidos na sua definio. A primeira preocupao que devemos ter ao definir um risco o seguinte: Se alguma coisa com certeza vai acontecer, ento isso deixa de ser um risco. Um risco nunca uma certeza de ocorrncia. Se alguma coisa vai realmente ocorrer, com probabilidade de 100%, ento isso um problema e no um risco. Um risco pode ser tratado preventivamente, o que no ocorre com um problema. Se um risco uma coisa que no temos certeza que vai ocorrer ento podermos usar a seguinte definio para risco: Risco algum evento no futuro cuja ocorrncia poder causar algum tipo de problema, no caso, ao projeto de teste de software.

Podemos tambm afirmar que um risco um acidente de percurso que pode causar um desvio anormal num projeto ou num processo. Um projeto tem um ciclo de vida que pode ser mudado pela ocorrncia de um evento, que no incio do projeto foi caracterizado como risco, impedindo o seu prosseguimento normal. Se voc est preparando uma viagem para So Paulo de avio, um atraso no vo um risco. Um risco pode se tornar um problema, caso no venha a ser gerenciado. Um risco pode ser dividido da seguinte forma: Sintoma Fonte Conseqncia. 1.1. Sintoma Chamamos de sintoma aquilo que pode indicar um problema. Se usarmos como exemplo o uso de uma ferramenta de automao para a executar testes de carga o sintoma seria: Execuo inadequada dos testes de carga.

1.2. Fonte
Podemos dizer que a fonte do risco o processo de aquisio da ferramenta que precisa estar concludo num prazo hbil que permita a equipe de teste ser treinada no seu uso, alm de precisar de tempo suficiente para us-la em projetos pilotos.

1.3. Conseqncia
A conseqncia da ocorrncia do risco, virando um problema, podem ser testes de carga mal executados ou at a sua falta de execuo em tempo hbil, por falta de disponibilidade da ferramenta a ser usada.

1.4. Resumo
Podemos resumir esta definio de risco da seguinte forma: Devido a uma <fonte>, o <sintoma> est ocorrendo, podendo causar <conseqncias>. Voltando ao nosso exemplo podemos afirmar o seguinte: Devido a um <atraso no processo de aquisio do software de teste de carga>, a <execuo inadequada dos testes de carga> est ocorrendo podendo causar <a liberao do software sem a adequada performance exigida nos seus requisitos>. Para fixar este conceito vamos dar um outro exemplo. Vamos supor que a equipe de testes no consegue preparar adequadamente os seus casos de teste porque a equipe de desenvolvimento do software tambm no documenta adequadamente os seus casos de uso. Isso com certeza poder fazer com que alguns defeitos no sejam detectados, resultando em possveis problemas no negcio. Usando a nomenclatura definida anteriormente podemos afirmar o seguinte: 2

Devido a <falta de documentao dos casos de uso>, os <casos de teste foram preparados inadequadamente ou incompletos> o que poder <produzir testes mal feitos causando o surgimento, posteriormente, de defeitos no ambiente de produo>.

2. Tipos de Risco de Teste

Quando falamos sobre testes podemos estar nos referindo a execuo desta atividade em um produto de software, um projeto de teste de software ou um processo de teste de software.

2.1. Produto de software

Muitas empresas desenvolvem produtos de software para venda, por exemplo. Essas empresas efetuam testes antes de liberar o seu produto, mas no possuem uma equipe permanente especializada em testes, logo executam basicamente testes unitrios e testes de integrao. Sai muito mais barato, por exemplo, contratar uma outra empresa especializada em testes para executar esta atividade. O negcio de uma empresa desenvolver e o da outra testar.

2.2. Projeto de software

O risco de teste num projeto de software pode surgir atravs de duas causas bsicas: Custo Prazo Todos sabemos que teste custa dinheiro, no necessariamente muito dinheiro, mas realmente tem um custo adicional. Muitas vezes o oramento para o desenvolvimento ultrapassa as previses iniciais aumentando substancialmente o custo do software. Nesses casos, muitas vezes, o processo de teste sacrificado por falta de recursos. Isso pode ser feito pela reduo do seu escopo ou pela execuo dos testes pela prpria equipe de desenvolvimento. O gerente do projeto, for falta de recursos, prefere correr o risco de entregar um produto que poder dar defeitos no futuro.

Regra 10 de Myers
12000 10000 Custo em US$ 8000 6000 4000 2000 0
D es en ho Te st e

Fases do processo de desenvolvim ento

Figura 1 Regra 10 de Myers

Tabela 1 Ciclo de vida de teste Esse ciclo de vida poderia ser resumido nas seguintes etapas: Anlise de requisitos Planejamento Preparao Especificao Execuo Entrega

2.3. Processo de teste

Normalmente os riscos de produto ou projeto so sintomas do processo de testes. Isto significa dizer que devido a um processo, por exemplo, mal definido ou mal estruturado, ou no perfeitamente absorvido pela equipe de testes um projeto de testes, foi mal executado ou um produto foi incorretamente testado. O processo de testes deve ter um ciclo de vida, como exemplificamos anteriormente, e uma metodologia. O processo de testes deve ser paralelo ao processo de desenvolvimento, o que significa dizer que os testadores devem iniciar os seus trabalhos no incio do desenvolvimento do sistema.

3. Como tratar o risco

Ns vimos anteriormente que os tipos de risco de teste de software podem estar ligados ao produto, projeto ou processo. Agora vamos acrescentar alguns outros conceitos a esta abordagem. Ao nos depararmos com um risco devemos trat-lo ou analis-lo usando alguns conceitos bsicos que procuraremos definir adiante.

Evitar ou transferir Aceitar Mitigar Monitorar

Evitar ou transferir
Caso consigamos evitar o risco ou transferir a sua responsabilidade para outro, ele deixa de ser um risco do projeto. Para isso preciso analis-lo e conhece-lo.

Aceitao
O risco foi identificado e definido como de responsabilidade da equipe de testes, e, neste caso, precisamos elaborar um plano para que possamos evitar que o risco venha a se tornar um problema no futuro.

Mitigao
Atravs da mitigao vamos preparar um caminho para reduzir o impacto do risco dentro do projeto de testes. Desta forma procuraremos evitar que o risco se transforme num problema, embora possa vir a causar prejuzos limitados.

Monitorao
Os riscos identificados precisam ser monitorados para que possamos saber se a probabilidade de ocorrncia est se tornando maior ou menor. Caso caminhemos para a certeza da sua ocorrncia o plano de contingncia dever ser acionado.

4. Riscos nos processos de teste

Todo projeto est sujeito a riscos. A gerncia de projetos, conforme apregoado pelo PMI, possui uma rea de gerncia especfica para riscos. Dentro dos conceitos atuais, o projeto de desenvolvimento de um software deve ser acompanhado por um outro projeto de teste deste mesmo software. Logo, o projeto de teste de software est sujeito a riscos. Dizem os especialistas que sempre que os testes so executados ao final do projeto de desenvolvimento, desta forma sob a caracterizao de uma atividade dentro do ciclo de vida de desenvolvimento, os riscos so maiores, e as razes so diversas, dentre as quais podemos listar: Ao final do projeto de desenvolvimento as presses so muito maiores; Os prazos de teste tendem as ser reduzidos; O trabalho de teste tende a ser feito de forma incompleta; Os produtos so liberados para a produo sem a qualidade desejada e carregando inmeros defeitos no identificados. Essa lista poderia ainda ser muito maior, mas basicamente podemos afirmar que o teste tratado sob a forma de um projeto, com uma equipe segregada e qualificada, tende a apresentar resultados muito melhores.

5. Gerencia de riscos O diagrama mostrado na Figura 3 mostra o modelo para o processo de gerncia de risco de testes. Este modelo identifica seis etapas, quais sejam: Identificao Anlise Classificao Planejamento Monitoramento/Rastreamento Controle Identificao de riscos O primeiro passo no processo de gerenciamento de riscos identificar os riscos..
Para identificar esses riscos podemos adotar o seguinte critrio:

Gerencia de Riscos
Incio Controle

Rastreamento

Identificao

Planejamento

Anlise

Classificao

Figura 3 Modelo para gerncia de riscos em projetos de teste de software.

Avaliar os problemas j enfrentados em outros projetos, pois alguns tendem a se repetir. Realizar entrevistas com os principais tcnicos envolvidos no projeto de teste e de desenvolvimento.

 Fazer sesses de troca de informaes (brain storm) entre os principais tcnicos envolvidos nos projetos de teste e de desenvolvimento. Rever a documentao do software buscando conflitos, ambigidades e plausibilidade (viabilidade de uso e aplicao). Muitas vezes um requisito ambguo, por exemplo, pode gerar defeitos no produto entregue e causar prejuzos srios ao negcio. Neste caso, no ser possvel escrever um requisito de teste adequado. Utilizar um lista de verificao com riscos conhecidos para identificar aqueles que podem ocorrer no projeto de testes, como, por exemplo, uma base de riscos da organizao.

5.1. Identificao dos riscos Problemas passados

Uma das boas prticas de testware termos uma base de documentao de testes o mais completa possvel. Nesta documentao vamos encontrar os registros dos problemas que ocorreram em projetos anteriores. Algumas empresas mantm uma base de problemas ocorridos em projetos anteriores organizada, classificada e indexada de forma a ser acessvel por gerentes de novos projetos. Essa prtica evita a repetio de erros passados.

Entrevistas
Nem sempre a base de documentos dos projetos de teste est suficientemente atualizada e nem sempre todos os problemas ficam registrados. Todos ns sabemos que pela prpria natureza humana alguns gerentes procuram esconder as suas falhas. Outros nem sempre so to cuidadosos. Desta forma, para buscar problemas passados ou outros que podem ocorrer, e, que muitas vezes j esto na cabea dos tcnicos experientes, uma outra maneira de identificar os riscos atravs da entrevistas com tcnicos e gerentes chaves no processo de testes, ou que possam vir a ter influncia neste processo.

Sesses de troca de informaes (brain storm)

Como vimos anteriormente existem vrios mtodos para identificarmos os riscos do projeto, e as sesses de troca de informaes apenas um deles, que vamos procurar detalhar mais agora. O ponto inicial montar uma equipe pequena mas que esteja focada no problema, isto , deve-se evitar a presena de pessoas que no tenham relao estreita com o projeto de testes. Esta lista deve basicamente ser a seguinte: Facilitador Testadores Desenvolvedores Gerentes envolvidos nos processos Usurios (em alguns casos os usurios podem ser importantes, porm nem sempre sero necessrios).

O processo para identificao dos erros, neste caso, deve iniciar incentivando todos os participantes a identificarem os potenciais riscos do projeto que sero registrados numa lista. Cada um tem liberdade para incluir o risco que achar importante e que possa prejudicar o bom andamento do projeto de testes. Esse processo deve continuar, com toda a liberdade, sem restries ou censuras, at que uma lista completa esteja pronta. O passo seguinte deve ser a classificao dos riscos listados como sintoma, fonte e conseqncia. Lembre-se do quadro que repetimos adiante. Devido a uma <fonte>, o <sintoma> est ocorrendo, podendo causar <conseqncias>. Muitas vezes fcil confundir sintoma com fonte, logo devemos tomar cuidados nesta classificao. Identificados todos os riscos possveis devemos ento classific-los como riscos do projeto, processo ou produto, ou outra forma de classificao adatada pela organizao. Com esta lista organizada da forma descrita, devemos discutir o mximo possvel sobre os impactos de cada um dos riscos. Esta uma das formas de identificarmos de forma ordenada e estruturada alguns dos riscos dos projetos de teste. Lembre-se que existem outros mtodos que podem ser usados para identificar os riscos, como a reviso da documentao e a lista de verificao que descreveremos adiante.

Reviso da documentao
Existem diversas tcnicas de inspeo e de reviso de documentao que fazem parte da atividade de verificao. O usual fazer atravs de reunies envolvendo os tcnicos chaves para o projeto de testes. Um dos documentos mais importantes e que faz parte do incio do processo de testes so os requisitos do projeto de desenvolvimento e que iro originar os requisitos do projeto de testes. Lembre-se que falamos anteriormente que a anlise dos requisitos do sistema, e, conseqentemente, a preparao dos requisitos de teste, a primeira etapa do ciclo de vida do processo de testes. A reviso da documentao tem por objetivo encontrar o seguinte: Conflitos Ambigidades Plausibilidade Detalhando um pouco mais temos as seguintes definies: Conflitos Os requisitos esto consistentes entre si? No existem conflitos entre os requisitos e outros itens? Os requisitos esto pertinentes com as necessidades de negcio do usurio? 8

Ambigidade Existe apenas uma interpretao do requisito? Os significados esto claramente entendidos? A terminologia usada est consistente? Plausibilidade Os requisitos so passveis de serem cumpridos? Os requisitos podem ser implementados com as tcnicas, ferramentas, recursos e pessoas disponveis, e tambm dentro do oramento, custo e cronograma?

Este mesmo mtodo pode tambm ser usado quando fazemos a reviso ou inspeo de outros documentos do projeto de desenvolvimento e do projeto de testes. Por exemplo, o Plano de Testes fonte para outros documentos como os Casos de Testes. Da mesma forma que os requisitos, o plano de testes deve estar sem ambigidades, sem conflitos e deve ser plausvel de ser implementado.

Lista de verificao
Existem listas de riscos j prontas para projetos de testes, cujo contedo no vamos detalhar, que classificam os riscos da seguinte forma: Processo de teste Tamanho do produto Usurio Gerencia do projeto Processo de software Pessoas Tecnologia.

Certamente outras listas podero ser acrescentadas s mostradas anteriormente pois os riscos podem acontecer devido a diversos outros aspectos inerentes, especificamente, ao ambiente onde o projeto est sendo desenvolvido.

5.2. Anlise e classificao dos riscos

Os riscos identificados na etapa anterior devem ser agora analisados. Uma das formas de fazer esta anlise respondendo as perguntas listadas adiante. O risco relevante para as atividades de teste? Este risco est na alada de responsabilidades da equipe de testes? O risco previsvel porm no existe nenhuma certeza absoluta quanto a sua ocorrncia futura? O risco significante para o projeto de testes? Se o risco foi selecionado com resposta positiva em alguma das perguntas anteriormente apresentadas e tambm recebeu sim para a seguinte pergunta:

 O risco no est sendo tratado pelo plano de gerncia do projeto de software? Os riscos devem ser identificados e listados numa tabela com o seguinte contedo bsico: Risco Tipo de risco Probabilidade Impacto ou criticidade Classificao ou pontuao probabilidade x impacto Data de reviso do risco Responsabilidade Plano de mitigao Plano de monitoramento Plano de contingncia

Probabilidade
A sugesto que sejam utilizados valores entre 10% e 90% e que os incrementos sejam em mltiplos de 10. Lembre-se que 0% no precisa ser tratado, visto que o risco no vai ocorrer, e que 100% uma certeza de ocorrncia, logo no um risco e sim um problema.

Criticidade
A sugesto que seja utilizada uma escala de 1 a 5, onde poderamos identificar os valores da seguinte forma: 1 impacto baixo no sucesso do projeto; 2 impacto mdio no sucesso do projeto; 3 impacto alto no sucesso do projeto; 4 impacto muito alto no sucesso do projeto; 5 impacto que pode afetar seriamente o sucesso do projeto.

Pontuao
Multiplicando-se os valores da probabilidade pela criticidade teremos nmeros entre 0,1 e 4,5. A tabela deve ento ser ordenada pelos valores da pontuao. O gerente do projeto de testes deve ento reservar pelo menos os dez maiores riscos para que sejam tratados. Pode ser que em projetos muito grandes existam muitos riscos com pontuao alta e que no devem ser descartados. Na verdade, o bom senso aconselha a que os riscos considerados altos, 4 a 4,5, por exemplo, devem ser sempre monitorados.

5.3. Planejamento dos riscos

Escolha os riscos mais relevantes usando o critrio de pontuao anteriormente mostrado. Os riscos mais relevantes podem ser os dez maiores, ou seja, aqueles que receberam a pontuao mais alta. Podem ser tambm todos que receberam a pontuao alta, caso exista um nmero significante de riscos com esta pontuao. A organizao ou o gerente do projeto pode escolher os riscos segundo o seu bom senso observando sempre a tabela de anlise de riscos. No existe uma regra fechada para a escolha dos riscos que sero monitorados.

10

Uma vez selecionados os riscos, para cada um deles dever ser feito o seguinte: Preparar um plano de mitigao Preparar um plano de monitorao ou rastreamento Preparar um plano de contingncia.

Plano de mitigao
O plano de mitigao serve para que o gerente possa tentar diminuir o impacto do risco ou at mesmo evitar a sua ocorrncia. Atravs da mitigao vamos preparar um caminho para reduzir o impacto do risco dentro do projeto de testes. Desta forma procuraremos evitar que o risco se transforme num problema, embora possa vir a causar prejuzos limitados. A definio anterior foi apresentada anteriormente neste artigo. Devido a <falta de documentao dos casos de uso>, os <casos de teste foram preparados inadequadamente ou incompletos> o que poder <produzir testes mal feitos causando o surgimento d defeitos posteriores no ambiente de produo>. O risco que repetimos anteriormente tambm j foi apresentado como exemplo neste artigo. Neste caso qual seria o plano para mitigao desse risco? Certamente este ser um risco de alta criticidade e pelo visto a sua probabilidade de ocorrncia tambm alta (suposio). O plano de mitigao deve ser a promoo de reunies de reviso e inspeo na documentao dos casos de uso de forma a melhorar a sua qualidade e tambm permitir que os casos de teste sejam mais bem feitos. Caso existam resistncias, o gerente do projeto de testes dever procurar apoio nas gerncias superiores, com forma de conseguir prioridade para este tipo de trabalho. Deve tambm ser levado em conta o custo e o benefcio do plano de mitigao para ver se vale a pena lev-lo adiante ou se sai mais barato correr o risco.

Plano de monitorao ou rastreamento

Monitorao Os riscos identificados precisam ser monitorados para que possamos saber se a probabilidade de ocorrncia est se tornando maior ou menor. Caso caminhemos para a certeza da sua ocorrncia o plano de contingncia dever ser acionado. Uma das formas de monitorarmos um risco comearmos analisando os sintomas. No caso do nosso exemplo o sintoma seria dado pela dificuldade na elaborao dos casos de testes. O plano deve indicar um responsvel por esta tarefa e deve tambm estabelecer datas para que isso seja feito. Normalmente as datas devero ser definidas entre perodos de tempo razoveis para evitar que o risco se torne um problema.

11

Lembre-se que o monitoramento verificar se o plano de mitigao est produzindo resultados satisfatrios.

Plano de contingncia
O Plano de Contingncia ser sempre acionado quando o risco se transformar num problema. Neste caso no existe mais a chance de evitarmos o risco e estamos frente a um problema. No caso do nosso exemplo, os casos de teste esto sendo elaborados insatisfatoriamente porque os casos de uso no esto suficientemente documentados. Possivelmente um plano de contingncia seria a contratao de um tcnico para em carter de urgncia fazer este trabalho, pois pode ser que os desenvolvedores no tenham tempo disponvel para fazer isso, ou at mesmo, no tenham o perfil adequado para este trabalho.

5.4. Rastreamento e controle

A gerncia de riscos um processo constante e contnuo. Os riscos podem mudar no tempo, e, conseqentemente, durante o desenvolvimento do projeto. No caso de projetos longos, alguns novos riscos podem surgir e antigos riscos podem desaparecer. Alm disso, a severidade dos riscos pode mudar medida que o projeto evolui. O Plano de Mitigao deve ser mantido atualizado e tambm o Plano de Monitoramento ou Rastreamento dos Riscos.

6 Concluso
A atividade de Anlise de Riscos existe para que os gerentes de projetos possam se precaver quanto a futuros problemas. Um risco um sinal de que poderemos ter um problema no futuro, caso nenhuma medida de precauo seja tomada. Os riscos podem prejudicar o sucesso de um projeto, caso no tenham planos de mitigao e de contingncia, e, conseqentemente, precisam ser monitorados. Gerenciar riscos significa, identific-los, analis-los, planej-los e monitor-los. Uma outra questo importante lembrar que o risco pode ser gerenciado dentro de um projeto, como estabelecido pelo PMI, ou num processo, conforme definido pelo CMMI ou mps BR.

7. Bibliografia 1. Ren, Marc. Risk Management for Testers. Quality Assurance Institute Testing Conference, maio de 2005. 2. Rios, Emerson e Moreira, Trayahu. Teste de Software. Editora Altabooks, 2003. 3. Vargas, Ricardo Viana. Gerenciamento de Projetos. Editora Brasport.2002. 4. PMBOK 2000 V.1.0. 5. Vargas, Ricardo. Manual Prtico do Plano de Projeto. Editora Brasport. 2003. 6. Verzuh, Eric. Gesto de Projetos. Editora Campus.2000.

12