QA - Como é que testam Microserviços (Testes Automáticos)?

[willie22]

Sou QA Lead e uma das tarefas da minha equipa é desenvolver Testes Automáticos a Microserviços.

Temos testado estes Microserviços com sucesso há mais de uma ano. Resumidamente, o nosso Processo de Testes é:

1. Analisar a documentação
2. Normalmente o output do Microserviço irá variar de acordo com cerca de 6 combinações de input. Escrevemos as Especificações para esses 6 Cenários de Teste
3. Produzir mensagens com os nossos Dados de Teste para os source Topics utlizando uma REST API
4. Os Microserviços irão consumir e processar as mensagens de input, mapear os campos, agregar/transformar os dados, realizar cálculos e produzir as mensagens de output
5. Consumir as mensagens dos Tópicos de output usando a REST API e realizar as asserções

Informação adicional: Os Developers são responsáveis pelos Testes Unitários. A Equipa de QA é responsável pelos Testes Funcionais, de Integração, de Performance e Exploratórios. Os nossos Testes Automáticos já estão integreados no Workflow de CI/CD.

No entanto, a empresa está a migrar de Docker para Kubernetes, iremos usar uma REST API diferente, por isso os Testes serão refatorizados. Por este motivo, antes da refatorização, a Equipa de DevOps atirou uma ideia para o ar: E se alterássemos o Paradigma de Testes e, em vez de desenvolver Testes Automáticos de Microserviços, a Equipa de QA desenvolvesse "Microserviços de Testes"? Estes "Microserviços de Testes" iriam correm no Ambiente de Produção e validar todas as mensagens geradas. Na minha opinião isto vai contra todas as boas Práticas de Testes mas gostava de ouvir a vossa opinião.

1. Desenvolver Microserviços é uma Tarefa de Desenvolvimento, não é uma Tarefa de QA~
2. Teríamos o dobro dos Microserviços em Produção (faria mais sentido correr estes "Microserviços de Testes" em Staging mas eles disseram Produção)? Isto iria degradar imensamente a performance do servidor
3. Qual é o objetivo? Não vejo nem benefício em fazer isto, apenas desvantagens

Para além disso, os nossos Testes Automáticos de Microserviços também poderiam fazer isto, não precisamos de desenvolver "Microserviços de Teste". Mas mais uma vez, apenas existem desvantagens. Cada Microserviço gera dezenas de milhares de mensagens diariamente. Para que é que iríamos realizar dezenas de milhares de Requests para cada Microserviço, quando os Cenários de Teste já foram identificados e o output irá variar de acordo com meia dúzia de combinações? Podemos fazer a mesma tarefa com apenas 6 Requests, evitando, desta forma, a degração da performance do servidor.

Concordam comigo? Desde já, obrigado pelo vosso input.

 

[Ne_]

Aqui vão os meus 5 cents neste assunto. A abordagem que descreves parece-me a mais comum e mais utilizada. O processo de testes deve começar o mais cedo possivel, validações manuais devem ser feitas antes da automação e dps ter uma bateria de regressão sempre atualizada associada a um serviço de CI/CD. Os testers devem ter tempo para efetuar testes exploaratórios.
Criar microserviços para testar micorserviços acho que só vai trazer uma camada adicional de complexidade ao processo, para não falar que podem ter muitos mais pontos de falha por causa dessa abordagem. Então se, como referes, todos requests em prod são testados... é um overhaed gigante e na minha perspestiva não traz ganhos nenhuns. Até percebo que a bateria de regressão possa ser corrida contra prod numa base diária ou semanal. Agora todos os requests, acho que não faz sentido.
Se pretendem agilizar o processo, e não sabendo eu qual a vossa stack de automação, pergunto se usam ou já poderaram contract testing?

 

[OubeLa]

Não concordo com o que dizes sobre não ser responsabilidade dos QAs fazer microsserviços. Os QAs devem fazer o que for preciso para assegurar a qualidade. O conceito de fazer testes pode passar por fazer código. Além disso não vejo como isso iria afectar a performance do ambiente, porque pelo que dizes trabalhas com o Kubernetes e então o cluster iria escalar para suportar esse número de microsserviços. Sendo um message based architecture provavelmente irias ter apenas mais um consumer a consumir os tópicos, algo perfeitamente escalável e previsto pelas ferramentas tipo Kafka e afins.

Agora, se faz sentido? Diria que não. Pelo menos pelo use case que apresentas parece que vocês estão a fazer mais checks do que testes. Pelo menos pela forma como referes de ter isso a correr no ambiente de produção.

Diria que a tua anterior abordagem é a que faz mais sentido, se muda apenas a REST API, é adaptar os testes. A menos que vocês por qualquer outro motivo que não apresentes aqui no use case achem que os testes não estão escaláveis ou robustos o suficiente.

O que fará sentido é vocês definirem claramente a vossa estratégia macro de testes. Numa arquitectura de microsserviços a estratégia macro é super importante para perceber que sistema testa o quê. "Eu, serviço A, testo-me a mim isolado e a minha integração com o sistema B". Contract testing pode ser uma boa hipotese para estes cenário. Em relação a testes especificos para message based systems acho que ainda mais sentido embora as ferramentas possam ser diferentes.

A única vantagem que eu vejo em ter serviços que validam outros serviços (neste caso as mensagens nos topics produzidos pelos consumers) é se isso for um requisito de negócio de alguma maneira que não consigas cobrir com testes a executarem periodicamente ou com monitoring+alerting. Isto é, se por algum motivo precisares de continuamente validar tudo contra uma qualquer especificação e se essa monitorização não conseguir ser feita pelos meios tradicionais de monitoring+alerting.