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.

Especializações interessantes para os profissionais da área de teste de software

A 32ª Mesa Redonda foi sobre “Especializações interessantes para os profissionais da área de teste de software” e teve apenas 2 respostas e 3 participantes, sendo eles: eu, Elias Nogueira e Lidiane Santos.

Como a discussão foi curta, abaixo segue praticamente a íntegra das contribuições feitas pelo Elias e pela Lidiane e também alguns comentários meus.

O Elias abordou vários pontos relevantes, entre eles o insight de que uma especialização na área de Teste de Software, não precisa ser necessariamente na área. Pode parecer estranho, mas é verdade:

Acredito que a especialização em si na Área de Teste não é apenas sobre a área (ex: uma pós em Gestão de Qualidade ou Teste de Software), e sim mais sobre o negócio onde trabalhamos (SOA, Sistemas Distribuidos, Mobile, etc…)

Claro que esse meu pensamento é um pouco puxado para o lado técnico. 😛

Sempre acreditei que o profissional em teste é um dos mais completos, por causa da variedade de conhecimentos que ele precisa ter para desempenhar sua função (óbvio que dependendo do papel/nível do mesmo). Logo, penso que a carreira de um profissional de teste é cheia de conhecimento “fora-teste” (análise de requisitos, programação, etc..)

Hoje, dentro da área acadêmica (Especialização, Pós, MBA) eu vejo quase que 100% formações de líderes, analistas de qualidade ou correlatos. É muito difícil encontrar algum curso acadêmico mais técnico em teste, ou que pelo menos ensine técnicas de teste, algumas ferramentas, etc…

Vejo que o profissional, se deseja algo mais técnico, tem que recorrer a uma destas áreas acadêmicas fora de teste ou recorrer a um mestrado para desenvolver algo diferente. É um ponto que as universidades estão amadurecendo, mas muito lentamente (se pensarmos o número de matérias de programação x número de matérias sobre qualidade e teste de software)

Eu fiz uma Pós em Teste de Software (onde vi toda a área de validação) na Unieuro, e recomendo. Apesar de eu já ter o conhecimento do que eu tive na pós, eu a procurei alguns motivos: ter outras visões do mesmo assunto e ter uma certa comprovação acadêmica. Hoje já recorro a cursos dentro da minha área de especialização que mais me interessam.

A minha dica é que na hora da escolha de uma especialização na área, em termos acadêmicos, que o profissional saiba qual linha ele quer/vai seguir, pois para a linha técnica não existe muita coisa.

Aproveito pra listar aqui algumas instituções acadêmicas ao redor do Brasil que possuem cursos voltados para a área de Teste e Qualidade de Software (sugestão de ficar como um thread separada depois)

– Unieuro (Brasília/DF) – MBA em Teste de Software (Pós Graduação) [não existe mais]

– Feevale (Novo Hamburgo/RS) – Teste e Garantia da Qualidade de Software (Pós Graduação)

– Unisinos (São Leopoldo/RS) – Qualidade de Processos de Software (Tecnológico)

– FIAP (São Paulo/SP) – MBA em Gestão da Qualidade em Software com ênfase em CMMi e MPS.BR (Pós Graduação) [não existe mais]

– SENAC (São Paulo/SP) – Gestão da Qualidade de Software (Pós Graduação)

 

 

 

– UNICAMP – Especialização em Engenharia de Software

A Lidiane contou um pouco da sua experiência e lembrou que participar de eventos é uma forma de buscar se especializar e também de compreender melhor a área e a sua amplitude:

Realmente esse tema é muito importante e legal. Vejo muitas pessoas que estão na área de teste que não sabem que os profissionais dessa área podem ter uma carreira.

Em relação a especializações, existem muitos cursos legais de ferramentas, automação de testes, implementador MPT.BR, TMM. Vejo que há bastante cursos online e/ou semi-presencias, mas não são muito divulgados

Pós-Graduação, eu vejo que é muito interessante na area de Engenharia de Software, Qualidade de Software, é muito importante analisar a grade, pois tem algumas pós que não abordam muito o tema Teste SW.

Na Poli tem alguns cursos bem legais de especialização e extensão vejam no site www.pecepoli.com.br , temos a Iterasys com os cursos preparatórios para certificações, mesmo que vc não faça a prova, o curso acaba sendo muito legal e você consegue praticar algumas coisas no dia-a-dia.

Eu atualmente tento frequentar os eventos de teste como o Brateste, Conferencias – inclusive fui no TDC 2010 realizado em Agosto, WorkShops, estou sempre antenada nas novidades e visitando blogs relacioandos a Qualidade e Teste SW.

Por fim, termino agora em novembro o MBA em Teste de Software pela Unieuro, o curso é bom tirando algumas falhas da instuição em relação ao atendimento ADM e Financeiro… *rs

