SlideShare una empresa de Scribd logo
PLAN DE PRUEBAS DE SOFTWARE

El Plan de Pruebas
El propósito 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 (verificación, integración e integración).

Un plan de pruebas incluye:

1. Identificador del plan.
Preferiblemente de alguna forma mnemónica que permita relacionarlo con su
alcance, por ej. TP-Global (plan global del proceso de pruebas), TP-Req-Seguridad1
(plan de verificación del requerimiento 1 de seguridad), TP-Contr-X (plan de
verificación del contrato asociado al evento de sistema X), TP-Unit-
Despachador.iniciar (plan de prueba unitario para el método iniciar de la clase
Despachador). Como todo artefacto del desarrollo, está sujeto a control de
configuración, por lo que debe distinguirse adicionalmente la versión 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 configuración a probar y las condiciones mínimas que debe cumplir para
comenzar a aplicarle el plan. Por un lado, es dificil y riesgoso probar una
configuración que aún reporta fallas; por otro lado, si esperamos a que todos los
módulos estén perfectos, puede que detectemos fallas graves demasiado tarde.

4. Estrategia
Describe la técnica, patrón y/o herramientas a utilizarse en el diseño de los casos
de prueba. Por ejemplo, en el caso de pruebas unitarias de un procedimiento, esta
sección podría indicar: "Se aplicará la estrategia caja-negra de fronteras de la
precondición" o "Ejercicio de los caminos ciclomáticos válidos". En lo posible la
estrategia debe precisar el número mínimo de casos de prueba a diseñar, por ej.
100% de las fronteras, 60% de los caminos ciclomáticos... La estrategia también
explicita el grado de automatización que se exigirá, tanto para la generación de
casos de prueba como para su ejecución.

5. Categorización de la configuración
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 culminación pueden ser tan simples como aprobar
el número mínimo de casos de prueba diseñados o tan complejo como tomar en
cuenta no sólo el número mínimo, sino también el tiempo previsto para las pruebas
y la tasa de detección de fallas.

6. Tangibles
Explicita los documentos a entregarse al culminar el proceso previsto por el plan p.
ej. subplanes, especificación de pruebas, casos de prueba, resumen gerencial del
proceso y bitácora 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 características del hardware, el software de sistemas (p. ej. el
sistema de operación), cualquier otro software necesario para llevar a cabo las
pruebas, así como la colocación específica del software a probar (p. ej. qué módulos
se colocan en qué máquinas de una red local) y la configuración del software de
apoyo.
La sección incluye un estimado de los recursos humanos necesarios para el
proceso. También se indican cualquier requerimiento especial del proceso:
actualización de licencias, espacio de oficina, tiempo en la máquina de producción,
seguridad.



9. Calendario
Esta sección 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 quién 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 español las pruebas de software se aplican como una etapa más
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
mayoría 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 más críticas del ciclo de vida del
desarrollo   de   software     y   esto   ha   causado     el        origen    de    diversas   metodologías.


En la actualidad el software testing se hace más complicado ya que debe hacer frente a una gran
cantidad de metodologías de desarrollo, lenguajes de programación, sistemas operativos, hardware etc.


Es por esto que el testing debe apoyarse en metodologías generales que revisan los aspectos más
fundamentales que debe considerar todo proceso de pruebas. Debido a esta complejidad actualmente se
cuentan con una gran cantidad de software diseñado exclusivamente para la etapa de pruebas,
incluyendo la gestión del proceso de software testing, la administración y seguimiento de errores, la
administración de los casos de prueba, automatización de pruebas etc.

Luego de culminadas las etapas de análisis, diseño 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 producción, lo ideal es preparar un ambiente de pruebas lo más parecido a los
ambientes que existen en producción 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 formación que les permite detectar una gran cantidad de errores
en tiempos mínimos, así como una metodología especifica que les permite hacer el trabajo de manera
correcta, algunas empresas más informales utilizan a los futuros usuarios del sistema como testers
situación que puede traer una serie de problemas debido a la poca experiencia que pueden tener los
usuarios en la detección de errores, además se obvian pruebas importantes como las pruebas de
Esfuerzo o “Stress testing”, también se dejan de lado las pruebas unitarias o pruebas modulares, las que
deberían 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 difícil probar con objetividad un software si nosotros mismos lo hemos desarrollado, un
técnico o analista programador empezara a probar con la idea preconcebida de que su hijito trabaja a la
perfección e inconcientemente evitara realizar pruebas mas exhaustivas considerando que las mismas
podrían 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 específicas para los cuales han
sido creados, es común 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       producción.


