Primero: estoy probando este foro, aunque esto es más una cuestión de gestión de pruebas que de gestión de proyectos. El intercambio de prueba/control de calidad parece centrarse en preguntas y problemas técnicos y prácticos.

La pregunta central, copiada de la parte inferior por solicitud: Supongo que lo que estoy preguntando son sugerencias sobre qué/cómo probar qué/dónde y cómo organizar las pruebas. Con respecto a la participación del cliente/usuario, pero también en el propio equipo de desarrollo (con los desarrolladores y probadores). Intentaré aclarar la pregunta más si es necesario, por supuesto.

Me pregunto si alguien tiene alguna idea y / o pensamiento sobre un entorno de desarrollo y prueba con el que estoy luchando un poco, en cuanto a la gestión de pruebas y pruebas.

Vengo de un entorno más tradicional, donde habíamos separado Pruebas de sistema y Pruebas de aceptación. La prueba del sistema fue realizada por los probadores/ingenieros de control de calidad, mientras que la prueba de aceptación fue realizada por el cliente y sus usuarios avanzados/probadores. Por lo general, la prueba de aceptación tenía un administrador de pruebas dedicado, y el administrador de pruebas del sistema le entregaba su informe de prueba a él y a los propietarios del producto.

También he sido probador y gerente de pruebas en equipos Scrum (ish). Pero esto no era muy diferente de cómo solíamos hacerlo en entornos más basados ​​en cascada. El administrador de pruebas y/o los evaluadores crearon casos de prueba al comienzo y durante cada sprint. Estos se crearon a partir de los requisitos y se ejecutaron durante los sprints tan pronto como las tareas de desarrollo se terminaron y registraron.

Durante los sprints, especialmente cerca del final, ejecutamos el conjunto de pruebas de regresión. Esta fue una colección de pruebas existentes, así como aquellas pruebas nuevas que decidimos incluir en la suite. Bastante estándar.

Los sprints a menudo también terminaban en una demostración para los propietarios del producto/cliente, aunque esto no siempre era posible debido a una posible planificación deficiente del sprint y la funcionalidad.

Al final de los X sprints, teníamos una fase de prueba del sistema, que incluía una gran colección de pruebas realizadas durante los sprints, pruebas de regresión, etc.

Luego se creó el informe de prueba y se entregó "todo" a los gerentes de prueba y proyecto para el cliente.

Ahora, me encuentro en un entorno/equipo de desarrollo donde las cosas son un poco diferentes, y me cuesta un poco descubrir qué, cómo, cuándo, etc. Tanto en lo que respecta a las pruebas reales como a las métricas. administración, etc. Es el desarrollo de una nueva versión de un sistema que ya está en producción, con nuevas funciones y corrección de errores.

• El proceso de desarrollo es una especie de scrum (ish), en el sentido de que está organizado en sprints de dos semanas (lo que me parece un poco corto). Sin embargo, no hay reuniones diarias, solo una reunión semanal.
• Usamos implementación e integración continuas (en los entornos de prueba). (Los procesos de liberación para prod. env. aún no están grabados en piedra.)
• El proyecto usa TFS y los flujos de trabajo especificados y los tipos de elementos de trabajo predeterminados para ese sistema: EPICS, CARACTERÍSTICAS e HISTORIAS DE USUARIO (así como errores y tareas, por supuesto).
• Todavía no hay un buen enfoque en las pruebas unitarias entre los desarrolladores. Este es un trabajo en progreso.
• No hay una fase de planificación de todo el equipo al comienzo de cada sprint; El gerente de desarrollo/equipo decide qué Historias de usuario llevar a cada sprint.

Así está estructurado el proyecto (por el momento):

EPICS: Todavía no los he resuelto por completo, y tampoco los líderes de desarrollo, o eso parece. Un trabajo en progreso.

CARACTERÍSTICAS: Esta es una colección de historias de usuarios (generalmente no más de un puñado.

HISTORIAS DE USUARIOS: Estas son muy pequeñas y específicas. Ejemplo:

• US1: Como usuario X, puedo ver una lista de cada arrendatario de un cliente.
• US2: Como usuario de X, puedo editar una entrada de arrendatario para...

El equipo de control de calidad/los probadores están, a partir de ahora, probando las historias de los usuarios. Al principio, traté de implementar una rutina de creación de casos de prueba para cada historia de usuario, organizada por sprint. Sin embargo, pronto vi que todos los casos de prueba e historias de usuarios terminaban 1 a 1, y que las descripciones de los casos de prueba eran solo una repetición de la historia de usuario y sus detalles, que son muy sencillos y no están sujetos a debate ni interpretación. (véase más arriba). Un montón de casos de prueba con uno o dos pasos que eran 100% obvios al mirar la historia del usuario parecía una pérdida de tiempo. Así que decidí/decidimos tratar de omitir los casos de prueba y solo usar los comentarios y el estado de las historias de los usuarios, ya que los casos de prueba han demostrado ser nada más que trabajo extra hasta el momento. Con solo dos semanas por sprint, no es deseable hacer trabajo/documentación doble o innecesaria. Tampoco hay "

Tiene alguna idea sobre esto? Estoy acostumbrado a los PBI en una configuración de Scrum, que a menudo eran lo suficientemente complejos como para necesitar al menos un caso de prueba con muchos pasos detallados y, a veces, más de uno. O había casos de prueba bastante grandes que, naturalmente, cubrían más de un PBI. En este caso, ese no ha sido el caso todavía. En este entorno, los casos de prueba son muy pequeños y aislados, y rápidos de probar. (La calidad entregada para cada historia de usuario es otra historia por completo, pero eso es un trabajo en progreso con los desarrolladores y líderes).

He estado pensando en la necesidad de casos de prueba para las CARACTERÍSTICAS, que creo que está más relacionado con el cliente. Sin embargo, estos son solo una colección de historias de usuarios que ya se probaron. Sus títulos tampoco son más que una breve descripción. Pero supongo que este es el lugar para los casos de prueba, ya que creo que deben ser probados o verificados por los clientes/usuarios del sistema.

Supongo que lo que pido son sugerencias sobre qué/cómo probar qué/dónde y cómo organizarlo con respecto a la documentación, la trazabilidad y la mayoría de los problemas comunes relacionados con las pruebas. Todavía no hay una participación real de los clientes/usuarios, pero creo que esto debe hacerse, al menos a nivel de CARACTERÍSTICA o ÉPICO. Pero esto requiere el tiempo y el conocimiento para escribir casos de prueba basados ​​en cadenas de valor y escenarios, lo que creo que es bastante diferente desde el punto de vista de un sistema/historia de usuario.

Vale la pena señalar que este es un equipo de desarrollo permanente que trabaja en un sistema de forma permanente y ahora trabaja en la versión 3 del mismo sistema. Entonces, el objetivo es el mismo sistema, solo que con más y mejores funciones, así como funciones adicionales solicitadas tanto por clientes externos como por usuarios internos. Pero a partir de ahora no hay nadie que actúe como propietario del producto o responsable de los requisitos. Esto también está en proyecto.