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.