Una vez que un ingeniero de control de calidad ingresa a la sala, todos esperan que los problemas de calidad se resuelvan mágicamente.
A lo largo de mi carrera en pruebas de software, he notado dilemas que afectan la dinámica de todo el equipo y los resultados del producto. Lo creas o no, estos patrones son comunes a todos los equipos de desarrollo con los que he trabajado. Estos patrones pueden interponerse fácilmente en el camino de los objetivos de un equipo, como desarrollar un producto sorprendente y de vanguardia que ayude a la humanidad… por lo que este increíble producto sólo existe como una necesidad o un sueño del propietario del producto. En cambio, el equipo construyó algo más.
Algunos equipos elogian la visibilidad por encima del valor, se olvidan de la calidad en medio de sprints muy ocupados y abordan las pruebas sin una estrategia clara. ¿Te suena familiar? Bienvenido a la realidad de trabajar en control de calidad.
¿Visibilidad sobre valor?
En muchos equipos, los miembros más ruidosos reciben elogios, aunque su influencia pueda ser igual a la de los miembros más silenciosos. Para encontrar un ejemplo clásico, basta observar una reunión común. Las personas que hablan mucho reciben toda la atención.
sobre ella artículoLa ingeniera de software Priyanka Jain cuenta la historia de dos colegas a quienes se les asignó la misma tarea. Uno de ellos publicó actualizaciones, hizo preguntas y gritó colaboraciones. El otro permaneció en silencio y proporcionó un código limpio. Ambos cumplieron. Sin embargo, sólo una persona fue elogiada como “un gran jugador de equipo”.
En muchas culturas laborales, combinamos visibilidad con valor. Si habla con frecuencia, la gente asumirá que está haciendo una contribución. Si estás callado, pensarán que no lo estás. por lo tanto extroversión promocionado más veces que introvertido.
Si es la única persona de control de calidad a bordo, debe ser visible y hablar. De lo contrario, se ignorarán sus contribuciones, se ignorarán los errores importantes y a nadie le importará la calidad del producto. Algunas personas incluso podrían preguntarse qué estás haciendo allí, ya que no publicas el código.
Si eres introvertido de corazón y no te gusta expresar tus opiniones o actualizaciones en cada rincón, esto puede ser un desafío para ti. Sin embargo, esta es la realidad de un entorno de “ritmo rápido”: cuanto más vocal y visible sea su voz, mejor será para el equipo.
La calidad es un oráculo, pero ¿lo es realmente?
La calidad es el oráculo de los equipos de producto; es algo por lo que los equipos de producto deben esforzarse y gestionar en consecuencia. De lo contrario, ¿está seguro de que sus clientes tolerarán todos estos errores e inconsistencias que encuentren? Ningún equipo quiere que los usuarios abandonen su producto. Sin embargo, ¿es la calidad realmente un oráculo?
Una vez estaba debatiendo una característica con un desarrollador. Pensó que definitivamente haría un botón de alternancia en lugar de un menú desplegable porque “parece más exótico”. Le pedí que visualizara ambas versiones en una herramienta de creación de prototipos para que pudiéramos probar cada opción. En el contexto de nuestro caso de uso específico, un menú desplegable todavía parece una opción apropiada.
Después de una breve sesión de prueba que hicimos juntos, los desarrolladores se dieron por vencidos y aceptaron. Ahorramos tiempo en posibles retrabajos. (La IA no era tan poderosa en aquel entonces. Ahora, uso herramientas impulsadas por IA para visualizar ambos escenarios para el equipo de desarrollo. De esa manera, también ahorramos tiempo discutiendo). De todos modos, todos están contentos, incluido el cliente que obtiene una versión pulida del producto de inmediato.
aquí, mentalidad de calidad Es algo que se puede aprender en el camino. El papel del control de calidad también es promover esta mentalidad para que los miembros del equipo sean conscientes de ella. Cuando son conscientes de que la calidad es una prioridad, los equipos de desarrollo toman más medidas para evitar que se produzcan errores en la producción. Después de todo, la calidad es un deporte de equipo.
¿Necesitamos una estrategia de prueba?
Antes de unirme a un equipo (llamémoslo X), no tenía un flujo de trabajo de prueba y el equipo no tenía la confianza suficiente para completar el ciclo de lanzamiento. El día antes de la liberación prevista, reinó el pánico habitual. El equipo aún no es consciente de la calidad. El sentimiento general es: “¿Pruebas? Simplemente no tenemos tiempo. ¿No eres tú un control de calidad? ¡Deberías resolverlo!”.
Toda la situación me recuerda la lógica de Hattifattener. Los libros de Tove Jansson.están siempre en movimiento, intentando alcanzar el horizonte a toda costa. Aquí, precio es igual a calidad.
Un mes después, dirigí al equipo en una acalorada discusión sobre la calidad actual del producto y lo que podíamos hacer para lanzar un producto mejor. El equipo estableció un flujo de trabajo de control de calidad que incluía múltiples técnicas de prueba en todos los niveles del producto (de un extremo a otro, API, unidad). Cuadrante de pruebas ágiles, una herramienta El marco propuesto por primera vez por Janet Gregory y Lisa Crispin es nuestro marco para seleccionar técnicas de prueba que se ajusten a las necesidades del equipo X. La calidad general del producto ha mejorado enormemente.
Antes de que un equipo comience a construir un sistema de garantía de calidad para un producto, es aconsejable reflexionar sobre cómo debería funcionar la garantía de calidad. Es importante definir cómo se mide la calidad:Tecnología de prueba Se aplicará al producto y cómo lograr una cobertura de prueba general.
Es fundamental analizar el estado actual de las pruebas y cómo el equipo está previniendo defectos (qué pruebas se utilizan y en qué nivel). Después de la sesión de lluvia de ideas, el equipo puede describir el proceso de control de calidad. Como resultado, una vez que el equipo entrega el producto, hay menos caos y un estado de ánimo más tranquilo.
Si se enfrenta a un dilema similar, siempre hay una solución. En equipos ágiles, hable más y comunique los problemas con claridad. Si el equipo se olvida de la calidad en la realidad de los sprints rápidos, recuérdeselo e involucre a los miembros del equipo en las sesiones de prueba. Finalmente, si sus esfuerzos de prueba parecen caóticos, analice su estrategia de prueba con su equipo y desarrollenla juntos. Después de todo, ¿no eres tú quien puede resolver esto? 🙂
puedes revisar el mio página de LinkedIn Si desea ponerse en contacto conmigo o tiene curiosidad sobre mis antecedentes. Como ingeniero de control de calidad con más de 7 años de experiencia comercial en la industria, siempre estoy listo para comunicarme con equipos que buscan orientación y asistencia para mejorar la calidad y las pruebas del producto. En este momento, estoy buscando un nuevo puesto como Analista de Calidad, Ingeniero de Calidad o Supervisor de Calidad.
Ilustración: Dibujada por mí (Apple Pencil, iPad, sin IA 🙂)
recurso:
- Priyanka Jain, No todas las grandes obras son ruidosas: https://code.likeagirl.io/not-all-great-work-is-loud-77874c554276
- Aletheia entrega, Haga de la calidad del producto un deporte de equipo: https://uxdesign.cc/making-product-quality-a-team-sport-35d94fc0a2cf
- Janet Gregory y Lisa Crispin, Pruebas ágiles condensadas: https://leanpub.com/agiletesting-condensed o https://www.amazon.de/gp/product/199922051X
Pruebas inteligentes: ¿Cómo resolver dilemas típicos en las pruebas? Publicado originalmente en Colectivo de experiencia de usuario En Medium, la gente continúa la conversación destacando y respondiendo a esta historia.
