Na 18º Mesa Redonda DFTestes o tema discutido foi Projetos de Testes. A discussão rendeu, até o momento, 26 respostas e teve 12 participantes, sendo eles: eu, Shmuel Gershon, Rodrigo Almeida de Oliveira, Robson Agapito, Leonardo Molinari, Aderson Bastos, Lorena Lyra, Elias Nogueira, Sarah Pimentel, Ueslei da Silva, Felipe Silva e Eduardo Gomes.
Abaixo, faço um “resumo” de como foi essa mesa redonda, e quem quiser acessar a discussão na íntegra, basta acessar esse link (necessário se inscrever no DFTestes).
Quais são os maiores desafios do gerenciamento de projetos de testes?
De acordo com o Felipe Silva:
Inicialmente os mesmo desafios de qualquer projeto, estimar corretamente, não ultrapassar a estimativa, entregar no prazo, encontrar “todos” os defeitos, não ultrapassar o orçamento planejado, satisfazer todos os stakeholders, manter as pessoas motivadas, aprender com o projeto corrente lições para o próximo projeto, não cair novamente no mesmo erro de um projeto passado, inovar, aumentar os skills do time, gerar e interpretar corretamente as métricas, etc
Como o Felipe disse, os mesmos de qualquer outro projeto. E alguns extras:
- Saber quando parar de testar;
- Lidar com os retestes e negociar eles com a gerência do projeto;
- Contratação de profissionais, o mercado carece de bons profissionais;
- Estabelecer uma boa relação e comunicação com a equipe de desenvolvimento.
Por que podemos encarar os testes como projetos?
O Leonardo Molinari compartilhou a sua visão dizendo:
Na minha visão, “testes são projetos dentro de projetos”. Depende do nível que desejamos analisar e depende de como a organização encara o nivel de célula de um projeto.
Em teste, temos todas as etapas típicas de projeto (não estou me prendendo ao PMI ou a outra definição) que compõe o velho PDCA: plan do check act. Em desenvolvimento apenas abrimos uma outra etapa, mas está lá o velho PDCA. Planejar: até para planejar é preciso inputs (no caso de testes poderiam ser os requisitos ou um conjunto de bugs) p/ poder definir o cronograma e criar os casos de testes. Em “do” poderíamos ter o criacao dos testes. Em check, teríamos a verificão do que foi planejado. Em act teríamos a validacão ou criação de bugs.
Quando as empresas alocam equipes de testes (ex: terceirização), podemos ver mais claramente um projeto de teste.
Quando num projeto típico de desenvolvimento que considera testes como uma fase, teremos que no mínimo fazer o velho PDCA nem que seja para nós mesmos…
O Felipe Silva deu a sua opinião falando:
Porque ajuda na organização e planejamentos de custos e esforços, faz com que se tenha orçamento direcionado “obrigatoriamente” aos testes, cria-se uma vertical que se interligada as horizontais e bem gerenciada facilita na administração, olhar direcionado e valorização da alta gerência a equipe de testes.
Na minha opinião, porque ele pode ser “um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo”. 🙂
Lembrando que também somos responsáveis pelo desenvolvimento do software, não codificando o sistema, mas auxiliando o processo de desenvolvimento.
Quais outras opções existem? No que elas são melhores que “projetos”?
Uma boa questão levantada pelo Shmuel Gershon.
O Rodrigo Almeida respondeu dizendo:
Existe a operação contínua, que faz parte da manutenção corretiva de um software/produto. Não é melhor ou pior do que projetos, mas é diferente.
Eu de bate pronto eu responderia processo e projeto. Cuja definição podemos pegar do PMBOK e do CMM:
Um projeto é um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo. (PMBOK)
Um conjunto de atividades, métodos, práticas e tecnologias que as pessoas utilizam para desenvolver e manter software e produtos relacionados. (CMM)
Lembrando que um projeto pode ter vários processos, dentre os quais podemos ter o processo de Teste de Software.
Agora tentando pensar mais sobre a questão levantada, me lembrei de um tal de modelo cascata, que é pouco conhecido e criticado (rs). Nele os testes são encarados como uma fase.
E os testes também podem ser só mais uma atividade dentro do desenvolvimento, principalmente, quando não temos um processo definido, e os testes são feitos de forma informal, muitas vezes pelo próprio desenvolvedor ou por um estagiário (nada contra estagiários)
O “melhor” irá depender do contexto, exemplos:
- Desenvolvimento de um web site com dois desenvolvedores sêniores e um designer
- Os testes são encarados como uma atividade comum no desenvolvimento do software, os desenvolvedores utilizam BDD, testes unitários e integrados.
- O ERP sofre manutenções frequentes
- Aqui você pode encarar cada manutenção como um projeto, mas também pode encarar tudo como um processo de manutenção do software, principalmente, quando há já um contrato de manutenção acordado com o cliente, agora se houver um contrato de uma nova versão com novas versões e correções de bugs, já podemos encarar os testes como projeto já é melhor, afinal a entrega da versão tem um término, não é algo contínuo, como as manutenções.
- Customização de um web site, exemplo loja virtual
- Neste caso podemos trabalhar de forma incremental ou até cascata, de tivermos tudo bem especificado ou a customização for bem simples e a equipe experiente, e teríamos os testes dentro da fase de teste.
Um ponto interessante que o Eduardo tocou foi que ao lidar com os testes como um projeto, eles passam a não ser deixados como segundo plano, e assim muitas vezes ganhamos com um maior profissionalismo, atenção, disciplina e eficiência nas atividades do Teste de Software.
O Elias Nogueira compartilhou a sua opinião, relacionada a pergunta dizendo:
Quando estamos dentro de uma Fábrica de Testes, temos a necessidade de ter o controle sobre tudo o que acontece. Isso envolve uma série de itens de Gerencia de Projeto ‘tradicional’ (PMI) como controlar o custo do projeto, recursos, cronogramas, etc…
Mesmo em métodos ágeis, estes item são executados e controlados, porém muitos deles sem a visão tradicional (trabalhar sobre um scrumboad é criar em partes o cronograma do projeto).
Agora, na realizada de alguns aqui que testam software COTS, não necessariamente tratamos os testes como um projeto, pois ele já está dentro do projeto do desenvolvimento do produto.
O que vale na minha opinião, é aprender um pouco sobre as metodologias de gerenciamento de projetos e ver qual delas se encaixa melhor a nossa realidade.
Quais dicas você daria para obter sucesso no projeto de teste?
O Felipe Silva acredita que o melhor é investir nas pessoas:
Buscar vencer todos os desafios citados na primeira pergunta, ter uma equipe ou papel de pessoas buscando sempre por novas tecnologias ou soluções, um trabalho FORTE em cima das PESSOAS, incentivando (participar do DFTestes por exemplo), tirando o melhor de cada pessoa (ao invés, de ficar tratando “gaps”), projetos são feitos por pessoas, o sucesso do projeto tem tudo a ver se o recurso trabalha motivo e feliz ou não, aqui na empresa existe até um papel de gerente direcionado somente a manter a “saúde” dos recursos, investir em treinamentos, apoiar realmente, acreditar as pessoas, tratá-las como profissionais dando liberdade (até o nível que máximo que for possível), acho besteira ficar controlando que sites o recurso está acessando, por exemplo, tratar as tarefas como metas, cumpriu a meta é pronto e ponto final, lógica que se destacará quem aproveitar os gaps de tempo para o bem do projeto. Invista nas PESSOAS!
Segue algumas:
- A número 1 é contratar pessoas insubstituíveis. 🙂
- Já como a primeira dica não é nenhum pouco fácil de realizar, foque a contratação nas características pessoais, lembre-se que para atuar na área de Teste de Software a pessoa precisa ter características específicas;
- Capacite as pessoas, principalmente no domínio do sistema que será testado;
- Utilize um processo incremental;
- Tenha ciência das ferramentas que podem auxiliar no seu projeto, e porque utilizar elas;
- Não enxergue apenas o seu próprio umbigo (projeto de teste), considere sempre o projeto como um tudo, tenha uma visão do todo e da importância do seu projeto de teste para o todo;
- Busque a melhoria contínua, distribua e peça feedbacks constantemente.
Até que ponto o gerente do projeto deve influenciar o projeto de teste?
Para o Felipe Silva a resposta dessa pergunta depende muito do cenário de cada projeto:
Até que ponto ele não deve? Difícil responder essas perguntas, primeiro porque cada gerente de projeto tem um poder de influencia e cada gerente tem suas atividades, cada gerente tem um angulo de visão diferenciado, o que estou dizendo é em relação as empresas, já difícil eu responder até que ponto o gerente do “MEU” projeto deve influenciar o projeto de testes, quem dirá responder de modo geral.
Como o Felipe Silva disse, a pergunta é difícil de ser respondida. Eu nunca tive problemas com os gerentes dos projetos, que participei. E acredito que a influência deles deve ser positiva para os testes, e para isso é fundamental eles enxergarem a importância dos testes e terem ciência da dependência existente entre os testes e o sistema sob teste.
Experiências com projetos de testes
O Robson Agapito compartilhou um pouco da sua experiência com projetos de testes, mostrando que lidar com os testes como sendo um projeto pode dá ótimos resultados:
Creio que eu posso ajudar neste quesito, pois levei a sério esta situação de teste como projeto e está dando certo, pelo menos para a minha equipe.
O controle sobre cada atividade está sendo muito bom… nós sabemos o que temos que testar, quanto já testamos, se estamos atrasados ou adiantados, o que entrou no meio do projeto, entre outras coisas.
Hoje temos algumas gerências trabalhadas, seguindo o padrão informado pelo MPS-Br, e que agora está no MPT-Br:
-> Gerência de Escopo
-> Gerência de Custo
-> Gerência de Tempo
-> Gerência de Qualidade
-> Gerência de Recursos Humanos
-> Gerência de Problemas
Estava trabalhando com Gerência de Risco em um excel, mas estava se tornando muito trabalhoso, então parei e assim que automatizar esta situação voltarei a trabalhar.
O que facilita esse trabalho é que a equipe é boa e madura nos processos de testes pré definidos pela célula de testes.
Além de ter um líder especifico e focado na liderança e não um líder que está trabalhando na base, o que faz toda a diferença, pois o planejamento do projeto, o controle e acompanhamento tomam muito tempo, o que se o líder estiver na base testando não conseguirá fazer as duas coisas bem feitas, nem testar e nem coordenar todo o projeto.
Futuramente colocaremos as seguintes gerências:
Gerência de Treinamento
Gerência de Riscos (como já falado)
Além do gráfico BurnDown que já estou trabalhando no mesmo.
Bem, o que posso lhes dizer na prática é que está funcionando, mas porque a empresa segue a metodologia do MPS-Br (o CMMI Nacional).
Claro, os projetos somente valem a pena para nós quando tem a carga horária maior que 50 horas, pois senão vai se levar mais tempo para planejar e acompanhar do que para testar.
O Eduardo Gomes também compartilhou um pouco da sua experiência com projetos de testes e os resultados que podemos obter ao lidar com os testes como sendo um projeto:
Tratar as atividades de teste como um projeto é uma das melhores abordagens para apoiar na internalização da cultura de testes na organização.
Em 2008, exploramos em um TCC do curso de Gestão de Projetos de Software exatamente o tema “Gerência de Projetos de Teste de Software”. Naquela época estávamos ainda estruturando as primeiras equipes independentes de teste no banco e a maturidade e a vivência em testes estava ainda bem no início dentro dessas equipes.
Mas já percebía-se uma grande similaridade entre o gerenciamento das atividades nos projetos de desenvolvimento e das atividades de teste que apoiavam estes projetos.
A resistência ao termo Projeto de Teste, desde o início, sempre foi muito grande, principalmente porque as atividades de testes fazem parte do processo de desenvolvimento. Outro argumento contrário à utilização do termo é que as atividades de teste podem ser continuadas ao longo do ciclo de vida do software, através de testes regressivos e já fora do contexto de um projeto.
Mas quando falamos de um projeto de desenvolvimento, não temos dúvidas de que o teste pode ser tratado como um projeto, que podemos classificar como um “projeto de apoio”, apenas para diminuir as resistências à utilização do termo.
No TCC mencionado, analisamos todas as áreas de conhecimento em gerenciamento de projetos preconizadas pelo PMI, avaliando a aplicabilidade das atividades de gerenciamento propostas ao gerenciamento das atividades de teste. Apoiando essa avaliação, procuramos aplicar no dia-a-dia da equipe alguns dos conceitos de gerenciamento de projetos, o que gerou excelentes resultados. Isso nos permitiu concluir pela viabilidade do tratamento dos testes sob a forma de um projeto específico.
Tanto nos projetos de desenvolvimento como nos projetos de teste, existe a necessidade de efetivo gerenciamento do escopo, dos prazos, custos e qualidade do projeto. Ou seja, as restrições são comuns aos dois tipos de projetos. Além disso, nos dois casos são utilizados
planos adicionais ou complementares ao plano global de projeto, como os planos de gerenciamento de recursos humanos, comunicações, riscos e aquisições.
A principal vantagem dessa abordagem, na minha opinião, é a independência e o maior patrocínio que os testes recebem dentro da organização. Isso é importante para que os testes não sejam deixados em segundo plano, o que infelizmente, ainda é muito comum na maioria dos projetos que tratam os testes apenas como uma fase do processo de desenvolvimento.
Vocês acham que temos condições (maturidade, apoio da alta diretoria…) de encararmos o teste como projeto?
Pergunta bem pertinente realizada pelo Aderson Bastos.
O Ueslei Silva respondeu a pergunta contando um pouco de uma experiência que teve:
Quando a alta Gerência de uma empresa cria resistência, acho que a solução é implantar aos poucos, pois desta forma os resultados aparecem de forma efetiva, o que, por fim, acaba mudando a visão da empresa e fazendo-a dar apoio.
Foi dessa forma que conduzi o trabalho em uma empresa que trabalhei, cujo software era um ERP com 23 módulos. O ambiente de desenvolvimento e teste um verdadeiro caos. Separei a equipe de testes em 2 partes. Uma parte mantive na demanda de teste diário para atender manutenção corretiva, e a outra elaborar casos de testes, pois não se tinha nenhuma documentação de desenvolvimento e nem de teste.
Como o ERP, tem 23 módulos interligados, Acontecia muito o fato de uma manutenção corretiva em determinado módulo propagar bugs a outros módulos. Criamos um mapa de interdependências, aumentando assim a cobertura dos testes para reduzir os erros propagados. Em seguida, inseri num projeto de manutenção evolutiva de, cerca de 400hs, o uso de Projeto de Teste, tendo o Plano de Testes, casos de teste, estratégias, automatização, etc… Aos poucos fomos evoluindo. Até onde sei, a empresa agora está com 3 divisões na equipe. Uma mantendo as demandas diárias de correção, outra com projetos evolutivos e a terceira com automatização.
Mesmo com toda a propagação de trabalho baseado em projeto, ainda vivemos a realidade de que o cliente quer tudo para ontem, a empresa não que perder a oportunidade nem o cliente mas, para atender, alguma coisa tem que morrer. Nessa hora, morre documentação, planejamento, gerencia de riscos, de RH, etc, etc… (existem casos que só não morrem os bugs…)
Na própria pergunta já tem a direção da resposta (rs).Maturidade eu vejo que ainda falta em muitas área de Teste de Software, não que isso seja um ponto tão negativo, uma vez que muitas áreas são bem recentes e há uma boa rotatividade de profissionais (na minha opinião, as pessoas ainda são o pilar principal para termos maturidade). Além disso, acredito que ainda há muitos profissionais que estão em um contexto, onde os testes estão no fim do processo de desenvolvimento, o que dificulta a eficiência dos testes;Apoio da alta diretoria vem sendo conquistada aos poucos, e esse apoio é muito importante, principalmente quando tratamos os testes como projeto.
Agora outro ponto importante são as pessoas, eu vejo que se for comparar o mercado de profissionais de hoje, do que quando eu entrei na área (em 2007) houve um bom progresso na maturidade e qualificação dos profissionais, prova disso são os níveis de discussões que temos aqui no DFTestes, entidades de ensino especializadas em cursos de Teste de Software, livros, eventos, blogs, etc.
Mas como eu disse antes, tudo depende da sua realidade, em certos projetos o melhor pode ser tratar os testes como uma atividade comum no desenvolvimento do sistema (e ao menos testes unitários e integrados deveriam ser!), e isso ocorre bastante, em empresas que utilizam metodologias ágeis. E mesmo, nesse contexto o profissional de Teste de Software tem um papel importante no projeto.
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.
Nunca tive problemas com os gerentes dos projetos, que participei. A influência deles deve ser positiva para os testes, e para isso é fundamental eles enxergarem a importância dos testes e terem ciência da dependência existente entre os testes e o sistema sob teste.
QualidadeBR 