Liderança em Testes: Executar um Projeto de Testes

Está preparado?

Gladiadores, chegou o momento de fazer o trabalho. O objetivo deste artigo é explicar-lhe como executar um projeto de testes. Vou abordar:

• A pressão clássica sobre os testes
• Comunicação do sucesso e do insucesso
• Erosão da cobertura
• Gestão de incidentes
• Gestão da fase final

Agora, está preparado? Existem quatro aspetos críticos:

• Pessoas — a sua equipa está preparada?
• Ambientes — dispõe das tecnologias, dos dados, dos dispositivos e das interfaces necessários para implementar testes significativos?
• Conhecimento — preparou os seus testes com um nível de detalhe adequado ou a sua equipa está preparada e é capaz de explorar e testar o sistema de forma dinâmica?
• Sistema sob teste — o software ou sistema que deve testar está realmente disponível?

Os três primeiros aspetos estão sob o seu controlo ou dispõe dos meios para monitorizar, gerir e coordenar ações que disponibilizem pessoas, ambientes e conhecimento. O sistema sob teste é outra questão. Se o sistema sob teste for entregue com atraso, não poderá iniciar os testes de forma significativa. Esta é a pressão clássica sobre os testes.

A pressão clássica sobre os testes

Qualquer pessoa que tenha testado sistemas já passou pela experiência de receber tardiamente o sistema a testar. A quase todos os níveis, desde componentes até sistemas completos, os programadores deparam-se com problemas e a entrega é atrasada ou fica incompleta. Na maioria das situações, quando foi atribuído um período para realizar os testes, o prazo não é alterado e os testes ficam sujeitos a uma pressão acrescida. Isto obriga as equipas a escolher entre qualidade e rapidez. Para conhecer ferramentas que oferecem o melhor dos dois mundos, consulte a nossa lista das principais plataformas de testes de software.

Entrega parcial e incremental

Embora o sistema completo não possa ser entregue para testes, algumas funcionalidades — um sistema parcial — podem ser entregues com a promessa de que as versões posteriores incluirão as funcionalidades restantes. A qualquer momento, o estado das funcionalidades de uma versão será:

• Concluídas conforme necessário: estas funcionalidades podem ser testadas — pelo menos de forma isolada.
• Incompletas: as funcionalidades não incluem determinados elementos e/ou sabe-se que apresentam falhas.
• Em falta: a entrega foi adiada para uma versão posterior.

No que diz respeito às funcionalidades disponíveis, poderá ser possível testá-las de forma isolada. No entanto, podem depender de dados criados por outras funcionalidades que ainda não estão disponíveis, o que pode dificultar os testes.

As funcionalidades podem estar disponíveis, mas os resultados dessas funcionalidades não podem ser verificados por outras funcionalidades que ainda não estão disponíveis, pelo que é necessário examinar a base de dados de testes antes e depois. É praticamente certo que os seus testes de ponta a ponta, que exigem sequências testáveis de funcionalidades, ficarão maioritariamente bloqueados.

Em quase todos os aspetos, os testes ao nível do sistema de sistemas parciais ficam seriamente condicionados.

Defender os testes

A sua equipa tem de progredir, por mais difícil que seja. Se o sistema não estiver disponível, ou estiver apenas parcialmente disponível para a equipa, terá de gerir as expectativas e defender o seu plano. 

O seu plano de testes, seja a uma escala pequena ou grande, depende da disponibilidade do sistema — esta é uma suposição —, pelo que o seu plano tem de mudar. Poderá não documentar critérios formais de entrada, mas a mensagem é a mesma:

Os critérios de entrada são pressupostos de planeamento – se estes critérios não forem cumpridos, os seus pressupostos de planeamento estão errados e o plano precisa de ser ajustado.

Quer esteja à espera que o sistema seja entregue, quer tenha acesso a um sistema parcial, rapidamente ficará sem coisas úteis para fazer. Depois, terá uma conversa difícil com o responsável pelo produto ou o gestor do projeto. Se o prazo de conclusão não for alterado, será obrigado a fazer menos testes. Algumas funcionalidades poderão ser testadas menos, ou retiradas por completo do âmbito dos testes.

