Capítulo IV
Capítulo IV
Capítulo IV
“Por norma, los sistemas software no funcionan bien hasta que han sido utilizados y han fallado
repetidamente en entornos reales”
LO-4.1.3 Evaluar la calidad de los casos de prueba en términos de trazabilidad clara a los
requisitos y resultados esperados. (K2)
Esta sección, proceso de desarrollo de pruebas, cubrirá los siguientes conceptos clave:
El desarrollo o la especificación de las pruebas que deben ser ejecutadas pueden llevarse
a cabo en una secuencia sistemática de fases. El diagrama en esta figura muestra esos
métodos, asumiendo que usted está utilizando una estrategia analítica de pruebas basada en
los riesgos.
En primer lugar, tenemos el análisis para identificar las condiciones que deben ser
probadas. Si está utilizando una estrategia analítica de pruebas basada en los riesgos,
debería utilizar un análisis de los riesgos de calidad. Tenga en cuenta que los planes de
proyecto, los requisitos de producto y la especificación de diseño del sistema son todos
datos de entradas en el proceso del análisis de los riesgos de calidad. Nosotros
mantenemos la trazabilidad hacia atrás a los documentos fuentes—es decir, al plan de
proyecto, los requisitos o el diseño— para los riesgos de calidad que surgen de las
declaraciones específicas en aquellos documentos.
Producimos un juego de pruebas, un framework lógico para los casos de prueba. Además
capturamos la trazabilidad hacia atrás a la base de pruebas—en este caso los riesgos de
calidad.
Por último, el diseño de pruebas de nivel bajo o la implementación de las pruebas son
llevadas a cabo. Refinamos o elaboramos el diseño de pruebas en casos de prueba y luego
refinamos aquellos casos de prueba en procedimientos de prueba, también llamados
guiones de prueba. Otra vez, nos referimos a las especificaciones detalladas del diseño
como una entrada. Utilizamos también las pruebas existentes para la reutilización y los
estándares, como anteriormente. Las versiones tempranas del objeto de pruebas nos
permiten probar nuestras pruebas, si es que están disponibles. Y nuevamente, mantenemos
la trazabilidad de los casos y procedimientos de prueba hacia atrás a los riesgos de
calidad.
Tenga en cuenta que, en la medida de lo posible, hemos utilizado entradas externas como
los planes del proyecto y los requisitos para ayudarnos a crear los entregables internos, el
testware. Una estrategia de pruebas basada netamente en los requisitos necesita estos
entregables. Una estrategia analítica basada en los riesgos puede ser llevada a cabo sin
dicha documentación, sólo con la participación de los interesados del negocio en un
análisis de los riesgos. Sin embargo, la utilización de los requisitos y los documentos del
diseño conducen a análisis de riesgos más precisos.
Idealmente, al utilizar una estrategia analítica de pruebas para desarrollar las pruebas, el
proceso del análisis ocurrirá en paralelo con la especificación de los requisitos. Esto es
mostrado en esta figura por la cronología de las pruebas paralelas y el proyecto en la parte
superior e inferior de la figura, respectivamente.
Una vez más, en condiciones ideales, el diseño de las pruebas de alto nivel se produce en
paralelo con el diseño del sistema. Eso se muestra nuevamente en esta figura como
referencia.
Esta figura muestra que hemos identificado juegos de pruebas, basado en nuestro análisis
de riesgos de calidad. Un juego de pruebas es una colección lógica de casos de prueba.
Por ejemplo, usted puede tener un juego de pruebas de rendimiento, un juego de pruebas
funcionales, un juego de pruebas de manejo de errores, y así sucesivamente.
Para cada juego de pruebas, identificamos las condiciones de las pruebas y las
características que deben ser probadas. Esto es la parte del “qué” del juego de pruebas.
Para cada juego de pruebas, identificamos también el “cómo”, las estrategias, las
herramientas y las técnicas que utilizaremos para probar estas características.
Además, especificamos los criterios de paso/falla, los cuales son los medios por los que
vamos a determinar si una prueba pasó o falló. Por ejemplo, en el caso de un juego de
pruebas de rendimiento, podríamos tener una referencia a una declaración de requisitos,
que dice, que todas las actualizaciones de la pantalla deben ocurrir en medio segundo o
menos, cuando un usuario ingresa una entrada. Estos criterios de paso/falla son también
conocidos como “oráculos de pruebas”.
Al igual que antes, en condiciones ideales, el diseño de las pruebas de nivel bajo se
produce en paralelo con el ciclo de vida de desarrollo del sistema, en este caso la
implementación del sistema. (Por esta razón, en un párrafo anterior, pudimos hablar de
versiones tempranas del objeto de pruebas que está disponible durante el diseño de las
pruebas de nivel bajo, de tal forma que podamos poner a prueba las pruebas. Este
paralelismo es mostrado nuevamente en esta figura como referencia.
En el diseño de las pruebas de nivel bajo, creamos los casos de prueba específicos y
finalmente los procedimientos de prueba que cubren las condiciones de las pruebas
establecidas en el análisis de las pruebas y el diseño de las pruebas de alto nivel. Como se
muestra en esta figura, cada prueba se ajusta a la estructura de los juegos de pruebas, los
cuales son simplemente otra vez colecciones lógicas de casos de prueba.
Las flechas de los Riesgos de Calidad hacia los Casos de Prueba muestran la información
de la trazabilidad que vamos a capturar, relacionando las pruebas con los riesgos. Cada
riesgo que debe ser mitigado por medio de las pruebas, tendrá uno o más casos de prueba
asociados a éste. No hemos mostrado todos los trazos en esta figura. Tenga en cuenta que
algunos riesgos tienen más de un caso de prueba asociado con esos riesgos. En algunos
casos, una prueba se relaciona con múltiples riesgos. En la siguiente parte de esta sección,
usted verá por qué.
Vamos a comenzar con el riesgo. El Glosario del ISTQB se refiere al riesgo como a, “Un
factor que podría resultar en futuras consecuencias negativas, generalmente expresado en
su impacto y su probabilidad”. Bien, eso es un poco difícil de comprender, entonces aquí
tiene una definición más fácil de recordar e informal para el riesgo. La posibilidad de un
resultado negativo o indeseable.
Cada riesgo tiene algún impacto o daño potencial. Esa es la parte negativa o indeseable.
Suele incluir elementos tangibles e intangibles. Por ejemplo, supongamos que la red de
cajeros automáticos de un banco se pone inoperable por un día. Hay la pérdida inmediata y
tangible de los ingresos que sucederían por las transacciones no procesadas. Hay también
el efecto a largo plazo e intangible de la insatisfacción del cliente.
Cada riesgo tiene también alguna probabilidad de convertirse en un resultado. Esto suele
ser difícil o imposible de cuantificar, porque no tenemos el mismo tipo de datos actuariales
y válidos estadísticamente para los proyectos y los productos de software que las
compañías de seguros tienen. Sin embargo, intuitivamente podemos decir que la
probabilidad es mayor que 0; las imposibilidades no son riesgos. También, la probabilidad
es menor que 1 (o 100%); las certezas no son riesgos tampoco.
Ahora, en el programa de estudios del ISTQB, hablamos acerca de los riesgos de proyecto
y los riesgos de producto. Por el momento, nos enfocaremos en los riesgos de producto.
Una definición informal del riesgo de producto que es fácil de recordar es, la posibilidad
de que el sistema fallará para satisfacer a los clientes, los usuarios u otros interesados del
negocio. Los riesgos de producto se llaman también riesgos de calidad.
Éste es un punto importante, porque las pruebas basadas en los riesgos no tienen como
objetivo probar cada posible defecto. Tampoco, el análisis de los riesgos tiene como
objetivo identificar y evaluar cada posible defecto. En cambio, utilizamos los ítems de
riesgo—las condiciones de más alto nivel de las posibles fallas—para enfocar nuestras
pruebas. Los varios niveles de riesgo, a través de los ítems de riesgo, nos ayudan a
priorizar y a ordenar nuestras pruebas, para poder ocuparnos primeramente con las áreas
más riesgosas. Los varios niveles de riesgo nos dicen dónde debemos probar más y dónde
debemos probar menos, porque deberíamos invertir más esfuerzo en las áreas más
riesgosas. Por medio de las pruebas podemos detectar los problemas que de otra manera
afectan a los clientes, y podemos encontrar un porcentaje desproporcionadamente más alto
de los problemas más importantes. A medida que probamos, reducimos el nivel de riesgo
residual a la calidad del sistema y proporcionamos los resultados basados en los riesgos,
informamos al equipo del proyecto y les ayudamos a tomar decisiones acerca de las
versiones en base a información fundamentada.
Las pruebas basadas en los riesgos, cuando son realizadas correctamente, comienzan en las
etapas del inicio del proyecto. Por medio de un comienzo temprano, éstas proporcionan
oportunidades para reducir el riesgo de calidad a través del proyecto. Identificamos los
ítems específicos de los riesgos de calidad específicos, evaluamos su nivel de riesgo y
utilizamos esa información a través del proceso de pruebas. El conocimiento de los riesgos
y sus niveles de riesgo influencian la planificación y el control de las pruebas, la
especificación de las pruebas, la preparación de las pruebas y la ejecución de las pruebas.
Los riesgos identificados, junto con su nivel de riesgo asociado, pueden ayudar con muchos
desafíos de las pruebas, así como:
Las pruebas basadas en los riesgos son una actividad de equipo, involucrando a los
interesados del negocio a través del proyecto. Algunos interesados del negocio traen
experiencia técnica, conocimiento y percepción, mientras otros traen experiencia de
negocios, conocimiento y percepción. Esta experiencia colectiva, este conocimiento y esta
percepción permiten a los interesados del negocio realizar un trabajo riguroso y exacto de
la identificación de los riesgos, la evaluación del nivel de riesgo para cada ítem de riesgo
y la determinación de los niveles y el grado de cobertura de las pruebas para abordar
aquellos riesgos.
En los métodos más maduros para el desarrollo de software, las pruebas basadas en los
riesgos son parte de un método más amplio de gestión de riesgos. Las pruebas basadas en
los riesgos ayudan a reducir la probabilidad de falla del producto y dónde queda la
probabilidad de falla del producto, para reducir el impacto de los problemas en aquellas
áreas. Las pruebas basadas en los riesgos son un método disciplinado, para
metódicamente: evaluar (y reevaluar sobre una base regular) lo que pueda ir mal con el
software, determinar, utilizando el nivel de riesgo, cuáles riesgos son importantes para ser
abordados y las acciones que deben ser implementadas para abordar aquellos riesgos.
Tabla 4.1: ¿Cómo Podemos Analizar los Riesgos de Calidad?
Allá a finales de los años ochenta, cuando entramos en el negocio de las pruebas de
software de trabajos anteriores como programador y administrador de sistemas, la Única
Manera Verdadera de realizar las pruebas era con una estrategia de pruebas basada en los
requisitos. Durante el período de la preparación de las pruebas, un probador serio debía
analizar los requisitos, identificar las condiciones de las pruebas, diseñar e implementar
las pruebas para cubrir las condiciones de las pruebas y mantener la trazabilidad de las
pruebas hacia atrás a los requisitos.
Durante los períodos de la ejecución y los períodos exactos, el probador tenía que ejecutar
las pruebas e informar los resultados, incluyendo los informes en cuanto a los requisitos
cumplidos y no cumplidos basados en las pruebas.
En la década de los ochenta, ambos Boris Beizer y Bill Hetzel escribieron, en sus libros,
que el riesgo debería conducir las pruebas. Lamentablemente, no dejaron ningunas
instrucciones acerca de cómo hacerlo.
Siendo una persona quien preferiría adaptar en vez de inventar, buscó en las técnicas de
los años 90 en el mercado de las ideas. Afortunadamente, él tenía mucha experiencia con
los sistemas hardware/software, así que se encontró con el concepto del Análisis de
Modos de Fallas y Efectos. En esta técnica, usted utiliza un framework con categorías,
características de calidad (a la ISO 9126), o subsistemas. Usted luego trabaja con los
interesados del negocio clave para identificar los posibles modos de falla, predecir sus
efectos en el sistema, el usuario, la sociedad, etc. Basado en estos efectos, usted asigna la
severidad, la prioridad y la probabilidad. Usted calcula el número de prioridad del riesgo
(RPN) como el producto de estos tres valores.
Esto fue una revelación para él. El Análisis de Modos de Falla y Efectos resolvieron sus
problemas con las pruebas basadas en los requisitos. Porque esto dependió de la lluvia de
ideas de grupo o entrevistas de uno-a-uno, esto era inmune a que si recibió o no los
requisitos. (Por supuesto, si él hubiera recibido los requisitos, podía haberlos utilizado
como una entrada, pero no estaba comprometido con otro equipo para que fueran escritos).
El número de prioridad del riesgo le decía la cantidad del esfuerzo a dedicarle a la
preparación y la realización de las pruebas relacionadas con cada ítem de riesgo. El orden
de la prioridad del riesgo también le decía el orden en el cual debería ejecutar las pruebas.
Así, a lo largo de los años, hemos desarrollado un método ligero e informal que funcionará
en casi cualquier situación, aun conservando las principales ventajas del Análisis de
Modos de Falla y Efectos. Hemos desarrollado una lista de categorías clásicas de los
riesgos de calidad, así como la funcionalidad, los estados y las transacciones, la capacidad
y el volumen, la calidad de datos, el control de errores y la recuperación después de fallas,
el rendimiento, los estándares y la localización, la usabilidad, etc. Trabajando con los
interesados clave del negocio, identificamos los riesgos de calidad, luego establecemos la
prioridad para probar cada riesgo de calidad.
Si quiere algo un poco más formal, puede utilizar el ISO 9126 para estructurar su análisis
de los riesgos. Usted comienza con las seis principales características de calidad,
Funcionalidad, Fiabilidad, Usabilidad, Eficiencia, Mantenibilidad y Portabilidad. Luego,
las divide en sub características clave que aplican para su sistema, siguiendo el estándar
ISO 9126. Por último, identifica los ítems de los riesgos de calidad para cada
subcaracterística y establece la prioridad para probar cada riesgo, nuevamente trabajando
con los interesados clave del negocio.
A partir de la página siguiente, vamos a explicar la técnica informal. Sin embargo tenga en
cuenta que independientemente de la técnica, los aspectos más importantes son la
participación multifuncional de los interesados del negocio, el consenso, y una perspectiva
del mejor resultado posible.
En esta figura, usted puede observar una plantilla que puede ser utilizada para capturar la
información que usted identifica en el análisis de los riesgos de calidad.
El proceso del análisis de los riesgos de calidad consiste en las siguientes actividades. En
primer lugar, identificará los riesgos de calidad y luego evaluará sus niveles de riesgo.
Basado en el nivel de riesgo, determinará la prioridad general de las pruebas y el alcance
de las pruebas. Por último, si los riesgos surgen de los requisitos específicos o elementos
de la especificación del diseño, establezca la trazabilidad hacia atrás a estos ítems.
Examinemos estas actividades y cómo ellas generan la información para llenar esta
plantilla.
Primero, recuerde que los riesgos de calidad son problemas potenciales del sistema los
cuales podrían reducir la satisfacción del usuario.
Podemos utilizar una jerarquía de las categorías de los riesgos para organizar la lista y
para refrescar su memoria. Al trabajar con los interesados del negocio, identificamos uno o
más riesgos de calidad en cada categoría y llenamos la plantilla.
Una vez que los riesgos han sido identificados, ahora podemos volver atrás y evaluar el
nivel de riesgo, porque podemos ver los ítems de riesgo en relación con los demás.
Usualmente, utilizamos dos factores principales para la evaluación del riesgo.
La primera es la probabilidad del problema, que es influenciada en su mayor parte por las
consideraciones técnicas. Entonces, a veces lo llamamos “riesgo técnico” para recordarnos
de ese hecho.
El segundo es el impacto del problema, que está influenciado la mayor parte por las
consideraciones de negocios u operaciones. Entonces, a veces lo llamamos “riesgo de
negocios” para recordarnos de ese hecho.
Tanto la probabilidad como el impacto pueden ser evaluados en una escala ordinal así
como alto, medio y bajo. Nosotros preferimos utilizar una escala de cinco puntos, de muy
alto a muy bajo.
Teniendo en cuenta la probabilidad y el impacto, necesitamos una sola medida conjunta del
riesgo para el ítem de riesgo de calidad. Utilizamos la frase número de prioridad de riesgo
para esto, aunque no es exactamente el mismo término de FMEA (Análisis de los Modos
de Fallas y los Efectos). Para crear el número de prioridad de riesgo, combinamos la
probabilidad y el impacto. Una forma es traducir la escala ordinal en una escala numérica,
por ejemplo:
1 = Muy alto.
2 = Alto.
3 = Medio.
4 = Bajo.
5 = Muy bajo.
Entonces podemos calcular el número de prioridad de riesgo como el producto de los dos
números. Es más bien poco elegante, pero funciona. Siéntase libre de elaborar sus propias
fórmulas para el cálculo de este número si la simple multiplicación no funciona.
Ahora, el número de prioridad de riesgo puede ser utilizado para la secuencia de las
pruebas. Sin embargo, todavía necesitamos determinar el alcance de las pruebas. Una
forma de hacerlo es de dividir el número de prioridad de riesgo en cinco grupos y
utilizarlos para determinar el esfuerzo de la prueba:
1-5 = Extenso.
6-10 = Amplio.
11-15 = Superficial.
16-20 = Oportunidad.
Otra vez, siéntase libre para afinar estos grupos para que coincida con sus necesidades.
Mientras pasa por el proceso del análisis de los riesgos de calidad, es probable que usted
genere varios subproductos útiles. Estos incluyen los supuestos de la implementación que
usted y los interesados del negocio hicieron acerca del sistema en la evaluación de la
probabilidad. Usted querrá validar estos, y ellos podrían demostrar sugerencias útiles. Los
subproductos incluyen también los riesgos del proyecto que usted descubrió, los cuales el
director del proyecto puede abordar. Tal vez lo más importante es que los subproductos
incluyen los problemas con los requisitos, el diseño u otros documentos de entrada. Ahora
podemos evitar que estos problemas se conviertan en defectos reales del sistema. Observe
que los tres habilitan el rol preventivo de los defectos de las pruebas tratados
anteriormente en este libro.
Segundo, utilice un proceso de dos etapas: identifique los ítems de riesgo, a continuación
evalúe el nivel de riesgo. Los riesgos están relacionados entre sí, por lo tanto no puede
asignar el nivel de riesgo hasta que haya visto todos los riesgos.
Tercero, sea tan específico como necesite serlo, pero no más específico. Es decir, si está
considerando un ítem de riesgo y si este debería ser dividido en dos o más ítems de riesgo,
pregúntese: “¿Me ayudaría a distinguir entre los diferentes niveles de riesgo la separación
de estos ítems de riesgo en dos o más ítems de riesgo?” Si la respuesta es no, no los
divida.
Por último, entienda que este proceso es falible. Usted cometerá errores, en algunos casos
debido a la información limitada. Eso está bien, siempre y cuando haga el seguimiento y
vuelva a alinear el análisis de los riesgos con las pruebas y el proyecto en hitos clave del
proyecto.
La especificación del diseño de pruebas describe una colección de casos de prueba y las
condiciones de pruebas que abarcan en un nivel alto. Esta plantilla incluye las siguientes
secciones:
La secuencia de los juegos y casos de prueba dentro de los juegos de prueba es a menudo
dirigida por la prioridad del riesgo y el negocio. Por supuesto, la secuencia debe ser
afectada por las restricciones, los recursos y el progreso del proyecto.
Luego viene la Especificación del Caso de Prueba IEEE 829. Una especificación del caso
de prueba describe los detalles de un caso de prueba. Esta plantilla incluye las siguientes
secciones:
Identificador de la especificación del caso de prueba.
Ítems de pruebas (lo que tiene que ser entregado y probado).
Especificaciones de las entradas (entradas del usuario, archivos, etc.).
Especificaciones de las salidas (resultados esperados, incluyendo pantallas,
archivos, tiempo, etc.).
Necesidades del entorno (hardware, software, personas, accesorios…).
Requisitos especiales de procedimiento (intervención del operador, permisos,
etc.).
Dependencias entre casos (si es necesario para establecer condiciones previas).
Si bien esta plantilla define un estándar para los contenidos, la pregunta de lo que es un
caso de prueba es ciertamente una pregunta abierta. En la práctica, los casos de prueba
varían significativamente en esfuerzo, duración y número de condiciones de pruebas
cubiertas. Finalmente viene la Especificación del Procedimiento de Prueba IEEE 829. Una
especificación del procedimiento de prueba que describe cómo ejecutar uno o más casos
de prueba. Esta plantilla incluye las siguientes secciones:
Mientras que el estándar IEEE 829 distingue entre los procedimientos de prueba y casos de
prueba, en la práctica los procedimientos de prueba son a menudo embebidos en los casos
de prueba.
El glosario define la trazabilidad como “La habilidad de identificar los ítems relacionados
en la documentación y el software, así como los requisitos con las pruebas asociadas”.
Note que es otra manera de decir que estamos asociando la prueba con la base de pruebas,
lo cual es “la documentación en la cual los casos de prueba se basan”.
La cobertura es un concepto similar, relacionado con la medición de la relación y se la
define como “el grado en el cual un ítem específico de la cobertura ha sido ejercido por un
juego de pruebas”, donde un ítem de la cobertura puede ser cualquier cosa en la que
estemos interesados en cubrir con las pruebas.
Hay muchas maneras de medir la cobertura en el uso común. Para las estrategias basadas
en los requisitos, planificaríamos medir principalmente contra las especificaciones de los
requisitos. Para las estrategias de pruebas más amplias, podríamos también medir contra
las especificaciones del diseño.
Para las estrategias basadas en los riesgos, medimos principalmente contra los riesgos,
aunque también tenemos la trazabilidad de los riesgos hacia atrás a las especificaciones de
los requisitos y el diseño. Cuando la interoperabilidad es un tipo de pruebas importante,
también podría medir la cobertura de las configuraciones, las interfaces y otros también.
Hemos ilustrado una técnica para capturar la cobertura en esta figura. Podemos utilizar una
hoja de cálculo para mostrar el caso de prueba horizontalmente a través de la parte
superior y la especificación de los requisitos verticalmente en el lado izquierdo hacia
abajo. Cada celda contiene una medida del grado de cobertura que un caso de prueba dado
proporciona para un elemento de especificación dado.
Sin embargo la realidad es, que usted no lo haría probablemente de esta manera. Para un
sistema grande, puede tener cientos de elementos en su base de pruebas, y cientos de casos
de prueba. Eso resulta en una hoja de cálculo con diez miles, algunas veces cientos de
miles de celdas que hacen el seguimiento. Introduciendo la información errónea en tal hoja
de cálculo es muy posible y es una pesadilla de mantener. El mejor método es utilizar una
base de datos. Esas bases de datos son la parte esencial de las herramientas de gestión de
pruebas que pueden capturar la información de la trazabilidad.
4.1.1 Ejercicios
Ejercicio 1
Basado en su lectura del Documento de los Requisitos de Marketing de Omninet, el
Documento de los Requisitos del Sistema Omninet y su experiencia con las pruebas y los
defectos, realice un análisis de los riesgos para Omninet.23
Argumente.
Otra equivocación común que la gente comete en el análisis de los riesgos es olvidar que
los riesgos no sólo se relacionan con la funcionalidad, sino también con el rendimiento, la
seguridad, la privacidad y otras características de calidad no funcionales.
Al realizar el análisis de los riesgos, usted tuvo que tener cuidado de mantener todos los
riesgos en la perspectiva mientras se asignaron los niveles de riesgo. De otra manera
habría tenido t una inflación de riesgos, donde todo sea calificado como de riesgo alto.
También debería haber estado listo para hacer algunas suposiciones razonables de la
implementación. Porque no todos los probadores son expertos técnicos, incluyendo los
tecnólogos en el proceso del análisis de los riesgos, quienes puedan llenar estos espacios
en blanco es esencial.
Para revisar el proceso, primero debería haber identificado los riesgos, después
priorizarlos. Una vez que tuviera una prioridad agregada, debería haber utilizado esa
prioridad para guiar el grado de cobertura de las pruebas en cada área de riesgo. En el
libro sugerimos que utilice cinco niveles del grado de cobertura:
Pruebas extensivas. Probar el área entera del riesgo, con muchas variaciones.
Pruebas amplias. Probar el área entera del riesgo, pero con pocas variaciones.
Pruebas superficiales: Probar una muestra del área del riesgo, explorándola
brevemente.
Pruebas de oportunidad. Probar el área del riesgo sólo si alguna otra prueba lo
lleva a usted al área.
Informar defectos. Si ve problemas en esta área del riesgo, infórmelos, pero no
haga nada más.
A medida que trabajó a través del Documentos de los Requisitos de Marketing de Omninet
y el Documento de los Requisitos del Sistema Omninet, descubriendo los riesgos
asociados con cada área, debería haber retenido la información de la trazabilidad entre la
sección de los documentos y los riesgos asociados. Esta información de la trazabilidad es
útil para el diseño de pruebas y la creación de los informes de resultados.
En la tabla 4.2, proporcionamos nuestra solución para el ejercicio del análisis de los
riesgos de calidad. En el material que sigue a la tabla, damos algunas observaciones
acerca de nuestra solución así como también algunos hallazgos interesantes que ocurrieron
cuando pasamos por el proceso del análisis de los riesgos de calidad.
Tabla 4.2: Solución-Análisis de los Riesgos de Calidad de Omninet.
Para algunos riesgos, hemos desviado el grado de cobertura de las pruebas de lo que el
número total de prioridad de riesgo sugeriría. Por ejemplo, hemos asignado las pruebas de
oportunidad para “el cierre de sesión del usuario falla”, la cual tenía un número de
prioridad de riesgo 10. ¿Por qué? Porque es una tarea de programación simple, lo más
probable, y puede realizar fácilmente su prueba de integración en algunas otras pruebas.
¿Puede detectar los otros riesgos para los cuales hemos desviado el grado de cobertura de
las pruebas? ¿Puede darse cuenta por qué? La documentación de esas decisiones y las
suposiciones es probablemente lo mejor. Sin una explicación como la que está en el
párrafo de arriba, es difícil de saber nuestro razonamiento.
Note que la relación entre los riesgos de calidad y los elementos de la especificación de
los requisitos es de muchos-a-muchos. Un requisito se puede relacionar con múltiples
riesgos. Eso está bien. Un riesgo se puede relacionar con múltiples requisitos. Eso está
bien, también, en números pequeños. Sin embargo, si encuentra que tiene demasiados
requisitos asociados con un riesgo, usted probablemente no está siendo lo suficientemente
específico. Por ejemplo, “el sistema no funciona” se relacionaría a cualquier requisito,
pero no le ayuda a darse cuenta a dónde enfocar sus pruebas.
A medida que priorizamos los riesgos, nos dimos cuenta que algunos ítems que habíamos
incluido, como dos riesgos, se plegaron en un sólo riesgo. Por ejemplo, “Los agentes del
centro de llamadas no pueden acceder/controlar las sesiones actuales”, eran originalmente
dos ítems en una línea cada uno, uno relacionado con el acceso y el otro con el control.
Cuando vimos que tenían los mismos números de riesgo de prioridad, entonces los
combinamos. Tomamos ventaja de esos descubrimientos para mantener las tablas del
análisis de los riesgos tan cortas como era posible.
Porque solamente realizamos este análisis, estamos seguros que pasamos por alto algunos
riesgos importantes. Los equipos multidisciplinarios que trabajan juntos no tienden a pasar
por alto tantos riesgos.
¿Cuáles defectos encontró en los requisitos? Es un buen beneficio secundario del análisis
de los riesgos de calidad que sirve como una forma estructurada de revisión de los
requisitos.
Ejercicio 2
Basado en su análisis de los riesgos de calidad para Omninet, esquematice un conjunto de
juegos de prueba para abordar las áreas importantes de los riesgos.
Establezca la relación entre sus juegos de prueba y los riesgos que serán cubiertos.
Basado en su análisis de los riesgos, ¿Cómo secuenciaría los juegos de prueba? ¿Qué otras
consideraciones afectarían la secuenciación de los juegos de prueba?
Argumente.
Note que hemos agrupado los juegos de prueba en grupos de secuencia que serían
ejecutados en paralelo y en orden por los probadores. Si tuviera que haber orden dentro de
un grupo, éste emergería de las restricciones logísticas como la disponibilidad de los
probadores o del material de trabajo. Las restricciones logísticas podrían también resultar
en un juego de prueba siendo ejecutado en paralelo con las pruebas en otro grupo de
secuencia.
Las pruebas no están perfectamente en el orden de los riesgos, porque decidimos probar la
funcionalidad individual, antes de empezar con pruebas más complejas. Idealmente, estas
pruebas serían empujadas a las etapas tempranas de pruebas y repetidas sólo como
criterios de entrada para la prueba de sistema.
LO-4.2.2 Explicar las características, cosas en común, y diferencias entre las pruebas
basadas en la especificación, las pruebas basadas en la estructura y las pruebas basadas en
la experiencia. (K2)
Esta sección, Categorías de las Técnicas de Diseño de Pruebas, cubrirá los siguientes
conceptos clave:
Algunas pruebas pueden ser clasificadas como basadas en la estructura, también llamadas
pruebas de caja blanca. Esto es cuando creamos principalmente las pruebas por medio del
análisis de la estructura del componente o sistema. Cuando éstas fallan, estas pruebas
revelan típicamente los defectos en la manera en la cual el sistema está construido.
Algunas pruebas pueden ser clasificadas como basadas en la experiencia, así como las
basadas en los ataques, las basadas en las listas de comprobación y las exploratorias.
Pruebas negativas: Pruebas con el objetivo de mostrar que una componente o sistema no
funciona. Las pruebas negativas están relacionadas con la actitud de los probadores más
que un método de pruebas específico o una técnica de diseño de pruebas, p.ej. las pruebas
con valores de entrada inválidos o excepciones. Note que este término no es
específicamente enunciado para esta sección pero es incluido aquí ya que está relacionado
con el término ataque de defectos.
Esto es cuando creamos las pruebas principalmente basadas en la comprensión del sistema,
la experiencia pasada y las suposiciones con cierta base acerca de los defectos. Cuando
fallan, estas pruebas revelan típicamente loas defectos en los lugares en los que otros
sistemas tienen defectos. Sin embargo, debido a la falta de documentación, estas pruebas a
menudo no construyen la confianza en el sistema, porque la cobertura es difícil de medir.
Las pruebas basadas en la estructura o pruebas de caja blanca, presentan algunos elementos
básicos comunes. Primero, utilizaríamos las estructuras del sistema para derivar los casos
de prueba, por ejemplo el código y diseño. Estas estructuras incluyen el código mismo, las
tablas de base de datos, las consultas o las relaciones y el diseño del sistema. El siguiente
paso típico sería que usted mida el grado de cobertura estructural para otros casos de
pruebas existentes, así como las pruebas basadas en la especificación o las pruebas
basadas en la experiencia. A continuación, si se justifica, utilizaríamos más casos de
prueba que pueden derivarse de forma sistemática para aumentar la cobertura
Cobertura de sentencias.
Cobertura de ramas o decisión.
Ataques.
Listas de comprobación.
Exploratorias.
4.2.1 Ejercicios
Ejercicio 1
Refiérase a su esquema de juegos de prueba para Omninet.
Para cada juego de prueba, identifique si una, dos o todas de las siguientes tres categorías
de las técnicas de pruebas serian útiles en el diseño de los casos de prueba:
Argumente.
Ejercicio 2
Usted está probando un sistema de comercio electrónico que vende chucherías como
gorras, camisetas de baseball etc. El ejercicio consiste en crear pruebas funcionales para
la página Web que acepta los pedidos. Una pantalla prototipo de la página Web para las
entradas de los pedidos es mostrada en la figura 4.7.24
Figura 4.7: Plantilla de la página Web para las entradas de los pedidos del
comercio electrónico de Omninet.
El sistema acepta una cantidad que debe ser pedida, del 1 al 99. Si el usuario ingresa un
Identificador de ítem previamente pedido y una cantidad 0, ese ítem es retirado del carrito
de compras.
Basado en estas entradas, el sistema recupera el precio del ítem, calcula el total del ítem
(la cantidad de veces el precio), y adiciona el total del ítem al total del carrito. Debido a
los límites de los pedidos con tarjetas de crédito, el máximo total para el carrito es de US$
999,99.
Figura 4.8: Clases de equivalencia y valores límite para el Identificador del ítem
La otra manera de pensar acerca de este campo es que éste es como una cadena de
caracteres que deben ser exactamente 5 caracteres de largo y consistir solamente de dígitos
decimales. En ese caso, la representación gráfica colocada abajo en la figura tiene sentido.
Querrá probar una cadena realmente, realmente larga (para hacer un desborde de búfer),
una cadena de 6 caracteres como “100000”, (inválida solo por el largo), dos cadenas de
cinco caracteres como “31:75” y “27/86” (inválida porque no es una cadena que consta
solamente de dígitos decimales), una cadena de 4 caracteres como “9999” (inválida sólo
por el largo), una cadena de cero caracteres como una cadena nula: “” (usualmente una
entrada de carácter interesante), y dos cadenas de cinco caracteres como “00000” y
“99999”.
¿Cuál representación es correcta? Bien, si usted puede preguntar al programador cómo está
implementado el campo, usted podría probarlo según lo que él le diga. Sin embargo, no lo
hace más dificultoso asumir que ambos podrían estar correctos y probarlo de ambas
maneras. En ese caso, si la implementación cambia, sus pruebas cubrirán todos los casos
interesantes.
Dibujamos las clases de equivalencia y los valores límite para las cantidades pedidas
como es mostrado en la figura 4.9. Observe cómo el valor cero es a veces válido y a veces
inválido, dependiendo de que si el Identificador del ítem ha sido previamente ingresado.
Figura 4.9: Clases de equivalencia y valores límite para las cantidades pedidas.
Las entradas, las acciones y los resultados esperados de las pruebas son mostrados en las
tablas de abajo.
Tabla 4.5: Solución-Casos de Prueba
Hemos asumido que el sistema aceptará el Identificador del ítem ya sea como entero (sin
ceros por delante) o como un campo de cinco caracteres con caracteres numéricos
solamente (con ceros por delante). Esa es la manera permisiva de definir el sistema, y
pensamos que los sistemas deberían ser permisivos cuando sea posible.
Hemos instruido a los probadores que confirmen los precios, probablemente utilizando un
catálogo en papel o una lista de precios y una calculadora. Cuando un oráculo fiable de
pruebas sea fácilmente de obtener y cambiante en el tiempo, es mejor no introducir
redundancia y discrepancias en última instancia por medio de la codificación en duro del
resultado esperado en el caso de prueba. En cambio, puede hacer una nota para comprobar
el resultado esperado durante la ejecución de las pruebas y posiblemente proporcionar
alguna información acerca de dónde encontrar el oráculo de pruebas.
En la prueba 3, podríamos haber notado que estamos asumiendo que usted puede pedir 100
(o más) de un solo ítem simplemente ingresando dos pedidos. ¿Debería estar bien eso?
Bien, si el objetivo del límite es prevenir que la gente pida accidentalmente demasiados de
un solo ítem, forzando al usuario a ingresar dos pedidos hace obvio que la gran cantidad de
pedidos es intencionada. Si el sistema rechazó este valor con un mensaje como, “Lo siento,
pero usted sólo puede pedir una cantidad total de 99 de cualquier ítem dado”, entonces lo
más probable es que no sería un error. Sin embargo, necesitaría de adicionar otra prueba
donde usted pediría la cantidad de 99 de un ítem en un sólo pedido.
También en la prueba 3, el “+” por delante en el total del carrito indica que usted debería
esperar el total del carrito para incluir el total previo del carrito mas la adición del total
del ítem para este ítem. En la prueba 4, el “=” por delante en el total del carrito indica que
usted debería esperar que el total del carrito no sea modificado del total anterior del
carrito.
En la prueba 5, estamos asumiendo que el total del ítem para este ítem—el más costoso en
el catálogo— junto con los 100 ítems menos costosos, no excederá el límite total del
pedido de US$ 999,99. Si excede, entonces nosotros posiblemente tendríamos que eliminar
ítems del carro o pasar a pagar antes de ejecutar la prueba 5.
Note que hemos ejercido los valores límite sobre las acciones y las salidas, no sólo
entradas. Por ejemplo, la prueba 6 verifica el pago con un sólo ítem en el carrito. Las
pruebas 7 y 9 verifican el intento de pago sin ítems en el carrito. La prueba 7 debería
resultar en dos mensajes de error, uno por un Identificador incorrecto del ítem y uno por el
intento de pago con el carrito vacío. La prueba 9 debería resultar en un mensaje de error
individual por pagar con el carrito vacío. Otras pruebas verifican el pago con múltiples
ítems en el carrito.
En la prueba 13, hemos asumido que ingresando un Identificador del ítem y una cantidad
válida para algo que ya está en el carrito de compras, se adiciona al total para ese ítem.
Sin embargo, éste podría sobrescribir el total. Sin una clara explicación de por qué el
sistema debería sobrescribir en vez de añadir al total, nosotros informaríamos eso como un
defecto. Como un usuario, esperaríamos que se adicione, no se sobrescriba, así que la
decisión estará reflejada en nuestra interpretación del resultado de la prueba.
No existe un límite establecido acerca de cuántos ítems pueden estar en el carrito, pero
existe un límite establecido acerca el costo total de los ítems. Eso está cubierto por las
pruebas 18 y 19. En la prueba 18, el sistema debería permitirnos comprar US$ 999,99 en
valor total de ítems. En la prueba 19, el sistema debería rechazar el último ítem que
adicionamos—ése que pone el total de nuestro carrito tan cerca como sea posible a US$
1.000,00— pero debería permitirnos comprar los otros ítems que ya hemos añadido a
nuestro carrito.
Hasta cierto punto, este ejemplo deja al criterio del probador o la especificación de los
requisitos las preguntas de que si sería correcto un punto decimal al estilo europeo o un
símbolo de moneda en el resultado. Usualmente preferimos tener probadores inteligentes
que tomen estas decisiones a medida que ellos ejecutan las pruebas. De esa manera, si
después el sistema se ubica en otro local, entonces no necesitamos cambiar las pruebas.
Ejercicio 3
Refiérase a la tabla de decisión de los pagos en el Documento de los Requisitos del
Sistema Omninet.25
Argumente.
También necesita considerar el análisis de los riesgos. En un ejercicio del análisis de los
riesgos de calidad, identificamos el “pago válido rechazado/pago inválido aceptado” como
un riesgo técnico muy bajo pero como un riesgo de negocios muy alto. Basado en eso,
decidimos que este ítem de riesgo debería recibir pruebas amplias.
¿Se recordó usted de referirse a su análisis de los riesgos de calidad para guiarse acerca
de cómo debería probar rigurosamente esta función? Si está realizando pruebas basadas en
los riesgos, eso es importante. Usted fácilmente puede desalinear sus pruebas con el nivel
de riesgo durante el diseño y el desarrollo de las pruebas. En esos casos, probará en
exceso algunos ítems de riesgo bajo y probará demasiado poco algunos ítems de alto
riesgo. En el capítulo posterior acerca de la trazabilidad, examinaremos una manera de
comprobar para asegurar que sus pruebas permanecen alineadas con su evaluación de los
riesgos durante el diseño y el desarrollo de las pruebas. En las pruebas basadas en los
riesgos, su análisis de los riesgos de calidad es su guía básica.
Por supuesto, su evaluación de los riesgos puede cambiar durante el proyecto. Si, durante
el diseño, el desarrollo o la ejecución de pruebas, usted obtiene nueva información o
percepciones que le dicen que la evaluación de los riesgos está incorrecta, usted debería
revisar la evaluación de los riesgos en vez de seguir una guía básica incorrecta.
Las pruebas amplias para esta tabla de decisión, significan que cada condición en la tabla
de decisión sea cubierta (véase la tabla 4.7). Las reglas 5 y 6 involucran una condición
compuesta, “PIN válido (para débito) o PIN no requerido (para tarjeta de crédito)”.
Entonces necesitamos una prueba para cada una de las reglas desde la regla 1 a la 4,
mientras que las reglas 5 y 6 necesitan dos pruebas cada una.
Tabla 4.7: Solución-Pruebas del Proceso de Pagos de Omninet
Desde el punto de vista de las pruebas, quisiéramos probar en ambas maneras que la
condición no podría ser cumplida en la regla 5. Sin embargo, por que no hay razón para
pensar que el uso de una tarjeta de crédito o débito influenciaría en la lógica del quiosco
en cuanto a períodos de tiempo válidos, no hay necesidad de incrementar el número de
pruebas para intentar todas las permutaciones.
Desde el punto de vista del diseño del sistema, pudimos prevenir el problema utilizando
una lista desplegable para pedir al usuario una cantidad. La lista solo contendría
cantidades válidas.
Otra cuestión de prueba es que necesitaremos algunos accesorios para esta prueba.
Necesitamos por lo menos una tarjeta de débito válida y una tarjeta de crédito válida. Estas
tarjetas deben estar enlazadas a las cuentas que tengan los saldos apropiados. Obtener este
tipo de accesorios de pruebas es a menudo difícil, entonces usted debería empezar a ver la
forma cómo conseguirlos tan pronto como se entere que los necesitará.
Ejercicio 4
Los quioscos públicos de acceso al Internet de Omninet, pueden estar en varios estados,
basados en la recepción de los pagos, las sesiones activas y así sucesivamente.26
Argumente.
Usted también pudo dibujar un diagrama más simple como algunos lo hacen, dejando de
lado las acciones de inicialización así como también las de filtrado.
Observe que el modelo ve el mundo desde el punto de vista del quiosco. Las transiciones
en este diagrama están definidas en el Documento de los Requisitos de Marketing y el
Documento de los Requisitos del Sistema.
Figura 4.10: Diagrama de Transición de Estados del Quiosco
Asumimos que el informe de los estados por hora para el servidor debería ocurrir en
segundo plano. También asumimos que el registro de los eventos de seguridad ocurre en
segundo plano. Estos involucrarían diagramas de transición de estados diferentes. El
diagrama mostrado, sólo aborda los eventos y las actividades en primer plano.
Elegimos representar las actividades del pago como estado único. También pudimos haber
dividido esto en una secuencia de estados. Cuando está utilizando las técnicas de pruebas
basadas en los estados, algunas veces tenemos que elegir dónde enfocar las pruebas y
dónde simplificar.
La diferencia básica entre cubrir el diagrama y cubrir la tabla es que la tabla toma en
cuenta las situaciones que “no pueden ocurrir” y “no deberían ocurrir”. Donde se necesiten
pruebas extensivas o control considerable de errores y pruebas de robustez, entonces usted
debería planificar para cubrir la tabla.
Finalmente, hemos creado los escenarios de las pruebas para cubrir el diagrama de
transición de estados. Recuerde que la regla de cobertura para el diagrama de transición de
estados es visitar cada estado y atravesar cada transición. Una vez que recibimos la
información acerca de cómo debieron ser tratadas las situaciones indefinidas en la tabla,
nosotros añadiríamos éstas como escenarios adicionales.
Tabla 4.8: Solución-Pruebas de estado del quiosco
Si puede automatizar las pruebas—que podría en este caso resultar algo desafiante— usted
podría tener una herramienta que continuamente navegue a través de los estados, creando
ambas combinaciones de estados/eventos definidas e indefinidas, para ver cómo se
comporta el sistema. Usted puede descubrir problemas de agotamiento de memoria,
bloqueos y caídas intermitentes, y otros tales defectos con tales pruebas.
LO-4.3.2 Explicar el propósito principal de cada una de las cuatro técnicas, cuál nivel y
tipo de pruebas podría utilizar la técnica y cómo la cobertura puede ser medida. (K2)
LO-4.3.3 Explicar el concepto de las pruebas de casos de uso y sus beneficios. (K2)
Valor límite: Un valor de entrada o valor de salida el cual se encuentra en el borde de una
partición de equivalencia o en la distancia incremental más pequeña en cada lado de un
borde, por ejemplo, el valor mínimo o máximo de un rango. Tenga en cuenta que este
término no se enunció específicamente para esta sección, pero se lo incluye aquí, ya que es
esencial para comprender el término análisis de valor límite.
Pruebas de tabla de decisión: Una técnica de diseño de pruebas de caja negra en la cual
los casos de prueba son diseñados para ejecutar las combinaciones de entradas y/o
estímulos (causas) representadas en una tabla de decisión. Véase también tabla de
decisión.
Tabla de decisión: Una tabla que muestra las combinaciones de entradas y/o estímulos
(causas) con sus productos y/o acciones (efectos) asociados, los cuales pueden ser
utilizados para diseñar casos de prueba. Tenga en cuenta que este término no se enunció
específicamente para esta sección, pero se lo incluye aquí, ya que es esencial para
comprender el término prueba de tablas de decisión.
Pruebas de transición de estados: Una técnica de diseño de pruebas de caja en la cual los
casos de prueba son diseñados para ejecutar transiciones de estado válidas e inválidas.
Véase también pruebas de conmutador de multiplicidad.
Pruebas de casos de uso: Una técnica de diseño de pruebas de caja negra en la cual los
casos de prueba son diseñados para ejecutar los escenarios de los casos de uso.
Típicamente, para cualquier conjunto dado de casos de prueba que necesita construir,
necesita usualmente probar más de una entrada, salida, comportamiento, etc. Entonces,
repetirá este proceso de identificar y particionar27 (“to partition”) conjuntos hasta que haya
creado las particiones de equivalencia para todas las entradas, salidas, comportamientos, y
así sucesivamente.
Ahora, en este punto, usted crea sus casos de prueba. Para construir las pruebas para las
entradas, las salidas, las configuraciones o las opciones válidas o lo que sea con lo que
esté trabajando, seleccione un valor de cada partición de equivalencia válida, a
continuación defina el resultado esperado en esa situación. Repita este proceso hasta que
haya seleccionado al menos un valor representativo para cada partición de equivalencia
válida en todas las clases de equivalencia que ha creado.
Note que hemos dicho al menos una vez. Hay muchos casos donde podría seleccionar más
de un valor representativo. Por ejemplo, en el caso de las clases definidas en conjuntos que
están ordenados, podría seleccionar dos valores para cada clase, específicamente aquellos
en el límite superior e inferior de cada clase. Estos valores se denominan valores límite, y
hablaremos más acerca de esta técnica en un momento.
Para construir las pruebas para las entradas, las salidas, las configuraciones o las opciones
de ajuste inválidas o lo que sea con lo que esté trabajando, seleccione un valor de una—y
sólo una—partición inválida de equivalencia. Para el resto de las particiones de
equivalencia, seleccione un valor válido. La razón de esta regla es que, si prueba valores
inválidos juntos, no podrá estar seguro de que una entrada, salida, comportamiento o lo que
sea por alguna razón específica serán tratados correctamente. Por supuesto, si sospecha
que ciertos valores inválidos van a interactuar, puede añadir pruebas para ello, pero
asegúrese de que también ha probado individualmente cada valor inválido.
Después que ha seleccionado los valores válidos e inválidos, como antes, usted define el
resultado esperado en esa situación. Usted repite este proceso hasta que se haya
seleccionado al menos un valor representativo para cada partición de equivalencia
inválida en todas las clases de equivalencia que ha creado.
¿Qué tal un ejemplo? Suponga que usted está probando impresoras compatibles para una
aplicación.
Otra forma de crear particiones del conjunto de impresoras se basa en la interfaz lógica, es
decir, ¿Cómo son los datos enviados a la impresora, empaquetados de manera compacta,
en algún flujo importante? Algunas impresoras utilizan PostScript para recibir datos,
algunos HPPL, algunos ASCII, y algunos utilizan otros formatos.
Hay algo bueno acerca de las pruebas de valores límite, cuando pueda hacerlo. Observe
que el particionamiento de equivalencia puede encontrar defectos en el código que maneja
cada partición de equivalencia. En otras palabras, ¿Se comporta el programa de la manera
Y cuando debería comportarse de la manera X? Sin embargo, un valor arbitrario de la
partición de equivalencia no comprueba necesariamente para ver que el programa
reconoce correctamente los miembros de la partición de equivalencia. Los valores límite,
porque comprueban los límites y son miembros de las clases de equivalencia, pueden
también encontrar defectos en el código que define los límites—las diferencias entre una
partición equivalente y la que está justo por debajo o encima de ésta. En otras palabras,
¿Muestra el programa un comportamiento Y cuando debería mostrar el comportamiento X,
o piensa éste que está tratando con la partición de equivalencia B cuando éste debería
reconocer esta situación como perteneciente a una partición de equivalencia A?
Ahora, note que sólo podemos utilizar el análisis de valores límite cuando los elementos
de la partición de equivalencia son ordenados. En otras palabras, tenemos que ser capaces
de hablar de un valor que es mayor que o menor que otro valor.
Examinemos las particiones de equivalencia y los valores límite para un campo entero.
Suponga que usted está probando un sistema de comercio electrónico. Un campo que
necesitaría probar es el que le permite a alguien especificar la cantidad de un ítem que
quiere pedir. Supongamos que su sistema permitirá que alguien pida máximo hasta 99 de
cualquier ítem dado, y que los ítems sean ítems indivisibles como libros, no ítems como la
harina que se pueden vender en casi cualquier cantidad.
Esta regla significa que los valores del 1 hasta el 99 son la partición de equivalencia
válida. Si es introducido un valor de 0 o menos, que es inválido, entonces aquellos valores
forman la partición de equivalencia inválida demasiado baja. Si un valor de 100 o más es
introducido, el cuál es inválido, entonces aquellos valores forman la partición de
equivalencia inválida demasiado alta.
Note que hay otros dos valores límite, que no se muestran aquí: el miembro más pequeño
de la partición de equivalencia inválida demasiado baja y el miembro más grande de la
partición de equivalencia inválida demasiado alta. Le podría ser difícil de identificar estos
valores extremos, porque ellos dependen de la representación interna de los números
enteros de la computadora, el número máximo de dígitos que puede ingresar en un campo, y
otras restricciones parecidas. Sin embargo, debería hacer un esfuerzo para probarlos,
porque los valores extremos son un lugar común donde se ocultan los defectos.
Para algunos esto podría ser suficientemente bueno, pero no para nosotros. Observe, la
partición de equivalencia válida incluye tanto los números positivos como los negativos y
el cero. Lo que sea que la especificación diga o no diga acerca del manejo diferente de
estos valores, nosotros sabemos que los programadores cometen errores en tales
situaciones—en parte porque nosotros solíamos trabajar como programadores y todavía
programamos y sabemos que hemos cometido esos errores. Entonces, vamos a
subparticionar la partición de equivalencia válida en tres subparticiones o subclases:
válido negativo; válido cero, y válido positivo.
¿Qué tan lejos podemos ir con el subparticionamiento? ¡Tanto así como lo necesitamos o
queramos! Mientras sigan existiendo interesantes valores de pruebas, que se ocultan en una
partición de equivalencia, podemos subparticionar esa partición para tratar de revelarlos.
Note, también, que en la figura 4.11 y la anterior, hemos dejado de lado toda una dimensión
del particionamiento, la cual es para las entradas las cuales no son ni números enteros o ni
decimales válidos en absoluto. Las entradas no numéricas para este campo decimal podría
incluir letras, espacios en blanco, signos de puntuación, caracteres de control y nulos. Para
un campo entero, podemos añadir números decimales en las entradas rechazadas, aunque
ellos sean números.
Figura 4.13: Carácter y Cadena de Texto
Esta argumentación acerca de las entradas más generales nos lleva al análisis de caracteres
y cadenas de texto. Suponga que está probando una característica de seguridad que
requiere contraseñas alfanuméricas de entre 6 y 10 caracteres de largo.
Podemos imaginar dos dimensiones del particionamiento, una basada en la longitud, una en
los caracteres de la contraseña. Tenga en cuenta que esta figura mental crea una región
válida en la gráfica, junto con cuatro regiones en las cuales la contraseña es inválida por
exactamente una razón: longitud ilegal o caracteres ilegales.
También tenemos cuatro regiones en las cuales la contraseña es inválida por exactamente
dos razones: longitud no permitida y caracteres no permitidos. ¿Necesitamos probar estas?
Bueno, tal vez.
Recuerde que las pruebas implican la selección de un subconjunto finito de pruebas que
deben ser ejecutadas a partir de un conjunto infinito de pruebas que usted podría ejecutar.
Debido a las restricciones de tiempo y dinero, la selección de una prueba significa por lo
general la deselección de alguna otra prueba. Por lo tanto, antes de que salgamos corriendo
hacia la gran nube infinita de pruebas que posiblemente podríamos ejecutar, haga memoria
en su análisis de los riesgos y pregúntese usted mismo si el nivel de riesgo asociado con
este caso de prueba justifica pruebas extensas.
DD/MM/YY
Examinemos las particiones de equivalencia y los valores límite para un campo fecha.
Suponga que usted está probando una aplicación web que le permite reservar pasajes de
avión en línea.
Un campo que necesitaría probar es el que permite a alguien especificar la fecha de salida.
Segundo, ¿Es la fecha válida en esta situación determinada? En otras palabras, ¿Es esta
fecha válida tomando en cuenta lo que le estamos pidiendo al programa que haga con esta?
Una fecha en el pasado, por ejemplo, no es una fecha válida, si estamos tratando de
especificar una fecha de salida para un vuelo que queremos reservar. Por el contrario, una
fecha en el futuro no es una fecha válida, si estamos tratando de especificar nuestra fecha
de nacimiento.
HH:MM:SS
Continuando con nuestro sistema web de reserva de vuelos, suponga que examinamos un
campo para el horario que nos pide la hora de salida preferida.
Una vez más, tenemos dos dimensiones interesantes de validez. La primera es el horario
como un valor de tiempo. Los horarios, como las fechas, son campos que normalmente
consisten en subcampos. El número de subcampos puede variar, por ejemplo, en este caso,
usted probablemente no especificaría la hora de salida preferida incluyendo el subcampo
de los segundos. De hecho, podría solamente especificar dos subcampos: la hora y AM o
PM. El formato del campo para el horario—AM/PM o de 24 horas—influye la validez del
subcampo hora.
Al igual que con las fechas, un horario puede ser válido o inválido para una situación dada.
Por ejemplo, no podemos salir en un horario que ya ha pasado. No se puede especificar un
horario de salida deseado que está después de nuestro horario de llegada deseado, en la
mayoría de los casos. Sin embargo, con los viajes en avión, si estamos volando a través de
la línea internacional del cambio de fecha, podría haber ocasiones donde las fechas y los
horarios de llegada preceden a las fechas y los horarios de salida.
Figura 4.16: Moneda
Primero, mientras que el redondeo de los valores decimales puede ocurrir con números
decimales, el redondeo de cantidades significativas de dinero es usualmente considerado
un defecto. Es decir, si usted tiene cuenta de inversión con millones de dólares,
generalmente esperaría que el balance de esa cuenta sea válido hasta la más pequeña
unidad monetaria significativa. En los Estados Unidos y en una serie de otros países, eso
sería centésimas de la moneda, p.ej., los centavos.
Para otros países, la unidad significativa más pequeña sería los veinteavos de la moneda;
p.ej. en Nueva Zelanda e Israel, el dólar neozelandés y el shekel israelí son redondeados al
lugar más cercano de un veinteavo en las transacciones en efectivo. Aún para otros países
la unidad monetaria significativa más pequeña es la moneda misma, como el won coreano.
Segundo, cuando se trata de un programa que debe manejar monedas para muchos países,
se presenta la pregunta del valor de la moneda. En el ejemplo que se muestra en esta figura,
el precio máximo de oferta de una acción es 999,99. Eso es una cantidad significativa de
dinero, si estuviéramos hablando de 999,99 libras, o de 999,99 euros, o incluso de 999,99
dólares. Sin embargo, si estuviéramos hablando 999,99 wons, eso es una cantidad muy
pequeña de dinero. Los límites superiores e inferiores codificados en duro, no tendrían
sentido en tales situaciones.
Hasta ahora, hemos estado examinando las técnicas de diseño de pruebas que se aplican a
entradas, salidas, valores de configuración individuales, y etc. Con las pruebas de caso de
uso y pruebas de escenario empezamos a ver las pruebas de los flujos de trabajo
completos, una pantalla completa o una serie de pantallas que logran una tarea
determinada.
Los casos de uso son una técnica de diseño de sistemas utilizada a menudo con el diseño
orientado a objetos. Para otros tipos de sistemas, la analogía es el escenario.
Por ejemplo, suponga que está probando una aplicación de préstamos hipotecarios. Un
solicitante solicita tal préstamo. El solicitante es evaluado en función de su situación
familiar, su valor de la garantía hipotecaria, sus activos, sus ingresos, su historial
crediticio y el tamaño del préstamo el cual está solicitando. Entonces, para probar esto,
necesitamos generar casos de prueba que llenen los campos de los datos pertinentes con
estos valores de evaluación.
”… una casa con un valor de US$ 400 mil de la cuál ellos deben US$ 350 mil…”.
”… dos coches con un valor de US$ 25 mil de lo cual ellos deben US$ 17 mil…”.
”… una mora en el pago de su tarjeta Visa y una mora en el pago de los coches, diecisiete
meses y treinta y cinco meses, respectivamente ..”.
Tendríamos también que determinar, basados en las reglas de negocio, dónde John y Jenny
Stevens deberían ser aprobados para este préstamo.
Hablemos uno poco más acerca de los casos de uso, lo que son, cómo se ven y como
utilizarlos.
Cada caso de uso tiene precondiciones, las cuales deben ser verdaderas antes del primer
paso del caso de uso, y cuál debe ser verdadero para que el caso de uso continúe
satisfactoriamente. Cada caso de uso tiene poscondiciones también, las cuales son los
resultados observables y el estado final del sistema después de que los pasos del caso de
uso hayan terminado.
Un caso de uso tiene usualmente un camino del flujo principal, el flujo de trabajo o el
escenario. Estos son el conjunto de pasos más probables que ocurren, algunas veces
denominados el camino feliz. Adicionalmente, el caso de uso debería tener caminos
alternativos definidos para los problemas o las variaciones típicas previsibles.
En esta página, vemos un ejemplo de un caso de uso informal, que describe las compras de
un sitio de comercio electrónico, de la tienda del sitio web de RBCS. En la parte superior,
tenemos el flujo de trabajo normal de la compra del sitio web. Éste es un camino feliz.
Note que la precondición es de que el cliente—quién es uno de los actores en este caso de
uso—está en la tienda en el sitio web de RBCS—el cuál es el otro actor en este caso de
uso—navegando a través de los cursos, libros y otros ítems en venta allí. Primero, el
Cliente coloca uno o más ítems en su carro de compras. Luego el Cliente selecciona
“pagar”. Ahora, el sistema recopila la dirección, el pago y la información del envío del
Cliente. Con la información recopilada, el Sistema muestra toda la información para la
confirmación por parte del Cliente. Finalmente, el Cliente confirma el pedido al sistema
para que sea entregado.
Note que el resultado final, la poscondición, es que el pedido está en el sistema para ser
entregado. Presumiblemente otro caso de uso para completar el pedido describirá cómo
este pedido llega en última instancia al hogar o lugar de trabajo del cliente.
Por un lado, el Cliente podría tratar de pasar a pagar con un carro de compras vacío. En
ese caso, el Sistema da un mensaje de error.
Finalmente, el Cliente podría abandonar la transacción antes o durante el paso del pago.
Para controlar esto, el Sistema retira el Cliente del sistema después de 10 minutos de
inactividad.
Note que para derivar las pruebas para este caso de uso, usted selecciona simplemente los
datos específicos y crea los casos de prueba que corresponden al camino feliz y a los
flujos de trabajo excepcionales. Típicamente, usted ejecutaría una prueba por lo menos por
cada flujo de trabajo. Los flujos de trabajo riesgosos merecerían, por supuesto, más de una
prueba. Un número importante de particiones de equivalencia—p.ej. diferentes tarjetas de
crédito permitidas en este ejemplo—conducirían a múltiples pruebas.
Está bien combinar técnicas de diseño de pruebas—de hecho, usted debería realmente—
pero en algunos casos, cosas extrañas pueden ocurrir. Por ejemplo, necesita diseñar
pruebas basadas en los casos de uso o escenarios con las particiones de equivalencia. Sin
embargo, ¿Debería utilizar los valores límite?
El utilizar los valores límite podría llevarnos a crear pruebas que no son necesariamente el
uso razonable del sistema. Por ejemplo, si la aplicación utiliza un elemento sin signo de
cuatro bytes como una variable contador, ¿debería probar ordenando millones de ítems
sólo porque el software lo soporta? O ¿debería el software imponer un límite superior
razonable en la cantidad del pedido? Si es así, ¿cuál es ese límite? ¿Está especificado?
Como mencionamos antes, las suposiciones aparentemente razonables acerca de los límites
lógicos no podrían aplicarse en todas las situaciones. En ciertos casos, basados en el
horario local, un sistema de reserva de vuelos podría permitir para los viajes, fechas de
salida posteriores a las fechas de llegada.
Los casos de uso y escenarios pueden a menudo revelar el hecho de que, con frecuencia,
las especificaciones de los límites podrían no estar completas. En algunos casos, aunque el
sistema pueda manejarlo, aceptar una entrada “ridícula” constituye un defecto.
Con las tablas de decisión, continuamos con las pruebas de completos flujos de trabajo,
una pantalla entera o una serie de pantallas que logran una tarea determinada. Las tablas de
decisión son una forma agradable, compacta y fácil de leer para expresar las reglas de
negocio que determinan como una aplicación debería manejar estos flujos de trabajo.
Por ejemplo, una tabla de decisión nos puede decir cómo el sistema debería procesar un
pedido basado en el tamaño, el stock disponible, el estado en el cuál se puede enviar, y así
sucesivamente. Una tabla de decisión es una representación tabulada de las reglas, la
lógica de negocios. Estas mismas reglas pueden ser mostradas como diagramas de flujo,
pero eso no es algo que vamos a cubrir en este libro.
Si usted es un probador, la obtención de las tablas de decisión es bonito, porque las puede
utilizar para crear casos de prueba muy fácilmente. Si recibe un diagrama de flujo o una
descripción de texto de las reglas de negocio, la creación de una tabla de decisión de esas
reglas puede también hacer fácil las pruebas.
Veamos un ejemplo.
Esta tabla muestra una tabla de decisión de un cajero automático (ATM), que sólo se ocupa
de solicitudes de retiro. Muestra el aspecto típico de una tabla de decisión. En el lado
izquierdo hay una columna con las condiciones enumeradas en la parte superior y las
acciones en la parte inferior. En cada columna de la derecha, hay una regla la cual
establece cuáles acciones son y no son tomadas basadas en cada una de las condiciones
que se han cumplido o no.
La primera regla dice que, si alguien inserta una tarjeta inválida en el cajero automático, el
cajero automático debería rechazar esa tarjeta. No debería solicitar al usuario que
introduzca o vuelva a introducir el PIN, porque ningún PIN aplica para tal tarjeta. No
debería retener la tarjeta. No debería solicitar al usuario que ingrese o vuelva a ingresar el
monto del retiro solicitado porque ninguna cuenta está asociada a la tarjeta. ¡Ciertamente,
no debería dar efectivo!
La segunda regla dice que, si alguien inserta una tarjeta válida en el cajero automático,
pero introduce un PIN inválido, el cajero automático debería solicitar al usuario que
vuelva a introducir el PIN, con la condición de que no hayan ingresado ya un PIN inválido
tres veces. La tercera regla aclara esta situación diciendo que, si el usuario introduce un
PIN inválido tres veces seguidas, debería retener la tarjeta.
La cuarta regla dice que, si alguien inserta una tarjeta válida en el cajero automático e
ingresa un PIN válido, pero una solicitud inválida de retiro, el cajero automático debería
solicitar al usuario que vuelva a introducir la solicitud de retiro.
La quinta regla—el llamado “camino feliz”—dice que, dada una tarjeta, el PIN, y la
solicitud válida de retiro, el cajero automático debería dar efectivo.
Esta tabla de decisión muestra la lógica de negocios para un cajero automático. Observe
que los guiones “-” indican condiciones que no son alcanzadas o no son aplicables para
esta regla. Las reglas son mutuamente exclusivas, porque sólo una regla puede aplicarse en
un momento determinado en el instante.
Observe que la capa de la lógica de negocios está generalmente bajo la capa de la interfaz
de usuario, de modo que en este punto el control de la sanidad básica de las entradas
debería haber sido realizado. En otras palabras, los valores límite y las particiones de
equivalencia inválidas de los campos de entrada deberían ser utilizados principalmente
para probar la validación de las entradas. Una vez que consigamos probar la lógica de
negocios, no deberíamos tener necesidad de repetir aquella validación de las entradas.
Cuando realiza pruebas con una tabla de decisión, la regla usual de la cobertura es tener
por lo menos una prueba por cada regla de negocios o columna en la tabla de decisión.
Decimos “por lo menos una prueba” porque, en algunas situaciones, más que una manera
interesante puede existir para satisfacer o no una condición y que sea valiosa de probar.
Por ejemplo, con nuestras pruebas del Cajero Automático, podríamos querer probar las
tarjetas del cajero automático vencidas, las tarjetas del Cajero Automático que utilizan una
red de efectivo no compatible, las tarjetas del Cajero Automático robadas, las licencias de
conducir u otras tarjetas con una banda magnética y las tarjetas sin banda magnética. Tenga
en cuenta que ésta es una aplicación de la técnica de particionamiento de equivalencia para
una sola columna de la tabla de decisión.
Hace años, cuando Rex Black solía conducir un poco más rápido de lo que debía, se
encontró con un policía que utilizó una computadora de mano para gestionar su notificación
por el exceso de velocidad. Esta computadora también le permitía al policía aceptar su
tarjeta de crédito para el pago de la multa—una característica práctica, porque le impidió
perder el vuelo de la aerolínea que estaba tratando de tomar con prontitud.
Como esto fue hace unos cuantos años atrás, ahora incluso más departamentos de policía
cuentan con computadoras de mano que emiten notificaciones e incluso aceptan tarjetas de
crédito para pagar las multas por las violaciones de conducción y otras infracciones.
Una tabla de decisión podría ser utilizada para diseñar y probar tal sistema. Las
condiciones que determinan las acciones que deben ser tomadas son mostradas en la tabla
de decisión en la siguiente tabla. En esta situación, puede que quiera utilizar el análisis de
valores límite para cubrir adecuadamente las reglas. Además, tendremos que considerar
cómo administrar la interacción de las reglas.
Aquí tenemos una tabla de decisión—o más probablemente una parte de una tabla de
decisión—que podría describir algunas de las acciones de tal computadora de la policía.
La primera regla dice que si el conductor tiene una licencia de conducir inválida, el
conductor será arrestado. El conductor incurrirá también en una multa de US$ 250. Las
líneas punteadas aquí nos dicen que otras condiciones y acciones podrían aplicarse
también.
La segunda regla dice que si el conductor tiene una orden judicial existente para su arresto,
el conductor será arrestado. El conductor incurrirá también en una multa de US$ 250. Una
vez más, otras condiciones y acciones se podrían aplicar.
La tercera regla dice que si el conductor no ha pagado sus cuotas del registro, el conductor
debe recibir una boleta de infracción corregible que obliga al conductor a pagar la cuota en
algún plazo determinado. El conductor incurrirá también en una multa de US$ 25. Si el
conductor no paga sus cuotas, típicamente, esa notificación expirará y se convertirá en una
orden judicial de arresto.
La cuarta regla dice similarmente que si el conductor tiene un vehículo con desperfectos, el
conductor debería recibir una boleta corregible que requiere que el conductor resuelva el
problema dentro de algún plazo determinado. El conductor incurrirá también en una multa
de US$ 25. Si el conductor no resuelve el problema, típicamente esa notificación expirará
y se convertirá en una orden judicial de arresto.
Cada una del primer conjunto de las cuatro reglas se puede aplicar simultáneamente. Es
decir, estas reglas no son mutuamente exclusivas. Los totales de multa serían adicionados
en estas situaciones.
La quinta regla dice que si el conductor estaba viajando entre 1 y 10 millas por hora (o
km/hora si lo prefiere) sobre el límite de velocidad, el conductor recibirá solo una
advertencia.
La sexta regla dice que si el conductor estaba viajando entre 11 y 20 millas por hora (o
km/hora si lo prefiere) sobre el límite de velocidad, el conductor incurrirá en una multa de
US$ 75.
La séptima regla dice que si el conductor estaba viajando entre 21 y 25 millas por hora (o
km/hora si lo prefiere) sobre el límite de velocidad, el conductor incurrirá en una multa de
US$ 150.
La octava regla dice que si el conductor estaba viajando a más de 25 millas por hora (o
km/hora si lo prefiere) sobre el límite de velocidad, el conductor incurrirá en una multa de
US$ 250. El conductor será arrestado entonces.
Todas estas reglas del segundo conjunto, que consisten en 4 reglas, son mutuamente
exclusivas.
Tome en cuenta cuánto más tiempo es necesario para en la descripción de estas reglas
verbalmente o textualmente. Usted puede observar cuán compacta y aún sin ambigüedades
puede ser la representación de la tabla de decisión de las reglas de negocio.
Tenga en cuenta que la multa máxima puede ser US$ 800, basada en la interacción de las
cuatro primeras reglas y la octava regla. ¡Por supuesto, el conductor será arrestado solo
una vez!
Cuando se prueba una tabla de decisión como esta, primero tenemos que probar cada regla
por sí misma. Para las reglas definidas en intervalos, como las reglas de la cinco a la ocho,
probablemente necesitaremos dos pruebas para asegurar que los rangos son definidos
correctamente en los límites.
Una vez que hayamos probado las reglas por sí mismas, deberíamos entonces probar las
combinaciones de las reglas. Hay técnicas para decidir cómo realizarlo así, tales como los
árboles de clasificación, las tablas de todos los pares y el análisis de dominio. Estas
técnicas son descritas en el libro Advanced Software Testing for the Test Analyst.
Las tablas de decisión son buenas cuando usted está probando un sistema que controla
transacciones individuales o lotes de entradas, y cada transacción o lote es manejado de
forma independiente. Sin embargo, para algunos sistemas las series de eventos y
condiciones que han ocurrido parcialmente en el pasado, determinan cómo el sistema
responderá al evento actual y a las condiciones que predominan. Para las pruebas de estos
sistemas deberíamos utilizar los diagramas de transición de estados. Para crear un
diagrama de transición de estados, usted primero identifica los varios estados en los que el
sistema puede estar. Querrá asegurarse de que entiende los estados inicial y final. Como
regla general, los casos de prueba deberían comenzar con el sistema en el estado inicial y
deben terminar con el sistema en el estado final.
En cada estado, algún evento puede ocurrir que forzará una transición de estado. (Esto es
cierto para todos los estados excepto el estado final.). Mientras la transición de estado
ocurre, el sistema podría tomar alguna acción. En algunos casos, dos o más condiciones
son aplicadas al evento, el cual influye cuál transición ocurre—y por lo tanto cuál acción
es tomada. Después que la transición de estado ha ocurrido, el sistema está ya sea en un
nuevo estado o se ha mantenido en su estado actual.
Veamos un ejemplo.
Esta figura muestra un diagrama de transición de estados para un sistema de punto de venta,
igual al que encontraría en un supermercado o pulpería.
Hay por lo menos dos defectos en este diagrama. Primero, el cajero sólo puede terminar su
turno mientras acepta el pago del cliente. Esto es doblemente absurdo. Un cajero no
debería dejar el trabajo en medio de la atención a un cliente. El cajero no debería tener que
estar en medio de la atención a un cliente para dejar el trabajo.
Una de las cosas buenas acerca del diagrama de transición de estados es que hace que sea
fácil de detectar problemas como éste. Esos problemas pueden esconderse en una
descripción larga de texto de los requisitos.
Como con las tablas de decisión, la representación compacta y precisa ayuda a revelar los
defectos y así acentúa el potencial de la prevención de los defectos por medio de las
pruebas—si el diseño de pruebas es realizado antes que el sistema sea construido, ¡eso es!
Y si usted persigue una estrategia de pruebas netamente reactiva, entonces perderá este
beneficio.
Note que se muestra el sistema desde el punto de vista del cajero. Le recomendamos que
vuelva a dibujar el diagrama desde el punto de vista del cliente. Luego, vuelva a dibujarlo
de nuevo desde el punto de vista del propio sistema de punto de venta.
Las acciones son también acontecimientos, pero ellas son usualmente salidas de algún tipo
de sistema o aplicación. Típicamente, una acción se inicia y termina rápidamente o en
algún período de tiempo fijo, relativamente constante. En algunos casos, encontrará un
tanto arbitrario en cuanto a si elegir el modelado de un determinado comportamiento como
una acción asociada a una transición de estado o como un estado intermedio con una
transición de estado y acción asociados.
Como con las otras técnicas formales del diseño de pruebas, hay criterios de cobertura
para los diagramas de transición de estados. Los criterios mínimos son: visitar cada estado
y atravesar cada transición. Note que si atraviesa cada transición, habrá ejercido cada par
de evento/condición en el diagrama así como también habrá observado cada acción en el
diagrama, porque las transiciones de estado son activadas por los pares evento/condición y
son tomadas acciones por el sistema durante las transiciones de estado.
Criterios más fuertes existen para la cobertura de los diagramas de transición de estados.
Por ejemplo, el criterio de la cobertura de transiciones (“switch-coverage”) de Chow
requiere la cobertura de las secuencias de las transiciones de longitud creciente. Estos
criterios son tratados en el libro Advanced Software Testing for the Test Analyst.
Los diagramas de transición de estados son bonitos, pero sólo muestran cómo el sistema
maneja los pares evento/condición para ciertos estados. ¿Qué pasa si un evento ocurre
cuando el sistema no lo está esperando? ¿Qué debería ocurrir?
Una tabla de estado-transición puede revelar situaciones indefinidas, como lo hace esta
parte de la tabla para el gráfico anterior. Puede construir estas tablas del diagrama de
transición de estados utilizando el siguiente proceso:
3. Crear una tabla con cada combinación posible del estado con el par evento/condición.
En este punto, puede haber encontrado algunos problemas de diseño del sistema. Para las
filas con las acciones y los nuevos estados indefinidos, quizás desee comprobar con la
gente para ver si aquellas son realmente situaciones las cuales no pueden suceder. Si no,
entonces ya sea el programador se acordará de codificarlos durante la implementación—la
cual es una suposición riesgosa— o el sistema tendrá un defecto de omisión que puede
resultar en un comportamiento impredecible durante su utilización.
Una vez más, como todos los demás modelos formales para el diseño de pruebas, tenemos
un criterio de cobertura para las tablas de transición de estados. Cada fila debería tener
una prueba asociada—si por ninguna otra razón se confirma que las cosas que “no puede
ocurrir” realmente no suceden.
El servidor de impresión responde a los eventos, los cuales son entradas, ya sea de los
usuarios o la impresora, basado en el estado en el que éste esté.
Teniendo en cuenta la regla acerca de los casos de prueba que tienen que empezar y
terminar en el estado inicial, ¿Cuál es el número máximo de casos de prueba?
Es infinito. Si usted nos muestra cualquier conjunto de pruebas que piensa que es
exhaustivo, podemos añadir otro ciclo del trabajo desde el trabajo de impresión a la
espera de los usuarios y de vuelta al trabajo de impresión que es una nueva prueba. Esta
propiedad, de siempre ser capaz de añadir una única variante más a una lista, es la
definición misma del infinito contable.
¿Terminó? Bien. Su tabla de transición de estados debería tener 35 filas en la tabla. ¿Tiene
40? Si es así, probablemente contó dos veces el evento “error recuperable reportado”.
LO-4.4.2 Explicar los conceptos de cobertura de sentencia y decisión, y dar las razones
por qué estos conceptos pueden también ser utilizados en otros niveles de prueba distintos
a las pruebas de componente (p.ej. en procedimientos comerciales en el nivel de sistema).
(K2)
LO-4.4.3 Escribir casos de prueba de los flujos de control dados utilizando las técnicas de
diseño de pruebas de sentencia y decisión. (K3)
En esta sección, Técnicas Basadas en la Estructura, cubrirá los siguientes conceptos clave:
Niveles de cobertura de código.
Obtención de la cobertura de sentencia y decisión con las pruebas.
Utilización del flujo de control del programa para diseñar las pruebas.
Empecemos con los conceptos básicos de las pruebas basadas en la estructura o de caja
blanca.
Recuerde que las pruebas basadas en la especificación, también conocidas como las
pruebas de caja negra o como las pruebas de comportamiento, son las que son diseñadas
desde la especificación del sistema. En las pruebas de comportamiento, nosotros
ignoramos el funcionamiento interno del sistema y nos enfocamos acerca de cómo este se
supone que se debe comportar.
Ahora, las pruebas basadas en la estructura, las cuáles son llamadas también pruebas
estructurales o de caja blanca, se basan en la estructura interna del sistema o en un
componente del sistema; p.ej., nosotros examinamos cómo el sistema funciona y qué hace.
Específicamente, seleccionamos las entradas, las precondiciones, las condiciones, los
eventos u otros estímulos basados en una parte de la estructura del sistema que estos
ejercerán.
Por supuesto, cuando realicemos las pruebas estructurales—porque éstas son pruebas
dinámicas—el sistema o componente presentará algún comportamiento. Tenemos que
comparar ese comportamiento con algún resultado esperado, de lo contrario no estamos
probando. No podemos derivar los resultados esperados para las pruebas estructurales por
completo de la estructura, porque de lo contrario terminamos probando el compilador, el
sistema operativo y otros elementos del entorno, más que el sistema propio. De este modo
nosotros derivamos típicamente los resultados esperados para las pruebas estructurales en
parte de la estructura, pero también de las especificaciones, las expectativas razonables, y
así sucesivamente.
Como con las pruebas de comportamiento, cuando nosotros estamos observando los
comportamientos mostrados por una prueba de estructura, nosotros podemos estar
observando comportamientos funcionales— ¿Qué hace el sistema o componente? —O
comportamientos no funcionales— ¿Cómo lo hace? —basado en la clasificación del ISO
9126.
La más simple es analizar los flujos de control en el código y utilizar ese análisis para
medir la cobertura de las pruebas existentes y para adicionar las pruebas adicionales para
alcanzar un nivel deseado de cobertura. (Hablaremos más acerca de la cobertura de código
más adelante). Estos tipos de pruebas estructurales son cubiertos en el programa de
estudios básico.
Permítanos resaltar de nuevo un uso importante del diseño de pruebas estructural: Es una
mejor práctica para medir el grado de cobertura estructural de las pruebas basadas en la
especificación y la experiencia, de tal manera que usted pueda buscar partes importantes
de la estructura del sistema, las cuales no están siendo probadas.
Si no tiene una base en programación, podría considerar esta sección un poco difícil.
Porque comprendiendo cómo los sistemas tienden a fallar y por qué, es una habilidad clave
cuando se está haciendo el análisis de los riesgos de calidad, nosotros lo animaríamos a
que se auto enseñe un lenguaje de programación si intenta que su profesión sea la de
pruebas de software.
Hay un número de variantes aquí, pero las más comunes son las siguientes:
La ramificación ocurre cuando el programa hace una decisión acerca de que si una
situación particular de dos o más situaciones posibles existen, y luego procede a fluir el
control del programa en una manera apropiada para manejar la situación. Ya que una
manera de manejar la situación es a través de la secuencia de sentencias, el 100% de
cobertura de rama significa que alcanzaremos el 100% de cobertura de sentencia.
Ahora, cuando no sólo contamos con condiciones simples en un programa, pero con
condiciones compuestas como “(edad >= 0) && (edad 18)”, entonces podemos hablar
acerca de la cobertura de multicondición. La cobertura de multicondición (más conocida
como la cobertura completa de condición múltiple) es el porcentaje de las condiciones de
todos los resultados de cada condición única dentro de una sentencia que ha sido evaluada
por mínimamente una de las pruebas.
Porque probando todas las combinaciones de las condiciones, también significa la prueba
de todas las condiciones posibles, el 100% de la cobertura de condición múltiple implica
el 100% de cobertura de condición.
Finalmente, hay una cobertura de bucle. Ésta no es una métrica formalizada de la cobertura
estructural en el ISTQB nivel básico. Sin embargo, informalmente, podemos decir que
hemos alcanzado el 100% de la cobertura del bucle cuando tengamos un conjunto de
pruebas que obligan al programa a tomar todos los caminos del bucle cero, uno y muchas
veces.
Nosotros mencionamos arriba que el 100% de la cobertura de rama significa que hemos
alcanzado el 100% de la cobertura de sentencia. ¿Piensa usted de que el 100% de la
cobertura de sentencia significa de que alcanzaremos el 100% de cobertura de rama? La
respuesta es “no”. Si usted ha escrito programas de computación antes, sabrá de que no
cada sentencia if tiene una sentencia correspondiente else y que ningún constructo
switch/case tiene un bloque por defecto de sentencias. En tales casos, el else implícito o la
acción por defecto es “hacer nada”, la cual representa una decisión tomada. Por su puesto,
si haciendo nada es la cosa correcta para hacer, es algo que también tenemos que probar.
En este programa, la entrada es el número del cual se calcula el factorial. Está guardado en
la variable n.
¿Listo? Bueno. Usted debería ver que si usted escoge un valor de n menor que 0 y otro
valor de n mayor que 0, ejecutará cada sentencia al menos una vez.
No, necesitamos también n==0 para comprobar que el bucle no sea ejecutado.
Si probamos con n menos que 0, n igual a 0 y n mayor que cero, ¿Alcanzaría eso cobertura
de condición? Sí, porque no tenemos condiciones compuestas.
Finalmente, ¿Qué hay de la cobertura de bucle? Para la cobertura de bucle del 100%,
necesitamos de cubrir n==1 y n==el número máximo de veces en todo el bucle.
De este modo, ¿Cómo podemos utilizar la cobertura de código para diseñar las pruebas?
¿Qué bueno es este material de las pruebas estructurales para nosotros como probadores?
En debates acerca de otras pruebas y con nuestra propia experiencia personal, nos hemos
dado cuenta de que, por sí mismas, las técnicas de caja negra pueden dejar de cubrir hasta
un 75% o más de las sentencias.
Ya sea si esta gran cantidad de código no probado representa un problema o no, depende
de lo que no es cubierto, así como si los programadores probaron o no este código en las
pruebas de unidad.
Al principio de este libro hablamos del análisis estático del código. Mencionamos que
algunas herramientas de análisis estático pueden localizar segmentos del código altamente
complejos. Veamos esa medida de complejidad, la cual tiene algunas implicaciones
interesantes del diseño de pruebas.
Porque no es muy divertido y las herramientas pueden ser costosas (sin embargo algunas
son libres), ¿Por qué ocuparse con este concepto de la complejidad ciclomática? Bien, éste
tiene algunas implicaciones útiles de las pruebas.
Hemos leído un estudio de algunas personas en IBM, que examinaron una de sus
aplicaciones. Para esta aplicación, ellos no encontraron correlación entre las varias
métricas de complejidad para los varios módulos y las densidades de defectos para esos
mismos módulos. Ahora, eso puede significar que la complejidad no influencia la
defectuosidad. Sin embargo, eso podría también significar que las métricas de complejidad
que ellos examinaron no se adecuan a la captura de todos los elementos de complejidad.
¿Tal vez lo que hace a un programa verdaderamente complejo—y así propenso a los
defectos—es algo que la mayoría de las métricas de complejidad no miden?
La otra implicación útil de esta métrica para las pruebas es cuando se evalúa un conjunto
de pruebas de unidad para una función. Usted puede extender la técnica de las gráficas del
flujo de control de McCabe para generar lo que él llama los caminos a través del grafo. El
número de caminos básicos es igual al número de pruebas básicas requeridas para cubrir
el grafo. Retornaremos a este concepto en breve, porque éste le ayudará a visualizar los
caminos básicos y las pruebas básicas como lo hablamos.
Esta figura muestra el programa que calcula el factorial en el lado izquierdo. Las líneas
punteadas del código al diagrama del flujo de McCabe en el centro de esta figura muestra
cómo las secuencias sin ramas de cero o más sentencias llegan a ser las aristas (o las
flechas), y cómo los constructos con las ramas y los bucles llegan a ser los nodos (o las
burbujas).
En la parte derecha de la figura, usted puede observar dos métodos que calculan la métrica
de la complejidad ciclomática de McCabe. El más simple es tal vez el cálculo de la
“región cerrada”. Las dos regiones cerradas, representadas por R en la ecuación superior,
se encuentran en el diagrama de abajo y mayormente en la izquierda del nodo “n0” y abajo
en la derecha del nodo “l=n”.
El otro método de cálculo involucra el conteo de las aristas (o flechas) y los nodos (o
burbujas).
Ahora, esto es simplemente suficiente para un programa pequeño y simple como éste. Para
funciones más grandes, dibujando el gráfico y haciendo el cálculo de éste es un verdadero
lío. De este modo, una simple regla de dedo es: Cuente los constructos de rama y bucle y
adicione 1. Las sentencias “if” y los constructos “for”, “while” y “do/while cuentan como
uno. Para los constructos switch/case, cada bloque case cuenta como uno. En los
constructos “if” y “ladder if”, el “else” no se cuenta. Para los constructos switch/case, el
bloque “por defecto” no se cuenta. Ésta es una regla heurística, pero parece que siempre
funciona.
Figura 4.21: Caminos y Pruebas Básicas
Las pruebas básicas son las entradas y los resultados esperados asociados con cada
camino básico. Usualmente, las pruebas básicas coincidirán con las pruebas necesarias
para alcanzar la cobertura de rama. Esto tiene sentido, porque la complejidad se
incrementa en cualquier momento en que más de una arista sale de un nodo en un diagrama
de flujo de McCabe. En un diagrama de flujo de McCabe, una situación donde “más de una
arista de un nodo” representa un constructo de ramas o de bucles.
¿Para qué sirve esta exquisita información? Bien, suponga que estuviese hablando con un
programador acerca de sus pruebas de unidad. Usted pregunta cuántas entradas utilizaron
ellos. Si ellos le dicen un número menor que la métrica de complejidad ciclomática de
McCabe, para el código que ellos están probando, es una apuesta segura de que ellos no
alcanzaron la cobertura de rama. Eso implica, como fue mencionado más antes, de que
ellos no cubren las particiones de equivalencia.
4.4.1 Ejercicios
Ejercicio 1
Abajo encontrará un programa simple escrito en C que acepta una cadena con caracteres
hexadecimales (entre otros caracteres no deseados). Éste ignora los otros caracteres y
convierte los caracteres hexadecimales en una representación numérica.28
Si prueba con las cadenas de entrada: “059”, “ace” y “ACD” ¿Qué niveles de cobertura
usted alcanzaría?
¿Qué cadenas de entrada podría usted añadir para alcanzar las coberturas de sentencia y
rama?
Argumente.
Mientras que no es necesario alcanzar ninguno de los niveles de cobertura estructural que
abordamos, usted podría considerar cadenas cortas mezcladas. Por ejemplo, “6dpF”
prueba cada uno de los cuatro bloques “case” en una sola prueba, y comprobar problemas
que podrían ocurrir en esas situaciones.
LO-4.5.2 Comparar las técnicas basadas en la experiencia con las técnicas de pruebas
basadas en la experiencia. (K2)
Es común encontrar que en vez de ser prediseñadas, las pruebas basadas en la experiencia
son a menudo creadas durante la ejecución de pruebas. En otras palabras, la estrategia es
dinámica o reactiva. Hablaremos acerca de las estrategias de pruebas en el siguiente
capítulo.
Al comienzo de este capítulo, hablamos acerca del análisis de los riesgos de calidad. De
este modo usted entiende ahora cómo y cuándo utilizamos los riesgos de calidad para
controlar nuestro esfuerzo de las pruebas y conseguimos la alineación del esfuerzo de las
pruebas con la calidad del sistema y con el nivel de riesgo para esa calidad.
Un método común para la mitigación de estos problemas es utilizar una lista de cartas de
pruebas (“test charters”), creada antes de la ejecución de las prueba. El tiempo que se debe
pasar en estas cartas de pruebas es frecuentemente “tiempo limitado”. Es decir, los
períodos cortos de las pruebas son concentrados en las condiciones específicas de las
pruebas asociadas con cada carta.
Con la mayoría de los métodos para las pruebas basadas en la experiencia —al menos los
métodos profesionales y serios— usted no crea todas las pruebas durante la ejecución de
pruebas. Usted tiene o desarrolla guías con anticipación.
Una taxonomía es una guía más complicada. Una taxonomía es una jerarquía de defectos
clasificada por tipo, subtipo, y así sucesivamente. Luego intentará de encontrar defectos
que son descubiertos en la taxonomía. Como se podría imaginar, las taxonomías de
defectos más efectivas son aquellas creadas por sistemas similares al que está probando
actualmente. Las taxonomías pueden ser efectivas para descubrir defectos, pero, como
cualquier método de pruebas, están enfocadas completamente en los riesgos técnicos—la
probabilidad de descubrir defectos, no influye en cuanto a la construcción de confianza; y
la reducción de los riesgos de calidad es incompleta.
Una lista de ataques es otra guía, todavía más complicada. En la lista de ataques, no tiene
solamente defectos metas que está buscando, sino también procedimientos de pruebas de
alto nivel para descubrir esos defectos. Los ejemplos más famosos de esta técnica son los
de James Whittaker’s How to Break Software and How to Break Software Security . Sin
embargo, en un ejemplo aún más antiguo—uno que precede al libro de Whittaker por más
de cinco años— es el de Brian Marick’s Craft of Software Testing. Nuevamente éste se
enfoca en los riesgos técnicos —descubriendo tantos defectos como sea posible—y no en
las demás contribuciones valiosas y potenciales que las pruebas pueden aportar al
proyecto.
Algo diferente es el concepto, desarrollado por Jon and James Bach, de utilizar un conjunto
de cartas de pruebas. Una carta de prueba es una descripción corta de la prueba que debe
ser realizada en cualquier lugar de dos a tres palabras hasta un par de frases.
Esto puede basarse en dónde esperamos descubrir los defectos, pero también puede
basarse en las características, los aspectos y las áreas clave del sistema. Entonces, como
tal, es más parecido a un método de listas de comprobación. Con el conjunto apropiado de
cartas de pruebas, esta técnica no solo puede descubrir los defectos, si no también ayuda a
construir la confianza en el sistema. Al igual que en las listas de comprobación, las cartas
de pruebas también permiten algún análisis de cobertura de pruebas en cuanto al mismo
sistema en vez de solamente una lista de defectos, que quisimos buscar.
Bien, como se podría imaginar que dado el enfoque acerca del descubrimiento de los
defectos en las técnicas, estas estrategias son a menudo muy efectivas en encontrar
defectos.
Además, debido a la especificación ligera de las pruebas, las pruebas tienden a variar de
un probador a otro y de una ejecución de pruebas a otra. Así, éstas varían más cada vez
que éstas son ejecutadas y resisten a la paradoja de pesticida explicada en el capítulo 1.
Porque las técnicas son tan diferentes a las técnicas estructurales y de comportamiento,
éstas sirven como una manera excelente para encontrar vacíos en las pruebas que
preparamos utilizando las estrategias analíticas.
Las estrategias analíticas de pruebas producen una lista sólida de las condiciones de
pruebas, los ítems de los riesgos y similares, cuando son iniciadas en el comienzo del
proceso de pruebas, éstas pueden ser utilizadas para estimar el esfuerzo necesario para
preparar y ejecutar las pruebas. Aquellos productos del trabajo no estarán disponibles
cuando se utilizan las estrategias dinámicas.
En muchos casos – por ejemplo, el método de las pruebas exploratorias con las cartas de
pruebas– hay una realización extensa de interrogatorios y debates para guiar el proceso,
porque no hay un “plan de pruebas” de por sí. (Más acerca de esto en el capítulo 5). Todas
estas sesiones de debates e interrogatorios funcionan para un equipo pequeño, idealmente
colocado y en la misma zona horaria, pero ellos no crecerán a equipos grandes o
distribuidos. Además, estas estrategias, mientras son útiles como un complemento para las
estrategias analíticas, no tienden a funcionar bien en muchos proyectos si se apoyan
exclusivamente sobre estas.
Esta tabla muestra un caso de estudio del uso de las pruebas exploratorias como técnica
complementaria en el proyecto que se apoyó principalmente en la estrategia de pruebas
analítica basada en los riesgos. Teníamos un equipo de pruebas que consistía en siete
técnicos de pruebas, tres ingenieros y un jefe de pruebas, Rex Black.
Los técnicos de pruebas eran básicamente contratados a bajo costo a quienes le dimos
precisamente los guiones detallados de las pruebas los cuales ellos luego ejecutaron. Cada
técnico de pruebas pasa normalmente 6 horas de 9 o 10 horas en el día en realidad
ejecutando estos guiones de pruebas. Las reuniones, el correo electrónico, la actualización
de los guiones de pruebas, la asistencia a los ingenieros de pruebas y otras funciones
importantes consumieron el resto del tiempo. De este modo fueron cerca de 42 horas al día,
que se utilizaron en la ejecución de los guiones de prueba.
Sin embargo entre los tres ingenieros de prueba y Rex Black, tenían más de 20 años en
total de experiencia en pruebas, de hecho probablemente más de 30 años. De manera que
no tendrían confianza en los guiones de pruebas y la capacidad de los técnicos de pruebas
para ejecutar aquellos guiones, decidimos realizar alguna prueba exploratoria con cartas.
Esto significó que nos pondríamos de acuerdo en probar diferentes áreas que pensamos,
que merecieran nuestra atención. Sin embargo, debido a que estuvimos ocupados, pudimos
dejar de lado solamente unas 6 horas al día en total entre los cuatro de nosotros para las
pruebas exploratorias.
En otras palabras, las pruebas exploratorias representaron un 13% del esfuerzo diario de
las pruebas. Pero, como puede ver en la tabla, mientras que las pruebas basadas en guiones
encontraron 928 defectos, un 78%, las pruebas exploratorias, basadas en el esfuerzo,
encontraron desproporcionadamente un numero alto, 261, o alrededor del 22%. Si divide
el número total de defectos por las horas por día del esfuerzo de pruebas, nos da una
métrica de efectividad de 22 para las pruebas basadas en guiones y un 44 para las pruebas
exploratorias.
De este modo, este caso de estudio nos demuestra que las pruebas exploratorias son
alrededor de 2 veces más efectivas en descubrir defectos en base a hora por hora. Si
fuéramos a calcular la eficiencia e incluir el tiempo dedicado para la preparación de las
pruebas, las pruebas exploratorias serían significativamente más eficientes. Después de
todo, las pruebas basadas en guiones necesitaron un esfuerzo extenso para ser creadas. Este
caso de estudio apoya el uso de pruebas exploratorias en un proyecto.
Sin embargo, hay algunas cosas de tomar en cuenta. ¿Podríamos haber empleado los
técnicos de pruebas para realizar las pruebas exploratorias y descubrir aún más defectos?
Probablemente no, porque el nivel relativo de experiencia es importante.
Además, como el cliché de gestión dice que lo que es medido es realizado y lo que no es
medido no es realizado. Así el problema con esta figura es que estamos midiendo
solamente los defectos. ¿Cuál es el valor de las pruebas más allá de encontrar los
defectos? Bien, para uno es la construcción de confianza y para otros la mitigación de los
riesgos. Porque las pruebas exploratorias tuvieron una medida de cobertura pequeña y
ninguna trazabilidad hacia atrás a los riesgos, no hay mucha cobertura demostrable o
mitigación de los riesgos.
Finalmente, note que la regresión fue un mayor riesgo para este proyecto. Tuvimos que ser
capaces de realizar pruebas precisas de regresión, como es el caso en muchos proyectos.
Así, el valor de la reutilización de los guiones fue de valor significativo.
4.5.1 Ejercicios
Ejercicio 1
Considere la utilización de las pruebas reactivas como opuestas a las pruebas
prediseñadas. En la tabla de abajo, ponga un “+” en la columna donde el factor o interés
motiva hacia la utilización del método y un “-” en la columna donde el factor o interés
desmotiva la utilización del método.
Tabla 4.13: Ejercicio-¿Pruebas Reactivas o Prediseñadas?
Los métodos reactivos de pruebas como los ataques de Whittaker o las técnicas
exploratorias de Kaner/Bach/Bolton tienden a tener un gran número de defectos
identificados por las horas totales de las pruebas. Porque existe una mínima
documentación, usted puede empezar a probar inmediatamente, lo cual es útil cuando usted
no está involucrado en el proyecto desde el principio. (Suponemos que es como hacer de la
necesidad una virtud, porque la participación tardía de los probadores es una de las peores
prácticas de ingeniería de software). También debido a la mínima documentación, los
cambios en la interfaz de usuario e incluso en la funcionalidad no incurren en grandes
costos del mantenimiento de las pruebas.
Esta sección, Selección de las Técnicas de Pruebas, cubrirá los siguientes conceptos clave,
los cuales son, los factores que influencian la selección de las técnicas apropiadas del
diseño pruebas.
¿Entonces cuáles son los factores que influencian la selección de las técnicas del diseño de
pruebas?
Tipo de sistema: Es una buena idea de utilizar las tablas de decisión para probar sistemas
que procesan transacciones similares. Sistemas que deben comportarse diferente
dependiendo de lo que ha ocurrido hasta el momento son más susceptibles a las pruebas
basadas en los estados.
Estándares regulatorios: Por Ejemplo, las Regulaciones de la Administración de la
Aviación Federal de los Estados Unidos requiere que los probadores usen técnicas
estructuradas de pruebas para asegurar un cierto nivel de cobertura del código en el
software de aviónica de seguridad crítica.
Requisitos del cliente o el contrato: El cliente o el contrato podría requerir que ciertas
técnicas sean utilizadas, directamente o indirectamente.
Nivel y tipo de riesgo: Deberíamos probar ciertos sistemas, como los de seguridad crítica,
en los niveles más altos posibles de seguridad. Deberíamos utilizar todas las técnicas de
pruebas aplicables.
Objetivos de las pruebas: Cuanto mayor sea el nivel de detección de defectos que
queremos alcanzar, más diversas son las técnicas que debemos utilizar. Si el objetivo
principal es encontrar muchos defectos como sea posible en un corto tiempo, entonces
confiaremos probablemente y fuertemente en las pruebas basadas en la experiencia.
Plazo y presupuesto: Si tenemos tiempo para preparar las pruebas, podemos hacerlo así. Si
tenemos dinero para herramientas de cobertura de código, entonces podemos determinar la
cobertura estructural.
Ciclo de vida del desarrollo: Como lo hablamos al principio, ciertos modelos del ciclo de
vida, como los iterativos, tienden a sufrir de los riesgos de alta regresión. Eso significa
que tenemos que buscar pruebas reutilizables.
Experiencias previas acerca de los tipos de defectos encontrados: Si tenemos una buena
idea de dónde buscar los defectos, las técnicas basadas en la experiencia que se basan en
esa experiencia funcionarán bien para nosotros.
Por supuesto, hay otros factores. Es importante, que cuando piense acerca de cómo probar,
que mantengan la mente comprometida con las necesidades del proyecto y vincule sus
pruebas a esas necesidades.
Figura 4.23: El Espectro Dinámico o Prediseñado
Sin embargo, la realidad es que hay más un espectro que una dicotomía. Cuanto más
precisas y detalladas las pruebas, cuanto más aprovechamos de los beneficios de la
trazabilidad, la reproducibilidad y aún la auditabilidad. Sin embargo pagamos el precio en
cuanto al costo del desarrollo y el mantenimiento, así como también la incursión del riesgo
de que los probadores pudieran desviarse de todas maneras de los guiones, así
privándonos de los beneficios que buscamos.
Cuanta menos especificación alrededor de las pruebas, cuanto más aprovechamos los
beneficios como la disminución de los costos de las pruebas, la flexibilidad mejorada y la
respuesta a las necesidades de cambio del proyecto. Sin embargo, pagamos el precio en
cuanto a la cobertura conocida, la reproducibilidad y algo similar.
La realidad es, una vez que usted separe varias personas quienes apoyan una técnica o
estrategia sobre otra, los equipos inteligentes de pruebas equilibran la el tamaño de la
documentación basada en las necesidades del proyecto. A menudo tenemos que vivir con
las restricciones como el programa y el presupuesto y a menudo necesitamos a pruebas
escritas y reproducibles. De este modo, tenemos que alcanzar un equilibrio.
Una vez estábamos conversando con un jefe de pruebas acerca del grado de detalle que él
quería en sus casos de prueba. El dijo, “Bien, si puedo dar el caso de prueba a un gorila
afeitado y esperaría que el gorila lo ejecute, ése es un caso de prueba bien escrito”.
“Ninguno”.
El no tenía una respuesta. Alguien le había dicho una vez que el estándar del gorila
afeitado era una regla difícil y rápida, y él tomó esto como la sabiduría revelada.
Es importante que tome en cuenta cómo alcanzar el equilibrio correcto de esta pregunta
acerca del detalle y la precisión del caso de prueba. La manera de alcanzar este equilibrio
es de considerar los intercambios en el espectro de la documentación de las pruebas. Las
pruebas precisas le permiten utilizar probadores con menos habilidad, pero esas pruebas
no son muy flexibles. Las pruebas imprecisas pueden cubrir más condiciones—porque
ellas son más rápidas de escribir—pero esas pruebas no son muy reproducibles,
especialmente a través de múltiples probadores. Las pruebas precisas le proporcionarán
los criterios de pruebas transparentes a usted y cualquiera que las lea, pero esas pruebas
son difíciles y costosas para mantener. Las pruebas imprecisas son rápidas de escribir,
pero la cobertura que ellas proporcionan, puede ser difícil de definir y medir.
La mayoría de los equipos de prueba no tienen guías para el grado correcto de precisión,
lo cual significa que ellos típicamente documentan en exceso o documentan muy poco. Un
buen comienzo es medir el número de palabras de la documentación en un ejemplo
aleatorio de 10, 50 o mejor todavía 100 de sus casos de prueba y procedimientos de
prueba. Ahora, por cada caso de prueba, divida el número de palabras entre el número de
horas o minutos que toma la ejecución de esa prueba. Cuanto más grande el número, cuanto
más precisa la documentación que está proporcionando a sus probadores.
A menudo, cuando realizamos este ejercicio con los clientes encontramos diferencias de
orden de magnitud entre los probadores acerca de esta métrica. Adicionalmente, no hay una
guía de gestión que diga a quién se debe proporcionar cuánto detalle. Ése es un problema
para rectificar si es que existe en su organización.
4.6.1 Ejercicios
Ejercicio 1
Hacer una lista de los factores abordados en esta sección que afectarían a la selección de
las técnicas de pruebas y el alcance de la documentación de Omninet.
Argumente.
Estándares
Términos
Términos
Términos