PARTE TEÓRICA 

Instrucciones: Se le presenta una temática referida al Testing basado en el Curso

Profesional testing Master 

En esta primera unidad, explicaremos los principales problemas que tiene el

Testing, así como cada una de las Fases.

Objetivos:  Al finalizar la Unidad:

 Los participantes se apropiarán de los principales conceptos que tiene el

Testing. Principios, etc.
 Conocerá las principales prácticas que tiene el testing
 Conocerán los principios y objetivos del testing.

ANTECEDENTES

Durante las últimas tres décadas, el testing ha representado más del 50% del
esfuerzo y el costo de los proyectos de desarrollo de software [Mye04]. No
obstante, muchas veces es menospreciado como un elemento secundario en el
proceso pese que a nivel mundial las organizaciones que emplean y desarrollan
software reciben un gran impacto (desde pérdidas económicas hasta pérdida de
imagen) por no realizar un correcto testing de sus aplicaciones de manera
adecuada.

Por otro lado, en el ámbito académico, no es habitual que las Universidades u

otras organizaciones educativas dicten materias dedicadas exclusivamente a
software testing, con lo cual los profesionales de Sistemas egresan sin tener un
conocimiento suficientemente profundo sobre este aspecto tan importante.
Tampoco es habitual que los docentes aconsejen a los alumnos que recién se
inician sobre cómo realizar el testing de sus propios ejercicios.

Por estos motivos consideramos apropiado el diseño de un curso para adquirir los
fundamentos de software testing y formar a los participantes en las mejores
prácticas de la actividad.

IMPORTANCIA

El testing representa más del 50% del esfuerzo y el costo de los proyectos de
desarrollo de software.

Sin embargo, no se le presta la debida atención. Esto causa pérdidas millonarias a

las empresas.

Las Universidades no suelen ofrecer materias específicas de testing.

Es necesario adquirir los conceptos fundamentales y formarse en las mejores

prácticas de la actividad
COSTO DE ERRORES

Explosión del cohete Ariane 5 en 1996 por un bug en el software. COSTO 500
millones de Dólares.

Aspectos psicológicos
 

 Los aspectos psicológicos, tales como una definición incorrecta del testing son
una de las causas del testing deficiente.

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

encontrar errores.

Un caso de prueba exitoso es aquel que promueve el progreso en encontrar

errores, haciendo que el programa falle.

Una de las causas principales de pruebas (testing) de software deficientes es el

hecho de que la mayoría de los programadores comienzan con una definición falsa
de la palabra. Ellos suelen decir:

•    "La prueba es el procedimiento para demostrar que no hay errores en el

programa." O sino

•    "El propósito de la prueba es demostrar que un programa realiza las funciones

previstas correctamente."

O también

•    "La prueba es el proceso de establecer confianza en que un programa hace lo

que se supone que debe hacer."

Estas definiciones están al revés.

 Cuando se prueba un programa se desea agregar algún valor al mismo. Agregar

valor a través del testing significa elevar la calidad y confiabilidad del
programa. Elevar la confiabilidad del programa quiere decir encontrar y
eliminar errores.

Por lo tanto, usted no debe probar un programa para demostrar que funciona, sino
que debe comenzar con la suposición de que el programa contiene errores (una
suposición válida para casi cualquier programa) y luego probar el programa para
encontrar la mayor cantidad posible de errores.

Por lo tanto, una definición más apropiada es la siguiente:

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

Aunque esto puede sonar como un sutil juego de semántica, es en realidad una
distinción importante. Entender la verdadera definición de software testing puede
hacer una gran diferencia en el éxito de sus esfuerzos.

Los seres humanos tienden a ser sumamente orientados a objetivos, y el

establecimiento de la meta adecuada tiene un efecto psicológico importante. Si
nuestro objetivo es demostrar que un programa no tiene errores, entonces
subconscientemente estaremos dirigidos hacia esta meta, es decir, tenderemos a
seleccionar los datos de prueba que tienen una baja probabilidad de causar que el
programa falle. Por otro lado, si nuestro objetivo es demostrar que un programa
tiene errores, nuestros datos de prueba tendrán una mayor probabilidad de
encontrar errores.

Este último enfoque va a añadir más valor al programa que el primero.

Un segundo problema con las definiciones tales como "La prueba es el

procedimiento para demostrar que no hay errores en el programa" es que tal
objetivo es imposible de lograr para prácticamente cualquier programa, incluso
programas triviales.

