Gerenciamento de Riscos voltado para Teste de Software

A 33ª Mesa Redonda DFTestes foi sobre “Gerenciamento de Riscos voltado para Teste de Software”. A discussão teve 3 respostas e 3 participantes, sendo eles: eu, Ana Paula Gomes e Sarah Pimentel.

Embora tenha tido poucas respostas, a mesa redonda gerou um bom conteúdo. Confira ele nos próximos parágrafos.

Devemos gerenciar os riscos de teste separados do desenvolvimento?

A Ana Paula respondeu a pergunta, contando um pouco da sua experiência:

O gerenciamento de riscos deve ser feito em conjunto com o planejamento estratégico da empresa, e principalmente com o desenvolvimento. A depender da demanda dos setores relacionados ao setor de Qualidade, todo o planejamento interno pode mudar.

Um exemplo desta situação, onde trabalho, é a obrigatoriedade do PAF-ECF na Bahia. Nós, do setor de Qualidade, cuidamos da homologação. Porém o desenvolvimento precisa estar atento aos prazos e aos novos requisitos inseridos pela secretaria da fazenda. Sem um planejamento conjunto, os riscos serão maiores.

Na minha opinião, depende do contexto. Se a equipe de teste é separada da de desenvolvimento, é bem provável que sim. Mas mesmo assim, haverá riscos inerentes as duas áreas, e que portanto deverão ser tratados por ambas as áreas.

Agora riscos relacionados exclusivamente com a área de Teste, podem muito bem se tratados separadamente, pelo responsável/gerente pela equipe.

Quais são os riscos mais frequentes em teste de software?

A Ana Paula citou três riscos mais frequentes:

– Implementações que geram outros erros (muito frequente quando não tem-se uma documentação bem estruturada ou uma matriz de rastreabilidade de requisitos);

– Pouco investimento em testes e qualidade e, consequentemente, falta de profissionais qualificados (falo isso pela situação na Bahia! 🙂 Aqui poucas empresas investem.)

– Prazos apertados.

A Ana Paula tocou em três riscos que acredito que são os mais comuns:

1. Qualidade dos builds/versões;
2. Falta de profissionais qualificados;
3. Atrasos.

O primeiro é um risco bem enjoado pra se gerenciar, pois ele é externo a equipe de Teste de Software, principalmente, quando essa se encontra separada da equipe de Desenvolvimento. Portanto, o que devemos fazer é propor ações para mitigar esse risco, como por exemplo:

• Realização de testes unitários e integrados pelos desenvolvedores;
• Implementar integração contínua;
• Estabelecer uma métrica para que a versão/build seja considerado testável pela equipe de Testes, por exemplo, passar em 90% dos testes unitários e integrados;
• Promover treinamentos aos desenvolvedores, tanto em relação a linguagem e boas práticas, quanto sobre o domínio de negócio do software.

Já o segundo podemos ter as seguintes ações:

• Desenvolver talentos internamente;
• Ter uma certificação/treinamento interna para balizar os conhecimentos dos profissionais;
• Terceirizar os testes.

E o último, que é um dos riscos que mais tira o sono do pessoal (literalmente rs). Podemos:

• Entregar/apresentar o software em intervalos mais curtos;
• Revisar as estimativas a cada ciclo de desenvolvimento;
• Monitorar o tempo gasto com as atividades;
• Identificar possíveis gargalos e impedimentos que possam ocorrer (por exemplo, a máquina de integração contínua está muito lenta – trocar para uma máquina melhor);
• Priorizar as atividades e buscar entregar o que agrega mais valor ao cliente primeiro.

A Sarah levantou uma ideia bem interessante, e que faz todo sentido para ser armazenado numa “base de conhecimento”, além de explicar alguns riscos, baseada em duas últimas experiências:

Cada projeto é um projeto, mas não sei se vocês têm a mesma impressão que eu, mas parece que tem riscos que podiam vir junto com o template do documento que registra/acompanha os riscos 🙂

