Liderança em Testes: Planeamento de Testes

Afinal, o que é um plano?

Um plano de projeto combina as tarefas do projeto, as durações estimadas, as dependências e os resultados a entregar num modelo programado da realidade.

Se considerar o plano uma previsão do futuro, terá muitas reservas em confiar nele, mas é isso que normalmente fazemos.

Poderá já ter encontrado gestores de projeto que tratam o seu plano como a sua realidade pessoal — o seu próprio mundo delirante. Mas não devemos ser tão severos com os gestores de projeto — muitas vezes, sentem-se motivados a criar um plano e a cumpri-lo, aconteça o que acontecer.

O plano não é a realidade; é um modelo da realidade que exige alterações constantes.

Neste artigo, abordarei todas as etapas do planeamento de testes, incluindo:

• Resultados a entregar
• Como
• Recursos
• A sua rede de apoio
• Estimativas
• Dependências, riscos e pressupostos
• Comunicação, compromisso e comunicação do progresso

Mas, primeiro, vamos formar uma ideia clara da utilidade de um plano. 

Porquê planear?

O objetivo do planeamento é, normalmente, criar uma abordagem acordada, um conjunto de compromissos, dependências, custos e um calendário para entregar um projeto. O plano é um entendimento entre as partes interessadas do projeto, os fornecedores e os participantes, que normalmente estabelece o seguinte:

• Que recursos são necessários e quando
• Quando devem começar e terminar as tarefas e quem as executará
• As competências necessárias para concluir as tarefas
• As ferramentas e tecnologias que apoiam o plano
• Os resultados a entregar e quando serão entregues
• Os custos do esforço e dos recursos necessários
• O processo para fazer avançar o projeto/processo ao longo das suas etapas
• Os riscos que ameaçam a entrega.

Alguns destes aspetos poderão estar especificados numa estratégia ou já estar implementados. Poderá ser sabido, por exemplo, que fornecedores estão envolvidos e o que farão pelo projeto. As ferramentas e a tecnologia a utilizar poderão já ser conhecidas e estar implementadas. As pessoas, os ambientes de testes e os dados poderão estar prontos. Poderá também existir uma estratégia que defina o processo, a abordagem ou as técnicas a utilizar.

Contudo, enquanto a estratégia estabelece os princípios ou a teoria, o plano descreve os aspetos práticos ou a logística de como o projeto será entregue na realidade.

Uma estratégia estabelece, em princípio, como um projeto será executado; o plano define e confirma como o projeto será executado na prática.

Para muitos gestores de projeto, o plano é mantido em software como o Microsoft Project, mas um plano viável depende de todos os participantes do projeto saberem o que estão a fazer e como o devem fazer. Para o conseguir, o plano e o conhecimento sobre como as coisas serão feitas têm de ser comunicados e assumidos por todos os envolvidos.

Planear é uma jornada, não uma tarefa

Nas palavras do antigo Presidente dos EUA Dwight D. Eisenhower, “planear é tudo. O plano não é nada.” Este sentimento é tão importante que merece ser repetido em quase todos os contextos de trabalho em projetos de sistemas. Mas o que significa dizer que o plano não é nada? Qual é o objetivo de planear se o resultado for um plano sem valor? 

O plano com que acaba nunca é inútil, mas o sentimento de Eisenhower está relacionado com o ato de planear e com o seu valor em comparação com o plano. Vamos comparar rapidamente, em separado, como funciona o planeamento em projetos estruturados de longa duração e em projetos ágeis/contínuos.

Planeamento estruturado vs. ágil

Num projeto de longo prazo, a sua empresa, os fornecedores e a equipa interna de TI precisam de saber que compromisso lhes é exigido, para poderem agendar a disponibilidade de pessoas e recursos físicos.

