1.

O que risco Para entendermos corretamente o conceito de risco teremos que levar em consider ao 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, c om probabilidade de 100%, ento isso um problema e no um risco. Um risco pode ser t ratado preventivamente, o que no ocorre com um problema. Se um risco uma coisa que no temos certeza que vai ocorrer ento podermos usar a se guinte definio para risco: Risco algum evento no futuro cuja ocorrncia poder causar algum tipo de problema, n o caso, ao projeto de teste de software.

1 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 disponibilida de 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 ca rga>, a <execuo inadequada dos testes de carga> est ocorrendo podendo causar <a liberao do so ftware 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, res ultando 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 preparad os inadequadamente ou incompletos> o que poder <produzir testes mal feitos causan do 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 e m 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 exempl o. Essas empresas efetuam testes antes de liberar o seu produto, mas no possuem uma equip e permanente especializada em testes, logo executam basicamente testes unitrios e testes de integrao. Sai muito mais barato, por exemplo, contratar uma outra empre sa 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 dinheir o, mas realmente tem um custo adicional. Muitas vezes o oramento para o desenvolvimento ultrapassa as previses iniciais aumentando substancialmente o cu sto 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.

Re gra 10 de M ye rs 12000 10000 8000 6000 4000 2000 0

Fas e s do proce s s o de de s e nvolvim e nto Figura 1 Regra 10 de Myers Tabela 1 Ciclo de vida de teste Esse ciclo de vida poderia ser resumido nas seguintes etapas: I I I I I I Anlise de requisitos Planejamento Preparacao Especificacao Execucao Entrega

2.3. Processo de teste Normalmente os riscos de produto ou projeto sao sintomas do processo de testes . Isto significa dizer que devido a um processo, por exemplo, mal definido ou mal estru turado, ou nao perfeitamente absorvido pela equipe de testes um projeto de teste s, foi mal executado ou um produto foi incorretamente testado. O processo de testes deve ter um ciclo de vida, como exemplificamos anteriorment e, e uma metodologia. O processo de testes deve ser paralelo ao processo de dese nvolvimento, 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 lig ados ao produto, projeto ou processo. Agora vamos acrescentar alguns out ros conceitos a esta abordagem. Ao nos depararmos com um risco devemos trat-lo ou analis-lo usando alguns conceitos bsicos que procuraremos definir adiante.

I I I I

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 mitigacao vamos preparar um caminho para reduzir o impacto do risco den tro do projeto de testes. Desta forma procuraremos evitar que o risco se t ransforme num problema, embora possa vir a causar prejuzos limitados. Monitorao Os riscos identificados precisam ser monitorados para que possam os 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 pr ojeto de teste deste mesmo software. Logo, o projeto de teste de software est suj eito a riscos. Dizem os especialistas que sempre que os testes sao executados ao final do proj eto de desenvolvimento, desta forma sob a caracterizacao de uma atividade dentro do ciclo de vida de desenvolvimento, os riscos sao maiores, e as razes sao diversas, dentre as quais podemos listar: Ao final do projeto de desenvolvimento as presses sao muito maiores; Os prazos de teste tendem as ser reduzidos; O trabalho de teste tende a ser feito de forma incompleta; Os produtos sao liberados para a producao sem a qualidade desejada e carregando inmeros defeitos nao 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 quali ficada, 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 ris co de testes. Este modelo identifica seis etapas, quais sejam: Identificacao Anlise Classificacao 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

Controle Incio

Rastreamento icao

Identif

Planejamento se

