Вы находитесь на странице: 1из 37

Módulo 1

Unidad 1
Lectura 1

Materia: Pruebas de Sistemas


Profesora: Ing. Ana Carolina Ferreyra
Unidad 1: La prueba de
sistemas como una
disciplina

1.1. Perspectiva histórica

“Todo programa hace algo bien; pero tal vez sea lo que no
queremos que haga.”
Anónimo

“Si se quiere y espera que un programa funcione, lo más


probable es que se vea un programa funcionando (y que se
pasen por alto los fallos).”
(Cem Kaner et al., 2001)

Es difícil brindar una definición clara de lo que son las pruebas de


sistemas, ya que se pueden encontrar muchas prácticas denominadas
como tal. Siempre se presentan algunos grises entre lo que diferentes
autores determinan como “qué es hacer pruebas” y “qué no es hacer
pruebas”; además de las adaptaciones y cambios que ha ido teniendo
esta actividad, desde sus primeras referencias allá por 1950 hasta hoy
con las nuevas tecnologías y herramientas.

Actualmente, la palabra “test” o “testing” se emplea sin traducción para


significar prueba y ya la tenemos incorporada en nuestro vocabulario,
sin traducción.

Todos hemos crecido haciendo pruebas o tests, por ejemplo, en la


escuela, pruebas de esfuerzo para un estudio de corazón, pruebas para
el ingreso universitario, pruebas para ingresar a un trabajo, entre
muchos otros ejemplos. Así, entendemos a un test como una serie de
preguntas o ejercicios para medir el conocimiento y las habilidades de
un individuo, extendiendo ese significado a la medición de los sistemas
informáticos, es donde no está muy claro.

Si le pedimos a diferentes profesionales que indiquen lo que es para


ellos hacer pruebas, obtendremos diferentes respuestas como:

 Encontrar errores en programas

Pruebas de Sistemas – Ana Carolina Ferreyra | 2


 Determinar la aceptabilidad de usuarios

 Adquirir confianza en el funcionamiento del sistema

 Demostrar que no tiene errores

 Evaluar las capacidades de un sistema

 Verificar el funcionamiento de un programa

 Asegurar que el sistema está listo para ser usado

 Mostrar que el sistema funciona correctamente

 Chequear el sistema contra las especificaciones

 Asegurar la satisfacción del cliente

Haciendo este ejercicio en cualquiera de las capacitaciones que se


imparten de Testing de Software o Pruebas de Sistemas, se podrá
comprobar que es así, que se dan muchísimas afirmaciones de lo que
los profesionales vinculados al proceso de desarrollo creen o llevan
adelante como “pruebas de sistemas”.

Todas estas diferentes proposiciones no son incorrectas, son correctas


aproximaciones, pero cómo podemos definir a las pruebas
formalmente, ya que algunas de ellas denotan objetivos distintos. Por
ejemplo, no es lo mismo decir que hacer pruebas es “demostrar que no
tiene errores”, es decir, “mostrar que el sistema funciona
correctamente”. En ambas se involucran sentidos contrarios y objetivos
distintos.

Vamos a hacer un poco de historia para brindar una definición y a su


vez, para entender claramente el concepto.

Desde el momento en que comenzaron a escribirse los primeros


programas, se puede decir que nacen las pruebas. Un programa que se
escribía para correr en una computadora tenía que ser probado, y de
encontrarse errores, eliminarlos. Así surge la primera visión:

La prueba vista como una actividad siguiente a la programación, que


implicaba no sólo descubrir errores sino también corregirlos y
removerlos.

Recién a partir de 1960 es cuando comienzan las primeras distinciones


entre lo que es hacer pruebas y depurar. Y también durante esta década
es cuando la prueba de sistemas comienza a tomar más significancia.

Era ya evidente que los programas o sistemas contenían deficiencias y


el costo e impacto de repararlos era significativo. Por esta razón, en la
década de los 70s se comenzó a dedicar más tiempo y recursos a las
pruebas.

Luego de la primera conferencia formal organizada en EEUU, en junio


de 1972, dedicada a las pruebas de sistemas es que surge la segunda
visión:

Pruebas de Sistemas – Ana Carolina Ferreyra | 3


La prueba de sistema abarca una serie de actividades asociadas a
obtener confianza que un programa o sistema hace lo que se supone
que tiene que hacer.

Debido a los resultados dispares obtenidos de las pruebas de sistemas,


éstas eran vistas como un elemento organizado pero sin tecnología. A
partir de allí, se comienza a dedicar más tiempo a hablar de calidad,
confiabilidad e ingeniería. Entonces, es cuando las pruebas de sistemas
comienzan a emerger como una disciplina sistemática y metodológica.

Muchos textos, libros y conferencias comienzan a aportar a este


desarrollo del tema con la necesidad de muchos sectores de la industria
de aplicar más métodos prácticos de aseguramiento de calidad. Según
Myers (1979), si se planteaban las pruebas con el objetivo de demostrar
que el programa o sistema no contenía errores, inconscientemente se
iban a elegir datos para probar con baja probabilidad de causar que el
sistema falle. Surge así una tercera visión de las pruebas, donde el
objetivo central es “encontrar errores” como parte de un proceso. Los
datos seleccionados para probar son aquellos con alta probabilidad de
encontrar errores.

“El testing es el proceso de ejecutar un programa o sistema con la


intención de encontrar errores.” (Myers, 1979, p. 5).

La anterior definición implicaba que sólo se podía probar después que


el programa había sido codificado, cerrando a que sólo el código podía
ser probado.

Si bien esta definición fue aceptada, se reconocía en el ambiente de


profesionales de Ingeniería de Software, que existían otras maneras de
probar un sistema además de hacerlo a través de la ejecución.

Entonces aparece una cuarta visión:

El testing como una actividad amplia y continua que acompaña el


proceso de desarrollo.

Esto implica que cualquier actividad que es realizada con el objetivo de


ayudar en la evaluación o medición de un atributo de software es
considerado como una actividad de testing. Una disciplina de testing
efectiva ayuda a recolectar información que permita responder a
preguntas como: ¿El software está listo para ser utilizado? ¿Cuáles son
los riesgos? ¿Cuáles son sus limitaciones? ¿Funciona como se supone
que tiene que funcionar? Es así como en 1988, Bill Hetzel revisa su
primera definición, y la resuelve así:

“El testing es cualquier actividad orientada a evaluar un atributo o


capacidad de un programa o sistema y determinar si alcanza los
resultados requeridos.” (Bill Hetzel, 1988, p. 6)

Pruebas de Sistemas – Ana Carolina Ferreyra | 4


Al comenzar a hablar de capacidades, atributos o resultados
requeridos, comenzó la relación con calidad, ésta significa
cumplimiento de requisitos.

Si los requerimientos están completos y un producto cumple esos


requerimientos, entonces es un producto de calidad. Nace la quinta
visión definiendo a las pruebas de sistemas como:

El proceso de verificar que el software se ajusta a los requerimientos


y validar que las funciones se implementan correctamente.

Esta última, atiende a tres puntos importantes:

 Uno, que su funcionamiento es correcto, implicando que no hay


errores que impidan operar el sistema.

 Dos, que el sistema cumpla con los requerimientos, es decir,


que lo que se haya planteado esté desarrollado, que no falten
funcionalidades o que no haya requerimientos incumplidos.

 Y tres, que el hacer pruebas es visto como un proceso (“el


proceso de…”), y no como una actividad al final.

De este modo completamos el concepto abrazando el concepto de


calidad, donde diversos factores relevantes afectan la calidad del
software.

Según Hetzel (1988), están por un lado los factores de calidad que
tienen que ver con la funcionalidad, por otro lado, factores
relacionados con cuán bien fue construido el software, incluyendo
documentación, eficiencia, nivel de pruebas, facilidad de aprendizaje,
entre otros, y por último los factores que tienen que ver con la
adaptabilidad, es decir si se puede adaptar a los cambios, a los
diferentes entornos, y si se le puede incorporar nueva funcionalidad,
cuando así sea necesario.

Plantea así tres dimensiones de la calidad de software (que los define


como calidad exterior, interior y futura respectivamente), con sus
factores asociados, a saber1:

 Funcionalidad definida como la calidad exterior:

◦ Exactitud

◦ Usabilidad

◦ Confiabilidad

 Ingeniería como calidad interior (tiene que ver con el proceso


de construcción):

◦ Capacidad de pruebas

◦ Eficiencia

1
Sólo se mencionan algunos a modo de ejemplo.

Pruebas de Sistemas – Ana Carolina Ferreyra | 5


◦ Documentación

 Adaptabilidad como calidad futura

◦ Flexibilidad

◦ Reusabilidad

◦ Mantenibilidad

La importancia de cada uno de esos factores varía según el tipo de


sistema. Un sistema en el cual, de su funcionamiento dependen vidas
humanas, atenderá de manera estricta a factores como la exactitud y la
confiabilidad, mientras que en un sistema comercial típico de oficina,
los factores relevantes serán la usabilidad y el mantenimiento, por
ejemplo.

Entonces, una prueba efectiva debe estar orientada a proveer medidas


de cada uno de los factores “relevantes” y hacer visible y tangible así, la
calidad.

Con todo lo expuesto anteriormente, podemos decir que:

 Hacer pruebas no es demostrar que no hay errores.

 Hacer pruebas es detectar los errores y no buscar los motivos,


