Como testar um serviço de pagamento internacional sem dores e nervos

Olá!



Meu nome é Sasha Zubarchuk. Eu vim para o Solid há três anos como Junior Manual QA. Desde então, tornei-me engenheiro de automação, formei alunos da primeira Escola de QA com a qual trabalhamos e passei para o cargo de Gerente de Produto.



Neste artigo, falarei sobre os recursos de teste de sistemas de pagamento e compartilharei a experiência de nossa equipe: o que estamos testando, como, quais desafios enfrentamos e como respondemos a eles. Esta experiência será útil para aqueles que constroem o processo de teste no projeto - engenheiros de QA e gerentes de produto / projeto.



Não vou me aprofundar na técnica e nas ferramentas específicas, mas vou falar sobre a ideia principal: como tornar o processo de teste de serviços tecnicamente complexos o mais transparente e calmo possível.



Em que consiste o serviço de pagamento e como funciona O



Solid é um portal que permite às empresas em todo o mundo aceitar pagamentos online de clientes de várias maneiras, desde cartões bancários e carteiras eletrônicas até PayPal e Alipay.



Existem quatro atores principais em toda esta história:



  • usuário (também é comprador);
  • comerciante - qualquer empresa que vende seus produtos / serviços na Internet e deseja aceitar dinheiro por eles;
  • gateway de pagamento - Sólido;
  • banco (adquirente) - instituição financeira que realiza transações com dinheiro real.










Em termos simples, é assim: Simplificando, ajudamos os comerciantes a monetizar e ganhar dinheiro.



Você pode ter uma pergunta: por que os comerciantes escolhem o Solid, se eles podem trabalhar diretamente com os bancos? É simples: 1) existem muitos bancos, e cada um deles tem suas próprias especificidades - combinando diferentes bancos de diferentes países em uma única infraestrutura, alcançamos o máximo de conversões e receita; 2) temos vasta experiência em lógica de pagamento e antifraude; 3) além dos pagamentos bancários, aceitamos todos os métodos de pagamento alternativos populares em uma determinada região e 4) somos mais baratos.



Vamos começar com o primeiro ponto - quais são esses recursos de fazer pagamentos em diferentes países? Por exemplo, nos EUA, por incrível que pareça, você não poderá fazer um pagamento tão facilmente como na Ucrânia - usando apenas os detalhes do cartão. Lá, os bancos são obrigados a verificar detalhes adicionais do pagador, como endereço de cobrança e código postal.



Existem muitas nuances semelhantes. Bem como alternativas para pagamentos com cartão. Na Holanda e na Alemanha, por exemplo, as pessoas gostam de usar carteiras de internet locais. Os métodos de pagamento mais populares na China são Alipay, WeChat Pay e UnionPay. E na Nigéria , para pagar mercadorias na Internet, os usuários vão ao banco com dinheiro!



Aceitamos todos os pagamentos populares, sem exceção - de cartões bancários a PayPal, e-wallets, Google Pay, Apple Pay ou SMS. Com a ajuda do Solid, o lojista tem acesso para trabalhar com todos os tipos de pagamento em uma integração. Além disso, o gateway tem sua própria proteção contra fraudes, um sistema de roteamento de pagamento, uma ferramenta para evitar estornos não razoáveis ​​e muito mais.



Por que testar sistemas de pagamento e os riscos de não testar



Muitos comerciantes estão conectados ao Solid. Portanto, somos responsáveis ​​não só pelo nosso negócio, mas também pela monetização de todos os clientes a nós conectados. Se algo der errado do nosso lado, estamos falindo com muitas empresas. E vice-versa - testando e melhorando nosso serviço de pagamento, aprimoramos os produtos de outras empresas.



Infelizmente, além de um pagamento bem-sucedido, podem ocorrer erros - tanto do sistema quanto do usuário. É importante entender que 100% dos pagamentos nunca serão aprovados em qualquer local. Mas, da nossa parte, temos a obrigação de fazer tudo para que a conversão de pagamentos seja o possível.



Testar um gateway de pagamento não é uma tarefa rotineira, pois é um mecanismo bastante complexo de dezenas de microsserviços e interconexões. Testamos tudo em três etapas. Primeiro verificamos cada tarefa em um ambiente isolado, depois combinamos e verificamos no release candidate no estágio, vemos como tudo funciona na integração, depois liberamos e testamos tudo novamente em produção.



Vamos dar uma olhada mais de perto no que especificamente temos que testar.



Recursos de teste de sistemas de pagamento



O sistema de pagamento consiste em interfaces API e web. Não há diferenças fundamentais em API e testes da web para sistemas de pagamento, ao contrário de qualquer outro produto. A principal característica é testar pagamentos específicos para diferentes regiões, bem como todos os serviços auxiliares.



Parece que testar um pagamento não é difícil: você precisa fazer um pagamento, verificar se o dinheiro foi debitado de uma conta e creditado em outra. Mas existem nuances. Os testadores precisam saber as especificações dos pagamentos em diferentes países e, às vezes, as nuances das leis locais e regulamentações bancárias.



