PLAN DE PRUEBAS DE SOFTWARE

El Plan de Pruebas
El propsito del plan de pruebas es explicitar el alcance, enfoque, recursos
requeridos, calendario, responsables y manejo de riesgos de un proceso de
pruebas.
Note que puede haber un plan global que explicite el nfasis a realizar sobre los
distintos tipos de pruebas (verificacin, integracin e integracin).

Un plan de pruebas incluye:

1. Identificador del plan.

Preferiblemente de alguna forma mnemnica que permita relacionarlo con su
alcance, por ej. TP-Global (plan global del proceso de pruebas), TP-Req-Seguridad1
(plan de verificacin del requerimiento 1 de seguridad), TP-Contr-X (plan de
verificacin del contrato asociado al evento de sistema X), TP-Unit-
Despachador.iniciar (plan de prueba unitario para el mtodo iniciar de la clase
Despachador). Como todo artefacto del desarrollo, est sujeto a control de
configuracin, por lo que debe distinguirse adicionalmente la versin y fecha del
plan.

2. Alcance
Indica el tipo de prueba y las propiedades/elementos del software a ser probado.

3. Items a probar
Indica la configuracin a probar y las condiciones mnimas que debe cumplir para
comenzar a aplicarle el plan. Por un lado, es dificil y riesgoso probar una
configuracin que an reporta fallas; por otro lado, si esperamos a que todos los
mdulos estn perfectos, puede que detectemos fallas graves demasiado tarde.

4. Estrategia
Describe la tcnica, patrn y/o herramientas a utilizarse en el diseo de los casos
de prueba. Por ejemplo, en el caso de pruebas unitarias de un procedimiento, esta
seccin podra indicar: "Se aplicar la estrategia caja-negra de fronteras de la
precondicin" o "Ejercicio de los caminos ciclomticos vlidos". En lo posible la
estrategia debe precisar el nmero mnimo de casos de prueba a disear, por ej.
100% de las fronteras, 60% de los caminos ciclomticos... La estrategia tambin
explicita el grado de automatizacin que se exigir, tanto para la generacin de
casos de prueba como para su ejecucin.

5. Categorizacin de la configuracin
Explicita las condiciones bajo las cuales, el plan debe ser:
Suspendido,
Repetido;
Culminado.
En algunas circunstancias (las cuales deben ser explicitadas) el proceso de prueba
debe suspenderse en vista de los defectos o fallas que se han detectado. Al
corregirse los defectos, el proceso de prueba previsto por el plan puede continuar,
pero debe explicitarse a partir de qu punto, ya que puede ser necesario repetir
algunas pruebas. Los criterios de culminacin pueden ser tan simples como aprobar
el nmero mnimo de casos de prueba diseados o tan complejo como tomar en
cuenta no slo el nmero mnimo, sino tambin el tiempo previsto para las pruebas
y la tasa de deteccin de fallas.

6. Tangibles
Explicita los documentos a entregarse al culminar el proceso previsto por el plan p.
ej. subplanes, especificacin de pruebas, casos de prueba, resumen gerencial del
proceso y bitcora de pruebas.

7. Procedimientos especiales
Identifica el grafo de las tareas necesarias para preparar y ejecutar las pruebas, as
como cualquier habilidad especial que se requiere.

8. Recursos
Especifica las propiedades necesarias y deseables del ambiente de prueba,
incluyendo las caractersticas del hardware, el software de sistemas (p. ej. el
sistema de operacin), cualquier otro software necesario para llevar a cabo las
pruebas, as como la colocacin especfica del software a probar (p. ej. qu
mdulos se colocan en qu mquinas de una red local) y la configuracin del
software de apoyo.
La seccin incluye un estimado de los recursos humanos necesarios para el
proceso. Tambin se indican cualquier requerimiento especial del proceso:
actualizacin de licencias, espacio de oficina, tiempo en la mquina de produccin,
seguridad.

9. Calendario
Esta seccin describe los hitos del proceso de prueba y el grafo de dependencia en
el tiempo de las tareas a realizar.

10. Manejo de riesgos

Explicita los riesgos del plan, las acciones mitigantes y de contigencia.

11. Responsables
Especifica quin es el responsable de cada una de las tareas previstas en el plan.
INTRODUCCION AL SOFTWARE TESTING

