Nada tiene mayor influencia en la posibilidad de que los equipos de diseño garanticen la satisfacción del interesado
con el software que la disponibilidad de una especificación clara de lo que son las expectativas de los interesados.
Con o sin un conjunto de especificaciones de requisitos lo suficientemente bueno, los casos de uso son un artefacto que
ayuda a reflejar las expectativas de los interesados, puesto que permite verificar y validar dichas expectativas.
Cuando un conjunto útil de requisitos está disponible, el equipo de prueba debe planificar pruebas que validen
adecuadamente dichos requisitos. Tenga en cuenta que se puede validar el software con respecto a los requisitos de modo
diferente, dependiendo del tipo de requisito. Por ejemplo, un verificador puede ejecutar el software para validar sus
requisitos de funcionamiento y rendimiento utilizando técnicas de prueba automatizadas, mientras que es posible que
para verificar un requisito de configuración como, por ejemplo, la conclusión de un sistema, se deban utilizar técnicas
de prueba manual.
Puesto que quizá no pueda (o no sea responsable) de verificar todos los requisitos, es importante que se centre en los
requisitos críticos o más adecuados para el ámbito del esfuerzo de trabajo actual. Los requisitos que elija para
verificar serán un equilibrio entre el coste, el riesgo y la necesidad de tener el requisito verificado y, por lo
general, se limitarán al ámbito de la iteración actual.
Mientras que los requisitos son una fuente importante de la que pueden derivar las pruebas, no son la única fuente de
información. De hecho, en muchos casos resultan insuficientes para facilitar una base completa para el desarrollo de
las pruebas. También se deben tener en cuenta los guiones de prueba, puesto que se basan en fuentes de información
como, por ejemplo, riesgos, restricciones, tecnologías, solicitudes de cambio (defectos) o anomalías, entre
otras.
Consulte el apartado Concepto: Ideas de
prueba para obtener más información sobre cómo obtener ideas de las que derivar las pruebas.
Identificar los guiones de prueba resulta útil por varios motivos.
-
Los guiones de prueba se pueden utilizar como base sobre la que diseñar e implementar las pruebas reales. El tiempo
dedicado a considerar el caso de uso ayuda a comprender los requisitos de diseño e implementación, y permite
ahorrar tiempo en tareas de diseño e implementación.
-
Algunas pruebas son especialmente complejas o detalladas. Las pruebas de este tipo pueden aprovechar por anticipado
las ventajas de una consideración cuidadosa antes de empezar la implementación de la prueba, y los artefactos de
guión de prueba y guión de diseño son herramientas adecuadas para explorar dichas consideraciones.
-
Por lo general, la "profundidad" de la prueba se considera proporcional al número de pruebas. Con frecuencia se
obtiene mayor seguridad en el proceso de la prueba en sí cuando se puede razonar la posible "profundidad" de la
prueba en función del número de guiones de prueba identificados.
-
Una medida de completitud del esfuerzo de la prueba se basa en al cobertura de supervisión con respecto a algún
conjunto de elementos de motivación. El informe de cobertura se puede basar en medidas como, por ejemplo, el número
de guiones de prueba identificados y el número de pruebas implementadas o ejecutadas con respecto a cada guión de
prueba, o bien, el esfuerzo gastado con respecto a cada guión de prueba.
-
La escala y la complejidad del esfuerzo de prueba es, hasta cierto punto, proporcional al número de guiones de
prueba. Con un análisis de los guiones de prueba, se puede razonar el esfuerzo de prueba sobre un nivel de
granularidad más fino.
-
El número y la complejidad de los guiones de prueba rigen, en parte, los tipos de desarrollo y diseño de pruebas, y
los recursos necesarios.
Sin embargo, existen algunos problemas que vale la pena considerar con respecto a los guiones de prueba:
-
No todas las pruebas son lo suficientemente complejos como para garantizar los gastos generales de crear un
artefacto de guión de prueba que se debe revisar y mantener: la prueba es lo bastante simple como para que una
descripción de texto breve sea suficiente para transmitir lo que se necesita. En realidad, la mayoría de guiones de
prueba pueden entrar dentro de esta categoría. El tiempo dedicado a documentar un vasto volumen de casos de uso
simples puede tener como resultado la pérdida de tiempo para tareas de prueba más importantes.
-
Se comprueba que algunas de las ideas iniciales sobre las pruebas fracasan posteriormente en algún aspecto.
Significa que se abandonan algunos guiones de prueba que había identificado inicialmente en base a dichas ideas.
Esta realidad supone que cualquier trabajo que realice documentando guiones de prueba con detalle se puede
abandonar posteriormente y que cualquier informe de cobertura que se base en los casos de uso debe considerar dicha
situación. Como tal, quizá sea mejor basar el informe de cobertura de los guiones de prueba en función de aspectos
de nivel superior a los guiones de prueba y tratar los guiones de prueba como artefactos del equipo de prueba
interno que se utilicen según se requiera.
Con frecuencia, los casos de prueba se pueden clasificar por categorías en función del tipo de prueba o requisito para
la prueba al que están asociados, y variar de acuerdo con esto. Una heurística para identificar guiones de prueba
empieza con lo siguiente:
-
demostrar que se ha alcanzado el requisito (guión de prueba positivo)
-
demostrar que el requisito sólo se ha alcanzado en las condiciones deseadas, a las que se hace referencia
como una prueba negativa. Este guión de prueba refleja condiciones inaceptables, anómalas o inesperadas, o bien,
datos a los que el software puede estar, razonablemente, sujeto.
Los guiones de prueba para prueba de funcionamiento derivan de los casos de uso de la prueba de destino (consulte el
apartado Producto de trabajo: Caso de uso ). Se deben desarrollar guiones de
prueba para cada caso de ejemplo de caso de uso . Los casos de ejemplo de caso de uso se identifican al describir las
vías de acceso a través del caso de uso que cruzan el flujo básico y el inicio de flujos alternativos para finalizar a
través del caso de uso .
En el diagrama que se incluye más abajo, se representan con las flechas cada una de las distintas vías de acceso a
través del caso de uso que reflejan los flujos básico y alternativo. El flujo básico, representado mediante la línea
recta negra, es la vía de acceso más simple a través del caso de uso . Cada flujo alternativo empieza con el flujo
básico y, a continuación, dependiendo de una condición específica, se ejecuta el flujo alternativo. Los flujos
alternativos se pueden volver a unir al flujo básico (flujos alternativos 1 y 3), se pueden originar a partir de otro
flujo alternativo (flujo alternativo 2), o bien, pueden terminar el caso de uso sin volver a unirse a un flujo (flujos
alternativos 2 y 4).
Flujos de sucesos de ejemplo para un caso de uso
Siguiendo cada vía de acceso posible a través del caso de uso del diagrama anterior, se pueden identificar los
diferentes casos de ejemplos del caso de uso . Empezando por el flujo básico y, a continuación, combinando el flujo
básico con flujos alternativos, se pueden identificar los casos de ejemplo de caso de uso siguientes:
Caso de ejemplo 1
|
Flujo básico
|
|
|
|
Caso de ejemplo 2
|
Flujo básico
|
Flujo alternativo 1
|
|
|
Caso de ejemplo 3
|
Flujo básico
|
Flujo alternativo 1
|
Flujo alternativo 2
|
|
Caso de ejemplo 4
|
Flujo básico
|
Flujo alternativo 3
|
|
|
Caso de ejemplo 5
|
Flujo básico
|
Flujo alternativo 3
|
Flujo alternativo 1
|
|
Caso de ejemplo 6
|
Flujo básico
|
Flujo alternativo 3
|
Flujo alternativo 1
|
Flujo alternativo 2
|
Caso de ejemplo 7
|
Flujo básico
|
Flujo alternativo 4
|
|
|
Caso de ejemplo 8
|
Flujo básico
|
Flujo alternativo 3
|
Flujo alternativo 4
|
|
Nota: Para ofrecer mayor simplicidad, los casos de ejemplo 5, 6 y 8 sólo ilustran una única ejecución del
bucle que indica el flujo alternativo 3.
La derivación de los guiones de prueba para cada caso de ejemplo se lleva a cabo identificando la condición específica
que hace que se ejecute el caso de ejemplo del guión de prueba específico.
Por ejemplo, suponga que el caso de uso que se ilustra en el diagrama anterior establece lo siguiente para el flujo
alternativo 3:
"Este flujo de sucesos ocurre si el importe en dólares que se ha indicado en el Paso 2 más arriba, "Entrar importe de
la retirada" es mayor que el saldo de cuenta actual. El sistema muestra un mensaje de aviso y, a continuación, se
vuelve a unir al flujo básico del Paso 2 "Entrar importe de la retirada" anterior, donde el cliente del banco puede
entrar una nuevo importe de retirada."
Con esta información, puede empezar a identificar los guiones de prueba necesarios para ejecutar el flujo alternativo
3:
ID del guión de prueba
|
Caso de ejemplo
|
Condición
|
Resultado esperado
|
TC x
|
Caso de ejemplo 4
|
Paso 2 - Importe de retirada > Saldo de cuenta
|
Volver a unir flujo básico en el Paso 2
|
TC y
|
Caso de ejemplo 4
|
Paso 2 - Importe de retirada < Saldo de cuenta
|
No ejecuta el Flujo alternativo 3, toma el flujo básico
|
TC z
|
Caso de ejemplo 4
|
Paso 2 - Importe de retirada = Saldo de cuenta
|
No ejecuta el Flujo alternativo 3, toma el flujo básico
|
Nota: Los guiones de prueba que se muestran más arriba son muy simplistas, puesto que no se facilita más
información. Rara vez los guiones de prueba son tan simples.
Más abajo se proporciona un ejemplo más realista de derivación de guiones de prueba de casos de uso :
Ejemplo:
Actores y casos de uso en una máquina cajero automático.
La tabla siguiente contiene el flujo básico y algunos flujos alternativos para el caso de uso Retirada de dinero del
diagrama anterior:
Flujo básico
|
Este caso de uso empieza con el cajero automático en el estado Preparado.
-
Iniciar Retirada - El cliente inserta la tarjeta bancaria en el lector de tarjetas del cajero
automático.
-
Verificar tarjeta bancaria - El cajero automático lee el código de cuenta de la banda magnética
de la tarjeta bancaria y comprueba si es una tarjeta bancaria aceptable.
-
Entrar PIN - El cajero automático solicita al cliente el código PIN del cliente (4
dígitos)
-
Verificar código de cuenta y PIN - Se verifica el código de cuenta y el PIN para determinar si
la cuenta es válida y si el PIN entrado es el correcto para la cuenta. Para este flujo, la
cuenta y el PIN asociados a esta cuenta son correctos.
-
Opciones del cajero automático - El cajero automático muestra las diferentes alternativas
disponibles en el cajero automático. En este flujo, el cliente del banco siempre
selecciona "Retirada de dinero".
-
Entrar importe - El cajero solicita la cantidad a retirar. Para este flujo, el cliente
selecciona un importe preestablecido ($10, $20, $50 ó $100).
-
Autorización - El cajero automático inicia el proceso de verificación con el Sistema de banca
enviando el ID de la tarjeta, el PIN, el Importe y la información de Cuenta como una
transacción. Para este flujo, el Sistema de banca está en línea, responde con la
autorización para completar la retirada de dinero satisfactoriamente, y actualiza el saldo de
cuenta en consecuencia.
-
Dispensar - Se dispensa el dinero.
-
Devolver tarjeta - Se devuelve la tarjeta bancaria.
-
Recibo - Se imprime y entrega el recibo. El cajero automático también actualiza el
registro interno según corresponda.
El caso de uso finaliza con el cajero automático en el estado Preparado.
|
Flujo alternativo - La tarjeta no es válida
|
En el flujo básico del Paso 2 - Verificar tarjeta bancaria, si la tarjeta no es válida, se rechaza con
un mensaje adecuado.
|
Flujo alternativo 2 - El cajero automático no dispone de dinero
|
En el flujo básico del Paso 5 - Opciones del cajero automático, si el cajero automático no dispone de
dinero, la opción "Retirada de dinero" no está disponible.
|
Flujo alternativo 3 - El cajero automático no dispone de fondos suficientes
|
En el flujo básico del Paso 6 - Entrar importe, si el cajero automático no dispone de fondos
suficientes para dispensar el importe solicitado, se muestra un mensaje adecuado y se vuelve a unir al
flujo básico del Paso 6 - Entrar importe.
|
Flujo alternativo 4 - PIN incorrecto
|
En el flujo básico del Paso 4 - Verificar código de cuenta y PIN, el cliente dispone de tres intentos
para entrar el PIN correcto.
Si se entra un PIN incorrecto, el cajero automático muestra el mensaje adecuado y, si el cliente sigue
disponiendo de tres intentos, se vuelve a unir al flujo básico del Paso 3 - Entrar PIN.
Si, en el último intento, el número de PIN entrado es incorrecto, se retiene la tarjeta, el cajero
automático vuelve al estado Preparado y termina este caso de uso .
|
Flujo alternativo 5 - No existe cuenta
|
En el flujo básico del Paso 4 - Verificar código de cuenta y PIN, si el Sistema de banca devuelve un
código que indica que no se ha podido encontrar la cuenta o que la cuenta permite retiradas, el cajero
automático muestra el mensaje adecuado y se vuelve a unir al flujo básico del Paso 9 - Devolver
tarjeta.
|
Flujo alternativo 6 - Fondo en cuenta insuficiente
|
En el flujo básico del Paso 7 - Autorización, el Sistema de banca devuelve un código que indica
que el saldo de cuenta es inferior al importe entrado en el flujo básico del Paso 6 - Entrar importe,
el cajero automático muestra el mensaje adecuado y se vuelve a unir al flujo básico del paso 6 - Entrar
importe.
|
Flujo alternativo 7 - Se ha alcanzado el importe de retirada máximo diario
|
En el flujo básico del Paso 6 - Autorización, el Sistema de banca devuelve un código que indica que,
incluida esta solicitud de retirada, el cliente ha o habrá excedido el importe máximo permitido en un
período de 24 horas, el cajero automático muestra el mensaje adecuado y se vuelve a unir al flujo
básico del Paso 6 - Entrar importe.
|
Flujo alternativo x - Registro de errores
|
En el flujo básico del Paso 10 - Recibo, no se puede actualizar el registro, el cajero automático entra
en la "modalidad segura" en la que se suspenden todas las funciones. Se envía una alarma adecuada al
Sistema de banca para indicar que el cajero automático ha suspendido las operaciones.
|
Flujo alternativo y - Abandonar
|
En cualquier momento, el cliente puede decidir terminar la transacción (abandonar). Se detiene la
transacción y se expulsa la tarjeta.
|
Flujo alternativo z - "Inclinación"
|
El cajero automático contiene numerosos sensores que supervisan funciones diferentes como, por ejemplo,
la alimentación eléctrica, la presión ejercida en las puertas y entradas, así como detectores del
movimiento. Si se activa un sensor en cualquier momento, se envía una señal de alarma a la
policía y el cajero automático entra en un "modo seguro" en el que se suspenden todas las funciones
hasta que se llevan a cabo las acciones de reiniciar/reinicializar adecuadas.
|
En la primera iteración, según el plan de iteración, se debe verificar que el caso de uso Retirada de dinero se
haya implementado correctamente. El caso de uso completo aún no se ha implementado, sólo se han implementado los
flujos siguientes:
-
Flujo básico - Retirada de un importe preestablecido ($10, $20, $50, $100)
-
Flujo alternativo 2 - El cajero automático no dispone de dinero
-
Flujo alternativo 3 - El cajero automático no dispone de fondos suficientes
-
Flujo alternativo 4 - PIN incorrecto
-
Flujo alternativo 5 - No existe cuenta / Tipo de cuenta incorrecto
-
Flujo alternativo 6 - Fondos en cuenta insuficientes
De este caso de uso pueden derivar los casos de ejemplo siguientes:
Caso de ejemplo 1 - Retirada de dinero satisfactoria
|
Flujo básico
|
|
Caso de ejemplo 2 - El cajero automático no dispone de dinero
|
Flujo básico
|
Flujo alternativo 2
|
Caso de ejemplo 3 - El cajero automático no dispone de fondos suficientes
|
Flujo básico
|
Flujo alternativo 3
|
Caso de ejemplo 4 - PIN incorrecto (quedan intentos)
|
Flujo básico
|
Flujo alternativo 4
|
Caso de ejemplo 5 - PIN incorrecto (no quedan intentos)
|
Flujo básico
|
Flujo alternativo 4
|
Caso de ejemplo 6 - No existe cuenta / Tipo de cuenta incorrecto
|
Flujo básico
|
Flujo alternativo 5
|
Caso de ejemplo 7 - Saldo en cuenta insuficiente
|
Flujo básico
|
Flujo alternativo 6
|
Nota: Para ofrecer mayor simplicidad, en la tabla anterior no se han incluido los bucles de los flujos
alternativos 3 y 6 (Casos de ejemplo 3 y 7) y las combinaciones de los bucles.
Se deben identificar guiones de prueba para cada uno de estos siete casos de ejemplo. Los guiones de prueba se pueden
identificar utilizando matrices o tablas de decisión. Más abajo se muestra un formato común, donde cada fila representa
un guión de prueba individual y las columnas identifican la información del guión de prueba. En este ejemplo,
para cada guión de prueba hay un ID de guión de prueba, la Condición (o descripción), todos los elementos de datos que
participan en el guión de prueba (como entrada o ya en la base de datos) y el resultado esperado.
Para iniciar el desarrollo de la matriz, empiece por identificar los elementos de datos que se necesitan para ejecutar
los casos de ejemplo de caso de uso . A continuación, para cada caso de ejemplo identifique, como mínimo, el guión de
prueba que contenga la condición adecuada para ejecutar el caso de ejemplo. Por ejemplo, en la matriz que se muestra
más abajo, se utiliza V (válida) para indicar que esta condición debe ser VÁLIDA para que se ejecute el flujo básico e
I (no válida) para indicar la condición que invoca el flujo alternativo deseado. En la tabla siguiente, "n/a"
indica que esta condición no se aplica al guión de prueba.
Nº ID TC
|
Caso de ejemplo / Condición
|
PIN
|
Nº cuenta
|
Importe entrado
(importe elegido)
|
Importe en cuenta
|
Importe en cajero automático
|
Resultado esperado
|
CW1.
|
Caso de ejemplo 1 - Retirada de dinero satisfactoria
|
V
|
V
|
V
|
V
|
V
|
Retirada de dinero satisfactoria.
|
CW2.
|
Caso de ejemplo 2 - El cajero automático no dispone de dinero
|
V
|
V
|
V
|
V
|
I
|
Opción Retirada de dinero no disponible, fin del caso de uso .
|
CW3.
|
Caso de ejemplo 3 - El cajero automático no dispone de fondos suficientes
|
V
|
V
|
V
|
V
|
I
|
Mensaje de aviso, volver al flujo básico del Paso 6 - Entrar importe
|
CW4.
|
Caso de ejemplo 4 - PIN incorrecto (> queda 1 intento)
|
I
|
V
|
n/a
|
V
|
V
|
Mensaje de aviso, volver al flujo básico del Paso 4, Entrar PIN
|
CW5.
|
Caso de ejemplo 4 - PIN incorrecto (= queda 1 intentos)
|
I
|
V
|
n/a
|
V
|
V
|
Mensaje de aviso, volver al flujo básico del Paso 4, Entrar PIN
|
CW6.
|
Caso de ejemplo 4 - PIN incorrecto (= quedan 0 intentos)
|
I
|
V
|
n/a
|
V
|
V
|
Mensaje de aviso, tarjeta retenida, fin del caso de uso
|
En la matriz anterior, los seis guiones de prueba ejecutan los cuatro casos de ejemplo. Para el flujo básico, el guión
de prueba CW1 anterior se muestra como un guión de prueba positivo. Ejecuta la vía de acceso del flujo básico a través
del caso de uso sin ninguna desviación. La prueba completa del flujo básico debe incluir guiones de prueba negativos
con el objeto de garantizar que sólo se toma el flujo básico cuando las condiciones son correctas. Los guiones de
prueba negativos se representan por medio de los guiones de prueba CW2 a 6 (la celda sombreada indica la condición
necesaria para ejecutar los flujos alternativos). Mientras que CW2 a 6 son guiones de prueba negativos para el
flujo básico, son guiones de prueba positivos para los flujos alternativos 2 a 4 y hay, como mínimo un guión de prueba
negativo para cada uno de los flujos alternativos (CW1 - el flujo básico).
El caso de ejemplo 4 es un ejemplo en el que tener un guión de prueba negativo y otro positivo en cada caso de ejemplo
resulta insuficiente. Para probar el Caso de ejemplo 4 - PIN incorrecto minuciosamente, se necesitan, como mínimo, tres
casos de uso positivos (para invocar el Caso de ejemplo 4):
-
el PIN entrado es incorrecto, quedan intentos y este flujo alternativo se vuelve a unir al flujo básico de Paso 3 -
Entrar PIN.
-
el PIN entrado no es correcto, no quedan más intentos y el flujo alternativo retiene la tarjeta y termina el caso
de uso .
-
se ha entrado el PIN CORRECTO cuando ya no quedaban más intentos. Este flujo alternativo se vuelve a unir al
flujo básico del Paso 5 - Entrar importe.
Observe que, en la matriz anterior, no se han entrado valores reales para las condiciones (datos). Una de las ventajas
de crear la matriz de guión de prueba es que, de este modo resulta más fácil ver las condiciones que se están probando.
También resulta muy fácil determinar si se han identificado suficientes guiones de prueba, puesto que sólo se deben
observar las V y las I (o, como se ha hecho en este caso, las celdas sombreadas). Al observar la tabla anterior,
existen varias condiciones para las que no hay ninguna celda sombreada y, por lo tanto, faltan guiones de prueba, por
ejemplo, para el Caso de ejemplo 6 - No existe cuenta o Tipo de cuenta incorrecto y el Caso de ejemplo 7 - Saldo en
cuenta insuficiente.
Una vez que se hayan identificado suficientes guiones de prueba, se deben revisar y validar a fin garantizar su
precisión y adecuación, además de eliminar guiones de prueba duplicados, equivalente o, por el contrario, redundantes.
Consulte el apartado Concepto: Lista de
ideas de prueba para obtener más detalles. Consulte también el apartado Definición de datos de prueba para guiones de prueba para obtener información
detallada.
Nº ID TC
|
Caso de ejemplo / Condición
|
PIN
|
Nº cuenta
|
Importe entrado
(importe elegido)
|
Importe en cuenta
|
Importe en cajero automático
|
Resultado esperado
|
CW1.
|
Caso de ejemplo 1 - Retirada de dinero satisfactoria
|
4987
|
809 - 498
|
50,00
|
500,00
|
2.000
|
Retirada de dinero satisfactoria. Saldo en cuenta actualizado a 450,00
|
CW2.
|
Caso de ejemplo 2 - El cajero automático no dispone de dinero
|
4987
|
809 - 498
|
100,00
|
500,00
|
0,00
|
Opción Retirada de dinero no disponible, fin del caso de uso .
|
CW3.
|
Caso de ejemplo 3 - El cajero automático no dispone de fondos suficientes
|
4987
|
809 - 498
|
100,00
|
500,00
|
70,00
|
Mensaje de aviso, volver al flujo básico del Paso 6 - Entrar importe
|
CW4.
|
Caso de ejemplo 4 - PIN incorrecto (> queda 1 intento)
|
4978
|
809 - 498
|
n/a
|
500,00
|
2.000
|
Mensaje de aviso, volver al flujo básico del Paso 4, Entrar PIN
|
CW5.
|
Caso de ejemplo 4 - PIN incorrecto (= queda 1 intentos)
|
4978
|
809 - 498
|
n/a
|
500,00
|
2.000
|
Mensaje de aviso, volver al flujo básico del Paso 4, Entrar PIN
|
CW6.
|
Caso de ejemplo 4 - PIN incorrecto (= quedan 0 intentos)
|
4978
|
809 - 498
|
n/a
|
500,00
|
2.000
|
Mensaje de aviso, tarjeta retenida, fin del caso de uso
|
Los guiones de prueba anteriores son sólo unos cuantos de los guiones de prueba que se necesitan para verificar el caso
de uso Retirada de dinero para esta iteración. Otros casos de uso que se necesitan incluyen:
-
Caso de ejemplo 6 - No existe cuenta o Tipo de cuenta incorrecto: Cuenta no encontrada o no disponible
-
Caso de ejemplo 6 - No existe cuenta o Tipo de cuenta incorrecto: La cuenta no permite retiradas
-
Caso de ejemplo 7 - Saldo en cuenta insuficiente: El importe solicitado es mayor que el importe en cuenta.
En futuras iteraciones, cuando se implementen otros flujos, se necesitan guiones de prueba para:
-
Tarjetas no válidas (se informa que la tarjeta se ha perdido, robado, no pertenece a un banco aceptado o tiene la
banda magnética estropeada, por ejemplo).
-
Imposibilidad de leer la tarjeta (el lector de tarjetas está atascado, fuera de línea o no funciona correctamente)
-
Cuenta cerrada congelada o, de lo contrario, no disponible
-
El importe que contiene el cajero automático es insuficiente o no se puede crear el importe solicitado (se
diferencia de CW3 en que una denominación está fuera, pero no toda)
-
No se puede contactar con el Sistema de banca para la aprobación
-
La red del banco se queda fuera de línea, o bien, se produce una interrupción de la alimentación a mitad de la
transacción
Al identificar guiones de prueba funcionales, asegúrese de lo siguiente:
-
se han identificado suficientes guiones de prueba, positivos y negativos, para cada caso de ejemplo de caso de uso
-
los guiones de prueba tratan todas las reglas empresariales que implementan los casos de uso , garantizando que
haya guiones de prueba dentro, fuera y en el valor/condición de límite para la regla empresarial.
-
los guiones de prueba tratan todas las secuencias de sucesos o acciones como, por ejemplo, las que identifican los
diagramas de secuencia del modelo de diseño, o bien, las condiciones o los estados de objeto de la interfaz de
usuario.
-
los guiones de prueba tratan todos los requisitos especiales definidos para el caso de uso , por ejemplo,
rendimiento mínimo/máximo, en ocasiones combinados con cargas o volúmenes de datos mínimos/máximos durante la
ejecución de los casos de uso .
Consulte el apartado Definición de datos de prueba para guiones de prueba
para obtener más instrucciones.
No todos los requisitos para un destino de la prueba se reflejan en artefactos de requisitos funcionales como, por
ejemplo, especificaciones de casos de uso . Los requisitos no funcionales, por ejemplo, rendimiento, seguridad y
acceso, y los requisitos de configuración, especifican características o comportamientos adicionales del destino de la
prueba y, con frecuencia, se documentan por separado de los requisitos funcionales. El especificación suplementaria es
uno de los orígenes principales para la derivación de guiones de prueba de estos requisitos adicionales.
Más abajo se describen las directrices para derivar estos guiones de prueba adicionales:
La entrada principal para guiones de prueba de rendimiento son las especificaciones suplementarias que contienen los
requisitos no funcionales (consulte el apartado Producto de trabajo: Especificaciones suplementarias). Utiliza las
directrices siguientes para derivar guiones de prueba para la prueba de rendimiento:
-
asegúrese de que se ha identificado, como mínimo, un guión de prueba para cada sentencia de la especificación
suplementaria que establece un criterio de rendimiento. Por lo general, los criterios de rendimiento se expresan
como tiempo por transacción, número de transacciones/usuarios o percentiles.
-
asegúrese de que se identifique, como mínimo, un guión de prueba para cada caso de uso crítico. Los casos de uso
críticos son los que identifican en las sentencias anteriores o en el documento de análisis de carga de trabajo y
que se deben evaluar utilizando medidas de rendimiento (consulte el apartado Producto de trabajo: Documento de análisis de carga de trabajo).
Como sucede con los guiones de prueba para pruebas funcionales, por lo general, suele haber más de un guión de prueba
por requisito o caso de ejemplo de uso. Es habitual definir varios guiones de prueba, por ejemplo, uno que se sitúe por
debajo del valor de umbral de rendimiento (índice promedio de transacciones), otro en el valor de umbral (índice alto
de transacciones) y un tercer guión de prueba por encima del valor de umbral (índice punta de transacciones).
Además de los criterios de rendimiento anteriores, asegúrese de que identifica las condiciones específicas que afectan
a los tiempos de respuestas, incluidas:
-
Tamaño de la base de datos - ¿cuántos registros existen?
-
Carga de trabajo - patrones de transacción:
-
tipo, número y frecuencia de acciones simultáneas de usuario,
-
tipo, número, frecuencia y duración de las transacciones simultáneas realizadas
-
Características del entorno (configuración de hardware, netware y software)
Una práctica común consiste en capturar guiones de prueba para pruebas de rendimiento en matrices tabulares similares a
las que se utilizan para la prueba de función.
Consulte el apartado Definición de datos de prueba para guiones de prueba
para obtener información detallada.
A continuación se presentan algunos ejemplos para los diferentes tipos de pruebas de rendimiento:
Para la Prueba de carga:
Nº ID TC
|
Carga de trabajo
|
Condición
|
Resultado esperado
|
PCW1.
|
1
(un solo cajero automático)
|
Transacción de retirada completa
|
La transacción completa (el tiempo no depende de ningún actor) se produce en < 20 segundos
|
PCW2.
|
2
(1.000 cajeros automáticos simultáneos)
|
Transacción de retirada completa
|
La transacción completa (el tiempo no depende de ningún actor) se produce en < 30 segundos
|
PCW3.
|
3
(10.000 cajeros automáticos simultáneos)
|
Transacción de retirada completa
|
La transacción completa (el tiempo no depende de ningún actor) se produce en < 50 segundos
|
Para la Prueba de tensión:
Nº ID TC
|
Carga de trabajo
|
Condición
|
Resultado esperado
|
SCW1.
|
2
(1.000 cajeros automáticos simultáneos)
|
Bloqueo de base de datos - 2 cajeros automáticos solicitan la misma cuenta
|
La solicitudes de los cajeros automáticos se ponen en cola
|
SCW2.
|
2
(1.000 cajeros automáticos simultáneos)
|
La comunicación del Sistema de banca no está disponible
|
La transacción se pone en cola o se excede el tiempo de espera
|
SCW3.
|
2
(1.000 cajeros automáticos simultáneos)
|
La comunicación del Sistema de banca termina durante la transacción
|
Se muestra un mensaje de aviso
|
Los actores y los casos de uso describen la interacción entre usuarios externos del sistema y las acciones que lleva a
cabo el sistema para producir un valor para un actor concreto. Los sistemas complejos contienen varios actores, por lo
que resulta de extrema importancia desarrollar guiones de prueba para garantizar que sólo los actores especificados
puedan ejecutar los casos de uso . En especial, esto es cierto si existen diferencias en el flujo de sucesos de casos
de uso basados en el tipo de actor.
Por ejemplo, en los casos del cajero automático, se pueden ejecutar diferentes flujos de sucesos de casos de uso para
el actor "Cliente del banco" si la tarjeta y la cuenta es del banco que posee el cajero automático contra el "Cliente
del banco" que utiliza una tarjeta bancaria (y cuenta) de un banco de la competencia, o bien, que intenta utilizar una
tarjeta bancaria no participante.
Para los guiones de prueba funcionales, siga las mismas directrices que se indican más arriba.
Consulte el apartado Definición de datos de prueba para guiones de prueba
para obtener más instrucciones.
Guiones de prueba de ejemplo para Acceso y seguridad:
Nº ID TC
|
Condición
|
Tarjeta
(V indica tarjeta válida)
|
Lector de tarjetas
(V indica que el cajero funciona correctamente)
|
Red del banco
|
Resultado esperado
|
ACW1.
|
En red bancaria
|
V
|
V
|
V
|
Todos los casos de uso disponibles
|
ACW2.
|
Fuera de la red bancaria
|
V
|
V
|
I
|
Sólo caso de uso Retirada de dinero
|
ACW3.
|
No se puede leer la tarjeta
|
I
|
V
|
V
|
Mensaje de aviso, se expulsa la tarjeta
|
ACW4.
|
Se informa del robo de la tarjeta
|
I
|
V
|
V
|
Mensaje de aviso, se retiene la tarjeta
|
ACW5.
|
Tarjeta caducada
|
I
|
V
|
V
|
Mensaje de aviso, se retiene la tarjeta
|
En los sistemas distribuidos típicos puede haber varias combinaciones de hardware y software permitidas a las que se da
soporte. Se debe realizar la prueba para verificar si el destino de la prueba funciona o si se lleva a cabo de modo
aceptable en configuraciones diferentes como, por ejemplo, con velocidades de CPU, navegadores o sistemas operativos
diferentes. Además, la prueba también debe abarcar combinaciones de componentes para descubrir defectos que proceden de
interacciones de componentes diferentes, por ejemplo, garantizando que la versión de las DLL que instala una aplicación
no entran en conflicto con las versiones de las mismas DLL que espera otra aplicación.
Para derivar guiones de prueba para la prueba de configuración, utilice las directrices siguientes:
-
Asegúrese de que haya, como mínimo, un guión de prueba para identificar cada configuración crítica. Para ello, se
deben identificar las configuraciones de hardware y software necesarias para el entorno del destino de la prueba y
dar prioridad a las configuraciones, garantizando que las más comunes se prueban primero, incluidas:
-
Soporte de impresora
-
Conexiones de red - redes local y de área amplia
-
Configuraciones del servidor - controladores y hardware del servidor
-
Otro software instalado en el escritorio o los servidores
-
Versiones de software para todo el software instalado
-
Asegúrese de que haya, como mínimo, un caso de uso para cada configuración que pueda tener problemas. Pueden
incluir:
-
Hardware con el rendimiento más bajo.
-
Software coresidente que tenga un historial de problemas de compatibilidad.
-
Clientes que acceden al servidor a través de la conexión LAN/WAN más lenta posible.
-
Recursos insuficientes (baja velocidad de CPU, resolución o memoria mínima o espacio en disco, entre
otros).
La prueba de instalación debe verificar que se pueda instalar el destino de la prueba en todos los casos de ejemplo de
instalación posibles. Los casos de ejemplo de instalación pueden incluir la primera instalación del destino de la
prueba, o bien, la instalación de una compilación o versión más reciente del destino de la prueba (en una máquina que
contenga la versión anterior). La prueba de instalación también debe garantizar que el destino de la prueba se lleva a
cabo de modo aceptable en caso de producirse situaciones anómalas como, por ejemplo, espacio en disco insuficiente.
Los guiones de prueba deben cubrir casos de ejemplo de instalación para el software, incluidos:
-
Medios de distribución, por ejemplo, disquetes, CD-ROM o servidor de archivos.
-
Nueva instalación.
-
Instalación completa.
-
Instalaciones personalizadas.
-
Instalaciones de actualizaciones.
Los programas de instalación para software cliente-servidor tienen un conjunto especializado de guiones de prueba. A
diferencia de los sistemas basados en sistema principal, generalmente, el programa de instalación se divide entre el
servidor y el cliente. Por este motivo, es importante que la prueba de instalación lleve a cabo la instalación en todos
los componentes del destino de la prueba, incluido el cliente, las capas centrales y los servidores.
Lo más adecuado es que busque toda la entrada necesaria para derivar guiones de prueba al modelo de caso de uso , el
modelo de diseño y los artefactos de especificación suplementaria. No obstante, en este punto no es extraño que
necesite complementar lo encontrado.
Algunos ejemplos serían:
-
Guiones de prueba para pruebas operativas (para verificar que el software funciona cuando está en uso durante mucho
tiempo durante anomalías).
-
Guiones de prueba que investiguen cuellos de botella de rendimiento, posibilidades de volumen del sistema o tensión
del destino de la prueba para anomalías.
En la mayoría de casos, estos guiones de prueba se encuentran al crear variantes o agregados de los guiones de prueba
que se han derivado de los identificados previamente.
La prueba de aceptación del producto es la acción de prueba final antes de desplegar el software. El objetivo de la
prueba de aceptación es verificar si el software está preparado y lo pueden utilizar lo usuarios para realizar las
funciones y las tareas para las que se diseñó. Con frecuencia, la prueba de aceptación del producto implica algo más
que la ejecución del software para su estado de preparación, también implica todos los productos de trabajo que se
entregan al cliente como, por ejemplo, formación, documentación y empaquetado.
La derivación de guiones de prueba para los productos de trabajo de software se lleva a cabo del modo descrito en los
apartados anteriores. Dependiendo del grado y la formalidad de la prueba de aceptación del producto, los guiones de
prueba pueden ser los mismos o similares a los identificados más arriba (formales), o un subconjunto (informales).
Independientemente del nivel de los guiones de prueba, se debe alcanzar un acuerdo sobre los casos de uso y los
criterios de aceptación del producto antes de implementar y ejecutar la prueba del producto.
La evaluación de los productos de trabajo que no son software varía considerablemente en función del producto de
trabajo que se evalúa. Consulte las Listas de comprobación y las Directrices de cada producto de trabajo específico que
no sea de software para obtener información sobre qué y cómo evaluarlo.
Las pruebas de regresión comparan dos compilaciones o versiones del mismo destino de la prueba e identifican
diferencias como posibles defectos. Por lo tanto, dan por supuesto que una nueva versión se debe comportar como una
versión anterior y garantizan que no se incluyan defectos como resultado de los cambios.
Lo más adecuado es que todos los guiones de prueba de una iteración se utilicen como guiones de prueba en las
iteraciones posteriores. Las directrices siguientes se deben utilizar para identificar, diseñar e implementar guiones
de prueba que maximicen el valor de la reutilización y prueba de regresión, además de minimizar el mantenimiento:
-
Asegúrese de que el guión de prueba identifica sólo los elementos de datos críticos (los que se necesitan para
crear o dar soporte a la condición que se está probando)
-
Asegúrese de que cada guión de prueba describe o representa un conjunto exclusivo de entradas o secuencia de
sucesos cuyo resultado sea el comportamiento exclusivo del destino de la prueba
-
Elimine casos de uso redundantes o equivalentes
-
Agrupe los guiones de prueba que tengan el mismo estado inicial del destino de la prueba y el mismo estado de los
datos de prueba.
Una vez que se hayan tratado los guiones de prueba y exista una aprobación/acuerdo general para estos, se pueden
identificar los valores de datos con más detalle (es decir, en la matriz de implementación de guiones de prueba), y
crear los artefactos de datos de prueba.
Consulte el apartado Directriz: Datos de
prueba para obtener información adicional sobre la definición y el mantenimiento de datos de prueba.
|