Resumen Gestión de US – TS - TX

maquetado por Monica A y remasterizado por Ely

Video Saitest en Youtube:

Análisis de Requerimientos

La US estará en estado ‘En Deployed’ en QA, lista para testear por nosotros.

Pasar la US a ‘In Progress’ (En Curso):

Analizamos la prioridad y los StoryPoints ya que debemos tenerlo en cuenta para organizar nuestro trabajo en caso de tener varias US asignadas:

Crearemos el Set de pruebas (Test Set) para la US (en otros gestores le dicen “Suite”).
Siempre será un TS por cada US. A menos de que se trate de una Súper US (que contenga varias funcionalidades en una; es decir, tratemos de usar los Test Set por cada funcionalidad dado estos casos)

En la US, debajo de todo, se debería apreciar el Test Coverage (Cobertura de Pruebas), si no aparece, hacer click en el botón indicado a continuación:

Luego al final de la página en “Crear Test”:

Modificamos el tipo de incidencia a TS:

Modificamos el Resumen (Título del TS) según corresponda para una mejor nomenclatura, agregando el ID de la US:

Hacia el final de la página completamos los campos que permiten la trazabilidad del TS y luego hacemos clic en CREATE:

• a) Assignee: a quien se asigna el TS

• b) Linked Issues: “Tests” (cuyo significado figurado es, “esto está testeando a”)

• c) Issue: US ID (Siempre te aparecerán las opciones de las issues que has visto recientemente)

Ejemplo:

Aclaración: aparecerán dos mensajes, uno bueno y uno malo.