O gestor poderá acreditar que conseguirá recuperar o tempo mais tarde, mas, na prática, isso é quase nunca possível.

O tempo de testes perdido devido a entregas tardias ou parciais não pode ser recuperado através de ‘trabalhar mais arduamente’.

Porque é que os testes são adiados? Existem muitas causas possíveis, mas tendem a seguir um destes padrões:

• Os ambientes não podem ser configurados a tempo. As pessoas começaram tarde, estavam demasiado ocupadas ou não tinham qualificações para criar um ambiente de testes adequado. O que está disponível é parcial, está mal configurado ou incompleto.
• A entrega está atrasada porque a dimensão do trabalho foi subestimada.
• A entrega está atrasada porque o software tem erros, é difícil de testar e de corrigir.
• A entrega está atrasada porque a equipa de desenvolvimento não possui as competências, a experiência ou o conhecimento necessário do domínio de negócio ou das tecnologias que está a utilizar.
• A entrega está atrasada porque o desenvolvimento começou tarde.
• A entrega está atrasada porque os requisitos continuam a mudar.

Estão excluídos da lista acima os atos de Deus e outros fatores externos fora do controlo da equipa do projeto. Se o gestor do projeto insistir que o prazo dos testes não muda e que o âmbito dos testes também é fixo, terá um desafio significativo. Em todos os casos acima, as causas da entrega tardia defendem a realização de mais testes, não menos.

Se o trabalho de desenvolvimento foi subestimado, então provavelmente os testes também o foram. Se o software tem erros, os testes demorarão mais tempo. Se os programadores não tiverem competências, o software será provavelmente de má qualidade e demorará mais tempo a testar. Se os programadores começaram tarde (porquê?) e o âmbito não foi alterado, por que razão deveriam os testes ser reduzidos? Se os requisitos mudam, é provável que os seus planos estejam errados de qualquer forma – trabalhar com base num plano inadequado torna inevitavelmente a vida mais difícil.

Quantas das causas comuns de uma entrega atrasada sugerem que são necessários menos testes? Nenhuma. Defenda o seu plano.

Comunicar o Sucesso e o Insucesso

A maioria dos testadores sabe que realizar testes eficazes exige curiosidade, persistência e um instinto para detetar problemas. A principal motivação é estimular falhas e criar provas suficientes para que as falhas sejam associadas a defeitos que possam depois ser corrigidos. 

Embora encontrar (e corrigir) defeitos seja positivo para a qualidade do produto, comunicar defeitos muitas vezes dá a sensação de que está a transmitir más notícias a alguém. Pode tratar-se de um programador que cometeu um erro em algum ponto e tem de o corrigir, ou pode estar a comunicar às partes interessadas que determinada funcionalidade crítica não funciona corretamente e que o sistema sofrerá um atraso.

Ninguém gosta de transmitir más notícias e é natural sentir relutância em perturbar outras pessoas, especialmente colegas próximos. Mas a sensação de que as suas notícias são boas ou más não é algo com que o mensageiro se deva preocupar. 

Os defeitos são sempre más notícias para alguém, mas o papel dos testes não é fazer juízos de valor desta forma. Em certos aspetos, o testador é como um jornalista, procurando a verdade. A história O Filho do Elefante, de Kipling, inclui os versos:

Conservo seis servidores honestos:
    (Ensinaram-me tudo o que sei)
Chamam-se O Quê, Onde e Quando
    E Como, Porquê e Quem.

Da mesma forma que um jornalista conta uma notícia, está a contar a história do que descobriu enquanto testava um sistema.

A verdade – a notícia – pode ser boa ou má, mas a sua responsabilidade consiste simplesmente em procurar tanto os problemas como os êxitos da melhor forma possível. Está a tentar descobrir o que um sistema faz e como o faz. 

No final de um projeto, o objetivo é colocar o produto em produção com o menor número possível de problemas pendentes. Quer que todos os seus testes passem, mas o caminho para o sucesso é dificultado por falhas nos testes que precisam de ser investigadas e resolvidas. O seu objetivo tático é encontrar rapidamente os problemas, mas o seu objetivo final é não ter problemas para comunicar. 

