ING. SAIDA QUINTERO

*

Piattini, Calvo-Manzano, Cervera y Fernández las pruebas

Probar si el software no hace lo que debe.

Probar si el software hace lo que no debe, es decir, si provoca

efectos secundarios adversos.

Glen Myers:

La prueba es el proceso de ejecución de un programa con la

intención de descubrir un error.

Un buen caso de prueba es aquel que tiene una alta probabilidad

de mostrar un error no descubierto hasta entonces.

Una prueba tiene éxito si descubre un error.

El diseño y ejecución de pruebas debe estar encaminado a:

Encontrar el mayor número de errores con la menor cantidad de

tiempo y esfuerzo posibles.

Mostrar hasta que punto las funciones del software operan de

acuerdo con las especificaciones y requerimientos del cliente.

Estos son algunos términos empleados en el proceso de pruebas:

* Prueba (test)

«Una actividad en la cual un sistema o componente es ejecutado bajo condiciones

específicas, se observan o almacenan los resultados y se realiza una evaluación de

algún aspecto del sistema o componente.»

* Caso de prueba (test case)

«Un conjunto de entradas, condiciones de ejecución y resultados esperados, diseñados

para un objetivo particular.»

* Equivocación (mistake)

«Una acción del ser humano que produce un resultado incorrecto.»

* Error (error)

«La diferencia entre un valor calculado, observado o medido y el valor verdadero,

especificado o teóricamente correcto.»

* Fallo (failure)

Un fallo puede ser definido como:

«La incapacidad de un sistema o de alguno de sus componentes para realizar las

funciones requeridas dentro de los requisitos de rendimiento especificados.»

* Defecto (defect, fault, bug)

Un defecto puede ser definido como:

* - «Un paso, proceso o definición de dato incorrecto en un programa de computadora. El

resultado de una equivocación.»

* - «Una variación de una característica deseada del producto.»

* Un defecto puede dividirse en dos categorías:

- Defectos en la especificación del producto: el producto construido varía del

producto especificado.

- Variaciones en las expectativas del cliente/usuario: estas variaciones son algo que

el usuario quiere que no esté en el producto final, pero éstas además no fueron

especificadas para ser incluidas en el producto.

* Depuración

«El proceso de localizar, analizar y corregir los defectos que se sospecha que contiene el

software »

* Verificación

- «El proceso de evaluación de un sistema o de uno de sus componentes para determinar

si los productos de una fase dada satisfacen las condiciones impuestas al comienzo de

dicha fase.»

* - «Un conjunto de actividades que aseguran que el software implementa correctamente

una función específica. (¿Estamos construyendo el producto correctamente?).»

* Validación

* - «El proceso de evaluación de un sistema o de uno de sus componentes durante o al

final del proceso de desarrollo para determinar si satisface los requisitos

especificados.»

* - «Un conjunto diferente de actividades que aseguran que el software construido se

ajusta a los requisitos del cliente. (¿Estamos construyendo el producto correcto?) »

Para los grupos asociados al proceso de prueba son:

*

Cliente del software (Software customer): grupo u organización que realiza la contratación

para el software que va a ser desarrollado.

* Usuario del software (Software user): individuo o grupo que usará el software una vez este

puesto en funcionamiento.

* Desarrollador de software (Software developer): individuo o grupo que aprueba o asiste la

redacción de los requerimientos, el diseño del software, la construcción del software, la

gestión de cambios y el mantenimiento del software según lo solicitado.

En el desarrollo de software existen varios grupos fuertemente asociados al

proceso de pruebas, tales grupos varían dependiendo de la compañía y del

proyecto pero en esencia y de acuerdo con algunos autores los roles siguen

siendo los mismos.

* Probador de software (Software tester): individuo o grupo que

realiza las funciones de verificación en el software. (Éste puede ser

un subgrupo de desarrolladores, un grupo independiente ó la

combinación de los dos.)

* Gerencia en informática (Information technology management):

individuo o grupo con la responsabilidad de cumplir con la misión

informática. (Las pruebas ayudan a cumplir esta misión.)

* Alta gerencia de la organización (Senior organization

management): director general de la organización y otros altos