El malo es una especie de advertencia, que aparece porque creamos un Test Set desde el botón de “crear test” ya que un Test Set no se puede asociar al Test Coverga, pero nosotros lo hacemos porque es la manera más rápida de crear la incidencia test Set (sino, también puedes crearla desde el botón “crear” arriba en el header de Jira”. Entonces el mensaje de advertencia sería:

El bueno es el que indica que el TS ha sido creado y te ofrece el link para ingresar.

Ej:

Ingresamos al TS generado

Verificamos que tengamos linkeada la US

Verificamos/completamos los campos del panel derecho:

• Test Type: Es un dropdown corto con las únicas opciones de “Manual” o “Automation”|, es para definir si este Set se puede automatizar o no. Esto se determina con la EstimaciónVCR!

• Regression Test Plan: Es un dropdown son simplemente “YES” o “NO” como opciones, para definir si este Set se llevará a Regresión o no. Esto se determina con la prioridad de la US y sumando el factor influyente de la VCR:

  • Un Set puede llevarse a Regresión, ya sea Manual o Automatizado, esto último depende de una estrategia de estimación (como la VCR que aplicamos en UPEX), pero el factor más importante es la Priorización de Negocio.

  • Un Set puede tener una Prioridad baja, pero una Estimación de Automatización muy alta, y en esos casos es más probable que se lleve a regresión igualmente (porque seguro es importante a nivel Dev).

  • Un Set que tiene baja prioridad y baja estimación de Automatización, No debería llevarse a Regresión por una cuestión de optimización de actividad y esfuerzo. Es trabajar inteligente.

  • Las features que NO son funcionales, tales como US Visuales nivel UI, o de contenido UX, no suele llevarse a Regresión, ya que no son “modulos” y si existiese un bug, cualquiera vería el error.

• Prioridad: debe ser igual a la de la US (Por una cuestión de super trazabilidad y sobretodo porque nos permite definir si el Set irá a regresión o no)

• Etiquetas: colocamos la funcionalidad de la US y que parte de dicha funcionalidad (esto se va definiendo según el proyecto)

• Sprint: iteración a la que corresponde nuestra US

Para traernos la información desde la US hacemos Ctrol+Clic sobre el link de dicha US y nos la abrirá en otra solapa (para poder trabajar con ambas a la vez: US y TS; simplemente técnicas freakys de trabajar ordenado)

Copiamos los AC de la US y los llevamos y pegamos en el TS al final de la descripción y guardamos los cambios. (También puede ser útil copiar y pegar antes de los AC, y las Bussines Rules Spec)
((todo esto es por organización y trabajo inteligente y más ágil, así no estás viajando de un lado a otro))

Completamos el apartado de Técnicas de Testing colocando si aplican o no las diferentes técnicas, de aplicar alguna agregamos el detalle. Guardamos.

Ej 1:

Ej 2:

((Ojo, si sos nuevo, intenta evadir usar las técnicas, o al menos hasta que hayas terminado el curso de TAG))
((De hecho, solo recomiendo aprender la Tabla de Particiones y Valores Límites; no es determinante aprender todas para conseguir el laburo deseado; Para cuando ya tengas el laburo, ahí sí puedes lanzarte con todo aprendiendo todas si quieres))

Completamos la Estimación VCR que, si bien no es algo que se complete siempre, es muy útil para definir si este Set se automatizará, y ayuda como factor adicional para saber si se elegirá para pruebas de regresión. (Tal cual comentamos previamente)

Los valores por considerar van de 1 a 5 (realmente no hay una regla, es estmativo, hay proyectos que lo hacen de a 2, 5 o 9 inclusive, salvajes):

Si la suma de los tres valores fuera igual o mayor a 9, es un indicador para el Manager de que esta US debería formar parte de la Automatización.

Aprende aplicar el VCR para que ganes experiencia como "pensamiento crítico", una de las mejores soft skills de todo tester.
VCR:
V = Value (Valor) = ¿La Feature tiene dependencias HIJAS? ¿Es un componente madre?
C = Cost (Costo) = ¿La Feature es difícil de desarrollar? ¿Tiene muchos AC?
R = Risk (Riesgo) = ¿La Feature es propensa al uso del usuario? ¿Probabilidad de fallo?

Así uno sabe si una Funcionalidad es importante o no, tomando en cuenta esta técnica.

Según sea el resultado, completamos el campo Test Type del panel derecho y guardamos los cambios.

Completamos el apartado Validaciones según con los casos de prueba/validaciones que hayamos analizado que corresponden para este TS. Siempre teniendo en cuenta que un Criterio de Aceptación puede contener mas de un caso de prueba.

Ej:

Creamos los TC, inicialmente utilizando los títulos de las validaciones anteriores, siempre recordando completar la nomenclatura correspondiente:

Ver toda la Documentación de Nomenclatura en: NOMENCLATURA QA - PRÁCTICA UPEX

Nuevo Test:

Colocamos el Título/Resumen con la correcta nomenclatura (la mejor práctica de un QA):

Linkeamos y nos asignamos:

Completamos todos los TC que sean necesarios.

Nota: luego de esto, si entramos a nuestra US deberíamos poder ver nuestro TS como ‘Incidencia Vinculada’, y nuestros TC como ‘Cobertura de Tests’.

Los TC estarán como NOTRUN – En Estado TO DO (hasta que los ejecutemos)

Editaremos cada TC y completaremos según corresponda (Ver video de Creación de Casos de pruebas)

Generamos el Test Execution para TS:

Nomenclatura:

Seleccionamos el ‘Entorno de Pruebas’ y habilitamos (o no) ‘Ir a la Ejecución…’ según tengamos o no ya finalizados todos los TC. Finalmente hacemos clic en el botón Crear.

Una vez generado el TX podremos verlo en el TS. De no visualizarlo dentro del TS debemos linkearlo para que haya trazabilidad ya que las tareas de diseño deben estar relacionadas a las tareas de ejecución correspondientes.

Seleccionamos ‘relates to’ y nuestro TX (si no aparece podemos buscar por el id de nuestro US gracias a la nomenclatura aplicada) y vinculamos:

Importante: los estados de los diferentes issues se irán modificando a medida se avance en ellos.

Así debería verse nuestro TS una vez linkeado al TX:

Completar el panel derecho de nuestro TX:

Deberemos verificar que se visualice la trazabilidad:

• Desde el TX ver el TS

• Desde el TS ver el TX y la US

• Desde la US veremos el link al TS y a los TC

• Desde los TC podemos ver los links del TX y del TS

para ver la guía (Dibujo gráfico) de toda la trazabilidad de un Testing de US: