Identificación del documento

DATOS GENERALES
Versión del Documento: 0.1
Nombre del Documento: Manual TFS.doc
INDICE

Identificación del documento...........................................................................................................................2

1. Historial de Cambios...................................................................................................................................4
2. Generar plan de pruebas para un proyecto..........................................................................................5
3. Crear ciclos de prueba................................................................................................................................8
4. Diseño de casos de prueba......................................................................................................................10
5. Ejecución de pruebas................................................................................................................................13
6. Registro de defectos.................................................................................................................................19
7. Gráficos.........................................................................................................................................................22

2
 1. Historial de Cambios

Versión Fecha Descripción Autor

V1.0 30/05/2018 Generación manual TFS Alejandro Medrano

3
 2. Generar plan de pruebas para un proyecto
URL: http://10.26.10.5:8080/tfs
Se mostrara pantalla “Inicio de sesión”
A. Ingresar Usuario y contraseña

B. Después de ingresar usuario y contraseña se realizará la búsqueda del proyecto en el que

trabajaremos.
C. En la pantalla principal seleccionamos opción “Examinar”.

Se mostrará la pantalla “Examinar el servidor”.

D. Seleccionar “QACollection” y seleccionar el proyecto en el que trabajaran. Se mostrarán

los proyectos a los que se tienen permiso.

4
E. Seleccionar “Navegar”

5
F. Crear plan de pruebas (Proyecto).
G. Seleccionar menú “PRUEBA”.

6
H. Seleccionar Sub Menú “Plan de pruebas”

I. Dar clic en el símbolo “+” y seleccionar “Plan de pruebas”

7
 J. Ingresar el nombre.
K. Seleccionar “Ruta de acceso del área”.
L. Seleccionar “Iteración” y dar clic en el botón Crear.

El líder de pruebas es el encargado de crear el plan de pruebas (Crear Proyecto).

8
 3. Crear ciclos de prueba

En plan de pruebas;
A. Desplegar el menú y seleccionar “Nuevo conjunto estático (Nuevo ciclo de pruebas)”.

B. Ingresar el nombre del conjunto y dar enter.

9
C. Continuar con el proceso anterior hasta haber creado los ciclos necesarios.

10
 4. Diseño de casos de prueba

En la pantalla de pruebas;
A. Seleccionar del conjunto de pruebas el menú “Pruebas”.
B. Se mostrará un submenú, seleccionar opción “Nuevo caso de prueba”.

11
Definición de campos para el diseño de casos de prueba.

En la columna de campo de Status se muestran los campos:

Asisigned To: Persona a la cual será asignado el caso de prueba. Puede ser el tester o el líder
de pruebas.

 State: Estado en el que se encuentra el caso de prueba, los cuales pueden ser:
o Desing: Esta en diseño por el tester y debe de estar asignado al líder
o Ready: Esta validado por el líder y asignado al tester
o Closed: Se cancela por el líder y la prueba no aplicaría
 Priority: El nivel de prioridad que representa el caso de prueba.
o 1 = Alta
o 2 = Media
o 3 = Baja
 Automation status: Estado en el que se encuentra la automatización. Este campo no se
modifica para pruebas funcionales. Los estatus pueden ser:
o Not Automated: No esta automatizado.
o Planned: Se encuentra planeado automatizar.

En la columna Classification se muestran los campos:

 Area: Proyecto en el que se desea generar el caso de prueba.
 Iteration: Ciclo de prueba en el que se desea agregar el caso de prueba.
 Matriz: Matriz de prueba al que se agregara el caso de prueba.
En la sección inferior se encuentran:
 Steps: Ingresar acción, resultado esperado y Datos adjuntos.
 Summary:
o Descripción: Redacción corta del caso de prueba.
o History: Historial de comentario del caso.

 Tested Requirements: Casos de prueba que se requieren ejecutar antes del caso de
prueba que se está realizando.
 All links: Listado de bugs relacionados con el caso de prueba.
 Attachments: Documentos adjuntos.
 Associated automation: Caso automatizado con el que se encuentra asociado el caso
de prueba.

12
C. Los campos por llenar son:
 Description (Descripción del caso de prueba)
 Assigned To (A quien estará asignado el caso de prueba)
 State (Estatus del caso de prueba)
 Priority (Prioridad del caso de prueba)
 Matriz (Matriz a la que estará asignado el caso de prueba)
 En “Steps”:
o Acción (Descripción del paso)
o Resultado esperado (Resultado esperado del caso de prueba)
o Datos adjuntos (Permite adjuntar documentos o imágenes)

13
D. Seleccionar botón “Guardar (Guarda los cambios)” o botón “Guardar y cerrar (Guarda el
caso de prueba actual y cierra la ventana)”

Criterios para seleccionar la prioridad de los casos de prueba

14
  1 Muy alto más de 30 pasos y más de 15 validaciones.
 2 Alta desde 20 a 30 pasos y entre 11 y 15 validaciones.
 3 Medio de 11 a 20 pasos y entre 6 y 10 validaciones.
 4 Baja menos de 10 pasos y menos de 5 validaciones.