A este tipo de pruebas se les denomina también pruebas de comportamiento o pruebas de caja negra, ya
que los testers o analistas de pruebas, no enfocan su atención a como se generan las respuestas del
sistema, básicamente el enfoque de este tipo de prueba se basa en el análisis 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 mayoría de los casos son realizadas manualmente por el analista de
pruebas, también 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 automatización de pruebas puede resultar compleja y solo la recomendaría en algunas
funcionalidades específicas, por ejemplo en las pantallas que tendrán 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 usaría 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 básicamente al negocio, posibles particularidades
que no se hayan contemplado adecuadamente en el diseño funcional, el analista de pruebas debería dar
fuerza a las pruebas funcionales y más aún a las de robustez, generalmente los usuarios realizan las
pruebas con la idea que todo debería funcionar, a diferencia del analista de pruebas que tiene más bien
una misión destructiva, su objetivo será encontrar alguna posible debilidad y si la llega a ubicar se
esforzará por que deje de ser pequeña y posiblemente se convertirá en un gran error, cada error
encontrado por el analista de pruebas es un éxito, y se debería 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 algún malestar si el tester sigue encontrando errores, si no se corrige esta
situación los proyectos en su gran mayoría fracasaran o perderán más tiempo aún.

En la empresa en la he laborado algunos años solo se realizaban pruebas del tipo funcional, ya que al
parecer son los que el usuario mejor comprendía y en las que podía apoyar, con el pasar de los años esta
situación a cambiado y en la actualidad se utilizan también pruebas unitarias en la mayoría 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 más evidentes
y fáciles de corregir, en la etapa de pruebas funcionales el sistema debería estar bastante estable y con
muy pocos errores críticos. Si un sistema llega a la etapa de pruebas funcionales con demasiados errores
críticos y/o bloqueantes, se debería 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 resolución de los errores ya que en esta etapa solo
se centra la atención en las entradas y salidas, y no en la lógica intermedia, (Black Box – Caja Negra).

Ing. Alexander Oré B.

UNIT TESTING - PRUEBAS UNITARIAS - CAP 1

Al desarrollar un nuevo software o sistema de información, la primera etapa de pruebas a considerar es la
etapa de pruebas unitarias o también llamada pruebas de caja blanca (White Box), estás pruebas también
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 módulo.

El principal factor que se debe considerar al inicio de las pruebas es el tamaño del módulo a probar, se
debe considerar si el tamaño del módulo permitirá probar adecuadamente toda su funcionalidad de
manera sencilla y rápida. También es importante separar los módulos de acuerdo a su funcionalidad, si
los módulos son muy grandes y contienen muchas funcionalidades, estos se volverán más complejos de
probar y al encontrar algún error será más difícil 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
módulos más 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 depuración y pruebas, así mismo deben conocer el lenguaje
de programación en el que se esta desarrollando la aplicación, 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, elaboración 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 culminación de todos los módulos del sistema para iniciar las pruebas,
generalmente las pruebas modulares y las pruebas integrales se solapan; en la actualidad algunas
metodologías consideran oportuno iniciar la etapa de pruebas unitarias poco después del desarrollo.


En esta imagen se muestra lo que se considera una representación clásica de Software Testing White
Box o pruebas de caja blanca, en este tipo de pruebas el cubo representaría 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 también sus interfases o comunicaciones con los demás
componentes (flechas), este tipo de pruebas también 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 técnicos, en mi experiencia como analista de
pruebas o también 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 definición funcional y técnica
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 podrán 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
técnicos son valiosos en esta labor, pero no son suficientes, necesitamos también tener conocimientos del
negocio, en la actualidad los sistemas más importantes son realizados para dar solución 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 aplicación y a cualquier tipo de plataforma:
Web, C/S o Host, siendo esta última a mí parecer la más complicada.

Para conocer como funcionara el sistema y tener una visión general de lo que este hace para el negocio
es necesario asimilar la documentación funcional y técnica previamente definida. Luego de asimilar estos
conocimientos será más 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. Próximamente espero publicar un artículo tocando el tema de cómo 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 también podremos realizar nuestro cronograma y plan de pruebas.