É preciso tempo precioso para reunir as informações necessárias à criação de um plano. Com todas as dependências de recursos e pessoas, e com o compromisso e desempenho dos fornecedores, bem como das pessoas internas, muitas coisas podem correr mal. Algumas coisas vão correr mal. Por isso, o plano, enquanto previsão do futuro, está sujeito a grandes dificuldades.

No dia seguinte à publicação de um plano, e todos os dias subsequentemente, surgem novas informações e é necessário efetuar alguns ajustes. Os requisitos são eliminados; os fornecedores fazem entregas atrasadas; os ambientes, os dados de teste ou as ferramentas não estão prontos a tempo. A lista continua. O planeamento nunca é uma tarefa pontual, é uma atividade contínua — quase diária.

Muitas vezes, os acontecimentos não planeados são tratados como ruído e não recebem muita atenção. Mas, mais tarde, algumas destas pequenas falhas transformam-se em problemas importantes. Um dos desafios dos projetos em cascata é que este ajuste contínuo pode ser oneroso, porque quaisquer alterações são vistas como interferências desnecessárias. Frequentemente, os projetos avançam independentemente, na esperança de que tudo corra ‘bem no momento decisivo’. Mas raramente é esse o caso e isto já foi dito muitas vezes:

Como é que um projeto se atrasa um ano? Um dia de cada vez.

A abordagem ágil é, em parte, uma reação à frustração causada por planos fixos ou inflexíveis. A agilidade é a alternativa comprovada à inércia das abordagens pesadas e faseadas. Mas isto significa que os projetos ágeis não fazem planeamento? Não. 

Mesmo em projetos ágeis, é necessário algum planeamento inicial para estruturar o trabalho, mobilizar recursos e calendarizar — pelo menos a um nível elevado — o processo de lançamento ao longo dos meses seguintes. Mas, iteração após iteração, e frequentemente dia após dia, o plano geral é continuamente ajustado para ter em conta os acontecimentos e as novas informações que vão surgindo.

O planeamento é uma jornada contínua de aprendizagem, não uma tarefa com um resultado a entregar.

Planeamento de testes

Até agora, analisámos o planeamento de projetos em termos gerais e sugerimos que se trata, em grande medida, de uma atividade contínua. Agora vamos concentrar-nos especificamente no planeamento dos testes em projetos. 

O planeamento de testes é muito semelhante ao planeamento de projetos — trata-se, na realidade, de um plano de menor escala. Naturalmente, o plano de testes também tem de se integrar no plano de projeto mais abrangente, porque depende de outras atividades e resultados a entregar do projeto (e outras tarefas dependem dos testes). Frequentemente, os planos de testes são afetados porque estas dependências não são cumpridas.

Em termos gerais, os planos de testes são relativamente simples. Pode haver várias atividades que dependem do projeto principal. Estas são as que aparecem frequentemente como tarefas no plano de projeto mais abrangente. Mas estas atividades são distribuídas por uma equipa, que pode ter um grande inventário de itens de teste para os quais é necessário planear e executar testes. 

Este nível de detalhe não é tão relevante para o calendário do gestor de projeto e é normalmente definido e gerido a nível local dentro da equipa de testes.

Vejamos alguns dos elementos fundamentais do seu plano de testes.

Resultados a entregar

Quais são os resultados a entregar dos testes?

Que pergunta! Certamente são as especificações dos testes, os testes, os resultados e os relatórios? Os resultados a entregar estão essencialmente contidos na documentação, por isso só temos de nos preocupar em tratar da documentação e assinalar algumas caixas. 

Mas esta abordagem, embora comum, é parcialmente responsável pela reputação dos testes (e dos testadores) como burocratas dispendiosos e pouco flexíveis, com pouco valor. Afinal, quem lê estes documentos volumosos?

Suponhamos que não existe intenção de produzir documentação de testes num projeto ágil. É muito provável que assim seja, por isso, o que é que os testes entregam realmente nessas situações? Que valor têm os testes? É um pouco tarde para fazer estas perguntas, não é?

