Criterios de aceptación para casos extremos

Soy propietario de un producto en un equipo ágil. Cuando hago pruebas de aceptación de pedidos, generalmente tomo nota para probar algunos casos extremos. No es raro que descubra algo y luego lo devuelvo a los desarrolladores. Estoy rechazando uno de los desarrolladores cuando rechazo sus historias. Él dice que es injusto ya que no especifico los casos extremos y cómo el programa debe responder en los criterios de aceptación, ya que tiende a codificar solo lo que describo en la historia. Lo he alentado a que me pregunte mientras se topa con cualquier caso de borde mientras codifica, pero piensa que no es su trabajo pensar en los casos de borde, es mío y debería hacer nuevas historias para el próximo sprint.

En mi defensa, no conozco su diseño para la historia hasta después de que la implementa, por lo que es difícil iterar a través de todas las posibilidades (¿la configuración estará en un DB o archivo de propiedades?). Por simplicidad, digamos que tenemos una historia para agregar división a una aplicación de calculadora. En el mundo SCRUM ideal, ¿me incumbiría agregar un "escenario de división de manejar por cero" a los criterios de aceptación o debería estar trabajando en esos casos a medida que se desarrolla para que la aplicación no implosione en 5/0? Para ser claros, en este caso no aceptaría si la aplicación se bloqueó con fuerza en 5/0, pero pasaría si registra, imprime DIV0 o cualquier otra forma de manejar el error ... siempre y cuando no No te estrelles.

Creo que la respuesta es que ambos deberían estar pensando en su propio conjunto de casos extremos. Él como el desarrollador debe manejar casos extremos que son específicos de los datos, como la aplicación se bloquea por cualquier entrada del usuario, 5/0 ciertamente cae en esta parte del espectro. El desarrollador debe preguntarle sobre lo que cree que sería un mensaje de error apropiado cuando la entrada dada como parte de la interacción del usuario conduce a algo no válido.

Su porción del espectro es el lado comercial de las cosas. ¿Cómo debe comportarse la calculadora si la cuenta del usuario no puede usar el botón dividir? ¿Cómo debería comportarse cuando la cuenta puede usar la operación Mod pero no tiene acceso a la función de división?

El mensaje importante que creo que debe transmitir, y para que todos los miembros del equipo lo acepten, es que todos están en el mismo equipo. Si el producto no está completo, el producto no está completo y el equipo tiene la culpa, no cualquier miembro dado.

El equipo necesita trabajar juntos en lugar de tener un tipo de actitud / mantra "No es mi trabajo, no es mi responsabilidad".

Los criterios de aceptación se presentan en forma de:

• Aceptación comercial
• Aceptación de garantía de calidad

Por lo general, la aceptación comercial suele responder la pregunta:

• ¿La función que se ha implementado hace lo que quiero que haga?

La función tendrá una serie de requisitos orientados a los negocios, por ejemplo, si presiono este botón, espero que ocurra esta acción. Enumerará los escenarios comerciales esperados y el comportamiento esperado, pero no cubrirá todos los casos posibles.

Se espera que los requisitos comerciales se definan antes de una iteración para que el aseguramiento de la calidad pueda desarrollar cualquier requisito técnico sobre los no comerciales. El aseguramiento de la calidad debe desarrollar casos destructivos, así como casos extremos, según sea necesario.

Ambos conjuntos de requisitos deben revisarse antes de comenzar cualquier trabajo de historia para que pueda producirse una estimación formal y un compromiso para la unidad de trabajo. Una vez hecho esto, se puede trabajar en la función / historias. En este punto, todos tienen claro lo que se debe entregar tanto desde el punto de vista comercial como técnico.

La historia llega a la aceptación final una vez que los miembros del equipo de negocios y garantía de calidad firman la historia. Esto debería suceder durante la iteración tanto para la aceptación comercial como para la aceptación del control de calidad. Esta es la definición de hecho (DoD) que indica que se puede comenzar un trabajo de historia adicional.

Cualquier hallazgo nuevo puede registrarse como defectos o picos de historia adicionales. En un mundo perfecto, esto nunca sucedería, pero en realidad generalmente hay una cierta cantidad de "descubrimiento" que ocurre cuando se trabaja en una característica / historia. Esto es natural

El equipo debe trabajar en conjunto (empresa, control de calidad, desarrollador) para resolver cualquier tipo de requisitos de descubrimiento nebuloso. Si esto es ágil, todos deberían estar sentados en la misma mesa para fomentar la comunicación y la resolución rápida de cualquier pregunta que pueda surgir. Debería ser algo como esto:

QA:

"Oye, desarrollador, deberíamos manejar este escenario en particular. He descubierto que si ingreso estos datos me sale un error".

DEV:

"Eso no estaba cubierto en ningún requisito, pero podemos agregar algunas funcionalidades adicionales para cubrir esto. OK, Hey Business Person, ¿cómo le gustaría que se comportara la aplicación para este caso?"

NEGOCIO:

"Muestremos nuestro mensaje de error estándar y dejemos que el usuario lo intente nuevamente para este escenario. ¿Cuánto esfuerzo adicional será entonces?"

DEV:

"Será fácil, solo una o dos horas más. Puedo comprometerme para esta iteración. Control de calidad, actualice sus criterios de aceptación para este escenario, no necesitamos una historia adicional para esto. ¡Gracias!"

