Guia de testes para fintechs

Em um processo de integração contínua no desenvolvimento de software, os testes automatizados são fundamentais para empresas de fintech. Elas precisam validar se há cobertura suficiente das funcionalidades mais importantes e críticas para o negócio, reduzir o tempo de feedback e minimizar erros humanos para otimizar os prazos de entrega e melhorar a qualidade.

Por isso, ao definir a estratégia de testes de aplicativos de fintechs, sugerimos focar o máximo possível em testes automatizados. É importante pensar em uma estratégia de testes completa antes de começar a automatizar.

Um bom caminho é o modelo de pirâmide de Cohn, com testes mais aprofundados no nível unitário e na camada de serviços. Nesses níveis, os testes são executados mais rapidamente e são mais fáceis de manter. Além disso, o modelo de Cohn propõe desenvolver menos testes no nível da interface do usuário para cobrir aspectos mais completos do sistema, considerando que esses testes são mais lentos e mais caros de manter.

Recomendamos fortemente a leitura deste artigo: Modelo de pirâmide de automação para o processo de testes de desempenho

Cada nível de testes envolve desafios diferentes, e há diversas ferramentas para projetá-los e executá-los. Nos testes para fintechs, geralmente há um aplicativo web e um aplicativo mobile. Selecionar as ferramentas certas para cada nível e para cada interface a automatizar é essencial para o sucesso da automação.

Recomendamos realizar provas de conceito antes de avançar com uma ferramenta ou estratégia, para ter certeza de que será possível atingir seus objetivos.

Em todos os casos, você pode optar por programar testes desenvolvendo seu próprio framework, baseado em ferramentas open source como WebdriverIO, Appium e RestAssure, entre outras. Ou usar ferramentas conhecidas como low-code, no-code, codeless ou scriptless, que aproveitam avanços em tecnologias como inteligência artificial e aprendizado de máquina para melhorar a experiência dos testes automatizados na criação e manutenção de casos de teste.

Na maioria dos casos, um sistema de fintech se integra a muitos outros serviços, como fornecedores externos para transações financeiras, bancos, gateways de pagamento ou serviços de contas de usuários.

Muitas vezes, enfrentamos a dificuldade de esses serviços externos não disponibilizarem ambientes de teste ou sandbox ou, quando disponibilizam, eles não estarem disponíveis no momento de executar um teste.

Portanto, para avançar adequadamente com nossos testes de forma ágil, é necessário eliminar a dependência da plataforma externa. Caso contrário, obteremos falsos positivos ou falsos negativos, o que gera muito retrabalho sem agregar valor.

A solução para essa situação é definir uma boa estratégia baseada em mocks. O objetivo é tornar nosso ambiente de teste robusto, sem fazer com que os resultados dos testes dependam de um ambiente de teste que não controlamos. Portanto, é necessário focar na integração dos testes com um servidor de mocks que simule as mesmas respostas que obteríamos do serviço externo.

Na imagem a seguir, você pode ver um exemplo de uso de mocks em um sistema de fintech para processar pagamentos. Testamos esse sistema na camada de serviços e, para evitar a dependência da integração com bancos, foram projetados mocks específicos para essa interação.

Na Abstracta, recomendamos o uso do Wiremock para dependências com serviços sobre HTTP, como uma API Rest ou SOAP, ou do Wiresham, um produto open source que desenvolvemos internamente, quando o serviço usa um protocolo sobre TCP.

Essa estratégia nos permite resolver os testes do nosso código e das nossas alterações. Entretanto, permanece um grande desafio relacionado às alterações feitas pelo fornecedor. Muitas vezes, essas alterações ocorrem sem aviso ou não são replicadas nos ambientes de teste ou sandbox que ele disponibiliza. Por isso, não as detectamos a tempo, e elas também não aparecem nos nossos testes com mocks.

Esse problema frequentemente leva à combinação dessa estratégia com testes em produção. Também é muito importante manter um diálogo fluido com os fornecedores, buscando gerar juntos um ciclo de melhoria contínua nesses processos de trabalho.

Os testes automatizados podem nos livrar de tarefas repetitivas e exaustivas e permitir testes mais rápidos, mas não é possível alcançar testes adequados e empáticos sem combiná-los com testes funcionais (também conhecidos como “testes manuais”).