Eu achei super válidas as contribuições do Elias e da Lidiane, e retratam bem as formas que podemos nos especializar na área de Teste de Software.

Na minha opinião, a especialização hoje é encarada pelos profissionais, basicamente de duas formas:

• O profissional gosta da área e quer se aprofundar melhor nela, ou está buscando cobrir lacunas da graduação e conhecer outras áreas (ex.: ao fazer uma pós em Engenharia de Software);
• A outra forma, são os profissionais que estão buscando status e aumento. Afinal, é bunitinho falar que é pós-graduado e para algumas empresas, o título mostra que o profissional é mais qualificado que outro que não possui uma pós. Essa abordagem é perigosa, porque você pode acabar fazendo um curso que não gosta ou que o seu perfil não encaixea Além do que, essa visão de que ser pós-graduado é igual ser melhor do que os que não são, é uma visão alienada.

Eu particularmente, prefiro uma pós-graduação fora da área de Teste de Software, para quem está na área de Teste de Software. Caso o seu perfil seja mais gerencial, busque uma pós de gestão ou um MBA, agora caso o seu perfil seja mais técnico, busque então uma pós em Engenharia de Software.

Escolha bem o curso e não vá na “hype”, afinal uma pós-graduação, geralmente exige um investimento financeiro grande. Faça a sua escolha com bastante parcimônia. 😉

E lembrem-se: nem sempre se especializar, significa se matrícular num curso de pós-graduação, hoje em dia há outras opções.

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

É possível realizar documentação de testes quando trabalhamos com metodologias ágeis? Digo, desde o plano de teste até o caso de teste, isso é possível?

Após um bom tempo sem fazer os resumos das excelentes mesas redondas virtuais, que ocorrem no grupo de discussão DFTestes. Nos próximo parágrafos, segue o resumo da 31ª Mesa Redonda DFTestes (sim, a minha intenção e fazer o resumo de todas que ocorreram no período em que parei de fazer os resumos).

Essa mesa redonda teve 7 respostas e 7 participantes, sendo eles: eu, Lidiane Santos, Shmuel Gershon, Felipe Silva, Fermiano de Queiroz, Sarah Pimentel e Ueslei Silva.

É possível realizar documentação de testes quando trabalhamos com metodologias ágeis? Digo, desde o plano de teste até o caso de teste, isso é possível?

A Lidiane deu a sua contribuição dizendo:

É possível sim, fazer documentação em um proceso ágil, mesmo porque você começa desenvolvendo em cima dos cenarios de testes que foram levantados.

E eu já trabalhei muito em empresas que não utilizam o processo agil, mas já testei muito software sem documentação, indo apenas pela intuição e conforme vou testando vou documentando os testes.

Acho que essa associação de Teste de Software = Documentação e Burocrácia é coisa do passado.

Para o Shmuel, você pode tanto documentar, como não documentar, quando está trabalhando com metodologias ágeis:

É possivel realizar documentacao de testes quando trabalhamos com metodologias ágeis.

E também, é possível não realizar documentação de testes quando trabalhamos sem metodologias ágeis. Surpresa!

O Fermiano contou um pouco da sua experiência atual:

Sei que existem testadores que usam deste argumento, mas também vejo testadores fazendo o contrário. Felizmente, aqui a maioria encara os desafios da função e assume os riscos, sedentos por um teste exploratório. Documentação também depende do processo utilizado, precisamos seguir os planos de testes para garantir o sucesso obtido em projetos anteriores. Em nosso processo temos uma variedade de testes, com base em planos de teste e, também, exploratórios, em várias etapas. Toda a documentação “necessária” para os testes é gerada durante essas etapas, de acordo com cada etapa do processo.

A Sarah tocou num ponto bem importante, o de que as metodologias ágeis muitas vezes não são utilizadas corretamente, e passam a ser apenas para mascarar que não está sendo utilizado nenhuma metodologia:

Pois é.. Uma questão é que muitas vezes quando alguém me diz “nesse projeto vamos usar metodologias ágeis” me dá um frio na espinha e eu já saio correndo pra mesa do SQA dizendo pra ele fazer alguma coisa, porque em muitos casos eu sei que ‘usar metodologia ágil’ é uma desculpa pra não usar metodologia alguma. A metodologia passa a ser: precisamos entregar para o cliente um monte de pedaços de sistemas e fazer várias entregas e rápidas.

Completamente deturpado. Não existe envolvimento próximo do cliente, não tem ninguém capacitado na equipe para conduzir o time nas práticas da metodologia escolhida, a equipe é formada por um grande numero de profissionais juniors, ou seja: tem tudo pra ser um desastre.

