Mi nombre es Sasha Zubarchuk. Llegué a Solid hace tres años como Junior Manual QA. Desde entonces, me convertí en ingeniero de automatización, gradué a estudiantes de la primera escuela de control de calidad con la que trabajamos y pasé al puesto de gerente de producto.
En este artículo, hablaré sobre las características de probar sistemas de pago y compartiré la experiencia de nuestro equipo: qué estamos probando, cómo, qué desafíos enfrentamos y cómo respondemos a ellos. Esta experiencia será útil para quienes construyan el proceso de prueba en el proyecto, tanto ingenieros de control de calidad como gerentes de productos / proyectos.
No profundizaré en la técnica y herramientas específicas, pero hablaré sobre la idea principal: cómo hacer que el proceso de testear servicios técnicamente complejos sea lo más transparente y tranquilo posible.
En qué consiste el servicio de pago y cómo funciona
Solid es una puerta de enlace que permite a las empresas de todo el mundo aceptar pagos de clientes en línea de diversas formas, desde tarjetas bancarias y monederos electrónicos hasta PayPal y Alipay.
Hay cuatro jugadores principales en toda esta historia:
- usuario (también es comprador);
- comerciante : cualquier empresa que venda sus bienes / servicios en Internet y quiera aceptar dinero por ellos;
- pasarela de pago - Sólido;
- banco (adquirente) : institución financiera que realiza transacciones con dinero real.
En términos simples, se ve así: en pocas palabras, ayudamos a los comerciantes a monetizar y ganar dinero.
Es posible que tenga una pregunta: ¿por qué los comerciantes eligen Solid, si pueden trabajar directamente con los bancos? Todo es simple: 1) hay muchos bancos, y cada uno de ellos tiene sus propias características: al combinar diferentes bancos de diferentes países en una sola infraestructura, logramos el máximo de conversiones e ingresos; 2) contamos con una vasta experiencia en lógica de pago y antifraude; 3) además de los pagos bancarios, aceptamos todos los métodos de pago alternativos populares en una región en particular, y 4) somos más económicos.
Comencemos con el primer punto: ¿cuáles son estas características de realizar pagos en diferentes países? Por ejemplo, en los EE. UU., Curiosamente, no podrá realizar un pago tan fácilmente como en Ucrania, utilizando solo los datos de la tarjeta. Los bancos deben verificar los detalles adicionales del pagador, como la dirección de facturación y el código postal.
Hay muchos matices similares. Así como alternativas a los pagos con tarjeta. En los Países Bajos y Alemania, por ejemplo, a la gente le gusta usar carteras de Internet locales. Los métodos de pago más populares en China son Alipay, WeChat Pay y UnionPay. ¡Y en Nigeria , para pagar bienes en Internet, los usuarios van al banco con efectivo!
Aceptamos todos los pagos populares, sin excepción, desde tarjetas bancarias hasta PayPal, monederos electrónicos, Google Pay, Apple Pay o SMS. Con la ayuda de Solid, el comerciante obtiene acceso para trabajar con todos los tipos de pago en una sola integración. Además, la pasarela tiene su propia protección contra el fraude, un sistema de enrutamiento de pagos, una herramienta para evitar contracargos irrazonables y mucho más.
Por qué probar los sistemas de pago y los riesgos de no probarlos
Muchos comerciantes están conectados a Solid. Por lo tanto, somos responsables no solo de nuestro negocio, sino también de la monetización de todos los clientes conectados a nosotros. Si algo sale mal de nuestro lado, estamos fallando a demasiadas empresas. Y viceversa: al probar y mejorar nuestro servicio de pago, mejoramos los productos de otras empresas.
Desafortunadamente, además de un pago exitoso, pueden ocurrir errores, tanto del sistema como del usuario. Es importante comprender que el 100% de los pagos nunca se realizarán correctamente en ningún lugar. Pero por nuestra parte, estamos obligados a hacer todo lo posible para que la conversión de pagos sea lo más posible.
Probar una pasarela de pago no es una tarea rutinaria, ya que es un mecanismo bastante complejo de decenas de microservicios e interconexiones. Probamos todo en tres etapas. Primero, verificamos cada tarea en un entorno aislado, luego las combinamos y las verificamos en el candidato de lanzamiento en la etapa, vemos cómo funciona todo en la integración, luego lanzamos y probamos todo nuevamente en producción.
Echemos un vistazo más de cerca a lo que tenemos que probar específicamente.
Características de probar sistemas de pago
El sistema de pago consta de interfaces API y web. No existen diferencias cardinales en las pruebas API y web para sistemas de pago, a diferencia de otros productos. La característica principal es probar pagos específicos para diferentes regiones, así como todos los servicios auxiliares.
Parece que es fácil probar el pago: debe realizar un pago, verificar que el dinero se debitó de una cuenta y se acreditó en otra. Pero hay matices. Los evaluadores necesitan conocer los detalles de los pagos en diferentes países y, a veces, los matices de las leyes locales y las regulaciones bancarias.
El segundo punto son los diferentes tipos de pagos: suscripciones, primer pago, autorización (congelación de dinero en la cuenta), pago a través de una billetera electrónica. Cada uno de ellos tiene sus propias especificaciones de prueba.
Se debe prestar especial atención al trabajo con monedas: no todas tienen una parte fraccionaria. Por ejemplo, la hryvnia tiene un centavo, pero el peso chileno no. Si transfiere el monto del pago 100 en Ucrania, el banco cancelará 1 UAH, es decir, 100 kopeks. Y en Chile eso significaría 100 pesos. Como puede ver, esos momentos no deben perderse.
Qué debe probarse en los sistemas de pago
Todos nuestros clientes (web, aplicaciones móviles, así como servicios back-end) se comunican con nosotros mediante Solid API . La puerta de enlace en sí está ubicada en un grupo separado y se comunica con varios sistemas (antifraude, tokenizador, bancos, etc.).
Los desarrolladores sólidos se dedican a resolver varios tipos de problemas (y todas estas tareas terminan a disposición del equipo de control de calidad):
- ( , , , , );
- (PayPal, Alipay Visa Mastercard);
- : API, ;
- ( , );
- , (, , -);
- .
Además de las tareas que vienen directamente de los desarrolladores, recibimos otras: verificar todos los datos y UAT al conectar nuevos comerciantes, verificar tareas del equipo de DevOps, configurar reglas antifraude.
En resumen, todo lo que probamos se puede dividir en las siguientes categorías:
Servicios de backend sólidos:
- anti fraude;
- servicio de suscripcion;
- enrutamiento de pago;
- sistema de control contable y financiero;
- integración con servicios externos.
Integración con bancos:
- verificar la corrección del trabajo con monedas;
- verificación de diferentes tipos de pagos (primer pago con datos de tarjeta, pago con token, reembolsos, congelación de dinero, etc.);
- procesamiento de notificaciones.
Métodos de pago alternativos (sin tarjeta):
- verificación del pago;
- comprobar las características de la ubicación.
Administración:
- panel de administración interno (todo lo que ayuda a los analistas de Solid a ejecutar pruebas A / B para la conversión de un formulario de pago, configurar reglas para antifraude);
- panel de administración para comerciantes.
Interfaces de usuario:
- aparición de formularios y páginas de pago;
- si el formulario se muestra en el idioma de una región en particular (el formulario de pago sólido está disponible en todos los idiomas del mundo);
- visualización correcta de la cantidad y monedas;
- seguimiento de las acciones de los usuarios en los formularios;
- estado de la página.
Otro:
- UAT al conectar un nuevo comerciante a Solid;
- tareas del departamento de riesgos para comprobar nuevas configuraciones;
- estudios de salud funcional (por ejemplo, Apple Pay funciona en WKWebView).
Pasos para probar el éxito
Automatización
Cuando trabaja con soluciones de TI a gran escala, como proveedores de pago, debe probar constantemente no solo el funcionamiento de los elementos funcionales individuales, sino también su interacción. No funcionará sin automatización. Si algún servicio no está cubierto por pruebas automáticas, no se pueden evitar fallas. Ejecute autotest siempre que sea posible. Vertió la tarea en el entorno: ejecute las pruebas. Fusionó varias tareas en una versión candidata: ejecute las pruebas.
En nuestro caso, es algo como esto:
- los desarrolladores ejecutan pruebas de forma independiente al implementar una tarea;
- los evaluadores ejecutan pruebas cuando prueban una tarea en un entorno aislado;
- las pruebas se inician automáticamente cuando se crea una nueva versión de la compilación;
- Los autotests se ejecutan constantemente en el entorno Prod.
La ejecución de pruebas automáticas lleva tiempo y, por lo tanto, siempre nos esforzamos por optimizar este proceso tanto como sea posible. Las pruebas se ejecutan con varios subprocesos y también se dividen en tareas según su importancia.
Tenemos un conjunto mínimo de pruebas que validan la funcionalidad principal de procesamiento de pagos de Solid: se ejecuta en menos de un minuto. Todas las demás pruebas de Solid API y otros microservicios tardan entre 3 y 4 minutos. Las pruebas de IU son, por supuesto, un poco más lentas. Pero incluso aquí no paramos de trabajar en la mejora y optimización.
¿Por qué las pruebas aisladas no son la mejor opción al probar los pagos? Te contaré sobre nuestro caso antifraude.
Cada comerciante de Solid tiene una cuenta antifraude relacionada con el establecimiento de reglas, cómo deben funcionar. Por ejemplo, si un usuario ha realizado más de tres pagos por día con un comerciante, bloqueamos el cuarto. O si más de cinco usuarios realizan pagos con la misma tarjeta, también los bloqueamos y los añadimos a la lista negra. Lo cubrimos con autotests, pero encontramos un problema.
Inicialmente, duplicamos todas las reglas para una cuenta de prueba, simulamos acciones fraudulentas y las pruebas parecieron funcionar. Pero resultó que el propio comerciante a menudo tiene situaciones en las que se combinan las reglas antifraude, por ejemplo, tres de ellas funcionaron.
Al aislar cada pago para cada regla específica, eliminamos la posibilidad de una combinación de reglas y la influencia de otros servicios en el proceso de pago.
Cómo realizamos cada pago: borramos los datos de prueba, creamos todas las condiciones para que el pago se rija por una determinada regla y funcionó. Pero no es un hecho que vaya a ser así en un entorno laboral, porque nunca existirá una situación ideal para que un pago caiga bajo una regla.
Decidimos conectar las reglas reales contra el fraude de nuestros clientes con el comerciante de prueba. Entonces empezaron a funcionar con más claridad. Es decir, era necesario crear reglas no aisladas, sino probarlas de forma agregada para un cliente en particular.
Ahora los clientes de Solid pueden personalizar las reglas antifraude por sí mismos. Porque las transacciones que parecen fraude para un comerciante pueden ser la norma para otro.
Si una persona realiza cinco compras por día en una tienda en línea, entonces esta es la norma: primero le gustó el estuche para el móvil, luego el portátil, etc. Pero para las aplicaciones de fitness, esto ya es una anomalía. Es poco probable que una persona compre cinco programas de entrenamiento al día.
La automatización realmente ayuda a construir un equilibrio: solo las características nuevas y los escenarios que requieren atención humana se verifican manualmente, todo lo demás está automatizado. La automatización puede ayudar a reducir tanto los costos de prueba como el riesgo humano.
Pruebas en la etapa de especificaciones técnicas.
Además de verificar directamente la funcionalidad de la funcionalidad, dedicamos mucho tiempo a asegurarnos de que los desarrolladores y gerentes perciban la funcionalidad implementada de la misma manera. Parece obvio, pero muchos lo descuidan.
Todos los servicios de configuración son bastante complejos, tienen una amplia gama de capacidades e incluso los detalles más pequeños pueden hacer que el servicio no funcione como se esperaba.
La técnica de "prueba temprana" tiene varias ventajas a la vez:
- el equipo de desarrollo comprenderá correctamente la tarea y no perderemos tiempo en correcciones;
- una especificación técnica bien redactada equivale al 70% de una buena documentación;
- Debido al hecho de que el equipo de pruebas se familiarizó con la especificación técnica de antemano, los escenarios de prueba también están pensados de antemano, y en el momento en que la tarea implementada llega a la prueba, el proceso va más rápido.
Buena documentación de prueba
La documentación interna realmente buena y estructurada es la mitad de la batalla al realizar las pruebas. A pesar de que casi todas las funcionalidades deberían automatizarse, el trabajo manual nunca se reducirá.
La descripción de los procesos de prueba para diversas funcionalidades, artículos con posible resolución de problemas y varios manuales agilizan el trabajo del equipo de pruebas.
En Solid hemos creado nuestra propia base de conocimientos. Describe cómo funciona cada banco y un método de pago alternativo en diferentes ubicaciones, qué tipos de pagos admite el banco y cómo, en principio, se realizan los pagos en una región en particular.
Esa base es una tarea amplia y compleja que se ha convertido en un desafío para nosotros. Era necesario reunir toda la documentación y describir los procesos de forma accesible. Pero ahora, cuando llega un nuevo empleado, no hay problemas. Es difícil recordar cómo debería funcionar algo la primera vez, y si hay documentación de prueba, la opción de cometer un error es mínima. La documentación clara permite al evaluador determinar exactamente por qué el pago no se realiza: es un error o este tipo de pago simplemente no debería funcionar en este banco.
Déjame darte otro ejemplo. Una vez cambiamos los logotipos de los sistemas de pago internacionales en las formas de pago. Disponemos de más de 200 diseños diferentes para nuestros clientes, para cada diseño puede haber varias configuraciones de campos en el formulario. Por ejemplo, para Brasil, se agrega un campo CPF adicional, un análogo de nuestro código de identificación.
Debido al nuevo tamaño del logotipo, algunos campos del formulario podrían moverse, desaparecer o dejar de ser clicables. Nadie en el equipo de pruebas de Solid sabe físicamente cómo deben verse los 200 formularios.
Probar esta tarea fue estresante, pero como resultado, creamos una base de conocimiento con formularios de referencia para cada uno de nuestros comerciantes, la cubrimos con pruebas automáticas y ahora no tememos ningún cambio relacionado con los diseños.
***
Finalmente, les contaré un pequeño dato interesante del mundo del procesamiento: la proporción de disminuciones de tarjetas restringidas en Ucrania es bastante baja: 1-2%. O los bancos ucranianos son tan buenos en la prevención del fraude, o nadie quiere robar los datos de las tarjetas de los usuarios ucranianos ...
Sin embargo, no existe un producto con procesos ideales de desarrollo y prueba, pero podemos mejorarlos. Después de todo, la tarea de todas las empresas es lanzar un producto de calidad. ¿Quién más, si no los ingenieros de control de calidad, ayudará con esto?
Me alegraría si compartiera sus principios de un buen proceso de prueba en los comentarios.