Los casos de prueba nos permitirán probar todas las funcionalidades del sistema, sin embargo es
importante tener buen criterio a la hora de desarrollarlos. Las combinaciones de casos de prueba podrían
ser prácticamente infinitas, propongo el siguiente ejemplo:

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

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

¿En que tipo de cuenta haremos el cargo? Ahorros, Corriente, A Plazos
Esto nos daría 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 Jurídica 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 atención se realizará esta operación?

    1.   En ventanilla
    2.   Cajero Automático – ATM

    3.   POS – Pago de servicio o consumo

    4.   Home Bankin

4 variables

Para este ejemplo tan sencillo podríamos obtener fácilmente más de 3000 casos de prueba y ni siquiera
estamos enfocados a los casos que presentarán en cada pantalla. Como menús, listas, grillas, botones
etc. Por este motivo debemos delimitar claramente cual es la funcionalidad que queremos probar
diseñando cada caso de manera que abarque la mayor cantidad de esfuerzo posible al sistema.

Una vez que empezamos a probar nuestros casos siempre deberíamos ir un poco más 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 dólares, luego de eso podría 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 mayoría de los errores se encuentran en los valores límite. Si una pantalla
se define para que no soporte un número mayor de 99999999.99 pues entonces probemos con
100000000.00 pues el sistema debería mostrarnos un mensaje indicando que el monto ingresado esta
fuera del rango permitido o algo por el estilo. Es increíble 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 jamás debería 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 podrían ser los campos de ingreso de datos, aún no entiendo
porque tantos programadores no colocan valores límite máximos permitidos en los campos de texto,
sobre todo en los campos de párrafos o multilíneas, 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
definición tan simple muchos la olvidan.

Las pruebas que requieran cálculos de diversos valores deberían tener pocos casos pero muy extensos y
complejos, alguna vez hice pruebas para un sistema de bolsa de valores en donde se deberían 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, jamás he tenido la experiencia de
encontrar un sistema nuevo sin errores en sus cálculos complejos “El sistema nunca funciona bien la
primera vez”. ¡Ese es mi lema!

Por último una muy buena recomendación 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 algún otro mensaje horrible.
Espero que con estas pequeñas recomendaciones puedan ser capaces de encontrar una gran cantidad
de errores. Próximamente espero mejorar y crear mejores artículos. No olviden que pueden escribirnos
sobre cualquier consulta o comentario.

Ing. Alexander Oré B.

Más contenido relacionado

La actualidad más candente

Pruebas De Software
Pruebas De SoftwarePruebas De Software
Pruebas De Software
Ricardo Mansilla
 
13 Privacidad En La Red
13 Privacidad En La Red13 Privacidad En La Red
13 Privacidad En La Red
msma
 
Diseño caso de pruebas
Diseño caso de pruebasDiseño caso de pruebas
Diseño caso de pruebas
Rocio Camargo Villa
 
Ejemplo plan de_pruebas
Ejemplo plan de_pruebasEjemplo plan de_pruebas
Ejemplo plan de_pruebas
nicolas2100
 
5. Métodos de Prueba de Software
5. Métodos de Prueba de Software5. Métodos de Prueba de Software
5. Métodos de Prueba de Software
Mario A Moreno Rocha
 
Proceso del Software
Proceso del Software Proceso del Software
Proceso del Software
Ares Atzarel Hernández Rodríguez
 
tipos de pruebas.
tipos de pruebas.tipos de pruebas.
tipos de pruebas.
Juan Ravi
 
Guia iso 9126
Guia iso 9126Guia iso 9126
Tipos de-pruebas
Tipos de-pruebasTipos de-pruebas
Tipos de-pruebas
Carlos Godoy Fajardo
 
Pruebas unitarias
Pruebas unitariasPruebas unitarias
Pruebas unitarias
Jose Luis Rodriguez Roldan
 
10.el diseño en el nivel de componentes
10.el diseño en el nivel de componentes10.el diseño en el nivel de componentes
10.el diseño en el nivel de componentes
Ramiro Estigarribia Canese
 
Plan de pruebas
Plan de pruebasPlan de pruebas
Plan de pruebas
Oscar Ramos
 
Escalabilidad
EscalabilidadEscalabilidad
Escalabilidad
Nombre Apellidos
 
