— ¿Cómo aplicar el proceso de llevar la organización y fácil para el bug de bash cremona

Importante: Este es un paso a paso de cómo organizar un bug de bash. Se puede encontrar más información sobre los beneficios de su uso en QuintoAndar en el artículo «Cómo los ataques de errores con frecuencia y consistentemente cambiaron la mentalidad del equipo hacia la calidad y la conexión construida en QuintoAndar».

Introducción

Bug Bash es una metodología de prueba, definida originalmente por Ron Patton en su libro Pruebas de software en 2001. Este enfoque de pruebas ha sido útil en diferentes escuadrones de QuintoAndar y, como resultado, hemos creado un proceso para optimizar su aplicación.

¿Error qué?!

Escuché por primera vez el término bug bash en mi entrevista de reclutamiento en QuintoAndar y sonó bien. Más tarde, estaba en línea buscando más información solo para descubrir que esta era una práctica bastante extendida, utilizada por muchas empresas con una cosa en común: un entorno ágil. Bug Bash es una metodología de prueba definida originalmente por Ron Patton, 2001. En su libro «Pruebas de software», describe bug bash como un procedimiento en el que todas las personas involucradas en el ciclo de desarrollo del producto, dejan de lado sus tareas diarias regulares y «golpean el producto». Por lo tanto, todos los que de alguna manera han tenido algo que decir sobre el producto, desde la definición hasta el diseño, desde el desarrollo hasta el marketing, deben estar en la misma sala, probando la función, de tantas maneras como sea posible antes de lanzarla.

Acerca al equipo, desde las partes interesadas hasta el desarrollo, para cubrir tantos escenarios de prueba como sea posible y, por lo tanto, reducir las posibilidades de una versión defectuosa. Reconociendo que esto podría ser una alternativa viable y valiosa a nuestro ritmo de trabajo rápido e intenso, comenzamos a introducir lentamente el concepto en el equipo, siempre mejorando y adaptando el enfoque de acuerdo con las necesidades de la función.

Heaven, ¿eres tú?

Suena como un sueño, pero si alguna vez ha dirigido un bug bash, probablemente sepa lo caótico que puede llegar a ser reunir tantos perfiles diferentes en una habitación: algunas personas plantean dudas sobre si se trata de un bug o no, otros preguntan dónde informar de los hallazgos, otros tienen problemas para acceder al sistema, todos discuten cómo hacer un seguimiento y priorizar las correcciones de errores durante las pruebas, etc. Sin una preparación mínima, es probable que se pierdan detalles importantes entre las preguntas y el post-its, la gente se frustre por no ser escuchada y, en última instancia, lo que debería ser el tiempo más productivo encontrar errores puede resultar una pérdida de tiempo para todo el equipo.

Además de la complejidad inherente de coordinar un bug bash, también tuvimos el desafío de aplicar el concepto en un producto que ofrece una solución empresarial completa: desde la búsqueda de propiedades hasta la administración de alquileres. Eso significa entregables de back-end y front-end a lo largo de toda la experiencia del usuario. Por lo tanto, aquí en QuintoAndar, era imperativo tener un proceso flexible y adaptable que pudiera adaptarse a ambos escenarios.

Sabíamos que había, y sigue habiendo, un gran desafío por delante: conocer cómo aplicar el bug bash de manera efectiva en diferentes contextos. Necesitábamos una hélice. Es decir, un proceso fluido con herramientas esenciales y robustas para la centralización que era lo suficientemente adaptable para ser utilizado en diferentes tipos de validación de entregas.

Así que preguntándonos por las realizaciones anteriores, hemos creado un proceso centrado en combinar puntos clave de pruebas junto con elementos clave de informes de errores, lo más simplificado posible sin comprometer su eficiencia.

Como se mencionó, los fundamentos para una buena prueba de errores incluyen una fase de preparación en la que la persona de control de calidad establece las condiciones para las pruebas, proporcionando a los evaluadores temporales herramientas que valoran sus habilidades de prueba. Hay tres pasos principales para una buena configuración:

Paso 1: Crear una hoja de cálculo para centralizar todos los hallazgos

Lo primero es lo primero: necesitamos a todos en la misma página. Literalmente! Cuando se trata de mapear problemas, es fundamental informar de todo en un solo documento. Esto podría significar una nota compartida, un documento de texto, un cartón gigante. Decidimos usar una hoja de cálculo en la que también pudiéramos dar alguna guía visual de lo que se estaba probando. Esta elección fue una colaboración con el diseñador de productos del equipo que describe los beneficios para el Diseño en sí en el artículo «Diseño de producto & Bug bash: cómo validar interfaces y garantizar la calidad de su entrega de extremo a extremo».