O si es mucho trabajo, se agrega una nueva historia a la cartera de pedidos. El equipo aún puede aceptar la historia original, ya que cumple con todos los requisitos originales, y luego retomar la historia de la espiga en la próxima iteración.

Escribir software que se comporte de manera robusta frente a una entrada incorrecta o ambigua es una parte esencial del trabajo de un desarrollador de software.

Si sus desarrolladores no lo ven de esa manera, incluya requisitos no funcionales adicionales en la especificación de requisitos que establezca este requisito explícitamente, y proporcione a sus desarrolladores un ejemplo de su proceso de prueba para que puedan aplicar ese proceso ellos mismos antes de enviar su versión final. Código para revisión.

Las pruebas de aceptación deben ser una parte vital de cualquier documento de requisitos de todos modos. Si un requisito no establece también sus criterios de aceptación, en realidad no es un requisito; Es un deseo.

Lo que ha sucedido aquí es que has descubierto valor . No se pensó el valor de entrada cuando se escribió la historia (y los criterios de aceptación) o cuando se escribió el código. Si no es parte del criterio de aceptación, realmente no tienes una base para rechazar la historia.

Lo que haríamos en mi equipo es:

1. Cree un error que detalle el comportamiento esperado y real.
2. Actualice los criterios de aceptación para que se documente el nuevo requisito encontrado.
3. Priorice el error junto con todas las otras historias y errores en la próxima iteración.

El beneficio aquí es que se ve obligado a considerar si corregir o no este error es la siguiente cosa más importante que hacer. Puede o no ser lo suficientemente importante como para solucionarlo, pero es importante que se considere su valor.

Por supuesto, aún necesita encontrar una manera de alentar a los desarrolladores (y a usted mismo) a explorar estos casos límite por adelantado. Si su equipo de desarrollo no está pasando el tiempo analizando historias, aliéntelos a tener una sesión de planificación detallada antes de comenzar a trabajar en ellos.

Algunas observaciones

... cuando rechazo sus historias

No conozco su cultura o proceso de trabajo, pero para mí rechazar una historia es un paso severo. Si yo fuera el desarrollador, también generaría un retroceso en eso, ya que es una acción grabada que se refleja mal en mí y en el equipo.

Él dice que es injusto ya que no especifico los casos extremos.

Es injusto de su parte esperar que conozca todos los casos límite. Pero al mismo tiempo, es injusto que esperes eso de él. Cada cambio tiene riesgo y, a medida que se descubren problemas, todos deben trabajar juntos como un equipo para abordarlos.

No sé su diseño para la historia hasta después de que la implemente

No deberías tener que conocer el diseño. Puede ser útil conocer el diseño para hacer conjeturas educadas iniciales sobre qué historias son más fáciles o más difíciles para la gestión de la cartera de pedidos. Pero evite atrapar al desarrollador en su diseño cuando escriba historias. Es muy divertido cuando eres simplemente un teclado activado por voz para el PO.

Parece que ustedes deberían trabajar en la mejora de procesos y hacer algo de trabajo en equipo. Algunas cosas que podría sugerir para el proceso:

• Sugiera que el desarrollador incluya tiempo en la historia para la tapa arreglando casos extremos descubiertos. Diablos, hazlo parte de cada historia de usuario. Esto es fácilmente defendible a través del objetivo de 0 nuevos errores introducidos. El problema es que el desarrollador no lo está planeando actualmente. Y se le acaba el tiempo cuando descubre problemas. Tomará tiempo de cualquier manera, así que póngalo en la historia donde sea visible durante la planificación.
• Después de su prueba (y gracias por probar por cierto!), Envíe al desarrollador una lista de problemas descubiertos. La solución de esos problemas irá en contra de la condición de satisfacción de los "casos de borde de reparación".
• Si algo permanece sin reparar o se descubre demasiado tarde, decida si la historia necesita ser promovida en función de si el caso de uso puede cumplirse. Problemas conocidos y soluciones alternativas suceden. Divulgarlos en notas de lanzamiento y crear nuevas historias para solucionarlos.
• Si hay un punto difícil en particular en el proceso que genera retroceso, ¡entonces cambie su proceso! Después de todo, la mejora del proceso es parte de Scrum. Por ejemplo, si su desarrollador se molesta cuando rechaza la historia, sugiera al equipo un cambio en el proceso para que el rechazo no provoque soluciones. Haga las pruebas y arreglos antes de Listo y Rechazado.
• Trabaje con el equipo y lo que han producido y haga el mejor uso posible. No hacen un trabajo perfecto y tú tampoco. Así que planifica eso. Por lo general, mis equipos han sido devops, por lo que tenemos una historia de usuario de soporte no planificado cada sprint para problemas emergentes ... planeando lo que no se puede planificar.

Los requisitos deben ser claros y concisos. Si no lo son, entonces sucede exactamente lo que te sucedió. Es su culpa, y lo peor que puede hacer al especificar los requisitos es asumir las cosas.

Usted ejemplo específico, sobre la división por cero. Si no especificó que desea registrar el error, no se queje si el desarrollador imprime 100 como resultado.

Pero en tales casos, simplemente llenaría los vacíos faltantes y los pasaría al desarrollador. Después de todo, ocurren errores en los requisitos.