Proceso de Testing y UAT de IT&S en VUCE

IT-SIS-04

Process Owner: Desarrollo de Sistemas / Alejandro Gonzalez Calderón

Registro de Cambios

Versión Descripción Autor Area Fecha de

actualización

1.0 Versión inicial Paula Sajoux Dirección IT&S 24/7/2019

Revisión del proceso Alejandro GC y Dirección IT&S 13/8/2019

Emmanuel

Revisión del proceso Marcela Erdozain Gerencia de Calidad 11/11/2019

y Mejora Continua

Aprobación Alejandro Gonzalez Dirección IT&S 4/12/2019

Calderón

1
Contenido
Objetivo ......................................................................................................................................... 3
Alcance .......................................................................................................................................... 3
Definiciones generales .................................................................................................................. 3
Conceptos Básicos ..................................................................................................................... 3
Tipos de Prueba ..................................................................................................................... 3
Testing de Software ...................................................................................................................... 4
Actores / Roles .......................................................................................................................... 5
Product Owner ...................................................................................................................... 5
Analista de QA ....................................................................................................................... 5
Analista de Desarrollo ........................................................................................................... 5
Dueño del Proceso ................................................................................................................ 5
Flujo de Proceso de Testing y UAT ............................................................................................ 6
Flujo de subproceso de UAT...................................................................................................... 7
Descripción detallada de tareas del Proceso de Testing y UAT ................................................ 7
Descripción detallada de tareas del SubProceso de UAT........................................................ 10
Matriz RACI.............................................................................................................................. 12
Anexo I – Diseño de Casos de Prueba ......................................................................................... 14

2
Objetivo
El presente documento tiene como finalidad detallar el proceso de Testing y UAT del software
de la Dirección de Sistemas y Tecnología de VUCE.

Alcance
Aplica para todos los desarrollos de software de la Dirección de Sistemas y Tecnología de VUCE.

Definiciones generales

Conceptos Básicos

Tipos de Prueba

Pruebas funcionales
• Las pruebas Funcionales del Sistema son sobre “lo que el sistema hace”.
• Las funcionalidades deben estar descriptas en las Historias de Usuario y en sus Criterios
de Aceptación (basado en diseños funcionales, especificaciones funcionales, diseño
técnico, especificaciones técnicas).
• Los casos de prueba son lotes de datos que se definen a partir de los Criterios de
Aceptación y de los Casos de Negocio, así como su interoperabilidad entre sistemas.

Pruebas no funcionales de software

• Los requerimientos no funcionales representan “cómo funciona el sistema” (en
contraposición con las funcionalidades que definen “lo que el sistema hace”).
• Su objetivo es probar los requerimientos no funcionales, incluyendo (sin limitarse a)
pruebas de comportamiento con el entorno: Desempeño, Carga, Estrés, Usabilidad,
Mantenibilidad y Portabilidad.
• Cada característica no funcional del software, se mede de diversa manera, por ejemplo,
por medio de tiempos de respuesta en el caso de pruebas de desempeño o por número
máximo de sesiones en pruebas de estrés.

Pruebas estructurales de software

• A este tipo de técnicas alternativas se las conoce también como Técnicas de Caja
Transparente. Se centra en cómo diseñar los casos de prueba atendiendo al
comportamiento interno y la estructura del programa. Se examina así la lógica interna
del programa sin considerar los aspectos de rendimiento.
• Asimismo, es posible aplicar técnicas estáticas de análisis de software.

3
 • Para expresar el alcance con un conjunto de pruebas (“test suite”) que ha cubierto la
estructura o arquitectura en cuestión, se utiliza el concepto de Cobertura (“Coverage”),
normalmente en forma de porcentaje.

Pruebas de regresión y re-pruebas de cambios

• Las Re-Pruebas son aplicadas después que un defecto es identificado y corregido, con
la finalidad de verificar que el defecto ya no se está presentando.
• Las Pruebas de Regresión se realizan sobre un componente ya probado, para verificar
que no presenta nuevos defectos cuando se realiza una modificación después de dichas
pruebas.
• Deben buscarse nuevos defectos tanto en el componente que se está probando cómo
otros componentes afectados por el cambio.
• Se necesita tener claridad de las piezas de software que resultan afectadas por el
cambio.
• Las pruebas deben ser repetibles si han de usarse para pruebas de confirmación y
regresión.
• Incluyen pruebas funcionales, no funcionales y estructurales.
• Dado que las pruebas se ejecutan repetidas veces, las pruebas de regresión son
candidatas a la automatización de pruebas por medio de herramientas.