Anli

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 r epetir. Realizar entrevistas com os principais tcnicos envolvidos no projeto de teste e de desenvolvimento.

 Fazer sesses de troca de informaces (brain storm) entre os principais tcnicos envolv idos nos projetos de teste e de desenvolvimento. Rever a documentacao do software buscando conflitos, ambigidades e plausi bilidade (viabilidade de uso e aplicacao). Muitas vezes um requisito am bguo, por exemplo, pode gerar defeitos no produto entregue e causar prejuzos srios ao negcio. Neste caso, nao ser possvel escrever um requisito de teste adequado. Utilizar um lista de verificacao com riscos conhecidos para identificar aqueles que podem ocorrer no projeto de testes, como, por exemplo, uma base de riscos d a organizacao. 5.1. Identificao dos riscos Problemas passados Uma das boas prticas de testware termos uma base de documentacao de testes o mais completa possvel. Nesta documentacao vamos encontrar os registros dos problemas q ue ocorreram em projetos anteriores. Algumas empresas mantm uma base de p roblemas ocorridos em projetos anteriores organizada, classificada e inde xada de forma a ser acessvel por gerentes de novos projetos. Essa prtica evita a repeticao de erros passados. Entrevistas Nem sempre a base de documentos dos projetos de teste est suficientemente atualiz ada 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 sem pre sao tao cuidadosos. Desta forma, para buscar problemas passados ou outros qu e podem ocorrer, e, que muitas vezes j estao na cabeca dos tcnicos experientes, um a outra maneira de identificar os riscos atravs da entrevistas com tcnicos e geren tes chaves no processo de testes, ou que possam vir a ter influncia neste process o. Sesses de troca de informaes (brain storm) Como vimos anteriormente existem vrios mtodos para identificarmos os risc os do projeto, e as sesses de troca de informaces apenas um deles, que vamos procurar detalhar mais agora. O ponto inicial montar uma equipe pequena mas que esteja focada no problema, ist o , deve-se evitar a presenca de pessoas que nao tenham relacao estreita com o pr ojeto 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 serao n ecessrios).

7 O processo para identificacao dos erros, neste caso, deve iniciar incentivando todos os participantes a identificarem os potenciais riscos do projeto que serao registrados numa lista. Cada um tem liberdade para incluir o risco que achar importante e que possa prejudicar o bom andamento do projeto de test es. Esse processo deve continuar, com toda a liberdade, sem restrices ou censura

s, at que uma lista completa esteja pronta. O passo seguinte deve ser a classificacao dos riscos listados como sintoma, font e 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 classificacao. Identificados todos os riscos possveis devemos entao classific-los como riscos do projeto, processo ou produto, ou outra forma de classificacao adatada pela organ izacao. Com esta lista organizada da forma descrita, devemos discutir o mximo possvel sobr e 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 revisao da documentacao e a lista de v erificacao que descreveremos adiante. Reviso da documentao Existem diversas tcnicas de inspecao e de revisao de documentacao que fazem parte da atividade de verificacao. O usual fazer atravs de reunies envolvendo os tcnicos cha ves para o projeto de testes. Um dos documentos mais importantes e que faz parte do incio do processo de testes sao os requisitos do projeto de desenvolvimento e que irao originar os requisit os do projeto de testes. Lembre-se que falamos anteriormente que a anlise dos req uisitos do sistema, e, conseqentemente, a preparacao dos requisitos de teste, a p rimeira etapa do ciclo de vida do processo de testes. A revisao da documentacao tem por objetivo encontrar o seguinte: Conflitos Ambigidades Plausibilidade

Detalhando um pouco mais temos as seguintes definices: Conflitos Os requisitos estao consistentes entre si? Nao existem conflitos entre os requisitos e outros itens? Os requisitos estao pertinentes com as necessidades de negcio do usurio? 8 Ambigidade Existe apenas uma interpretacao do requisito? Os significados estao claramente entendidos? A terminologia usada est consistente? Plausibilidade Os requisitos sao passveis de serem cumpridos? Os requisitos podem ser implementados com as tcnicas, ferramentas, rec ursos e pessoas disponveis, e tambm dentro do orcamento, custo e cronogra ma?

Este mesmo mtodo pode tambm ser usado quando fazemos a revisao ou inspecao de outr os documentos do projeto de desenvolvimento e do projeto de testes. Por exemplo, o Plano de Testes fonte para outros documentos como os Casos de Tes tes. Da mesma forma que os requisitos, o plano de testes deve estar sem ambigidad es, sem conflitos e deve ser plausvel de ser implementado. Lista de verificao Existem listas de riscos j prontas para projetos de testes, cujo conted o nao 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 poderao ser acrescentadas s mostradas anteriormen te 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 fo rmas de fazer esta anlise respondendo as perguntas listadas adiante. O risco relevante para as atividades de teste? Este risco est na alcada de responsabilidades da equipe de testes? O risco previsvel porm nao 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 anterio rmente apresentadas e tambm recebeu sim para a seguinte pergunta:

9 O risco nao est sendo tratado pelo plano de gerncia do projeto de software? Os riscos devem ser identificados e listados numa tabela com o seguinte contedo bs ico: Risco Tipo de risco Probabilidade Impacto ou criticidade Classificacao ou pontuacao probabilidade x impacto Data de revisao do risco Responsabilidade Plano de mitigacao Plano de monitoramento Plano de contingncia Probabilidade A sugestao que sejam utilizados valores entre 10% e 90% e que os incrementos sej