Algumas das ultimas experiências que eu tive:

– Projeto de consultoria: Quality Assessment

Equipe de testes 90% terceirizada no modelo fábrica.

Por que é um risco: Porque a empresa se envolvia muito pouco no ‘modus operandis’ do terceiro e problemas que encontrássemos que tivesse raiz na fábrica tinha pouca probabilidade de ser resolvido. Além disso, tínhamos acesso restrito às informações sobre esse ‘modus operandis’ e o terceiro tinha todo direito de não nos atender.
Impacto: Altíssimo
Probabilidade: Alta
Ações previstas: Reuniões entre os lideres da empresa e do terceiro para explicar a nossa forma de trabalho, explicando que não se trata de uma auditoria de contrato e que as respostas seriam confidenciais e a própria empresa contratante não teria acesso a essas respostas diretamente.

Equipe de testes interna com auto estima muito elevada

Por que é um risco: Estranho não? Mas é que é complicado tu dizeres pra uma pessoa que o que ela acha que ela faz melhor que a grande maioria não é bem assim.

Impacto: Altíssimo. Se não quiserem nos ouvir, o projeto não gera nenhum resultado.
Probabilidade: Média. Não era possível aferir mais que isso porque ainda não conhecíamos a maturidade da equipe.
Ações previstas: Reuniões intermediárias de apresentações de findings para “preparar o espírito” para o relatório final.

Bom, esses eram os tops em minha opinião. Mas claro, sempre existem vários outros como confiança e conseqüente cooperação das áreas correlatas no trabalho realizado (um trabalho de quality assessment não pode contar somente com a equipe de testes como entrevistado e colaborador, precisa ser um trabalho holístico); previsão de orçamento interno para implantar as melhorias sugeridas; entre outros.

Esses trabalhos de consultoria são bem legais (eu gosto pelo menos rs), tem que ter conhecimentos diversos na área de TI pra meter o bedelho na área de todo mundo, mas principalmente tem que desenvolver bem um trabalho psicológico para não ferir os brios de ninguém, inspirar confiança e influenciar pessoas de modo a convencê-las dos ganhos que as mudanças podem trazer.

Já num outro projeto de delivery, eu entro em todos os pontos que o Fabrício e a Ana falaram, e ainda acrescento alguns complicadores como:

– A equipe de desenvolvimento já havia comunicado que não iria fazer testes unitários
– A data do projeto é uma daquelas datas previstas por astrólogos e negociadas com os deuses do Olímpio e se tu não cumprires vai ter toda uma vida de má sorte 😛
– Um dos momentos mais emocionantes foi descobrir que não tinha tempo de re-trabalho previsto no cronograma.

Enfim. A gente tá sempre fazendo malabarismos na nossa área. Impressionante. Um bom gerenciamento de riscos permite NO MÍNIMO manter os olhos de todos abertos para todos os “problemas inevitáveis que estão por vir”, e com um pouco de sorte, conseguir impedir que alguns deles cheguem a afetar o projeto.

A propósito, outra experiência interessante desse ano foi ouvir: “Estou cansado de ouvir as pessoas falando nas reuniões de projeto sobre risco de não entrega de infra-estrutura. Está marcada para o dia 30/10. Atrasou? Não. Então não é um risco!”. É muito importante que antes de entrar numa reunião sobre riscos, os participantes tenham idéia de O QUE É um risco. Ajuda a acalmar os ânimos rs.

Além dos já citados, eu acrescento:

• Não ter um ambiente de teste próximo do de produção;
• Falta de expertise em determinada ferramenta;
• Ausência de ferramentas para determinado teste;
• Dificuldades em manter os testes automatizados;
• etc.

Esse foi o resumo da 33ª Mesa Redonda DFTestes, se você quiser saber como foram as outras mesas redondas, confira os outros resumos.