Para comunicar com precisão o sucesso ou o insucesso do seu projeto de testes, considere integrar ferramentas avançadas de gestão de testes que disponibilizem análises abrangentes

Tem de agir como um jornalista de investigação – procurando a história com uma mente crítica e independente. Como escreveu Kipling:

Se conseguires encontrar-te com o Triunfo e o Desastre e tratares esses dois impostores exatamente da mesma forma …

Assim, manterá a cabeça fria e fará um bom trabalho para o seu projeto e para as partes interessadas.

Erosão da cobertura

Quaisquer que sejam os objetivos de cobertura definidos no início dos testes, vários fatores contribuem para reduzir a cobertura efetivamente alcançada. Erosão é um termo adequado, pois reflete verdadeiramente a redução gradual do âmbito dos testes planeados e a inevitável constatação de que nem todos os testes planeados podem ser executados no tempo disponível.

A erosão da cobertura tem várias causas anteriores à execução dos testes:

• Em primeiro lugar, os planos de testes identificam os riscos a abordar e a abordagem a utilizar para os tratar. Os planos assumem normalmente um orçamento para os testes – o que é sempre um compromisso.
• Requisitos, conceções e especificações do sistema deficientes, instáveis ou inacabados dificultam a especificação dos testes. A cobertura do sistema fica comprometida pela falta de detalhe nas especificações.
• A disponibilidade tardia ou a inadequação dos ambientes de teste tornam certos testes planeados impraticáveis ou desprovidos de significado. Os testes de integração em maior escala podem ser impossíveis de executar conforme planeado, porque nem todas as interfaces ou sistemas com os quais se estabelecem interfaces podem ser disponibilizados.
• Os testes de desempenho podem ficar comprometidos porque os ambientes não têm a escala necessária ou não refletem o ambiente de produção.
• A entrega tardia do software sob teste significa que, quando os prazos se mantêm fixos, a quantidade de testes abrangida pelo âmbito tem de ser reduzida.

A erosão da cobertura durante a execução dos testes também tem várias causas:

• Se a qualidade do software a testar for deficiente no início de uma fase de testes, executar os testes pode ser particularmente frustrante. Os testes mais básicos podem falhar e os defeitos encontrados podem ser tão fundamentais que os programadores precisam de mais tempo para os corrigir do que qualquer pessoa previa. Se os testes forem suspensos porque a qualidade do software é demasiado baixa, haverá atrasos. Se o prazo não for alterado, alguns testes serão retirados do âmbito.
• Quando ocorrem mais defeitos do que o previsto, o próprio ciclo de correção e repetição dos testes demorará mais tempo e o tempo esgotar-se-á antes de concluir todos os testes.
• Quando o tempo se esgota e é tomada a decisão de lançar o produto, nem todos os testes estarão concluídos. Ou alguns testes nunca foram alcançados no plano, ou existem defeitos remanescentes que impedem a conclusão dos testes falhados. Quando a data de entrada em produção não é alterada, esta é a clássica compressão dos testes mencionada anteriormente.

Lidar com a erosão da cobertura dos testes é um dos desafios que os testadores enfrentam em todos os projetos. As coisas raramente correm sem problemas e reduzir o tempo destinado aos testes (e a cobertura) é normalmente a única opção para manter o projeto no caminho certo.

Não é errado reduzir a quantidade de testes; só é errado reduzir os testes arbitrariamente. Consequentemente, ao decidir quais testes eliminar, é necessário rever o impacto nos objetivos dos testes e nos riscos a abordar. Poderá ter de enfrentar algumas conversas difíceis com as partes interessadas.

Quando o impacto é significativo, poderá ser necessário facilitar uma reunião entre aqueles que solicitam os cortes (normalmente, a gestão do projeto) e aqueles cujos interesses poderão ser afetados pelos cortes (as partes interessadas). O seu papel consiste em expor a situação relativamente aos testes concluídos, ao estado atual conhecido do sistema testado, aos testes que falharam e/ou bloqueiam o progresso e à quantidade de testes que ainda falta realizar.

