Siempre es bueno seguir a los expertos para mejorar, así que traemos la experiencia de Karim Fanadka, líder del QA en HP, quien ha liderado ingenieros responsables de la calidad del producto de prueba de rendimiento en la nube, StormRunner, mientras construye los marcos de prueba utilizando las técnicas de prueba más modernas.

Karim compartió, para TechBeacon, algunos consejos para que los equipos QA tengan mejores prácticas:

• Ir más allá del rol y responsabilidades

Muchos equipos TI, en la actualidad, están orientados al cliente, así que los responsables deben salir del área técnica y acercarse a los clientes que experimentan y estar dispuestos a escuchar las características que les gustaría ver en el producto. Así se participará de manera activa en las discusiones de diseño.

El conocimiento y experiencia en pruebas de código ayuda a identificar fallas de diseño antes de que alguien pase tiempo codificando, lo que reduce de manera sustancial los ciclos de desarrollo y tiene beneficios al momento de cumplir con las expectativas del cliente a medida que lanzamos nuevas versiones de forma adaptativa.

• Elige cuidadosamente los criterios de lanzamiento

Debes confiar en el producto que aprueba si se enfoca en las áreas de su código donde se realizaron los cambios más significativos. Antes de que comience un nuevo ciclo de lanzamiento, el equipo debe reunirse con todos los colaboradores ​​para comprender qué partes del producto podrían ser impactadas por código nuevo o actualizado. Utiliza esa información para priorizar los esfuerzos de prueba. Céntrate en esas partes del código y utiliza las pruebas de automatización existentes para manejar otras partes. Si sabe que algo funcionó en la última versión y no se tocará en esta versión, entonces no necesita pasar demasiado tiempo probando. Así que basa tus criterios de lanzamiento en el nuevo código que se agrega.

• Prioriza las correcciones de errores en función del uso

La corrección de errores es una parte integral de cualquier nueva versión, pero ¿en qué errores debe centrar tus esfuerzos? En los datos de uso. Pureba con Google Analytics para ver cómo interactúan los usuarios finales sin herramientas de prueba de carga. Esto da una gran cantidad de información vital. Por ejemplo, si sabemos que un área de una aplicación rara vez se usa, un error en esa parte del código tiene menor prioridad. Si menos del uno por ciento de nuestros usuarios están en un navegador en particular, los problemas específicos de ese navegador reciben menos atención. Pero también escuchamos a nuestros clientes. Lo último que queremos es que nuestros usuarios experimenten errores. Si algo nos pasa y los usuarios descubren errores, esos errores tienen prioridad para las correcciones en la próxima versión.

• Adopta un enfoque de dos niveles para la automatización de pruebas

Si una confirmación que un desarrollador hace al tronco principal rompe la compilación de alguna manera, se informa lo más rápido posible. Dicho esto, no es posible ejecutar pruebas exhaustivas del sistema para cada confirmación. Eso llevaría demasiado tiempo, y para cuando se encuentre un problema, el desarrollador podría haber pasado a otra cosa. Entonces, es recomendable adoptar un enfoque de dos niveles para la automatización de pruebas. El primer nivel se activa por cada confirmación de la base del código y proporciona una validación rápida de los cambios del desarrollador, con pruebas de integridad que se completan en varios minutos. El nivel dos ejecuta pruebas de regresión más exhaustivas y se ejecuta automáticamente por la noche, cuando tenemos más tiempo para probar los cambios. Decidir qué tan ligero o exhaustivo debe ser cada nivel es un arte. Pero una vez que comience a trabajar así, aprenderá rápidamente cómo equilibrar entre las pruebas de cordura diurnas y las pruebas de regresión nocturna.

• Probar en diferentes entornos

Todos los equipos de QA han escuchado el comentario del desarrollador, «Funciona en mi máquina». ¿Cómo evitas esa situación?

Es clave que los equipos de control de calidad y los equipos de desarrollo ejecuten exactamente el mismo entorno. Sin embargo, a medida que las compilaciones se mueven a través de la tubería de desarrollo, debemos probar el código en condiciones de producción, por lo que se debe construir un entorno de ensayo para simular los entornos de producción de los clientes.

• Busca formar un equipo de pruebas de seguridad dedicado