O paradoxo do pesticida¶

Certamente, o paradoxo do pesticida se aplica a essa questão. Os insetos que um pesticida não consegue eliminar ficam mais fortes. Um teste automatizado sempre testa a mesma coisa; ele não explora o que não pedimos que fosse testado.

Ele encontra os maiores bugs na primeira execução, mas os que não foram encontrados ficam mais fortes. Por isso, é bom adotar uma abordagem combinada: realizar testes automatizados e também testes ‘manuais’, com uma dose de curiosidade.

Desafios e expertise no negócio¶

Os testes funcionais em aplicativos de fintechs envolvem determinados desafios, como executar testes de regressão, conhecer a complexidade do negócio, muitas vezes com a dificuldade adicional de ter pouca documentação, conhecer todas as regulamentações do setor nos países em que o negócio opera e aspectos jurídicos e tributários, entre outros fatores.

Portanto, a expertise no negócio é essencial, assim como se apoiar em sistemas semelhantes para gerar uma base de ideias para testes a partir de experiências anteriores.

Se as equipes não tiverem expertise no negócio em questão, é crucial colaborar ativamente com o Product Owner e o Business Analyst para realizar um trabalho mais dinâmico e preciso.

Testes em produção e mitigação de riscos¶

Uma prática essencial nesse tipo de sistema são os testes em produção. Isso costuma ser mais desafiador do que em outros tipos de sistemas, pois, em sistemas de fintechs, provavelmente cada transação ou cada aspecto que queremos testar envolve movimentações financeiras.

Como podemos testar isso em produção?

Algumas equipes com as quais trabalhamos têm cartões de crédito corporativos para fazer compras em locais específicos. Em produção, existe uma loja fictícia (cadastrada no sistema, mas que não existe na realidade), com produtos muito baratos, por exemplo.

Entretanto, a transação da compra é realizada por completo, o que exercita a conexão com o meio de pagamento ou outros componentes que se deseja testar. Isso reduz bastante o risco que talvez não tenhamos conseguido cobrir nos ambientes de teste.

Mesmo assim, é muito importante reduzir ao máximo o número de testes em produção que podem gerar complicações ou trazer algum risco e contar com testes mínimos que entreguem o maior valor possível ao que buscamos cobrir.

Uma maneira de alcançar isso é usar cartões de teste nos nossos ambientes de teste, que devem estar conectados aos serviços sandbox disponibilizados pelos meios de pagamento. Geralmente, os meios de pagamento oferecem esse tipo de serviço. Por isso, se usarmos Google Pay, Apple Pay, Stripe, Paypal, Affirm ou outros, poderemos acessar os recursos disponibilizados por esses meios de pagamento.

Por exemplo, aqui você pode conhecer melhor o mecanismo de testes oferecido pela Stripe.

Monitoramento e mecanismos de rollback¶

Portanto, se decidirmos executar testes em produção, precisamos dos mecanismos correspondentes de monitoramento e rollback para reagir rapidamente a qualquer incidente e minimizar a perda de dinheiro.

Podemos monitorar diversas métricas, incluindo erros registrados, contagens de determinados códigos de status HTTP e valores totais de transações em um período específico. Isso nos permite comparar estatísticas e identificar tendências.

Tem interesse em aprimorar seus sistemas com testes funcionais? Clique aqui para conhecer nossos serviços e soluções sob medida.

Produtos e aplicativos de fintechs são alvos constantes de ataques cibernéticos devido à grande quantidade de dados sensíveis que armazenam e ao tipo de transações que processam. Por isso, representam um risco para os usuários de sua tecnologia. Da mesma forma, a necessidade de chegar rapidamente à produção com segurança é um grande desafio para o ciclo de vida do desenvolvimento de software.

Segundo as conclusões de “ The Global Risks Report 2024”, o cibercrime generalizado e a insegurança cibernética estão entre os 10 riscos mais graves da próxima década.

Como destacou Rohit Ghai, CEO da RSA, na RSA 2022 Conference em São Francisco: “Haverá novas tecnologias, haverá novas vulnerabilidades. Haverá novos exploits e, é claro, haverá malware que explore esses exploits.” Nesse contexto, focar na segurança dos aplicativos de fintechs é uma prioridade.

