/projects/dell-automated-caller

Dell Automated Caller

Teste end-to-end automatizado de um sistema de telefonia.

Concepção, arquitetura e implementação · 2020

.NET CoreRabbitMQEntity FrameworkTwilioxUnit

Privado

Captura de tela de Dell Automated Caller

Visão geral

Uma ferramenta interna que testa uma URA ligando de verdade para ela — a suíte disca o menu telefônico, ouve o que ele diz, confere contra o esperado e registra o resultado junto com o resto da suíte.

O que eu fiz

Concebi a ferramenta e a construí, e depois fui mentor do engenheiro júnior que entrou no projeto.

A linguagem de roteiro de teste e o validador que rejeita roteiro ruim antes de custar uma ligação.
Asserção por similaridade, com o limiar declarado em cada passo.
A fila entre a requisição e a ligação.
A integração de telefonia e o webhook que traz cada resposta transcrita de volta.
O reporte dos resultados de volta para a ferramenta de gestão de testes.

O problema

Testar um menu telefônico significava alguém discar, apertar as teclas, ouvir o que o sistema dizia e anotar se estava certo — uma vez por cenário, por idioma, por rota. Um ciclo completo eram mais de vinte mil ligações feitas à mão pelo time, o que na prática significava que o ciclo completo quase nunca rodava. Automatizar reduziu o ciclo para cerca de três horas.

Em números

Volume de ligações e tempo de ciclo conforme lembrados do projeto; a contagem de comandos é verificável no código.

20 mil+ligações por ciclo de testeantes, uma a uma, à mão, pelo time

~3hpara rodar o ciclo inteiroantes levava cerca de um mês

9comandos na DSL de testeo roteiro é validado antes de qualquer discagem

Arquitetura

Um serviço .NET Core em camadas DDD. A API recebe um roteiro; um validador rejeita roteiro malformado antes de gastar uma ligação; a execução é despachada por uma fila publish/subscribe no RabbitMQ; um provedor de telefonia faz a chamada e devolve cada resposta transcrita por webhook; a resposta é pontuada contra o que o roteiro esperava; e o resultado volta para a ferramenta de gestão de testes, amarrado aos identificadores de plano, suíte e item de trabalho.

Test scriptUma lista ordenada de comandos descrevendo uma ligação.
ValidatorRejeita roteiro malformado antes de qualquer discagem.
QueuePublish/subscribe, então uma ligação lenta não trava a requisição.
Telephony providerFaz a chamada e devolve cada resposta transcrita.
Test managementRecebe o resultado amarrado ao plano, à suíte e ao item de trabalho.

Um roteiro de teste

Setup Language="en-US"
Dial +1 (000) 000 0000
Wait 3
Hear [Confidence=85%] thank you for calling, please say or enter your service tag
Enter (serialnumber) 1234567#
Hear [WaitBefore=2] one moment while I look that up
Hang

A gramática é conferida antes da ligação: um Dial ou Hang ausente, um passo repetido onde só cabe um, ou um passo fora de ordem reprovam o roteiro em vez da conta de telefone. Os passos de validação rodam depois que a chamada termina. O número acima é um placeholder de documentação.

Um ciclo de teste

À mão~1 mês

Automatizado~3 horas

Durações conforme lembradas do projeto; o repositório não as registra.

O que um passo registra

Esperado	Ouvido	Similaridade
please enter your service tag	please enter your service tag	100%
one moment while I look that up	one moment while i look that up	97%
transferring you to support	transferring you to sales	78%

Estrutura do modelo real — toda resposta falada é guardada com o que se esperava, o que foi transcrito e o quanto os dois bateram. Os valores aqui são ilustrativos.

O que faz

Um roteiro de teste é uma lista curta de comandos ordenados: discar, esperar, digitar, ouvir, validar, desligar.
Placeholders no roteiro são substituídos em tempo de execução, então um roteiro cobre muitos conjuntos de dados.
Toda resposta falada é guardada com o que se esperava, o que foi ouvido e o quanto os dois bateram.
Os resultados voltam para a ferramenta de gestão de testes amarrados ao plano, à suíte e ao item de trabalho a que pertencem.
Um roteiro malformado é rejeitado com uma lista legível de erros antes de qualquer ligação.

Decisões de engenharia

Asserção por similaridade, com o limiar declarado em cada passo
Transcrição de fala nunca é exata caractere a caractere, então comparar por igualdade reprova bons testes. Cada asserção carrega sua própria tolerância no roteiro, porque o quão perto a transcrição chega depende do que foi dito — um prompt padrão transcreve de forma confiável, um nome de produto não.
O roteiro é uma linguagem pequena, validada antes de qualquer discagem
Uma ligação real custa tempo e dinheiro e não dá para desfazer. O validador confere que os comandos obrigatórios estão presentes, que os de uso único aparecem uma vez, que a ordem é válida e que cada linha bate com sua gramática — reportando cada erro em linguagem clara antes do primeiro dígito discado.
Uma fila entre a requisição e a ligação
Uma ligação telefônica leva minutos e falha por motivos fora do controle de quem chamou. Publish/subscribe desacopla quem pediu a execução de quem a executa, então uma ligação lenta ou falha nunca trava a requisição que a iniciou.
Conferir mais que o áudio
Ouvir as palavras certas não prova que a ligação foi roteada corretamente. Passos de validação separados conferem o menu de voz, o roteamento telefônico e os registros que os dois deixaram — e é isso que faz dele um teste end-to-end em vez de uma asserção sobre áudio.