Codificación y prueba en el mismo sprint

¿Cómo se manejan las pruebas dentro del mismo sprint que la codificación, si toda o la mayor parte de la codificación no se realiza hasta el final del sprint? (Me refiero al desarrollo y prueba de "sopa de nueces" de un solo PBI dentro de un sprint).

La mayoría de las respuestas que he visto en línea involucran la automatización del control de calidad, pero incluso eso no es realmente posible, ya que generalmente necesita una interfaz de usuario funcional para grabar o crear pruebas automatizadas. Solo tengo guiones gráficos que continúan evolucionando a medida que desarrollo características y descubro nuevos requisitos.

En mi caso, estoy desarrollando una nueva aplicación de escritorio. Las aplicaciones de escritorio generalmente no se prestan muy bien a las pruebas automatizadas. Tengo algunas pruebas unitarias automatizadas, pero no son las pruebas funcionales / de integración manuales que realizaría un profesional de control de calidad.

Entonces, donde estoy ahora es que mi sprint termina mañana, todavía tengo que codificar para terminar, y mis amigos de QA aún no tienen nada que probar, y no tengo idea de cómo probar lo que les daría sin que yo los tome de la mano.

Estoy seguro de que no soy la primera persona en tener este dilema.

En el pasado, hice una tubería: en el sprint actual, el equipo de prueba prueba las características que se implementaron durante el sprint anterior. En mi trabajo actual, el primer ministro se refiere a este enfoque como "cascada" y, como tal, inaceptable.

Si no prueba una historia de usuario (EE. UU.) Y verifica que se cumplen los criterios de aceptación, esta historia no se realiza. Si no se hace esto, Estados Unidos pasa al siguiente sprint, por supuesto. Y si todos sus Estados Unidos están en este estado, el sprint ha finalizado sin ningún valor agregado al proyecto. Desde el punto de vista del cliente, no puedo distinguir esto de todo el equipo de desarrollo que se va de vacaciones.

Uno de los principios lean (ágil no termina con scrum) dice que "la calidad está integrada". Solo se hace algo si cumple con los criterios de calidad que usted define. Esto es crucial para tener un proceso ágil real, terminar la primavera con un valor cero o pruebas separadas del desarrollo son síntomas de un gran problema.

Hay muchas cosas que puedes hacer:

• La automatización es clave para el éxito. Al menos a nivel de prueba unitaria, y algunas otras prácticas como CI también son importantes. Esto no es suficiente, pero si se hace bien, este tipo de pruebas resultan en pocos o ningún error descubierto en las pruebas manuales (generalmente cosas menores en la interfaz de usuario). Si tiene personal de control de calidad dedicado, ellos pueden ser los que automatizan las pruebas de aceptación, y parte de esta automatización puede comenzar antes de que termine un sprint.

• Mira el tamaño de tus historias de usuario. Si tiene un EE. UU. Que finalizó los dos primeros días del sprint el tercer día, una persona de control de calidad puede probarlo. En mi opinión, tener historiales de usuarios pequeños (SMART) es una de las cosas más importantes para tener éxito en el desarrollo ágil, y mucha gente parece no darse cuenta de esto.

• La colaboración entre el probador y los desarrolladores es otra parte clave del éxito. En mi proyecto anterior, cuando un desarrollador de EE. UU. Lo termina una persona de control de calidad realiza "pruebas de emparejamiento" con el desarrollador (puede ser manual, puede ser mediante el lanzamiento de algunos automatizados, o mejor, ambos), esto funciona bastante bien.

El problema esencial es que tienes programadores que codifican pero no prueban y probadores que prueban pero no codifican.

Resuelva ese problema y no tendrá este problema, y ​​posiblemente un equipo más eficiente.

Una forma que funcionó para mí en el pasado fue sugerir a los programadores y evaluadores que combinaran historias con la tarea explícita de entregar una historia completamente probada. Junto con eso, he borrado todas las formas de pensamiento "dev complete": no hay columnas "dev complete" en el tablero scrum / kanban / trello, ninguna actitud "dev done" de los codificadores.

Lo que paso fue:

• Los pares fueron responsables de entregar historias y ambos fracasarían si no se completara una historia. Fueron tratados como profesionales responsables a cargo de entregar software y lo hicieron, en la mayoría de los casos.

• Se realizó mucho menos trabajo de prueba porque los probadores estuvieron expuestos a las pruebas de unidad e integración, por lo que no repitieron la misma prueba manualmente.