Roger Abelenda, Chief Technology Officer da Abstracta, apresentou: “ Ao desenvolver software, é fundamental considerar boas práticas para evitar ataques e práticas conhecidas que tornam o software vulnerável. Isso exige alinhamento e responsabilidade compartilhada entre todos os envolvidos no desenvolvimento de software: desenvolvedores, testadores, product owners e gerentes de projeto, administradores de sistemas etc.”

Ele continuou: “Os testes de software são essenciais para alcançar um controle adicional sobre o software implementado, seja com testes exploratórios, testes automatizados ou ferramentas de varredura de vulnerabilidades e/ou análise estática de código.”

Para alcançar isso, Roger destacou que é prioritário contar com um protocolo para possíveis ataques previstos, incluindo os atores envolvidos, o escalonamento de incidentes e os prazos. Além disso, é sempre necessário ter um plano de contingência para situações imprevistas, executá-lo rapidamente e evitar pontos cegos.

Por sua vez, Matias Reina, co-CEO da Abstracta, destacou: “É essencial lembrar que todos ou a maioria dos aplicativos mobile usam um backend de serviços. Esse backend deve ser testado seguindo os padrões da OWASP, em particular o ASVS, e não é possível avaliar a parte mobile sem considerar o backend.”

Você pode encontrar mais informações sobre a OWASP e os métodos existentes para realizar validações de acordo com seus padrões de segurança neste artigo.

Procura um parceiro para testes de segurança? Conheça nossos serviços personalizados aqui.

Os sistemas financeiros precisam ter alta disponibilidade, ou seja, estar funcionando durante uma alta porcentagem do tempo. Além disso, geralmente precisam processar grandes quantidades de dados rapidamente. Se um sistema fica indisponível ou demora para responder, é muito provável que gere perdas financeiras para o negócio.

Falhas de sistema e impacto no negócio¶

Roger explicou assim: “Falhas de sistema e desempenho inadequado diante de uma alta demanda podem ter um grande impacto nas taxas de retenção e conversão, assim como na sustentabilidade e na escalabilidade dos negócios. As plataformas digitais são cada vez mais centrais na vida das pessoas, por isso uma falha de software pode gerar enormes perdas para as empresas.”

“Quanto mais exposto estiver um aplicativo e quanto mais usuários e variáveis houver ao seu redor, mais importante será realizar testes de desempenho. Outro fator naturalmente relevante é a criticidade do sistema: por exemplo, um sistema bancário ou de saúde em comparação com um sistema de uso pessoal para entretenimento ou com pouco impacto nos usuários”, continuou.

Uma das métricas típicas medidas nesses tipos de sistemas é a quantidade de transações por unidade de tempo, como transações por segundo (TPS), para avaliar a carga que o sistema consegue suportar com uma determinada infraestrutura. Por exemplo, com uma única instância do sistema e um único servidor, quantas TPS ele consegue processar com bons tempos de resposta? Isso pode dar uma ideia clara de como esses sistemas escalam, especialmente em termos de custos em sistemas hospedados na nuvem.

Importância de iniciar cedo os testes de desempenho¶

Os testes de desempenho fornecem informações sobre seu comportamento e desempenho em ambientes simulados e ajudam a determinar se respondem ou não nos tempos adequados, permitindo ajustes. Esse processo deve começar o mais cedo possível para ser mais eficaz, pois muitas vezes as otimizações envolvem mudanças na arquitetura do software. Se isso for detectado tarde, pode custar muito caro.

Aqui, é muito importante falar sobre testes de carga. Ao simular cenários do mundo real, eles permitem que as empresas antecipem e se preparem para a dinâmica complexa do comportamento dos usuários.

Outro aspecto essencial é a interseção entre o comportamento dos usuários e as estratégias de negócio. Ao realizar testes de carga eficazes, as empresas podem avaliar o desempenho técnico e também identificar padrões que orientem decisões de negócio.

Quando o sistema já está em produção e funciona regularmente, uma abordagem complementar ao monitoramento do desempenho é o que chamamos de “ testes de desempenho contínuos”. Nesse momento, em vez de tentar verificar as TPS suportadas e os tempos de resposta para uma determinada carga, o objetivo é detectar degradações de desempenho o mais cedo possível. Esses testes são adicionados ao pipeline de integração contínua.

