¿Qué es la historia de usuario y los criterios de aceptación (ejemplos)?

Ejemplo:

Como usuario de WhatsApp, quiero un ícono de cámara en el cuadro de escritura del chat para capturar y enviar imágenes para poder hacer clic y compartir mis imágenes simultáneamente con todos mis amigos.

¿Qué es un criterio de aceptación?

Un criterio de aceptación es un conjunto de condiciones o reglas comerciales aceptadas que la funcionalidad o característica debe satisfacer y cumplir para ser aceptada por el propietario del producto o las partes interesadas.

Esta es una parte muy importante de la finalización de la historia del usuario y debe ser estudiada por el propietario del producto y el analista comercial muy meticulosamente porque omitir un solo criterio puede costar mucho. Esta es una lista simple numerada o con viñetas.

Su formato es el siguiente:

“ Dada alguna condición previa cuando hago alguna acción, espero el resultado ”.

software gratuito de copia de dvd para mac

Ejemplo (w.r.t a la historia de usuario anterior):

• Consideremos que estoy charlando con un amigo y debería poder capturar una imagen.
• Cuando hago clic en una imagen, debería poder agregar un título a la imagen antes de enviarla.
• Si hay algún problema al iniciar la cámara de mi teléfono, aparece un mensaje de error como 'No se pudo iniciar la cámara'. etc., deben mostrarse en consecuencia.

Por lo tanto, la historia del usuario define el requisito de cualquier funcionalidad o característica, mientras que los criterios de aceptación definen la 'Definición de hecho' para la historia del usuario o el requisito.

Como garantía de calidad, es muy importante comprender profundamente la historia del usuario y sus criterios de aceptación sin que quede ni una sola duda al 'inicio de la prueba'. En el futuro, entendamos por qué es extremadamente importante profundizar en las historias de los usuarios y los criterios de aceptación.

Profundizando en las historias de los usuarios

Para empezar, comprendamos primero la importancia de un estudio 'en profundidad' de una cosa básica y fundamental, es decir Historias de usuarios.

Los siguientes casos son mis propias experiencias reales.

Caso 1:

Antes de 3 años, estaba trabajando en un proyecto de aplicación móvil y el producto era una aplicación diseñada para los repartidores.

Habría visto a un repartidor llegar a su lugar para realizar la entrega. Y tienen un teléfono móvil en el que te piden que firmes después de la entrega. Esta firma se refleja en el portal de los proveedores de servicios de mensajería como DTDC, FedEx, etc.

Imaginemos que la aplicación móvil se acaba de lanzar y sus portales ya existen y están en funcionamiento.

Problema: Para un Sprint, el propietario de su producto tiene una historia de usuario para esta aplicación móvil que 'Como administrador del portal, debería poder ver la firma tomada por la persona que realiza la entrega en el momento de la entrega' . Aquí, el portal (aplicación web) se cambia y actualiza en consecuencia para reflejar la firma.

Como QA, debe verificar si la firma capturada en la aplicación móvil se refleja como se esperaba en el portal.

Si observa esta historia de usuario, parece simple, pero hay un requisito oculto aquí que dice: 'Para las entregas históricas, no había una función de reflejo de firma, entonces, ¿qué debería suceder si los chicos del portal ven las entregas históricas?' ¿Deberían borrarse los datos históricos? ¿Deberíamos permitir bloqueos o errores para dichos datos?

Por supuesto que no, esto debe manejarse con amabilidad.

Solución: Cuando las tablas de base de datos respectivas se actualizan para agregar una nueva columna para la ubicación de la firma, los datos antiguos deben tener un valor NULL o 0 que debe verificarse y debe mostrarse un mensaje que indique 'No existe firma'.

Esto se puede llamar una falta del propietario del producto o del analista de negocios, pero debe hacerse. Los clientes no desean implementar una función con éxito pero romper algo junto con ella. Esto debe hacerse junto con la misma historia de usuario y en el mismo sprint.

Caso # 2

Hace 6 años, estaba trabajando en una Aplicación de Finanzas para la Planificación de la Jubilación (sin BA) que era una aplicación global donde la gente de Finanzas como CA, Asesores Financieros podían usarla para diferentes monedas para proyectar los planes de inversión, ahorros, etc., sobre un gran período a sus clientes.

Problema: El propietario del producto le brinda una historia de usuario que “Como asesor, quiero ver el informe de mi cliente en función de los detalles financieros proporcionados”.

Aquí había 2 requisitos ocultos y lo llamaría una historia incompleta porque:

a) Los informes deben considerar la tasa de conversión de moneda diaria y no la histórica como en el último informe visto y

b) Si se cambia la moneda después de proporcionar los detalles financieros del cliente, los informes deben mostrarse en la moneda cambiada.

Solución: Le planteé esta inquietud directamente a nuestro Product Owner y le hice saber que ambas cosas tenían que hacerse lo antes posible. Estuvo de acuerdo conmigo y creó 2 historias diferentes para los próximos sprints con prioridad.

Quitar: Estos fueron detectados porque todos conocíamos muy bien los productos, su diseño, estructura, etc. Este conocimiento solo se puede lograr entendiendo el producto por completo, entendiendo la interoperabilidad de los módulos y estudiando la historia del usuario a fondo, incluso si es un 2 liner.

Tome notas para facilitar las cosas y hable con los BA y los desarrolladores sobre su forma de pensar.

Análisis en profundidad de los criterios de aceptación