• Algunas pruebas se automatizaron cuando los desarrolladores entendieron mejor lo que los evaluadores necesitaban.

• Algunas personas se enojaron.

• Las historias se entregaron más rápido en promedio porque el ciclo de confirmación de extracción de código se volvió casi instantáneo

Por supuesto, esta es solo mi experiencia anecdótica, pero es posible que desee probarlo usted mismo si puede.

En su caso, dado su comentario de que los evaluadores y los desarrolladores están separados en su empresa, el mensaje me parece claro. Existe una barrera obvia para la comunicación y la colaboración establecida por las reglas de la compañía.

Este es un problema de comunicación , no un problema ágil . Adoptar una metodología ágil simplemente lo está haciendo evidente. Los equipos de silos son un antipatrón de gestión conocido , ¡así que adopte la no adaptabilidad de ágil en este caso!

El papel real de su QA está cerca de las pruebas de aceptación. Me imagino que esto lo hará un equipo separado, que actúa más como propietario del producto que como parte del equipo de desarrollo.

Ejemplo: durante un sprint, debe agregar una función que permita filtrar los resultados de búsqueda por diferentes criterios. Ya tiene implementado su mecanismo de búsqueda, pero los resultados están ordenados alfabéticamente.

• Durante el sprint:

  1. El equipo redacta el diseño de la nueva característica y el impacto en la base del código real.

  2. Los desarrolladores escriben pruebas unitarias que aseguran que el pedido funciona como se esperaba, y al mismo tiempo escribe el código real.

  3. La nueva característica se prueba cuidadosamente para garantizar que no rompa nada (prueba de regresión) y que funcione como se espera (pruebas unitarias).

  4. Si es posible y apropiado , que no es el caso en la mayoría de los proyectos , el propietario del producto (y, por lo tanto, su equipo de control de calidad) puede evaluar constantemente la nueva función para evitar que el equipo vaya en la dirección incorrecta. Esto requiere una integración continua con docenas de compilaciones todos los días.

• Después del sprint, el propietario del producto evalúa la nueva característica para verificar que corresponde a las necesidades del cliente. Su equipo de control de calidad está realmente aquí, después de que terminó el sprint.

Creo que sus problemas reales son los siguientes:

• Ámbito de aplicación . Un sprint concierne a su equipo, y solo a su equipo, no a su control de calidad real, que actúa más como propietario del producto.

• Las pruebas . El hecho de que tenga un equipo de control de calidad no significa que todo lo que necesita hacer es escribir código. El trabajo de su equipo es ofrecer una función que funcione como se espera, no arrojar código para que otros lo prueben. Si confía en el equipo de control de calidad para que realice las pruebas por usted, esto aumentará el costo general, ya que los errores se solucionarán una o dos semanas después en lugar de solucionarse casi al instante.

si toda o la mayor parte de la codificación no se realiza hasta el final del sprint?

¿Por qué no termina antes? Esta limitación clave es la fuente de sus problemas, y he visto que dos enfoques tienen éxito. Uno encaja bien en el enfoque ágil (pero no en otras prácticas comunes) y el otro contamina un poco ágil (pero es más común).

La primera es que no codificas hasta el final del sprint. En realidad, escribir código es una parte relativamente pequeña del desarrollo. Si terminas aproximadamente a la mitad del sprint, eso proporciona mucho tiempo para que QA haga su trabajo. También le deja tiempo de sobra para escribir documentación, limpiar deudas técnicas, diseñar para elementos pendientes ... Todas las demás cosas que necesita hacer para obtener un producto de calidad. La única desventaja de esto que he visto es que es casi imposible obtener la funcionalidad y las pruebas unitarias se hacen rápidamente. Personalmente, creo que está completamente bien hacer pruebas unitarias después de permitir que QA comience a analizar la funcionalidad, pero los defensores de TDD (y otros) no estarán de acuerdo.

La segunda opción es que QA opere un sprint detrás del personal de desarrollo como lo odia su PM. También me suele gustar esto. Elimina el concepto de "producto liberable" al final del sprint, incluso si tiene un proceso de escalado para sus lanzamientos. Peor aún, los desarrolladores se centrarán en cosas "nuevas" cuando el control de calidad llegue a ellos con preguntas o errores de las pruebas. Los desarrolladores también tienen menos probabilidades de corregir errores en este arreglo. Pero lo he visto producir software de calidad a tiempo.