Quando um componente, subsistema ou todo o sistema é testado, o resultado é uma evidência de como o sistema se comporta numa determinada situação ou contexto. As evidências do comportamento do sistema são recolhidas e compiladas para serem apresentadas às partes interessadas (programadores, utilizadores, gestores, etc.), para que estas tomem uma decisão: corrigir erros, integrar um componente, aceitar ou rejeitar funcionalidades, lançar ou implementar um subsistema ou o sistema como um todo.

O resultado a entregar dos testes é a evidência do comportamento do sistema utilizada pelas partes interessadas para tomar uma decisão.

Agora, em alguns projetos, é essencial fornecer documentação de testes para registar como um teste foi delimitado, concebido, implementado e executado. Mas são as evidências do comportamento do sistema que constituem o resultado final de valor para as partes interessadas.

O valor dos testes é o nível de confiança que as partes interessadas têm para tomar decisões com base nas evidências dos testes.

Estas evidências podem ser recolhidas, organizadas em tabelas e analisadas sistematicamente em soluções de gestão de testes sofisticadas e apresentadas às partes interessadas em formatos gráficos elegantes. Ou as notas manuscritas podem ser utilizadas por um testador para apresentar verbalmente a história dos testes a um responsável pelo produto numa reunião diária.

Independentemente da forma como são recolhidas e apresentadas, a tarefa final dos testes é a entrega das evidências.

Como

Independentemente da dimensão ou da metodologia do projeto, os testes dependem de uma determinada série de atividades. Analisaremos um processo genérico através da perspetiva do testador (ou da equipa) e, em seguida, veremos algumas das variações que ocorrem. 

Existem as chamadas «atividades de teste» e existem atividades de «suporte aos testes» ou «logísticas». Para garantir que inclui todas as atividades no plano, poderá considerar úteis as tabelas abaixo como listas de verificação.

Uma atividade da tabela acima que talvez não reconheça tão bem é a atividade de feedback. É provável que já tenha tido de trabalhar com requisitos deficientes. 

A atividade de feedback, revisão e questionamento é aquela em que os testadores, depois de analisarem e modelarem um requisito, detetam problemas e podem utilizar exemplos para demonstrar onde os requisitos estão ausentes, são ambíguos ou são contraditórios.

Se considerar que os requisitos são deficientes, vale definitivamente a pena reservar tempo para esta atividade.

Logística de testes

A logística de testes apoia as atividades de teste acima descritas. Embora a lista de atividades de teste que apresentei seja razoavelmente abrangente, a logística de testes varia em cada projeto e organização. Por conseguinte, a lista abaixo não é abrangente. No seu projeto, dedique algum tempo a analisar cada atividade ou dependência necessária para realizar os testes.

Recursos (humanos, físicos)

Utilizamos frequentemente a palavra recursos para nos referirmos às pessoas nos nossos projetos e, para algumas pessoas, isso não é confortável. As pessoas não são coisas, são seres humanos, naturalmente. Em projetos mais pequenos, poderá ser possível utilizar nomes, mas, em organizações maiores, quando estão envolvidas equipas de projeto que poderão ainda não ter sido constituídas, um determinado número de recursos é simplesmente uma forma abreviada de dizer um determinado número de pessoas.

Mais importante ainda, não é necessariamente o número de pessoas que conta – são as suas capacidades que realmente importam. Naturalmente, as pessoas trabalham de formas diferentes e, geralmente, a velocidades diferentes, pelo que terá de ter isso em conta no seu planeamento.

Para além das pessoas, precisará, em diferentes fases, de diferentes recursos físicos para que os testes possam avançar. Estes vão desde os mais banais aos altamente específicos, e a falta de qualquer um deles pode ameaçar a missão de testes.

Poderá já ter a sorte de ter acesso a um laboratório de testes dedicado, gerido e totalmente equipado. Se não tiver, poderá precisar de especificar tudo – desde o espaço físico e o mobiliário até às notas autocolantes e às borrachas – para definir o seu ambiente de trabalho.

