![\"Pr\u00e1cticas](\"https:\/\/gbh.tech\/content\/uploads\/02_qa_chronicles_part_one_headphones.png\")
<\/p>\n
[\/et_pb_text][\/et_pb_column][\/et_pb_row][et_pb_row module_class=\u00bbd-lg-flex flex-lg-row-reverse\u00bb _builder_version=\u00bb4.16″ background_size=\u00bbinitial\u00bb background_position=\u00bbtop_left\u00bb background_repeat=\u00bbrepeat\u00bb custom_margin=\u00bb0px|0px|0px|0px|true|true\u00bb custom_padding=\u00bb0px|0px|0px|0px|true|true\u00bb collapsed=\u00bboff\u00bb global_colors_info=\u00bb{}\u00bb][et_pb_column type=\u00bb4_4″ _builder_version=\u00bb4.16″ custom_padding=\u00bb|||\u00bb global_colors_info=\u00bb{}\u00bb custom_padding__hover=\u00bb|||\u00bb][et_pb_text _builder_version=\u00bb4.21.0″ background_size=\u00bbinitial\u00bb background_position=\u00bbtop_left\u00bb background_repeat=\u00bbrepeat\u00bb hover_enabled=\u00bb0″ global_colors_info=\u00bb{}\u00bb sticky_enabled=\u00bb0″]<\/p>\n
Hace tres meses, cambi\u00e9 mi sombrero de gerente por unos auriculares de tester, sumergi\u00e9ndome nuevamente en las trincheras como L\u00edder de QA. Despu\u00e9s de dos a\u00f1os liderando el equipo, me encontr\u00e9 de nuevo en la primera l\u00ednea, listo para abordar un nuevo desaf\u00edo. El equipo al que me un\u00eda estaba luchando contra problemas tanto de calidad como de velocidad. Adem\u00e1s, algunas preocupaciones individuales de rendimiento burbujeaban bajo la superficie. Estaba claro que este proyecto no ser\u00eda un paseo por el parque, pero yo prospero en el meollo de las cosas.<\/p>\n
Con <\/span>ganas<\/span> de <\/span>comenzar<\/span>, <\/span>inici\u00e9<\/span> el<\/span> proceso<\/span> de <\/span>incorporaci\u00f3n<\/span>. Al <\/span>entrar<\/span> en<\/span> el<\/span> proyecto<\/span>, me <\/span>encontr\u00e9<\/span> con un <\/span>obst\u00e1culo<\/span>: la <\/span>documentaci\u00f3n<\/span> del <\/span>proceso<\/span> del <\/span>equipo<\/span> no <\/span>estaba<\/span> a la <\/span>altura<\/span>. Los <\/span>documentos<\/span> no se <\/span>completaron<\/span>, <\/span>faltaban<\/span> algunas<\/span> secciones<\/span> y, <\/span>en<\/span> algunos<\/span> casos<\/span>, la <\/span>informaci\u00f3n<\/span> no era <\/span>suficiente<\/span>, lo que me <\/span>dejaba<\/span> con un <\/span>conocimiento<\/span> insuficiente<\/span> para <\/span>hacer<\/span> mi <\/span>trabajo<\/span> de <\/span>manera<\/span> efectiva<\/span>. Esto <\/span>produjo<\/span> un <\/span>efecto<\/span> domin\u00f3<\/span> que <\/span>afect\u00f3<\/span> al <\/span>equipo<\/span>. Las <\/span>tareas<\/span> se <\/span>completaron<\/span> al azar y <\/span>los<\/span> l\u00edderes<\/span> no <\/span>pudieron<\/span> evaluar<\/span> con <\/span>precisi\u00f3n<\/span> qui\u00e9n<\/span> se <\/span>ajustaba<\/span> mejor<\/span> al <\/span>proyecto<\/span>. Este <\/span>sistema<\/span> defectuoso<\/span> obstaculiz\u00f3<\/span> el<\/span> rendimiento<\/span> de <\/span>todos<\/span>.<\/span><\/span>\u00a0<\/span><\/p>\n [\/et_pb_text][\/et_pb_column][\/et_pb_row][et_pb_row _builder_version=\u00bb4.16″ background_size=\u00bbinitial\u00bb background_position=\u00bbtop_left\u00bb background_repeat=\u00bbrepeat\u00bb custom_margin=\u00bb0px|0px|0px|0px|true|true\u00bb custom_padding=\u00bb0px|0px|0px|0px|true|true\u00bb collapsed=\u00bboff\u00bb global_colors_info=\u00bb{}\u00bb][et_pb_column type=\u00bb4_4″ _builder_version=\u00bb4.16″ custom_padding=\u00bb|||\u00bb global_colors_info=\u00bb{}\u00bb custom_padding__hover=\u00bb|||\u00bb][et_pb_text _builder_version=\u00bb4.21.0″ header_4_line_height=\u00bb36px\u00bb background_size=\u00bbinitial\u00bb background_position=\u00bbtop_left\u00bb background_repeat=\u00bbrepeat\u00bb global_colors_info=\u00bb{}\u00bb]<\/p>\n Las causas de estos problemas fueron m\u00faltiples, pero un problema evidente fue la falta de una estrategia de pruebas. A pesar del entusiasmo del equipo, el proceso de prueba carec\u00eda de una direcci\u00f3n clara. En cambio, todo el proceso de calidad se bas\u00f3 en un documento de alto nivel que describ\u00eda algunos puntos de prueba. Esta ambig\u00fcedad abri\u00f3 la puerta a desviaciones de las mejores pr\u00e1cticas y dej\u00f3 a todos sin claridad sobre el rol de los ingenieros de control de calidad en las reuniones, la documentaci\u00f3n de casos de prueba, la comunicaci\u00f3n y la colaboraci\u00f3n general. El equipo tambi\u00e9n desarroll\u00f3 pr\u00e1cticas inconsistentes, y las pruebas se volvieron dependientes de las negociaciones individuales entre desarrolladores e ingenieros de control de calidad. Esto cre\u00f3 un sistema de favoritismo, eludiendo los procedimientos documentados y fomentando la falta de transparencia.<\/p>\n Esta fue una situaci\u00f3n desafiante de abordar, ya que era necesario mejorar tantas cosas diferentes. Sin embargo, lo vi como una oportunidad para construir un equipo m\u00e1s fuerte y transparente, y una base para otros equipos en la empresa. Para ello, implement\u00e9 con el equipo las siguientes estrategias:<\/p>\n [\/et_pb_text][\/et_pb_column][\/et_pb_row][et_pb_row admin_label=\u00bb1. Adoptar la comunicaci\u00f3n abierta\u00bb _builder_version=\u00bb4.21.0″ _module_preset=\u00bbdefault\u00bb custom_padding=\u00bb|0px||0px|false|true\u00bb collapsed=\u00bbon\u00bb global_colors_info=\u00bb{}\u00bb][et_pb_column type=\u00bb4_4″ _builder_version=\u00bb4.21.0″ _module_preset=\u00bbdefault\u00bb global_colors_info=\u00bb{}\u00bb][et_pb_text admin_label=\u00bb1. Adoptar la comunicaci\u00f3n abierta\u00bb _builder_version=\u00bb4.21.0″ _module_preset=\u00bbdefault\u00bb custom_margin=\u00bb||10px||false|false\u00bb global_colors_info=\u00bb{}\u00bb]<\/p>\n [\/et_pb_text][et_pb_text _builder_version=\u00bb4.21.0″ _module_preset=\u00bbdefault\u00bb global_colors_info=\u00bb{}\u00bb]<\/p>\n Siendo parte de un equipo, las acciones fueron definidas e implementadas por todos, no solo por m\u00ed. Animamos activamente al equipo a tener todas las conversaciones en canales p\u00fablicos donde todos los miembros del equipo y los representantes del cliente tuvieran visibilidad.<\/p>\n Para eso, decidimos predicar con el ejemplo, a veces haciendo preguntas cuya respuesta ya conoc\u00edamos, provocando discusiones y sacando a la luz problemas ocultos. Adem\u00e1s, impulsamos al equipo a trasladar las conversaciones de los canales internos a aquellos en los que el cliente ten\u00eda visibilidad. De esta manera, pudimos identificar los problemas de manera proactiva<\/strong>, brindar al equipo soluciones adecuadas y oportunas, y asegurar al cliente al brindar visibilidad sobre la soluci\u00f3n de los problemas<\/strong> identificados. Adem\u00e1s, el equipo de Aseguramiento de Calidad comenz\u00f3 a notificar por Slack cada vez que se tomaba un ticket para pruebas, y el hilo se actualizaba con cualquier pregunta que pudiera tener el ingeniero de control de calidad y\/o el resultado del ticket.<\/p>\n [\/et_pb_text][\/et_pb_column][\/et_pb_row][et_pb_row admin_label=\u00bb2. Reconstrucci\u00f3n del conjunto de casos de prueba\u00bb _builder_version=\u00bb4.21.0″ _module_preset=\u00bbdefault\u00bb custom_padding=\u00bb|0px||0px|false|false\u00bb collapsed=\u00bbon\u00bb global_colors_info=\u00bb{}\u00bb][et_pb_column type=\u00bb4_4″ _builder_version=\u00bb4.21.0″ _module_preset=\u00bbdefault\u00bb global_colors_info=\u00bb{}\u00bb][et_pb_text admin_label=\u00bb2. Reconstrucci\u00f3n del conjunto de casos de prueba\u00bb _builder_version=\u00bb4.21.0″ _module_preset=\u00bbdefault\u00bb custom_margin=\u00bb||10px||false|false\u00bb global_colors_info=\u00bb{}\u00bb]<\/p>\n [\/et_pb_text][et_pb_text _builder_version=\u00bb4.21.0″ _module_preset=\u00bbdefault\u00bb global_colors_info=\u00bb{}\u00bb]<\/p>\n Nos embarcamos en la misi\u00f3n de volver a documentar meticulosamente todos los casos de prueba existentes. Esto result\u00f3 en un conjunto conciso y bien escrito de casos de prueba enviados al cliente para su revisi\u00f3n. Decidimos solicitar su revisi\u00f3n por dos razones. Quer\u00edamos asegurar la claridad de los casos de prueba, permitiendo al cliente proporcionar observaciones valiosas y confirmar la cobertura de funcionalidades cr\u00edticas, y en segundo lugar, su aporte sirvi\u00f3 como una valiosa verificaci\u00f3n de cordura, ayud\u00e1ndonos a identificar cualquier brecha potencial en nuestra estrategia de pruebas.<\/p>\n [\/et_pb_text][\/et_pb_column][\/et_pb_row][et_pb_row admin_label=\u00bb3. Integraci\u00f3n de las actividades de Aseguramiento de la Calidad con UX\u00bb _builder_version=\u00bb4.21.0″ _module_preset=\u00bbdefault\u00bb custom_padding=\u00bb|0px||0px|false|false\u00bb collapsed=\u00bbon\u00bb global_colors_info=\u00bb{}\u00bb][et_pb_column type=\u00bb4_4″ _builder_version=\u00bb4.21.0″ _module_preset=\u00bbdefault\u00bb global_colors_info=\u00bb{}\u00bb][et_pb_text admin_label=\u00bb3. Integraci\u00f3n de las actividades de Aseguramiento de la Calidad con UX\u00bb _builder_version=\u00bb4.21.0″ _module_preset=\u00bbdefault\u00bb custom_margin=\u00bb||10px||false|false\u00bb global_colors_info=\u00bb{}\u00bb]<\/p>\n [\/et_pb_text][et_pb_text _builder_version=\u00bb4.21.0″ _module_preset=\u00bbdefault\u00bb global_colors_info=\u00bb{}\u00bb]<\/p>\n Esta estrategia introdujo un elemento revolucionario: la participaci\u00f3n directa del equipo de Aseguramiento de la Calidad en las reuniones de presentaci\u00f3n de caracter\u00edsticas de UX. En estas reuniones, los dise\u00f1adores de UX presentan cada nueva caracter\u00edstica y discuten la l\u00f3gica detr\u00e1s del dise\u00f1o propuesto con los representantes del cliente, los ingenieros de software y ahora, tambi\u00e9n con los ingenieros de control de calidad. Este enfoque proactivo desbloque\u00f3 varios beneficios.<\/p>\n El primero es la obvia detecci\u00f3n temprana de errores<\/strong>, ya que al participar en los requerimientos durante la fase de dise\u00f1o, los ingenieros de control de calidad ahora pueden identificar pasos faltantes en las nuevas funcionalidades, as\u00ed como conceptos err\u00f3neos sobre el comportamiento del sistema existente. El segundo beneficio proviene de la detecci\u00f3n de problemas ocultos<\/strong>, ya que esta participaci\u00f3n temprana tambi\u00e9n arroja luz sobre errores que podr\u00edan haberse pasado por alto debido a la falta de comprensi\u00f3n sobre las decisiones de dise\u00f1o espec\u00edficas y su l\u00f3gica subyacente. El tercer beneficio proviene de un dise\u00f1o proactivo de casos de prueba<\/strong>, lo que nos permite comenzar a dise\u00f1ar los casos de prueba desde un momento temprano, con tiempo para encontrar los mejores enfoques. Si bien esta pr\u00e1ctica no est\u00e1 completamente implementada, ya vemos el potencial para que los ingenieros de control de calidad dise\u00f1en casos de prueba incluso antes de que se finalicen las estimaciones de desarrollo. Esto les proporcionar\u00eda una comprensi\u00f3n m\u00e1s clara del alcance y los capacitar\u00eda para planificar su enfoque de pruebas de manera m\u00e1s efectiva. Dado que esta ha sido una experiencia muy enriquecedora, interactuando directamente con un p\u00fablico tan diverso, la detallaremos m\u00e1s en un futuro art\u00edculo.<\/p>\n \u00a1Mantente conectado!<\/p>\n [\/et_pb_text][\/et_pb_column][\/et_pb_row][et_pb_row admin_label=\u00bb4. Migraci\u00f3n de la automatizaci\u00f3n de pruebas de Selenium a Playwright\u00bb _builder_version=\u00bb4.21.0″ _module_preset=\u00bbdefault\u00bb custom_padding=\u00bb|0px||0px|false|false\u00bb collapsed=\u00bboff\u00bb global_colors_info=\u00bb{}\u00bb][et_pb_column type=\u00bb4_4″ _builder_version=\u00bb4.21.0″ _module_preset=\u00bbdefault\u00bb global_colors_info=\u00bb{}\u00bb][et_pb_text admin_label=\u00bb4. Migraci\u00f3n de la automatizaci\u00f3n de pruebas de Selenium a Playwright\u00bb _builder_version=\u00bb4.21.0″ _module_preset=\u00bbdefault\u00bb custom_margin=\u00bb||10px||false|false\u00bb global_colors_info=\u00bb{}\u00bb]<\/p>\n [\/et_pb_text][et_pb_text _builder_version=\u00bb4.21.0″ _module_preset=\u00bbdefault\u00bb hover_enabled=\u00bb0″ global_colors_info=\u00bb{}\u00bb sticky_enabled=\u00bb0″]<\/p>\n Necesit\u00e1bamos un framework m\u00e1s r\u00e1pido para lograr los objetivos que nos hab\u00edamos marcado. Por el momento, aunque no hemos alcanzado el conjunto necesario de casos de prueba automatizados, ya lo tenemos como parte de una pipeline automatizada. Configuramos un conjunto de pruebas de humo que se ejecuta despu\u00e9s de cada implementaci\u00f3n en los entornos de Pruebas de Aceptaci\u00f3n de Usuario (UAT) y Producci\u00f3n. Adem\u00e1s, tambi\u00e9n se ejecuta para cada Pull Request (PR) que crea el equipo de Desarrollo como una verificaci\u00f3n que debe pasar antes incluso de ser revisada por pares. Esto, junto con la asignaci\u00f3n de la responsabilidad de fusi\u00f3n e implementaci\u00f3n a QA, ha permitido mantener estable la rama principal. Ahora que tenemos un entorno de Producci\u00f3n en vivo, podemos lanzar dos veces por semana, dedicando solo medio d\u00eda a cada esfuerzo de lanzamiento.<\/p>\n [\/et_pb_text][\/et_pb_column][\/et_pb_row][et_pb_row admin_label=\u00bbConclusi\u00f3n y pr\u00f3ximos pasos\u00bb _builder_version=\u00bb4.21.0″ _module_preset=\u00bbdefault\u00bb custom_padding=\u00bb|0px||0px|false|false\u00bb collapsed=\u00bbon\u00bb global_colors_info=\u00bb{}\u00bb][et_pb_column type=\u00bb4_4″ _builder_version=\u00bb4.21.0″ _module_preset=\u00bbdefault\u00bb global_colors_info=\u00bb{}\u00bb][et_pb_text admin_label=\u00bbConclusi\u00f3n y pr\u00f3ximos pasos\u00bb _builder_version=\u00bb4.21.0″ _module_preset=\u00bbdefault\u00bb custom_margin=\u00bb||10px||false|false\u00bb global_colors_info=\u00bb{}\u00bb]<\/p>\n [\/et_pb_text][et_pb_text _builder_version=\u00bb4.21.0″ _module_preset=\u00bbdefault\u00bb global_colors_info=\u00bb{}\u00bb]<\/p>\n Si bien hemos recorrido un largo camino, con mejoras visibles, creo que esto es solo el comienzo. Nuestro objetivo es tener un proceso completo de extremo a extremo que nos permita lanzar a producci\u00f3n cada ticket tan pronto como el equipo de Aseguramiento de la Calidad lo apruebe, y estoy seguro de que estamos en el camino correcto para lograrlo. Lo mantendremos informados sobre los resultados de este caso en un par de semanas para que todos ustedes sepan c\u00f3mo estamos y qu\u00e9 otros cambios aplicamos a nuestro proceso.<\/p>\n![\"La](\"https:\/\/gbh.tech\/content\/uploads\/qa_chronicles_part_one_dark_room.png\")
<\/p>\n1. Adoptar la comunicaci\u00f3n abierta<\/strong><\/h4>\n
2. Reconstrucci\u00f3n del conjunto de casos de prueba<\/strong><\/h4>\n
3. Integraci\u00f3n de las actividades de Aseguramiento de la Calidad con UX<\/strong><\/h4>\n
4. Migraci\u00f3n de la automatizaci\u00f3n de pruebas de Selenium a Playwright <\/strong><\/h4>\n
![\"Migraci\u00f3n](\"https:\/\/gbh.tech\/content\/uploads\/04_qa_chronicles_part_one_bridge.png\")
<\/p>\nConclusi\u00f3n y pr\u00f3ximos pasos<\/strong><\/h4>\n