Como profissional de controle de qualidade , criar um novo usuário para teste de produto pode parecer uma tarefa simples – basta preencher o formulário de registro e pronto. No entanto, e se você precisar testar um usuário com um histórico de mensagens de um ano ou avaliar como um recurso de serviço de vídeo funciona para um determinado grupo de teste A/B? Essas situações podem rapidamente se tornar tediosas e demoradas ao criar usuários manualmente.
Neste artigo, compartilharemos nossa jornada de desenvolvimento de uma ferramenta que automatiza totalmente esse processo. Vamos mergulhar!
Apresentando nossa ferramenta de gerenciamento de usuários
No Social Discovery Group, fornecemos serviços online que conectam pessoas ao redor do mundo. Nossos produtos permitem que os usuários se comuniquem por meio de bate-papo e vídeo e compartilhem conteúdo de mídia. À medida que nossos produtos evoluíram, começamos a encontrar cenários de teste cada vez mais complexos. Por exemplo, precisávamos examinar o perfil de um usuário com uma assinatura expirada ou analisar a funcionalidade de uma lista de contatos com mais de 30 entradas.
Para gerar um usuário "rico em histórico", tivemos que executar várias consultas de API, enviar mensagens para o RabbitMQ e executar scripts SQL. Como essas etapas já foram incorporadas aos nossos testes automatizados, a equipe de controle de qualidade manual frequentemente nos pedia para realizar um teste automatizado para criar o usuário necessário. Com o tempo, a criação de um único usuário passou a demorar mais do que o próprio teste. Portanto, decidimos encontrar uma maneira de capacitar qualquer funcionário para lidar com o processo de criação do usuário de forma independente.
Nossa automação de teste é escrita em C#. Utilizamos ativamente chamadas de API para nossos recursos de aplicativos em testes automatizados. Por exemplo, usamos o seguinte método para registro de clientes:
var client = new Client(); RegisterClient(client, param1, param2, param3);
Depois de analisar nosso framework, concluímos que a solução mais fácil para criar os usuários necessários para testes seria desenvolver uma aplicação ASP.NET Web Forms usando nossos métodos. Imaginamos um site que os testadores de QA pudessem usar para criar facilmente os usuários necessários.
Aqui está o que fizemos:
Primeiro, adicionamos uma página para criação de usuários. Os testadores podiam selecionar parâmetros adicionais e configurar o usuário de acordo com suas preferências – seja como um novo usuário ou com um longo histórico de chats.
Veja como ficou o processo:
Aqui está o código da página, incluindo o elemento de saída.
<%@ Page Language = "C#" AutoEventWireup = "true" CodeBehind = "WebForm1.aspx.cs"
Inherits = "Habrl.Pages.Registration.RegistrationForm1" %> <!DOCTYPE html> <html xmlns = "http://www.w3.org/1999/xhtml" > <head runat = "server" > <title></title> </head> <body> <form id = "registration" runat = "server" > <div> <div> <label>Client type:</label> <asp:DropDownList ID = "clientType" runat = "server" AutoPostBack = "true"
CssClass = "select" OnSelectedIndexChanged = "clientType_OnSelectedIndexChanged" > <asp:ListItem value = "regularClient" Selected = "True" >Regular client</asp:ListItem> <asp:ListItem value = "clientWithChatHistory" >Client with chat history</asp:ListItem> <asp:ListItem value = "inactiveClient" >Inactive Client</asp:ListItem> </asp:DropDownList> </div> <div id = "usersCountDiv" runat = "server" > <label>How much clients we should register:</label> <asp:TextBox ID = "clientsCount" runat = "server" CssClass = "input"
Text = "1" ></asp:TextBox> <div class = "errorMsg" > <asp:RequiredFieldValidator Display = "Dynamic" runat = "server"
ControlToValidate = "usersCount" ErrorMessage = "Define clients count!" ></asp:RequiredFieldValidator> <asp:RangeValidator Display = "Dynamic" runat = "server"
ControlToValidate = "clientsCount" Type = "Integer" MinimumValue = "1" MaximumValue = "30"
ErrorMessage = "We can create from 1 till 30 clients at once!" ></asp:RangeValidator> </div> </div> <div> <asp:Button CssClass = "MyButton separateButton" ID = "SubmitButton" runat = "server"
text = "Register" OnClick = "OnRegisterButtonClick" ></asp:Button> </div> </div> </form> <div runat = "server" id = "result" ></div> </body> </html>
Aqui está a implementação da lógica:
public partial class RegistrationForm : System . Web . UI . Page
{ int _clientsCount; string _clientType; protected void Page_Load ( object sender, EventArgs e )
{ _clientsCount = int.Parse(clientsCount.Text); _clientType = clientType.SelectedValue; } protected void OnRegisterButtonClick ( object sender, EventArgs e )
{ var clients = new ConcurrentBag<Client>(); Parallel.For( 0 , _clientsCount, _ =>
{ var client = new Client(); RegisterClient(client, _clientType); clients.Add(client); }); result.InnerHtml = GenerateTableViewForClientsEnumerable(clients); } }
Ao se cadastrar, recebemos a seguinte tabela:
O método RegisterClient usado no UMT é idêntico ao usado em nossos autotestes. Isso significa que sempre que introduzimos novas funcionalidades em nossos produtos, nossos autotestes são atualizados automaticamente e essas alterações também são refletidas no UMT. O UMT serve essencialmente como uma implementação de front-end sobre nossos contratos, que fornecem o código de autoteste subjacente.
Graças ao UMT, toda a equipe agora pode criar facilmente o perfil de usuário necessário em qualquer um de nossos vários ambientes de teste com apenas alguns cliques. A equipe manual de controle de qualidade pode gerar até mesmo os perfis de usuário mais intrincados de forma independente, sem exigir qualquer envolvimento da equipe de automação. Para nossa surpresa, a equipe de desenvolvimento também começou a aproveitar o UMT para seus propósitos.
Desenvolvimento e Melhoria
Depois que lançamos o UMT, começamos a receber pedidos de novos recursos. Adicionamos páginas para gerenciamento de usuários (incluindo emulação de status online e mensagens) e gerenciamento de pagamentos. Mais tarde, a equipe móvel nos abordou com uma preocupação: criar um usuário UMT em dispositivos móveis exigia muito tempo e esforço para inserir detalhes de e-mail e senha. Em resposta, adicionamos um recurso pequeno, mas útil, ao UMT – a geração de códigos QR com links de login e links diretos para aplicativos móveis.
À medida que continuamos a desenvolver o UMT, passamos por duas grandes reformulações e adicionamos um menu em forma de árvore ao site. Como resultado, a página original de registro do usuário passou por uma transformação significativa e agora parece totalmente diferente.
Ao longo dos cinco anos e meio de existência da UMT, expandimos a ferramenta muito além de seu propósito original de facilitar o teste de produtos. Adicionamos seções para automatizar as atividades de DevOps, como reiniciar serviços e servidores, configurar, limpar e vincular ambientes de teste e fornecer informações estatísticas, bem como uma base de conhecimento e muito mais. Na próxima seção, examinarei mais de perto alguns desses recursos.
Autorização
Depois de um tempo, decidimos restringir o acesso ao UMT para alguns funcionários (por exemplo, aqueles em estágio). Para fazer isso, adicionamos um banco de dados e uma tabela com funções e usuários, implementamos autenticação de domínio e atribuímos permissões. Com esse sistema instalado, podemos identificar a sessão do usuário e dar ao usuário acesso a funcionalidades específicas com base em seus direitos. Também adicionamos a autorização do Google ao UMT, devido ao uso que nossa empresa faz dos serviços do Google.
Serviços e ambiente de teste
Como o UMT se tornou uma ferramenta popular entre a equipe, nossa equipe de controle de qualidade queria gerenciar serviços e test-beds por meio do UMT, em vez de depender de vários scripts e ferramentas como o Ansible. Adicionamos a capacidade de reiniciar os serviços Docker e Windows, IIS e nós da Web e editar as configurações desses serviços. Também incluímos um recurso para configurar esses serviços e compará-los em bancos de teste.
TestRail e Jenkins
A automação de teste é uma parte crucial do nosso trabalho e geralmente temos mais de dez execuções de teste em andamento a qualquer momento. No entanto, pode ser difícil localizar uma execução específica entre muitas outras em Jenkins ou verificar sua posição na fila. Para resolver esse problema, desenvolvemos uma página em UMT que exibe dados sobre todas as execuções atuais e as que estão na fila. Esta página pesquisa todas as nossas instâncias do Jenkins para coletar informações sobre trabalhos em execução, que são apresentadas em tabelas para facilitar a referência.
Além disso, o UMT oferece uma página separada para criar TestPlans com TestRuns habilitados no TestRail. Com apenas alguns cliques, os usuários podem escolher entre vários TestPlans básicos com cenários de teste.
O UMT também provou ser útil para analisar autotestes com falha ou investigar o comportamento anômalo do usuário. Anteriormente, essas tarefas exigiam abrir manualmente o Fiddler para consultas de API ou conectar-se ao banco de dados para executar consultas SQL. Com o UMT, no entanto, as páginas dedicadas fornecem informações técnicas abrangentes sobre os usuários criados no ambiente de teste, tornando a solução de problemas mais rápida e eficiente.
Hoje, o UMT é um projeto completo que continua a evoluir à medida que o departamento de automação de teste recebe novas tarefas para adicionar funcionalidade ou corrigir bugs. Tarefas priorizadas são incluídas no sprint. O UMT continua sendo uma ferramenta essencial para nossa equipe, economizando tempo e esforço reunindo muitas atividades de rotina em um só lugar. Não há mais necessidade de fazer anotações, salvar consultas de API no Fiddler ou Postman ou abrir o SQL Studio para executar rotinas de banco de dados. Portanto, se sua empresa enfrenta desafios semelhantes, agora você sabe o que fazer.
Escrito por Pavel Yasonau, Team Lead QA Automation no Social Discovery Group