Fique por dentro das novidades, assine o feed do QualidadeBR.

Risk-based testing (RBT)

A 22ª Mesa Redonda DFTestes teve como tema “Risk-based testing (RBT)”. A discussão teve 3 respostas e participantes, sendo eles:  eu, Aderson Bastos e Robson Agapito.

A seguir, coloco a discussão na íntegra. 😉

Por que usar RBT?

O Aderson Bastos conseguiu responder a pergunta em uma frase:

No risk, no test… (Martin Pol) rs

Na minha opinião, RBT é uma abordagem muito útil para as equipes de teste e que pode ajudar na eficiência dos testes. Afinal, não podemos testar tudo, mas podemos testar o que tem maior risco de falhas.

É possível usar RBT sem ter um gerenciamento de riscos?

Segundo o Aderson Bastos:

Não, pois os riscos mudam e a ingerência destes comprometerá os testes.

Eu acredito que é possível sim, pois a própria equipe de testes poderá discutir quais áreas/funcionalidades da aplicações há maior risco. E é importante lembrar que umas das pessoas mais gabaritadas para realizar uma análise de risco é uma pessoa de teste. 🙂

Porém, acredito que o ideal seria que a análise de riscos seja feita junto com o planejamento da sprint/ciclo/projeto e que todos ou os cabeças chaves das equipes possam participar, pois assim, a análise poderá ser feita de forma melhor e todos estarão cientes dos riscos do produto.

Como devemos direcionar os testes usando RBT?

O Aderson Bastos lembrou muito bem da ISO 9126-1:

A ISO/IEC 9126-1 é uma ótima referência neste direcionamento.

Eu vejo que a ideia por trás do RBT é você testar a área que mais dói, portanto e lá que você concentrar os seus esforços iniciais, seja ela, uma funcionalidade com um algoritmo por trás, onde ouve mais mudanças, etc.

E uma vez identificada tal área, é sempre bom lembrar de Pareto, e então tentar descobri o mais cedo possível as falhas, seja usando automação, alocando o testador mais experiente, etc.

Quando utilizamos RBT precisamos focar onde o risco é maior, por isso da necessidade de fazer uma boa análise de riscos, pois senão, você poderá estressar uma área que não era tão importante assim.

Como foram as suas experiências com RBT?

O Aderson Bastos compartilhou as suas experiências dizendo:

É muito difícil usar RBT sem os riscos identificados e gerenciados! rs

Das poucas vezes que me deparei com cenário propício, a abordagem se mostrou bastante eficaz.

O Robson Agapito relatou uma pouco da sua experiência dizendo:

Aqui utilizamos algo parecido com a análise de risco… criamos um processo que não é uma análise de risco completa, mas adaptado ao nosso processo.

Todo requisito que vem para teste classificamos de duas maneiras, o impacto e a probabilidade. Mas falar somente impacto e probabilidade parece muito vago então focamos mais para a equipe de testes o que seria cada uma destas características.

O impacto não muda muito, seria o impacto da funcionalidade do requisito para o negócio que é visualizado para o cliente.

