Las 10 buenas prácticas de QA

Leandro Neme Jose de QAdvance comparte en este artículo las 10 buenas prácticas que su empresa ha adoptado para hacer que la carga de trabajo sea manejable y garantizar que las novedades y fixes que aprueban mantengan los más altos estándares de calidad sin tener que resignar horas de calidad familiar

Por Leandro Neme Jose de QAdvance

Como fundador de QAdvance, empresa de testing y líder de varios equipos de control de calidad (QA), tengo la responsabilidad de homologar y firmar un conjunto de cambios funcionales, técnicos por cada versión que ingresa a proceso de testing y QA. Contamos con 11 ingenieros de control de calidad trabajando en código desarrollado por 43 desarrolladores.

Es una tarea difícil de llevar. Por lo tanto, para evitar tener que resignar horas de calidad familiar en post del cumplimiento, hemos adoptado estas 10 buenas prácticas para hacer que la carga de trabajo sea manejable y garantizar que las novedades y fixes que aprobamos mantengan los más altos estándares de calidad.

1. Libérate de las funciones y responsabilidades clásicas de QA

Hemos traspasado los límites en ambas direcciones. Somos una unidad orientada al cliente, y escuchamos a nuestros clientes sobre los problemas que experimentan y las funciones que les gustaría ver en nuestro producto. En el otro extremo, participamos activamente en las discusiones de diseño, ofreciendo los comentarios que recibimos de los clientes. Además, nuestro conocimiento y experiencia en pruebas de código nos ayudan a identificar fallas en los diseños antes de que alguien dedique tiempo a la codificación, lo que reduce significativamente los ciclos de desarrollo y nos ayuda a cumplir con las expectativas del cliente a medida que lanzamos nuevas versiones.

2. Elija cuidadosamente su estrategia de prueba.

No se puede probar todo en un producto empresarial para cada release y, afortunadamente, no es necesario. Aún puede 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 testing, nuestro equipo se reúne con todas las partes interesadas para comprender qué partes del producto serán tocadas por un código nuevo o actualizado. Usamos esa información para priorizar nuestros esfuerzos de prueba. Nos centramos en esas partes del código y utilizamos las pruebas de automatización existentes para manejar otras partes. Si sabe que algo funcionó en la última versión y no lo está tocando en esta versión, entonces no necesita dedicar demasiado tiempo a las pruebas. Así que basa sus criterios de lanzamiento en el nuevo código que se está agregando.

3. Dar prioridad a las correcciones de errores en función del uso

Arreglar errores es una parte integral de cualquier nueva versión, pero ¿en qué errores debería enfocar sus esfuerzos? Nuestra respuesta es datos de uso. Utilizamos una herramienta de análisis para ver cómo interactúan los usuarios finales. Esto nos da una gran cantidad de información vital. Por ejemplo, si sabemos que un área de una aplicación rara vez se utiliza, 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 pasó y los usuarios descubrieron errores, esos errores tendrán prioridad para las correcciones en la próxima versión.

4. Adoptar un enfoque de dos niveles para probar la automatización.

Si un compromiso que un desarrollador realiza en el troncal principal rompe la compilación de alguna manera, les informamos lo más rápido posible. Dicho esto, no podemos ejecutar pruebas exhaustivas del sistema para cada compromiso. Eso llevaría demasiado tiempo, y para cuando se pudiera encontrar un problema, el desarrollador podría haberse mudado a otra cosa. Entonces, adoptamos un enfoque de dos niveles para probar la automatización. El nivel uno se activa por cada compromiso con el código base y proporciona una validación rápida de los cambios del desarrollador, con pruebas de cordura que se completan en unos 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 cuán ligero o exhaustivo debe ser cada nivel es un arte. Pero una vez que empiezas a trabajar así, aprendes rápidamente cómo equilibrar las pruebas de cordura diurna y la regresión nocturna.

5. Manténgase cerca del entorno relevante

Cada equipo de control de calidad ha escuchado el comentario del desarrollador, “… pero funciona en mi máquina”. ¿Cómo evitar esa situación?