ya que buscar los motivos es hacer debugging. Hacer pruebas no
es debbugear un código, ya que podemos tener un sistema libre
de errores pero puede no servir para lo que se lo necesita.

 Hacer pruebas no implica simplemente verificar que las


funciones requeridas se implementaron.

 Hacer pruebas es someter un software a ciertas condiciones que


puedan demostrar si es o no válido a los requerimientos
planteados.

 Considerar las pruebas es agregar valor no sólo al producto,


sino que también al proceso de desarrollo, si se consideran los
resultados generados.

En lo que se refiere a la historia, podemos resumirla a través de las


visiones dadas:

1. Primera visión: inicialmente, hacer pruebas era hacer


debugging.

La prueba vista como una actividad siguiente a la


programación, que implicaba no sólo descubrir errores sino
también corregirlos y removerlos.

2. Segunda visión: la prueba no es sólo buscar errores o lo que no


anda bien, sino que se ve a la prueba de sistema como una serie
de actividades asociadas a “obtener confianza” que un programa
o sistema hace lo que se supone que tiene que hacer.

3. Tercera visión: las actividades de pruebas vistas como un


proceso, y nunca perdiendo de vista el objetivo de encontrar

Pruebas de Sistemas – Ana Carolina Ferreyra | 6


errores. “El testing es el proceso de ejecutar un programa o
sistema con la intención de encontrar errores.” (Myers, 1979, p.
5).

4. Cuarta visión: En los 80’ aparecen los estándares


relacionados, intentando dar metodología al proceso de pruebas
y vincularlo directamente al concepto de calidad, es decir, la
prueba vista como cualquier actividad realizada con el objetivo
de ayudar en la evaluación o medición de un atributo de
software.

5. Quinta visión: la prueba vista como el proceso de verificar que


el sistema desarrollado se ajusta a los requerimientos y de
validar que las funciones se implementan correctamente.
Incorpora tres puntos fundamentales: proceso, verificación
cumplimiento de requerimientos, y validación de funcionalidad.

6. En los 90’ aparecen las herramientas para dar soporte al


proceso y ayudar en la ejecución.

7. En el 2000 comienza a considerarse como parte del proceso


de aseguramiento de calidad de software.

8. Si bien actualmente todavía suele ser un proceso inmaduro, esto


está cambiando.

Respecto de las definiciones que se fueron dando con las distintas


visiones de la prueba de sistemas, es importante destacar que se
diferencian dos enfoques de las pruebas, uno dinámico y otro estático.

El enfoque dinámico apunta a ejecutar una parte o todo el software


para determinar si funciona según lo esperado.

El enfoque estático se refiere a la evaluación del software sin ejecutarlo


usando mecanismos automatizados (herramientas asistidas) y
manuales tales como controles de escritorio, inspecciones y revisiones.

Considerando ambos enfoques, la “prueba de sistemas” se puede


definir como:

Cualquier actividad realizada para evaluar la calidad del producto


identificando defectos y problemas, y mejorar esa calidad si se
consideran los resultados obtenidos.

Esto implica entonces, que, por ejemplo, hacer inspecciones de código,


controles de escritorio, revisiones de requerimientos, es también hacer
pruebas.

Considerando el enfoque dinámico, se define a las pruebas como:

Pruebas de Sistemas – Ana Carolina Ferreyra | 7


La verificación dinámica del comportamiento de un programa contra
el comportamiento esperado, usando un conjunto finito de casos de
prueba seleccionados metodológicamente de un conjunto infinito de
casos de ejecución.

Dinámica: implica que para realizar las pruebas hay que ejecutar el
programa para los datos de entrada.

Comportamiento esperado: debe ser posible decidir cuando la


salida observada de la ejecución del programa es aceptable o no, de
otra forma el esfuerzo de la prueba es inútil. El comportamiento
observado puede ser revisado contra las expectativas del usuario,
contra una especificación o contra el comportamiento anticipado por
requerimientos implícitos o expectativas razonables.

Otras definiciones que podemos tomar de la IEEE2 en su Std. 610


(1990) que lo define ya como un proceso de operar el sistema o
componente, bajo ciertas condiciones específicas, observar su
comportamiento, registrar los resultados, y realizar una evaluación de
algún aspecto del sistema o componente.’

Entonces:

Es el proceso de ejercitar el sistema para detectar errores y verificar


que satisface las especificaciones de requerimientos funcionales y no
funcionales.

Traemos esta definición porque menciona requerimientos funcionales


y no funcionales, es decir, todo lo que tiene que ver con la función
requerida, y todo lo que no tiene que ver con función, y que
normalmente no es requerido de manera explícita, por ejemplo, si es
fácil de usar, si las funciones se ejecutan en los tiempos necesarios y
coherentes, si es adaptable, entre otros.

1.2. Términos relacionados


y definiciones
Dentro de esta disciplina comienzan a manejarse una serie de términos
de los cuales debemos conocer su significado. Tan es así que el ISTQB3
(2011) ha definido un glosario de términos para establecer un
vocabulario común entre los profesionales del testing, además de
homologar las traducciones con sus regionalizaciones.

2
Institute of Electrical and Electronics Engineers
3
International Software Testing Qualifications Board

Pruebas de Sistemas – Ana Carolina Ferreyra | 8


Cualquier profesional relacionado con las pruebas de sistemas debe
conocer lo que se define como caso de prueba, debe tener en claro la
diferencia entre validar y verificar, y también cuando hablamos de un
error, una falla o un defecto, debe entender su acepción.

1.2.1. Error-falla-defecto
El ISTQB (2011) definió los conceptos de error- falla-defecto, haciendo
una distinción entre cada uno de ellos y los profesionales del medio los
han adoptado internacionalmente.

Error: es la acción humana de equivocarse.

Falla: es la diferencia entre el resultado esperado y el realmente


obtenido, es decir que es una desviación del componente o del
sistema en lo que es su resultado esperado.

Defecto: se llama de este modo al desperfecto en un componente o


sistema que puede causar que el componente o sistema falle en
desempeñar las funciones requeridas, por ejemplo, una sentencia o
una definición de datos incorrectas.

¿Es correcto decir que un error lleva a uno o más defecto que están
presentes en un componente de software?

¿O que un defecto ocasiona cero, una o más fallas?

Claro que sí. El acto de equivocarse (error) lleva a un desperfecto, que


podría ser un error en el código (defecto), así pues, si durante la
ejecución se localiza ese defecto puede causar un fallo en el
componente o sistema (falla). Entonces un defecto no siempre causa
una falla, el software falla si se ejecuta esa parte del código donde se
encuentra el defecto.

Habiendo ya realizado las pruebas, si un defecto no se detectó, ¿qué


puede suceder?

Pruebas de Sistemas – Ana Carolina Ferreyra | 9


Puede suceder que una vez el sistema funcionando en el entorno real,
se produzca la falla.

De esto se deduce que las pruebas tienen que estar enfocadas en


provocar que el software falle para detectar el defecto vigente antes que
lo detecte el usuario o cliente.

Entonces, ¿qué detectamos durante las pruebas?


¿Fallas o defectos?

Con las pruebas, propiamente dichas, estamos buscando provocar


fallos y todos esos fallos pueden deberse al mismo problema o al mismo
error de código (defecto).

A partir de aquí, ya entendiendo estos conceptos, no los emplearemos


indistintamente, sino que, cuando hablemos de fallas, sabremos que es
cuando el sistema tiene un comportamiento no esperado o distinto al
esperado y cuando hablemos de defecto, estaremos indicando un
desperfecto.

Al realizar pruebas propiamente dichas, nos estamos refiriendo a


ejecutar casos de pruebas que se construyen con el único fin de
provocar fallos. Sin embargo, ¿qué es un caso de prueba o cómo se
define?

1.2.2. Caso de prueba


La IEEE en su Std. 829 (2008), define:
Caso de prueba como la documentación que especifica las entradas,
los resultados previstos o esperados, y un conjunto de condiciones
de ejecución de un elemento de prueba.

Su traducción en inglés es test case y en la diaria profesional se adopta


este término en inglés sin su traducción al castellano.

Según la IEEE en el Std. 610 (1990), la descripción de un caso de


prueba incluye, al menos, la siguiente información:

 Precondiciones
 Conjunto de valores de entrada
 Conjunto de resultados esperados
 Pos-condiciones esperadas
 Identificador único
 Dependencia de otros casos de prueba
 Referencia al requisito que será

Pruebas de Sistemas – Ana Carolina Ferreyra | 10


 Forma en la cual se debe ejecutar el caso de prueba y verificar los
resultados (opcional)
 Prioridad (opcional)

Analizando estas referencias y sosteniendo un enfoque sistémico, el


caso de prueba contiene entradas, proceso y salidas.

La entrada comprende:

 El conjunto de datos a ingresar para ejecutar el caso de


prueba.

 Las pre-condiciones necesarias para poder ejecutar


correctamente el caso de prueba. Éstas pueden ser:

o De entorno, es decir, en qué sistema operativo, con qué


productos corriendo, entre otras.

o De software, es decir, en qué lugar se debe empezar, qué


opción de menú tiene que estar disponible, entre otras.

El proceso es el conjunto de acciones a realizar para ejecutar el caso


de prueba, que partiendo de los datos de entrada, deberán producir los
datos esperados como resultado.

La salida es el conjunto de resultados que deben estar pre-


establecidas, es decir, ser conocidas y previstas antes de la primera
ejecución del caso de prueba o lo que es lo mismo, se deben especificar
en el momento de definir el caso de prueba.

¿Cuál es la diferencia entre un buen caso de prueba y un caso de


prueba exitoso?

Un buen test case es aquel que tiene alta probabilidad de detectar un


defecto aún no descubierto, en cambio, se llama caso de prueba exitoso
a aquel que detecta un defecto aún no descubierto.

Como corolario de lo anterior, se dice el desarrollo exitoso, puede llevar


a pruebas no exitosas, es decir, que no encuentra defectos.

1.2.3. Verificación y Validación


Muchas veces empleamos de manera indistinta las palabras validar y
verificar, pero en Ingeniería de Software tienen significados diferentes.

Pruebas de Sistemas – Ana Carolina Ferreyra | 11


¿Por qué hablar de verificación y validación en pruebas de sistemas?
Según muchos autores dedicados a la Ingeniería de Software, como
Roger S. Pressman (2006), exponen que la Verificación y Validación
contienen a muchas de las actividades incluidas en el aseguramiento de
la calidad de software, y las pruebas tienen un papel bien importante en
este punto.

La norma ISO 9000 (2008) define a estos términos en sus puntos 3.8.4
y 3.8.5 de la siguiente manera:

“Verificación
Confirmación mediante la aportación de evidencia objetiva (3.8.1) de
que se han cumplido los requisitos (3.1.2) especificados.”

“Validación
Confirmación mediante la aportación de evidencia objetiva (3.8.1) de
que se han cumplido los requisitos (3.1.2) para una utilización o
aplicación específica prevista.”

Considerando estas definiciones se tiene que ambas son una


comprobación, con la diferencia que la validación es la comprobación
con respecto a su usabilidad final, es decir para ver si funciona o no el
producto para lo cual se construyó. Para aclarar un poco más, ver si un
producto al final del proceso de desarrollo cumple con sus funciones
técnicas.

Aplicado a la Ingeniería de Software, podemos decir que:

Verificación y Validación es el proceso que asegura que el software


bajo desarrollo o cambio implementado:

1. Satisfacen los requerimientos funcionales y otros


requerimientos (validación)
2. Cada paso en el proceso de desarrollo de software
produce el producto correcto (verificación)

A partir de aquí, Boehm (1981) plantea dos preguntas claves


que ayudan a comprender ambos conceptos.

¿Estamos construyendo el sistema correctamente?


¿A qué responde?
Responde a la Verificación

¿Estamos construyendo el sistema correcto?


¿A qué responde?
Responde a la Validación

Pruebas de Sistemas – Ana Carolina Ferreyra | 12


Hoy, las pruebas son vistas como algo más que validación. Como
muestra de ello, tomamos la comparación que hace Boris Beizer (1983)
entre las pruebas de sistemas y la inspección de un edificio, en la que
muestra que si se prueba únicamente considerando los requisitos del
usuario final, sería como si se inspeccionara un edificio considerando
sólo el trabajo realizado por el diseñador de interiores, y sin tener en
cuenta los cimientos, las vigas ni las instalaciones.

1.2.4. Normas y estándares para


pruebas de sistemas:
Norma ISO 9126, IEEE,
CMM, TMM
Volviendo a la perspectiva histórica, allá por la a del 80’ junto con la
tercera visión de las pruebas donde son consideradas como un proceso,
comienzan los primeros estándares relacionados. Éstos han ido
creciendo y evolucionando y, es hoy, que contamos con una serie de
normas, modelos y estándares relacionados con las pruebas.

¿Qué relación tiene esto con las pruebas?

Como profesionales de la informática debemos estar de acuerdo que el


objetivo último de la Ingeniería de Software es producir software de
alta calidad. En el desarrollo de software se trabaja en base a
expectativas de los usuarios o clientes4 y es ahí donde está el problema
ya que normalmente no se expresa lo que realmente se quiere.

La calidad se basa en lo que alguien quiere y como alguien lo quiere.

Aplicado a la calidad de software, Roger S. Pressman la define


como:

“El cumplimiento de los requisitos de funcionalidad y desempeño


explícitamente establecidos, de los estándares de desarrollo
explícitamente documentados y de las características implícitas que
se esperan de todo software desarrollado profesionalmente.” (Roger
S. Pressman, 2006, p. 463)

Aquí destacamos dos puntos como más relevantes. Primero habla de


requisitos de funcionalidad que es todo aquello que se dice o expresa
que se espera del software. Es lo que podemos llamar características
explícitas. Y al final, habla de las características implícitas. En software
ocurre muy a menudo que el cliente no solicita algo, pero que lo espera.
Por ejemplo, el cliente solicita que su sistema emita determinado
4
Se dice cliente o usuario sabiendo las diferencias entre uno y otro.

Pruebas de Sistemas – Ana Carolina Ferreyra | 13


reporte, pero deja como implícito que esté en un tipo de fuente que sea
legible, o que se genere en un tiempo acorde a las necesidades de su
negocio.

Habiendo comprendido lo que es calidad de software, y habiendo visto


ya lo conceptos de Verificación y Validación, podemos afirmar entonces
que las pruebas son una actividad más que se realiza como parte del
aseguramiento de calidad, de ahí que las pruebas de sistemas deben ir
de la mano con la calidad. Esto no significa que:

 Las pruebas sean una barrera para todos los defectos existentes en
el software

 Aumentar las pruebas incremente la calidad.

La calidad no se compra, es un esfuerzo entre todos. Al respecto dice


Pressman:

“Si no está ahí antes de que empiece la prueba, no estará cuando


termine.” (Pressman, 2006, p 384)

La calidad debe medirse y necesitamos una forma de medir la calidad


que sea comprensible a todos, expresada en un lenguaje accesible a
todos para indicar dónde están los principales problemas a atacar.

Según (Pressman, 2006, p. 464) los factores que afectan la calidad de


software se dividen en dos grupos. Uno, llamados directos, que son los
que miden directamente a través, por ejemplo de cantidad de defectos
descubiertos sobre casos de pruebas corridos. Y otro, indirectos, que
son los que miden indirectamente como puede ser por ejemplo, la
facilidad de uso del producto.

A veces resulta difícil y hasta imposible desarrollar medidas directas de


estos factores pero aunque se midan subjetivamente o derivados de una
lista de comprobación, por lo menos se tiene una idea o se le asigna una
graduación y eso ayuda como base valiosa para evaluar la calidad de
software.

Ya pasando a los estándares relacionados tenemos por un lado, la


Norma ISO 9126 y el Modelo de Mc Call orientados a los factores o
atributos de calidad en relación al producto5. Más adelante veremos la
ISO 9001 y el Modelo CMMI orientados al proceso de pruebas.6

Modelo de McCall
El modelo de Jim McCall, desarrollado inicialmente para la Fuerza
Aérea de los EE.UU en 1977, es uno de los más renombrados
actualmente ya que busca reducir la brecha entre usuarios y

5
Cuando decimos producto nos estamos refiriendo al producto que es generado por
un proceso de desarrollo de software, pudiendo ser un sistema, un programa, una
aplicación, un componente.
6
Para cada uno de los modelos, estándares y normas, veremos lo que nos interesa a
los efectos de esta materia. No se desarrollará el contenido de cada uno de ellos.

Pruebas de Sistemas – Ana Carolina Ferreyra | 14


desarrolladores enfocándose en un número de factores de calidad que
reflejen las prioridades de ambos.

El modelo establece una jerarquía de Perspectivas, Factores, Criterios


de Calidad y como fin último, las Métricas.

Es muy rico porque logra definir métricas para los factores de calidad,
además de dar un significado para cada uno de los factores. Cuando se
dice que se requiere que el software sea fácil de usar, lo que se está
requiriendo es que cumpla con el factor de Facilidad de Uso. Pero, ¿qué
significa? La Facilidad de Uso puede tener definiciones dispares para
diferentes personas, y lo que significa fácil de usar para unos, no es lo
mismo que para otros. Este modelo permite unificar.

Explicamos entonces cómo se estructura:

El modelo de McCall se basa en 11 factores de calidad, organizados en


torno a tres perspectivas:

Operación del producto: Corrección, Confiabilidad, Facilidad de Uso,


Integridad, Eficiencia.

Transición del producto: Portabilidad, Facilidad de Reutilización,


Interoperabilidad.

Revisión del producto: Facilidad de Mantenimiento, Flexibilidad,


Facilidad de Prueba.

A partir de esos factores, toma a cada uno de ellos y los abre en


criterios. Por ejemplo, el factor Facilidad de uso se abre Facilidad de
operación, Facilidad de Comunicación y Facilidad de Aprendizaje.
Siguiendo con otro ejemplo, Flexibilidad se abre en Auto descripción,
Capacidad de expansión, Generalidad y Modularidad.7

A continuación plantearemos un ejemplo de aplicación de cierta lista


de chequeo para la obtención de una de las métricas. Se trata de una
simple lista de chequeo orientada al criterio Completitud. Para evaluar
la completitud en un producto software es necesario dar respuesta a
esta lista de comprobación.

Las letras R, D e I indican si la lista de comprobación es aplicable a los


requisitos (R), el diseño (D) y/o la implementación (I). Se contesta a
estas preguntas con un SÍ o NO.

1. No hay referencias ambiguas [R,D,I]

2. Todas las referencias a datos definidas son calculadas u


obtenidas de una fuente externa [R,D,I]

3. Todas las funciones definidas son utilizadas [R,D,I]

4. Todas las referencias a funciones están definidas [R,D,I]

7
Sobre cada uno de los factores Ud. puede consultar el significado en la bibliografía
básica.

Pruebas de Sistemas – Ana Carolina Ferreyra | 15


5. Se han definido todas las condiciones y procesamientos para
cada punto de decisión [R,D,I]

6. Concuerdan todos los parámetros de llamada a funciones


definidos y referenciados [D,I]

7. Todos los informes de problemas se han resuelto [R,D,I]

8. El diseño concuerda con los requisitos [D]

9. El código concuerda con el diseño [I]

Luego se aplica la siguiente fórmula matemática que da como resultado


el grado o nivel de calidad para dicho atributo:

De esta forma, la medida para la completitud es un número entre 0 y 1.

La “corrección” depende de la “completitud”, la “trazabilidad”, y la


“consistencia”. Entonces, de la misma manera que está esta lista de
comprobación para la completitud, existe otro recurso aplicable a la
trazabilidad y así sucesivamente.

La medida para la corrección, por ejemplo, se calculará aplicando la


fórmula: (x+y+z)/3

Donde x es la medida para la completitud, y la medida para la


trazabilidad y z la medida para la consistencia. Para que todas las
métricas se puedan combinar sin problemas, lo habitual es que se
normalicen sus valores dentro del intervalo [0,1].

¿Qué indicaría el valor más cercano a 1?


¿Qué indicaría el valor más cercano a 0?

Llegamos hasta el desarrollo de aplicación de una métrica para que se


pueda demostrar lo que antes se dijo al respecto: ‘aunque se midan
subjetivamente o derivados de una lista de comprobación, por lo
menos se tiene una idea o se le asigna una graduación y eso ayuda
como base valiosa para evaluar la calidad de software.’

Norma ISO 9126


Es un estándar internacional para la evaluación de la calidad de
software que si bien se deriva del anterior Modelo de McCall, recoge las
investigaciones de muchos modelos de calidad propuestos por

Pruebas de Sistemas – Ana Carolina Ferreyra | 16


profesionales del tema de los últimos treinta años. Ya a partir del 2005
fue reemplazada por la ISO 25000:2005.

La ISO 9126 (2001) propone un modelo de calidad que se divide en tres


vistas: interior, exterior y en uso. Estas vistas están compuestas por
características (en total 6), que se dividen en sub-características, y que
éstas a su vez se componen de atributos, es decir una entidad que
puede ser verificada o medida en el producto software.

De la misma manera que se definen tres vistas, las mediciones


realizadas dan como resultado una serie de métricas que se clasifican
en tres categorías según sea su naturaleza:

o Métricas internas: aquellas que no dependen de la


ejecución del software (estáticas).

o Métricas externas: aquellas aplicables al software en


ejecución (dinámicas).

o Métricas de uso: sólo disponibles cuando el producto


final es usado en condiciones reales.

En el siguiente gráfico se pueden ver las seis características y las sub-


características asociadas.

Adecuación
Precisión
FUNCIONALIDAD Interoperabilidad
Seguridad

Madurez
CONFIABILIDAD Tolerancia a falla
Recup. de fallas

Facil. de comprensión
Facil. de aprendizaje
USABILIDAD Facil. de operación
Atractivo
ISO 9126
Tiempo de respuesta
EFICIENCIA Utiliz. de recursos

Facil. de análisis
Facil. de cambio
MANTENIBILIDAD
Estabilidad
Facil. de prueba

Adaptabilidad
Facil. de instalación
PORTABILIDAD
Coexistencia
Facil. de reemplazo

Pruebas de Sistemas – Ana Carolina Ferreyra | 17


Las visiones de calidad permiten definir modelos de calidad (conjunto
de características), estos modelos permiten definir propiedades del
producto y del proceso y en base a estas propiedades definimos
métricas; a partir de las éstas se realiza la Gestión de Calidad para
asegurarla.

En ninguno de los dos casos vistos se tiene el tema resuelto respecto de


las mediciones de la calidad de software, pero sí ambos casos proveen
un entorno para que las organizaciones definan un modelo de calidad
para su producto software.

Cada organización tiene la tarea de especificar precisamente su propio


modelo, con base en éstos u otros e incorporando otros atributos o
factores que le puedan resultar necesarios alcanzar. Esto podría ser
hecho especificando los objetivos para las métricas de calidad (evalúan
el grado de presencia de los atributos de calidad).

Hasta aquí vimos lo que es orientado al producto, ahora pasamos a la


Norma ISO 9001 y el Modelo CMMI orientados al proceso de pruebas.

Norma ISO 9000:2005


Se puede decir que son reglas básicas de calidad, independientes del
producto o servicio de que se trate. Se definen como un conjunto de
buenas prácticas de fabricación de un producto u ofrecimiento de un
servicio. Es un modelo que da seguridad que el proveedor tienen la
capacidad de producir los bienes o servicios requeridos.

En forma complementaria a la ISO 9000 existe el documento ISO


9000-3, el cual es una guía específica para la aplicación de la norma
ISO 9001 al desarrollo y mantención de software. La ISO 9000-3 está
dividida en 3 partes:

 Marco de trabajo
 Actividades en el ciclo de vida
 Actividades de apoyo

Específicamente en lo relativo a las pruebas en general, establece los


siguientes elementos principales:

a) Las pruebas deben ser realizadas en varios niveles, desde el ítem


de software individual hasta el producto completo.

b) En algunas ocasiones la validación, la prueba de campo y la


prueba de aceptación pueden ser una sola actividad.

c) El documento que describe el plan de pruebas puede ser un


documento independiente o estar compuesto de varios
documentos.

 Relativo a la planificación de las pruebas

Pruebas de Sistemas – Ana Carolina Ferreyra | 18


Dentro de lo que es la Planificación de las pruebas se debe contemplar:
a) Planes para realizar las pruebas de unitarias, integración,
sistema y aceptación.
b) Definición de casos de pruebas, datos de prueba y resultados
esperados.
c) Tipos de pruebas a realizarse, por ejemplo, prueba funcional,
prueba de límites, pruebas de rendimiento, prueba de
usabilidad.
d) Especificar ambiente de pruebas, herramientas y técnicas de
pruebas de software.
e) Criterios de completitud en las pruebas.
f) Documentación disponible (requerimientos, diseño, otros).
g) Personal y entrenamiento requerido.

 Relativo a la validación del Proveedor

Antes de entregar el producto y la prueba de aceptación del usuario, el


proveedor debe validar su operación como un producto completo y si es
posible bajo condiciones similares al ambiente que tendrá la aplicación
de acuerdo a lo especificado en el contrato.

 Relativo a la aceptación del comprador

Cuando el proveedor está listo para entregar el producto validado, el


comprador debe juzgar si el producto es aceptable de acuerdo a los
criterios estipulados con el contrato. El método de manejar los
problemas detectados durante la prueba de aceptación debe ser
acordado entre el comprador y el proveedor y documentado.

 Recursos y personal para verificación

El proveedor deberá identificar internamente los requerimientos,


proveer los recursos adecuados y asignar personal entrenado para las
actividades de verificación. Las actividades de verificación deben
incluir:
o Inspección
o Pruebas
o Monitoreo del diseño, producción, instalación, y
procesos de servicio o productos
o Revisiones del diseño
o Auditorías del sistema de calidad, procesos y /o
productos.
Todo debe ser realizado por personal independiente de
aquel que tiene directa responsabilidad por el trabajo
que está siendo desarrollado.

Modelo CMMI8
Tiene su origen en el Departamento de Defensa, USA. Es un modelo
para la mejora y evaluación de procesos para el desarrollo,

8
Integración de modelos de madurez de capacidades

Pruebas de Sistemas – Ana Carolina Ferreyra | 19


mantenimiento y operación de sistemas de software. Fue uno de los
mayores aportes para superar la “crisis de software”.

¿Cuál es la idea de este modelo? Evaluar el proceso:

 ¿Cuán “bueno” es mi actual proceso?


 ¿Cuáles son mis fortalezas y debilidades?
 ¿Qué debo hacer para mejorar?

 Y, mejorarlo:
o Pasos requeridos para iniciar el cambio
o Acciones que resultan más rentables
o Métodos para un control cuantitativo
o Cómo ir de un enfoque de corrección de problemas a un
enfoque de prevención

Se estructura en 5 niveles que explicaremos brevemente:

Inicial (Nivel 1): Se opera sin procedimientos formales, sin


estimaciones ni planes y las herramientas no están bien integradas.
No hay buena información acerca de los problemas y asuntos
internos y no existe un control de cambio riguroso. Por todo esto, la
instalación y mantenimiento de software a menudo presenta
problemas.

Repetible (Nivel 2): En este estado, superior del anterior, la


organización ha logrado un rendimiento estable a través de una
administración de compromiso, costos, planificación y control de
cambios. Esta estabilidad se traduce en un conjunto de acciones
diseñadas para lograr controlar los costos y plazos. Hay
Organización, administración de proyectos, administración del
proceso de desarrollo y tecnología.

Definido (Nivel 3): Ya en este nivel hay un proceso estándar


definido, se puede decir que hay metodología. Si bien hay escasos
datos cuantitativos, se manejan las contingencias y se puede
mejorar ordenadamente y facilitar la introducción de tecnología de
apoyo.

Administrado cuantitativamente (Nivel 4): Completo proceso de