Una vez más, los estudios psicológicos nos dicen que las personas funcionan mal
cuando se proponen una tarea que ellos saben que es inviable o imposible. Por
ejemplo, si le pidiéramos resolver el crucigrama de la edición dominical del New
York Times en 15 minutos, probablemente observaríamos poco o ningún avance
después de 10 minutos, porque la mayoría de nosotros estaríamos resignados al
hecho de que la tarea parece imposible. Sin embargo, si se le pide una solución en
cuatro horas, se podría esperar razonablemente ver más progresos en los 10
minutos iniciales. Definir a la prueba del software como el proceso de descubrir
errores en un programa hace que sea una tarea factible, superando de este modo
este problema psicológico.

Teniendo en cuenta la definición de software testing mencionada anteriormente, el

siguiente paso es la determinación de si es posible probar un programa para
encontrar todos sus errores. Le mostraremos que la respuesta es negativa, incluso
para programas triviales. En general, no es práctico, y a menudo imposible,
encontrar todos los errores en un programa. Este problema fundamental, a su vez,
tendrá consecuencias para la economía del testing, los supuestos que el tester
tendrá que hacer sobre el programa y la forma en que se diseñan los casos de
prueba.

Para combatir los problemas relacionados con la economía del testing, usted debe
establecer algunas estrategias antes de comenzar. Dos de las estrategias más
comunes incluyen las pruebas de caja negra (black-box testing) y las pruebas de
caja blanca (white- box testing), que vamos a introducir en las dos secciones
siguientes.

PRUEBA DE CAJA NEGRA

Una estrategia de testing importante es la prueba de caja negra (black-box, data-
driven, ó input/output-driven testing). Para utilizar este método, vea el programa
como una caja negra. Su objetivo es despreocuparse totalmente del
comportamiento interno y la estructura del programa. En su lugar, concentrarse en
encontrar circunstancias en las que el programa no se comporta de acuerdo a sus
especificaciones.

En este enfoque, los datos de prueba se derivan únicamente de las

especificaciones (es decir, sin tomar ventaja del conocimiento de la estructura
interna del programa).

Si desea utilizar este método para encontrar todos los errores en el programa, el
criterio es la prueba exhaustiva de las entradas, generando un caso de prueba
para cada de una de las condiciones de entrada posibles. 

Testing

Un enfoque estratégico

El testing de software es un conjunto de actividades que se pueden planear

anticipadamente y ejecutar como un proceso sistemático. Por esta razón se debe
definir un modelo para el proceso de software (un conjunto de pasos en los que se
pueden incluir técnicas específicas de diseño de casos de prueba y métodos de
testing).

En la bibliografía se han propuesto varias estrategias de testing, todas las cuales

tienen las siguientes características generales 

•      Para realizar un testing efectivo se deben realizar revisiones técnicas

efectivas. Mediante esto se eliminan muchos errores antes de comenzar el testing.

•      El testing comienza a nivel componente y funciona “hacia afuera”, hacia la

integración del sistema completo.

•      Distintas técnicas de testing son apropiadas para distintos enfoques de

ingeniería de software y en distintos momentos.

•      El testing lo dirige el desarrollador de software y (para proyectos medianos a

grandes) un grupo de testers independiente.

•      Testing   y   depuración  (debugging)  son   actividades independientes, pero

el debugging debe estar contemplado en toda estrategia de testing.

La estrategia de testing debe contemplar tests de bajo nivel, necesarios para

verificar que un pequeño fragmento de código fuente fue implementado
correctamente, así como también tests de alto nivel para validar que la
funcionalidad del sistema responde a los requerimientos del cliente.

Una estrategia debe proveer una guía para el ejecutor y un conjunto de hitos
(milestones) para el gerente de proyecto. Debido a que los pasos de la estrategia
de testing se ejecutan en un momento en que la presión de los tiempos (deadlines)
comienza a aumentar, el progreso debe ser medible y los problemas deben
descubrirse lo antes posible.

 2.5.1 Verificación y validación

La prueba del software es un elemento de un concepto más amplio que suele

denominarse verificación y validación (VyV). Verificación es el conjunto de
actividades que aseguran que el software implemente correctamente una función
específica. Validación es un conjunto diferente de actividades que aseguran que el
software construido respeta los requisitos del cliente (requerimientos). Boehm
[Boe81] lo establece de otra manera:

•      Verificación: "¿Estamos construyendo el producto correctamente?"

•      Validación: "¿Estamos construyendo el producto correcto?"