Una hoja de cálculo también permite que el proceso se automatice fácilmente para que sea más suave y funcional. En una hoja de cálculo de bug bash, tenemos tres pestañas: Participantes, Bug bash, Informe automático.

Como las aplicaciones de usuario final de QuintoAndar se basan principalmente en la web, las pruebas deben incluir diferentes dispositivos móviles y de escritorio. A veces, el problema está relacionado con el dispositivo, lo que hace que su divulgación sea indispensable. Así que creamos la pestaña «Participantes», en la que cada probador o participante del bug bash ingresa información como el nombre, el usuario simulado, el navegador, la marca del dispositivo y el tipo de dispositivo. Estos son la información básica que necesitamos para empezar a investigar — o solucionar el problema. Una vez que se complete esa información, podemos continuar.

En la segunda pestaña «Bug bash» combinamos los elementos testing y bug reporting. Una imagen del contexto que se va a probar en la primera columna va seguida de tres columnas en las que el probador introduce el nombre del probador, una descripción detallada del problema encontrado, así como una imagen del mismo, si corresponde. De esta manera, si hay dudas sobre el informe, sabemos a quién preguntar y ahorrar tiempo. Esto es particularmente valioso cuando se aseguran entregas front-end, ya que podemos validar el producto final contra el diseño diseñado. Si estamos validando entregas de back-end, la imagen de front-end generalmente se reemplaza con un flujo de trabajo que explica lo que está sucediendo en el back-end. De esta manera, mantenemos a las personas informadas sobre el contexto, aunque no sea visiblemente comprobable. La gente probará el producto e informará de todos los problemas, mejoras y dudas en esta pestaña. Cuando termine el tiempo de prueba, el equipo revisará los problemas reportados, revisará y discutirá lo que tiene sentido incluir en la fase de reparación.

Debido a esta etapa de evaluación de la gravedad y priorización, todo el equipo estará al tanto de todos los problemas encontrados y seleccionará los relacionados con ese ciclo de desarrollo para informar. Esto optimizará la fase de presentación de informes y evitará reuniones de seguimiento para priorizar los problemas.

La tercera y última pestaña de la hoja de cálculo, llamada «Informe automático», es clave para mantenerse al día con la velocidad de nuestros procesos. Contiene un script que toma toda la información de las dos últimas pestañas y crea automáticamente un informe de problemas en nuestro tablero Jira. Esto significa que no se pierde información en la fase del proceso de presentación de informes. Esto evita una gran cantidad de reelaboración y hace que todo el proceso sea mucho más eficiente. El script es personalizable, por lo que es posible agregar más campos para informar.

Paso 2: Crear una presentación de contexto

Para que sea eficaz, el alcance del producto a probar debe estar muy bien definido para todos los involucrados en el proceso de prueba. El alcance debe limitarse a la(s) característica (s) añadida (s) en esa ventana de tiempo o ciclo de desarrollo en particular. Cuanto más claro esté la gente sobre el alcance de esa ceremonia de prueba en particular, menos podrá responder si se trata de un error o un problema heredado. Es especialmente importante tener esta presentación en caso de que las partes interesadas o los miembros externos del escuadrón estén participando en las pruebas, ya que es posible que no tengan la claridad que tienen las personas dentro del desarrollo en sí.

Paso 3: Reserve una habitación y envíe invitaciones con días de antelación

Organizar una habitación para que se ajuste a un grupo grande de personas y, al mismo tiempo, cuidar el calendario de las personas no siempre es tan sencillo. Podría llevar mucho tiempo coincidir con el calendario de todos o tener un espacio lo suficientemente grande disponible, así que manténgase a la vanguardia. En la invitación, comparta la presentación de contexto junto con la hoja de cálculo de bug bash y asegúrese de haber dado el permiso necesario a todos los participantes. Otro aspecto muy importante de los ataques de insectos es el tiempo. Asegúrese de dedicar al menos 1h 30m ( una hora y media) para invertir en esta ceremonia. Puede parecer mucho, pero no lo es cuando hay tantas personas diferentes que usan el producto e interactúan para obtener un mejor enfoque de la experiencia del usuario.