Os seus planos e modelos articulam o âmbito original dos testes e são essenciais para ajudar as partes interessadas e a gestão a compreender as lacunas e os riscos pendentes, bem como a decidir se devem continuar os testes ou interrompê-los.

Gestão de incidentes

Assim que o projeto entra nas fases de Testes de Sistema e Testes de Aceitação, é em grande medida orientado pelos incidentes que ocorrem durante a execução dos testes. Os incidentes desencadeiam atividades no restante do projeto e as estatísticas dos incidentes podem, por vezes, proporcionar uma boa perceção do estado do projeto. Ao categorizar os incidentes, temos de pensar antecipadamente na forma como essas informações serão utilizadas posteriormente.

Um incidente é um evento não planeado que ocorre durante os testes e que pode ter alguma influência na conclusão bem-sucedida dos testes, na decisão de aceitação ou na necessidade de tomar qualquer outra medida.

Utilizamos um termo neutro para estes eventos não planeados – incidente. No entanto, estes eventos são frequentemente designados por outros termos; alguns mais neutros do que outros. 

Os testes que falham podem ser designados por observações, anomalias ou problemas – termos neutros que não pressupõem uma causa. Mas, por vezes, são utilizados os termos problemas, erros, defeitos ou falhas – o que pressupõe que o sistema tem uma deficiência. No entanto, esta pode ser uma conclusão prematura e estas designações podem induzir em erro.

Sugerimos que reserve os termos erro, defeito ou falha para os resultados do diagnóstico de falhas na construção do sistema sob teste, que normalmente geram trabalho adicional para a equipa de desenvolvimento.

Os incidentes manifestam-se de duas formas:

1. Falha do sistema: o sistema não se comporta conforme esperado num teste, ou seja, falha de alguma forma ou parece não cumprir algum requisito.
2. Interrupção ou comprometimento dos testes ou da testagem: algum acontecimento que afeta a capacidade dos testadores de concluírem as suas tarefas, como a perda ou falha do ambiente de teste, dos dados, das interfaces, dos sistemas ou serviços integrados de suporte, ou alguma outra influência externa.

Falha do sistema

Estes incidentes são frequentemente motivo de preocupação mais direta, porque comprometem a confiança na qualidade do sistema. 

Interrupções e testes comprometidos

Algumas organizações não consideram estes acontecimentos como incidentes – as interrupções fazem parte da azáfama dos projetos que chegam à sua conclusão. Os testes comprometidos, isto é, aqueles em que o ambiente ou a configuração do teste estão incorretos, podem ser atribuídos à equipa de testes (por causa da configuração ou, pelo menos, por não ter verificado a configuração antes dos testes).

Em ambos os casos, o progresso dos testes é afetado e, se estiver a gerir o processo, é responsável por explicar os atrasos. Por este motivo, deve registar estes acontecimentos como incidentes ou pedir à equipa que mantenha um registo de testes e documente as interrupções do ambiente, os problemas de configuração ou a falta de versões de software adequadas para testar. Caso contrário, terá dificuldade em justificar os atrasos no progresso, o que poderá refletir-se negativamente em si e na equipa.

Registar incidentes ou não?

Com o advento das abordagens ágeis e da entrega contínua, a perspetiva tradicional sobre a gestão de incidentes tem sido posta em causa. Nos projetos faseados, os incidentes são tratados como potenciais pacotes de trabalho para os programadores, aprovados de acordo com a gravidade e/ou urgência. 

Existe um processo formal, frequentemente burocrático, a seguir, através do qual os incidentes são analisados, priorizados e tratados pela equipa de desenvolvimento (ou por outra equipa). Podem ser utilizadas ferramentas sofisticadas de gestão de incidentes.