Já a probabilidade, contamos com a probabilidade desta funcionalidade conter defeitos (o risco de se identificar o defeito. Isso é algo específico aqui, pois temos Analistas de Testes experientes com relação ao sistema, isto é, conhecem muito sobre o negócio e o sistema que estão trabalhando. Então fica mais fácil de se identificar os pontos mais críticos para se ter um defeito. Mas nada que uma reunião com os analistas e desenvolvedores não nos faça identificar tal situação.

Com estas duas características identificadas, conseguimos definir a ordem dos testes.

Então temos a probabilidade e o impacto podendo ser classificado como :

1         – Muito Baixo

2         – Baixo

3         – Médio

4         – Alto

5         – Muito Alto

E utilizamos a seguinte ordem para os testes, sempre realizar os testes primeiramente dos requisitos com maior impacto, e para desempate utilizar a probabilidade de se identificar defeito começando pelo Muito Alto e indo até o Muito Baixo nas duas situações.

Com isso conseguimos priorizar, quando necessário, os testes a serem realizados primeiro.

É uma maneira simples e bem parecida (apenas uma pequena parte) da análise de risco.

As minhas foram muito boas! Como disse no começo, era é uma abordagem muito útil e ser usada com outras técnicas, como por exemplo, Teste Exploratório, pode garantir uma boa e eficiente cobertura de teste.

E ela pode direcionar tanto a execução dos testes como as outras atividades, e desta forma, podemos encontrar as falhas de forma mais rápida.

E o interessante do Teste Baseado em Riscos, é que ele pode trazer bons resultados independente da metodologia do projeto. E a sua aplicação faz o teste ser mais inteligente, principalmente pelo fato de estarmos testando com foco e sabendo o porquê.

Saiba Mais

Uma leitura recomendada sobre o assunto, é esse post da Sarah Pimentel.

Bem pessoal é isso. Continuem de olho na lista do DFTestes, pois sempre há assuntos bem interessantes lá, e poderão haver novas respostas nessa mesa redonda.

Fique por dentro das novidades, assine o feed do QualidadeBR.

Riscos!? Que riscos?

Riscos é um assunto que deixa muitos incomodados, afinal muitas vezes, principalmente em projetos de software, ele é visto como algo negativo, um empecilho que pode ocorrer e diminuir as chances de sucesso do projeto.

E o perigo maior está quando não identificamos o risco, e o impacto dele pode comprometer todo o projeto. Fazendo uma analogia, seria como você descobrir que o botijão de gás está vazando ao ligar a lâmpada, ou seja, tarde demais… BOOMM!!!

Assustador não é?

Por isso, o gerenciamento de riscos é algo muito importante no seu projeto. A seguir, irei falar um pouco sobre ele, espero que gostem e que possa ser útil. 🙂

De onde vem os riscos?

no Futuro … que pode ser duvidoso e nos forçar a mudanças…

nas Mudanças … que podem ser inúmeras e nos forçam a decisões…

nas Decisões … que podem não ser as mais corretas…

• Do futuro: que pode ser duvidoso e nos forçar a mudanças;
• Das mudanças: que podem ser inúmeras e nos forçam a decisões;
• Das decisões: que podem não ser as mais corretas.

Riscos em Engenharia de Software

• Do futuro: do ambiente interno e externo, mercado, tecnologia, economia, governo, etc;
• Das mudanças: do ambiente, dos requisitos dos clientes, em ambientes tecnológicos, equipamentos, política econômica e tecnológica, leis e programas de apoio a P&D, orçamentos., etc;
• Das decisões: O que produzir? Com que métodos e ferramentas? Com que equipe? Com que nível de qualidade? Com qual orçamento? etc.

O processo de gerenciamento de riscos

Sendo o gerenciamento de riscos um conjunto de técnicas e ferramentas para identificar, estimar, avaliar, monitorar e administrar os acontecimentos que colocam em risco a execução do projeto. Podemos ilustrar o processo de gerenciamento de riscos, proposto pelo PMBOK, da seguinte maneira:

• Planejamento do gerenciamento de riscos – decisão de como abordar, planejar e executar as atividades de gerenciamento de riscos de um projeto;
• Identificação de riscos – determinação dos riscos que podem afetar o projeto e documentação de suas características;
• Análise qualitativa de riscos – priorização  dos riscos para análise ou  ação adicional subsequente  através de avaliação  e combinação de sua probabilidade de ocorrência e impacto;
• Análise quantitativa de riscos – análise numérica do efeito dos riscos identificados nos objetivos gerais do projeto;
• Planejamento de respostas a riscos – desenvolvimento de opções e ações para aumentar as oportunidades e reduzir as ameaças aos objetivos do projeto;
• Monitoramento e controle de riscos – acompanhamento dos riscos identificados, monitoramento dos riscos residuais, identificação dos novos riscos, execução de planos de respostas  a riscos  e avaliação  da sua eficácia durante todo o ciclo de vida do projeto.

Ao meu entender, as quatro primeiras etapas compõem a análise de riscos, que é algo de extrema importância para qualquer projeto, independente da sua natureza.

E para o nosso mundo de desenvolvimento de software a análise de riscos é essencial, pois o nosso projeto está sempre rondado de riscos, e precisamos estar atentos a eles.

É importante lembrar que o objetivo do gerenciamento de riscos é aumentar a probabilidade e o impacto dos eventos positivos e diminuir a probabilidade e o impacto dos eventos adversos ao projeto.

Tem como garantir que nenhum risco irá afetar o meu projeto?

Não. Infelizmente não tem como garantir que os riscos não irão causar impacto no seu projeto. Mas calma, nem tudo está perdido. Podemos utilizar três estratégias para lidar com os riscos e diminuir a probabilidade deles ocorrerem:

1. Prevenir: como já diz aquele velho e bom ditado popular “prevenir é o melhor remédio”, e no gerenciamento dos riscos essa é a melhor ação que podemos executar. Muitas vezes precisamos realizar mudanças no plano do projeto para eliminar a ameaça que um risco pode apresentar. Podemos também isolar os objetivos do projeto do impacto que o risco pode oferecer ou ainda flexibilizar o objetivo que está sendo ameaçado pelo risco;
2. Transferir: essa é uma ação que não elimina o risco, e sim passa o gerenciamento dele para um terceiro. Por exemplo: você irá terceirizar uma determinada parte do seu sistema para outra empresa. Um dos riscos que você terá é do atraso da entrega dessa parte do sistema, e para tentar compensar o impacto que esse risco poderá ter para a sua empresa, você pode colocar no contrato uma multa em caso de atraso;
3. Mitigar: o foco da mitigação de riscos é a redução da probabilidade e/ou impacto de um risco até um limite aceitável. Um exemplo, seria a realização de TDD para diminuir a probabilidade e impacto do risco de falhas do sistema, já que aumentaria a qualidade do desenvolvimento do software.

O que pode acontecer se não houver uma análise dos riscos no meu projeto?

Como diria um professor meu: “coisas horríveis irão acontecer”.

A análise de riscos é fundamental para o gerenciamento de riscos e um fator chave para o sucesso do seu projeto. É uma maneira de agir proativamente diante dos riscos e é muito melhor do que agir de forma reativa, pois talvez dependendo do risco que não foi tratado e do impacto ocasionado por ele, poderá ser muito tarde para tomarmos alguma providência.

A análise de riscos pode ter algum impacto para a minha área de testes?

Sim, e se bem realizada poderá ser um impacto muito benéfico para a equipe de testes. Pois será mais uma fonte de consulta na hora da elaboração dos testes e ainda poderá ajudar na priorização da execução dos testes. Por exemplo: na análise de riscos de uma manutenção do software está descrito quais áreas poderão ser afetadas pela manutenção, ou seja, novos bugs poderão ser introduzidos nessas áreas. Sendo assim poderemos focar os testes de regressão primeiro nas áreas que tem maior chance de ter sido impactada e desta maneira, podemos encontrar a falha mais cedo = menos $$$ gasto com o bug.

Além do mais, sabemos que garantir que 100% do sistema não tem falhas é algo muito difícil e na maioria das vezes não viável. Portanto com a análise de riscos podemos garantir por exemplo, que 90% das falhas do sistema foram encontradas e que os outros 10% possam ser falhas de baixo impacto no sistema. Já sem uma análise de riscos poderíamos talvez, garantir que 99% das falhas foram encontras, mas daí o 1% que faltou pode ser uma falha crítica. Aí já sabe neh…

Sendo tão importante, por que às vezes a análise de riscos não é realizada?

Pois muitos preferem ficar na segurança e conforto da ignorância. Sabe aquelas pessoas que falam, nem precisa testar está funcionando. Então, uma das razões para essa pessoa falar isso é que ela sabe que se você for testar irá achar um monte de falhas que irá dá mais trabalho para ela.

Com os riscos o cenário é parecido. Se você for fazer uma análise de riscos, com certeza irá encontrar muitos riscos e ainda terá várias outras “razões” para evitar a  análise de riscos:

• Análise de Riscos “consome” tempo precioso dos membros da equipe do Projeto ;
• Análise de Riscos demonstra “ Análise de Riscos demonstra problemas que “só atrapalham”;
• Análise de Riscos tem tendência de “ Análise de Riscos tem tendência de trazer “más notícias”;
• Análise de Riscos pode levar a “ Análise de Riscos pode levar a situações “embaraçosas”;
• Análise de Riscos acelera a necessidade de levantar questões que, cedo ou tarde, deveriam ser percebidas pelo Cliente do Projeto.

Portanto, se você não quer ter nenhuma explosão no seu projeto, por favor, identifique, analise, administre e controle os seus riscos. Caso contrário, você um dia poderá ter uma surpresa desagradável ao chegar ao trabalho.

Fique por dentro das novidades, assine o feed do QualidadeBR.

Fonte:

Um Guia do Conjunto de Conhecimentos em Gerenciamento de Projetos (Guia PMBOK); Terceira edição, 2004. Project Management Institute, Four Compus Boulevard, Newton Square, PA 19073-3299 EUA.

www.inf.ufsc.br/~cybis/ine5617/Analise_riscos.ppt (Walter de Abreu Cybis)

www.pmimg.org.br/…/GestaoRiscosProjetos_LucioDiniz_31082004. (Lúcio J. Diniz)

Quando os testes devem parar?

Essa é uma das perguntas mais difíceis de ser respondida quando estamos testando um software. Se formos perguntar para um gerente de teste, ele provavelmente vai responder que os testes deverão parar quando o prazo para eles se esgotar. Porém, nem sempre esse é momento certo para encerrar a etapa de testes, pois os testes podem ter sido interrompidos muito antes do tempo necessário para a sua completa cobertura.

Uma das maneiras de saber quando devemos dá por encerrado a etapa de testes é verificar os seguintes pontos:

• O número de bugs achados que estão fechados é maior do que o número de bugs que se esperava achar;
• Todos os testes foram executados;
• A porcentagem de cobertura da aplicação pelos testes já é o suficiente;
• Todas as funcionalidades funcionam corretamente;
• O software tornou-se confiável;
• A estabilidade alcançada atingiu o esperado;
• O sistema atende as métricas de confiabilidade, disponibilidade e durabilidade definidas no Plano de Teste;
• O número e severidade dos bugs caíram a um nível satisfatório;
• O tempo médio entre defeitos encontrados é muito alto.

Logicamente, trabalharmos sempre buscando 100% do software, mas para que isso seja possível, geralmente, o prazo para os testes deverá ser muito alto, o que em muitos projetos é inviável. Assim sendo, uma outra maneira de saber o momento de finalizar os testes é avaliar os riscos envolvidos com a liberação da aplicação para a produção, comparando tais riscos com os da não-liberação. Pois, podemos chegar num momento em que o custo das falhas que possam vir a ocorrer no ambiente de produção não compensa o gasto adicional de dinheiro para tentar evitá-las.

Fique por dentro das novidades, assine o feed do QualidadeBR.

Fonte:

Bastos, A.; Rios, E.; Cristalli, R. & Moreira, T. Base de conhecimento em teste de software. São Paulo, Martins Fontes, 2007.

Farrell-Vinay, P. Manage Software Testing. New York, Auerbach Publications, 2008.