Entender as necessidades do usuário é extremamente importante para o sucesso de um produto. Mas requisitos exaustivos, além de trabalhosos, não garantem a correta implementação das necessidades dos usuários. Quando mal escritas, tais especificações podem precisar de intermediários no processo de tradução desses artefatos. E quando longas, as descrições acabam transformando o processo de testes num gargalo na entrega das funcionalidades (feature), visto que o time da qualidade irá executar todos os cenários que cubram os requisitos escritos.
Quando se fala em requisito, normalmente, se associa à história de usuário (user story), mas história de usuário é apenas uma forma de materializar os requisitos. Em equipes ágeis, é extremamente comum a busca pela documentação apenas quando necessária, cabendo ao time utilizar formas produtivas de entregar mais funcionalidades com código claro e testes que sirvam como documentação. Com o amadurecimento da cultura ágil, as histórias de usuários passaram a ser escritas de forma simplificada, curtas o suficiente para caberem num pequeno bloco de notas (post-it).
Normalmente, os desenvolvedores não costumam confiar nas documentações do projeto, visto que nem sempre estão completas ou atualizadas. Por isso, o mercado vem buscando formas de desenvolver documentações mais úteis, cuja execução esteja completamente atrelada ao estado atual da funcionalidade, exigindo atualização sempre que alguma mudança acontecer.
No aspecto operacional de gerenciamento de requisitos, uma técnica muito importante, que vem ganhando espaço em equipes multidisciplinares (squads), é o teste de aceitação (acceptance testing), que influencia diretamente no processo de design do produto, tendo como objetivo não apenas garantir a qualidade das funcionalidades entregues, mas também a existência de uma documentação de requisitos para o que o dono do produto designou como importante.
Aceitação é uma fase do processo de engenharia que tem como objetivo verificar se o escopo de uma aplicação está sendo executado com sucesso antes da disponibilização de uma nova versão (release). Os testes nessa fase são executados num ambiente que simula o ambiente real do usuário. Os testes de aceitação não precisam abranger todos os aspectos da funcionalidade a ser implementada, mas devem ser sucintos o suficiente para serem claros para o time de desenvolvimento sobre o que o dono do produto espera.
Como boa prática, algumas características não são negociáveis. Uma delas é manter histórias com testes de aceitação, já que é esperado que todas elas devam ter um número mínimo de testes aprovados pelo dono do produto.
Tais testes ou cenários de testes precisam estar prontos, antes do desenvolvimento da funcionalidade, pois eles servirão de referência para o que será implementado, seguindo a ideia do BDD (Behavior Driven Development).
Como implementar:
By the book, uma vez que o backlog do produto é criado com os seus respectivos itens (histórias), cabe ao profissional da qualidade ou qualquer outro responsável por especificar os requisitos, escrever no verso do cartão de cada história as condições mais importantes da funcionalidade. Essa técnica evita o retrabalho muitas vezes encontrado em modelos tradicionais de desenvolvimento de software, onde o engenheiro de requisitos transcreve toda a especificação e, só depois, os testes são criados para essa especificação, havendo uma redundância de informações.
Diferentemente dos testes oriundos do TDD (Test Driven Development) — unitários e integração — , os testes de aceitação concentram-se nas regras de negócio e não precisam ser exaustivos — com milhares de cenários — , mas devem, sim, conter a representação do fluxo que o usuário faria em produção, garantindo a qualidade aceitável determinada pelo time.
Assim como a criação das histórias, os cenários de testes precisam ser independentes, pois isso fará com que um teste falho não interfira no resultado de um outro teste.
Os testes de aceitação auxiliam o dono do produto a priorizar quais defeitos (bugs) devem ser corrigidos, já que, quando executados com frequência, apontam para o time quais defeitos ou falhas foram inseridos durante o desenvolvimento.
Não obrigatoriamente, mas fortemente recomendável, tais testes podem ser automatizados e entregues no ciclo de integração das funcionalidades. A automação traz para o projeto a possibilidade da adoção do processo de regressão (regression testing), executando os testes sempre que uma nova versão for disponibilizada ou quando novas funcionalidades forem integradas às já existentes. A automação dos testes pode representar um esforço grande no início da implementação, mas pode resultar em uma grande redução de custos a longo prazo, já que as validações manuais acabam tendo um escopo menor e bugs são detectados antes da liberação de novos códigos.
A escrita e boas práticas:
As ideias voltadas para o produto nem sempre nascem de um profissional da computação que entende de código, por isso, a linguagem utilizada para a escrita dos testes deve ser uma linguagem de alto nível — linguagem de negócio.
A escrita de um cenário de teste deve sempre responder as seguintes perguntas:
- É de fácil entendimento?
- Demanda muito tempo para leitura?
- É abrangente sem ser exaustivo?
- Você sabe o que está construindo nesse teste?
- Qual o valor que esse teste agrega?
Periodicamente, os testes precisam ser revisados, já que funcionalidades tendem a ser removidas ou alteradas. Usando testes de aceitação, não apenas o time de desenvolvimento, mas também os clientes se sentem mais confiantes no produto entregue, uma vez que testes foram executados para as funcionalidades solicitadas.
