Antes de mais nada, você precisa saber que não existe uma fórmula padronizada para a elaboração de testes de software. Assim, cada caso é um caso. Nesse cenário, faz-se imprescindível conhecer algumas questões que podem facilitar — e muito! — o processo de estabelecimento de um roteiro próprio para decidir se seu software está pronto para ser testado. Ficou curioso para saber que questões são essas? Então confira já nosso post:

Falando a mesma língua

Se os membros da sua equipe — interna ou terceirizada — estão todos usando as mesmas ferramentas, os mesmos métodos e processos no desenvolvimento do software, primeiramente temos que dizer que você é muito sortudo e, em segundo lugar, que esta seção não é para você. Pode pular para a próxima.

Como este raramente é o caso, o mais provável é que seus profissionais tenham experiências em diferentes métodos de desenvolvimento — cascata, orientado a testes (prototipação), incremental, interativo, ágil e assim por diante. Nesse cenário, trate de eliminar, o mais cedo possível, o ruído da comunicação entre os envolvidos nas tarefas de desenvolvimento, certificando-se de que todos entendem plenamente o resultado esperado. Para garantir, você pode inclusive pedir que eles mesmos expliquem o que lhes foi pedido, com suas próprias palavras. Os resultados podem ser até divertidos!

Alinhando as expectativas

Seu documento de requisitos — ou equivalente — deixa tudo muito claro sobre o software? Nem sempre, certo? Pois então cabe a você estender o processo de verificação da comunicação citado no tópico acima para cobrir cada um dos requisitos e o que você espera que sua equipe faça com eles.

Um profissional com experiência em Test Driven Development ou Desenvolvimento Orientado a Testes (TDD) vai começar pensando em testes, já um desenvolvedor ágil vai pensar em testes por último. Como responsável pelo processo, é você quem vai definir quando a equipe vai mudar o foco do desenvolvimento para passar para os testes.

Analisando pontos essenciais

Ok, então chegaram todos aqui falando a mesma língua e você deixou bem claro o que espera de cada um dos membros da equipe. Agora chegou o momento de conhecer um conceito dentro das metodologias ágeis que é útil de várias maneiras diferentes: o Definition of Done (DoD) ou Definição de Pronto.

Essa definição é simplesmente uma lista de atividades — escrever código, incluir comentários, preparar documentação, executar testes de unidade, testes de integração e por aí vai — que adicionam ao produto um valor que pode ser devidamente verificado e demonstrado. Tendo ou não familiaridade com esse conceito, você vai ver como fica fácil, utilizando-o como ferramenta, dizer se realmente chegou a hora de parar de escrever o código e passar para os testes.

Entendendo as definições de prontidão

As Definições de Pronto (DoD) podem ser escritas em vários níveis:

• DoD para uma funcionalidade: item do backlog ou da história do usuário
• DoD para uma entrega: conjunto de funcionalidades com data de conclusão
• DoD para uma versão: potencialmente pronto para a produção

Dica: se sua empresa tercerizar os testes, envolva os profissionais de teste o mais cedo possível no processo de definição. Dessa forma, não se aproveita só o feedback de sua experiência na descrição e definição de testes, como também os inclui no alinhamento de comunicação e de expectativas.

Porém, independentemente de executar testes com terceiros, equipe interna especializada, na programação em pares ou com um programador solitário, debater as atividades de teste durante a preparação da sua Definição de Pronto permite conhecer, de antemão, o momento em que seu software está pronto para ser testado.

Fica a seu critério incluir ou não na Definição os pré-requisitos dos testes — infraestrutura de integração, bancos de dados de teste, software de teste e seus respectivos responsáveis. Se a complexidade do seu sistema e de suas integrações crescer demais, pode ser interessante simplesmente citá-lo na Definição de Pronto e colocar os detalhes em um plano de testes separado.

Observando os gargalos do processo

Agora que seus DoDs registram por escrito as atividades que você definiu com sua equipe, é hora de ficar atento a qualquer gargalo no processo. Os percalços no desenvolvimento das atividades podem conter indicadores de que alguma tarefa estava atrasada ou adiantada em relação às atividades de teste, demonstrando que alguma funcionalidade ainda não estava pronta para ser testada. Mas agora você tem um histórico que pode ser revisto em vários níveis para fazer a sintonia fina do seu processo a fim de executá-lo com mais eficácia da próxima vez.

Precisa de uma equipe para testar a sua aplicação? Clique aqui para agendar uma conversa.