Qu son las pruebas de software?

1. Son los procesos (conjunto de actividades planeadas) de ejecucin de programas con el fin de encontrar errores.
2. Es ejecutar software con datos de prueba donde se examinan las salidas para comprobar su funcionamiento y para
comprobar los requerimientos
Defecto: Carencia de alguna cualidad propia de algo.
Falla: Incumplimiento de una obligacin.
Error: Cosa hecha erradamente.
Datos de prueba
Son los datos que permiten probar el software

Datos artificiales: son los que se crean artificialmente tratando de considerar todas las combinaciones y rutas
posibles, debiendo ser preparados por personas distintas de las que programaron el sistema.

Datos reales -> correctos

Datos falsos -> incorrectos

Verificacin

Conjunto de tareas que garantizan que el software se implemente correctamente a travs de funciones especficas.
Es cuando los sistemas cumplen con sus especificaciones y con las caractersticas del software.

Es cuando se comprueba que el software satisface los requerimientos funcionales y no funcionales.

Construimos el producto correctamente?

Validacin

Es un conjunto diferente de tareas que asegura que el software que se construye sigue los requerimientos del
cliente.
Demuestra que el software hace lo que el cliente espera que haga.

Asegura que el software satisface las expectativas del cliente.

Construimos el producto correcto?

Verificacion y validacion