Normas ISO 9126 - 25000
Normas ISO 9126 - 25000Normas ISO 9126 - 25000
Normas ISO 9126 - 25000
Loreto Arriagada
 
Sqa ejemplo
Sqa ejemploSqa ejemplo
Sqa ejemplo
Jose Limon
 
Ventajas y desventajas de moprosoft
Ventajas y desventajas de moprosoftVentajas y desventajas de moprosoft
Ventajas y desventajas de moprosoft
Chuyito Alvarado
 
Taller casos de prueba
Taller casos de pruebaTaller casos de prueba
Taller casos de prueba
Andrés Grosso
 
GESTIÓN DE LA CONFIGURACIÓN DEL SOFTWARE (GCS)
GESTIÓN DE LA CONFIGURACIÓN DEL SOFTWARE (GCS)GESTIÓN DE LA CONFIGURACIÓN DEL SOFTWARE (GCS)
GESTIÓN DE LA CONFIGURACIÓN DEL SOFTWARE (GCS)
Mónica María Espejo Pérez
 
Sqa
SqaSqa
Estimación de Proyectos de Software
Estimación de Proyectos de SoftwareEstimación de Proyectos de Software
Estimación de Proyectos de Software
Andrés Felipe Montoya Ríos
 

La actualidad más candente (20)

Pruebas De Software
Pruebas De SoftwarePruebas De Software
Pruebas De Software
 
13 Privacidad En La Red
13 Privacidad En La Red13 Privacidad En La Red
13 Privacidad En La Red
 
Diseño caso de pruebas
Diseño caso de pruebasDiseño caso de pruebas
Diseño caso de pruebas
 
Ejemplo plan de_pruebas
Ejemplo plan de_pruebasEjemplo plan de_pruebas
Ejemplo plan de_pruebas
 
5. Métodos de Prueba de Software
5. Métodos de Prueba de Software5. Métodos de Prueba de Software
5. Métodos de Prueba de Software
 
Proceso del Software
Proceso del Software Proceso del Software
Proceso del Software
 
tipos de pruebas.
tipos de pruebas.tipos de pruebas.
tipos de pruebas.
 
Guia iso 9126
Guia iso 9126Guia iso 9126
Guia iso 9126
 
Tipos de-pruebas
Tipos de-pruebasTipos de-pruebas
Tipos de-pruebas
 
Pruebas unitarias
Pruebas unitariasPruebas unitarias
Pruebas unitarias
 
10.el diseño en el nivel de componentes
10.el diseño en el nivel de componentes10.el diseño en el nivel de componentes
10.el diseño en el nivel de componentes
 
Plan de pruebas
Plan de pruebasPlan de pruebas
Plan de pruebas
 
Escalabilidad
EscalabilidadEscalabilidad
Escalabilidad
 
Normas ISO 9126 - 25000
Normas ISO 9126 - 25000Normas ISO 9126 - 25000
Normas ISO 9126 - 25000
 
Sqa ejemplo
Sqa ejemploSqa ejemplo
Sqa ejemplo
 
Ventajas y desventajas de moprosoft
Ventajas y desventajas de moprosoftVentajas y desventajas de moprosoft
Ventajas y desventajas de moprosoft
 
Taller casos de prueba
Taller casos de pruebaTaller casos de prueba
Taller casos de prueba
 
GESTIÓN DE LA CONFIGURACIÓN DEL SOFTWARE (GCS)
GESTIÓN DE LA CONFIGURACIÓN DEL SOFTWARE (GCS)GESTIÓN DE LA CONFIGURACIÓN DEL SOFTWARE (GCS)
GESTIÓN DE LA CONFIGURACIÓN DEL SOFTWARE (GCS)
 
Sqa
SqaSqa
Sqa
 
Estimación de Proyectos de Software
Estimación de Proyectos de SoftwareEstimación de Proyectos de Software
Estimación de Proyectos de Software
 

Similar a Plan de pruebas de software

Capitulo 17 estrategias_de_prueba_de_software
Capitulo 17 estrategias_de_prueba_de_softwareCapitulo 17 estrategias_de_prueba_de_software
Capitulo 17 estrategias_de_prueba_de_software
Andres Valencia
 
Auditoria ii
Auditoria iiAuditoria ii
Auditoria ii
Jeyzon Big-Monster
 
