Imagina que el software más importante de tu empresa deja de funcionar de repente. ¿Qué sucedería? Se podrían perder pedidos, no se cumplirían los plazos, pero los clientes definitivamente se quejarían.
Esta situación catastrófica se puede evitar si implementas un proceso de pruebas continuo y riguroso que detecte los problemas antes de que causen caos. Sin embargo, implementar este proceso en tu organización es más fácil decirlo que hacerlo.
En este documento, se muestra todo lo que debes tener en cuenta cuando comiences a realizar pruebas en tu empresa y cómo puedes beneficiarte de las pruebas a largo plazo.
Prácticas recomendadas de pruebas para equipos de productos
En la primera parte de este documento, se aborda el proceso para comenzar a implementar pruebas en tu flujo de trabajo.
Implementa una cultura de pruebas en tu equipo
Para introducir las pruebas en tu equipo de forma exitosa, es necesario que todos compartan una mentalidad común y consideren la calidad no como una carga, sino como una inversión. Este es un proceso que, como cualquier otro cambio cultural, requiere tiempo y coherencia.
Una de las cosas que pueden ayudar a dar forma a esta cultura son las reuniones periódicas para analizar los defectos, el impacto que tuvieron, de dónde provienen y qué se necesitó para corregirlos. Esto ayuda a crear conciencia sobre por qué es bueno evitar esos defectos en primer lugar.
Tener una persona dedicada en el equipo que supervise y dirija el esfuerzo puede aumentar considerablemente las posibilidades de éxito. Alguien que defina lineamientos para el equipo, o incluso para toda la organización, recopile prácticas recomendadas, las comparta y defienda el esfuerzo en todos los niveles.
Otro instrumento útil puede ser rotar el rol de asistencia de tu producto. Obtener estadísticas directas y sin filtrar de tus clientes y conocer los problemas cotidianos que enfrentan con tu producto puede ser una experiencia valiosa para los administradores de productos, los diseñadores y los desarrolladores.
El objetivo es que todos en tu equipo comprendan que la calidad es una función, tan importante como cualquier otra funcionalidad que crees para tu producto. Una vez que todos adopten esa mentalidad, es una progresión natural comprender que las pruebas también son una función. Esto se debe a que las pruebas son lo que garantiza la calidad del producto enviado.
Un proceso de pruebas paso a paso
Una vez que haya alineación entre los diferentes equipos involucrados en el desarrollo de productos, puedes formalizar aún más la existencia y el uso de las pruebas.
Incluye las pruebas en la "Definición de finalizado"
Si agregas pruebas como requisito de función, declaras que una función no está lista para enviarse hasta que se pruebe de forma adecuada y automática.
Ejecuta pruebas con regularidad
Una vez implementadas, las pruebas automatizadas pueden ser tu protección en cada paso del proceso de desarrollo. No necesitan intervención humana y se pueden ejecutar en cada paso fundamental de tu canalización de desarrollo. Por ejemplo:
- En cada confirmación
- En cada solicitud de extracción
- Después de cada versión completa o cambio de entorno
Si dependes de servicios de terceros en tu entorno de producción, incluso puede ser conveniente ejecutar las pruebas en la producción para garantizar que las APIs de terceros se comporten como se espera.
Define y recopila métricas
Definir un conjunto de métricas es importante para medir la eficacia de tus pruebas y el impacto de los flujos de trabajo de pruebas en tu empresa. Estos son algunos ejemplos de métricas que puedes usar:
- Versiones por mes: Una mayor cantidad de versiones por mes puede indicar un proceso de desarrollo más ágil. Las pruebas automatizadas desempeñan un rol clave aquí, ya que garantizan que las versiones puedan continuar con confianza.
- Informes de errores: Una tendencia decreciente en los informes de errores puede ser un signo positivo de que tus pruebas (y procesos de desarrollo) son eficaces.
- Cobertura de pruebas: Si bien nunca es una métrica exacta, la cobertura puede ser un buen indicador de la profundidad con la que pruebas los casos de uso críticos.
Ten en cuenta que estas métricas también están influenciadas por otros factores que pueden sesgarlas. Por ejemplo, la cantidad de versiones puede disminuir en una temporada de vacaciones, mientras que los informes de errores aumentan. Por lo tanto, no dependas solo de algunas y asegúrate de correlacionarlas con otros datos disponibles para tu equipo.
Si implementas esos pasos de forma exitosa con tu equipo, la salud de tu producto definitivamente se beneficiará a largo plazo. Pero aún puedes hacer más.
Prácticas recomendadas de pruebas para administradores del sistema
Los equipos de productos no pueden trabajar por su cuenta. Dependen del hardware, las herramientas y la infraestructura que mantienen los administradores del sistema. Si bien los administradores del sistema no suelen contribuir directamente al desarrollo de productos, pueden influir en el flujo de trabajo de desarrollo para bien. Por ejemplo, si administran de forma activa la versión del navegador que usan ciertos grupos de usuarios de la empresa.
En esta segunda parte del artículo, se explica cómo funciona esto con los canales de versiones de Chrome y las políticas empresariales.
Canales de versiones de Chrome
Hay cuatro canales de versiones: estable, beta, para desarrolladores y Canary.
Para obtener más información, consulta Canales de versiones de Chrome.
Uso de canales en una organización ejemplar
La estructura de los equipos de productos varía entre las organizaciones, ya que no existe un enfoque único para el desarrollo de software. Como ejemplo, supondremos un equipo con los siguientes roles: administración de productos, UX y UI, ingeniería, operaciones y asistencia.
Para una organización como esta, puedes pensar en la siguiente división de canales:
- Administración de productos: Por lo general, los administradores de productos pueden estar en el canal estable para usar la misma versión que la mayoría de los usuarios. En ocasiones, podrían usar el canal beta o para desarrolladores si están trabajando en una función que requiere una API que aún no se lanzó.
- Ingeniería y UX: Algunas partes de estos equipos pueden estar en el canal para desarrolladores para darles acceso a las funciones más recientes, como las transiciones de vista, incluso antes de que estén en la versión estable.
- Operaciones: Podría estar en la versión beta para prever las interrupciones que afectarán a los usuarios a continuación.
- Asistencia: Puede permanecer en el canal estable para asegurarse de que están interactuando con el producto con el mismo navegador que la mayoría de tus clientes.
Usa políticas empresariales para administrar canales
En lugar de proporcionar lineamientos y dejar la decisión sobre qué canal usar, Chrome también ofrece herramientas empresariales y de administración para administrar de forma activa qué canal termina usando cada usuario. Esto es útil, ya que aumenta de inmediato la superficie de pruebas de unos pocos usuarios individuales a un conjunto determinista de usuarios, lo que ayuda a identificar las interrupciones lo antes posible y de forma trazable.
Si deseas usar ese nivel de control, esta es la configuración que te recomendamos:
- Empleados (usuarios de la app): Para minimizar el riesgo de interrupción, la mayoría de los empleados deben estar en el canal estable, que el equipo de pruebas de Chrome probó por completo. Además, un pequeño porcentaje de usuarios (del 5 al 10%) puede estar en el canal beta. Este canal obtiene una vista previa de 4 a 6 semanas de la versión estable y puede ayudar a los administradores a descubrir posibles problemas con una versión, lo que les da más tiempo para abordar los problemas antes de que se lance la versión para todos los demás.
- Departamento de TI: Los miembros del departamento de TI, incluidos los administradores del sistema pueden estar en el canal beta o para desarrolladores para obtener una vista previa de 4 a 6 o 9 a 12 semanas de lo que se incluirá en la versión estable de Chrome.
Canales de versiones a largo plazo
Es posible que el desarrollo de productos no sea tan rápido como se planeó y que la cadencia de versiones de Chrome de un mes sea demasiado alta. Para este caso de uso, Chrome proporciona un canal estable extendido que permite obtener actualizaciones de funciones con menos frecuencia, pero que aún recibe correcciones de seguridad. Este canal se actualiza cada ocho semanas.
En el siguiente diagrama, se muestra cómo avanzan los diferentes eventos importantes a través de los diferentes canales de versiones de Chrome:
- Los canales estable y estable extendido envían las mismas versiones durante las primeras cuatro semanas, después de las cuales divergen.
- No hay un canal beta extendido. En cambio, se usa el ciclo beta estándar de cuatro semanas para estabilizar los canales estable y estable extendido. Las empresas que eligen participar en el canal estable extendido de ocho semanas deben seguir ejecutando el canal beta como lo hacen hoy para identificar de forma proactiva los problemas que puedan afectar sus entornos.
La importancia continua de los canales beta y para desarrolladores para los usuarios estables extendidos
Si bien el canal estable se acelera a un ciclo de versiones de dos semanas y tu organización adopta el ciclo estable extendido de ocho semanas para obtener más tiempo para las pruebas, sigue siendo fundamental usar los canales beta y para desarrolladores. No hay canales "beta o para desarrolladores extendidos" separados. Los canales beta y para desarrolladores estándar se usan para estabilizar las versiones estable y estable extendido.
Si continúan ejecutando los canales beta y para desarrolladores, las empresas mantienen la capacidad de identificar de forma proactiva los problemas que podrían afectar sus entornos. Los canales beta y para desarrolladores proporcionan una vista previa de cuatro semanas de la próxima versión estable. Para los usuarios estables extendidos, esta ventana de vista previa es esencial para descubrir y abordar posibles interrupciones mucho antes de la actualización de funciones de ocho semanas.
Los canales beta y para desarrolladores actúan esencialmente como el sistema principal de alerta temprana para cualquier cambio que se produzca en tu entorno estable extendido de ocho semanas, lo que garantiza que tus apps empresariales sigan siendo compatibles. Los administradores del sistema pueden seguir asignando un grupo pequeño y determinista de usuarios (por ejemplo, del 5 al 10% de los usuarios de la app) a los canales beta y para desarrolladores para maximizar este beneficio.
Conclusión
Las pruebas son una parte fundamental de las empresas de desarrollo de software para garantizar la calidad de sus productos y también un paso importante para los administradores del sistema, para dar a los empleados de una organización acceso a software de alta calidad y evitar interrumpir los procesos empresariales.
Para tener éxito cuando implementes un flujo de trabajo de pruebas dentro de tu organización, es importante que todos compartan la mentalidad común de que la calidad y, por lo tanto, las pruebas son una función.
En este documento, revisamos diferentes formas de integrar las prácticas recomendadas de pruebas en tu organización. Para obtener una revisión detallada de las herramientas de pruebas existentes, consulta nuestro artículo Herramientas de Chrome para pruebas automatizadas y sin fricciones.
Para obtener orientación sobre las pruebas, de principio a fin, consulta también nuestro reciente curso de Learn Testing y las prácticas recomendadas de automatización de pruebas en web.dev.