Testing exploratorio
• Es un estilo o enfoque para la realización de pruebas. Su característica principal es
que el aprendizaje, el diseño y la ejecución de las pruebas se realizan de forma
simultánea.
• Mientras se está probando el software, el tester va aprendiendo a manejar el
sistema y junto con su experiencia y creatividad, genera nuevas pruebas a ejecutar.
A menudo se piensa que el testing exploratorio es como una técnica de prueba de
caja negra. Sin embargo, aquellos que lo han estudiado, lo consideran un enfoque
que se puede aplicar a cualquier técnica de pruebas, en cualquier etapa del proceso
de desarrollo. La clave no es la técnica ni el elemento que estamos probando o
revisando; la clave es el compromiso cognitivo del tester y la responsabilidad del
tester para gestionar su tiempo.

Testing de Software
El proceso de Testing y UAT de Software debe colaborar con la Gestión de Versiones y
Despliegues y asegurar que las versiones implementadas y los servicios resultantes cumplan las
expectativas del cliente.

4
Actores / Roles

Product Owner
Es un rol representado por una o más personas siendo los responsables del éxito del producto
desde el punto de vista de los stakeholders. Determina hacia dónde debe evolucionar el
Producto según las necesidades de la organización. Representa el nexo entre los Stakeholders y
el equipo Sistemas. Representa el negocio dentro de la Dirección de Sistemas y Tecnología de
VUCE.

Analista de QA
Es el responsable de diseñar los casos de prueba en base a los requerimientos funcionales y
técnicos, ejecutar las mismas, identificar todas las fallas del producto, previo a la salida del
software a la etapa de producción.

Debe verificar que se cumplan los criterios de aceptación de los requerimientos.

Analista de Desarrollo
Es el responsable de desarrollar el código y de corregir los errores que surgieran durante las
pruebas.

Dueño del Proceso

- Es el responsable de que se cumpla el proceso, de su diseño, actualización, entrenamiento
del personal.
- Es responsable de garantizar que su proceso se esté realizando de acuerdo con el proceso
acordado, documentado y que se estén cumpliendo los objetivos de la definición del
proceso.
- Responsabilidades:
• Documentar y publicar el proceso.
• Definir las métricas para evaluar la efectividad y eficiencia del proceso.
• Analizar las métricas para ejecutar las acciones correctivas necesarias.
• Responsable del diseño del proceso.
• Mejor la eficiencia y eficacia del proceso y revisar las mejoras propuestas.
• Asegurar el entrenamiento de los que participan en el proceso y que cada uno tenga
conciencia de su rol.
• Asegurar la existencia de revisiones y auditorias regulares del proceso, de sus roles y sus
responsabilidades, y de la documentación correspondiente.

5
Flujo de Proceso de Testing y UAT

6
Flujo de subproceso de UAT

Descripción detallada de tareas del Proceso de Testing y UAT

1. Verifica si es Prueba UAT

Si es prueba de UAT invoca al “Subproceso de UAT”, sino continúa con la actividad “Elabora
diseño de pruebas”.

Pruebas de Testing

Estas pruebas se realizan en el entorno de testing o de desarrollo.

2. Elabora diseño de pruebas

Elabora el diseño de las pruebas con los casos de prueba a ejecutar y documenta los mismos.

3. Verifica si es una Prueba exploratoria

Si se trata de una prueba exploratoria continua con la actividad “Ejecuta pruebas exploratorias”.

Si no es una prueba exploratoria continúa con la actividad “Ejecuta casos de prueba”.

7
4. Ejecuta pruebas exploratorias

El analista de QA ejecuta la serie de pruebas exploratorias. Una vez finalizadas continua con la
actividad “Finalizó el ciclo”.

5. Ejecuta casos de prueba

El analista de QA ejecuta la serie de pruebas.

Una vez finalizadas, si las mismas fueron exitosas continúa con la actividad “Finalizó el ciclo”,
sino continua con la actividad “Reporta Bug y se la asigna al desarrollador”.

6. Reporta Bug y se la asigna al desarrollador

Reporta los bugs u errores en la herramienta correspondiente y se los asigna al desarrollador.

Continúa con la actividad “Analiza y Resuelve Bug”.

