Liderança em Testes: Testar em Equipa

Nos últimos anos, a responsabilidade pelos testes tornou-se mais distribuída. Em vez de serem equipas dedicadas a assumir a responsabilidade pelos testes, as equipas estão agora a incentivar utilizadores, analistas, programadores e testadores a redistribuir essa responsabilidade para apoiar uma melhor colaboração. Por conseguinte, algumas atividades e responsabilidades de teste estão a ser antecipadas.

Neste artigo, abordarei:

• Antecipação dos testes
• Testes como atividade, não como função
• Uma nova função
• Intervenções de testes ágeis
• Relações com os programadores
• Desafios das equipas distribuídas e subcontratadas

Introdução à antecipação dos testes

A antecipação dos testes, ou deslocação para a esquerda, pode referir-se a vários cenários diferentes. Pode significar que os programadores assumem uma maior propriedade e responsabilidade pelos seus próprios testes. Também pode significar que os testadores se envolvem mais cedo no projeto, questionando os requisitos e fornecendo exemplos aos programadores através de um processo de Desenvolvimento Orientado pelo Comportamento (BDD). 

Por vezes, pode significar que não existem testadores (dun-dun-duuu), ficando os analistas de negócio e os programadores com toda a responsabilidade pelos testes.

A antecipação dos testes não é uma novidade — os defensores dos testes têm pregado o mantra «testar cedo, testar frequentemente» há muitos anos. Já em 1993, sugeria-se que todos os artefactos de um processo faseado — tanto documentais como de software — podiam (e deviam frequentemente) ser testados.

A antecipação dos testes consiste sobretudo em introduzir mais cedo no processo a reflexão sobre os testes.

Embora o modelo em cascata fosse a abordagem dominante ao ciclo de vida na altura, o número ou a duração das fases não são o que importa. O princípio subjacente era que as fontes de conhecimento que orientam a conceção e o desenvolvimento de software deviam ser questionadas ou testadas. 

Num projeto faseado, isto poderia envolver revisões formais. Num projeto Ágil, o testador (ou programador, analista de negócio ou utilizador) pode sugerir cenários que desafiem o autor de um requisito ou história a refletir sobre exemplos concretos e a discuti-los antes de ser escrito qualquer código.

Estas são as principais mudanças associadas ao fenómeno da antecipação dos testes:

1. A abordagem de Desenvolvimento Orientado pelo Comportamento (BDD) permitiu que programadores, utilizadores/analistas de negócio e testadores colaborassem em torno do que se pode chamar histórias de negócio. O Desenvolvimento Orientado por Testes tem sido utilizado por muitos programadores há 15 ou mais anos. Atualmente, o BDD está a ser adotado de forma mais generalizada porque promove uma melhor colaboração nas equipas ágeis, além de introduzir ferramentas de BDD que podem ser utilizadas pelos programadores. É uma abordagem de Desenvolvimento Orientado por Testes mais simples.
2. A Entrega Contínua (CD) existe há 5-10 anos e tem as suas raízes nas abordagens altamente automatizadas de compilação e automatização de lançamentos desenvolvidas pelas grandes empresas em linha. Atualmente, é adotada pela maioria das organizações com presença em linha.
3. A CD sistematizou e acelerou o processo de lançamento através da automatização. Mas também evidenciou os atrasos na produção, implementação e alteração da infraestrutura que anteriormente eram ocultados por processos lentos de compilação, teste e lançamento. DevOps é uma mudança de mentalidade cultural através da qual os programadores colaboram muito mais estreitamente com as equipas de operações. Atualmente, surgem novas ferramentas quase diariamente e os fornecedores promovem DevOps como «a próxima grande tendência». É uma situação muito mediatizada e dinâmica.
4. SMAC, ou Social, Móvel, Análise e Nuvem, representa uma mudança na forma como as organizações gerem as alterações empresariais e dos sistemas no espaço móvel. A experimentação empresarial, implementada como alterações nos sistemas de produção, é monitorizada a um nível detalhado. Os dados de grande dimensão recolhidos são processados e são tomadas decisões empresariais com base nas análises obtidas.

A experimentação frequente com sistemas de produção permite a inovação empresarial «à velocidade do marketing». A experimentação está no centro do que foi a tendência mais importante da década de 2010 — a Transformação Digital.

Testes como atividade, não como função