La verificación y la validación abarcan una amplia lista de actividades de

aseguramiento de la calidad del software [Pre10]: revisiones técnicas formales,
auditorías de calidad y de configuración, monitoreo del desempeño, simulación,
factibilidad, revisión de la documentación y la base de datos, análisis de
algoritmos, pruebas de desarrollo, de facilidad de uso, de calificación y de
instalación. Aunque las actividades de prueba tienen un papel demasiado
importante en VyV, también se necesitan muchas otras actividades.

Las pruebas son el último bastión para la evaluación de la calidad y, de manera

más pragmática, el descubrimiento de errores. Pero las pruebas no deben
considerarse como una “red de seguridad”. Como suele decirse: “No es posible
probar la calidad. Si no está ahí antes de que empiece la prueba, no estará cuándo
se termine”. La calidad se incorpora al software en todo el proceso de ingeniería.
La aplicación correcta de métodos y herramientas, las revisiones técnicas formales
y efectivas junto con una administración y una medición sólidas aportan la calidad,
que se confirma durante las pruebas.

   Roles durante el testing

En cualquier proyecto de software se presenta un conflicto de intereses cuando

comienzan las pruebas. Ahora se pide a las personas que han construido el
software que lo prueben. En sí, esto parece inofensivo; después de todo, ¿quién
conoce mejor un programa que la persona que lo desarrolló? Por desgracia, a
esos mismos desarrolladores les interesa mucho demostrar que el programa está
libre de errores, que funciona de acuerdo con los requisitos del cliente y que se
completará a tiempo y sin exceder el presupuesto. Cada uno de estos intereses
mina las bondades de la prueba.

Desde un punto de vista psicológico, el análisis y el diseño del software (junto con
la codificación) son tareas constructivas. El ingeniero del software analiza, modela
y luego crea un programa de computadora, junto con su documentación. Como
cualquier constructor, el ingeniero del software se sentirá orgulloso del edificio que
acaba de construir y mirará con recelo a cualquiera que pretenda echarlo abajo.
Cuando comienza la prueba hay un intento sutil, pero definitivo, de "romper" lo que
ha construido el ingeniero del software. Al ponerse en los zapatos del desarrollador
la prueba parecerá (psicológicamente) destructiva. De modo que el desarrollador
actuará con cuidado, diseñando y ejecutando pruebas que demostrarán el buen
funcionamiento del programa en lugar de descubrir errores. Por desgracia, los
errores seguirán presentes. Y si el ingeniero del software no los encuentra, ¡el
cliente sí lo hará!

De las consideraciones precedentes suelen inferirse erróneamente varias malas

interpretaciones: 1) que el responsable del desarrollo no debería participar en el
proceso de prueba, 2) que el software debe ponerse a salvo de extraños que lo
prueben sin misericordia, y 3) que quienes aplican las pruebas sólo deben
participar en el proyecto cuando vayan a darse los primeros pasos de esas
pruebas. Todas estas afirmaciones son incorrectas.

El desarrollador del software siempre será el responsable de probar las unidades

individuales (componentes) del programa y asegurar que cada una realice la
función o muestre el comportamiento para el que se diseñó. En muchos casos, el
desarrollador también aplica la prueba de integración (un paso que lleva a la
construcción, y la prueba, de toda la arquitectura del software). Sólo después de
que la arquitectura del software esté completa participará un grupo independiente
de prueba.

El papel del grupo independiente de prueba (GIP) consiste en eliminar los

problemas propios de dejar que el constructor (desarrollador) pruebe lo que él
mismo ha construido. La prueba independiente elimina el conflicto de intereses
que, de otra manera, estaría presente. Después de todo, al personal del GIP se le
paga para que encuentre errores.

Sin embargo, el ingeniero del software no debe simplemente entregar el programa

al GIP y alejarse. El desarrollador y el GIP deben trabajar unidos en todo el
proyecto de software para asegurar la realización de pruebas rigurosas. Mientras
éstas se realizan, el desarrollador debe estar disponible para corregir los errores
que se descubran.

El GIP es parte del equipo del proyecto de desarrollo del software, ya que participa
en el análisis y diseño, y además sigue participando (al planear y especificar
procedimientos de prueba) en todos los pasos de un proyecto grande. Sin
embargo, en muchos casos el GIP informa a la organización de aseguramiento de
calidad del software, por lo que obtiene un grado de independencia que sería
imposible si fuera parte de la organización encargada de la ingeniería del software