Codificación y prueba en el mismo sprint

22

¿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.

Mark Richman
fuente
2
No eres la primera persona en tener este dilema. Podría usar una canalización: en el sprint actual, el equipo de prueba prueba las características que se han implementado durante el sprint anterior.
Giorgio
2
PM obliga al equipo a hacer las cosas a su manera, suena como un Ágil Medio Arsed
mosquito
8
@ Mark Richman: ¿Cascada? No tiene ciclos de desarrollo de 1-2 semanas en cascada. Creo que no tiene idea de lo que está hablando.
Giorgio
2
@gnat: si el equipo no funciona particularmente bien (y parece que este equipo se ajusta a esa descripción), podría ver esto como el primer ministro que guía al equipo a desarrollar una estrategia de desarrollo más efectiva. Quizás el primer ministro sienta que entregar constantemente código no probado no es bueno para el negocio. Ágil no necesariamente significa "dejar que los equipos hagan lo que quieran", debe haber algunos límites hasta que un equipo sea lo suficientemente maduro como para decidir por sí mismo.
Bryan Oakley

Respuestas:

13

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.

AlfredoCasado
fuente
8

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!

Sklivvz
fuente
2
Esta organización ha creado límites y roles claros para "desarrolladores" y "probadores", y nunca se encontrarán entre los dos;)
Mark Richman
Entonces, ¡cambia la regla!
Sklivvz
3
@MarkRichman en uno de mis trabajos anteriores también tenía límites claros en los roles de "desarrolladores" y "probadores", pero esa organización no puso nada para que se comuniquen (¡qué mala idea por cierto!); Recuerdo que hice sprints en pareja con el "probador asignado" y todo salió genial. ¿Su empresa simplemente separa roles o establece adicionalmente una barrera de comunicación / colaboración entre los ingenieros que cumplen estos roles?
mosquito
1
"El problema esencial es que tienes programadores que codifican pero no prueban y probadores que prueban pero no codifican": ¿Eh? ¿Por qué es esto un problema? Un programador debería, bueno, programar y un probador debería probar. Además, necesita alguna característica mínima que se implemente antes de poder probarla : no puede paralelizar dos tareas si el resultado de una tarea es la entrada de la otra tarea.
Giorgio
@ Jorge es una vista de cascada. En ágil, las personas que pueden ofrecer valor de forma independiente son muy favorecidas. No hay ninguna razón por la cual el desarrollo y las pruebas deberían ser profesiones separadas. Es una elección respetable, pero poco adecuada para el desarrollo ágil.
Sklivvz
4

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.

Arseni Mourzenko
fuente
De hecho, creo que gran parte del problema de esta organización (para lo cual soy nuevo) es que se dedica poco tiempo a analizar los requisitos y definir una solución que se pueda descomponer en pequeñas unidades atómicas. Con el proyecto y el estado actual del equipo, creo que el sprint actual no debería haber sido más que un sprint de análisis, donde los entregables son PBI completos con tareas y casos de prueba. Sin embargo, parecen centrarse en el dinero que me pagan cada hora, y por cada hora que no estoy "codificando con el teclado" están perdiendo valor.
Mark Richman
@MarkRichman por cada hora que le pagan para escribir tonterías en la base de código que están perdiendo, no solo la hora por la que le pagan, sino todas las horas que toma sacar las tonterías de la base de código.
Más el
4

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.

Telastyn
fuente
1
Estoy acostumbrado a que QA esté atrasado en sus pruebas. La gente aquí quiere ver todo el SDLC completo cada dos semanas. Simplemente no veo cómo eso es posible.
Mark Richman
55
@MarkRichman - ¿Por qué no? 1 día para planificación, 5 días para codificación y 4 para pruebas unitarias, documentación, corrección de errores y diseño para el próximo sprint. El desafío no es realmente lograrlo, sino ser lo suficientemente disciplinado como empresa para hacer bien una pequeña cantidad de trabajo.
Telastyn
1
porque no se centrarán en los 5 días que estoy codificando, pero los otros 5 días no. Ciertamente, llenaría los otros 5 días con codificación, pero dado que desean completar todas las tareas de codificación "sopa de nueces" (incluidas las pruebas), simplemente no es consistente con la física de la flecha del tiempo :)
Mark Richman
1
@markrichman: bien, entonces debería ser fácil señalar todas las otras cosas que no están codificando y que debes hacer para que se realicen .
Telastyn
bueno, también descubro trabajo adicional que debe hacerse para completar el trabajo comprometido durante el sprint actual. Esto obliga a que otro trabajo no se implemente para ese sprint. Esto está bien, y creo que tiene un espíritu ágil, pero me dijeron que nunca agregue nada al sprint actual, y que agregue estas tareas recién descubiertas (y completadas) a la Lista de Producto, lo que no me parece correcto. .
Mark Richman
1

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.

Derek Davidson PST CST
fuente
0

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 .

instinto
fuente
Estoy de acuerdo con usted, pero los "poderes fácticos" parecen ser puristas sobre cualquier otra cosa que no sea completar todo el SDLC en un solo sprint de dos semanas. Cualquier otra cosa que no sea esta metodología parece considerarse cascada.
Mark Richman
0

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.

logc
fuente