am em mltiplos de 10. Lembre-se que 0% nao precisa ser tratado, visto que o risco nao vai ocorrer, e que 100% uma certeza de ocorrncia, logo nao um risco e sim um pro blema. Criticidade A sugestao 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 entr e 0,1 e 4,5. A tabela deve entao ser ordenada pelos valores da pontuacao. O gerente do p rojeto de testes deve entao reservar pelo menos os dez maiores riscos para que s ejam tratados. Pode ser que em projetos muito grandes existam muitos riscos com pontuacao alta e que nao devem ser descartados. Na verdade, o bom senso aconsel ha a que os riscos considerados altos, 4 a 4,5, por exemplo, devem ser sempre mo nitorados. 5.3. Planejamento dos riscos Escolha os riscos mais relevantes usando o critrio de pontuacao anteriormente mos trado. Os riscos mais relevantes podem ser os dez maiores, ou seja, aqueles que receberam a pontuacao mais alta. Podem ser tambm todos que receberam a pontuacao alta, caso exista um nmero significante de riscos com esta pontuacao. A organiz acao ou o gerente do projeto pode escolher os riscos segundo o seu bom senso ob servando sempre a tabela de anlise de riscos. Nao existe uma regra fechada para a escolha dos riscos que serao monitorados.

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

Plano de mitigao O plano de mitigacao serve para que o gerente possa tentar diminuir o impacto do risco ou at mesmo evitar a sua ocorrncia. Atravs da mitigacao vamos preparar um caminho para reduzir o impacto do risco den tro do projeto de testes. Desta forma procuraremos evitar que o risco se transforme num problema, embora possa vir a causar prejuzos limitados. A definicao anterior foi apresentada anteriormente neste artigo.

Devido a <falta de documentao dos casos de uso>, os <casos de teste foram preparad os inadequadamente ou incompletos> o que poder <produzir testes mal feitos causan do o surgimento d defeitos posteriores no ambiente de produo>. O risco que repetimos anteriormente tambm j foi apresentado como exemplo neste art igo. Neste caso qual seria o plano para mitigacao desse risco? Certamente este s er um risco de alta criticidade e pelo visto a sua probabilidade de ocorrncia tambm alta (suposicao). O plano de mitigacao deve ser a promocao de reunies de revisao e inspecao na documentacao dos casos de uso de forma a melhor ar 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 mitigacao para ver se vale a pena lev-lo adiante ou se sai mais barato correr o risco. Plano de monitorao ou rastreamento Monitoracao Os riscos identificados precisam ser monitorados para que possam os 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 aciona do. Uma das formas de monitorarmos um risco comecarmos analisando os sintomas. No ca so do nosso exemplo o sintoma seria dado pela dificuldade na elaboracao dos caso s de testes. O plano deve indicar um responsvel por esta tarefa e deve tambm estab elecer datas para que isso seja feito. Normalmente as datas deverao ser definida s 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 mitigacao est pro duzindo resultados satisfatrios. Plano de contingncia O Plano de Contingncia ser sempre acionado quando o risco se transforma r num problema. Neste caso nao existe mais a chance de evitarmos o risco e estamos fre nte a um problema. No caso do nosso exemplo, os casos de teste estao sendo elabo rados insatisfatoriamente porque os casos de uso nao estao suficientemente docum entados. Possivelmente um plano de contingncia seria a contratacao de um tcnico pa ra em carter de urgncia fazer este trabalho, pois pode ser que os desenvolvedores nao tenham tempo disponvel para fazer isso, ou at mesmo, nao tenham o perfil adequ ado para este trabalho. 5.4. Rastreamento e controle A gerncia de riscos um processo constante e contnuo. Os riscos podem mudar no temp o, 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 d e Mitigacao deve ser mantido atualizado e tambm o Plano de Monitoramento ou Rastr

eamento dos Riscos. 6 Concluso A atividade de Anlise de Riscos existe para que os gerentes de projet os possam se precaver quanto a futuros problemas. Um risco um sinal de que poderemos ter um problema no futuro, caso nenhuma medida de precaucao s eja tomada. Os riscos podem prejudicar o sucesso de um projeto, caso nao tenham planos de mitigacao e de contingncia, e, conseqentemente, precisam ser monitorados . Gerenciar riscos significa, identific-los, analis-los, planej-los e monitor-los. Uma outra questao importante lembrar que o risco pode ser gerenciado dentro de u m projeto, como estabelecido pelo PMI, ou num processo, conforme definido pelo C MMI 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 Altabo oks, 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. Gestao de Projetos. Editora Campus.2000.

12