A antecipação dos testes altera o papel dos testadores. A redistribuição dos testes desencadeada pela abordagem de antecipação torna claro que os testadores não são os únicos responsáveis pelos testes, ou seja, os testadores já não detêm a responsabilidade pelos testes. 

Se pensarmos nisso, na realidade nunca foram verdadeiramente responsáveis pelos testes, mas existia um entendimento tácito nos projetos de que, independentemente do que o resto da equipa, em particular os programadores, fizesse em termos de testes, os testadores forneciam uma rede de segurança. Se os programadores fossem pressionados pelo tempo e reduzissem os seus testes para conseguir entregar, a rede de segurança era assegurada pelos testadores.

Os testes são agora uma atividade, não uma função.

Os programadores estão a adotar melhores práticas de testes e uma maior visibilidade sobre o seu trabalho. Os bons testes ao nível dos componentes ou testes unitários têm objetivos específicos, distintos dos testes do sistema (por exemplo). Por isso, o âmbito (ou a quantidade) dos testes ao nível do sistema pode ser reduzido. 

A distribuição correta dos objetivos dos testes e dos testes necessários para atingir esses objetivos é a finalidade principal da estratégia de testes. Infelizmente, até recentemente, os programadores não eram responsabilizados de forma eficaz, pelo que dependiam de testes tardios do sistema para compensar.

A deslocação para a esquerda torna os programadores mais responsáveis.

De um modo geral, a responsabilidade pelos testes é redistribuída, pelo que a função do testador se altera. Os testadores podem realizar menos testes táticos, mas a sua contribuição estratégica aumenta. Os testadores podem ser responsáveis pela estratégia de testes, questionar os requisitos, aconselhar as partes interessadas e estabelecer uma relação mais próxima com os programadores para apoiar melhores testes realizados pelos programadores e a automatização de testes.

Uma nova função

A deslocação para a esquerda implica que, sempre que for possível fornecer feedback que ajude a equipa a compreender, questionar e melhorar os objetivos, requisitos, conceção ou implementação, esse feedback deve ser fornecido. 

Os utilizadores, os analistas de negócio, os programadores e toda a equipa de software devem estar preparados para trocar feedback desta forma. Por vezes existe resistência, mas o objetivo geral é executar um projeto melhor e mais informado — nada mais.

A forma mais fácil de resumir este comportamento é «envolver-se cedo» — tão cedo quanto possível. Participar na discussão e colaborar em ideias, requisitos e em todas as fases em que o resultado dessa fase tenha impacto no valor do produto final do projeto. 

Em termos simples, o testador questiona as fontes de conhecimento, quer essas fontes sejam partes interessadas, utilizadores, programadores, histórias de negócio, documentos ou precedentes.

A abordagem mais comum consiste em questionar através de exemplos. Em todas as fases, estes exemplos podem ser considerados testes. Podem ser rapidamente descartados após a utilização ou codificados em automatização de testes ou verificações manuais. Estes exemplos podem ser utilizados apenas de forma tática para salientar falhas no raciocínio das pessoas, ou ser fornecidos aos programadores, por exemplo, como ideias ou bases para testes realizados pelos programadores. Podem também ser utilizados como auxiliares de orientação para mostrar aos utilizadores ou programadores como criar testes melhores.

Pense no seu projeto de software como um processo de aquisição de conhecimento. Este conhecimento é recolhido ao longo do projeto e, muitas vezes, evolui com o tempo. O objetivo da deslocação para a esquerda é garantir este conhecimento através do questionamento e dos testes próximos da sua origem e assegurar, sempre que possível, que é fiável antes de ser congelado no código.

A deslocação para a esquerda leva a filosofia de testar primeiro mais longe. Os métodos ágeis sempre promoveram a colaboração e o feedback rápido — a deslocação para a esquerda pode ser vista como uma abordagem concertada de feedback rápido. Se a sua equipa estiver a adotar uma abordagem de deslocação para a esquerda aos testes, ter as ferramentas certas pode fazer toda a diferença. Consulte a nossa lista selecionada de ferramentas de testes de software para encontrar a opção mais adequada à sua equipa.

Intervenções de testes ágeis