El Software testing o como se conoce en espaol las pruebas de software se aplican como una etapa ms
del proceso de desarrollo de software, su objetivo es asegurar que el software cumpla con las
especificaciones requeridas y eliminar los posibles defectos que este pudiera tener. En un principio la
mayora de empresas de desarrollo contaban con una etapa de pruebas demasiado informal, en la
actualidad el software testing se ha convertido en una de las etapas ms crticas del ciclo de vida del
desarrollo de software y esto ha causado el origen de diversas metodologas.

En la actualidad el software testing se hace ms complicado ya que debe hacer frente a una gran
cantidad de metodologas de desarrollo, lenguajes de programacin, sistemas operativos, hardware etc.

Es por esto que el testing debe apoyarse en metodologas generales que revisan los aspectos ms
fundamentales que debe considerar todo proceso de pruebas. Debido a esta complejidad actualmente se
cuentan con una gran cantidad de software diseado exclusivamente para la etapa de pruebas,
incluyendo la gestin del proceso de software testing, la administracin y seguimiento de errores, la
administracin de los casos de prueba, automatizacin de pruebas etc.

Luego de culminadas las etapas de anlisis, diseo y desarrollo se inicia la etapa de pruebas, en esta
etapa lo recomendable es que el software se mantenga en un ambiente aislado o separado del ambiente
de desarrollo o de produccin, lo ideal es preparar un ambiente de pruebas lo ms parecido a los
ambientes que existen en produccin para asegurar su correcto funcionamiento en esa futura etapa, se
debe considerar adquirir un equipo de pruebas especializado software tester o analista de pruebas, con
experiencia, estas personas tienen una formacin que les permite detectar una gran cantidad de errores
en tiempos mnimos, as como una metodologa especifica que les permite hacer el trabajo de manera
correcta, algunas empresas ms informales utilizan a los futuros usuarios del sistema como testers
situacin que puede traer una serie de problemas debido a la poca experiencia que pueden tener los
usuarios en la deteccin de errores, adems se obvian pruebas importantes como las pruebas de
Esfuerzo o Stress testing, tambin se dejan de lado las pruebas unitarias o pruebas modulares, las que
deberan asegurar que cada modulo del sistema trabaje correctamente de manera independiente, otro
error muy conocido en empresas de software es el uso de los mismos desarrolladores como analistas de
pruebas, es muy difcil probar con objetividad un software si nosotros mismos lo hemos desarrollado, un
tcnico o analista programador empezara a probar con la idea preconcebida de que su hijito trabaja a la
perfeccin e inconcientemente evitara realizar pruebas mas exhaustivas considerando que las mismas
podran ser absurdas o innecesarias, lo bueno es que poco a poco estas ideas van quedando
descartadas y se van alineando conceptos hacia un software testing profesional.

Ing. Alexander Or B.

FUNCTIONAL TESTING - PRUEBAS FUNCIONALES

Se denominan pruebas funcionales o Functional Testing, a las pruebas de software que tienen por
objetivo probar que los sistemas desarrollados, cumplan con las funciones especficas para los cuales han
sido creados, es comn que este tipo de pruebas sean desarrolladas por analistas de pruebas con apoyo
de algunos usuarios finales, esta etapa suele ser la ultima etapa de pruebas y al dar conformidad sobre
esta el paso siguiente es el pase a produccin.

A este tipo de pruebas se les denomina tambin pruebas de comportamiento o pruebas de caja negra, ya
que los testers o analistas de pruebas, no enfocan su atencin a como se generan las respuestas del
sistema, bsicamente el enfoque de este tipo de prueba se basa en el anlisis de los datos de entrada y
en los de salida, esto generalmente se define en los casos de prueba preparados antes del inicio de las
pruebas.
Las pruebas funcionales en la mayora de los casos son realizadas manualmente por el analista de
pruebas, tambin es posible automatizar este tipo de pruebas utilizando herramientas como WinRunner o
SilkTest las cuales permiten generar scripts conforme nosotros hagamos interacciones con el aplicativo a
probar. La automatizacin de pruebas puede resultar compleja y solo la recomendara en algunas
funcionalidades especficas, por ejemplo en las pantallas que tendrn mayor uso, generalmente pantallas
de ingreso de datos. Se debe tener en cuenta que el costo de estas licencias suele ser bastante elevado.