Seminario de actuaciones presentacion.pptx
Seminario de actuaciones presentacion.pptxSeminario de actuaciones presentacion.pptx
Seminario de actuaciones presentacion.pptx
aulasdigitales24
 
Estrategias prueba de software
Estrategias prueba de softwareEstrategias prueba de software
Estrategias prueba de software
Centro Líbano
 
Fundamento pruebas Ingeniería del software
Fundamento pruebas Ingeniería del softwareFundamento pruebas Ingeniería del software
Fundamento pruebas Ingeniería del software
William Remolina
 
Pruebas de software
Pruebas de softwarePruebas de software
Pruebas de software
panavarrv
 
2 pdf.pdf
2 pdf.pdf2 pdf.pdf
Trabajo de teoria de sistema 2
Trabajo de teoria de sistema 2Trabajo de teoria de sistema 2
Trabajo de teoria de sistema 2
Darwis Gonzalez
 
Fundamentos Rational Tester
Fundamentos Rational TesterFundamentos Rational Tester
Fundamentos Rational Tester
Professional Testing
 
Exposición software.pptx
Exposición software.pptxExposición software.pptx
Exposición software.pptx
kevin manuel ortiz galeano
 
Exposición software.pptx
Exposición software.pptxExposición software.pptx
Exposición software.pptx
kevin manuel ortiz galeano
 
Epa aqui
Epa aquiEpa aqui
Epa aqui
Darwis Gonzalez
 
Diseã±os de planes_de_pruebas_de_software1
Diseã±os de planes_de_pruebas_de_software1Diseã±os de planes_de_pruebas_de_software1
Diseã±os de planes_de_pruebas_de_software1
naviwz
 
pruebas de calidad.pdf
pruebas de calidad.pdfpruebas de calidad.pdf
pruebas de calidad.pdf
Chirmi1
 
Ciclo de vida de un software
Ciclo de vida de un softwareCiclo de vida de un software
Ciclo de vida de un software
MargotVenegas2
 
Diseños de planes de pruebas de software1
Diseños de planes de pruebas de software1Diseños de planes de pruebas de software1
Diseños de planes de pruebas de software1
Vanessa Toral Yépez
 
Tipos de pruebas de software
Tipos de pruebas de softwareTipos de pruebas de software
Tipos de pruebas de software
Antonio Elias Muñoz Espinoza
 
Taller 3 calidad_de_software_jcom
Taller 3 calidad_de_software_jcomTaller 3 calidad_de_software_jcom
Taller 3 calidad_de_software_jcom
Juan Carlos Ospina
 
Pruebas - Fundamentos
Pruebas - FundamentosPruebas - Fundamentos
Pruebas - Fundamentos
Professional Testing
 
Pruebas fundamentos
Pruebas fundamentosPruebas fundamentos
Pruebas fundamentos
Professional Testing
 

Similar a Plan de pruebas de software (20)

Capitulo 17 estrategias_de_prueba_de_software
Capitulo 17 estrategias_de_prueba_de_softwareCapitulo 17 estrategias_de_prueba_de_software
Capitulo 17 estrategias_de_prueba_de_software
 
Auditoria ii
Auditoria iiAuditoria ii
Auditoria ii
 
Seminario de actuaciones presentacion.pptx
Seminario de actuaciones presentacion.pptxSeminario de actuaciones presentacion.pptx
Seminario de actuaciones presentacion.pptx
 
Estrategias prueba de software
Estrategias prueba de softwareEstrategias prueba de software
Estrategias prueba de software
 
Fundamento pruebas Ingeniería del software
Fundamento pruebas Ingeniería del softwareFundamento pruebas Ingeniería del software
Fundamento pruebas Ingeniería del software
 
Pruebas de software
Pruebas de softwarePruebas de software
Pruebas de software
 
2 pdf.pdf
2 pdf.pdf2 pdf.pdf
2 pdf.pdf
 
Trabajo de teoria de sistema 2
Trabajo de teoria de sistema 2Trabajo de teoria de sistema 2
Trabajo de teoria de sistema 2
 
Fundamentos Rational Tester
Fundamentos Rational TesterFundamentos Rational Tester
Fundamentos Rational Tester
 
Exposición software.pptx
Exposición software.pptxExposición software.pptx
Exposición software.pptx
 