O segundo ponto são os diferentes tipos de pagamentos: assinaturas, o primeiro pagamento, autorização (congelamento de dinheiro na conta), pagamento através de carteira eletrônica. Cada um deles tem suas próprias especificações de teste.



Uma atenção especial deve ser dada ao trabalho com moedas: nem todas elas têm uma parte fracionária. Por exemplo, a hryvnia tem um centavo, mas o peso chileno não. Se você transferir o valor do pagamento 100 na Ucrânia, o banco cancelará 1 UAH, ou seja, 100 copeques. E no Chile isso significaria 100 pesos. Como você pode ver, esses momentos não devem ser perdidos.



O que precisa ser testado nos sistemas de pagamento



Todos os nossos clientes (web, aplicativos móveis, bem como serviços de back-end) se comunicam conosco usando a API Solid . O próprio gateway está localizado em um cluster separado e se comunica com vários sistemas (antifraude, tokenizer, bancos, etc.).



Desenvolvedores sólidos estão empenhados em resolver diversos tipos de problemas (e todas essas tarefas ficam à disposição da equipe de QA):



  • ( , , , , );
  • (PayPal, Alipay Visa Mastercard);
  • : API, ;
  • ( , );
  • , (, , -);
  • .


Além das tarefas que vêm diretamente dos desenvolvedores, recebemos outras: checar todos os dados e UAT ao conectar novos comerciantes, checar tarefas da equipe DevOps, configurar regras antifraude.



Para resumir, tudo o que testamos pode ser dividido nas seguintes categorias:



Serviços de back-end sólidos:



  • anti-fraude;
  • serviço de assinatura;
  • roteamento de pagamento;
  • sistema de controle contábil e financeiro;
  • integração com serviços externos.


Integração com bancos:



  • verificar a correção do trabalho com moedas;
  • verificação dos diferentes tipos de pagamentos (primeiro pagamento por dados de cartão, pagamento por token, reembolsos, congelamento de dinheiro, etc.);
  • processamento de notificações.


Métodos de pagamento alternativos (sem cartão):



  • verificação do pagamento;
  • verificar as características do local.


Admin:



  • painel de administração interno (tudo que ajuda os analistas da Solid a executar testes A / B para conversão de um formulário de pagamento, configurar regras para antifraude);
  • painel de administração para comerciantes.


Interfaces de usuário:



  • aparência de formulários de pagamento e páginas;
  • se o formulário é exibido no idioma de uma determinada região (o formulário de pagamento Solid está disponível em todos os idiomas do mundo);
  • exibição correta do valor e moedas;
  • rastrear ações do usuário em formulários;
  • status da página.


De outros:



  • UAT ao conectar um novo comerciante ao Solid;
  • tarefas do departamento de risco para verificar novas configurações;
  • estudos funcionais de saúde (por exemplo, o Apple Pay funciona no WKWebView).


Passos para o sucesso do teste



Automação



Ao trabalhar com soluções de TI em grande escala, como provedores de pagamento, você precisa testar constantemente não apenas a operação de elementos funcionais individuais, mas também sua interação. Não funcionará sem automação. Se algum serviço não for coberto por autotestes, as falhas não podem ser evitadas. Execute autotestes sempre que possível. Derramei a tarefa no ambiente - execute testes. Várias tarefas mescladas em um candidato a lançamento - execute os testes.



No nosso caso, é mais ou menos assim:



  • os desenvolvedores executam testes independentemente ao implementar uma tarefa;
  • os testadores executam testes ao testar uma tarefa em um ambiente isolado;
  • os testes são iniciados automaticamente quando uma nova versão do build é construída;
  • autotestes são executados constantemente no ambiente Prod.


A execução de autotestes leva tempo e, portanto, sempre nos esforçamos para otimizar esse processo o máximo possível. Os testes são executados em vários segmentos e também são divididos em tarefas por importância.



Temos um conjunto mínimo de testes que validam a funcionalidade central de processamento de pagamentos do Solid - ele é executado em menos de um minuto. Todos os outros testes do Solid API e outros microsserviços levam cerca de 3-4 minutos. Os testes de IU são, obviamente, um pouco mais lentos. Mas mesmo aqui não paramos de trabalhar na melhoria e na otimização.



Por que o teste isolado não é a melhor opção ao testar pagamentos? Vou te contar sobre nosso caso antifraude.



Cada estabelecimento Solid possui uma conta antifraude ligada ao estabelecimento de regras de funcionamento. Por exemplo, se um usuário fez mais de três pagamentos por dia com um comerciante, bloqueamos o quarto. Ou se mais de cinco usuários fizerem pagamentos com o mesmo cartão, também os bloqueamos e adicionamos à lista negra. Nós cobrimos isso com autotestes, mas encontramos um problema.







Inicialmente, duplicamos todas as regras de uma conta de teste, simulamos ações fraudulentas e os testes pareceram funcionar. Mas descobriu-se que o próprio comerciante costuma enfrentar situações em que as regras antifraude são combinadas, por exemplo, três delas funcionaram.