Al realizar pruebas funcionales lo que se pretende en ponerse en los pies del usuario, usar el sistema
como l lo usara sin embargo el analista de pruebas debe ir mas all que cualquier usuario,
generalmente se requiere apoyo de los usuarios finales ya que ellos pueden aportar mucho en el
desarrollo de casos de prueba complejos, enfocados bsicamente al negocio, posibles particularidades
que no se hayan contemplado adecuadamente en el diseo funcional, el analista de pruebas debera dar
fuerza a las pruebas funcionales y ms an a las de robustez, generalmente los usuarios realizan las
pruebas con la idea que todo debera funcionar, a diferencia del analista de pruebas que tiene ms bien
una misin destructiva, su objetivo ser encontrar alguna posible debilidad y si la llega a ubicar se
esforzar por que deje de ser pequea y posiblemente se convertir en un gran error, cada error
encontrado por el analista de pruebas es un xito, y se debera considerar como tal, en mi experiencia
personal he podido ver que proyectos atrasados, o con algunos problemas de tiempo sacrifican horas de
pruebas, incluso se siente algn malestar si el tester sigue encontrando errores, si no se corrige esta
situacin los proyectos en su gran mayora fracasaran o perdern ms tiempo an.

En la empresa en la he laborado algunos aos solo se realizaban pruebas del tipo funcional, ya que al
parecer son los que el usuario mejor comprenda y en las que poda apoyar, con el pasar de los aos esta
situacin a cambiado y en la actualidad se utilizan tambin pruebas unitarias en la mayora de los
aplicativos desarrollados, siendo las pruebas unitarias una primera etapa y las pruebas funcionales la
segunda y definitiva en la que se da la conformidad del sistema.

Los sistemas que han pasado por pruebas unitarias tienen un menor tiempo de pruebas funcionales, este
comportamiento es obvio, ya que las pruebas unitarias nos permiten encontrar los errores ms evidentes
y fciles de corregir, en la etapa de pruebas funcionales el sistema debera estar bastante estable y con
muy pocos errores crticos. Si un sistema llega a la etapa de pruebas funcionales con demasiados errores
crticos y/o bloqueantes, se debera devolver el sistema a la etapa de pruebas unitarias ya que resulta
muy poco productivo realizar pruebas funcionales con sistemas inestables, el avance es demasiado lento
y el analista de pruebas no podr apoyar mucho en la resolucin de los errores ya que en esta etapa solo
se centra la atencin en las entradas y salidas, y no en la lgica intermedia, (Black Box Caja Negra).

Ing. Alexander Or B.

UNIT TESTING - PRUEBAS UNITARIAS - CAP 1

Al desarrollar un nuevo software o sistema de informacin, la primera etapa de pruebas a considerar es la

etapa de pruebas unitarias o tambin llamada pruebas de caja blanca (White Box), ests pruebas tambin
son llamadas pruebas modulares ya que nos permiten determinar si un modulo del programa esta listo y
correctamente terminado, estas pruebas no se deben confundir con las pruebas informales que realiza el
programador mientras esta desarrollando el mdulo.

El principal factor que se debe considerar al inicio de las pruebas es el tamao del mdulo a probar, se
debe considerar si el tamao del mdulo permitir probar adecuadamente toda su funcionalidad de
manera sencilla y rpida. Tambin es importante separar los mdulos de acuerdo a su funcionalidad, si
los mdulos son muy grandes y contienen muchas funcionalidades, estos se volvern ms complejos de
probar y al encontrar algn error ser ms difcil ubicar la funcionalidad defectuosa y corregirla. Al hacer
esta labor el analista de pruebas podr recomendar que un modulo muy complejo sea separado en 2 o 3
mdulos ms sencillos.
Este tipo de pruebas debe ser realizado por personal especializado en Software testing, el cual debe estar
familiarizado en el uso de herramientas de depuracin y pruebas, as mismo deben conocer el lenguaje
de programacin en el que se esta desarrollando la aplicacin, en la actualidad existen una gran cantidad
de herramientas que apoyan la labor del analista de pruebas, inclusive se pueden conseguir herramientas
para cada tipo de lenguaje, estas herramientas pueden facilitar el desarrollo de pruebas, elaboracin de
casos de pruebas, seguimiento de errores, etc. Algunas de las herramientas que se utilizan para pruebas
unitarias son: JUnit, La Suite de Mercury, CPPUnit etc.