Debido al aumento en la oferta del Software as a Service (SaaS), las empresas almacenan todos los datos en sus servidores, y se necesitan realizar pruebas de seguridad antes de cada lanzamiento. Los usuarios tienden a descubrir vulnerabilidades de seguridad en las plataformas SaaS, y esos problemas pueden alejar rápidamente a los clientes. Para evitar eso, se puede formar un equipo de pruebas dedicado que realiza una semana completa de pruebas de penetración en versiones estables de productos y actualizaciones que se lanzarán próximamente. Antes de que comiencen las pruebas, se informa al equipo sobre las nuevas características en las próximas versiones y entornos de productos. El equipo usa esa información para probar vulnerabilidades de seguridad e intentar penetrar en el sistema. Estos miembros del equipo se someten a una rigurosa capacitación en seguridad y están familiarizados con los estándares de seguridad corporativos e ISO relevantes, con una especialización en aplicaciones en la nube.

• Busca formar un equipo dedicado de pruebas de desempeño

Haz que un equipo de rendimiento dedicado ejecute pruebas tan pronto como un producto sea estable, e informa al equipo sobre las nuevas versiones y características para que puedan evaluar los riesgos de rendimiento. Cuando los desarrolladores introducen una nueva característica que no tiene ningún efecto en el rendimiento, como un botón en la pantalla, sólo se ejecutan nuestras pruebas de regresión. Pero si se sospecha que una característica podría afectar el rendimiento, también se escriben y ejecutan nuevas pruebas de rendimiento.

Siempre actualiza sus equipos de seguridad y rendimiento con toda la información pertinente y bríndeles un entorno lo más cercano posible a la producción.

• Ejecuta un ciclo de regresión

Ejecutamos nuestro ciclo de regresión en la fase final de estabilización del producto, y es ese proceso el que desencadena la luz verde para pasar a la producción. Dado que hay muy pocos cambios en el desarrollo en este momento, tienes la oportunidad de validar todo el producto. Conceptualmente se modela el producto como un árbol con una jerarquía de módulos y ramas de componentes para ayudar a comprender el producto desde la perspectiva del cliente. Cuando se modifica cualquier rama, la jerarquía muestra qué ramas debajo de ella se verán afectadas y necesitarán pruebas de control de calidad adicionales.

Puede resultar útil utilizar un ciclo de regresión con el método del semáforo. Si cada sucursal recibe luz verde (pasa todas las pruebas), el producto se considera listo para la entrega. Si una sucursal recibe una luz amarilla (todas las pruebas pasaron pero con una o más advertencias informadas), se discute el problema con nuestros interesados. Finalmente, si una rama recibe una luz roja (una o más pruebas fallaron), hay que detenerse y atender el problema.

• Simula cuentas de clientes en producción

Dado que se mantien los datos del cliente en las bases de datos, se deben asegurar de que sigan siendo compatibles con cualquier versión nueva que publiquemos. Cuando el equipo de control de calidad ejecuta pruebas de migración de datos, se crea una cuenta de prueba que se administra en nuestros sistemas de producción.

Cuando se lanza una nueva versión, se jectuan actualizaciones para verificar que no se dañaron los datos, y si encontramos algún error que corrompa los datos, estos se convierten en nuestra máxima prioridad. También pasamos uno o dos días en pruebas manuales de compatibilidad con versiones anteriores mientras tomamos medidas para encontrar un enfoque automatizado y más eficiente. Sin embargo, aún necesita hacer algunas pruebas manuales, ya que esta es una de las últimas fases antes de la producción.

• Realiza pruebas de cordura en la producción

Realizamos pruebas de cordura posteriores al lanzamiento en nuestra cuenta de producción para validar que todo funcione como se espera, incluidos todos los sistemas de terceros. Primero realizamos pruebas con nuestra cuenta de producción existente, pero luego creamos una cuenta nueva para validar que el proceso continuará funcionando correctamente a medida que se registren nuevos clientes. Llevamos a cabo pruebas de cordura durante medio día, donde parte del equipo prueba la cuenta anterior y la otra prueba la nueva. Finalmente, probamos componentes de terceros, como el sistema de facturación, para garantizar la compatibilidad de versiones.

La ingeniería de rendimiento ha cambiado los roles y procesos tradicionales de los Ingenieros de QA. Hoy, debe tener equipos altamente especializados y dedicados, así como un proceso continuo de control de calidad a través de la producción y más allá. Además, para desempeñar su función a fondo y satisfacer a sus clientes, debes estar dispuesto a ser un cliente tú mismo.

Para mantener la calidad del producto y al mismo tiempo satisfacer la demanda de lanzamientos frecuentes del producto, los evaluadores de control de calidad deben romper los moldes tradicionales. Debes desarrollar nuevas habilidades, como el diseño y desarrollo de software, para poder involucrarse más en las diferentes etapas del proceso de desarrollo.

imagen: biancoblue