Nuestro control de calidad y nuestros equipos de desarrollo ejecutan exactamente el mismo entorno. Sin embargo, a medida que nuestras construcciones se mueven a través del proceso de desarrollo, debemos probar el código en condiciones de producción, por lo que construimos nuestro entorno de pruebas para simular los entornos de producción de nuestros clientes.

6. Formar un equipo de pruebas de seguridad dedicado

Debido a que los clientes consumen nuestros productos como una oferta de software como servicio (SaaS), almacenamos todos los datos en nuestros servidores y debemos realizar pruebas de seguridad antes de cada lanzamiento. Las vulnerabilidades de seguridad en las plataformas SaaS tienden a ser descubiertas por los usuarios, y esos problemas pueden alejar rápidamente a los clientes. Para evitarlo, formamos 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, informamos al equipo acerca de las nuevas características en las próximas versiones y entornos de productos. El equipo utiliza esa información para probar las vulnerabilidades de seguridad para intentar penetrar en el sistema. Estos miembros del equipo reciben 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.

Con su ayuda, nuestro equipo descubrió recientemente una vulnerabilidad de seguridad, creada por uno de los principales proveedores de entornos de nube, que habría permitido a los hackers maliciosos obtener información valiosa. Actualizamos rápidamente nuestra infraestructura en la nube de Amazon para evitar una violación.

7. Formar un equipo de pruebas de performance dedicado

Haga que un equipo de rendimiento dedicado realice pruebas tan pronto como el producto esté estable, e informe al equipo sobre las nuevas versiones y características para que puedan evaluar los riesgos de rendimiento. Cuando los desarrolladores introducen una nueva función que no afecta el rendimiento, como un botón en la pantalla, solo ejecutamos nuestras pruebas de regresión. Pero si sospechamos que una característica puede afectar el rendimiento, también escribimos y ejecutamos nuevas pruebas de performance.

Actualice siempre 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.

8. Ejecutar un ciclo de regresión

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

Si todas las pruebas de regresión resultan OK, el producto se considera listo para su entrega. Si una o mas pruebas reciben una advertencia (todas las pruebas pasaron pero con una o más advertencias reportadas), discutimos el problema con nuestros interesados. Finalmente, si una prueba falla , paramos y resolvemos el problema. También automatizamos nuestro ciclo de regresión, por lo que solo demora unos días en ejecutarse.

9. Simular cuentas de clientes en producción.

Dado que mantenemos los datos simulados de los clientes en nuestras bases de datos, (mismas condiciones con datos ficticios) debemos asegurarnos de que sean compatibles con cualquier versión nueva que publiquemos. por lo que cuando el equipo de control de calidad ejecuta las pruebas de migración de datos, creamos una cuenta de prueba que se administra en nuestros sistemas de producción. Utilizamos esta cuenta para generar datos continuamente y llenar nuestras bases de datos.

Cuando lanzamos una nueva versión, ejecutamos actualizaciones para verificar que no se dañó ningún dato, y si encontramos algún error que corrompe los datos, se convierten en nuestra máxima prioridad. También dedicamos uno o dos días a realizar pruebas de compatibilidad manuales hacia atrás mientras tomamos medidas para encontrar un enfoque automatizado y más eficiente. Sin embargo, todavía necesita hacer algunas pruebas manuales, ya que esta es una de las últimas fases antes de la producción.

10. Realizar pruebas de cordura en producción.

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

La ingeniería de rendimiento ha cambiado los roles y procesos tradicionales de los ingenieros de control de calidad. Hoy en día, 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 papel a fondo y satisfacer a sus clientes, tiene que estar dispuesto a ser un cliente usted mismo.

Para mantener la calidad del producto y satisfacer la demanda de lanzamientos frecuentes de productos, los evaluadores de control de calidad deben romper los moldes tradicionales. Debe desarrollar nuevas habilidades, como el diseño y desarrollo de software, para poder participar más en las diferentes etapas del proceso de desarrollo. Seguir estas 10 mejores prácticas es un ganar-ganar para su equipo y el negocio. Hágalo bien, acortará los ciclos de desarrollo y hará que el trabajo de sus profesionales de control de calidad sea más atractivo

 

Leandro Neme Jose
Co-fundador QAdvance Testing Services
www.qadvance.com.ar

Etiquetas
Mostrar más

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Close