Exposición software.pptx
Exposición software.pptxExposición software.pptx
Exposición software.pptx
 
Epa aqui
Epa aquiEpa aqui
Epa aqui
 
Diseã±os de planes_de_pruebas_de_software1
Diseã±os de planes_de_pruebas_de_software1Diseã±os de planes_de_pruebas_de_software1
Diseã±os de planes_de_pruebas_de_software1
 
pruebas de calidad.pdf
pruebas de calidad.pdfpruebas de calidad.pdf
pruebas de calidad.pdf
 
Ciclo de vida de un software
Ciclo de vida de un softwareCiclo de vida de un software
Ciclo de vida de un software
 
Diseños de planes de pruebas de software1
Diseños de planes de pruebas de software1Diseños de planes de pruebas de software1
Diseños de planes de pruebas de software1
 
Tipos de pruebas de software
Tipos de pruebas de softwareTipos de pruebas de software
Tipos de pruebas de software
 
Taller 3 calidad_de_software_jcom
Taller 3 calidad_de_software_jcomTaller 3 calidad_de_software_jcom
Taller 3 calidad_de_software_jcom
 
Pruebas - Fundamentos
Pruebas - FundamentosPruebas - Fundamentos
Pruebas - Fundamentos
 
Pruebas fundamentos
Pruebas fundamentosPruebas fundamentos
Pruebas fundamentos
 

