Azure Devops

AZURE DEVOPS
PROCESO FLEX
CÓMO ESCRIBIR LA HISTORIA DE USUARIO
DESCRIPCIÓN
Yo como ____________
Requiero ___________
Para _______________.
CRITERIOS DE ACEPTACIÓN
• Deben ser concretos y

claros.
• Deben estar enumerados.
• Los apoyos visuales se
adjuntan como archivo.
DOR
• Se debe escribir lo que

se necesita tener listo
para iniciar la HU
CARACTERISTICAS GENERALES
CUMPLE INVEST FUE APROBADA POR PO AMBIENTE
Se debe seleccionar SI o Se diligencia cuando se le Se realiza trazabilidad

NO, dependiendo del entrega la HU al PO y él cuando la HU este en
cumplimiento del criterio. confirma que esta de Desarrollo, QA o
acuerdo con lo realizado. Producción.
NUEVA EN BACKLOG ESFUERZO PUNTOS EQUIPO PROVEEDOR
Si se agrega nueva se Se colocan los puntos de Se debe diligenciar los

selecciona IN, si la HU no esfuerzo acordados por equipos que intervendrán
se va a realizar por algún QA y Desarrollo. en la HU.
motivo se selecciona
OUT.
CÓMO RELACIONAR ITEMS A LA HISTORIA DE USUARIO
Se deben relacionar los

ítems para realizar
trazabilidad de tiempos y
seguimiento al estado de
la HU.
Se relacionan:
- Tareas
- Bugs
- Impedimentos
- Casos de prueba
CÓMO ADJUNTAR DOCUMENTOS A LA HISTORIA DE USUARIO
En este espacio se deben

adjuntar los documentos
relacionados con la HU.
Se relacionan:
- Evidencias de pruebas.
- Documentos técnicos.
- Pruebas unitarias.
- Documentos de
importancia para la HU.
CÓMO SE DEBE ADMINISTRAR LA HISTORIA DE USUARIO
QUIEN LA CREA? QUIEN LA MODIFICA? QUE ESTADOS CAMBIA EL

PO?
La debe crear el PO y lo El contenido y los campos solo lo
debe hacer antes del primer puede modificar el PO, esto se - Refinada Ready
refinamiento. La HU debe realiza siempre y cuando no se - Refinada No Ready
quedar clara y concisa. haya refinado la HU, después de - Done
refinada no se podrá modificar.
QUE ESTADOS CAMBIA EL QUIEN CIERRA LA HU? QUIEN DECIDE SI LA HU SE

EQUIPO? ELIMINA?
Solo la podrá cerrar el PO, esto
- Desarrollo se realiza luego que el equipo Esto solo lo puede decidir el
- En pruebas de desarrollo y QA hagan la PO, y solamente él podrá
entrega formal de la HU. colocar el estado de la HU en
Removida.
CÓMO CREAR UN CASO DE PRUEBA
Se debe seleccionar en
Link Type y Work Item
Type la opción Test Case
Estructura del titulo:
CP001 xxxxxxxxxxxxxx
CÓMO ESCRIBIR EL CASO DE PRUEBA
PASOS
- Deben estar enumerados.

- Deben ser entendibles por
cualquier persona.
- Deben tener un resultado
esperado.
ESTADOS
- Desing: Cuando no se ha
ejecutado.
- Ready: Cuando se ejecuto y
quedo todo OK.
- Closed: Cuando es obsoleto
el caso de prueba.
CÓMO SE DEBE ADMINISTRAR EL CASO DE PRUEBA
QUIEN LO CREA? QUIEN LO MODIFICA? QUE ESTADOS SE UTILIZAN?
La debe crear el Profesional El contenido y los campos solos - Desing

de Calidad asignado al puede modificar el Profesional de - Ready
proyecto, él es quien Calidad que creo el caso de - Closed
conoce la necesidad del prueba, o en su defecto el
cliente y los requerimientos Profesional de calidad de apoyo o
a probar. reemplazo.
QUIEN CAMBIA LOS QUIEN ELIMINA EL CASO DE

ESTADOS? PRUEBA?
Solo los puede cambiar el Lo elimina el Profesional de

Profesional de Calidad, ya que Calidad, esto lo hace con el
él es el que sabe el estado estado Closed y se justifica con
actual del caso de prueba. un comentario el por que del
cierre.
CÓMO CREAR UN BUG
Se debe seleccionar en
Link Type la opción Child y
Work Item Type la opción
Bug
Estructura del titulo:
- Error: XXXXXXX
- Sugerencia: XXXXXXX
- Hallazgo: XXXXXXX
CÓMO ESCRIBIR EL BUG
DESCRIPCIÓN
Se debe hacer una descripción

corta y concisa del erro,
hallazgo o sugerencia
reportado.
PASOS
Se adjunta evidencia del bug y

adicional se da una breve guía
sobre como reproducirlo.
DETECCIÓN Y DETALLES
Se debe seleccionar cada uno

de los campos de estos
enunciados y dar prioridad y
severidad del bug, esto nos
ayuda hacer trazabilidad.
CÓMO SE DEBE ADMINISTRAR EL BUG
QUIEN LO CREA? QUIEN LO MODIFICA? QUE ESTADOS UTILIZA EL

PROFESIONAL DE CALIDAD?
La debe crear el Profesional El Bug no se debe modificar,
de Calidad asignado al solamente adjuntar evidencias de - To Do
proyecto. la solución y el retest. - Done
- Removed
QUIEN ELIMINA EL BUG? EN QUE MOMENTO SE USA

QUE ESTADOS UTILIZA EL
EL ESTADO DONE?
DESARROLLADOR? Lo cambia de estado a
Removed el Profesional de Una vez el Profesional de
- In Progress Calidad, esto luego de Calidad haya realizado retest y
- Solucionado socializar con el equipo que el verifique la solución del Bug.
Bug es obsoleto o no se
considera Bug.

Azure Devops

Cargado por

Copyright:

Formatos disponibles

Azure Devops

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Azure Devops

Cargado por

Copyright:

Formatos disponibles

AZURE DEVOPS

• Deben ser concretos y

• Se debe escribir lo que

CUMPLE INVEST FUE APROBADA POR PO AMBIENTE

Se debe seleccionar SI o Se diligencia cuando se le Se realiza trazabilidad

NUEVA EN BACKLOG ESFUERZO PUNTOS EQUIPO PROVEEDOR

Si se agrega nueva se Se colocan los puntos de Se debe diligenciar los

Se deben relacionar los

En este espacio se deben

QUIEN LA CREA? QUIEN LA MODIFICA? QUE ESTADOS CAMBIA EL

QUE ESTADOS CAMBIA EL QUIEN CIERRA LA HU? QUIEN DECIDE SI LA HU SE

Estructura del titulo:

- Deben estar enumerados.

QUIEN LO CREA? QUIEN LO MODIFICA? QUE ESTADOS SE UTILIZAN?

La debe crear el Profesional El contenido y los campos solos - Desing

QUIEN CAMBIA LOS QUIEN ELIMINA EL CASO DE

Solo los puede cambiar el Lo elimina el Profesional de

Estructura del titulo:

Se debe hacer una descripción

Se adjunta evidencia del bug y

Se debe seleccionar cada uno

QUIEN LO CREA? QUIEN LO MODIFICA? QUE ESTADOS UTILIZA EL

QUIEN ELIMINA EL BUG? EN QUE MOMENTO SE USA

También podría gustarte