Adotar testes de aceitação pode ser uma boa estratégia para manter um ciclo de desenvolvimento de software mais consistente e com foco na qualidade. Porém, dentro de um contexto ágil, é primordial que o tempo de implementação desses testes não impacte no cronograma de entrega da funcionalidade, bem como que a arquitetura de código adotada esteja em conformidade com as diretrizes técnicas da empresa.
Este artigo demonstra como você pode usar a StackSpot AI para acelerar a construção de testes de aceitação, trazendo mais eficiência e padronização de código para o projeto.
O que é teste de aceitação?
Teste de Aceitação (ou Teste de Aceite) é uma descrição formal do comportamento esperado de um produto de software, expresso como um cenário de uso. Uma equipe de controle de qualidade conduz testes de aceitação para garantir que o software ou aplicativo atenda aos requisitos de negócios e às necessidades do usuário final.
Os testes de aceitação permitem que uma organização envolva a área de negócio no processo de teste e colete seus feedbacks para transmitir à equipe de desenvolvimento. Esses feedbacks ajudam o controle de qualidade a identificar falhas que podem ter passado despercebidas durante os testes do estágio de desenvolvimento, como os testes unitários, por exemplo.
Além disso, os testes de aceitação ajudam as pessoas desenvolvedoras a compreender as necessidades comerciais de cada funcionalidade do software testado.
O que é Acceptance Test-Driven Development (ATDD)?
O Acceptance Test-Driven Development (ATDD) em inglês, é uma metodologia de desenvolvimento que aborda a escrita de testes de aceitação antes da implementação da funcionalidade correspondente, mesmo princípio do Test Driven Development (TDD). Esses testes representam o ponto de vista da pessoa usuária e atuam como uma forma de validação, verificando se o sistema funciona conforme o pretendido.
O ATDD é uma prática colaborativa, por isso envolve pessoas da equipe com diferentes papéis, por exemplo, Product Owners (POs), pessoas desenvolvedoras e QAs colaborando para escrever critérios de aceite. Posteriormente, esses critérios serão transformados em testes de aceitação para validar os diversos cenários de uso do sistema. Estes testes entram no ciclo de “Falha — Refatoração – Sucesso”, até a entrega final.
Principais benefícios do Acceptance Test-Driven Development (ATDD)
- Identificação antecipada de problemas: Ao criar testes de aceitação para cada requisito ou história de usuário, os defeitos podem ser identificados mais cedo no processo de desenvolvimento.
- Redução de retrabalho: Ao identificar defeitos mais cedo, o retrabalho pode ser reduzido, economizando tempo e recursos.
- Entendimento dos requisitos: Refinar os testes de aceitação ajuda a entender e esclarecer os detalhes dos requisitos com antecedência, em vez de descobrir requisitos pouco claros apenas na metade do código.
- Aumento da cobertura de testes: Ao focar na cobertura de testes no nível de aceitação, o ATDD ajuda a melhorar a cobertura geral de testes e garante que funcionalidades críticas sejam exaustivamente testadas.
- Satisfação de clientes: Ao criar testes de aceitação para cada requisito ou história de usuário, o foco é mantido na satisfação do cliente e em atender às suas necessidades.
Definição dos Critérios de Aceite
Os Critérios de Aceite são escritos em paralelo à criação das User Stories, em uma parceria do QA com o PO do projeto. A escrita dos cenários segue o padrão Gherkin, técnica de padronização de escrita de especificações de testes baseada no Behavior-Driven Development (BDD).
| Critérios de Aceite Cenário: 1 – Pesquisar por produto existente Dado que a pessoa usuária acessa a página inicial Quando pesquisa por um produto existente Então a pesquisa retorna o produto com sucesso Cenário: 2 – Pesquisar por produto inexistente Dado que a pessoa usuária acessa a página inicial Quando pesquisa por um produto inexistente Então a pesquisa retorna a seguinte mensagem: “Produto não encontrado.” |
Na tabela acima é possível ver dois exemplos de critério de aceite escritos no padrão Gherkin, cada um com três Steps (Dado, Quando e Então).
Refinamento com o time
O próximo passo é refinar os critérios de aceite com o time, verificando se todos os comportamentos esperados estão mapeados.
- POs revisam com olhar no negócio;
- pessoas desenvolvedoras revisam com olhar mais técnico, já pensando na arquitetura que atenderá tais requisitos;
- QAs revisam com foco em qualidade, na criação dos testes de aceite.
Após concluir o refinamento e iniciar a implementação da feature, é hora de transformar os critérios de aceite em testes automatizados, os quais validarão a entrega da funcionalidade.
A seguir, entenda o que é a StackSpot AI e como este produto pode ajudar a acelerar a criação de testes de aceitação.
Conheça a StackSpot AI
StackSpot AI é um assistente de código que usa um contexto (Stack AI) e fontes de conhecimento (Knowledge Sources) para produzir código com qualidade e de forma assertiva. Através de uma linguagem natural, qualquer pessoa desenvolvedora é capaz de utilizá-lo para gerar código baseado nos padrões definidos pela empresa.
A StackSpot AI armazena as preferências e necessidades das pessoas usuárias de código e documentações a partir de fontes de conhecimento pré-configuradas, conhecida como Stack AIs, Knowledge Sources e Quick Commands. Mais especificamente:
- Stack AIs – grupos de tecnologias declarativas para dar mais contexto a LLM;
- Studios – responsáveis por agrupar as Stacks AIs conforme suas finalidades;
- Knowledge Sources – que possibilitam a geração de código contextualizado com base em trechos de código e APIs pré-cadastrados;
- Quick Commands – comandos rápidos personalizados para trechos de código e ações de uso frequente.
Após estas definições, a StackSpot AI, utiliza de um Large Language Model (LLM) para conhecer a partir disso, para construir trechos de código, funções padronizadas, textos técnicos e até mesmo testes automatizados, altamente contextualizados.
Utilizando a StackSpot AI
Studio
Depois de autenticar, é preciso criar um Studio para armazenar a Stack AI que será utilizada nos testes, conforme exemplo abaixo.
Stack AI
Em seguida, cadastrar uma Stack AI associada ao Studio recém-criado. Foi criada, por exemplo, uma Stack com as seguintes definições: linguagem de programação JavaScript, framework Cypress e Cucumber BDD para construção de testes end-to-end.
Como se trata de testes automatizados, o campo Observability pode ser desconsiderado.
Knowledge Source
O próximo passo é cadastrar uma Knowledge Source do tipo Snippets Group. Os Snippets são trechos de código customizados e padronizados, no qual a StackSpot AI utilizará como referência para gerar um código contextualizado.
Acima, por exemplo, foi criado um Snippet com um Custom Command do Cypress que realiza a comparação entre dois valores, na linguagem JavaScript.
Quick Commands
Para dar ainda mais celeridade à implementação do código dos testes, foi criado um Custom Quick Command do tipo Prompt, conforme visualizado abaixo.
A forma de interação selecionada foi via Chat, dessa forma, o StackSpot AI deposita o resultado dentro da própria conversa.
Lembrando que o Quick Command deve ser associado à Knowledge Source e publicado no Studio criados anteriormente.
Workspace
Por fim, basta criar um Workspace associando a ele todos os artefatos criados anteriormente: Stack AI, Knowledge Sources e Quick Command.
Implementando os testes de aceite com StackSpot AI
StackSpot AI Extension
O StackSpot AI fornece um plugin para integrá-lo ao ambiente de desenvolvimento (IDE), tanto no IntelliJ, como no Visual Studio Code (VS Code). Para aplicar o exemplo proposto, foi instalada a extensão para VS Code, conforme imagem abaixo.
Selecione o Workspace e a Stack AI criadas anteriormente.
Dessa forma, é só adicionar os critérios de aceite em um arquivo de texto, selecioná-los e, com o botão direito do mouse, utilizar o Quick Command criado para gerar o código necessário.
Como resultado, a StackSpot AI construiu, primeiramente, o arquivo de feature com os testes de aceite seguindo o padrão do Cucumber.
Em seguida, disponibilizou o código JavaScript necessário para execução dos steps dos testes, seguindo os padrões pré-determinados na Knowledge Source.
Por fim, ele ainda forneceu as informações necessárias para instalar e configurar as dependências do projeto, nos arquivos index.js e cypress.json
Assista ao tutorial em vídeo:
Conclusão
A proposta do ATDD é, portanto, favorecer uma colaboração maior entre todos os envolvidos no desenvolvimento de um produto. Isso resulta em um entendimento mais claro dos requisitos que serão desenvolvidos durante uma sprint. Além disso, ele contribui com o aumento gradativo da cobertura de testes automatizados, já que novos testes serão implementados conforme novas features são entregues.
Entretanto, é preciso garantir que os testes de aceitação automatizados estejam prontos antes da funcionalidade a ser testada, é nesse momento que a StackSpot AI se torna uma boa alternativa para acelerar a implementação desses testes, reduzindo o tempo de codificação do QA.
Além do código do cenário de teste, a StackSpot AI disponibiliza todos os passos necessários para instalar e configurar as dependências do projeto, orientando o QA sobre a estruturação do código conforme documentação e padrões do framework de testes adotado.
Portanto, unir o ATDD com a StackSpot AI para construção de testes de aceitação pode ser uma boa estratégia para redução do tempo e do esforço de codificação, além de garantir uma entrega mais consistente e de qualidade, conforme padrões pré-determinados pela empresa.
Referências
- Acceptance Test-Driven Development (ATDD), passo a passo – InfoQ
- Acceptance Test Driven Development (ATDD) – Agile Alliance
- About StackSpot AI | Documentação StackSpot AI
- ATDD by Example: A Practical Guide to Acceptance Test-Driven Development por Markus Gärtner
- Jornada Ágil de Qualidade: Aplique técnicas de qualidade no início do ciclo para implantação contínua de software por Antônio Muniz e outros.
- StackSpot AI: Key Concepts | Documentação StackSpot AI
- StackSpot AI: hyper-contextualized code generation | Blog StackSpot