El objetivo del proceso de verificacion y validacion es establecer la seguridad de que el sistema software esta
hecho para un proposito.
La verificaci[on y validacion no son lo mismo

La verificacion intenta mostrar que un programa satisface su especificacion

La validacion intenta mostrar que el programa hace lo que el usuario requiere

Principios del proceso de prueba

Pruebas y proceso de desarrollo

Participantes
1. Autor o propietario: El programador o disenador responsable de generar el programa, es responsable de reparar
los defectos descubiertos durante el proceso de prueba.
2. Inspector o probador: encuentra errores, omisiones o inconsistencias en los programas documentados, tambien
puede identificar cuestiones mas generales que estan fuera del ambito del equipo de inspeccion o de prueba.
3. Lector: presenta el codigo o documento en una reunion de inspeccion.

4. Secretario: registra los resultados de la reunion de inspeccion.

5. Presidente o moderador: gestiona el proceso y facilita la inspeccion. Realiza un informe de los resultados del
proceso para el moderador jefe.
6. Moderador jefe: responsable de las mejoras del proceso de inspeccion, actualizacion de las listas de
comprobacion, estandares de desarrollo, etc.

Proceso de prueba
Objetivos de prueba
Convencer a los desarrolladores del sistema y a los clientes de que el software es lo suficientemente bueno para su
uso operacional.
La prueba es un proceso que intenta proporcionar confianza en el software.

Las pruebas solo pueden demostrar las presencia de errores, no su ausencia Edsger Dijkstra, 1972

DISEO DE CASOS DE PRUEBA

El diseo de casos de prueba, tiene un nico objetivo: tener la mayor probabilidad de encontrar
el mayor nmero de errores con la mnima cantidad de esfuerzo y tiempo posible.
Cualquier producto software puede aprobarse de una las siguientes formas:

1. Conociendo la funcin para la que fue diseado el producto.

Se pueden utilizar pruebas para: comprobar su funcin operativa y buscar

errores de cada funcin.

2. Conociendo el funcionamiento del producto.

Se pueden utilizar pruebas para: comprobar que las operaciones esta de

acuerdo con las especificaciones y para comprobar que los componentes
internos funcionan de forma adecuada.

Niveles de prueba

1. Pruebas Unitarias o de Componente: este tipo de pruebas son ejecutadas normalmente por el equipo de
desarrollo, bsicamente consisten en la ejecucin de actividades que le permitan verificar al desarrollador que los
componentes unitarios estn codificados bajo condiciones de robustez, esto es, soportando el ingreso de datos
errneos o inesperados y demostrando as la capacidad de tratar errores de manera controlada. Adicionalmente,
Las pruebas sobre componentes unitarios, suelen denominarse pruebas de mdulos o pruebas de clases, siendo
la convencin definida por el lenguaje de programacin la que influye en el trmino a utilizar. Por ltimo, es
importante que toda la funcionalidad de cada componente unitario sea cubierta, por al menos, dos casos de
prueba, los cuales deben centrarse en probar al menos una funcionalidad positiva y una negativa.
2. Pruebas de Integracin: este tipo de pruebas son ejecutas por el equipo de desarrollo y consisten en la
comprobacin de que elementos del software que interactan entre s, funcionan de manera correcta.

3. Pruebas de Sistema: este tipo de pruebas deben ser ejecutadas idealmente por un equipo de pruebas ajeno al
equipo de desarrollo, una buena prctica en este punto corresponde a la tercerizacin de esta responsabilidad. La
obligacin de este equipo, consiste en la ejecucin de actividades de prueba en donde se debe verificar que la
funcionalidad total de un sistema fue implementada de acuerdo a los documentos de especificacin definidos en el
proyecto. Los casos de prueba a disear en este nivel de pruebas, deben cubrir los aspectos funcionales y no
funcionales del sistema. Para el diseo de los casos de prueba en este nivel, el equipo debe utilizar como bases de
prueba entregables tales como: requerimientos iniciales, casos de uso, historias de usuario, diseos, manuales
tcnicos y de usuario final, etc. Por ltimo, es importante que los tipos de pruebas ejecutados en este nivel se
desplieguen en un ambiente de pruebas / ambiente de pre-produccin cuya infraestructura y arquitectura sea
similar al ambiente de produccin, evitando en todos los casos utilizar el ambiente real del cliente, debido
principalmente, a que pueda ocasionar fallos en los servidores, lo que ocasionara indisponibilidad en otros
servicios alojados en este ambiente.

4. Pruebas de Aceptacin: Independientemente de que se haya tercerizado el proceso de pruebas y as la firma

responsable de estas actividades haya emitido un certificado de calidad sobre el sistema objeto de prueba, es
indispensable, que el cliente designe a personal que haga parte de los procesos de negocio para la ejecucin de
pruebas de aceptacin, es incluso recomendable, que los usuarios finales que participen en este proceso, sean
independientes al personal que apoy el proceso de desarrollo. Cuando las pruebas de aceptacin son ejecutadas
en instalaciones o ambientes proporcionados por la firma desarrolladora se les denominan pruebas Alpha, cuando
son ejecutadas desde la infraestructura del cliente se les denomina pruebas Beta. En los casos en que las pruebas
de aceptacin del producto se hayan ejecutado en el ambiente del proveedor, el aplicativo no podr salir a
produccin, sin que se hayan ejecutados las respectivas pruebas Beta en el ambiente del cliente, de lo anterior es
importante concluir, que las pruebas Alpha son opcionales, pero las pruebas Beta son obligatorias.
Tipos de prueba

Un conjunto de actividades de pruebas suele orientase a comprobar determinados aspectos de un sistema software (o de una parte del
mismo). Continuando as con nuestro anterior artculo sobre el modelo de cebolla para los Niveles de Pruebas Software, y siguiendo
las directrices del ISTQB, acotaremos los Tipos de Pruebas Software en funcin del objetivo en que se centran.

En primer lugar tenemos las Pruebas Funcionales. Tpicamente encontraremos el comportamiento del sistema, subsistema o
componente software descrito en especificaciones de requisitos o casos de uso, aunque tambin puede no estar documentado (que
funcione como el sistema al que sustituye) . Es decir, con las funciones establecemos lo que el sistema hace.
Estas pruebas se definen a partir de funciones o caractersticas (como decimos, bien descritas en documentos o bien interpretadas por
los probadores) y su interoperabilidad con sistemas especficos, pudiendo ejecutarse en todos los niveles de pruebas (componentes,
integracin, sistema, etc).
Se consideran Pruebas de Caja Negra (black-box testing) puesto que valoramos el comportamiento externo del sistema. Las Pruebas
de Seguridad o las Pruebas de Interoperabilidad entre sistemas o componentes son casos especializados de las pruebas funcionales.
En segundo lugar figuran las Pruebas no Funcionales que incluyen las pruebas de: Rendimiento, Carga, Estrs, Usabilidad,
Mantenibilidad, Fiabilidad o Portabilidad, entre otras. Por tanto se centran en caractersticas del software que establecen cmo
trabaja el sistema.
Estas pruebas tambin pueden ejecutarse en todos los niveles de pruebas. Las caractersticas no funcionales del software se pueden
medir de diversas maneras, por ejemplo, por medio de tiempos de respuesta en el caso de pruebas de rendimiento o por nmero
mximo de sesiones en pruebas de estrs.
Puesto que las Pruebas no Funcionales normalmente consideran el comportamiento externo del sistema, en la mayora de los casos se
utilizan tcnicas de Pruebas de Caja Negra.
A continuacin, en tercer lugar, tenemos las Pruebas Estructurales. Nuevamente pueden ejecutarse en todos los niveles de pruebas
(ya sabis: componentes, integracin, sistema, etc.) y encajan muy bien si hemos utilizado tcnicas de especificacin de la estructura o
arquitectura del Software. Es posible aplicar tcnicas estticas de anlisis de cdigo.
Para expresar el alcance con un conjunto de pruebas (test suite) que ha cubierto la estructura o arquitectura en cuestin, se utiliza el
concepto de Cobertura (Coverage), normalmente en forma de porcentaje.
Es especialmente habitual utilizar herramientas de apoyo para calcular la cobertura del cdigo en el caso de Pruebas
de Componentes o en Pruebas de Integracin de Componentes (por ejemplo, trazando la jerarqua de llamadas entre elementos).
Puesto que indagamos en el comportamiento interno, estas pruebas se denominan tambin Pruebas de Caja Blanca (white-box
testing).
Finalmente, el cuarto tipo de pruebas que nos presenta el ISTQB son las pruebas derivadas de la realizacin de cambios: las Pruebas
de Regresin y las Re-pruebas.
Una vez que un defecto ha sido corregido, toca volver a probar el software para confirmar que el defecto ha sido eliminado. Son
pruebas repetidas o Re-Pruebas.
Las Pruebas de Regresin consisten en volver a probar un componente, tras haber sido modificado, para descubrir cualquier defecto
introducido, o no cubierto previamente, como consecuencia de los cambios. Los defectos pueden encontrarse tanto en el software que
se ha cambiado como en algn otro componente. Se ejecutan cuando se cambia el software o su entorno. El criterio para decidir la
extensin de estas Pruebas de Regresin est basado en el riesgo de no encontrar defectos en el software que anteriormente estaba
funcionando correctamente.
Las Pruebas de Regresin se realizan sobre un componente ya probado, para verificar que no presenta nuevos defectos cuando se
realiza una modificacin despus de dichas pruebas.
Este tipo de pruebas deben ser repetibles si han de usarse para pruebas de confirmacin (o aseguramiento) y regresin (como Sondas
de Disponibilidad, por ejemplo). Los conjuntos de pruebas de regresin (Regression test suites) suelen ser bastante estables por lo
que son muy buenos candidatos para actividades de automatizacin de pruebas.

Quiz ya no os sorprenda que estas pruebas tambin puedan ejecutarse en todos los niveles de pruebas e incluyen casos de prueba
de los tipos vistos anteriormente: Pruebas Funcionales, No Funcionales y Estructurales.
Ahora que ya tenemos una buena imagen de los tipos de pruebas que podemos incorporar para asegurar la Calidad del
Software (SQA), es ms fcil que entendamos que se trata de una actividad que requiere una elevada capacidad de adaptacin de las
cargas de trabajo, as como de una suficiente especializacin. Por ello, en @PanelSistemas hemos consolidado nuestra orientacin
hacia modelos de factora, os lo contamos en nuestro artculo: el Testing bajo modelos de factora.