análisis y medidas, tales como calidad, costo, productividad, entre
otros. Existe un preciso conocimiento de los procesos como base
para una continua calidad de sus productos y un mejoramiento de
la productividad. Existe la asignación de recursos para la
recopilación y mantención de los datos.

Optimizado (Nivel 5): En este nivel, la completa información acerca


del proceso de software es usada para evaluar la efectividad de este
proceso y hacer ajustes en forma regular. Esto provee las bases para
una continua mejora del desarrollo y un ordenado y planificado
aumento de la productividad.

Si bien el término "pruebas de sistema" no es un término usado en


CMMI debido a sus múltiples interpretaciones entre diferentes
disciplinas, no implica que no estén contempladas por el modelo. Por
razones de consistencia y claridad, en vez de "sistema" se han usado los
términos "producto" y "componente de producto". Y en vez de

Pruebas de Sistemas – Ana Carolina Ferreyra | 20


“pruebas” se usaron los términos "verificación" y "validación" porque
las pruebas pueden ser parte de la verificación o validación.

Las pruebas en el modelo CMMI están tratadas principalmente en las


áreas de proceso "Verificación" y "Validación". Si bien, ya vimos el
significado de estos conceptos, que se pueden ampliar consultando
directamente el modelo.

IEEE
La IEEE9 es la sociedad técnica profesional más grande del mundo
dedicada a la estandarización, entre otras cosas. Su trabajo es
promover la creatividad, el desarrollo y la integración, compartir y
aplicar los avances en las tecnologías de la información, electrónica y
ciencias en general para beneficio de la humanidad y de los mismos
profesionales.

Se listarán algunos de sus estándares relacionados a las pruebas y que


son los más consultados dentro de la comunidad de probadores,
demostrando la importancia internacional que tienen las pruebas. Se
encuentra:

IEEE 610 (1990): estandariza una terminología. Si bien no es una


terminología específica de pruebas, ya que es de Ingeniería de
Software, incluye todos los términos relacionados a las pruebas, por lo
cual es utilizada en común por los profesionales de pruebas.

IEEE 829 (2008): desarrolla una estructura de plan de pruebas


maestro acreditada que incluye: descripción de un caso de prueba,
contenido de un informe de estado de pruebas, estructura de un
informe de incidencias, entre otros puntos.

IEEE 730 (2002): estructura y da los contenidos de un plan de


calidad, asociación indispensable con las pruebas de sistemas.

IEEE 1028 (2008): dedicado exclusivamente a las revisiones, cómo


deben hacerse y qué deben incluir.

9
En español: Instituto de Ingenieros Eléctricos y Electrónicos.

Pruebas de Sistemas – Ana Carolina Ferreyra | 21


1.3. Principios de las
pruebas y su
Psicología
Comenzaremos explicando qué consideramos un principio: es
considerado una verdad aceptada, que encarna una idea sobre la
disciplina de las pruebas.

Entendemos así que estos principios, en cualquiera de los autores que


tomemos, surgen a partir de las premisas de lo que son las pruebas, de
su psicología y de los puntos clave o guía que pueden ser identificados.

Al presentarlos pueden parecer intuitivamente obvios, sin embargo son


muchas veces pasados por alto y no tenidos en cuenta a la hora de
hacer las pruebas.

Según los diferentes autores y comunidades de pruebas, la lista de


principios va cambiando tanto en cantidad como en contenido. Bill
Hetzel (1988) estableció, por ejemplo, seis principios fundamentales.
Pasando por otros autores o comunidades los mismos van cambiando,
y con el correr de los años, ante los cambios de procesos, metodologías,
y evolución que va teniendo esta disciplina, los principios
fundamentales de las pruebas no son ajenos a este crecimiento.

Comenzaremos por los principios que datan de la década de los 80,


pero también daremos algunos más actuales que demuestran la
evolución.

 Principio N°1: La prueba completa no es posible.

De la siguientes expresiones que frecuentemente escuchamos, como


“Pararé de probar cuando esté seguro que funciona”, o
“implementaremos el sistema tan pronto como todos los errores
sean corregidos”. Podemos ver que asumen que la prueba es una
actividad que puede terminar y que siempre se tiene la certeza que
todos los defectos son removidos. No podemos esperar lograr la
prueba completa, o lo que otros autores denominan la prueba
exhaustiva por dos razones: una, limitaciones prácticas y dos,
imposibilidad teórica.

Dado cualquier programa por más pequeño y simple que sea, será
imposible ejecutar todos los casos de pruebas posibles. Tomando un
ejemplo similar al dado por Hetzel (1988), donde un simple programa
recorre una lista de palabras e imprime el primero que encuentra bajo
la cadena “PRUEBA”, ¿cómo podremos determinar cuándo hemos
terminado de probarlo completamente?

Pruebas de Sistemas – Ana Carolina Ferreyra | 22


¿Qué probaremos? ¿Dos casos únicamente? Uno, con una lista que
tenga la palabra PRUEBA y otro, con una lista que no la contenga
¿Probaremos diferentes longitudes de listas? ¿Importa que probemos
con la palabra PRUEBA en diferentes partes de la lista?

Todas estas son variables que podrían posiblemente afectar el


funcionamiento apropiado de un programa. Entonces, ¿cuántas
pruebas son suficientes?

Los probadores o testers deben seleccionar un pequeño set de pruebas


que incluye estas posibilidades. Y ese set debe ser lo suficientemente
grande para proporcionar un nivel satisfactorio de confianza, pero no
tan grande que resulte impráctico de administrar.

Y si no podemos testear todo, ¿qué podemos hacer?

 Gestionar y reducir el riesgo.


 Priorizar los casos para enfocar las áreas principales de
riesgo.
 Distribuir el tiempo de pruebas según el grado de los riesgos
involucrados.
 Entender el riesgo del negocio.

 Principio N°2: El trabajo de pruebas es creativo y difícil.

Existen falsas creencias como que:


o Hacer pruebas es fácil
o Cualquiera puede hacer pruebas
o No se requiere ni experiencia previa ni entrenamiento
o Hacer pruebas es aburrido y rutinario
o No está involucrado personal senior, y que el personal de
pruebas no tiene crecimiento profesional, salvo que pase
a desempeñarse como programador.

Lo cual no es así, ya que para probar efectivamente se debe entender el


sistema a fondo y los sistemas no son ni simples, ni sencillos de
comprender. No se puede comenzar a diseñar y desarrollar una prueba
efectiva hasta que no se haya detalladamente entendido lo que se
supone que hace el sistema. Mientras para esto se destinan a los
mejores analistas de negocios, se asume equivocadamente que los
probadores o testers deben tener este conocimiento como
prerrequisito.

Hetzel (1988) establece los siguientes ingredientes esenciales para una


buena prueba:

 Creatividad e intuición
 Conocimiento de negocio
 Experiencia en pruebas
 Metodología de pruebas

A través de un libro, un curso o una materia se pueden aprender las


metodologías de pruebas y también tener una perspectiva para

Pruebas de Sistemas – Ana Carolina Ferreyra | 23


aprender de la experiencia colectiva. Mientras el conocimiento del
negocio se aprende en el trabajo, la creatividad e intuición no se
pueden enseñar, dependen del individuo.

 Principio N°3: Una importante razón de las pruebas de sistemas


es prevenir que ocurran las deficiencias.

Si bien muchos profesionales no ven a las pruebas como una actividad


de prevención de defectos y sí como la actividad de encontrarlos, este
principio está enfocado en una de las últimas visiones que abraza el
concepto de pruebas a lo largo del ciclo de vida de desarrollo y no que
la prueba es una fase. Hay muchos entregables asociados a cada fase de
desarrollo sobre los cuales se pueden hacer pruebas que ayuden a
detectar de manera temprana las deficiencias que podrían estar
presentes. De este modo, no resulta tan costosa su corrección y se
pueden prevenir los problemas posteriores derivados. El mejor proceso
de pruebas es el que da rápido feedback.

También abarca la creencia que, pensar primero los casos de pruebas


con los que se va a probar, ni bien se han definido los requerimientos,
ayuda a evitar ciertos errores o darse cuenta que existen deficiencias,
además de incrementar nuestro conocimiento sobre el sistema.

Otros autores llaman a este principio como “Pruebas tempranas”.

La tarea de diseñar los casos de pruebas es un mecanismo de los más


efectivos de prevención de errores… El proceso de crear los casos de
pruebas buenos, si es pensado, puede descubrir y eliminar problemas
de cualquiera de las etapas de desarrollo. (Beizer, 1983)

 Principio N°4: La prueba se basa en el riesgo.

Una buena prueba es basada en el riesgo… ¿en el riesgo de qué? En el


riesgo de falla.

¿Cuántas pruebas se está dispuesto a realizar si se tiene una baja


probabilidad de ocurrencia de una falla? De la misma manera,
¿Cuántas pruebas se está dispuesto a realizar para encontrar un defecto
que costaría la vida encontrarlo?

La cantidad de pruebas que deberíamos hacer depende directamente


en el riesgo involucrado. Sistemas con alto riesgo requieren más casos
de pruebas y más énfasis en las pruebas, por el contrario, programas
con bajo riesgo o con un impacto de falla limitado no justifican la
misma prueba.

Este principio es corolario del primer principio, si no podemos probar


todo, debemos priorizar y adecuarnos a los recursos disponibles. El
riesgo debe ser usado como la base para asignar el tiempo disponible
para pruebas y para ayudarnos a hacer la selección de qué pruebas
hacer y por dónde priorizar más con las pruebas.

 Principio N°5: La prueba debe ser planeada.