ejecutivos quienes tienen la responsabilidad de cumplir con la misión

de la organización. (La informática es una actividad que ayuda a

cumplir esta misión.)

* Auditor (Auditor): Uno o más individuos que tienen la

responsabilidad de evaluar la efectividad, eficiencia, y eficacia de los

controles en el área de la informática. Las pruebas son consideradas

un control por la función de auditoría.

* Los administradores del proyecto, los administradores del programa, o

los directores (Project managers, program managers, or producers):

manejan el proyecto desde el inicio hasta el final. Son generalmente

responsables de escribir la especificación del producto, el manejo del

cronograma y los encargados de las decisiones críticas y de las negociaciones.

* Arquitectos o ingenieros de sistemas (Architects or system engineers):

son los expertos en tecnología. Generalmente poseen mucha experiencia y

por consiguiente son llamados los diseñadores de toda la arquitectura del

sistema o del diseño de todo el software. Trabajan conjuntamente con los

programadores.

* Los programadores, desarrolladores o codificadores (Programmers,

developers, or coders): diseñan y escriben el software y reparan los

defectos que son encontrados. Trabajan conjuntamente con los arquitectos y

los directores del proyecto para crear el software. Y trabajan conjuntamente

con los directores del proyecto y los probadores para conseguir reparar los

bugs.

* Probadores o personal QA - Aseguradores de la calidad

(Testers or QA (Quality Assurance) Staff): son responsables de

encontrar y reportar los problemas en el producto de software.

Trabajan conjuntamente con todos los miembros del equipo

informándoles como se esta desarrollando y ejecutando las

pruebas y reportando los problemas encontrados.

* Escritores técnicos, asistentes de usuario, educadores de

usuario, escritores de manuales o ilustradores (Technical

writers, user assistance, user education, manual writers, or

illustrators): crean la documentación que viene en el producto

de software.

* Directores de configuración o constructores (Configuration

management or builder): manejan el proceso de colocar junto

todo el software escrito por los programadores y toda la

documentación creada por los escritores y de ponerla en un solo

paquete.

* Pressman menciona algunos de los principios básicos que guían las pruebas del software:

* A todas las pruebas se les debería poder hacer un seguimiento hasta los requisitos del cliente.

* Las pruebas deberían planificarse mucho antes de que empiecen. La planificación de las pruebas

puede empezar tan pronto como esté completo el modelo de requisitos y la definición detallada

de los casos de prueba tan pronto como se tenga consolidado el modelo de diseño.

* Las pruebas deberían empezar por «lo pequeño»y progresar hacia «lo grande». Las primeras

pruebas planeadas y ejecutadas se centran generalmente en módulos individuales del programa. A

medida que se avanza en éstas, el enfoque de las pruebas cambia en un intento de encontrar

nuevos errores relacionados con la integración de éstos módulos y finalmente con la interacción

del sistema completo.

* No son posibles las pruebas exhaustivas. El número de permutaciones de caminos para incluso un

programa de tamaño moderado es demasiado grande. Por lo cual, es imposible ejecutar todas las

combinaciones de caminos durante las pruebas. Es posible, sin embargo elegir y ejecutar una serie

de caminos lógicos importantes que permitan probar adecuadamente el software.

* Para ser más eficaces, las pruebas deberían ser realizadas por un equipo independiente. El

ingeniero de software que creó el sistema no es el más indicado para realizar las pruebas debido a

que consciente o inconscientemente puede omitir casos de prueba importantes que conlleven a

descubrir nuevos errores. Por consiguiente, es recomendable organizar un grupo de trabajo

independiente para las pruebas que suministre una visión más objetiva del software.

*

De acuerdo con James Bach la facilidad de prueba puede ser

definida de la siguiente manera:

La facilidad de prueba del software es simplemente la facilidad

con la que se puede probar un programa de computadora.

El alcance de esta facilidad de prueba adquiere gran importancia

por parte del equipo de desarrollo del software debido a que se

reconoce que las pruebas son unos de los procesos más difíciles y

costosos que se deben realizar. Por esta razón se hace necesario

implementar métricas y métodos que faciliten este proceso.

Operatividad: hace referencia al aspecto funcional del