Na tabela abaixo, são apresentados alguns recursos típicos necessários. Sem dúvida, a sua lista será consideravelmente diferente. 

Depois de identificar todos os recursos necessários para executar o seu plano, considere se precisa de incluir atividades adicionais no plano para os adquirir.

A sua rede de apoio

Se as pessoas e competências de que precisa para realizar os testes estivessem sob o seu controlo, os projetos poderiam ser muito mais simples! Mas poucas equipas possuem todas as competências de que necessitam ou a autorização e o acesso aos recursos físicos necessários. Muitos projetos são constituídos e geridos segundo o modelo de gestão matricial. Os principais membros da equipa respondem, na realidade, perante responsáveis de outros departamentos especializados e obterá deles um compromisso limitado.

Poderá ser necessário especificar um determinado número de horas por dia ou definir horários para ter acesso às competências especializadas acima. Por vezes, ser-lhe-á perguntado que nível de serviço é aceitável, por exemplo, «os pedidos de alta prioridade terão resposta no prazo de trinta minutos», e assim por diante.

Estimativas

A estimativa em projetos de software é uma tarefa complexa. Muito se tem escrito sobre a dificuldade, ou até impossibilidade, de fazer estimativas. No entanto, são necessárias estimativas em todos os projetos e, quanto maior for o projeto, mais dependemos delas.

Precisamos de estimativas para criar um plano, mas o problema é que a estimativa não proporciona exatidão. O melhor que podemos fazer é calcular o esforço ou o tempo decorrido com algum nível de confiança ou probabilidade.

Algumas pessoas consideram a estimativa uma arte obscura e existe até um movimento #NoEstimates com um número significativo de seguidores. Existe muita controvérsia sobre se uma estimativa pode alguma vez ser suficientemente precisa ou se é sequer uma boa prática em projetos de software.

A estimativa nunca será uma ciência exata. Mas, com base na minha experiência, há alguns princípios que me sinto à vontade para partilhar:

• Os requisitos são falíveis e imprecisos.
• As pessoas são mais ou menos competentes, conscienciosas e trabalhadoras.
• Quanto menor for o item de trabalho, mais fácil será estimá-lo; divida as tarefas grandes em unidades menores sempre que possível e agregue as estimativas na tarefa maior.
• A estimativa baseia-se na experiência. Se não tiver nenhuma, procure situações em que a experiência de outras pessoas seja relevante e possa ser adaptada.
• O seu item de trabalho é único, por isso procure padrões de trabalho noutras situações conhecidas em que tenha experiência.
• Peça a outras pessoas que façam uma estimativa e compare-as. A discussão das discrepâncias expõe diferenças nas expectativas, na confiança e no rigor.
• Estime a situação mais favorável e, em seguida, a situação menos favorável. Uma boa estimativa encontra-se algures entre as duas.

Faça uma estimativa hoje e comece o trabalho; amanhã e em todos os dias seguintes, com os conhecimentos adquiridos, a sua estimativa do tempo necessário para concluir irá melhorar.

Dependências, riscos e pressupostos

Num artigo anterior, abordámos o risco e o papel dos testes na gestão de riscos. Os riscos do produto estão relacionados com o facto de o produto satisfazer ou não as necessidades dos utilizadores relativamente aos requisitos funcionais ou técnicos. Aqui, o foco está nos riscos associados ao plano de entrega propriamente dito.

As coisas correm mal nos projetos. Durante o planeamento, é necessário deixar claro quais os riscos de falha que considerou e para os quais tomou medidas. Há três aspetos a considerar: dependências, riscos e respostas.

Dependências

As dependências representam uma lista dos recursos humanos e físicos necessários, bem como das atividades predecessoras, que têm de ser concluídas para que as atividades planeadas sejam bem-sucedidas e produzam resultados. 

