Penpot

Desafío

Penpot recurrió a QAwerk para asegurarse de que podría lanzar su producto al público general dentro del plazo establecido. Querían que su equipo interno se centrara en el desarrollo de características de valor añadido y en pulir la funcionalidad del producto en lugar de preocuparse por los errores y las formas de capturarlos.

He aquí un breve resumen de lo que se esperaba de nosotros:

• Diseñar una estrategia y un plan de pruebas. Antes de asociarse con QAwerk, el equipo de Penpot informaba de los errores con la ayuda de los miembros del equipo interno y de su gran comunidad de usuarios de la versión beta. Con el crecimiento de la popularidad de Penpot y su intención de eliminar la etiqueta beta de su aplicación, este enfoque ya no era sostenible. Por eso nos pidieron que planificáramos todo el esfuerzo de pruebas y estableciéramos flujos de trabajo de control de calidad adecuados para sentar las bases de las pruebas profesionales continuas en el futuro.
• Pasar de la versión beta a la oficial. Eliminar errores y mejorar el rendimiento antes de lanzar el producto al público como comercialmente listo era primordial para Penpot. Nuestra tarea consistió en revisar metódicamente toda la funcionalidad existente y encontrar tantos problemas como fuera posible para garantizar que no quedaran errores críticos y que la aplicación funcionara sin retrasos ni problemas de ahorro de datos.
• Pulir las nuevas funcionalidades. La versión de producción incluía algunas funcionalidades muy esperadas, como interfaces flexibles, acceso al código directamente desde el área de trabajo y mejoras en la accesibilidad, entre otras cosas. Nuestra tarea consistió en asegurarnos de que estas actualizaciones se integraban a la perfección, no causaban interrupciones en la funcionalidad existente y hacían que los usuarios estuvieran realmente entusiasmados con el uso de Penpot.

Además, queríamos ayudar a Penpot a conseguir una mejor cobertura y a lanzar actualizaciones con tranquilidad. Así que les ofrecimos mejorar las pruebas manuales con la automatización de pruebas.

Solución

Cuando acabábamos de empezar las pruebas, nos encontramos con una gran cantidad de errores internos del servidor que aparecían de forma bastante aleatoria, y no estaba claro cuál era la causa inicial de este comportamiento. Estos errores requerían una solución inmediata, ya que los usuarios que los experimentaban podían perder su trabajo.

Así que grabábamos vídeos para capturar los pasos exactos para reproducir este tipo de error, intentando encontrar un patrón común entre estos sucesos y averiguar qué acciones del usuario podrían haber desencadenado los errores y qué áreas de la aplicación son más propensas a ellos. Compartimos nuestros hallazgos con los desarrolladores de Penpot y, finalmente, erradicaron este problema por completo.

Nuestras pruebas incluían varios tipos de pruebas:

• Pruebas funcionales. Comprobamos si la autorización de usuarios se realizaba sin problemas. Probamos a fondo los módulos de perfil de usuario, panel de control y espacio de trabajo. Nos aseguramos de que todos los cambios se aplicaban al diseño sin retrasos, especialmente durante la edición colaborativa.
• Pruebas de regresión. El equipo de Penpot envía continuamente nuevas funciones y actualizaciones de las funciones existentes, lo que requiere pruebas de regresión regulares. Combinamos pruebas de regresión manuales y automatizadas para lograr la mejor cobertura y resultados consistentes.
• Pruebas de interfaz de usuario. La elegante apariencia visual de la interfaz de usuario es primordial para cualquier aplicación moderna, especialmente para una herramienta de diseño como Penpot utilizada por profesionales de UI/UX y de producto en grandes corporaciones. Comprobamos la posición y la alineación de los elementos en cada interfaz y nos aseguramos de que los patrones de la interfaz de usuario fueran coherentes en toda la aplicación.
• Pruebas de compatibilidad. Nuestros ingenieros de control de calidad probaron Penpot en tres navegadores principales: Firefox, Chrome y Safari. Probamos Penpot en varias versiones de Safari, ya que algunos errores sólo aparecían en versiones anteriores. También utilizamos tres sistemas operativos diferentes, Windows, macOS y Linux, para garantizar que todos los usuarios puedan beneficiarse de Penpot independientemente de sus dispositivos.

En cuanto a la automatización de pruebas, nos centramos principalmente en los casos de pruebas de regresión.

Automatización de pruebas

La automatización de las pruebas se llevó a cabo utilizando el framework Playwright. Playwright está diseñado para simplificar la automatización entre navegadores y plataformas, por lo que se adapta bien a nuestras necesidades.

Al seleccionar los casos de prueba para la automatización, seguimos dos reglas: los casos de prueba deben tener un gran impacto y su preparación no debe consumir demasiado tiempo. De esta forma, se puede ver un ROI positivo.

Por ejemplo, no automatizamos casos como el registro o el olvido de contraseña porque aquí hay que tratar con API de terceros, como Gmail, y automatizar este flujo no merece la pena. O casos con acciones de arrastrar y soltar o copiar y pegar porque Playwright no siempre las gestiona correctamente y las pruebas pueden ser inestables.

Automatizamos casos de prueba como el inicio de sesión, la creación y eliminación de archivos, la apertura y el cambio de nombre de archivos, la creación y eliminación de tableros, la adición de desenfoque a los tableros, el cambio del color de fondo, entre muchos otros. Están disponibles en el repositorio público de Penpot.

También aprovechamos las comparaciones visuales de Playwright para realizar pruebas instantáneas. Para minimizar el número de pruebas fallidas debidas a cambios en la interfaz de usuario, utilizamos capturas de pantalla que capturaban un único elemento o sección, como una forma creada. De este modo, si se añadían nuevas secciones al panel de diseño, no afectaban a la estabilidad de la prueba.

Alrededor del 10% de nuestros casos de prueba requieren capturar toda la pantalla, por ejemplo, cuando necesitamos comprobar no sólo las capas, sino también la barra de herramientas. Aquí utilizamos el enmascaramiento para ignorar elementos con contenido dinámico, como marcas de tiempo o nombres de usuario. Aunque es imposible eliminar por completo los falsos positivos, actualizar estos casos de prueba es fácil y rápido.