Definición de caso de prueba
El caso de prueba (CP) es una especificación formal y fácilmente identificable, en la cual se detalla los pasos a seguir para poder verificar un comportamiento esperado. Se compone de una entrada de datos, condiciones de ejecución y resultados esperados claramente definidos, que tienen como propósito hacer una evaluación sobre un objeto de prueba.
Beneficios de escribir un buen caso de prueba
Escribir un buen caso de prueba tiene como propósito, que toda persona que lo utilice pueda realizar su trabajo, sin tener que iniciar un exhaustivo trabajo de investigación para deducir que es lo que se hizo en primera instancia y si esto es útil para el proyecto actual.
Lista de beneficios:
- Se registra el comportamiento de la aplicación.
- Se conoce el límite y o alcance del caso de prueba.
- Se puede re utilizar el caso de prueba.
- Se puede determinar el momento exacto en el que se produce un error.
- Se puede utilizar el caso de prueba como una unidad medible.
Todos estos beneficios se logran al determinar que prueba se debe realizar, incluyendo el punto de origen y fin de la misma. Para ello se deben especificar las precondiciones, las acciones a realizar y por sobre todo, el resultado esperado, que es la razón por la cual existe en primer lugar el caso de prueba.
Partiendo de las Referencias Funcionales (RF) o de los Casos de Uso (CU) que surgen del Análisis funcional, se pueden identificar 4 fases:
Los escenarios se pueden Identificar tomando como base los documentos de Análisis Funcional (AF) que se realiza en función de lo que el usuario requiere. En el documento se detalla lo mínimo que el desarrollo debe cubrir.
Ejemplo en Movics:
RF1. Ingreso de Subagente en operaciones. de Postventa
Descripción |
Al ingresar a cualquiera de las siguientes operaciones: SC26 Migración a Crédito SC52 Migración Cuentas Mixtas SC25 Migración a Phone Card SC12 Cambio de Plan SC20 Alta y Baja de Servicios SC10 Cambio de Equipo (voluntario, por robo, etc) SC37 Migración a GSM SC13 Robo Equipos / Negative Se deberá pedir el código de vendedor y si se trata de un vendedor de indirectas (TAB106_TIPO_VENDEDOR = A) pedir el código de Subagente. El código de vendedor se valida contra la tabla 106 y el código de subagente se debe validar contra la tabla 598. |
En este RF podemos identificar al menos 8 escenarios de prueba, uno por cada operación.
Ejemplo en SGU:
Descripción |
El sistema informará mediante una alarma aquellos números que han sido enviados a Ingeniería, si han pasado n días (parametrizable) con el grado de apertura necesario en cuanto a ALM, SUB-ALM, Tecnología, Modalidad, y DDN. Argentina: n = 7 para numeración cuyos hitos pendientes dependan de una operadora móvil n=15 para numeración cuyos hitos pendientes dependan de una operadora fija Chile: n=5 numeración de otras operadoras n=3 numeración propia |
Característica del requerimiento: | Crítico | Importante | X | Negociable | ||||
Tipo de requerimiento | Funcional | X | No Funcional | |||||
Origen de requerimiento | Chile | X | Argentina | X | ||||
En este AF podemos identificar al menos 4 escenarios, dos para Argentina y 2 para chile.
Al hablar de escenario no nos referimos a la cantidad de pruebas a realizar en el mismo, sino de dividir el trabajo para poder organizar mejor la prueba y así cubrir todo el requerimiento.
El escenario puede tener un flujo normal y flujos alternativos o combinación del los anteriores.
Un método para identificar los casos de prueba es graficar la secuencia de eventos, esto permite, abstraer los eventos que ocurren e identificar el flujo normal o básico y los flujos alternos, y sirve de apoyo para visualizar fácilmente las posibles combinaciones que posteriormente terminarán siendo CP.
Ejemplo: supongamos que se modifica la operación OC01.1 Alta Codificada por pantalla y hay que probar que la misma funciona con el agregado que se le haya realizado. El diagrama de flujo completo para la operación sería:
En la pantalla de Datos del cliente se agregó un nuevo campo.
La OC01 se prueba completamente con la siguiente lista de casos.
Camino Rojo | Camino Azul |
01.01.-F_OC01- Botón Cancelar[1] | 02.01.-F_OC01- Botón Confirmar |
Camino Verde | Nuevos CP |
03.01.-UF_OC01- Alta Codificada x pantalla - OK [2] | 04.01.-F_OC01- Nuevo campo – Formato 04.02.-F_OC01- Nuevo campo – datos origen. 04.03.-F_OC01- Nuevo campo – ubicación en pantalla |
[1] Ver Anexo I - 6.1.1 F_OC01- Botón Cancelar
[2] Ver Anexo I - 6.1.2 UF_OC01- Alta Codificada x pantalla – OK
Identificar el alcance de los casos de prueba.
¿Cómo determinar el límite y alcance de caso de prueba?, como personas pensantes podemos tomar distintos caminos para poder resolver esta pregunta a la hora de diseñar una prueba.
Analicemos un ejemplo:
La prueba consiste en dar de alta un numero en movics y que el estado Activo del número llegue a SGU-Adn como estado Ocupado. Los sistemas involucrados son Movics – SDT – ADN. Y si el número no existe en ADN, en el SDT no se tiene que encolar la transacción.
Este es el diagrama
Podemos decir a primera vista que tenemos 2 pruebas: una en Movics y otra en el SDT
CP1: Generar un alta y que el nuevo estado del número se registre en ADN à Carpeta Movics.
CP2: Que el SDT descarte la transacción cuando el número no existe en ADN à Carpeta SDT.
O bien, podríamos plantearnos la siguiente pregunta: con 3 sistemas distintos, ¿dónde se deben escribir las pruebas?
Miremos el árbol de carpetas:
¿Cuáles son las acciones a realizar y donde ocurren?
Lista de Acciones:
1.- El usuario da de alta un cliente desde movics
2.- Movics informa a SDT que se produjo un alta (lo hace por medio de un movitag)
3.- El SDT recibe la novedad e invoca el servicio “ocuparNumero” de ADN
Si el número existe en ADN
4.- El servicio impacta en ADN, el cambio de estado de Disponibles a Ocupado.
Sino
5.- ADN informa a SDT que no existe el número.
6.- El SDT descarta la novedad.
Donde ocurren las acciones
a.-Los puntos 1 y 2 del lado de Movics.
b.-Los puntos 3 y 6 se producen en el SDT
c.-Los puntos 4 y 5 en ADN
Entonces podemos decir, en rasgos generales, que
CP1: Alta Inicial + generación de Movitag à podría representar los puntos 1 y 2
CP2: ADN impacta la novedad à podría representar los puntos 4
CP3: El SDT descarta novedad à podría representar los puntos 3 y 6
Entonces la posible ubicación de las pruebas sería:
Ubicación | Caso de Prueba | Lista de Precondiciones |
Movics/Operaciones/OC01 | CP1: Alta Inicial + Movitag | 1.-Realizar OC17.4 |
SGU/ADN | CP2: ADN impacta la novedad | 1.-El número debe existir en ADN 2.-Realizar OC17.4 3.-Realizar OC01.1 |
Satélites/SDT | CP3: El SDT descarta novedad | 1.-El número no debe existir en ADN 2.-Realizar OC17.4 3.-Realizar OC01.1 |
Podemos decir que al dividir las pruebas tenemos mas posibilidades de ubicar en que momento ocurre un error y al mismo tiempo podemos identificar al sistema, que le corresponde el defecto y por consiguiente al desarrollador que le va a asignar el mismo.
Este tipo de pruebas por lo general tiene un desarrollador diferente por cada sistema, por lo cual es importante determinar a quien debemos consultar si encontramos un problema.
Especificar los Casos de Prueba.
Como se menciono anteriormente el caso de prueba se compone de una entrada de datos, ejecución de condiciones y un resultado esperado. En esta fase se detallan cada una de las partes.
Todo CP tiene que ser fácilmente identificable. Para ellos se propone la siguiente nomenclatura:
ESCENARIO_ORDEN.-CLASE_UBICACION - Titulo
Donde:
ESCENARIO_ORDEN: Es un agrupador que permite visualizar un conjunto de pruebas que están relacionadas, pueden ser escenarios propiamente dichos o componentes a los que se asocian un conjunto de pruebas, veamos algunos ejemplos:
1.- Ejemplo sobre un Escenario
Uno de los escenarios de la operación SC52: Cambio de Plan con Agente Indirecto Habilitado.
Los casos de prueba que prueban el escenario planteado serían:
01_01.- UR_SC52 - Cambio Plan ACT-ACT Agente Habilitado
01_02.- UR_SC52 - Cambio Plan AHO-AHO Agente Habilitado
01_03.- UR_SC52 - Cambio Plan ACT-ACT Agente NO Habilitado
01_04.- UR_SC52 - Cambio Plan AHO-AHO Agente NO Habilitado
Para el mismo escenario, en este caso 01, existen 4 pruebas. Esta forma de numerar las pruebas permite tenerlas agrupadas.
Una opción que permitiría intercalar nuevas pruebas que puedan surgir sería que el ORDEN se incremente de 10 en 10, así ante la necesidad de agregar una prueba secuencial podríamos utilizar un número intermedio. Ejemplo:
01_10.- UR_SC52 - Cambio Plan ACT-ACT Agente Habilitado
01_15.- UR_SC52 - Cambio Plan ACT-ACT Agente Habilitado con plan habilitado
01_20.- UR_SC52 - Cambio Plan AHO-AHO Agente Habilitado
2.- Ejemplo sobre un componente de pantalla
01_01.- F_CONNUM – Fecha Desde menor igual que Fecha hasta
01_02.- F_CONNUM – Fecha Desde formato día
01_03.- F_CONNUM – Fecha Desde formato mes
01_04.- F_CONNUM – Fecha Desde formato año
01_05.- F_CONNUM – Fecha Desde formato fecha
02_01.- F_CONNUM – Fecha Hasta formato día
02_02.- F_CONNUM – Fecha Hasta formato mes
02_03.- F_CONNUM – Fecha Hasta formato año
02_04.- F_CONNUM – Fecha Hasta formato fecha
Se agrupan todas las pruebas relacionadas a ese componente bajo el número 01 para fecha desde y 02 para fecha hasta.
3.- Ejemplo sobre alguna regla de negocio
15.01.- UR_REGTRN_Cualquier SC- Porcentaje OK - A reprocesar[1]
15.02.- UR_REGTRN_Cualquier SC- Porcentaje Error – Descartar[2]
CLASE de prueba a la que hace referencia el tipo de prueba
Letra | Descripción | Definición | Ejemplo |
U | Usuario | Pruebas para la certificación con el usuario. Esta letra nos permite identificar a simple vista que prueba va a ir al UAT | |
R | Reglas de Negocio | Es todo aquel caso de prueba que verifica que la aplicación realice lo solicitado en el análisis funcional. Es el comportamiento lógico que debe tener la aplicación en función de determinados criterios. | No permitir borrar un rango de números que se encuentren en uso. No permitir cargar un precio a un ByS que sea de tipo folleto. |
F | Funcionalidad | Es el comportamiento que debe tener la aplicación frente a las acciones de los usuarios. | Probar las secuencias del tab. Que no salte ningún error. La correcta funcionalidad de cada componente. Verificar tipo de dato longitud de un campo. Que valores por defecto debe tener un campo, etc. |
P | Proceso | Todos los casos que tengan que ver con ejecutar un proceso. | Verificar que después de correr un proceso se carguen determinadas tablas, que se envíen mails de alarma, que se generen archivos y se envíen a otros servidores mediante sftp, etc |
Se puede combinar hasta 2 letras, siempre U con alguna mas.
Esta clasificación nos permite identificar a simple vista que prueba es para el usuario y de que tipo de prueba se trata
UBICACIÓN es una abreviación del nombre de la carpeta que contiene las pruebas y no debe superar los 6 caracteres.
[1] Si el porcentaje que paso las reglas de selección de SC no pasa las reglas de transformación entonces se tienen que re procesar los números.
[2] Si más de X porcentaje de números no pasan las reglas de selección de SC entonces se descarta todo el rango
Ejemplo:
Carpeta donde se encuentra el CP | Ubicación |
 | AC21 |
 | MOVCAR |
 | MODSEG |
 | CAJAGE |
 | CFECFA |