Existem sempre dependências em qualquer atividade de testes, quer se trate de um teste de sistema em grande escala, quer de uma sessão de testes exploratórios de uma funcionalidade. As dependências abrangem três aspetos principais.

Riscos

O risco é a probabilidade de o seu plano falhar durante a execução. O risco está relacionado com aspetos como:

• As suas estimativas: o que poderia fazer com que as suas estimativas estivessem erradas? Um sistema mais complexo, com defeitos, incompleto ou em constante mudança poderia afetar as suas estimativas.
• A indisponibilidade de pessoas, a falta de experiência ou de competências, ou a falta de empenho total na sua fase do projeto. Podem tratar-se de membros da equipa ou de pessoas da sua rede de apoio.
• A indisponibilidade, preparação inadequada ou existência de defeitos na infraestrutura, como ambientes de testes, ferramentas (ou formação na utilização das ferramentas) ou espaço de escritório.
• O não cumprimento atempado das atividades predecessoras (ou o seu abandono, a entrega de produtos parciais ou com defeitos, ou a não entrega de qualquer produto).

Respostas

Para cada um destes riscos, é necessário avaliar a probabilidade, o impacto e, quando forem significativos, uma resposta adequada ou a consequência esperada. Estas respostas tendem a assumir uma das seguintes formas:

• Pressuposto: considera-se que o risco é suficientemente baixo para ser ignorado ou considerado inconsequente. No entanto, permanece no radar e é registado como um pressuposto (de disponibilidade, conclusão, etc.)
• Ajuste: o risco é significativo, mas existe uma ação que pode reduzir o seu impacto no plano. Por exemplo, se o sistema em teste for entregue parcialmente, com funcionalidades em falta, o plano pode ser ajustado para testar apenas as funcionalidades disponíveis.
• Consequência: alguns riscos não podem ser assimilados. Se o sistema for entregue com atraso, os testes não poderão começar até que seja entregue.

Comunicação, compromisso e comunicação do progresso

Por último, chegamos ao aspeto crucial, mas frequentemente negligenciado, do planeamento. Pode elaborar um plano de projeto que inclua todas as tarefas, participantes, recursos, responsabilidades, dependências, prazos, esforço e custos. Ou pode tratar-se de um entendimento verbal entre os membros de uma equipa ágil. 

De qualquer forma, o plano precisa de ser comunicado eficazmente a todos, para que saibam o que é necessário e quando.

Um plano acordado é um contrato entre os participantes. Se um gestor de equipa aprovar formalmente um plano, isso constitui um compromisso implícito ou explícito de cumprir a parte do contrato correspondente à sua equipa.

O plano é um contrato entre os participantes.

Em projetos menos formais, pode não existir qualquer plano escrito ou compromisso. Nestas circunstâncias, o plano é uma conversa contínua entre os membros da equipa. A equipa reúne-se diariamente e as tarefas ativas do plano são discutidas em tempo real. Em que estão as pessoas a trabalhar? O progresso está a decorrer de acordo com as expectativas? Que problemas estão as pessoas a enfrentar? Que problemas estão a bloquear o progresso?

Em todos os projetos, o objetivo dos relatórios de progresso é duplo. Obviamente, é necessário comunicar em que ponto se encontra cada pessoa relativamente à sua atividade atual no projeto. Mas o relatório de progresso é também uma verificação periódica contínua de que o progresso pode ser mantido e de que se pode contar com o cumprimento do compromisso assumido pelos participantes.

Obrigado pela leitura; juntem-se a nós da próxima vez para… adivinharam, a execução!

Inscreva-se no boletim informativo da The QA Lead para receber uma notificação quando forem publicados novos capítulos da série. Estas publicações são excertos do curso de Liderança em Testes do Paul, que recomendamos vivamente para aprofundar este e outros temas. Se o fizer, utilize o nosso código de cupão exclusivo QALEADOFFER para obter um desconto de 60 $ no preço total do curso!