BBVA API Market
Nunca debes subestimar el plan de pruebas. Cuando se desarrolla un proyecto de software es crucial asegurar la calidad que el cliente espera, así como revisar que se cumplen los criterios que se acordaron en la definición del mismo. Tenemos que procurar que no se produzcan errores, bugs o cualquier condición que haga fallar nuestro software.
El concepto de QA surge de dicho compromiso de calidad. Todo equipo de desarrollo debería contar con al menos un responsable encargado de asegurar el correcto funcionamiento del software que se desarrolla. No debe interpretarse como alguien que constantemente está corrigiendo lo que hacen mal los desarrolladores, sino como un facilitador para la realización de pruebas de testing que demanda el software.
QA en equipos scrum
Cuando un equipo de desarrollo implanta una metodología como Scrum duda dónde encajar el tema del testing. La concepción tradicional relega a QA al final de todo el proceso. Un tremendo error si pretendemos ser ágiles: conseguir que nuestra empresa pueda moverse rápido desarrollando poco a poco y contrastando las expectativas del cliente para subir a producción en pequeños sprints de dos semanas, por ejemplo. Y, por supuesto, ir rectificando rápidamente lo que no funciona o no acaba de encajar.
Para conseguir los objetivos que plantean las metodologías ágiles, desarrollo y QA deben ir de la mano, integrados en el día a día. En esta concepción y en la definición de equipo de trabajo, cada equipo de desarrolladores debería contar con un encargado de QA que siga el proceso de desarrollo durante la concepción, análisis, desarrollo y, obviamente, verificación.
Durante la fase de concepción QA debe ser consciente de las expectativas que se persiguen. Es decir, qué tipo de requisitos y cómo quiere verlo implementado el Product Owner del proyecto (o cliente en su caso). Con esto se puede comenzar a crear los primeros test de aceptación que serán usados en la fase de verificación.
Durante el desarrollo se debe contar con herramientas de integración continua que combinen los test unitarios más propios de las metodologías de TDD que ha usado el desarrollador para implementar las funcionalidades con los test de integración.
Las responsabilidades de QA
QA debe situarse entre la parte de negocio y la parte técnica. Ayudar al negocio a traducir lo que el cliente quiere en pruebas y, por otro lado, validar los criterios de aceptación del software implementado por los desarrolladores.
QA no se limita a detectar fallos, sino a anticiparse y verificar toda la casuística posible para ser validada por todos los actores implicados.
Debe ser responsable de crear un entorno de pruebas adecuado. El programador durante su proceso de desarrollo necesita un entorno de pre-producción y de staging con datos reales, pero que no influyan en la parte de producción de la aplicación. El QA definirá parte de esos datos y procesos acordes con la realidad que nos encontraremos cuando salgamos a producción.
Las tareas de preparación de datos pueden ser bastante tediosas, por ello, es necesario que se automaticen en procesos que logren conseguir entornos fácilmente reproducibles para los distintos escenarios.
Aspectos a la hora de definir un plan de testing
A la hora de definir un plan de testing debemos recopilar los requisitos funcionales que definen el alcance del proyecto. Esto es el núcleo que conforma la parte del negocio que fijamos con el cliente y los usuarios.
Fijar un tiempo claro de pruebas. Preferiblemente desde el inicio. Aunque el proyecto vaya mal en tiempo o en costes nunca hay que recortar el tiempo de pruebas. Hay que asegurar que el proyecto que entreguemos esté libre de errores. Cuando se avanza de forma precipitada es cuando precisamente se cometen más fallos.
Es muy recomendable involucrar a los usuarios claves que han participado en la definición de los requisitos de las aplicaciones. Recoger feedback frecuentemente.
Tener en cuenta los test de regresión: cuando se corrija un error debemos volver a testear todo. Es fundamental asegurarnos que no se haya roto nada por otro lado.
No debemos olvidar las pruebas de carga, es la única forma de que probemos al 100% que toda la parte técnica funciona correctamente. Es decir, que la infraestructura sea capaz de dar soporte al número de usuarios esperado. La escalabilidad es un tema clave en grandes proyectos de software.
Y por último, recuerda mantener estables tus entornos de pruebas: pre-producción y staging. Nunca hagas pruebas en producción. Ten en cuenta que puedes ocasionar problemas reales a los usuarios actuales.
Llevar a un cliente por todo el proceso de compra hasta que este se formaliza es un viaje arduo y que se enfrenta a la posibilidad constante de abandono. Sin embargo, hay formas de lograr que la decisión de compra se haga realidad si se le dan facilidades como una financiación ágil, segura y adaptada a lo que necesita.
En un mundo conectado, las APIs son el pegamento que une todas las piezas que forman nuestra vida diaria. Y de la misma forma que un pegamento solo es potente si sabemos en qué material utilizarlo y conocemos sus propiedades, las APIs son tan útiles como su documentación permita.
Existen diferentes soluciones para monitorizar el rendimiento de una API, tanto en términos de tráfico como de calidad y rapidez de las respuestas que proporciona. Detectar fallos en el código o cuantificar los ingresos que genera también son algunas de las opciones que ofrecen estas útiles herramientas.