5. Ejecución de pruebas

A. Seleccionar opción “Ejecutar” y “Ejecutar prueba”.

B. Se puede ejecutar dando click derecho del mouse sobre la prueba.

15
C. Se mostrará del lado izquierdo de la pantalla, ventana para ejecutar la prueba.

D. Seleccionar pasado o fallado en cada paso de la prueba según aplique.

16
 E. Seleccionar “Estatus de la prueba”.

Otra forma de ejecutar casos de prueba es dar clic sobre el ciclo de pruebas.

17
De esta forma al ejecutar un caso de prueba se podra continuar ejecutando casos de prueba
seleccionando “Siguiente” sin cerrar la ventana.

18
No se pueden ejecutar pruebas desde el siguiente menú.

19
F. En todos los casos de prueba sin importar si están pasados o fallados se debe adjuntar la
evidencia.

G. Se selecciona el archivo que se adjuntara.

20
6. Registro de defectos

A. En la pantalla donde se realiza la ejecución del caso de prueba se encuentra la opción de “Crear bug”.

B. Se mostrara la pantalla “Nuevo Bug” donde ingresaremos el titulo del defecto, seleccionar la matriz.

21
C. En el sub menú “Comentarios QA”, seleccionar el ambiente donde se encontro el defecto e ingresar
“Ccomentarios de QA”.

D. Se agregara evidencia, seleccionando “Datos adjuntos”.

22
 E. Se selecciona archivo con evidencia del defecto.

Estatus de defectos:
 Proposed: Nuevo, lo tiene el líder de desarrollo y está en espera de ser asignado al desarrollador que lo
atenderá
 Active: Asignado al desarrollador que lo atenderá.
 Reincidencia: Defecto cerrado o en validación (Completed) que presento de nuevo el error.
 Removed: No aplica

23
  Closed: Cerrado Sera posible reabrir el defecto
 Completed: Se validó la corrección por parte de QA
 Resolved: Resulto por parte de desarrollo y lo toma QA

Definición de campos BUG:

 Title: Nombre del bug
Campos de la columna “Status”:
 Assigned To: Persona a la que se le asignará el bug.
 Reason: La justificación del cambio de estatus.
Campos de la columna “Planning”:
 Priority: Prioridad que se asigna al defecto
 Severity: Severidad que le asignara al defecto
 Triage: Indica el desarrollador que requiere para su corrección.

 Blocked: Se indica si el defecto es o no bloquente

Campos de la columna “Classification”:
 Area: Proyecto en el que se desea generar el caso de prueba.
 Iteration: Ciclo de prueba en el que se desea agregar el caso de prueba.
 Root cause: Causa principal por la que se presentó el bug.
 Matriz: Matriz de prueba al que se agregara el defecto.
 No. Incidencia: Número asignado a la incidencia.
 No. Ticket: N/A

A continuación se listan los tipos de severidad:

 Bloqueante (Critical): Problema de seguridad o que afecta a un requisito

primordial para el cual no es posible continuar, además impacta más casos de

24
 prueba (determinar número de casos). Impide el uso o la prueba del sistema y debe
ser solucionado al momento. Ejemplo: Un error crítico ha sido encontrado y no
permite que se continúe con la operación de UNO Integral “Server Error”.

Alto (High): Un defecto que afecta a un requisito primordial para el cual no es

posible continuar el proceso de la función seleccionada solo afecta algún módulo
particular.
Ejemplo: El componente clave no está disponible o la funcionalidad está incorrecta en el
sistema UNO Integral.

 Medio (Medium): Un defecto que afecta un requisito no-primordial es decir, las

funciones son restringidas, pero el procesamiento puede continuar.
Ejemplo: Componentes no críticos no están disponibles o la funcionalidad es incorrecta;
cálculos incorrectos en funcionalidad clave.

 Bajo (Low): Un defecto que afecta un requisito no-primordial para el cual se

requiere un cambio de forma menor. Ejemplo: Errores de usabilidad, pantallas, GUI,
reportes de errores que no afectan la calidad, cambio en una etiqueta, un mensaje,
etc.

7. Consulta de defectos

 Seleccionar menú “TRABAJO”

 Seleccionar “Consultas”
 Seleccionar “Editor”

25
 Seleccionar “Agregar nueva cláusula”
 Y/O “And”
 Campo “Work Item Type”
 Operador “=”
 Valor “Bug”
La primera Cláusula es para indicar queremos buscar un bug.

26
 La segunda es para indicar en que matriz realizaremos la busqueda
 En la nueva cláusula seleccionar:
 Y/O “And”
 Campo “Found In”
 Operador “=”
 Valor “La matriz en la que se está trabajan
 Para ejecutar la consulta se selecciona “Ejecutar consulta”

Como resultado se obtendran los bug dados de alta en la matriz que seleccionamos “MP- Prueba- Lisyx”

27
8. Gráficos

28