Estoy tratando de formalizar el flujo de trabajo de desarrollo y aquí está el primer borrador. Damos la bienvenida a sugerencias sobre el proceso y cualquier ajuste para la optimización. Soy bastante nuevo cuando se trata de configurar los procesos y sería genial recibir comentarios al respecto. PD: Estamos trabajando en una aplicación sin servidor de AWS.
Crear un enlace de problema en JIRA: probado por. El enlace 'está probado por' no tiene relevancia aparte de corregir la visualización de la relación mientras se ve la historia.
Cree un nuevo tipo de problema en JIRA - Testcase. Este tipo de problema debe tener algunos campos personalizados para describir completamente el caso de prueba.
Para cada historia de usuario, habrá un conjunto de casos de prueba que están vinculados a la historia de usuario mediante la función de vinculación de Jira. Los casos de prueba serán definidos por el QA.
Los casos de prueba de integración/e2e se escribirán en la misma rama que el desarrollador. Los casos de prueba E2E se escribirán en una rama separada ya que es un repositorio separado (Abierto para discusión).
El tipo de problema de caso de prueba también debe estar asociado con un flujo de trabajo que pasa de los estados Nuevo => En prueba => Éxito/Fracaso
Además, podríamos considerar agregar la capacidad en el sistema de CI para mover automáticamente el caso de prueba a Éxito cuando el caso de prueba pasa en el CI. (Esto debería ser posible mediante el uso de la API de JIRA). Esto es completamente opcional y lo más probable es que lo hagamos manualmente.
Cuando todos los casos de prueba se relacionan con una historia de usuario con éxito, la historia de usuario se puede mover a Listo.
Algunos puntos a tener en cuenta:
También usaremos https://marketplace.atlassian.com/apps/1222843/aio-tests-test-management-for-jira para la gestión y vinculación de pruebas.
El control de calidad debería estar trabajando en la rama de funciones desde el día 1 para agregar los casos de prueba. Trabajar en la misma rama permitirá que el control de calidad y el desarrollador estén siempre sincronizados. Esto debería garantizar que el desarrollador no esté bloqueado esperando que se completen los casos de prueba para que la rama se fusione con el desarrollo.
La rama de funciones se revisará cuando el desarrollador cree la solicitud de incorporación de cambios. Esto es para garantizar que la revisión no quede pendiente hasta que se hayan desarrollado/aprobado los casos de prueba. Esto debería ayudar con una retroalimentación rápida.
El enfoque aquí está en el proceso de "control de calidad orientado a características" para garantizar que la rama de desarrollo esté siempre lista para el lanzamiento y que solo el código bien probado se fusione en la rama de desarrollo.
La mayor parte de su flujo de trabajo propuesto se ve bien, pero hay una cosa que lo morderá.
El tipo de problema de caso de prueba también debe estar asociado con un flujo de trabajo que pasa de los estados Nuevo => En prueba => Éxito/Fracaso
No. Un caso de prueba debe tener un flujo de trabajo como Nuevo => En proceso de escritura => Listo para ejecución.
Además de eso, debe usar un tipo de problema adicional "Ejecución de caso de prueba" con el flujo de trabajo que propuso. Los problemas de ejecución de casos de prueba registran los resultados de la ejecución de uno o más casos de prueba asociados. La ventaja es que cuando hace que el sistema CI ejecute pruebas de regresión, puede simplemente crear nuevos tickets de ejecución de casos de prueba para registrar los resultados de cada ejecución, sin perder el historial de las veces anteriores en que ejecutó la prueba.
La regla para cerrar una historia sería que tenga una Ejecución de caso de prueba que muestre todas las pruebas que pasan.
Además, antes de comenzar a agregar manualmente nuevos tipos de problemas relacionados con las pruebas, verifique qué tipos de problemas agrega AIO Tests para usted a Jira.
Tomas Owens
Bart van Ingen Schenau
Tomas Owens