Plan de pruebas de software

  • 1. PLAN DE PRUEBAS DE SOFTWARE El Plan de Pruebas El propósito 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 (verificación, integración e integración). Un plan de pruebas incluye: 1. Identificador del plan. Preferiblemente de alguna forma mnemónica que permita relacionarlo con su alcance, por ej. TP-Global (plan global del proceso de pruebas), TP-Req-Seguridad1 (plan de verificación del requerimiento 1 de seguridad), TP-Contr-X (plan de verificación del contrato asociado al evento de sistema X), TP-Unit- Despachador.iniciar (plan de prueba unitario para el método iniciar de la clase Despachador). Como todo artefacto del desarrollo, está sujeto a control de configuración, por lo que debe distinguirse adicionalmente la versión 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 configuración a probar y las condiciones mínimas que debe cumplir para comenzar a aplicarle el plan. Por un lado, es dificil y riesgoso probar una configuración que aún reporta fallas; por otro lado, si esperamos a que todos los módulos estén perfectos, puede que detectemos fallas graves demasiado tarde. 4. Estrategia Describe la técnica, patrón y/o herramientas a utilizarse en el diseño de los casos de prueba. Por ejemplo, en el caso de pruebas unitarias de un procedimiento, esta sección podría indicar: "Se aplicará la estrategia caja-negra de fronteras de la precondición" o "Ejercicio de los caminos ciclomáticos válidos". En lo posible la estrategia debe precisar el número mínimo de casos de prueba a diseñar, por ej. 100% de las fronteras, 60% de los caminos ciclomáticos... La estrategia también explicita el grado de automatización que se exigirá, tanto para la generación de casos de prueba como para su ejecución. 5. Categorización de la configuración 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
  • 2. 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 culminación pueden ser tan simples como aprobar el número mínimo de casos de prueba diseñados o tan complejo como tomar en cuenta no sólo el número mínimo, sino también el tiempo previsto para las pruebas y la tasa de detección de fallas. 6. Tangibles Explicita los documentos a entregarse al culminar el proceso previsto por el plan p. ej. subplanes, especificación de pruebas, casos de prueba, resumen gerencial del proceso y bitácora 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 características del hardware, el software de sistemas (p. ej. el sistema de operación), cualquier otro software necesario para llevar a cabo las pruebas, así como la colocación específica del software a probar (p. ej. qué módulos se colocan en qué máquinas de una red local) y la configuración del software de apoyo. La sección incluye un estimado de los recursos humanos necesarios para el proceso. También se indican cualquier requerimiento especial del proceso: actualización de licencias, espacio de oficina, tiempo en la máquina de producción, seguridad. 9. Calendario Esta sección 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 quién es el responsable de cada una de las tareas previstas en el plan.
  • 3. INTRODUCCION AL SOFTWARE TESTING El Software testing o como se conoce en español las pruebas de software se aplican como una etapa más 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 mayoría 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 más críticas del ciclo de vida del desarrollo de software y esto ha causado el origen de diversas metodologías. En la actualidad el software testing se hace más complicado ya que debe hacer frente a una gran cantidad de metodologías de desarrollo, lenguajes de programación, sistemas operativos, hardware etc. Es por esto que el testing debe apoyarse en metodologías generales que revisan los aspectos más fundamentales que debe considerar todo proceso de pruebas. Debido a esta complejidad actualmente se cuentan con una gran cantidad de software diseñado exclusivamente para la etapa de pruebas, incluyendo la gestión del proceso de software testing, la administración y seguimiento de errores, la administración de los casos de prueba, automatización de pruebas etc. Luego de culminadas las etapas de análisis, diseño 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 producción, lo ideal es preparar un ambiente de pruebas lo más parecido a los ambientes que existen en producción 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 formación que les permite detectar una gran cantidad de errores en tiempos mínimos, así como una metodología especifica que les permite hacer el trabajo de manera correcta, algunas empresas más informales utilizan a los futuros usuarios del sistema como testers situación que puede traer una serie de problemas debido a la poca experiencia que pueden tener los usuarios en la detección de errores, además se obvian pruebas importantes como las pruebas de Esfuerzo o “Stress testing”, también se dejan de lado las pruebas unitarias o pruebas modulares, las que deberían 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 difícil probar con objetividad un software si nosotros mismos lo hemos desarrollado, un técnico o analista programador empezara a probar con la idea preconcebida de que su hijito trabaja a la perfección e inconcientemente evitara realizar pruebas mas exhaustivas considerando que las mismas podrían 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 específicas para los cuales han sido creados, es común 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 producción. A este tipo de pruebas se les denomina también pruebas de comportamiento o pruebas de caja negra, ya que los testers o analistas de pruebas, no enfocan su atención a como se generan las respuestas del sistema, básicamente el enfoque de este tipo de prueba se basa en el análisis 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.
  • 4. Las pruebas funcionales en la mayoría de los casos son realizadas manualmente por el analista de pruebas, también 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 automatización de pruebas puede resultar compleja y solo la recomendaría en algunas funcionalidades específicas, por ejemplo en las pantallas que tendrán 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 usaría 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 básicamente al negocio, posibles particularidades que no se hayan contemplado adecuadamente en el diseño funcional, el analista de pruebas debería dar fuerza a las pruebas funcionales y más aún a las de robustez, generalmente los usuarios realizan las pruebas con la idea que todo debería funcionar, a diferencia del analista de pruebas que tiene más bien una misión destructiva, su objetivo será encontrar alguna posible debilidad y si la llega a ubicar se esforzará por que deje de ser pequeña y posiblemente se convertirá en un gran error, cada error encontrado por el analista de pruebas es un éxito, y se debería 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 algún malestar si el tester sigue encontrando errores, si no se corrige esta situación los proyectos en su gran mayoría fracasaran o perderán más tiempo aún. En la empresa en la he laborado algunos años solo se realizaban pruebas del tipo funcional, ya que al parecer son los que el usuario mejor comprendía y en las que podía apoyar, con el pasar de los años esta situación a cambiado y en la actualidad se utilizan también pruebas unitarias en la mayoría 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 más evidentes y fáciles de corregir, en la etapa de pruebas funcionales el sistema debería estar bastante estable y con muy pocos errores críticos. Si un sistema llega a la etapa de pruebas funcionales con demasiados errores críticos y/o bloqueantes, se debería 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 resolución de los errores ya que en esta etapa solo se centra la atención en las entradas y salidas, y no en la lógica intermedia, (Black Box – Caja Negra). Ing. Alexander Oré B. UNIT TESTING - PRUEBAS UNITARIAS - CAP 1 Al desarrollar un nuevo software o sistema de información, la primera etapa de pruebas a considerar es la etapa de pruebas unitarias o también llamada pruebas de caja blanca (White Box), estás pruebas también 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 módulo. El principal factor que se debe considerar al inicio de las pruebas es el tamaño del módulo a probar, se debe considerar si el tamaño del módulo permitirá probar adecuadamente toda su funcionalidad de manera sencilla y rápida. También es importante separar los módulos de acuerdo a su funcionalidad, si los módulos son muy grandes y contienen muchas funcionalidades, estos se volverán más complejos de probar y al encontrar algún error será más difícil 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 módulos más sencillos.
  • 5. Este tipo de pruebas debe ser realizado por personal especializado en Software testing, el cual debe estar familiarizado en el uso de herramientas de depuración y pruebas, así mismo deben conocer el lenguaje de programación en el que se esta desarrollando la aplicación, 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, elaboración 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 culminación de todos los módulos del sistema para iniciar las pruebas, generalmente las pruebas modulares y las pruebas integrales se solapan; en la actualidad algunas metodologías consideran oportuno iniciar la etapa de pruebas unitarias poco después del desarrollo. En esta imagen se muestra lo que se considera una representación clásica de Software Testing White Box o pruebas de caja blanca, en este tipo de pruebas el cubo representaría 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 también sus interfases o comunicaciones con los demás componentes (flechas), este tipo de pruebas también 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 técnicos, en mi experiencia como analista de pruebas o también 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 definición funcional y técnica 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,
  • 6. una vez aprobados estos documentos podrán 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 técnicos son valiosos en esta labor, pero no son suficientes, necesitamos también tener conocimientos del negocio, en la actualidad los sistemas más importantes son realizados para dar solución 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 aplicación y a cualquier tipo de plataforma: Web, C/S o Host, siendo esta última a mí parecer la más complicada. Para conocer como funcionara el sistema y tener una visión general de lo que este hace para el negocio es necesario asimilar la documentación funcional y técnica previamente definida. Luego de asimilar estos conocimientos será más 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. Próximamente espero publicar un artículo tocando el tema de cómo 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 también podremos realizar nuestro cronograma y plan de pruebas. Los casos de prueba nos permitirán probar todas las funcionalidades del sistema, sin embargo es importante tener buen criterio a la hora de desarrollarlos. Las combinaciones de casos de prueba podrían ser prácticamente infinitas, propongo el siguiente ejemplo: Si pensamos hacer casos funcionales para un sistema bancario nos encontraremos con una gran combinación de variables: Para este ejemplo solo nos centraremos en un simple retiro bancario, en donde nos encontraríamos con las siguientes variables: ¿En que tipo de cuenta haremos el cargo? Ahorros, Corriente, A Plazos Esto nos daría 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 Jurídica 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
  • 7. 2. Transferencia a un tercero 3. Transferencia interbancaria 4. Retiro en efectivo 5. Pago de un cheque 5 variables ¿En que canal de atención se realizará esta operación? 1. En ventanilla 2. Cajero Automático – ATM 3. POS – Pago de servicio o consumo 4. Home Bankin 4 variables Para este ejemplo tan sencillo podríamos obtener fácilmente más de 3000 casos de prueba y ni siquiera estamos enfocados a los casos que presentarán en cada pantalla. Como menús, listas, grillas, botones etc. Por este motivo debemos delimitar claramente cual es la funcionalidad que queremos probar diseñando cada caso de manera que abarque la mayor cantidad de esfuerzo posible al sistema. Una vez que empezamos a probar nuestros casos siempre deberíamos ir un poco más 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 dólares, luego de eso podría 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 mayoría de los errores se encuentran en los valores límite. Si una pantalla se define para que no soporte un número mayor de 99999999.99 pues entonces probemos con 100000000.00 pues el sistema debería mostrarnos un mensaje indicando que el monto ingresado esta fuera del rango permitido o algo por el estilo. Es increíble 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 jamás debería 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 podrían ser los campos de ingreso de datos, aún no entiendo porque tantos programadores no colocan valores límite máximos permitidos en los campos de texto, sobre todo en los campos de párrafos o multilíneas, 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 definición tan simple muchos la olvidan. Las pruebas que requieran cálculos de diversos valores deberían tener pocos casos pero muy extensos y complejos, alguna vez hice pruebas para un sistema de bolsa de valores en donde se deberían 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, jamás he tenido la experiencia de encontrar un sistema nuevo sin errores en sus cálculos complejos “El sistema nunca funciona bien la primera vez”. ¡Ese es mi lema! Por último una muy buena recomendación 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 algún otro mensaje horrible.
  • 8. Espero que con estas pequeñas recomendaciones puedan ser capaces de encontrar una gran cantidad de errores. Próximamente espero mejorar y crear mejores artículos. No olviden que pueden escribirnos sobre cualquier consulta o comentario. Ing. Alexander Oré B.