Nas equipas ágeis mais pequenas, a relação entre o testador e o programador é próxima. A equipa, como um todo, pode reunir-se diariamente para discutir incidentes de maior dimensão, mas, na maioria das vezes, os erros são detetados, diagnosticados, corrigidos e novamente testados informalmente, sem qualquer necessidade de registar um incidente ou envolver outras pessoas da equipa ou elementos externos da área de negócio ou das TI. Os erros mais graves podem ser discutidos e integrados no trabalho de uma história de utilizador, ou agrupados em iterações ou sprints dedicados à correção de erros.

Num artigo anterior, discutimos o objetivo e a necessidade da documentação. Essa discussão também se aplica aos incidentes. A equipa precisa de considerar se é necessária uma ferramenta e um processo de gestão de incidentes e se estes são úteis para a equipa e/ou exigidos por pessoas externas à equipa.

As equipas maiores tendem a depender de processos e ferramentas para gerir incidentes por três motivos: 

1. Garantir que os incidentes não são esquecidos
2. Garantir que os problemas graves são analisados pelas partes interessadas e pela gestão do projeto 
3. Recolher métricas que possam ser valiosas durante e após o projeto.

Separar a urgência da gravidade

Independentemente do processo de gestão de incidentes que adote, recomendamos que atribua um código de prioridade e um código de gravidade a todos os seus incidentes.

• A prioridade é atribuída do ponto de vista dos testes e influencia quando um incidente será resolvido. O testador deve decidir se um incidente tem prioridade alta ou baixa (ou qualquer um dos graus intermédios que possam ser permitidos). A prioridade indica a urgência desta falha para os próprios testadores e baseia-se no impacto que a falha do teste tem no restante processo de testes.
• A gravidade é atribuída do ponto de vista do utilizador e indica a aceitabilidade ou não aceitabilidade de (normalmente) um defeito. Os utilizadores finais ou a respetiva gestão devem atribuir a gravidade ou, de forma mais eficiente, substituir conforme necessário a avaliação inicial dos testadores. A gravidade reflete o impacto desse defeito no negócio caso não fosse corrigido antes da entrega. Normalmente, um defeito grave torna o sistema inaceitável. Se um defeito tiver baixa gravidade, pode ser considerado demasiado insignificante para precisar de ser corrigido antes da entrada em produção, mas poderá ser corrigido numa versão posterior.

Se um incidente interromper os testes e estes estiverem no caminho crítico, todo o projeto é interrompido.

Um incidente de alta prioridade interrompe todos os testes e, normalmente, o projeto.

O aspeto importante a ter em conta nos esquemas de classificação de incidentes é que nem todos os incidentes urgentes são graves e que nem todos os incidentes graves são urgentes.

Gerir a fase final

Chamamos «fase final» às últimas etapas do nosso processo de testes, porque a gestão das atividades de teste durante estes últimos dias, possivelmente frenéticos e stressantes, exige uma disciplina diferente da do período anterior, aparentemente muito mais descontraído, de planeamento dos testes.

Lembre-se de que o objetivo dos testes é fornecer informações às partes interessadas para lhes permitir tomar uma decisão – aceitar, corrigir, rejeitar, prolongar o projeto ou abandoná-lo completamente. 

Se tiver uma compreensão partilhada dos modelos a utilizar nos testes, será muito mais fácil explicar o que «funciona» (no que diz respeito ao modelo), bem como onde as coisas não funcionam e quais são os riscos dessas falhas. Cabe às partes interessadas utilizar estas informações para tomar as suas decisões, orientadas por si.

Uma das vantagens de adotar uma abordagem de testes baseados no risco é que, quando os testes são reduzidos numa fase tardia do projeto, utilizamos o risco residual para defender a continuação dos testes ou até a realização de mais testes. 

Quando a gestão insiste em reduzir os testes, os testadores devem simplesmente apresentar os riscos que estão a ser «trocados». Isto é muito mais fácil quando foi realizada uma avaliação inicial dos riscos, utilizada para orientar as atividades de teste e acompanhada ao longo de todo o projeto. Quando a gestão está continuamente consciente dos riscos residuais, é menos provável que reduza os testes desde o início.

E é tudo, boa sorte com os seus testes!

Inscreva-se na newsletter do The QA Lead para receber uma notificação quando forem publicados novos artigos da série. Estes artigos são excertos do curso 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!