software.

Principalmente esta característica plantea que en cuanto mejor

funcione el software más eficiente será el proceso de pruebas.

Lista de comprobación:

* El sistema tiene pocos errores. –

* Ningún error bloquea la ejecución de las pruebas.

* El producto evoluciona en fases funcionales, lo que permite

ejecutar simultáneamente el desarrollo y las pruebas.

A continuación se enuncian algunas características junto con algunos

ítems de comprobación que llevan a que un software sea fácil de probar

*Observabilidad: puede ser descrita con la siguiente frase «Lo

que ves es lo que pruebas»

Lista de comprobación:

* Se genera una salida distinta para cada entrada.

* Los estados y variables del sistema están visibles o se pueden

consultar durante la ejecución.

* Todos los factores que afectan a los resultados están visibles.

* Un resultado incorrecto se identifica fácilmente.

* Los errores internos se detectan automáticamente a través de

mecanismos de auto-comprobación.

* El código fuente es accesible.

* Controlabilidad: cuantas más revisiones y controles se realicen al

software más fácil será lograr su adecuada automatización y optimización.

Lista de comprobación:

Todos los resultados posibles se pueden generar a través de alguna combinación

de entrada.

* Todo el código es ejecutable a través de alguna combinación de entrada.

* El ingeniero de pruebas puede controlar directamente los estados y las

variables del hardware y del software.

* Los formatos de las entradas y los resultados son consistentes y

estructurados.

* Las pruebas pueden especificarse, automatizarse y reproducirse

convenientemente.

Capacidad de descomposición: hace referencia al grado de modularización del

software. Entre mayor sea éste, más rápido se podrán aislar los problemas y será posible

llevar a cabo mejores pruebas de regresión.

Lista de comprobación:

* El software está construido con módulos independientes.

* Los módulos del software se pueden probar independientemente.

Simplicidad: cuanto más entendible, estandarizado y estructurado esté el software

menos pruebas deberán realizarse y más rápido avanzará la planificación y ejecución de

pruebas.

Lista de comprobación:

* Simplicidad funcional.

* Simplicidad estructural.

* Simplicidad del código.

* Estabilidad: entre menor sea el número de cambios realizados al software, el proceso

de pruebas avanzará rápidamente ya que no se presentarán mayores interrupciones.

Lista de comprobación:

* Los cambios del software son infrecuentes, están controlados y no invalidan las pruebas

existentes.

* El software se recupera bien de los fallos.

* Facilidad de comprensión: está característica plantea que entre mayor información se

tenga del proceso de software más inteligentes serán la definición y ejecución de las pruebas.

Lista de comprobación:

* El diseño se ha entendido perfectamente.

* Las dependencias entre los componentes internos, externos y compartidos se han entendido

perfectamente.

* Se han comunicado los cambios del diseño.

* La documentación técnica es instantáneamente accesible.

* La documentación técnica está bien organizada, es específica, detallada y exacta.

En general la «facilidad de prueba» dependerá en gran medida del diseño del

software y deberá tenerse en mente ya que ayudará a los ingenieros a proponer casos

de prueba más fácilmente.

Característica de una buena

prueba

* Una buena prueba tiene un alta probabilidad de encontrar un error. El

ingeniero de software debe tener un alto nivel de entendimiento del software a

construir para poder diseñar buenos casos de prueba que encuentren el mayor

número de defectos.

* Una buena prueba no debe ser redundante. Uno de los objetivos de las pruebas es

«encontrar el mayor número de errores con la menor cantidad de tiempo y

esfuerzo posibles», por lo cual no se deben diseñar casos de prueba que tengan el

mismo propósito que otros sino que se debe buscar diseñar el menor número de

casos de prueba que permitan probar adecuadamente el software y que permitan

optimizar los recursos.

* Una buena prueba debería ser la mejor de la cosecha. La limitación en tiempo y

recursos puede impedir que se ejecuten todos los casos de prueba de un grupo de

pruebas similares por lo cual en estos casos se debería seleccionar la prueba que

tenga la mayor probabilidad de descubrir errores.

* Una buena prueba no debería ser ni demasiado sencilla ni demasiado compleja.