Ao isolar cada pagamento para cada regra específica, eliminamos a possibilidade de uma combinação de regras e a influência de outros serviços no processo de pagamento.



Como fizemos cada pagamento: limpamos os dados de teste, criamos todas as condições para que o pagamento se enquadrasse em uma determinada regra e funcionou. Mas não é um fato que será assim em um ambiente de trabalho, porque nunca haverá uma situação ideal para que um pagamento caia sob uma regra.



Decidimos conectar as verdadeiras regras antifraude de nossos clientes ao comerciante de teste. Então eles começaram a trabalhar com mais clareza. Ou seja, foi necessário criar não regras isoladas, mas testá-las de forma agregada como são para um determinado cliente.



Agora os clientes da Solid podem personalizar as regras antifraude para eles próprios. Porque as transações que parecem fraude para um comerciante podem ser a norma para outro.

Se uma pessoa faz cinco compras por dia em uma loja online, esta é a norma: primeiro ele gostou do case do celular, depois do notebook, etc. Mas para aplicações de fitness, isso já é uma anomalia. É improvável que uma pessoa compre cinco programas de treino por dia.



A automação realmente ajuda a construir um equilíbrio: apenas os novos recursos e os cenários que requerem atenção humana são verificados manualmente, todo o resto é automatizado. A automação pode ajudar a reduzir os custos de teste e o risco humano.



Testes na fase de especificações técnicas



Além de verificar diretamente a funcionalidade da funcionalidade, dedicamos muito tempo para garantir que os desenvolvedores e gerentes percebam a funcionalidade implementada da mesma forma. Parece óbvio, mas muitos o negligenciam.



Todos os serviços de configuração são bastante complexos, têm uma grande variedade de recursos e mesmo os menores detalhes podem fazer com que o serviço não funcione como esperado.



A técnica de "teste inicial" tem várias vantagens ao mesmo tempo:



  • a equipe de desenvolvimento entenderá corretamente a tarefa e não perderemos tempo com correções;
  • uma especificação técnica bem escrita é 70% de uma boa documentação;
  • pelo fato de a equipe de teste conhecer as especificações técnicas com antecedência, os cenários de teste também são pensados ​​com antecedência e, no momento em que a tarefa implementada entra em teste, o processo é mais rápido.


Boa documentação de teste



Uma documentação interna realmente boa e estruturada é metade da batalha durante o teste. Apesar do fato de que quase todas as funcionalidades devam ser automatizadas, o trabalho manual nunca será em vão.



Descrição dos processos de teste para várias funcionalidades, artigos com soluções para possíveis problemas e diversos manuais agilizam o trabalho da equipa de testes.



Nós da Solid criamos nossa própria base de conhecimento. Ele descreve como cada banco e um método de pagamento alternativo funcionam em diferentes locais, que tipos de pagamentos o banco suporta e como, em princípio, os pagamentos são feitos em uma determinada região.



Essa base é uma tarefa ampla e complexa que se tornou um desafio para nós. Era preciso reunir toda a documentação e descrever os processos de forma acessível. Mas agora, quando um novo funcionário vem até nós, não há problemas. É difícil lembrar como algo deve funcionar na primeira vez e, se houver documentação de teste, a opção de cometer um erro é mínima. A documentação clara permite ao testador determinar exatamente porque o pagamento não foi realizado: é um erro ou esse tipo de pagamento simplesmente não deveria funcionar neste banco.



Deixe-me te dar outro exemplo. Uma vez que mudamos os logotipos dos sistemas de pagamento internacionais em formulários de pagamento. Temos mais de 200 designs diferentes para nossos clientes, para cada design podem haver várias configurações de campos no formulário. Por exemplo, para o Brasil, um campo adicional de CPF é adicionado - um análogo de nosso código de identificação.



Devido ao novo tamanho do logotipo, alguns campos do formulário podem se mover, desaparecer ou se tornar impossíveis de clicar. Ninguém na equipe de testes do Solid sabe apenas fisicamente como todos os 200 formulários devem ser.



Testar essa tarefa foi estressante, mas, como resultado, criamos uma base de conhecimento com formulários de referência para cada um de nossos comerciantes, cobrimos com autotestes e agora não temos medo de quaisquer alterações relacionadas aos designs.



***



Por fim, vou contar um pequeno fato interessante do mundo do processamento: a parcela de declínios do Cartão Restrito na Ucrânia é bastante baixa - 1-2%. Ou os bancos ucranianos são tão bons na prevenção de fraudes ou ninguém quer roubar os dados do cartão dos usuários ucranianos ...



No entanto, não há nenhum produto com processos de desenvolvimento e teste ideais, mas podemos melhorá-los. Afinal, a tarefa de todo negócio é lançar um produto de qualidade. Quem mais, senão os engenheiros de controle de qualidade, ajudará com isso?



Eu ficaria feliz se você compartilhasse seus princípios de um bom processo de teste nos comentários.



All Articles