TAE-2.1.1 (K2) Descrever as necessidades de configuração de uma infraestrutura que permita a implementação da automação de teste.
A testabilidade do Sistema em Teste (SUT), ou seja, a capacidade de controlá-lo e observar seu comportamento durante o teste, é imperativo para a qualidade do software. Para garantir a testabilidade eficaz, é preciso projetá-la e implementá-la em paralelo com o desenvolvimento de outras funcionalidades. Ignorar a testabilidade desde o início pode resultar em custos significativamente mais altos durante o desenvolvimento e manutenção do sistema.
Normalmente, o Arquiteto de Software lidera a implementação da testabilidade, tratando-a como um requisito não funcional essencial. O Engenheiro de Automação de Teste (TAE) desempenha um papel fundamental nesse processo, colaborando com o arquiteto para identificar áreas de melhoria e garantir que o SUT seja testável de forma eficiente.
Soluções para Melhorar a Testabilidade do SUT:
Identificadores de Acessibilidade: Permitem que os testes interajam com elementos específicos da interface do usuário. As estruturas de desenvolvimento podem gerá-los automaticamente, ou os desenvolvedores podem defini-los manualmente.
Variáveis de Ambiente do Sistema: Parâmetros configuráveis que influenciam o comportamento do aplicativo, facilitando a execução de testes em diferentes cenários.
Variáveis de Implantação: Semelhantes às variáveis de ambiente, mas definidas antes da implantação, permitindo configurar o sistema especificamente para o ambiente de teste.
A implementação dessas soluções, em conjunto com a aplicação dos três pilares da testabilidade – observabilidade, controle e transparência da arquitetura – garante a criação de um SUT robusto e fácil de testar. Lembre-se, a testabilidade não é um acréscimo posterior, mas sim um investimento estratégico que renderá frutos ao longo de todo o ciclo de vida do software.
Para garantir a testabilidade eficaz de um SUT, três aspectos principais devem ser considerados:
Observabilidade: O SUT precisa fornecer interfaces que permitam a coleta de informações sobre seu funcionamento. Essas interfaces permitem que os casos de teste verifiquem se os resultados reais correspondem aos resultados esperados.
Controle: O SUT precisa oferecer interfaces que permitam a execução de ações específicas. Essas interfaces podem ser elementos de interface do usuário, chamadas de função, protocolos de comunicação (como TCP/IP e USB) ou até mesmo sinais eletrônicos para manipular variáveis de ambiente.
Transparência da Arquitetura: A documentação da arquitetura do SUT precisa apresentar seus componentes e interfaces de forma clara e compreensível. Essa transparência facilita a observação e o controle do sistema em todos os níveis de teste, contribuindo para a qualidade geral.
Configurando uma Infraestrutura para Automação de Testes – Exemplo com iFood
Vamos falar agora sobre a importância de projetar uma infraestrutura adequada para automação de testes, com foco na testabilidade do Sistema em Teste (SUT). Vamos usar o iFood como exemplo para entender como aplicar esses conceitos na prática.
1. A Importância da Testabilidade
Testabilidade é a capacidade do sistema de ser testado de forma eficaz e eficiente. Isso inclui:
- Observar o que está acontecendo no sistema.
- Controlar os elementos necessários durante os testes.
- Garantir que a arquitetura do sistema seja transparente e compreensível.
No caso do iFood, uma infraestrutura bem projetada permite, por exemplo:
- Testar a funcionalidade de rastreamento de pedidos
- Validar notificações push para status do pedido.
- Simular cenários como falhas no pagamento ou atrasos na entrega.
2. Testabilidade Durante o Desenvolvimento
A testabilidade deve ser considerada desde o início do desenvolvimento. Ignorar isso pode gerar retrabalho e custos adicionais. No iFood, o arquiteto de software pode liderar esse processo, enquanto o Engenheiro de Automação de Teste (TAE) colabora identificando requisitos específicos.
Exemplo Prático: Ao desenvolver a funcionalidade de rastreamento de pedidos em tempo real, o TAE pode solicitar:
- Um endpoint na API que forneça os dados em formato JSON.
{
“pedido_id”: 12345,
“cliente”: {
“nome”: “João Silva”,
“telefone”: “+55 11 99999-1234”,
“endereco_entrega”: “Rua das Flores, 123, São Paulo, SP”
},
“status”: “A caminho”,
“entregador”: {
“nome”: “Carlos Santos”,
“veiculo”: “Moto”,
“placa”: “ABC-1234”,
“localizacao_atual”: {
“latitude”: -23.563210,
“longitude”: -46.654321
},
“tempo_estimado_entrega”: “15 minutos”
},
“restaurante”: {
“nome”: “Pizzaria Boa Massa”,
“telefone”: “+55 11 88888-1234”,
“endereco”: “Av. Central, 456, São Paulo, SP”
},
“itens”: [
{
“produto”: “Pizza Margherita”,
“quantidade”: 1,
“preco”: 39.90
},
{
“produto”: “Coca-Cola 2L”,
“quantidade”: 1,
“preco”: 10.00
}
],
“pagamento”: {
“metodo”: “Cartão de Crédito”,
“total”: 49.90,
“status_pagamento”: “Aprovado”
},
“historico_status”: [
{
“status”: “Pedido recebido”,
“horario”: “2025-01-11T12:00:00”
},
{
“status”: “Pedido em preparação”,
“horario”: “2025-01-11T12:10:00”
},
{
“status”: “Entregador a caminho”,
“horario”: “2025-01-11T12:30:00”
}
]
}
- Variáveis configuráveis para simular diferentes condições de entrega (p. ex., entregador a caminho ou pedido cancelado).
Simular um pedido cancelado
Variável configurável: STATUS_ENTREGA = “cancelado”
- Como funciona: Essa variável muda o status do pedido para “cancelado” no ambiente de teste. O sistema deve:
- Exibir uma notificação ao cliente.
- Permitir o reembolso automático, se aplicável.
- Cenário Testado: Verificar se a mensagem exibida é:
- “Seu pedido foi cancelado. Entre em contato com o suporte para mais informações.”
Como implementar?
As variáveis configuráveis podem ser definidas no ambiente de teste usando arquivos de configuração, APIs simuladas ou diretamente no banco de dados de teste.
3. Soluções para Melhorar a Testabilidade
Para garantir que o iFood seja testável, algumas soluções práticas podem ser aplicadas:
3.1 Identificadores de Acessibilidade
Esses identificadores permitem que testes automatizados interajam com elementos específicos da interface do usuário, como botões e campos de texto.
Exemplo Prático:
- O botão “Finalizar Pedido” no iFood pode ter um identificador como id=btn_finalizar_pedido.
- Isso facilita a automação de um teste que verifica se o botão funciona corretamente após a seleção de itens no carrinho.
3.2 Variáveis de Ambiente do Sistema
Essas variáveis configuráveis ajudam a simular diferentes cenários durante os testes.
Exemplo Prático:
- Configurar uma variável de ambiente NOTIFICACAO_DELAY para simular atrasos no envio de notificações push.
- Isso permite validar como o aplicativo se comporta em condições adversas, como notificações que chegam com atraso.
Como essa variável afeta o comportamento do aplicativo?- Simulação de Atrasos:
- Durante o teste, quando o sistema tenta enviar uma notificação push, ele espera os 5 segundos configurados antes de enviá-la.
- Validação do Comportamento:
- O sistema precisa ser capaz de lidar com atrasos sem comprometer a experiência do usuário.
- O aplicativo do iFood pode ser testado para verificar:
- Se as mensagens exibidas ao usuário são atualizadas corretamente após o atraso.
- Se o usuário continua recebendo as notificações na ordem correta.
- Simulação de Atrasos:
- Variáveis que alteram o comportamento do sistema: Devem ser configuradas no SUT.
- Variáveis que controlam a execução dos testes: Devem ser configuradas no TAS.
No caso do exemplo NOTIFICACAO_DELAY, ele deve ser configurado no SUT, porque seu objetivo é simular atrasos no envio de notificações, o que afeta diretamente o comportamento do sistema.
3.3 Variáveis de Implantação
As variáveis de implantação são configurações específicas definidas no momento em que o sistema é configurado para ser executado em um ambiente, como desenvolvimento, teste ou produção. Elas permitem adaptar o comportamento do sistema ao ambiente em que ele será executado, sem a necessidade de alterar o código do software.
Exemplo Prático:
- Configurar uma variável URL_API_TESTE que redireciona as chamadas da API para um ambiente de teste.
- Isso garante que os testes não interfiram nos dados reais de produção.
Cenário:
- Em produção:
- O aplicativo do iFood usa a URL:
https://api.ifood.com - Todas as chamadas são enviadas para o ambiente real, onde dados de produção são armazenados e processados.
- O aplicativo do iFood usa a URL:
- Em teste:
- É configurada uma variável de implantação:
URL_API_TESTE=https://api-teste.ifood.com - Essa configuração garante que todas as chamadas feitas pelo aplicativo durante os testes sejam direcionadas para o ambiente de teste.
- É configurada uma variável de implantação:
4. Os Três Pilares da Testabilidade
4.1 Observabilidade
O SUT precisa fornecer informações sobre seu funcionamento.
Exemplo Prático:
- No iFood, uma interface de observação pode ser uma API que retorna o estado atual de um pedido (ex.: “preparando”, “em rota” ou “entregue”).
- Os testes automatizados verificam se o status do pedido exibido para o usuário está correto.
4.2 Controle
O SUT deve oferecer interfaces que permitam manipular ações específicas durante os testes.
Exemplo Prático:
- Um endpoint para simular pagamentos pode ser criado (/simular-pagamento) para validar diferentes respostas do gateway de pagamento, como aprovação, rejeição ou erro.
4.3 Transparência da Arquitetura
A documentação do SUT deve ser clara e completa.
Exemplo Prático:
- No iFood, a arquitetura deve detalhar como a interface gráfica se conecta às APIs e como cada componente do sistema interage. Isso facilita a criação de testes que verificam a integração entre esses componentes.
5. Conclusão: Investimento Estratégico
A testabilidade não é um “luxo”, mas sim um investimento estratégico. No caso do iFood, aplicar esses conceitos desde o início:
- Reduz o retrabalho em funcionalidades futuras.
- Aumenta a eficiência da equipe de QA.
- Garante que o sistema seja robusto e confiável.