Detalle del Caso de Prueba
Todo caso de prueba debe tener una descripción, en donde se describe en forma específica y breve, que es lo que se quiere probar con ese caso de prueba, se sugiere el siguiente formato:
Propósito / Objetivo:
Este caso de prueba es para [validar / verificar/ comprobar/ generar/ consultar] que ”suceda algo” cuando suceda determinada “condición”
Puede darse el caso de tener que agregar algún concepto que aporte claridad a la prueba, el mismo debe ser breve y conciso.
[Información Adicional]
Ejemplo:
Definición de Números Reservados: Todo abonado de la tabla ga_reservas con fec_hasta =null y que el abonado exista en la tabla ga_reutilnum con ind_reutil = 0.
En caso de existir un proceso o imagen que se requiera ejecutar, se debe detallar solo para el proceso que genera la acción a probar, los siguientes campos.
[Nombre de Proceso]
[Parámetros]
[Entrada]
[Salida]
[Ubicación]
Ejemplo:
Proceso a Ejecutar: adncargaini.sh
Datos de Entrada: GA_ADN_RANGOS
Datos de Salida: ADN_RTA_SIS_ID_YYMMDD.TXT
Ubicación del proceso: /appl/prod/siscel/abonados/scripts
Ubicación del archivo de salida: /appl/prod/siscel/spool/abonados/ADN/entregas
Se debe recordar que el propósito de la descripción es que toda aquella persona que lee la misma, la pueda entender sin tener la necesidad de consultar a la persona que la escribió. También sirve para no tener que estar leyendo todos los pasos del CP para saber de que se trata la prueba.
Esto SI se debe hacer | Esto NO se debe hacer |
R El CP debe tener descripción | Q No debe existir dos descripciones iguales o se estaría duplicando un CP |
R La descripción debe ser breve. | Q En la descripción no se debe contar el requerimiento |
R La descripción es específica al CP. | Q La descripción no debe ser general. |
R Todo proceso previo a la ejecución del proceso que vamos a probar, se debe listar como precondición | Q No utilizar siglas, al menos que se ponga la definición entre paréntesis la primera vez que se utiliza |
Analizamos algunas descripciones de caso de prueba existentes
Ejemplos actuales | Cómo se podrían mejorar … |
Pantalla nueva para generación y cierre masivo de tickets | |
Verificar la carga de los campos definidos como obligatorios | Este caso de prueba es para verificar que los siguientes campos: Identificador de vendedor, Número de identificador y Número de Línea son obligatorios |
Generar una operación FC06 Re-Facturación de Anexos | Este caso de prueba es para verificar que al generar una operación FC06 Re-Facturación de Anexos se genere la factura en la cuenta corriente del cliente. |
Se realiza la consulta desde Movics de cualquier pieza de un cliente que se encuentre cargado en SGU | Este caso de prueba es para consultar que, desde la pantalla de movics, se puedan visualizar los datos de una pieza que se cargó previamente en SGU |
Vuelva a la opción y aplique un filtro por activo | Este caso de prueba es para verificar que al seleccionar en el campo XXX el valor activo, se puedan visualizar todos los registros que cumplen con la condición. |
Ejecutar la operación N70 con un único archivo | Este caso de prueba es para verificar que, al ejecutar la operación N70 con un único archivo, se visualice en el archivo invtr_numtcp_sn_ursnt_*.lis la líneas con estado Numero de móvil inexistente |
Incorporar la funcionalidad para que en un hallazgo se puedan ingresar tanto acciones inmediatas como correctivas. | Desc CP1: Este caso de prueba es para verificar que se puede realizar el alta de un hallazgo con acciones inmediatas. Desc CP2: Este caso de prueba es para verificar que se puede realizar el alta de un hallazgo con acciones correctivas. Desc CP3: Este caso de prueba es para verificar que se puede realizar el alta de un hallazgo sin definir acción. |
En la precondición se deben especificar las condiciones necesarias para ejecutar el caso de prueba.
Deben escribirse en orden de ejecución.
La precondición debe responder a la pregunta: ¿Qué se necesita tener para poder realizar la prueba?
El formato es el siguiente:
Número de orden .- Verbo en Infinitivo + cláusula
1.- [Configurar / Utilizar / Ingresar / Iniciar / Realizar / Ejecutar / Generar] + …
Ejemplos:
1.- Configurar [Tabla / Parámetro/ Variable / Atributo, etc] con el valor…
2.- Utilizar [cte / cta / nro / forma pago / forma cont/ etc] con las siguientes características:
3.- Ingresar a la pantalla …
4.- Ingresar en el campo el valor
5.- Seleccionar elemento de la lista / checkbox / botón / etc
6.- Iniciar sesión en …
7.- Realizar operación …
8.- Ejecutar proceso …
9.- Generar una archivo con las siguientes características….
Esto SI se debe hacer | Esto NO se debe hacer |
R Deben escribirse en orden de ejecución. | Q No se debe mencionar nombre de usuarios o password. |
R Deben ser acciones previas, necesarias para realizar la prueba. | Q No se deben incluir pruebas |
R Deben ser claras y específicas. | Q No se debe incluir código. |
En cada paso se debe describir lo que se tiene que hacer para poder realizar la prueba.
Describir una acción que marque un único resultado o una lista de resultado esperado que identifique unívocamente la acción descripta
Todos los pasos deben iniciar con un verbo en infinitivo: Ir, Verificar, Comprobar, Visualizar, etc
Ejemplos:
Descripción del Paso | Resultado esperado [1] |
Verificar que si el Código pertenece a un plan de servicio y Tipo de código = B (Bien), solo se pueda seleccionar A: Accesorio, F: Folleto , J: Ajuste de Bien | Que para un plan de servicio solo se puedan seleccionar los siguientes tipos de bien= A: Accesorio, F: Folleto, J: Ajuste de Bien |
Verificar que en el campo Tipo de equipo, se visualicen los valores de la tabla 134 Tipos de Equipos de Movics | 1.-Que se visualice todos los registros de la tabla 134 Tipos de Equipos 2.- Que la carga del campo sea obligatoria |
Verificar que si se selecciona Tipo de Bien = F, entonces se habilite el campo PP (Punto de pedido) con un máximo de 6 dígitos y con valor por defecto de 0000000 | 1.- Que se habilite el campo 2.- Que solo permita dígitos 3.- Que la máxima longitud sea 7 4.- Que el valor por defecto sea 0000000 |
Nota: para los casos en que en el resultado esperado existe en forma de lista, se debe cumplir todos los puntos para poder dar por ok el paso. Por un punto que no se cumpla, se debe generar un defecto y aclarar en el mismo cual no paso la prueba
Clasificación de los diferentes tipos de pasos
Paso que marca un destino
Descripción del Paso | Resultado esperado |
Ir al menú … Seleccionar el estado … Ingresar el cliente … Presionar el botón …. |
En este paso se listan acciones a realizar, no busca probar nada sólo marca una guía.
No requiere que se escriba un resultado esperado a menos que la acción que se dispara sea la que demuestra la prueba.
Paso que marca una validación
Descripción del Paso | Resultado esperado |
Verificar / Comprobar / Constatar (que bajo una condición suceda algo) | Que “algo suceda” |
El resultado esperado es obligatorio.
Paso que marca una ejecución
Descripción del Paso | Resultado esperado |
Ejecutar el proceso …. o Presionar el botón … o Generar …. | Que “algo suceda” |
El resultado esperado es obligatorio.
Esto SI se debe hacer | Esto NO se debe hacer |
R La descripción del Paso es obligatoria. | Q Descripción que no marca una acción |
R La descripción debe ser específica. | Q En la descripción no se debe contar el requerimiento |
R La descripción siempre tiene que mostrar una dirección de acción. | Q No debe permitir más de un camino de acción. |
R Todo proceso previo a la ejecución del proceso, al cual se refiere la prueba, se debe listar como condición previa. | Q No utilizar siglas, al menos que se ponga la definición entre paréntesis la primera vez que se utiliza |
R Tiene que ser de fácil comprensión. | Q La descripción no debe ser general |
Descripciones Actuales | Cómo se podrían mejorar … |
Si el agente no esta registrado en la configuración de agente habilitado para “Altas Manuales” en movics el sistema comercial destino será siscel | Paso para CP1: Verificar que si el agente esta habilitado para generar Altas Manuales la operación se debe generar en Movics. ó Paso para CP2: Verificar que si el agente NO esta habilitado para generar Altas Manuales la operación se debe generar en Siscel. |
a) Si confirmo: b) Si cancelo: c) Si continuo: | Si por cada acción existe un resultado esperado diferente, entonces estamos hablando de 3 casos de prueba y no de 3 pasos distintos. Paso para CP1: Ingresar Vendedor, presionar F10 y Confirmar Paso para CP2: Ingresar Vendedor, presionar F10 y Cancelar Paso para CP3: Ingresar Vendedor, presionar F10 y Continuar |
Realizar desde portal de movistar on line un alta manual con servicio “Activa” Nota1: debemos verificar que el campo “solicitud” no contenga una letra al final de número cuando pasamos a la siguiente pantalla, en el caso de ser así el sistema en el cual estará impactando será siscel. Nota2: para poder hacer el alta debemos pasar por el control de crédito | La Nota 2 es una precondición, por lo tanto tiene que ir en la solapa de precondición 1.-Realizar el control de crédito La nota 1 muestra que existen dos pruebas a realizar con dos resultados distintos, por lo tanto son 2 CP diferentes: Paso para CP1: Realizar un alta manual, desde el portal de movistar, ingresando en el campo solicitud un valor que no contenga una letra en el último carácter. Paso para CP2: Realizar un alta manual, desde el portal de movistar, ingresando en el campo solicitud un valor que contenga una letra en el último carácter. |
Cada paso tiene un resultado esperado.
En este campo no se deben utilizar los siguientes verbos en infinito: Configurar / Utilizar / Ingresar / Iniciar / Realizar / Ejecutar / Generar / Verificar, ya que los mismos implican una acción y lo que se necesita escribir es una RESPUESTA, que se genera en función de una acción.
El formato para la respuesta esperada será el siguiente:
Que se + suceda algo
Que algo sea …
Ejemplos:
Que se visualice por pantalla…
Que se genere el archivo…
Que el valor por defecto del campo sea…
Que la máxima longitud del campo sea…
Que el campo solo permita el ingreso de dígitos
Que se emita el siguiente mensaje de error: “xxx”
Que se muestre por pantalla un mensaje informando que el dato es requerido
Que el proceso se ejecute
Que el estado de la operación sea…
La respuesta puede ser única, es decir solo se requiere que un evento suceda.
Ejemplo:
Descripción | Resultado Esperado |
Ingresar una localidad inexistente | Que se emita el siguiente mensaje de error: “La localidad es inexistente” |
O puede tener una lista de eventos que están relacionados intrínsecamente con la acción solicitada, y solo con una acción.
Ejemplo:
Descripción | Resultado Esperado |
Verificar que en el campo Tipo de equipo, solo se puedan ingresar los valores de la tabla 134-Tipos de Equipos de Movics | 1.-Que solo se permita el ingreso de los códigos de la tabla 134-Tipos de Equipos 2.- Que la carga del campo sea obligatoria |
La respuesta puede ser única, es decir solo se requiere que un evento suceda.
Ejemplo:
Descripción | Resultado Esperado |
Ingresar una localidad inexistente | Que se emita el siguiente mensaje de error: “La localidad es inexistente” |
O puede tener una lista de eventos que están relacionados intrínsecamente con la acción solicitada, y solo con una acción.
Ejemplo:
Descripción | Resultado Esperado |
Verificar que en el campo Tipo de equipo, solo se puedan ingresar los valores de la tabla 134-Tipos de Equipos de Movics | 1.-Que solo se permita el ingreso de los códigos de la tabla 134-Tipos de Equipos 2.- Que la carga del campo sea obligatoria |
Esto SI se debe hacer | Esto NO se debe hacer |
R Debe existir un resultado esperado | Q No se debe marcar una acción |
R Se debe escribir que una respuesta | Q No se debe utilizar verbos en infinitivo |
R Si es una lista de eventos, tiene que estar numerada | Q |
R Siempre debe empezar con la preposición QUE | Q |
· Cuando se quiere hacer una prueba de integración. Se puede escribir un CP que solo llame a la ejecución de otros CPs.
Ejemplo: Se quiere probar que cuando se da de alta un número en movics, se informe del alta a SGU-ADN.
Se tiene 3 casos de prueba:
CP1: Alta en Movics
CP2: SDT recibe la notificación de Movics por el alta y comunica a SGU.
CP3: SGU-ADN registra el alta en la base de datos
Podríamos crear un CP que llame a los anteriores, utilizando un call, y de esta forma tener una prueba de integración completa que previamente se probó en forma individual.
· Cuando se identifica que un conjunto de pruebas comparten pasos de ejecución y o verificación. Para este caso, la prueba consiste en comprobar que no importa que camino se elija, la operación siempre termina de ejecutarse correctamente.
Ejemplo: RF1: Se solicita agregar en la pantalla 3 un componente que permita seleccionar que se va a realizar con los datos obtenidos por la aplicación de filtros en pantallas anteriores.
¿Qué ventaja existe en escribir 4 casos de prueba en lugar de 3 casos de prueba? Primero, en el caso de tener que modificar el CP1 por un cambio de funcionalidad, solo hay que editar un CP y no tres. Segundo, Si se agrega N opciones no hace falta escribir N veces las pruebas contempladas en CP1
Siguiendo con el ejemplo, ¿cómo quedarían las pruebas con el call?
Un error que se suele cometer es confundir un Call con una precondición.
Ejemplo: la operación OC01.1 Alta Inicial Codificada tiene como precondición ejecutar OC17 – Control de Crédito. Ahora bien, si se modificó el código de la operación OC01.1, la prueba consiste en verificar que esta operación funcione como debería. Sí en el Step 1 agregamos un Call a la operación OC17, también estaríamos probando el funcionamiento de la operación de control de crédito, la cual no fue modificada. En cambio si agregamos en la solapa de precondiciones que debemos realizar una operación OC17 para después ejecutar la OC01.1, solo nos estaríamos concentrando en la operación que debemos probar.
¿Cómo agregar un Call a un caso de prueba en el QC?
En la solapa Design Steps, presionar el icono Call to Test, que se muestra en la figura:
Se abre una pantalla, en donde podemos seleccionar la prueba a la que el call va a hacer de referencia.
Cuando se presiona OK, se puede ver agregado el link a la prueba
Como y cuándo utilizar parámetros
Los parámetros ayudan a la reutilización de las pruebas, al permitir agregarle variantes a la ejecución de las mismas. La condición que se debe cumplir es que para cualquiera de las variantes ingresadas el resultado esperado sea el mismo.
Ejemplo: Se tiene que verificar que cualquiera sea el estado de un número, cuando se aplique la operación Cancelar número el estado final del mismo sea Cerrado.
Tenemos la opción de escribir 3 pruebas, una por cada estado inicial, o escribir un único caso de prueba y utilizar un parámetro, en este caso estado_nro para re utilizar la prueba 3 veces.
¿Cómo quedaría la prueba escrita?
Ubicación | Subject/Carpeta/Numero | |
Titulo | 01.01.-F_CARNUM – Cancelar Número | |
Descripción | Este caso de prueba es para verificar que cuando se ejecuta la operación Cancelar Número, el mismo quede con estado final CERRADO | |
Precondiciones | n/a | |
Pasos | Descripción | Resultado Esperado |
Step 1 | Ir al menú Buscar Numero Buscar un número con estado = estado_nro | Que se visualicen por pantalla todos los números cuyo estado sea estado_nro. |
Step 2 | Seleccionar un número. Presionar la opción Cancelar Número | Que el estado final del número sea Cerrado |
Parámetros | Descripción | Valor por defecto |
estado_nro | Estado que debe tener el número para la prueba: Abierto, Pendiente, Bloqueado, Procesado | vacío |
¿Cómo se agrega un parámetro en el QC?
Desde la solapa Design Spteps, ir al icono New Step como se muestra en la figura.
Empezar a escribir el caso de prueba, y cuando se requiera ingresar el valor especifico del campo, ir al icono Insert Parameter, como se muestra en la figura [1]
Ir al icono New Parameter [2] y se visualiza la pantalla New Parameter.
Ingresar en el campo Parameter Name, el nombre del parámetro, el mismo debe ser descriptivo y fácil de entender, puede ser una palabra o varias, en este último caso debe estar unida por “_”.
Después ir a la solapa Default Value [4] y agregar un valor por defecto si corresponde.
Para completar los datos del parámetro, ir a la solapa Description [5] y agregar la definición del parámetro, los posibles valores a tomar o el origen de los datos.
Presionar la tecla OK, hasta volver a la pantalla del Design Step Editor, donde se visualiza el parámetro recién creado, como se muestra en la figura
Continuar con la escritura del CP.
Para realizar cualquier modificación sobre un parámetro ya creado, ir a la solapa Test Parameter y modificar las propiedades del mismo.
Como escribir un template
Un caso template es una caso de prueba que se escribe en forma genérica y que sirve para realizar una prueba específica y repetitiva.
Las pruebas que se podrían escribir como template son aquellas
· Que validan campos.
· Que el comportamiento esperado siempre es el mismo como en la ejecución de procesos, es decir siempre se espera el mismo resultado, ejemplo: que se genere un archivo en la ubicación especificada.
· Que validan el comportamiento de los componentes de pantalla que siempre se tienen que manejar igual no importa en que modulo se encuentre dentro de un mismo sistema comercial.
· Etc.
Ejemplo: Campo Fecha dentro del SC SGU. Este componente se tiene que comportar de la misma forma en todos los módulos, ya sea ADI, ADN, Pricing, Distribución, Facturación, etc
¿Qué se necesita validar?
El formato de la fecha
El valor del campo día
El valor del mes,
El tipo de datos a ingresar
El valor por defecto
La obligatoriedad del campo
Etc
Estas son pruebas que siempre se tienen que realizar sobre un campo del tipo fecha, no importa la aplicación que se utilice.
Entonces podríamos escribir una prueba tipo template para que todo el mundo pueda utilizarla. Ejemplo:
Ubicación | Subject/Templates/Componentes | |
Titulo | 01.01.-F_TMPCOP - Campo fecha - formato | |
Descripción | Este caso de prueba es para verificar que el formato del componente Fecha cumple con el comportamiento esperado dentro del sistema comercial SGU. | |
Precondiciones | n/a | |
Pasos | Descripción | Resultado Esperado |
Step 1 | Verificar que el campo < | Que el campo < |
Step 2 | Verificar que el formato del campo sea < | Que el formato sea < |
Step 3 | Verificar que si se ingresa un formato incorrecto se informe por pantalla. | Que se muestre un mensaje por pantalla informando que el formato no es el esperado. |
Step 4 | Verificar que si se ingresa un valor para el día, inferior a 1 o superior a 31, se muestre por pantalla un mensaje de error. | Que solo muestre un mensaje por pantalla informando que el formato no es el esperado. |
Step 5 | Verificar que si se ingresa un valor para el mes, inferior a 1 o superior a 12, se muestre por pantalla un mensaje de error. | Que solo muestre un mensaje por pantalla informando que el formato no es el esperado. |
Step 6 | Verificar que el valor por defecto del campo sea < | Que en el campo se visualice el valor < |
Step 7 | Verificar que solo se pueden ingresar números en el campo. | Que solo se pueda ingresar números en el campo. |
Parámetros | Descripción | Valor por defecto |
nombre_del_campo | Nombre del campo que se esta verificando. | vacío |
Es_obligatorio | Si un campo es obligatorio o no. Posibles valores: SI o NO | SI |
formato | Formato del campo fecha. | DD/MM/YYYY |
Valor_x_defecto | El valor inicial que debe tener el campo. | Fecha_Actual |
¿Cómo marcar un CP como template en QC?
Parado en el caso de prueba presionar botón derecho y marcar Mark as Template Test
En resumen, ¿Qué se necesita para escribir un template?
· Determinar si la prueba es repetitiva.
· Determinar si la prueba se puede escribir a un nivel general para que pueda ser utilizada en todas pantallas de un mismo SC.
· Si se utiliza parámetros, estos deben tener nombres claros y bien definidos
· Se tiene que detallar en la descripción del CP, cual es el propósito de la prueba y el alcance.
Lista de Palabras | Ejemplos |
Datos correctos | Que se carguen los datos correctos Que se muestre la pantalla en forma correcta |
Tal como en | Que el alta se realice como en la operación XX Que se genere el archivo tal como en el modulo de … |
Correctamente | Que la pantalla muestre los datos correctamente. Que el archivo se genere correctamente Que la operación se genere correctamente Que el alta se haya generado correctamente |
“algo” consistente | Que los datos sean consistentes. Que las información se muestre por pantalla sea consistente |
Correspondiente | Que se muestre el valor correspondiente. |
Esperada | Que el sistema se comporte de la manera esperada. |
En ninguna parte del Caso de Prueba se debe utilizar estas palabras. Las mismas son genéricas y no aportan ningún tipo de información que pueda servir al CP.
2 Organizar el Plan de Prueba
Con un plan de prueba bien organizado se puede determinar el avance del requerimiento y mostrar la situación actual del mismo.
Para ello hay que tener en claro que es lo que marca el progreso en la ejecución de las pruebas.
Hoy en día tenemos que cada proyecto tiene al menos un ciclo y un test set en el cual se encuentran todas las pruebas. En base a esto, se puede determinar el avance del proyecto, al contabilizar la cantidad de pruebas que se ejecutaron con éxito. Ejemplo:
PRY##### | % de Pruebas | % No run | % Fail | % Ok | |
Ciclo 1 | Test Set 1 | 100 % | 60 | 10 | 30 |
¿Qué significan estos números?
Casos de prueba con OK
¿Podemos decir con certeza :
· Que el 30% corresponde al los RF o CU mas importantes?
· Que el 30% corresponde al los RF o CU menos prioritarios?
· Cuáles del los RF o CU se certificaron y cuáles no?
Casos de prueba con Error
¿Podemos claramente determinar
· cuál RF o CU tiene la mayor cantidad de errores
· qué todos los RF o CU tienen defectos
· cuáles son los puntos funcionales requieren una mayor atención de desarrollo?
¿Qué pasaría si cambiamos la organización del plan de prueba y lo organizamos en función de los RF o CU? Ejemplo:
PRY##### | Cant de Pruebas | No Run | % Fail | % Ok | |
Ciclo 1 | RF 1 | 40 | 40 | 0 | 0 |
RF 2 | 25 | 0 | 0 | 25 | |
RF 3 | 20 | 5 | 15 | 0 | |
RF 4 | 15 | 0 | 5 | 10 | |
Totales | 100 | 45 | 15 | 35 |
Del ejemplo podemos sacar la siguiente información:
De los 4 RF a certificar tenemos que:
ü Uno se probó completamente con todas sus pruebas en Ok, esto representa un 25 % de progreso en el proyecto. (RF2)
ü Un 25 % no fue ejecutado hasta el momento. (RF1)
ü El 50 % no paso las pruebas y sabemos cuales son los RF. (RF 3 y 4)
ü Tenemos cual es el RF con mayores problemas. (RF3)
Sólo cuando el total de las pruebas del RF den OK y todos sus defectos estén cerrados, se puede marcar un progreso en el requerimiento.
Veamos otro ejemplo con más complejidad, en este caso el proyecto esta distribuido en distintos sistemas comerciales y fue desarrollado por diferentes áreas de desarrollo.
PRY#### | Carpeta | Test Set | No Run | Fail | OK | Total CP | |
Ciclo 1 | |||||||
Movics | |||||||
Opera 1 | 5 | 5 | 10 | ||||
Opera 2 | 5 | 5 | |||||
Opera 3 | 5 | 5 | |||||
Siscel | |||||||
Opera 4 | 5 | 5 | |||||
Opera 5 | 1 | 4 | 5 | ||||
Opera 6 | 5 | 5 | |||||
SDT | |||||||
Opera 7 | 30 | 30 | |||||
SGU | |||||||
Opera 8 | 10 | 10 | |||||
Opera 9 | 10 | 10 | |||||
Totales | 42 | 36 | 17 | 95 |
De este ejemplo podemos deducir lo siguiente:
ü El PRY#### tiene un porcentaje de progreso de 50% (SDT y SGU) y los sistemas que presentan dificultad son Movics y Siscel.
ü Dentro de Movics, las operaciones 1 y 3 tienen defectos
ü Dentro de Siscel, la operación 5 tiene defectos.
ü Movics tiene un 0% de avance mientras Siscel tiene un avance del 33%.
ü SDT y SGU están probados al 100%
En este ejemplo el avance del proyecto se marca cuando se completa el total de las pruebas en cada carpeta.
En resumen:
La organización del plan va a depender del tipo de proyecto y de lo que se necesite mostrar a la hora de presentar informes de situación. Es importante pensar esto antes de armar el plan para que la organización del mismo nos sea útil. La idea es que, cualquiera sea la persona que lo mire, pueda ver y analizar la situación del proyecto.
¿Cómo armar un plan de pruebas?
R Crear tantos Test Set como funcionalidad se requiera utilizar.
R De ser necesario crear carpetas que permita agrupar los test set en forma lógica.
R No generar un árbol de carpetas. Esto quita la visibilidad sobre el proyecto. Se recomienda: Ciclo # à Carpeta à Conjunto de Test Set.
¿Cuando se marca el avance?
R Cuando un test set tiene todas sus pruebas en OK y sin defectos pendientes.
R Cuando una carpeta tiene todos sus test set con las pruebas en OK y sin defectos pendientes
Cuanto mas cantidad de pruebas tenga un test set mayor va a ser la probabilidad que no se pueda marcar un progreso, ya que si una prueba tiene error no se puede decir que la funcionalidad que cubre el test set se haya certificado.
Esto SI se debe hacer | Esto NO se debe hacer |
R Pensar en el diseño del plan antes de crear los test set | Q No armar un plan de pruebas en forma automática. |
R Crear Test Set por funcionalidad | Q No crear un único Test Set con todas las pruebas del proyecto |
R El Test Set debe tener una cantidad limitada de CP. | Q El Test Set no debería superar los 10 CP |
R Numerar los test set, si es posible en el orden en que hay que probarlos. | Q |
R Crear un árbol con el siguiente formato: Ciclo # à Carpeta à Conjunto de Test Set. | Q No crear un árbol del siguiente tipo: Ciclo # à Carpeta_Padre à Carpeta_Hijoà Carpeta_Nietoà Conjunto de Test Set. |
Veamos distintas formas en las que se puede organizar un plan:
Proyecto en el que se tiene que probar una pantalla nueva la cual tiene la funcionalidad de un ABM
Ciclo 1 | Carpeta | Test Set | Cant. CP |
01.- Pantalla XX | |||
01.- Formato de pantalla | 20 | ||
02.- Alta de … | 5 | ||
03.- Baja de … | 3 | ||
04.- Modificación de … | 2 | ||
05.- Consultas por filtros | 15 | ||
Otra forma podría ser:
Ciclo 1 | Carpeta | Test Set | CP |
01.- Pantalla XX - formato | |||
01.- Sección Encabezado | 5 | ||
02.- Sección Ingreso de Datos | 10 | ||
03.- Sección Grilla de datos | 5 | ||
02.-Pantalla XX - Funcionalidad | |||
01.- Alta de … | 5 | ||
02.- Baja de … | 3 | ||
03.- Modificación de … | 2 | ||
04.- Consultas por filtros | 15 | ||
Un proyecto en el que se tenga que organizar las pruebas en función de prioridad de las operaciones
Ciclo 1 | Carpeta | Test Set | Cant. CP |
01.- Op. Prioridad Alta | |||
01.- GC01.1 | 3 | ||
02.- GC02.1 | 5 | ||
03.- SC20.1 | 2 | ||
04.- SC77.0 | 1 | ||
05.- SC04.1 | 10 | ||
02.-Op. Prioridad Media | |||
01.- SC10.4 | 2 | ||
02.- GC02.0 | 2 | ||
03.- SC10.8 | 1 | ||
04.- AG17.0 | 1 | ||
05.- SC73.1 | 5 | ||
03.-Op. Prioridad Baja | |||
01.- SI02.0 | 5 | ||
02.- SV11.0 | 2 | ||
03.- SV17.2 | 3 | ||
04.- SV23.0 | 2 | ||
05.- SV24.0 | 1 | ||
Un proyecto cuyas pruebas se realizan en diferentes plataformas
Ciclo 1 | Carpeta | Test Set | Cant. CP |
01.- Movics | |||
01.01.- Pantalla XX - Sección Encabezado | 5 | ||
01.02.- Pantalla XX - Sección Datos | 10 | ||
01.03.- Pantalla XX - Sección Grilla | 5 | ||
02.01.- Pantalla XX - Alta de … | 5 | ||
02.02.- Pantalla XX - Baja de … | 3 | ||
02.03.- Pantalla XX - Modificación de … | 2 | ||
02.04.- Pantalla XX - Consultas por filtros | 15 | ||
03.- GC02.0 | 1 | ||
04.- SC73.1 | 1 | ||
02.- Siscel | |||
01.- Alta por Sistema | 4 | ||
02.- Cambio de Número | 2 | ||
03.- Cambio de Solicitud | 3 | ||
04.- Baja de Numero – Contrato - Ahorro | 10 | ||
05.- Baja de Numero - Prepago | 5 | ||
3 Anexo I – Ejemplo de Casos de Prueba
[] = los paréntesis significan “opcional”
Esta es una prueba genérica. Se puede utilizar con todas las pantallas del alta inicial.
Ubicación | Subject/Movics/Operaciones/ OC01 - Alta Inicial/ OC01.1 | |
Titulo | 01.01.-F_OC01- Botón Cancelar | |
Descripción | Este caso de prueba es para verificar que cuando se presiona el botón Cancelar, Movics genera un número de operación y regresa a la pantalla de Operaciones sobre Clientes. | |
Precondiciones | 1.-Realizar una operación OC17.4 - Cont Créd Manual. | |
Pasos | Descripción | Resultado Esperado |
Step 1 | Ingresar todos los datos requeridos para la < Presionar F10 | Que se visualice el menú que permite elegir: cancelar , confirmar y continuar |
Step 2 | Seleccionar Cancelar | 1.- Que se genere el número de operación. 2.- Que el control de la aplicación retorne a la pantalla de Operaciones sobre Clientes. 3.- Que el número de la operación se encuentre en la tabla WLF_< |
Parámetros | Descripción | Valor por defecto |
Pantalla | Nombre de la pantalla en la que se esta trabajando | |
DTM# | DTM en el cual se realiza las pruebas | |
Esta es una prueba genérica. Se puede utilizar para validar ambiente ya que no importa que tipo de producto se utilice o que tipo de vendedor realice la operación; el alta del cliente se tiene que poder realizar.
Si el propósito de la prueba se modifica o las precondiciones se alteran o se especifican con más detalle, para poder realizar una prueba en particular, se tiene que escribir un nuevo caso de prueba.
Ubicación | Subject/Movics/Operaciones/ OC01 - Alta Inicial/ OC01.1 | |
Titulo | 03.01.-UF_OC01- Alta Codificada x pantalla – OK | |
Descripción | Este caso de prueba es para verificar que se puede realizar el alta de un cliente en el ambiente. Prueba genérica, aplica para todo tipo de producto y vendedor | |
Precondiciones | 1.-Realizar una operación OC17.4 - Cont Créd Manual. | |
Pasos | Descripción | Resultado Esperado |
Step 1 | Ingresar: Cod.Paq.Eq Cod.Paq.Serv Forma Cont Vendedor [Subagente] Tipo Documento Nro Doc Tipo Formulario Tipo Activación Presionar Enter Seleccionar Confirma | Que se habilite el campo tipo persona. |
Step 2 | Ingresar: Tipo Persona Categoría IVA SubAlm/Localidad Presionar Enter Seleccionar Confirma | Que se habilite la pantalla para ingresar la sim card y el equipo |
Step 3 | Ingresar: Sim Card Terminal Presionar F10 dos veces Seleccionar Confirma | Que se habilite el ingreso de Comentarios |
Step 4 | Paso Opcional Ingresar un comentario Presionar Enter Seleccionar Confirma | Que se habilite la pantalla “Datos del Cliente - Control de Crédito” |
Step 5 | Ingresar: Apellido Nombre Nac Presionar F10 Seleccionar Confirma | Que se habilite la pantalla de “Datos Apoderado” |
Step 6 | Paso Opcional Ingresar: Tipo Autorización Nombre Apoderado Tipo y Nro. Doc. [Observaciones] Presionar F10 Seleccionar Confirma | Que se habilite la pantalla de “Alta de Débito Automático” |
Step 7 | Paso Opcional Ingresar: Entidad Tipo Cta Número Presionar F10 Seleccionar Confirma | Que se habilite la pantalla de “Datos del Cliente – Titular” |
Step 8 | Ingresar Datos para la Facturación: Calle Número Piso C.Post Pcia Nuevo Campo Ingresar Datos para CRM: [Ciclo] Presionar F10 Seleccionar Confirma | 1.- Que se genere el número de operación. 2.- Que el control de la aplicación retorne a la pantalla de Operaciones sobre Clientes. |
Step 9 | Postear la operación | 1.- Que el estado de la operación sea Procesada: a.-Desde la base del dtm asociado (WLF_CAB.cab_estado = P) b.-Desde las consultas: · Operaciones de un Cliente · Operaciones de una Cuenta 2.- Que se pueda consultar los datos del cliente desde el menú: · Datos de una Cuenta · Datos Generales del Cliente · Cuenta Corriente de Cliente · Servicios Periódicos |
Parámetros | Descripción | Valor por defecto |
4 Anexo II – Cuadros Resumen
Cuadros con el resumen de los principales puntos de la guía
Caso de Prueba | Formato |
Titulo | ESCENARIO_ORDEN.-CLASE_UBICACION – Titulo Ejemplo: 01.01.-UF_OC01 – Alta Inicial |
Descripción | Propósito / Objetivo: Este caso de prueba es para [validar / verificar/ comprobar/ generar/ consultar] que ”suceda algo” cuando exista determinada “condición” [Información Adicional] [Nombre de Proceso] [Parámetros] [Entrada] [Salida] [Ubicación] |
Precondición | ¿Qué se necesita tener para poder realizar la prueba? Número de orden .- Verbo en Infinitivo + cláusula 1.- [Configurar / Utilizar / Ingresar / Iniciar / Realizar / Ejecutar / Generar] + … |
Descripción del Paso | Todos los pasos deben iniciar con un verbo en infinitivo: Ir, Verificar, Comprobar, Visualizar, etc |
Resultado Esperado | Que se + suceda algo Que algo sea … |
Área del CP | Esto SI | Esto No |
Descripción del CP | R El CP debe tener descripción | Q No debe existir dos descripciones iguales o se estaría duplicando un CP |
R La descripción debe ser breve. | Q En la descripción no se debe contar el requerimiento | |
R La descripción debe ser especificar al CP | R La descripción no debe ser general | |
R Todo proceso previo a la ejecución del proceso que vamos a probar, se debe listar como precondición | Q No utilizar siglas, al menos que se ponga la definición entre paréntesis la primera vez que se utiliza | |
Precondiciones | R Deben escribirse en orden de ejecución. | Q No se debe mencionar nombre de usuarios o password. |
R Deben ser acciones previas, necesarias para realizar la prueba. | Q No se deben incluir pruebas | |
R Deben ser claras y específicas. | Q No se debe incluir código. | |
Descripción del Paso | R La descripción del Paso es obligatoria. | Q Descripción que no marca una acción |
La descripción debe ser específica. | Q En la descripción no se debe contar el requerimiento | |
R La descripción siempre tiene que mostrar una dirección de acción. | Q No debe permitir más de un camino de acción. | |
R Todo proceso previo a la ejecución del proceso, al cual se refiere la prueba, se debe listar como condición previa. | Q No utilizar siglas, al menos que se ponga la definición entre paréntesis la primera vez que se utiliza | |
R Tiene que ser de fácil comprensión. | Q La descripción no debe ser general | |
Resultado Esperado | R Debe existir un resultado esperado | Q No se debe marcar una acción |
R Se debe escribir que una respuesta | Q No se debe utilizar verbos en infinitivo | |
R Si es una lista de eventos, tiene que estar numerada | ||
R Siempre debe empezar con la preposición QUE |
Siglas y Abreviaciones
Término | Significado |
ADI | Administración de Incidencias |
ADN | Administración de Numeración |
AF | Análisis Funcional |
CP | Caso de prueba |
CU | Caso de Uso |
QC | Quality Center |
RF | Referencia Funcional |
SC | Sistema Comercial. Ejemplo: Movics, Siscel, SGU |
SDT | Sistema de Transacciones |
SGU | Sistema Único de Gestión |
Muchas gracias por realizar este guia tan completa!
ResponderEliminar