A abordagem de deslocação para a esquerda é fundamental para uma estratégia de testes em projetos ágeis. Num contexto ágil, a estratégia de testes pode ser vista como uma série de intervenções de testes. Em todos os projetos existem momentos críticos em que surgem oportunidades para recolher e fornecer feedback. O testador deve concentrar-se nesses momentos críticos e estar preparado para contribuir nessas ocasiões.

Nos seus próprios projetos, deve identificar os momentos críticos em que é possível intervir e identificar as escolhas que pode fazer ao testar enquanto equipa. Por exemplo, deve o testador escrever testes unitários para os programadores, fornecer exemplos para os ajudar a começar ou orientá-los para melhorar a sua capacidade de testar? Só você e a sua nova equipa de testes de software podem decidir.

Utilizaremos um processo Scrum típico para demonstrar como as intervenções de testes podem ser posicionadas na abordagem Scrum. As intervenções ocorrem ao nível do projeto (ou lançamento) ou ao nível de um sprint. O diagrama abaixo apresenta uma visão ao nível do projeto e as cinco intervenções principais.

O questionamento da história e a definição da história são os momentos em que o testador valida, respetivamente, uma história de utilizador e os critérios de aceitação propostos para uma história. Os testes de integração verificam se as novas funcionalidades se ligam corretamente a outras funcionalidades e ao sistema como um todo. Os testes do sistema e os testes de utilizador (de aceitação) são realizados conforme adequado.

Um projeto tem normalmente vários sprints e as quatro intervenções do sprint são apresentadas no diagrama abaixo. A reunião diária de acompanhamento é uma oportunidade para comunicar o progresso, manifestar preocupações, identificar riscos ou discutir questões levantadas e respostas recebidas durante o sprint. 

O aperfeiçoamento da história e as contribuições para os testes realizados pelos programadores são atividades diárias que ocorrem no âmbito das discussões com utilizadores, analistas e programadores. O testador incorpora os testes realizados pelos programadores e os novos testes do sistema numa coleção crescente de testes a automatizar.

Na tabela abaixo, pode ver um resumo tabular das intervenções dos testadores. O seu processo pode ser diferente, ou basear-se no Scrum com algumas variações, mas a tabela identifica tipos de intervenção típicos num processo Scrum típico. Poderá ter mais ou menos intervenções ativas em diferentes momentos do seu próprio processo único.

Sugiro que identifique os momentos críticos, proponha o seu contributo e negoceie com a sua equipa. Oferece mais liderança e orientação relativamente aos testes, em vez de se disponibilizar simplesmente para assumir a responsabilidade pelo trabalho de testes. Esta abordagem tornará muito mais fácil demonstrar o seu valor à equipa, mas a equipa poderá não precisar de tantos testadores.

Relações com os programadores

Em algumas organizações, a relação entre os programadores pode ser de desconfiança, culpabilização e antagonismo. No pior dos casos, a relação é tóxica: os programadores quase não testam e os testadores são vistos como servos dos programadores. Os testadores adotam comportamentos que podem ser descritos como codependentes e comportam-se como vítimas. Esta situação é precisamente aquilo que a abordagem de antecipação dos testes procura evitar.

Existem muitas metáforas que têm sido utilizadas para descrever uma boa relação entre programadores e testadores. Utilizaremos uma forma de trabalhar baseada na relação entre piloto e navegador para ilustrar como pode funcionar uma relação comparável entre programadores e testadores. Mas, primeiro, vejamos uma situação disfuncional.

O navegador não entra no avião, mas acena ao piloto enquanto este descola. O navegador viaja de autocarro, separadamente, mas devagar. Por fim, o navegador chega ao destino, mas, passado algum tempo, descobre-se que o avião voou na direção errada e embateu numa montanha.

Certamente que o navegador deveria estar no avião? Imagine como os pilotos e os navegadores trabalham juntos na realidade.

• O piloto não consegue pilotar o avião sem um navegador. O navegador não consegue pilotar o avião.
• O piloto e o navegador concordam com o plano de voo antes de a viagem começar.
• O piloto descola e pilota o avião.
• O navegador acompanha o percurso e compara-o com o plano de voo e/ou o destino final, tendo em conta acontecimentos adversos, em particular as condições meteorológicas.
• O navegador procura desvios, traça um novo percurso e informa o piloto, que faz ajustes à trajetória de voo.
• E assim por diante.