7. Analiza y Resuelve Bug

El desarrollador analiza el error reportado y realiza las correcciones que correspondan. Continúa
con la actividad “Verifica solución de Bug”.

8. Verifica solución de Bug

El PO verifica que el error reportado haya sido solucionado.

9. Finalizó el ciclo

Si no finalizó el ciclo y es una Prueba Exploratoria sigue con la actividad “Ejecuta pruebas
exploratorias”.

Si no finalizó el ciclo y no es una Prueba Exploratoria sigue con la actividad “Ejecuta casos de
Prueba”.

Si finalizó el ciclo y es una Prueba exploratoria sigue con la actividad “Elabora informe Pruebas
Exploratorias”.

Si finalizó el ciclo y es no una Prueba exploratoria sigue con la actividad “Elabora informe de
Certificación”.

8
10. Elabora informe Pruebas Exploratorias

Elabora informe de Pruebas Exploratorias indicando en el mismo:

- Alcance de las pruebas

- Resultado de las pruebas:
o Casos de Prueba diseñados
o Casos de Prueba Ejecutados
o Casos de Prueba Exitosos
o Casos de Prueba Fallidos
- Retesting
- Riesgos de la versión
- Conclusión

Luego continúa con la actividad “Envía informe”.

11. Elabora informe de Certificación

Elabora informe de Certificación indicando en el mismo:

- Alcance de las pruebas

- Resultado de las pruebas:
o Casos de Prueba diseñados
o Casos de Prueba Ejecutados
o Casos de Prueba Exitosos
o Casos de Prueba Fallidos
- Retesting
- Riesgos de la versión
- Conclusión

Luego continúa con la actividad “Envía informe”.

12. Envía informe

Envía el informe por correo al Product Owner.

Continúa con la actividad “Aprueba informe”.

9
13. Aprueba informe

Si el PO no aprueba el informe, envía los comentarios y continua con la actividad “Realiza ajustes
en informe”.

14. Envía a los interesados

Una vez aprobado, envía el informe a todos los interesados y lo guarda como evidencia de las
pruebas realizadas.

15. Realiza ajustes en informe

De acuerdo a los comentarios sobre el informe emitido recibidos por el Product Owner realiza
los ajustes necesarios.

Continúa con la actividad “Envía informe”.

Descripción detallada de tareas del SubProceso de UAT

1. Elabora diseño de pruebas

Elabora el diseño de las pruebas con los casos de prueba a ejecutar.

2. Ejecuta casos de prueba

El PO ejecuta la serie de pruebas.

Una vez finalizadas, si las mismas fueron exitosas continúa con la actividad “Finalizó el ciclo”,
sino continua con la actividad “Reporta Bug y asigna al desarrollador”.

3. Reporta Bug y asigna al desarrollador

Reporta los bugs u errores en la herramienta correspondiente y se los asigna al desarrollador.

Continúa con la actividad “Analiza y Resuelve Bug”.

4. Analiza y Resuelve Bug

10
El desarrollador analiza el error reportado y realiza las correcciones que correspondan. Continúa
con la actividad “Verifica solución de Bug”.

5. Verifica solución de Bug

El PO verifica que el error reportado haya sido solucionado.

6. Finalizó el ciclo

Si no finalizó el ciclo sigue con la actividad “Ejecuta casos de Prueba”.

Si finalizó el ciclo sigue con la actividad “Elabora informe de resultados”.

7. Elabora informe de Resultados

Elabora informe de Resultados indicando en el mismo:

- Alcance de las pruebas

- Resultado de las pruebas:
o Casos de Prueba diseñados
o Casos de Prueba Ejecutados
o Casos de Prueba Exitosos
o Casos de Prueba Fallidos
- Retesting
- Riesgos de la versión
- Conclusión

8. Guarda la evidencia de las pruebas realizadas.

Guarda las evidencias de las pruebas realizadas. Envía evidencias al Gestor de Versiones para
que suba las mismas en la herramienta de versionado.

11
Matriz RACI

En esta matriz se asignan los roles que un recurso debe ejecutar, para cada actividad dada.

A continuación, se describe la representación de cada una de las letras asignadas.

R - Responsible (responsable de la ejecución)

Alguien que desempeña una tarea determinada. Para cada tarea en un proceso ITIL existe
normalmente un rol ITIL responsable de su ejecución.

A - Accountable (responsable del proceso en conjunto)

