1. ING. SAIDA QUINTERO
*

2. 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.

3. 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.»

4. * 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.

6. * 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?) »

7. 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.

8. * 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.

9. * 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.

10. * 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.

11. * 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.

12. *
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.

13. 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

14. *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.

15. *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.

16. 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.

17. *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.

18. 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.