El objetivo fundamental de las pruebas unitarias es asegurar el correcto funcionamiento de las interfases,
o flujo de datos entre componentes.

No es un requisito indispensable la culminacin de todos los mdulos del sistema para iniciar las pruebas,
generalmente las pruebas modulares y las pruebas integrales se solapan; en la actualidad algunas
metodologas consideran oportuno iniciar la etapa de pruebas unitarias poco despus del desarrollo.

En esta imagen se muestra lo que se considera una representacin clsica de Software Testing White Box
o pruebas de caja blanca, en este tipo de pruebas el cubo representara un sistema en donde se pueden
observar los diversos componentes que forman parte del mismo, cada uno de estos componentes debe
ser probado en su totalidad (valos), y tambin sus interfases o comunicaciones con los dems
componentes (flechas), este tipo de pruebas tambin son llamadas pruebas de caja de cristal ya que este
tlimo termino representa mejor el tipo de pruebas.

COMO REALIZAR PRUEBAS FUNCIONALES?

Las pruebas funcionales - Functional Software Testing y las pruebas unitarias Unit Software Testing deben
ser consideradas como temas cien por ciento tcnicos, en mi experiencia como analista de pruebas o
tambin llamado tester, he llegado a probar una buena cantidad de sistemas en varias empresas,
enfocadas principalmente al sector financiero.

Para el analista de pruebas es muy importante y conveniente tener una definicin funcional y tcnica
decente antes de iniciar el proceso de prueba, en realidad en un proceso de aseguramiento de la calidad
el analista QA revisor debe validar que estos documentos son lo suficientemente claros y consistentes,
una vez aprobados estos documentos podrn servir de base para que el analista de pruebas pueda
preparar el plan de pruebas, el cronograma de pruebas y los casos de prueba.

Cada vez que tengo un sistema en mis manos siento que mi labor debe ser darle un valor agregado, cada
error que yo pudiera encontrar significa un xito para la calidad del sistema. Evidentemente el analista de
pruebas o tester debe ser un profesional en Ing. De Sistemas o Ing. de Software, los conocimientos
tcnicos son valiosos en esta labor, pero no son suficientes, necesitamos tambin tener conocimientos del
negocio, en la actualidad los sistemas ms importantes son realizados para dar solucin a los problemas
de negocios. El nivel de conocimiento del tester sobre un negocio debe ser similar al del usuario que
utilizar el sistema. Un tester experimentado puede llegar a tener un amplio conocimiento de diversos
negocios y le resultar sencillo adaptarse a cualquier tipo de aplicacin y a cualquier tipo de plataforma:
Web, C/S o Host, siendo esta ltima a m parecer la ms complicada.

Para conocer como funcionara el sistema y tener una visin general de lo que este hace para el negocio
es necesario asimilar la documentacin funcional y tcnica previamente definida. Luego de asimilar estos
conocimientos ser ms sencillo el desarrollo de los casos de prueba.

En las pruebas funcionales los casos de prueba tienen el objetivo de detectar errores, los casos de
prueba deben definir los datos de entrada a utilizar, el proceso que debemos seguir en el sistema y el
resultado esperado. Prximamente espero publicar un artculo tocando el tema de cmo realizar buenos
casos de prueba.

Una vez concluidos los casos de prueba es mas sencillo poder estimar cuanto tiempo nos tomara una
primera barrida de pruebas y con esto tambin podremos realizar nuestro cronograma y plan de pruebas.

Los casos de prueba nos permitirn probar todas las funcionalidades del sistema, sin embargo es
importante tener buen criterio a la hora de desarrollarlos. Las combinaciones de casos de prueba podran
ser prcticamente infinitas, propongo el siguiente ejemplo:

Si pensamos hacer casos funcionales para un sistema bancario nos encontraremos con una gran
combinacin de variables:

Para este ejemplo solo nos centraremos en un simple retiro bancario, en donde nos encontraramos con
las siguientes variables:

En que tipo de cuenta haremos el cargo? Ahorros, Corriente, A Plazos

Esto nos dara al menos 3 variables o casos de prueba.

La cuanta tendr saldo? Saldo = 0, Saldo > 0, Saldo < 0

3 variables

Es una cuenta en Moneda Nacional MN o Moneda extranjera?

2 variables

Pertenece a una Persona natural PN o Persona Jurdica PJ?

2 variables

La cuenta es mancomunada? Si o No
2 variables