Quais são as vantagens dos testes de desempenho contínuos? Descubra neste artigo do Roger, com uma entrevista com Andréi Guchin, líder do hub de desempenho da Abstracta.

Clique aqui para ler um case de sucesso de um dos nossos clientes, a Shutterfly.

Outro requisito a considerar no processo de qualidade é a facilidade de uso do nosso aplicativo: a usabilidade. Ele deve ser intuitivo e fluido para facilitar as transações de negócio que o usuário precisa realizar.

Os testes de usabilidade avaliam em que medida usuários específicos conseguem usar o sistema com eficácia, eficiência e satisfação em um contexto de uso específico. Existem diferentes técnicas para analisar a usabilidade.¶

Avaliação da usabilidade por meio de heurísticas¶

Para começar, sugerimos realizar uma avaliação baseada nas heurísticas de Nielsen, uma inspeção de usabilidade que analisa se cada elemento da interface do usuário segue os princípios de usabilidade estabelecidos.

Para complementar as descobertas dessa avaliação, recomendamos realizar testes guiados com usuários. Para isso, é necessário definir a persona do usuário do sistema de fintech em questão, considerando o país de origem, a idade, o poder aquisitivo e outros aspectos.

Uma estratégia que usamos em algumas ocasiões é combinar nossos testes com serviços de crowd-testing, nos quais é possível envolver testadores de regiões específicas, com dispositivos e meios de pagamento específicos.

Quanto à acessibilidade, é essencial cumprir pelo menos os requisitos mínimos de acessibilidade estabelecidos pela Web Accessibility Initiative do World Wide Web Consortium (W3C), o órgão internacional que define os padrões globais da web.

Melhorar a experiência digital das pessoas por meio do desenvolvimento de software sem barreiras tecnológicas, considerando todas as condições e deficiências existentes, é vital para alcançar a maior autonomia e independência digital possível em cada caso, em busca de uma sociedade mais inclusiva, com maior qualidade de vida, mais empática e respeitosa com as diferenças.

Segundo a Organização Mundial da Saúde (OMS), estima-se que 1,3 bilhão de pessoas, ou 16% da população mundial, tenham atualmente “uma deficiência significativa”.

Assim, a acessibilidade digital é importante por sua relevância social e também porque uma implementação adequada amplia o alcance dos serviços, favorecendo a sustentabilidade de organizações e empresas. Esse último ponto significa que estaríamos ampliando o tamanho do mercado-alvo e, consequentemente, o negócio.

Não perca este artigo! Heurísticas em testes de API para software de qualidade

Testes guiados com usuários e conformidade com a acessibilidade¶

É possível medir a acessibilidade com o auxílio dos padrões de acessibilidade web criados pelo W3C, conhecidos como Web Content Accessibility Guidelines (WCAG 2.1). Essas diretrizes estão organizadas em 4 princípios: perceptível, operável, compreensível e robusto. Esses princípios têm 13 diretrizes associadas, que, por sua vez, têm 78 critérios de sucesso associados, organizados em três níveis de conformidade (A, AA, AAA). Todos esses critérios de sucesso podem ser verificados por diferentes testes.

Sabemos que essa é uma tarefa enorme para acrescentar às que já estão planejadas, mas também entendemos que esses aspectos são extremamente relevantes para construir uma sociedade com igualdade de oportunidades e livre de barreiras tecnológicas. Na Abstracta, temos quase 20 anos de experiência ajudando órgãos públicos e empresas privadas nessa transição.

Para começar, nossa recomendação é criar interfaces de usuário que se adaptem ao padrão WCAG no nível AA. Para avaliar isso, tanto na web quanto no mobile, você pode usar ferramentas como axe, WAVE, ARCtoolkit e outras, mas muitos desses testes precisam ser realizados manualmente. Na Abstracta, criamos um checklist de verificação com orientações sobre como testar cada critério, o que facilita e agiliza a tarefa.

Procura serviços de testes de acessibilidade? Conheça nossos serviços personalizados aqui

