“Esta API é simples, não há necessidade de tantos testes”.

Todo mundo está feliz. O product owner pode entregar rapidamente, o desenvolvedor testa sozinho e não há necessidade de envolver o controle de qualidade ou um arquiteto.

Embora essa abordagem funcione para APIs localizadas, não funciona para as críticas.

As APIs são os pneus na estrada: o único elo que garante processos entre sua empresa e outras do ecossistema.

Alguns deles podem oferecer suporte a operações internas em execução 24 horas por dia, 7 dias por semana, e muitos oferecerão suporte direto à experiência do usuário.

Qualquer degradação faz com que perca um usuário em potencial, daí a necessidade de testes contínuos de API com Quality Engineering para permanecer com Quality at Speed.

Segue a QE Unit para mais conteúdo exclusivo de Quality Engineering.

Comece com o porquê, para quem, depois o que

APIs costumam ser vistas como meras camadas técnicas e intermediárias.

Mas as APIs são usadas em todos os lugares para resolver um problema do usuário final: enviar dados para uma plataforma de análise, recuperar uma lista de produtos e passar um pedido.

As APIs devem, portanto, responder às necessidades de determinadas personas.

O primeiro antes da codificação é identificar os usuários-alvo, suas necessidades e casos de uso associados. Só a partir daí o desenho técnico pode começar.

A primeira verificação da Quality Engineering já pode ser feita nessa fase: garantindo os casos de uso, dicionário de dados, padrão de API e design de endpoints.

Construir e validar a Minimum Viable API

O desenvolvimento de API pode começar a partir de usuários bem definidos e casos de uso associados. Mas os resultados devem aparecer rapidamente.

Uma implementação de túnel da API completa criará uma distância entre o produtor e o consumidor de APIs, aumentando o risco de divergência.

Os stubs de API mais simples devem ser criados nesse estágio para obter feedback antecipado dos usuários sobre o valor fornecido.

Esses mocks podem ser feitos usando uma descrição swagger para uma API REST, por exemplo. Certifique-se de integrar requisitos não funcionais, como autenticação.

É na integração da API que a maioria dos problemas são descobertos, gerando retrabalho significativo e tempo de espera entre as equipes.

Entregue a API com integração de ponta a ponta antecipada 

Podemos temer publicar uma API que não esteja totalmente concluída. Os usuários receberão bugs, levantarão problemas e questionarão nossas competências.

Uma integração de API antecipada pode levantar problemas cedo para resolvê-los mais rapidamente com custos mínimos. Pode até descobrir que mudanças na estrutura são necessárias.

Essa é a realidade com a qual o design deve ser confrontado.

Encare a realidade como ela é, não como ela era ou como deseja que ela seja.

—Jack Welch

Portanto, precisa implantar sua API em ambientes que permitem que ela interaja diretamente com os consumidores no ambiente de produção.

Verá e resolverá todo um conjunto de problemas rapidamente com uma API simples, melhorando o design e a robustez do seu produto para continuar iterando com velocidade.

Garantir a melhoria sistemática dos portões de qualidade

Não construímos muros uma vez que as fundações de uma casa não estão estabelecidas. Então, por que fazer isso ao criar APIs?

A implementação da cadeia de entrega de software para iteração rápida na API é necessária para adaptar continuamente as APIs em ciclos curtos posteriormente.

Não comece tentando implementar todos os endpoints e casos de uso de APIs.

Concentre-se na implementação dos pipelines de CI/CD em todos os ambientes, incluindo portas de qualidade mínima que lhe dão confiança para realizar as principais alterações.

Dessa forma, tem todas as bases para realizar incrementos rápidos de suas APIs para aumentar seus requisitos funcionais e não funcionais.

Feche o ciclo de feedback verificando a utilidade

Depois que sua API estiver pronta, implantada sistematicamente por meio de portões de qualidade em CI/CD, uma pergunta permanece: Estamos criando valor?

As APIs existem em primeiro lugar para resolver as necessidades das personas. É seu trabalho garantir que eles sejam atendidos e que seja capaz de aumentar sua proposta de valor.

Essa é a área de observabilidade, análise e crescimento de APIs.

A maioria dos portais de APIs disponíveis fornece um conjunto de métricas de uso de APIs. Sua responsabilidade é calculá-los, mas fazer uso deles.

É apenas o início de sua jornada de API, pois precisará iterar para melhorar sua proposta de valor. É por isso que precisa de Quality Engineering

Restringir seu pipeline de API para o Quality at Speed

O Quality Engineering é o paradigma para restringir o ciclo de vida do software à entrega contínua de valor.

Cobrimos as várias etapas envolvidas na construção de APIs, desde o design até a análise, terminando nas fases de melhoria contínua.

Os elementos implementados não estavam ali por beleza ou perfeccionismo; eles são necessários para manter a iteração com Quality at Speed a longo prazo, se necessário.

As verificações iniciais são mínimas em documentação e stubs, compartilhando com os usuários, para dinamizar rapidamente, se necessário, sem consumir nenhum recurso de desenvolvimento.

Esse é o poder do Quality Engineering, restringindo gradualmente o ciclo de vida do software à máxima Qualidade, Velocidade com o mínimo de Complexidade.

Coisas simples não são necessariamente fáceis.