Si bien todos parecen estar de acuerdo con este principio, no todos


están disciplinados en esto de planificar las pruebas. Este principio

Pruebas de Sistemas – Ana Carolina Ferreyra | 24


también es corolario del principio n° 1 (que dice, en otras palabras, que
no se puede probar todo), es que debe hacerse una selección, y una
planificación cuidadosa de las pruebas, y según esa selección que se
haga es lo que diferencia entre una buena prueba o una prueba pobre.

La etapa de planificación dentro de un proceso de pruebas, es


o pensar en un enfoque global,
o diseñar las pruebas
o y establecer los resultados esperados.

Como salida de esta etapa de planificación está el plan de pruebas que


define los objetivos y enfoque de las pruebas. Puede ser formal, si es
escrito y está a disposición de manera permanente como un documento
del proyecto. O bien, puede ser informal cuando existe en notas
temporales o en la cabeza de alguien sin la intención de ser grabado o
revisado. Como se puede apreciar, se está considerando la actividad de
diseño de los casos de pruebas dentro de la etapa de planificación,
cuando otras bibliografías lo consideran como dos tareas separadas. A
los efectos de explicar este principio no tiene importancia.

 Principio N°6: La actividad de pruebas requiere independencia.

Cuando se requiere una medición objetiva, se requiere una persona


objetiva e imparcial que haga esa medición.

Lo mismo ocurre con las pruebas, por dos motivos:

1. Las personas tienden a pasar por alto sus propios


defectos, así entonces, los desarrolladores corren el
riesgo de no reconocer defectos evidentes.

2. El desarrollador nunca va a analizar su “creación” (el


código generado) de forma imparcial ya que tiene con él
un apego afectivo, aunque él conoce el objeto de prueba
mejor que nadie.

Esto puede resultar contradictorio a la premisa de que ‘no se puede


probar lo que no se conoce’. Las personas a cargo de las pruebas deben
estar involucradas en el proceso de desarrollo desde sus inicios, pero al
momento del desarrollo de las pruebas deben ser desarrolladas por
personas imparciales y objetivas.

Los programadores entienden el sistema y por ello son


condescendientes con él, y fundamentalmente están dirigidos por el
“entregable”. Por el contrario, los probadores o testers deben lograr
entender el sistema para probarlo, pero en su tarea de probar
intentarán provocar fallas, y lo que es muy importante, están dirigidos
por la calidad. Deben estar comprometidos con la búsqueda de errores
y no con la defensa del sistema.

Hay distintos niveles de independencia según las organizaciones,


que van desde los niveles de cero independencia a los niveles más
altos. Entonces, las pruebas puede hacerlas:
o Quien escribe el código
o Otra persona
o Una persona de diferente sección
o Otra persona de diferente organización

Pruebas de Sistemas – Ana Carolina Ferreyra | 25


o La selección de casos no la hace una persona, sino una
herramienta.

Además de estos principios, presentaremos aquí ciertas premisas


que pueden tomarse como principios o derivados de los dados,
pero que resultan interesantes de tenerlos en cuenta.

 Los casos de pruebas deben ser escritos tanto para condiciones


de entradas válidas y esperadas, como para inválidas e
inesperadas.

Como corolario de lo anterior se dice una parte de las pruebas


es probar un programa para ver si no hace lo que se supone que
hace, y la otra parte, es probar si un programa hace los que no
se supone que hace.

Myers (1979), entre sus varios principios, aporta éste que


resulta interesante en la explicación que da, pero que deja de
tener vigente debido a la magnitud que ha tomado hoy, el
mantenimiento de software.

 Evite desechar los casos de pruebas a menos que el programa


sea ya un verdadero programa.

Aún es frecuente ver en la práctica que quienes realizan las


pruebas, se sientan en una terminal, inventan casos de pruebas
en el aire y comienzan a ejecutarlos sobre el programa. El caso
es que los casos de pruebas son una valiosa inversión que en la
situación planteada, desaparece después que las pruebas son
ejecutadas. Entonces, cuando el programa requiere ser probado
nuevamente, reinventar los casos de pruebas requiere una
cantidad de trabajo que ciertamente pocas veces se hace. Esto
lleva a que el retesting del programa raramente es tan riguroso
como la prueba original y todo lo que eso trae aparejado.

Este principio carece de toda importancia, si se tiene un proceso


de pruebas maduro donde el diseño de casos de pruebas se
realiza y queda registrado, y la ejecución se hace contra ese
diseño.

 Nunca planificar el esfuerzo de pruebas suponiendo que no se


encontrarán errores.

Suele ser un error frecuente entre los gerentes de proyectos


además de reflejar una incorrecta visión de las pruebas que es
asumir que las pruebas son el proceso de mostrar que programa
funciona correctamente.

 La probabilidad de existencia de más errores en una sección de


un programa es proporcional al número de errores ya
encontrados en esa sección.

Hay innumerables ejemplos medidos que datan desde el


nacimiento de este principio, allá por 1979, cuando Glendford J.
Myers lo escribe en su libro “The art of software testing”.
Actualmente se aplica la conocida Ley de Paretto (con cierto
grado de verdad) que dice que el 80% de los defectos se

Pruebas de Sistemas – Ana Carolina Ferreyra | 26


encuentran en el 20% del código base. Por ende, si una
aplicación tiene 1000 errores conocidos y se mira el detalle de
cómo se distribuyen, quizás la mayoría estén agrupados en el
20% de los módulos del sistema.

Hasta aquí hemos desarrollado los principios de Bill Hetzel y algunos


más. A continuación listaremos los siete principios dados por el ISTQB
(2011), más actuales, desarrollando todo aquello que consideramos que
agregan a lo anterior.

1. El proceso de pruebas demuestra la presencia de defectos: este


principio atiende a la psicología misma de las pruebas. Dicho de
manera contraria, no se tiene que probar para demostrar que
funciona y tiene que ver con el último principio de la
independencia de las pruebas, ya que eso de demostrar que
funciona, es una acción natural del programador. Si las pruebas
reducen la probabilidad de presencia de defectos que permanezcan
sin ser detectados, entonces se deben seleccionar datos para los
casos de pruebas que pueden detectar errores.

2. No es posible realizar pruebas exhaustivas: idéntico al principio


n°1 que dice que “La prueba completa no es posible”.

3. Pruebas tempranas: encubierto dentro del principio n° 3.

4. Agrupamiento de defectos (“defect clustering”): Este principio


merece la explicación, pues no fue contemplado este concepto con
los principios de Hetzel. Sostiene que los defectos aparecen
agrupados como hongos o cucarachas, donde se encontró un
defecto y se encontrarán más “cerca”. De alguna manera, está
requiriendo cierta flexibilidad de los probadores, ya que si bien
pueden contar con un diseño de pruebas que siguen, es importante
considerar el rumbo de las pruebas posteriores. La
identificación/localización de un defecto puede necesitar ser
investigada con un mayor grado de detalle, por ejemplo, realizando
pruebas adicionales o modificando pruebas existentes.

5. Paradoja del pesticida: Pareciera que le fue asignado un nombre de


fantasía. ¿Qué es esto de la paradoja del pesticida? Si siempre se
ejecutan las mismas pruebas de forma reiterada no se podrán
encontrar nuevos defectos, es decir que es como que el sistema se
hace inmune a los casos de pruebas elegidos. Lo que marca este
principio es que repetir pruebas en las mismas condiciones no es
efectivo y que se necesita revisar/modificar las pruebas
regularmente para los distintos módulos.

6. Las pruebas dependen del contexto: simplemente, objetos de


prueba diferentes son probados de forma diferente. Este
principio marca además que si bien siempre habrá
desviaciones entre el entorno de pruebas y el entorno de
producción, debe tratar de minimizar esas diferencias, ya que
estas desviaciones pondrán en tela de juicio las conclusiones
que se obtienen tras las pruebas.

7. La falacia de la ausencia de errores: similar en su explicación


al principio n° 4 de Hetzel, aunque marca claramente que en

Pruebas de Sistemas – Ana Carolina Ferreyra | 27


la mayoría de los casos el proceso de pruebas no detectará
todos los defectos del sistema, pero los defectos más
importantes deberían ser detectados, y que esto por sí solo
no prueba la calidad del software. No se puede introducir la
calidad a través de las pruebas, ella tiene que construirse
desde el principio.

1.4. Niveles de pruebas


Existen tres preguntas elementales que esperamos que cualquier
metodología nos proporcione un medio para poder responder:

 ¿Qué se debe probar? Es decir, ¿cómo elegir un set de


pruebas apropiado para usar en determinada situación?

 ¿Cuándo deben comenzar las pruebas y cuándo deben


parar? Enmarca una serie de preguntas como ¿cuándo se
considera una prueba exitosa y cuándo no? O bien ¿cuándo
debería comenzarse con el trabajo del diseño y construcción
de los casos de pruebas?

 ¿Quién lleva adelante las pruebas? Esto enmarca no sólo


quién hace las pruebas, sino cómo deberían coordinar con el
resto del equipo involucrado en el proceso de desarrollo.

Probar es simplemente seleccionar algo para medir, es decir un


atributo de calidad, desarrollar casos de pruebas con entradas
controladas que ejerciten el programa o revelen algo del atributo a
ser medido, simular situaciones de prueba observando los
resultados en comparación con el comportamiento esperado. Se
considera exitoso si los resultados observados dan con lo esperado
y es no exitoso cuando sucede lo contrario, que los valores
observados no alcanzan a los esperados.