As práticas mencionadas nos pontos anteriores podem ajudar a minimizar riscos antes de disponibilizar o produto ou novas funcionalidades aos usuários, com o menor número possível de bugs. Mesmo assim, não é possível garantir a ausência de bugs antes de entrar em produção.

Portanto, é crucial aplicar técnicas de observabilidade e testes shift right para continuar obtendo informações sobre a qualidade do produto mesmo depois de ele entrar em produção.

Segundo a teoria, devemos realizar testes em diferentes etapas e ambientes para alcançar uma determinada cobertura antes de liberar para produção. No contexto dos testes para fintechs, isso não é suficiente, por isso é importante complementar essa abordagem com estratégias de testes shift-right. Para isso, é necessário trabalhar para que nossos sistemas tenham bons níveis de observabilidade, permitindo detectar problemas rapidamente e agir de acordo.

Algumas práticas essenciais dessa abordagem incluem técnicas de canary release e testes A/B, testes em produção e um sistema de monitoramento que ofereça um bom nível de observabilidade.

Um monitoramento adequado em produção pode ajudar a:

✔️Medir e processar o que acontece no nosso sistema em tempo real.

✔️Observar o número de transações em um determinado período ou o volume de dinheiro em circulação para detectar anomalias ou valores fora dos padrões normais.

✔️Detectar se algum serviço não está respondendo como esperado.

✔️Configurar diferentes parâmetros e regras, ajustáveis conforme o negócio, para enviar alertas, como os de problemas de segurança.

Aplicação de técnicas de testes shift-right¶

Na Abstracta, recomendamos o uso do DataDog, uma ferramenta que permite aos usuários combinar todos os aspectos da observabilidade, reunir de forma integrada informações de métricas, rastros e logs em tempo real e configurar alertas baseados em regras. Essas regras podem ser definidas a partir de métricas padrão (como CPU) ou métricas personalizadas, definidas por nós (como o valor total de dinheiro transferido por um determinado gateway).

Se você quiser saber mais sobre o DataDog, a equipe da Abstracta pode ajudar com treinamentos e também com a instalação e adoção da ferramenta.

A detecção de erros em tempo de execução pode ser feita com diferentes ferramentas, que podem até ser integradas aos nossos monitores e alertas. Existem ferramentas como Bugsnag, Crashlytics, Sentry ou LogSnag que ajudam os desenvolvedores a identificar, priorizar e reproduzir erros decorrentes de exceções controladas e não controladas do aplicativo.

Essas ferramentas permitem identificar proativamente defeitos no código, as linhas específicas em que esses erros ocorreram e as sessões de usuário às quais pertencem. Isso ajuda a resolver problemas antes que se agravem. Além disso, algumas podem ser integradas ao Slack, ao Jira ou ao Trello, facilitando o registro de detecções em tempo real.

Importância do monitoramento e das métricas de negócio¶

Vamos entender tudo isso com um exemplo. Imagine que, como parte do nosso desenvolvimento, precisamos liberar uma integração com um novo gateway de pagamento. A equipe realizou testes com mocks baseados na documentação fornecida pelo fornecedor do gateway. Os testes foram executados no ambiente sandbox dele, mas esse ambiente não tem a versão mais recente do software do gateway, por isso sabemos que há um risco.

A liberação para produção usa uma abordagem de canary release. Essa funcionalidade é disponibilizada apenas para uma porcentagem muito pequena de usuários (se possível, somente familiares e amigos ou testadores beta). Se tudo correr bem, ela é liberada para mais usuários, e assim por diante até chegar a todos.

Também pode acontecer de bugs serem descobertos devido a situações extremas imprevistas ou a diferenças entre o software com o qual nos integramos no ambiente sandbox e no ambiente de produção. Também é possível detectar fraudes ou a exploração de vulnerabilidades nessa integração, pois, por exemplo, a nova versão do software com o qual nos integramos pode ter defeitos que afetam nosso negócio.

Isso mostra que precisamos monitorar métricas do servidor, erros HTTP 500 ou similares e também focar nas métricas de negócio. Faz sentido que a nova integração se comporte de maneira diferente da esperada? Essas práticas ajudam a avaliar todas essas questões de forma abrangente.

Não perca este artigo! Testes shift-left e testes shift-right: uma estratégia possível