En que estado se encuentra la cuenta? Activa, Inactiva, Cerrada (Suponiendo que solo se manejen 3
estados).
3 variables

La cuenta tendr alguna facilidad crediticia? Es decir Permite sobregiros?

Si o No
2 variables

De que tipo ser el cargo a la cuenta?

1. Transferencia entre cuenta propia

 2. Transferencia a un tercero

3. Transferencia interbancaria

4. Retiro en efectivo

5. Pago de un cheque

5 variables

En que canal de atencin se realizar esta operacin?

1. En ventanilla
2. Cajero Automtico ATM

3. POS Pago de servicio o consumo

4. Home Bankin

4 variables

Para este ejemplo tan sencillo podramos obtener fcilmente ms de 3000 casos de prueba y ni siquiera
estamos enfocados a los casos que presentarn en cada pantalla. Como mens, listas, grillas, botones
etc. Por este motivo debemos delimitar claramente cual es la funcionalidad que queremos probar
diseando cada caso de manera que abarque la mayor cantidad de esfuerzo posible al sistema.

Una vez que empezamos a probar nuestros casos siempre deberamos ir un poco ms all. Muchos de
los errores que he podido encontrar no estaban escritos en mis casos de prueba. Si en mi caso defino
hacer un cargo de 1000 dlares, luego de eso podra hacer una prueba con un cargo de 1000.01 y otro de
9999.99 siempre tratando de encontrar los valores limites que provoquen un mal funcionamiento. Es
interesante notar que la gran mayora de los errores se encuentran en los valores lmite. Si una pantalla
se define para que no soporte un nmero mayor de 99999999.99 pues entonces probemos con
100000000.00 pues el sistema debera mostrarnos un mensaje indicando que el monto ingresado esta
fuera del rango permitido o algo por el estilo. Es increble como algunos programadores creen que no se
deben probar casos para los cuales el sistema no esta preparado, bueno yo pienso totalmente lo contrario
un buen sistema debe funcionar perfectamente con datos ingresados bien o mal esto diferencia a un
sistema de alta calidad, se debe probar que el sistema haga lo que debe de hacer y por supuesto que no
haga lo que no debe de hacer, la labor del analista de pruebas es totalmente destructiva para con el
sistema, un analista tester jams debera estar bajo las ordenes de un programador y tampoco es
recomendable dejar que el programador pruebe sus propios programas, es gracioso cuando me pongo a
pensar en la gran cantidad de programadores que me han pagado apuestas por su seguridad en la
robustez de sus sistemas, simplemente en el fondo no quieren maltratarlos, los aman

Otro nicho en el que se ocultan errores podran ser los campos de ingreso de datos, an no entiendo
porque tantos programadores no colocan valores lmite mximos permitidos en los campos de texto,
sobre todo en los campos de prrafos o multilneas, disfruto de esas pruebas haciendo un solo Copy de
un texto mediano para luego hacer 100 veces Paste, casi me parece escuchar como se truenan los
huesos de la base de datos cuando no soportan el contenido. Si realizo esa prueba la primera vez en un
sistema y lo logra pasar limpio pues ese programador se ha ganado mi respeto, a pesar de ser una
definicin tan simple muchos la olvidan.

Las pruebas que requieran clculos de diversos valores deberan tener pocos casos pero muy extensos y
complejos, alguna vez hice pruebas para un sistema de bolsa de valores en donde se deberan calcular
diversos campos calculados, cada uno de ellos mostrado en un campo o grilla, el caso debe especificar
que valor se espera en cada campo y una vez ejecutado el caso constataremos que los datos que se
presenten sean correctos, tanto en las pantallas como en los reportes, jams he tenido la experiencia de
encontrar un sistema nuevo sin errores en sus clculos complejos El sistema nunca funciona bien la
primera vez. Ese es mi lema!

Por ltimo una muy buena recomendacin de pruebas es el manejo del valor cero 0 muchas veces por la
complejidad de los procesos el programador olvida que este valor puede llegar a ser un divisor de otro
valor y entonces: Error Exception Faillure #afg99d7 - no valido o algn otro mensaje horrible.
Espero que con estas pequeas recomendaciones puedan ser capaces de encontrar una gran cantidad
de errores. Prximamente espero mejorar y crear mejores artculos. No olviden que pueden escribirnos
sobre cualquier consulta o comentario.

Ing. Alexander Or B