Muitos consideram o teste em ambientes de produção uma prática prejudicial: não ajuda a impedir que os problemas cheguem aos usuários finais, mas afirma que eles estão presentes. Além disso, o testador é desanexado do fluxo de trabalho padrão e das técnicas usadas no ambiente de teste. Meu nome é Olya Mikhalchuk, sou engenheiro de controle de qualidade na empresa financeira fintech ID Finance. Neste post, explicarei por que os testes no produto podem ajudar significativamente seu projeto.
Por que você precisa de um controle de qualidade no produto, se houver um ambiente de pré-produção
Durante o processo de desenvolvimento de software, sempre existem vários ambientes nos quais o aplicativo é implantado. O ambiente que os usuários finais usam, como você sabe, é chamado de produção. Geralmente, pressupõe-se que o teste deve ser realizado em um ambiente separado, geralmente no ambiente de controle de qualidade ou na preparação (pré-produção), para impedir que erros cheguem aos usuários. Mas existe uma técnica como o controle de qualidade no prod, que ajuda perfeitamente a resolver problemas fisicamente impossíveis de resolver em um ambiente de teste.
Quais tarefas o controle de qualidade no prod ajuda
1. O problema das diferenças entre os ambientes de teste e produção.
A preparação é geralmente considerada uma cópia do ambiente de produção, inacessível aos usuários finais, mas é mais semelhante ao ambiente de combate. Quando o aplicativo é bastante complexo, a sincronização e a manutenção de uma mini-cópia tornam-se uma tarefa demorada e nem sempre racional.
Por exemplo, em nosso projeto, o pré-prod é usado mais para testes funcionais em cenários de teste feitos manualmente. Não possui recursos técnicos comparáveis ao ambiente de produção. Além disso, geralmente não sincronizamos completamente as configurações e os bancos de dados com o ambiente de produção, o que não interfere nos testes funcionais. Por que não copiamos o ambiente de prod? Imagine quantos recursos seriam necessários para criar uma cópia do Facebook, digamos, com os mesmos servidores, serviços, banco de dados e configurações superpoderosos da produção. Na verdade, é como implantar outro aplicativo do mesmo tipo.
Além disso, ao integrar-se a serviços de terceiros, você sempre tem configurações diferentes para os ambientes de teste e combate (a mesma API). Não estou dizendo que os ambientes de teste e teste são inúteis. Apenas não é possível garantir 100% que, após a conclusão bem-sucedida de determinados testes em um ambiente, os serviços não caem em outro. Testes adicionais para produção podem ajudar a resolver esse problema.
2. Níveis reais de multitarefa e carga.
Alguns erros podem ser detectados apenas em um nível longo e real de multitarefa e carga de trabalho. Isso se aplica a vazamentos de memória, estabilidade, velocidade e estabilidade do sistema. Por exemplo, tivemos uma situação em que o problema de desempenho do sistema surgiu devido ao fato de que duas tarefas com muitos recursos foram executadas no mesmo intervalo de tempo. Os desenvolvedores otimizaram o trabalho das tarefas, a equipe fez testes no ambiente de pré-produção, entregou as alterações e depois fez uma verificação de produção.
3. Erros de implantação
A partir da definição, implantação é a instalação por um grupo de trabalho de uma nova versão do código do programa de serviço na infraestrutura de produção. Consequentemente, a melhor maneira de ver erros de implantação é através de testes no próprio processo de implantação.
4. Falta de monitoramento no pré-prod
Uma das melhores e indispensáveis maneiras de controlar se o aplicativo funciona conforme o esperado é monitorar determinadas métricas. Por exemplo, a partir de exemplos simples e mais críticos: monitoramento do número de novos registros de usuários por hora, da conversão de uma ação de destino para outra, do número de empréstimos emitidos. Obviamente, esse monitoramento só faz sentido em um ambiente de combate.
5. A capacidade de analisar cenários de usuário final para usar o sistema
Produção - um depósito de casos de teste para o testador. Se possível, o testador pode ver e processar os scripts usados pelos usuários finais, identificar os cenários mais críticos, descobrir a causa do defeito ou prestar atenção a casos não triviais ao testar no pré-produto.
6. A capacidade de manter estatísticas e métricas mais confiáveis da qualidade do software.
Por exemplo, o número de erros nos logs de um aplicativo ou componente, relatórios de erros e outros relatórios que um pró-testador pode executar, demonstram de maneira mais realista a qualidade do software em comparação com os mesmos relatórios do ambiente de teste.
7. É sempre melhor se o erro no produto for percebido pelo "seu" testador do que pelo usuário final.
Geralmente, depois que a tarefa é entregue, o testador faz verificações básicas da funcionalidade nova ou alterada no produto. Além disso, temos uma pessoa separada em nossa empresa - um testador em prod. Quero mais uma vez observar que não posiciono o controle de qualidade no prod como um substituto para os testes de pré-produção e, é claro, é necessário evitar bugs e tomar medidas preventivas. Mas esses testes podem ser uma ótima técnica adicional no processo de garantir a qualidade do seu projeto.
Práticas úteis de controle de qualidade na produção que funcionam efetivamente em nosso projeto1. Verificando as tarefas entregues para garantir que elas estejam bem estabelecidas e funcionando no novo ambiente.
Por exemplo, quando introduzimos a integração com um novo parceiro, além dos testes no pré-produto, definitivamente verificamos a integração após a entrega, porque há muitas configurações dependendo do ambiente (API, URLs, componentes). Também existem problemas de terceiros - os erros não estão do nosso lado, mas do lado dos serviços integrados.
2. Log e auditoria.
Um bom registro ajuda os desenvolvedores e testadores a perceberem um problema antes mesmo que o usuário final o adivinhe, bem como a locais que precisam de otimização. Uma auditoria de ações e mudanças nos permite descobrir sempre os motivos de um comportamento específico sem problemas. Por exemplo, se um componente de uma política de crédito não pode tomar uma decisão sobre um empréstimo, para analisar por que isso aconteceu, primeiro recorremos aos logs. Este item se aplica aos ambientes de produção e pré-produção.
3. Sistema de monitoramento e alerta
Como mencionei acima, o monitoramento por determinadas métricas é uma das melhores maneiras de controlar se tudo está bem com nosso aplicativo. Além disso, se surgir algum problema, você deve enviar um alerta às partes interessadas (por exemplo, o número de pedidos de empréstimo é 20% menor que o esperado - enviaremos um alerta aos departamentos de TI e de negócios, a carga da CPU é maior que o normal - notifique administradores e virgens). É necessário garantir que os alertas sobre problemas sejam oportunos e relevantes, além de realmente indicar o problema.
4. Regressão e verificação de estabilidade
Uma prática interessante é passar periodicamente por testes de regressão para garantir que nada deu errado em lugar algum. Pode ajudar em alguns casos estreitos e específicos quando o monitoramento não apresenta problemas.
5. Relatórios e estatísticas
Como em qualquer teste, os relatórios e as estatísticas dos resultados dos testes de produtos tornam o processo mais transparente, a qualidade do software e as causas dos defeitos mais visíveis.
Todos os erros não podem ser detectados no pré-prod, portanto eles caem no ambiente de combate. Se os usuários os encontrarem, isso afetará a reputação da empresa e, finalmente, a perda de dinheiro. Testar o produto ajudará a evitar isso.