El punto central está en seleccionar qué probar.

Por otra parte, encontramos lo que se denomina como “Economía


de las Pruebas”. El proceso de pruebas de por sí, es un proceso
“caro”, mirado como un costo y no como una inversión. Según los
resultados obtenidos, puede causar la reescritura del código y eso
puede retrasar el proceso de desarrollo.

¿Qué es más económico?


¿Probar y encontrar defectos antes de la entrega al
cliente?
¿No probar y encontrar defectos una vez que está en
producción?

Pruebas de Sistemas – Ana Carolina Ferreyra | 28


¿Qué involucra encontrar un defecto en producción?

Encontrar un defecto en producción puede generar múltiples


consecuencias; dentro de las más importantes están:

 Cambios de requerimientos, especificaciones y código.

 Cambios en los casos de pruebas y rehacer todos los niveles de


pruebas.

 Cambios y reparaciones de lo que está instalado.

 Costo de administración y pérdidas de negocios.

Por esto es que, cuanto antes se detecta un defecto, más barato es


corregirlo. Existen muchas acciones que se pueden llevar adelante para
la prevención de defectos, o la detección temprana y evitar la
multiplicación. Por ejemplo, el análisis de especificaciones durante la
preparación de la prueba, saca a la luz errores en las especificaciones
que si no se encontraran estos tipos de errores, el sistema será
desarrollado de manera incorrecta.

Como conclusión está probar tempranamente el diseño para prevenir la


multiplicación de defectos; probar desde los primeros componentes
individuales y no esperar hasta que esté conformado como un todo.

Hetzel (1988) plantea tres niveles de pruebas elementales.

Los programas individuales son probados como componentes


individuales y las llama “Pruebas de Unidad”, luego los grupos de
programas son probados todos juntos integrando un sistema, a las que
llama “Pruebas de Sistema” y, por último, una vez con el sistema
completo, se hacen las “Pruebas de Aceptación”.

Las organizaciones o los equipos de pruebas pueden hacer las pruebas


pasando por estos tres niveles, donde las pruebas de aceptación pueden
ser llevadas a cabo por los usuarios finales o clientes. También
reconoce otros niveles de pruebas empleados en proyectos más largos y
más complejos, como podrían ser las “Pruebas de Integración”.
Actualmente, por la complejidad de los sistemas, y la interacción que
deben tener con otros sistemas, es inevitable pensar en las pruebas de
integración.

1.4.1. Pruebas de Componente


También conocidas como pruebas de unidad, pruebas unitarias o
pruebas de módulos, según como se denomine a la elemento mínimo
en el lenguaje de programación que se esté empleando, esto es, si se
llama función, clase o componente así se denominará a este nivel de
pruebas.

Pruebas de Sistemas – Ana Carolina Ferreyra | 29


Consiste en la prueba de los componentes más pequeños apenas son
generados.

Cuándo parar de probar es normalmente una decisión del


programador. Además, pueden darle tanto un enfoque de perspectiva
externas con casos de pruebas basados en las especificaciones de lo que
se supone que hace el sistema o bien, un enfoque de perspectiva interna
con casos de pruebas diseñados para ejercitar y cubrir la lógica interna
del programa.

Así como la mayoría de las veces es informal, es decir que no se


mantienen registros de los casos de pruebas corridos ni de los defectos
encontrados, también se puede decir que termina este nivel de pruebas
cuando el programador “se siente conforme o a gusto” con el programa
y ha corregido las deficiencias descubiertas.

También reconoce que unas pocas organizaciones llevan adelante el


testing unitario de manera más formalizada. En el plan de pruebas se
describe qué será testeado y los resultados esperados, que son
establecidos tanto por los programadores como por los diseñadores.
También se establece un criterio de cobertura, es decir, un porcentaje
de código que se deberá ser cubierto con las pruebas, que debe
alcanzarse para decir que la prueba ha sido completa.

Este nivel de pruebas tan relacionado al código, tiene como objetivos


validar:

 Tipos de datos inconsistentes.


 Valores de inicialización y default incorrectos.
 Correspondencia entre parámetros y argumentos en las
llamadas de funciones o módulos.
 Precisión en las funciones de cálculo.
 Comparación entre tipos de datos diferentes.
 Terminaciones de loop impropias o no existentes.
 Variables de loop modificadas inapropiadamente.
 Manejo de errores inadecuado o inentendible.

1.4.2. Pruebas de Integración


Si bien Hetzel (1988) plantea tres niveles elementales de pruebas
(componentes, sistemas y aceptación) también reconoce la
necesidad de otro nivel, que en la actualidad es inevitable, las
Pruebas de Integración.

Pressman (2006) comienza la explicación de este nivel planteando


que sólo un neófito en el mundo del software podría conjeturar: “Si
todo funciona bien individualmente, ¿por qué dudan que funcione
cuando se une?”

Justamente ahí es donde está el punto. Es en la unión de los


componentes donde pueden perderse datos o al combinarse las
funciones no dar el resultado esperado.

Pruebas de Sistemas – Ana Carolina Ferreyra | 30


La prueba de integración es la que está orientada a asegurar que las
unidades individuales operan correctamente cuando se combinan
en la aplicación. Pueden evaluarse:

o Interfaces entre componentes

o Interacciones con diferentes partes de un


sistema (SO, sistema de archivos, hardware)

o Interfaces entre sistemas

No tiene que ser visto como un nivel que se da siempre después del
nivel de sistemas como se encuentra en algunas bibliografías, ya
que:

o La prueba de integración de componentes se


hace una vez que la prueba de componentes
se llevó a cabo.

o La prueba de integración de sistemas se hace


una vez que la prueba de sistemas se llevó a
cabo.

Pero, ¿cómo se hace la integración?

Puede ser de dos maneras: la llamada big bang o incremental.

 Pruebas de Integración “Big Bang”

Este tipo de integración es la que, una vez probados todos los


componentes individuales, se combinan todos de una sola vez y se
prueba como un todo.

¿Qué imagina que puede suceder si al aplicar la integración big bang se


encuentran gran cantidad de errores?

Al no poder aislar las causas de esos errores, es decir, conocer en la


integración de qué partes se originan, es difícil poderlos corregir. Si
una vez corregidos aparecen otros, se entra en un proceso que
pareciera interminable.

 Pruebas de Integración Incremental

Esta modalidad viene a dar solución a lo expuesto anteriormente: “la


antítesis del enfoque Big Bang” (Pressman, 2006, p. 395). Se van
integrando y probando pequeños incrementos del programa, lo que
hace más fácil encontrar la causa de las fallas y así corregir los
defectos.

Pruebas de Sistemas – Ana Carolina Ferreyra | 31


Dentro de esta modalidad de integración existen diferentes
estrategias.

o Integración descendente o top-down: los módulos se van


integrando comenzando por el módulo de control principal al
que se le pueden ir incorporando el resto de los módulos de dos
maneras diferentes: primero-en-profundidad o primero-en
anchura.

o Integración ascendente o bottom-up: se combinan primero los


módulos de bajo nivel que juntos realicen alguna sub-función
específica. La mayoría de las veces es necesario escribir un
controlador que coordine la entrada y salida de los casos de
pruebas para probar los grupos. Una vez probado el grupo, se
eliminan esos controladores y se integra con otros grupos
ascendiendo por la estructura.

¿Qué es un controlador o también llamado driver?

Si se tienen los módulos Y y Z listos pero el módulo de X no está listo


y para probar los módulos Y y Z se necesita que el módulo X
devuelva valores, entonces se escribe una pieza de código ficticio de
X que devuelve valores para Y y Z. Esta pieza de código ficticio es lo
que se llama controlador.

Los controladores aportan el entorno al proceso del sistema o


subsistema con el objeto de permitir o producir entradas y salidas
del (subsistema) sistema o con el objeto de registrar datos.

Lo que pareciera tan simple en lo que es la integración y el uso de


controladores, no lo es tanto. Al reemplazar los controladores de
prueba por componentes reales se pueden generar nuevos defectos
tales como:

~ Pérdida de datos, manipulación errónea de datos o entradas


erróneas.

~ Los componentes involucrados interpretan los datos de entrada


de una manera distinta a los controladores.

~ Los datos son transferidos en un momento incorrecto: muy


pronto, muy tarde, a una frecuencia distinta de la requerida.

Luego de visto todos los enfoques, ¿cuál es el esquema de integración que


se recomienda emplear?

Lo ideal es una combinación de ambos esquemas según la


necesidad que se tenga, teniendo en cuenta que los módulos
críticos deben ser probados lo más tempranamente posible.

Pruebas de Sistemas – Ana Carolina Ferreyra | 32


1.4.3. Pruebas de Sistema
Las pruebas de sistema comienzan cuando una aplicación está
funcionando como un todo. Tiene como objetivo determinar si el
sistema en su globalidad opera satisfactoriamente (recuperación de
fallas, seguridad y protección, stress, performance, otros). Las
funciones del sistema son ejercitadas y el programa es estresado para
descubrir las limitaciones y medir los topes de capacidades.

La mayoría de las pruebas de sistema se basan en la perspectiva de caja


negra, es decir, sin considerar el cómo está hecho el programa, sino
sólo considerar las funcionalidades solicitadas. El concepto de
cobertura también se ha extendido a este nivel solicitando que se
exprese la cantidad de pruebas realizadas en términos de número de
rutinas o funciones probadas, y se establece un porcentaje de acuerdo a
algún estándar que en comparación, determine cuándo se ha
terminado de probar.