La Guía Scrum requiere que los equipos sean multifuncionales. Todos los miembros del equipo se consideran desarrolladores, independientemente de su especialización individual. Las personas con silos (codificador, probador, qa, ux, etc.) no ayudan en Scrum. Los miembros del equipo se ayudan mutuamente siempre que pueden. No existe el concepto de 'pasar el elemento a qa'.

En su situación, parece que puede tener un problema de estimación. Al estimar los elementos de la cartera de productos, debe tener en cuenta todos actividades, es decir: codificación, prueba, revisión por pares, implementación, integración, cualquiera que sea su definición de demandas realizadas.

Como regla general, espere traer entre 5 y 15 elementos de la cartera de productos en un sprint. Esto le da una idea de qué tan grande debe ser cada elemento de la cartera de productos. También te brinda una excelente oportunidad de hacer el trabajo 'hecho' dentro del sprint.

Finalmente, la tarea del equipo es mover un elemento de la cartera de pedidos del producto a 'hecho' y luego pasar al siguiente. A veces, hacer esto significa que las personas pisan los dedos de los demás y, por lo tanto, tiene sentido aumentar la acumulación de más de un producto a la vez. Sin embargo, su directriz debería ser reducir su trabajo en progreso (WIP) y mover los elementos de la cartera de pedidos del producto a listo.

Las pruebas y la codificación van de la mano. Puede programarlo módulo por módulo. Una vez que el módulo esté terminado, puede suministrarlo a los probadores. Todo este escenario también depende de la fase de prueba en la que esté trabajando. El modelo SDLC en espiral se ve bien. En eso, las pruebas simultáneas y la codificación son convenientes. Otro enfoque podría ser modelo V .

Mi respuesta, que probablemente sea bastante extraña al principio, sería: no encuentra tiempo para realizar la prueba porque cree que la prueba debe realizarse sobre los efectos secundarios del código. Y con efecto secundario me refiero al término de informática :

Se dice que una función (...) tiene un efecto secundario si, además de devolver un valor, también (...) tiene una interacción observable con (...) el mundo exterior.

Mencioné la cita para enfatizar la parte de "interacción con el mundo exterior": desea que las pruebas se realicen en la interfaz de usuario tal como está impresa en la pantalla ("[para comenzar las pruebas] no es realmente posible ya que generalmente necesita una función UI para grabar o crear pruebas automatizadas desde ").

Otras respuestas le han dicho que automatice esta "prueba de aceptación", para que pueda suceder rápidamente. Esto es correcto, pero no aborda completamente su problema original: ¿qué pasa si no hay suficiente tiempo para escribir esas pruebas de aceptación?

Debe dejar de lado su punto de vista de las pruebas una vez que el código ha interactuado con el mundo exterior, es decir, ha impreso algo y espera alguna entrada. El problema con los efectos secundarios es que, en efecto, no son verificables. Esto se me ocurrió al leer una entrevista con Guido van Rossum, donde dijo que una declaración que apaga la computadora solo puede probarse que funciona al ejecutarla.

La solución a esa "imposibilidad de prueba" es comprender que, si ha demostrado una vez que la declaración funciona, puede usarla en todas partes y confiar en ella para hacer su trabajo. Aislarlo en una función y probar todo lo demás .

Al acercar ese ejemplo a su pregunta, la función ahora es probablemente una biblioteca o marco completo, y en lugar de apagar la computadora, imprime algo: una interfaz de usuario. Mantén las llamadas lo más tontas y estables posible , porque una vez que ingresa esa parte de su aplicación, solo puede probar a través de costosas pruebas de aceptación, es decir, algún tipo de observación externa.

Considerar la IU como "territorio extranjero" es en realidad un punto de vista correcto, ya que no es necesario probar la lógica de una biblioteca que no proporciona usted, y quizás sorprendentemente, es un punto de vista realista: ¿realmente esperar probar alguna vez esa llamada, por ejemplo MyWidget.draw() hace lo que espera, al nivel de un solo píxel?

Esto no quiere decir que las pruebas de aceptación no sean importantes o que se puedan omitir. Está ahí para quedarse y automatizarlo, como sugieren otras respuestas, tiene enormes beneficios. Pero si desea encontrar tiempo para probar y codificar en el mismo sprint, intente mantener su código lo más libre de efectos secundarios posible.