Liderazgo en las Pruebas: Pruebas como Equipo
Nota del editor: Bienvenidos a la serie Liderazgo en Pruebas del gurú y consultor de pruebas de software Paul Gerrard. La serie está diseñada para ayudar a testers con algunos años de experiencia—especialmente a quienes están en equipos ágiles—a sobresalir en sus roles de líderes y gestores de pruebas.
En el artículo anterior, Paul analiza cómo gestionar la ejecución de un proyecto de pruebas. Aquí, examinará el papel cambiante del tester en un equipo de proyecto y cómo fomentar una mejor colaboración con tus colegas tanto en la oficina como de forma remota.
En los últimos años, la responsabilidad de las pruebas se ha vuelto más distribuida. En lugar de equipos dedicados propietarios de las pruebas, ahora los equipos fomentan que usuarios, analistas, desarrolladores y testers redistribuyan la responsabilidad de las pruebas para apoyar una mejor colaboración. Por lo tanto, algunas actividades y responsabilidades de prueba se están desplazando hacia la izquierda.
En este artículo, cubriré:
- Desplazamiento hacia la izquierda
- Las pruebas como actividad, no como rol
- Un nuevo rol
- Intervenciones ágiles en pruebas
- Relaciones con los desarrolladores
- Desafíos de equipos distribuidos y subcontratados
Presentando el desplazamiento hacia la izquierda
Shift-Left, o desplazamiento a la izquierda, puede referirse a varios escenarios diferentes. Puede significar que los desarrolladores asuman más propiedad y responsabilidad por sus propias pruebas. También puede significar que los testers se involucren antes en el proyecto, desafiando requerimientos y proporcionando ejemplos a través de un proceso de Desarrollo Guiado por Comportamiento (BDD) a los desarrolladores.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
A veces puede significar que no haya testers en absoluto (chan-chan-chaaaan), y que los BAs y desarrolladores asuman la responsabilidad total de las pruebas.
El desplazamiento hacia la izquierda no es algo nuevo—los defensores de las pruebas han predicado el mantra, "probar temprano, probar a menudo" durante muchos años. Ya en 1993, se sugería que todos los artefactos en un proceso por etapas—tanto documentales como de software—podían (y a menudo debían) ser probados.
El desplazamiento hacia la izquierda se trata principalmente de llevar el pensamiento sobre las pruebas antes en el proceso.
Aunque en ese momento el enfoque principal del ciclo de vida era el Waterfall, la cantidad o duración de las etapas no es lo importante. El principio subyacente era que las fuentes de conocimiento que ofrecen dirección para el diseño y desarrollo de software deberían ser desafiadas o puestas a prueba.
En un proyecto por etapas, esto podría implicar revisiones formales. En un proyecto Ágil, el tester (o el desarrollador, BA o usuario) puede sugerir escenarios que desafíen al autor de un requerimiento o historia a pensar en ejemplos concretos y discutirlos antes de que se escriba cualquier código.
Estos son los principales cambios involucrados en el fenómeno del desplazamiento hacia la izquierda:
- El enfoque de Desarrollo Guiado por Comportamiento (BDD) ha permitido que desarrolladores, usuarios/BAs y testers participen alrededor de lo que podría llamarse historias de negocio. El Desarrollo Guiado por Pruebas ha sido utilizado por muchos desarrolladores por 15 años o más. Hoy en día, el BDD se está adoptando más ampliamente porque fomenta una mejor colaboración en equipos ágiles, además de introducir herramientas BDD que pueden ser usadas por desarrolladores. Es un enfoque Test-First más sencillo.
- La Entrega Continua (CD) existe desde hace 5-10 años y tiene sus raíces en los enfoques de automatización de compilación y despliegue altamente automatizados impulsados por grandes empresas en línea. Ahora es adoptado por la mayoría de las organizaciones con presencia en línea.
- CD sistematizó y aceleró el proceso de lanzamiento mediante la automatización. Pero también puso en evidencia los retrasos en producción, despliegue y cambios de infraestructura que previamente habían estado enmascarados por procesos lentos de construcción, pruebas y lanzamiento. DevOps es un cambio de mentalidad cultural mediante el cual los desarrolladores colaboran mucho más estrechamente con el personal de operaciones. Actualmente, aparecen nuevas herramientas casi a diario y los proveedores promocionan DevOps como la 'próxima gran cosa'. Es una situación muy promovida y dinámica.
- SMAC, o Social, Móvil, Analítica y Nube, representa un cambio en la manera en que las organizaciones gestionan los cambios de sistemas y negocios en el espacio móvil. La experimentación en el negocio, implementada como cambios en sistemas productivos, se monitorea a nivel detallado. Los datos "grandes" capturados se procesan y las decisiones comerciales se toman en base a los análisis obtenidos.
La experimentación frecuente con sistemas en producción permite la innovación empresarial 'a la velocidad del marketing'. La experimentación está en el corazón de lo que fue la tendencia más importante de la década de 2010 – Transformación Digital.
Las pruebas como actividad, no como rol
El desplazamiento hacia la izquierda cambia el papel de los testers. La redistribución de las pruebas provocada por este enfoque deja claro que los testers no son los únicos responsables de las pruebas; es decir, los testers ya no son los dueños exclusivos de las pruebas.
Si lo piensas bien, en realidad nunca realizaron pruebas por sí mismos, pero existía un entendimiento tácito en los proyectos de que, independientemente de lo que hiciera el resto del equipo, en particular los desarrolladores, en cuanto a pruebas, los testers proporcionaban una red de seguridad. Si a los desarrolladores les faltaba tiempo y reducían sus pruebas para poder entregar, los testers aportaban esa red de seguridad.
La prueba ahora es una actividad, no un rol.
Los desarrolladores están adoptando mejores prácticas de pruebas y una mayor visibilidad en su trabajo. Las buenas pruebas a nivel de componente o pruebas unitarias tienen objetivos específicos, distintos de las pruebas de sistema (por ejemplo). Por lo tanto, se puede reducir el alcance (o la cantidad) de pruebas a nivel de sistema.
La correcta distribución de los objetivos de las pruebas, y probar para cumplir con esos objetivos, es el propósito principal de la estrategia de pruebas. Lamentablemente, hasta hace poco, los desarrolladores no eran realmente responsables de manera efectiva, así que dependían de las pruebas de sistema tardías para compensar.
El shift-left hace a los desarrolladores más responsables.
En general, la responsabilidad de las pruebas se redistribuye, por lo que el rol del tester cambia. Los testers pueden hacer menos pruebas tácticas, pero su contribución estratégica aumenta. Los testers pueden ser dueños de la estrategia de pruebas; desafían los requisitos, consultan con las partes interesadas y establecen una relación más cercana con los desarrolladores para apoyar mejores pruebas de desarrollo y la automatización de pruebas.
Un nuevo rol
Shift-Left implica que siempre que sea posible dar retroalimentación que ayude al equipo a comprender, cuestionar y mejorar los objetivos, requisitos, diseño o implementación, esa retroalimentación debe ser proporcionada.
Usuarios, analistas de negocio, desarrolladores y todo el equipo de software deben estar preparados para intercambiar retroalimentación de esta manera. A veces hay resistencia, pero el objetivo general es ejecutar un proyecto mejor y más informado, eso es todo.
La forma más sencilla de resumir este comportamiento es: ‘involúcrate temprano’, tan temprano como sea posible. Participa en la discusión y colabora en las ideas, requisitos y en cada etapa donde el resultado de esa fase tenga impacto en el valor del entregable final del proyecto.
En pocas palabras, el tester desafía las fuentes de conocimiento, ya sean partes interesadas, usuarios, desarrolladores, historias de negocio, documentos o precedentes.
El enfoque más común es desafiar mediante ejemplos. En todas las etapas, estos ejemplos pueden considerarse pruebas. Puede que se descarten rápidamente después de su uso o que se transformen en automatización de pruebas o comprobaciones manuales. Estos ejemplos pueden usarse tácticamente para señalar fallas en el razonamiento de las personas, o bien, suministrarse a los desarrolladores como ideas o semillas para pruebas. También pueden emplearse como herramientas educativas para demostrar a usuarios o desarrolladores cómo crear mejores pruebas.
Piensa en tu proyecto de software como un proceso de adquisición de conocimiento. Este conocimiento se recopila a lo largo del proyecto y a menudo evoluciona con el tiempo. El objetivo del shift-left es asegurar este conocimiento desafiándolo y probándolo cerca de su fuente, y garantizar, en la medida de lo posible, que sea fiable antes de fijarlo en el código.
Shift-Left lleva la filosofía de las pruebas primero aún más lejos. Agile siempre ha promovido la colaboración y la retroalimentación rápida: shift-left puede verse como un enfoque concertado de retroalimentación rápida. Si tu equipo está adoptando una aproximación shift-left para las pruebas, disponer de las herramientas adecuadas puede ser determinante. Consulta nuestra lista seleccionada de herramientas de pruebas de software para encontrar la mejor opción para tu equipo.
Intervenciones de Prueba Ágil
El enfoque shift-left es fundamental para una estrategia de pruebas en proyectos ágiles. En un contexto ágil, la estrategia de pruebas puede verse como una serie de intervenciones de prueba. Hay momentos críticos en todos los proyectos donde surgen oportunidades para recoger y brindar retroalimentación. El tester debe concentrarse en estos momentos críticos y estar listo para contribuir en esas ocasiones.
En tus propios proyectos, necesitas identificar los momentos críticos donde es posible intervenir e identificar las opciones que puedes tomar al probar como equipo. Por ejemplo, ¿debe el tester escribir pruebas unitarias para los desarrolladores, proporcionar ejemplos para que comiencen o entrenarlos para mejorar su capacidad de prueba? Sólo tú y tu nuevo equipo de pruebas de software pueden decidir esto.
Usaremos un proceso Scrum típico para demostrar cómo se pueden ubicar las intervenciones de prueba dentro del enfoque Scrum. Las intervenciones ocurren a nivel de proyecto (o de versión), o a nivel de sprint. El diagrama a continuación muestra una vista a nivel de proyecto y las cinco intervenciones clave.
El desafío de la historia y la definición de la historia son donde el tester valida una historia de usuario y los criterios de aceptación propuestos para esa historia, respectivamente. Las pruebas de integración verifican que las nuevas funcionalidades se conecten correctamente con otras funcionalidades y con el sistema en general. Las pruebas de sistema y de usuario (aceptación) se realicen según corresponda.
Un proyecto suele tener múltiples sprints, y las cuatro intervenciones de sprint se muestran en el diagrama a continuación. El daily stand-up es una oportunidad para reportar avances, plantear inquietudes, identificar riesgos o discutir preguntas surgidas y respuestas recibidas durante el sprint.
La refinación de las historias y las contribuciones a las pruebas de los desarrolladores son actividades diarias que ocurren como parte de las discusiones con usuarios, analistas y desarrolladores. El tester incorpora pruebas de desarrollador y nuevas pruebas de sistema a una colección creciente de pruebas para ser automatizadas.
En la siguiente tabla, puedes ver un resumen en forma de tabla de las intervenciones realizadas por los testers. Tu proceso puede ser diferente, o estar basado en Scrum con sus propias variaciones, pero la tabla identifica los tipos típicos de intervención en un proceso Scrum estándar. Es posible que tengas más o menos intervenciones activas en diferentes momentos según tu proceso único.
Te sugiero que identifiques los momentos críticos, propongas tu aporte y lo negocies con tu equipo. Ofreces más liderazgo y orientación en pruebas en lugar de ofrecerte solo para asumir la responsabilidad del trabajo de pruebas. Adoptar este enfoque hará que sea mucho más fácil demostrar tu valor al equipo, aunque puede que el equipo no necesite tantos testers.
Relaciones con los Desarrolladores
En algunas organizaciones, la relación entre los desarrolladores puede ser desconfiada, culposa y antagónica. En el peor de los casos, la relación es tóxica: los desarrolladores apenas prueban y los testers son vistos como sirvientes de los desarrolladores. Los testers pueden adoptar comportamientos codependientes y actuar como víctimas. Esta situación es precisamente lo que la metodología shift-left pretende evitar.
Se han utilizado muchas metáforas para describir una buena relación desarrollador-tester. Vamos a usar el estilo piloto-navegante para ilustrar cómo puede funcionar una relación desarrollador-tester comparable. Pero antes, veamos una situación disfuncional.
El navegante no sube al avión, pero le hace señas al piloto mientras despega. El navegante viaja en autobús, de forma separada pero lentamente. Finalmente, el navegante llega al destino, pero, después de algún tiempo, se descubre que el avión voló en la dirección equivocada y se estrelló contra una montaña.
¿No debería el navegante haber estado en el avión? Imagina cómo trabajan juntos los pilotos y los navegantes en la realidad.
- El piloto no puede volar el avión sin un navegante. El navegante no puede volar el avión.
- Piloto y navegante acuerdan el plan de vuelo antes de comenzar el viaje.
- El piloto despega y vuela el avión.
- El navegante sigue el curso y lo compara con el plan de vuelo y/o destino final teniendo en cuenta imprevistos, en particular el clima.
- El navegante busca desviaciones, marca un nuevo rumbo y avisa al piloto, quien ajusta la trayectoria de vuelo.
- Y así sucesivamente.
La relación piloto/navegante es comparable a la relación programador/tester. Separar a desarrolladores y testers en equipos distintos que trabajan de manera secuencial tampoco tiene sentido. Sin embargo, eso es lo que hemos hecho convencionalmente durante los últimos treinta años, especialmente en proyectos grandes y de larga duración.
Shift-left redistribuye el pensamiento sobre las pruebas y, en la práctica, lo adelanta. Los testers actúan como socios de pleno derecho de los desarrolladores, igual que hacen los navegantes con los pilotos:
- El tester y el desarrollador recopilan en conjunto la información sobre los requisitos.
- Generalmente, el tester desafía los requisitos exponiendo ejemplos (ideas de pruebas potenciales o reales).
- El desarrollador piensa en la implementación, usando los ejemplos para orientar su diseño.
- El tester, el desarrollador, los interesados, usuarios y analistas acuerdan una comprensión compartida de un requisito confiable.
- El tester está en comunicación constante con el desarrollador, dialogando sobre cambios de requisitos, riesgos de fallos, y cómo las pruebas pueden mostrar que las funcionalidades funcionan o exponen fallos.
- El tester analiza cómo la funcionalidad en la que se está trabajando se integrará tanto a nivel técnico como de recorrido de usuario, y cómo se puede probar esa integración.
- El tester observa más allá de la funcionalidad inmediata en la que el desarrollador trabaja para identificar futuros retos, riesgos, cambios e incertidumbres.
- Y así sucesivamente.
La relación ideal entre desarrolladores y testers, como la que acabamos de describir, no se da automáticamente. El equipo debe trabajar para conseguirla. Puedes pensar en cada una de las actividades anteriores como intervenciones, pero las intervenciones no siempre resultan cómodas para todos. Da a este enfoque la mejor oportunidad de prosperar hablando sobre cada tipo de intervención con tus socios desde el principio, en cuanto sepas que vas a trabajar de manera cercana.
Las intervenciones, igual que las buenas historias de usuario, son detonantes para las conversaciones.
Cada tipo de intervención requiere el consentimiento por ambas partes de que es una acción válida. Para que sea cómoda, cada persona debe confiar en la otra y saber que existe una buena razón para hacer preguntas, señalar problemas y desafiar requisitos o entendimiento en reuniones diarias, sesiones de planificación y retrospectivas.
Retos de los equipos distribuidos y subcontratados
En las discusiones anteriores, se ha asumido tácitamente que todos trabajan en el mismo equipo y están ubicados en el mismo lugar. Cuando la carga de trabajo del equipo de pruebas de software se subcontrata y/o se realiza offshore, entran en juego varios factores negativos. La tabla muestra tres factores típicos a considerar.
| Separación física (y temporal) | Los equipos pueden estar distribuidos en una oficina, en diferentes edificios, ciudades, países y zonas horarias. La comunicación se interrumpe, los canales se ven limitados y fluye menos información. |
| Diferentes motivaciones | El equipo proveedor trabaja para una organización que recibe pago por realizar el trabajo de pruebas. En última instancia, su motivación es obtener un beneficio. En los contratos de precio fijo, la presión es trabajar rápido. En los contratos de tiempo y materiales, la tentación es alargar el trabajo. |
| Diferencias culturales | Las diferencias nacionales y culturales pueden ser significativas. Estas a veces requieren tiempo para ser reconocidas y tenerlas en cuenta. |
| Cultura empresarial/corporativa | Las culturas empresariales también difieren: las empresas suelen asociarse mejor con otras de tamaño, flexibilidad y formalidad comparables. Las empresas pueden ser más o menos cautelosas en lo que respecta a privacidad, seguridad, confidencialidad, etc. Las compañías tienen estilos de liderazgo distintos y la diferencia entre organizaciones gubernamentales y comerciales también requiere adaptación. |
| Los proveedores se rigen por los contratos | Tu proveedor no tiene lealtad hacia los interesados de tu proyecto ni hacia los objetivos comerciales de estos. Ellos trabajan según las normas especificadas en su contrato. Si puedes, asegúrate de que los contratos identifiquen todas las responsabilidades de ambas partes, y que recompensen los buenos comportamientos y penalicen las conductas incorrectas. |
Algunas empresas fortalecen los equipos existentes de pruebas de software para aumentar capacidades en proyectos grandes, o contratan empresas especializadas en pruebas en lugar de recurrir a contratistas o personal de usuario interno. En otras situaciones, todo el desarrollo y/o las pruebas pueden ser delegados a los proveedores. En todos los casos, la empresa cliente debe gestionar a sus proveedores. Esto no significa que redactar un contrato restrictivo con cláusulas de penalización severas sea suficiente.
Cuando las cosas salen mal, quieres respuestas rápidas y colaboración de tu proveedor; no deseas que se escondan detrás de cláusulas legales en los contratos.
Las claves para el éxito son:
- Si no gestionas a tu proveedor, ellos te gestionarán a ti (si no son socios plenos, y dejas que el proveedor defina los términos, el proveedor tendrá todo el poder).
- El objetivo es definir una buena relación de trabajo. Debe establecerse a todos los niveles: responsables de interés, gerentes y también profesionales.
- Los contratos deben estar redactados para identificar todas las responsabilidades de ambas partes, con medidas, umbrales, pagos por etapas y criterios de aceptación apropiados para fomentar un buen comportamiento (en ambos lados del acuerdo).
- Los acuerdos deben fomentar la transparencia y el compromiso con el objetivo compartido del éxito del proyecto.
Para reflexionar
Y por último, algunas preguntas para hacerte pensar.
¿Qué relación tienes como probador con tus desarrolladores? O, si eres desarrollador y estás leyendo esto, ¿cuál es tu relación con quienes prueban? Quizá deberías preguntar a tus compañeros de desarrollo o de pruebas cómo describirían vuestra relación. ¡Compara vuestras opiniones!
Para que los equipos de pruebas de software sean productivos, deben comunicarse y colaborar.