Não tô dizendo que NINGUÉM sabe fazer projeto ágil, por favor. Tô dizendo que HÁ CASOS, em que ‘metodologia ágil’ é desculpa para não usar metodologia alguma. Se não tiver um responsável fazendo às vezes de SQA (no sentido de orientar a equipe e até mesmo intervir na escolha da metodologia) o negócio desanda feio.

Então metodologia ágil pode ou não ter o teste documentado, dependendo da necessidade do projeto.

Se para testar é necessário ter uma vasta documentação, já discutimos isso antes. A minha opinião é: não.

O Ueslei compartilhou um pouco da sua experiência:

Depende!

Atualmente estou alocado em uma empresa que usa desenvolvimento ágil. Junto com o Desensolvimento, estão 3 pessoas encarregadas pelos testes.

As histórias de usuário criadas pelo desenvolvedor, são levantadas com base nas especificações que são realizadas por uma área específica.

A equipe de teste, utilizam tais especificações para realização da primeira bateria de testes.

Mas, isso não é tudo. Temos também uma outra equipe de testes, com perfil de homologação/aceitação, mas que explora os sistemas com maior granularidade do que os conhecidos testes de aceitação.

Esta equipe, é formada por 10 colaboradores. Esta equipe, também com base nas especificações, geram documentos de casos de teste e automação de teste.

Bom! no nosso ambiente, além de ágil, temos outros processos que suportam as necessidades e geram artefatos. Mas, mesmo que uma organização use ágil puro, ainda sim, seria interessante usar documentos, mesmo que simples. Por exemplo, mapas do que é interessante ser testado. Assim, o conhecimento não fica tácito nem corre-se o risco de algo importante cair no esquecimento.

Eu acredito que sim. Porém, pensando em uma equipe que é realmente ágil ou pelo menos busca respeitar os princípios ágeis, talvez não seja necessário realizar um plano de teste. Copiando e colando um exemplo que dei num comentário no blog As Especialistas, relacionado ao assunto:

De acordo com o contexto, podemos até não utilizar o Plano de Teste, mas isso não significa que estaremos pulando a fase de planejamento (que é essencial), mas sim que podemos utilizar outras formas de fazer o planejamento.

Para ilustrar o que quero dizer, vamos pensar numa equipe de Teste de Software com 3 pessoas, que testam um sistema que é desenvolvido em ciclos de 2 semanas. A cada ciclo de desenvolvimento novas funcionalidades são adicionadas e também bugs são resolvidos.

Para esta equipe, o planejamento do Teste de Software pode ser iniciado na própria reunião de planejamento do ciclo de desenvolvimento, da qual já podem sair, por exemplo, com as funcionalidades que serão testadas, o que não será testado, ambientes que serão usados e os prazos.

Depois os três podem fazer uma reunião entre eles para detalhar melhor o planejamento de teste. Deste detalhamento podem sair com vários post-its para serem colocados num quadro ou com um checklist num Google Docs, por exemplo.

O que ocorre é que “o Método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de desenvolvimento, é através de uma conversa cara a cara”, portanto toda documentação que você faria apenas com o objetivo de comunicar algo a alguém será provavelmente, descartada.

Por que raios, quando se fala em Teste de Software, as pessoas logo lembram de documentação, e não de testes em si? Por que os profissionais de Teste de Software ainda são tão dependentes de documentação?

Segundo o Shmuel:

Um dos motivos da ligação Teste de Software –> Documentação é esse mesmo, os testadores passarem o tempo tentando provar que da pra documentar, e tentando gerar documentação suficiente pra se proteger atrás dela. Quem nunca ouviu um testador falando: “Testei o que está nos requerimentos”, “esse bug eu perdi, porque não esta no plano de testes”, “Já terminamos os testes: 100% do plano de testes”… ? Acho que essa associação é culpa nossa, mais do que culpa deles.

O Felipe Silva comentou a resposta do Shmuel dizendo:

Que jogue a primeira pedra aquele que nunca se protegeu atrás de documentação.

Na minha opinião, a documentação acaba sendo uma forma da gente se defender. E além disso, muitos profissionais foram influenciados por processos que tem em sua saída a produção de artefatos. Então, acabamos utilizando a documentação até mesmo em ocasiões onde ela não é necessário (ex.: comunicação).

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

Microsoft adquire o TestLink

O TestLink é uma das ferramentas mais usadas pelas equipes de Teste de Software pelo mundo, provavelmente só deve perde para o Excel.

Sabendo disso a Microsoft foi ligeira e contratou a equipe do TestLink. A equipe mantenedora do TestLink passará a trabalhar fulltime em uma nova versão do TestLink, que irá fazer parte do Visual Studio Test Professional.

A nós, resta torcer/participar do projeto, que continuará disponível, uma vez que ele é um projeto open-source. Mas agora dependerá exclusivamente dos esforços da comunidade para se manter.