Las pruebas de sistema son mucho más formales que las pruebas de
componentes, registrando y manteniendo los resultados de las pruebas.
Es frecuente que se utilicen herramientas como “generadores de datos
de pruebas” que crea baterías de datos para pruebas basados en ciertos
parámetros de entrada y “Comparadores” que se usan para comparar
dos archivos y encuentra las diferencias.

El ambiente para este nivel de pruebas, donde el sistema está


funcionando como un todo debe corresponderse lo más que se
pueda con el ambiente de producción.

1.4.4. Pruebas de Aceptación


Cuando las pruebas de sistema han sido completadas, comienzan las
pruebas de aceptación. Para llegar a este nivel de pruebas también se
ha dado el nivel de integración en cualquier punto anterior del proceso:
cuando se han realizados las pruebas de sistemas, se hace la
integración; o luego de las pruebas de componentes se hace la
integración.

Pasando a las pruebas de aceptación, el propósito de estas pruebas es


darle al cliente o al usuario final la confianza y la seguridad que el
sistema está listo para ser usado, por lo que encontrar defectos no tiene
que ser el foco principal.

Los set de pruebas se arman con casos de pruebas de las pruebas de


sistemas e incluyen transacciones y escenarios típicos del negocio.
Frecuentemente se hacen de manera informal, y los registros se
mantienen en función de cómo fueron los resultados.

Como la representación del usuario final o del cliente es vital en este


nivel, se dice que son ellos quienes dirigen las pruebas de este nivel. Es
la prueba realizada por el usuario final o cliente para determinar si la
aplicación se ajusta a sus necesidades.

Pruebas de Sistemas – Ana Carolina Ferreyra | 33


Si bien aquí se presenta como un simple nivel de pruebas, según el
proceso de desarrollo que se siga no tiene que ser visto como un nivel
de pruebas que se hace al final de todo. Por ejemplo, las pruebas de
aceptación de un componente, puede tener lugar ni bien la prueba de
componente se haya hecho.

Este nivel de pruebas es popularmente conocido como los UAT10, o


Prueba de aceptación de usuario. Indicando esto de que el usuario es el
actor principal. Pero el ISTQB (2011) plantea otros tipos de pruebas de
aceptación además de las de usuario en función del objeto que se
someta a pruebas.

 Pruebas de aceptación de contrato: se refiere a las pruebas que


demuestran que los criterios de aceptación definidos en el
contrato cliente-proveedor se han alcanzado. Demuestra que el
sistema adhiere a: normativas gubernamentales, definiciones
impositivas, reglamentaciones relacionadas. Por ejemplo, si se
desarrolla un sistema de facturación el mismo debe adherir a
las normas impositivas de discriminación de IVA, cobrar el IVA
que corresponde según el tipo de producto, cobrar impuesto
interno a las bebidas, entre innumerables reglamentaciones que
existen.

 Pruebas de aceptación operacional: se refiere a lo que implica la


operación de un sistema. Por ejemplo, las pruebas de backups y
restore, chequeos periódicos de seguridad ante
vulnerabilidades, recupero de desastres, entre otros.

Este nivel de pruebas introduce dos conceptos según el laboratorio en


el que se lleven adelante las pruebas: pruebas alfa y pruebas beta. No
puede, la organización desarrolladora del sistema, prever cómo el
usuario final utilizará el sistema. El sistema puede llevar a que el
usuario malinterprete alguna funciones, o que el usuario tenga alguna
combinación de datos extraña, entre otros ejemplos que pueden
mencionarse.

Ya se vio que en las pruebas de aceptación, el cliente aplica una serie de


pruebas que permiten validar los requisitos.

¿Cómo se hace si el sistema o software que se desarrolla va destinado a


muchos clientes diferentes, no tiene un cliente específico?

Esto resulta impráctico.

Lo que se hace es tomar clientes que representen el sector de mercado


al que se apunta para que usen el sistema del mismo modo que lo
harían si lo compraran. La idea es retroalimentarse con los
comentarios, reportes de deficiencias y fallos y depurar el sistema antes
de largarlo al mercado para su comercialización. Un ejemplo típico es
cuando Microsoft lanza una nueva versión del office y deja a
disposición. ¿Quién no ha sido alguna vez beta tester de este tipo de
programas?

10
User Acceptance Testing

Pruebas de Sistemas – Ana Carolina Ferreyra | 34


Pruebas beta: Pruebas realizadas por el usuario en ambientes de
producción, de trabajo reales.

Es una práctica muy frecuente en nuestros días, sobre todo para


empresas proveedoras de sistemas que no son de gran reconocimiento.

Pruebas alfa: Pruebas realizadas por el usuario en ambientes de


laboratorio.

Por su definición podemos apreciar que si estamos en las pruebas beta


donde se requiere una versión estable del sistema ya que el usuario
seleccionado lo instalará para llevar adelante sus funciones, de alguna
manera es una prueba de aceptación de usuario.

De la misma manera, siguiendo con la definición que las pruebas alfa


son pruebas realizadas por el usuario en ambientes de laboratorio,
también se está indicando que son dentro del nivel de aceptación.

Lo que queda claro, es que no son tipos de pruebas de aceptación sino


modos de llevar adelante estas pruebas.

Algunos autores llaman pruebas alfa a todas las pruebas desarrolladas


cualquiera sea el nivel al que pertenezcan, mientras sean de
laboratorio, y beta a las pruebas que hace un cliente seleccionado al que
se le da el sistema para su uso. Pero no es el enfoque más popularmente
aceptado ya que el concepto incluye al cliente o usuario final en ambos
modos de prueba (alfa y beta) y este enfoque no.

A continuación presentamos un cuadro que resume los tres niveles


fundamentales dados por Hetzel (1988), con sus características básicas.

Unitario Sistema Aceptación


Objetivo Confirma que el Módulos o Evaluar su
módulo o componentes condición para su
componente fue ensamblados y uso.
programado trabajando como
correctamente. un sistema.

¿Quién lo Normalmente los Equipo de pruebas. Usuarios finales o


hace? programadores. cualquier agente
que lo represente.

¿Qué se Funcionalidades. El Requerimientos de Principales


prueba? código puede ser sistema y funciones,
probado. Se exploran funciones. documentación y
límites y extremos. procedimientos.

¿Cuándo está Normalmente Normalmente Normalmente


cuando el cuando la mayoría cuando el usuario

Pruebas de Sistemas – Ana Carolina Ferreyra | 35


completo? programador se de los está conforme o
siente conforme y no requerimientos son cuando los sets de
hay defectos alcanzados y sin pruebas se
conocidos. mayores defectos. ejecutaron sin
fallos.

Herramientas Normalmente no Generadores de Comparadores.


aplicables. datos de prueba,
comparadores,
simuladores.

Registros Normalmente sin Se registran los Es variable, algunos


registros. defectos informales, otros
descubiertos. Son altamente
mantenidos los formalizados.
casos de pruebas.

Fuente: Libro “The Complete Guide of Software Testing” – Bill Hetzel, pág. 9-12.

Pruebas de Sistemas – Ana Carolina Ferreyra | 36


Bibliografía Lectura 1
ANSI/IEEE Std P610.12-1990. “Standard Glossary of Software Engineering
Terminology”.

ANSI/IEEE Std P730-2002. “Standard for Software Quality Assurance


Plans”.

ANSI/IEEE Std P829-2008. “Standard for Software and System Test


Documentation”.

ANSI/IEEE Std P1028-2008. “Standard for Software Reviews and Audits”.

Beizer, B. (1983). “Software Testing Techniques”, Van Nostrand-Reinhold.

Boehm, B. (1981). “Software Engineering Economics”. Prentice-Hall.

CMMI® para Desarrollo, Versión 1.3 (2010). “Mejora de los procesos para el
desarrollo de mejores productos y servicio”.

Hetzel, Bill (1988). An Introduction. The Complete Guide to Software Testing.


(2da ed.) Massachsetts. USA: QED Information Science.

ISO/IEC 9000 (2005). “Sistemas de gestión de la calidad —


Fundamentos y vocabulario”.

ISO/IEC 9126-1 (2001). “Software engineering — Product quality — Part 1:


Quality model”.

ISTQB (2011). “Fundamentals of Testing. Certified Tester Foundation Level


Syllabus”. International Software Testing Qualifications Board.

ISTQB (2011). SSTQB (2008). “Glosario Estándar de términos utilizados en


Pruebas de Software”. (versión 1.3.ES.0.915)

Kaner C., Bach J., Pretichord B. (2001). “Lessons Learned in Software


Testing”. New York, USA: John Wiley & Sons.

McCall, Jim A.; Richards, Paul K. ; Walters, Gene F. “Factors in Software


Quality. Volume I. Concepts and Definitions of Software Quality”. Final
technical rept. Aug 1976-Jul 1977

Myers, Glendford (1979). “The Art of Software Testing”. New York, USA: John
Wiley & Sons.

Pressman Roger, (2006). “Ingeniería de Software. Un enfoque práctico”. (6ta.


ed.), México: Ed. McGraw Hill.

Pressman Roger, (2006). “Ingeniería de Software. Un enfoque práctico”. (pp.


463) (6ta. ed.), México: Ed. McGraw Hill.

www.uesiglo21.edu.ar

Pruebas de Sistemas – Ana Carolina Ferreyra | 37