Alguien que asume la responsabilidad conjunta final por la correcta y completa ejecución de un
proceso y que recibe las informaciones de los responsables de la ejecución del proceso.
Normalmente, el Responsable de Proceso asume la responsabilidad conjunta de un proceso y
para cada proceso existe un Responsable de Proceso.

C - Consulted (consultado)

Alguien que no está implicado directamente en la ejecución de un proceso pero que brinda algún
tipo de input para el proceso y/o al cual se pide su consejo y opinión.

I - Informed (a informar)

Alguien que recibe las salidas (outputs) de un proceso o a quien se informa de los avances del
proceso.

12
 ROLES Y RESPONSABILIDADES

PO / Líder de
Desarrollo de
Analista QA

Proyecto
Sistemas
TAREAS Entradas Salidas

Informa ci ón l a entrega de s oftwa re

va l i da da .
Si es UAT conti núa con el "Subproceso
Informa ci ón de l a entrega de
Verifica si es UAT
s oftwa re.
Gestión de UAT" . R
Si no es UAT conti núa con l a a cti vi da d
de "Elabora diseño de Pruebas" en el
entorno de tes ti ng.
Informa ci ón de l a entrega de
Elabora diseño de Pruebas
s oftwa re.
Pl a nti l l a de ca s os de prueba a rea l i za r R I
Si es expl ora tori a conti núa con "Ejecuta
Informa ci ón de l a entrega de prueba s expl ora tori a s ".
Verifica si es exploratoria
s oftwa re. Si no l o es conti núa con "Ejecuta ca s os
R
de Prueba ".
Formul a ri o de Requi s i tos de Pl a n de
Pl a nti l l a de ca s os de prueba
Prueba revi s a do.
Ejecuta pruebas exploratorias
Pl a nti l l a de ca s os de prueba a
expl ora tori a ejecuta da . R I
Bugs o errores en l a ejecuci ón.
rea l i za r
Formul a ri o de Requi s i tos de Pl a n de
Prueba revi s a do. Pl a nti l l a de ca s os de prueba ejecuta da .
Ejecuta casos de Prueba
Pl a nti l l a de ca s os de prueba a Bugs o errores en l a ejecuci ón.
R I
rea l i za r
Pl a nti l l a de ca s os de prueba
Bugs o errores de l a ejecuci ón
Reporta Bug y asigna al desarrollador ejecuta da .
reporta dos .
R I
Bugs o errores en l a ejecuci ón.
Bugs o errores de l a ejecuci ón
Analiza y Resuelve Bug reporta dos .
Bugs o errores corregi dos . I R
Verifica solución de Bug Bugs o errores corregi dos . Correcci ón de bugs veri fi ca da . R I
Pl a nti l l a de ca s os de prueba
Elabora informe de Certificación ejecuta da . Informe de Certi fi ca ci ón. R
Bugs o errores en l a ejecuci ón.
Pl a nti l l a de ca s os de prueba
expl ora tori a ejecuta da . Informe Prueba s Expl ora tori a s R
Elabora informe Pruebas Exploratorias Bugs o errores en l a ejecuci ón.
Informe de Certi fi ca ci ón.
Envía informe Informe de Prueba s expl ora tori a s .
Informes envi a dos R I
Informe de Certi fi ca ci ón/Expl ora tori o
a proba do.
Informe de Certi fi ca ci ón.
Aprueba informe
Informe de Prueba s expl ora tori a s .
Informe de Certi fi ca ci ón/Expl ora tori o R
des a proba do.
Ajus tes a rea l i za r.
Informe de Certi fi ca ci ón/Expl ora tori o
Informe de Certi fi ca ci ón/Expl ora tori o
Realiza ajustes en informe des a proba do.
con a jus tes
R I I
Ajus tes a rea l i za r.
Informe de Certi fi ca ci ón/Expl ora tori o Informe de Certi fi ca ci ón/Expl ora tori o
Envía a interesados
a proba do. a proba do envi a do.
R

13
Anexo I – Diseño de Casos de Prueba

Template de Casos de Pruebas de Software

Área Funcional / Sub Funcionalidad / Dependencias con otros
Id Caso de Prueba Descripción Fecha Precondiciones Pasos Descripción del Paso Datos / Acciones de Entrada Resultado Esperado Resultado Obtenido Resultado de Prueba Estado Última Fecha de Estado Observaciones
proceso Característica casos de Prueba

14