Comprender los criterios de aceptación y todas las demás condiciones y reglas de manera exhaustiva es incluso más importante que entender la historia de un usuario. Porque si un requisito es incompleto o vago, se puede retomar en el siguiente sprint, pero si se pasa por alto un criterio de aceptación, la historia del usuario en sí no se puede publicar.

Supongo que todos habríamos utilizado la banca neta en algún momento y la mayoría de nosotros la usamos todos los días y descargo mucho mis declaraciones históricas. Si lo observa con atención, hay ciertas opciones específicas disponibles para descargarlos.

Existe una opción para seleccionar el tipo de archivo para descargar su estado de cuenta. Hay una opción para elegir si desea descargar solo los Créditos / Débito / ambos.

Ahora imagine que el propietario del producto le brinda esta historia de usuario: 'Como cliente, quiero descargar mi estado de cuenta para poder ver todas mis transacciones realizadas durante un período específico'.

Con los siguientes criterios de aceptación:

• Teniendo en cuenta que estoy en la página Descargar declaración histórica, debo seleccionar el período para el que quiero descargar la declaración.
• Teniendo en cuenta que estoy en la página Descargar estado de cuenta histórico, debo seleccionar la cuenta para la que quiero descargar el estado de cuenta.
• Teniendo en cuenta que estoy en la página Descargar declaración histórica, no se me debería permitir descargar la declaración para la fecha 'Hasta' futura.
• Teniendo en cuenta que estoy en la página Descargar declaración histórica, no se me debería permitir seleccionar la fecha 'Desde' 10 años después en el pasado.
• Teniendo en cuenta que descargué mi estado de cuenta, debería poder ver el archivo descargado.
• Teniendo en cuenta que estoy en la página Descargar declaración histórica, debería poder descargar mi declaración en formatos doc, excel y pdf.

Si pasa por esta aceptación, faltan 3 cosas aquí:

• Nombre y formato del nombre del archivo que se descargará.
• Qué información (nombres de columna) se mostrará en el archivo.
• La lista de opciones para seleccionar qué tipo de transacción desea el cliente, es decir, solo débitos o solo créditos o ambos.

Estos casos pueden suceder de vez en cuando, sin embargo, estudie bien cada criterio de aceptación e intente visualizarlo con referencia a la historia del usuario. Cuanto más estudie profundamente sobre las condiciones y las reglas comerciales, más conocimiento tendrá sobre la función.

Los errores encontrados en la etapa inicial no cuestan nada en comparación con lo que pueden costar en la etapa de 'prueba'.

Importancia de encontrar discrepancias en la historia del usuario / criterios de aceptación

Siempre es importante profundizar en las historias de usuario y los criterios de aceptación en una etapa temprana, incluso antes de que comience el desarrollo o las pruebas.

Porque involucra:

# 1) Pérdida de tiempo:

Si se encuentran discrepancias o errores en la historia del usuario / criterios de aceptación cuando el desarrollo o las pruebas están en curso, es posible que sea necesario realizar muchas modificaciones en el tiempo restante del sprint.

No sucede que incluso si el propietario del producto se perdió algunas cosas, moverá la historia del usuario al próximo sprint. El 95% de probabilidades es que le pidan al equipo que haga la implementación necesaria y la publiquen en el mismo sprint.

De ahí que se convierta en una pesadilla para el equipo, ya que tienen que dedicar más tiempo, venir los fines de semana o trabajar hasta tarde en la noche. Esto se puede evitar estudiando y discutiendo la historia del usuario / los criterios de aceptación en la etapa más temprana posible.

# 2) Desperdicio de esfuerzos:

Los desarrolladores y el control de calidad tienen que revisar el código implementado y los casos de prueba nuevamente. Actualizar, agregar y eliminar según los requisitos no es una tarea fácil. Se vuelve demasiado doloroso porque ya existe la presión de entregar a tiempo.

En tal situación, existen posibilidades de errores en la etapa de desarrollo o prueba. Si se encuentra con tal situación, elija 'DevQA Pairing'. Como guinda del pastel, es posible que no obtenga una compensación por el trabajo extra.

Conclusión

La comprensión profunda de la historia de usuario y los criterios de aceptación solo se puede lograr dedicando una gran cantidad de tiempo a estudiarla.

No existe una herramienta o curso específico disponible en el mercado para hacer esto, ya que se trata de pensamiento lógico, experiencia y conocimiento sobre el producto.

Participar activamente en la reunión del plan previo, hablar con el BA, estudiar por su cuenta solo puede ayudarlo a lograrlo. Mientras más esfuerzos pongas, más aprenderás y crecerás.

Ya sean los QA o los desarrolladores, todos deben estar en sintonía sobre las historias de los usuarios y sus criterios de aceptación, solo entonces las expectativas del cliente se pueden lograr con éxito.

¿Tiene algo nuevo que compartir con nosotros sobre sus experiencias al trabajar con User Stories? ¡Exprese sus pensamientos a continuación!

Lectura recomendada

• MongoDB Crear usuario y asignar roles con ejemplos
• Plantilla de muestra para el informe de prueba de aceptación con ejemplos
• Autenticación de usuario en MongoDB
• Parametrización de datos de JMeter usando variables definidas por el usuario
• Permisos de Unix: permisos de archivo en Unix con ejemplos
• ¿Qué son las pruebas de aceptación (una guía completa)?
• ¿Qué es la prueba de aceptación del usuario (UAT): una guía completa?
• Tutorial de Python DateTime con ejemplos