A relação entre piloto e navegador é comparável à relação entre programador e testador. Separar os programadores e os testadores em equipas distintas que trabalham sequencialmente também não faz sentido. No entanto, é isso que temos feito convencionalmente há cerca de trinta anos — sobretudo em projetos maiores e de mais longa duração.

A antecipação dos testes redistribui a reflexão sobre os testes e, na prática, antecipa-a. Os testadores trabalham como parceiros de pleno direito dos programadores, tal como os navegadores fazem com os pilotos:

• O testador e o programador reúnem conjuntamente informações sobre os requisitos.
• Normalmente, o testador questiona os requisitos através de exemplos (ideias de testes potenciais ou reais).
• O programador pensa na implementação, utilizando os exemplos para orientar o seu desenho.
• O testador, o programador, as partes interessadas, os utilizadores e os analistas chegam a um entendimento partilhado de um requisito fiável.
• O testador comunica constantemente com o programador, discutindo alterações aos requisitos, riscos de falha e a forma como os testes podem demonstrar que as funcionalidades funcionam ou revelar falhas.
• O testador analisa a forma como a funcionalidade em desenvolvimento será integrada, tanto ao nível técnico como ao nível da jornada do utilizador, e como essa integração pode ser testada.
• O testador olha para além da funcionalidade imediata em que o programador está a trabalhar, de modo a identificar desafios, riscos, alterações e incertezas futuras.
• E assim por diante.

A relação ideal entre programadores e testadores descrita acima não acontece automaticamente. Tem de ser construída pela equipa. Pode encarar cada uma das atividades acima como uma intervenção, mas as intervenções nem sempre são confortáveis para todas as partes. Dê a esta abordagem as melhores possibilidades de sucesso discutindo cada tipo de intervenção com os seus parceiros logo no início — quando souber pela primeira vez que irão trabalhar em estreita colaboração.

As intervenções, tal como as boas histórias de utilizador, desencadeiam conversas.

Cada tipo de intervenção requer o acordo de ambas as partes de que se trata de uma ação válida. Para se sentirem confortáveis, ambas têm de confiar uma na outra e reconhecer que existe uma boa razão para fazer perguntas, levantar questões e questionar requisitos ou entendimentos em reuniões diárias, sessões de planeamento ou retrospetivas.

Desafios das equipas distribuídas e subcontratadas

Nas discussões anteriores, partiu-se tacitamente do princípio de que todos trabalham na mesma equipa e estão no mesmo local. Quando a carga de trabalho da equipa de testes de software é subcontratada e/ou transferida para o estrangeiro, entram em jogo vários fatores negativos. A tabela apresenta três fatores típicos a considerar.

Algumas empresas reforçam as equipas de testes de software existentes para desenvolver capacidades para projetos de maior dimensão, ou contratam empresas especializadas em testes em vez de dependerem de prestadores de serviços ou de utilizadores internos para realizar os testes. Noutras situações, todo o desenvolvimento e/ou os testes podem ser entregues a fornecedores. Em todos os casos, a empresa cliente precisa de gerir os seus fornecedores. Isto não significa que seja suficiente redigir um contrato restritivo com cláusulas de penalização severas.

Quando as coisas correm mal, pretende respostas rápidas e colaboração por parte do seu fornecedor; não pretende que este se esconda atrás de cláusulas legais nos contratos.

Os segredos do sucesso são:

• Se não gerir o seu fornecedor, ele irá geri-lo a si (se não forem parceiros completos e deixar o fornecedor definir os termos, este ficará com todas as cartas na mão).
• O objetivo é definir uma boa relação de trabalho. Esta relação deve ser estabelecida a todos os níveis – partes interessadas, gestores e profissionais.
• Os contratos devem ser redigidos de forma a identificar todas as responsabilidades de ambas as partes, definindo medidas, limiares, pagamentos por etapas e critérios de aceitação adequados, de modo a incentivar bons comportamentos (de ambas as partes do acordo).
• Os acordos devem incentivar a abertura e o compromisso com o objetivo partilhado de sucesso do projeto.

Para refletir

E, finalmente, algumas perguntas para o fazer pensar. 

Que relação tem, enquanto testador, com os seus programadores? Ou, se é um programador a ler isto, que relação tem com os testadores? Talvez possa perguntar aos seus parceiros de desenvolvimento ou de testes como descreveriam a vossa relação. Compare as respostas!

Para que as equipas de testes de software sejam produtivas, têm de comunicar e colaborar.