PLAN DE PRUEBAS

Departamento/Proyecto/ Subttulo
Mes 2013
Departamento/Proyecto/ Subttulo
2
 HISTRICO DE CAMBIOS

Fecha Versin Descripcin Autor

19/07/2017 1.0 Diana Marcela
Tilano/Edward Leandro
Hurtado

Departamento/Proyecto/ Subttulo
3
ndice
1.1. Error! Bookmark not defined.
1.1.1. Error! Bookmark not defined.
1.1.2. Error! Bookmark not defined.
1.2. Error! Bookmark not defined.
1.3. Error! Bookmark not defined.
2.1. Error! Bookmark not defined.
2.2. Error! Bookmark not defined.
2.3. Error! Bookmark not defined.
2.4. Error! Bookmark not defined.
2.5. Error! Bookmark not defined.
3.1. Error! Bookmark not defined.
3.2. Error! Bookmark not defined.
3.3. Error! Bookmark not defined.
3.4. Error! Bookmark not defined.
3.5. Error! Bookmark not defined.
5.1. Error! Bookmark not defined.
5.2. Error! Bookmark not defined.
5.2.1. Error! Bookmark not defined.
5.2.2. Error! Bookmark not defined.
5.2.2.1. Error! Bookmark not defined.
5.2.3. Error! Bookmark not defined.
5.2.3.1. 14
5.2.3.2. 14

Departamento/Proyecto/ Subttulo
4
1. INTRODUCCIN
LEANDIA; es un sistema con el que los pacientes podrn reservar sus citas de manera
remota. El software permite mejorar mejorar la atencin que se brinda en el CENTRO
CLNICO Y DE REHABILITACIN haciendo posible que los usuarios reserven las citas
mdicas sin necesidad de hacer presencia.De esta forma se agilizan los procesos, aumenta
la satisfaccin de los usuarios y se ahorra en costo de operacin.

OBJETIVOS Y TAREAS
1.1.1. Objetivos

- Registrar las reservas solicitadas por los pacientes, permitiendo la cancelacin y

modificacin, confeccionar los listados de atencin de los pacientes diarios, tanto por
el Centro Dacadi como por profesional.
- Registra el diagnstico y los procedimientos realizados sobre el paciente.
- El Sistema actualiza los datos del usuario en la base de datos.

Tareas
- Se debe crear el tamao mximo de base de datos (real, escalado o con datos
representativos) y mltiples clientes ejecutando consultas simultneamente por un
perodo de tiempo extenso
- Seguridad en el mbito de aplicacin, incluyendo el acceso a los datos y a las
funciones del CENTRO.
- Seguridad en el mbito de sistema, incluyendo conexin, o acceso remoto al sistema
1.2. AUDIENCIA PREVISTA
Los grupos encargados de realizar la audiencia sern los siguientes:
- Equipo de pruebas
- Equipo de desarrollo
- Jefe de proyecto
- Grupo de gestin de proyecto

Departamento/Proyecto/ Subttulo
5
1.3. REFERENCIAS
Lista todos los documentos que se han utilizado para crear este plan, los que se usarn en
el desarrollo de casos de pruebas o durante la ejecucin de pruebas. Estos se pueden listar
en una tabla como la siguiente:

Documento Autor Versin Localizacin

estrategias y Rodriguez Tello http://www.tamps.cin

tcnicas de pruebas Edwardo vestav.mx/~ertello/s
de software we/sesion15.pdf

Introduccion a las Toledo Rodriguez https://s3-us-west-

Pruebas de sistemas federico 2.amazonaws.com/a
de informacin bstracta/Publications
/Introducci%C3%B3n
+a+las+Pruebas+de
+Sistemas+de+Infor
maci%C3%B3n.pdf

Departamento/Proyecto/ Subttulo
6
2. ALCANCE Y ENFOQUE
2.1. TEMS A PROBAR (FUNCIONES)
La prueba de esfuerzo en un tipo de prueba de performance implementada y ejecutada para
encontrar errores cuando hay pocos recursos o cuando hay competencia por recursos. Poca
memoria o poco espacio de disco pueden revelar fallas en el software que no aparecen bajo
condiciones normales de cantidad de recursos. Otras fallas pueden resultar al competir por
recursos compartidos como bloqueos de bases de datos o ancho de banda de red. La
prueba de esfuerzo tambin puede usarse para identificar el trabajo mximo que el software
puede manejar.
Poca memoria o sin disponibilidad de memoria en el servidor
Cantidad mxima de clientes conectados
Mltiples usuarios realizando la misma operacin sobre los mismos datos
Peor caso de volumen de operaciones.

2.2. CUESTIONES DE RIESGO

Identifica qu software se ha de probar y cules son las reas crticas, tales como:
- Entregable de un producto desarrollado por terceros.
- Capacidad de usar y entender una nueva herramientas
- Funciones extremadamente complejas
- Modificaciones de componentes con un histrico pasado de fallos
- Mdulos o peticiones de cambio mal documentados
Hay algunos riesgos de software inherentes como la complejidad; stos han de ser
identificados.
Otra posible rea de riesgo es el mal entendimiento de los requisitos originales. Esto puede
ocurrir a nivel de gestin, usuario o desarrollador. Hay que tener en cuenta los requisitos
que no estn claros y los que no se pueden probar.

2.3. CARACTERSTICAS A PROBAR

Estrategia de Verificacin
Tipos de pruebas
Prueba de integridad de los datos y la base de datos
Prueba de Funcionalidad
Prueba de Ciclo del Negocio
Prueba de Interfase de Usuario
Prueba de Performance
Prueba de Carga
Prueba de Esfuerzo (stress, competencia por recursos, bajos recursos)
Prueba de Volumen
Prueba de Seguridad y Control de Acceso
Departamento/Proyecto/ Subttulo
7
Prueba de Fallas y Recuperacin

2.4. CARACTERSTICAS QUE NO SE VAN A PROBARe

Las vas que pueden dificultar la determinacin de los requisitos son:

Los usuarios no se involucran en la elaboracin de requisitos escritos
Los usuarios insisten en nuevos requisitos despus de que el coste y la
programacin se hayan fijado.
La comunicacin con los usuarios es lenta
Los usuarios no participan en revisiones o son incapaces de hacerlo.
Los usuarios no tienen claro lo que desean los usuarios no comprenden los
problemas tcnicos
Los usuarios no entienden el proceso del desarrollo
Esto puede conducir a la situacin donde las exigencias del consumidor cambian,
incluso cuando el desarrollo del producto ya est en marcha.

2.5. ENFOQUE (ESTRATEGIA)

Existen distintas estrategias de pruebas, y dependiendo de su alineamiento con el objetivo
de las pruebas y con los propios proyectos, estas estrategias pueden tener xito o fallar.
Otro punto a tener en cuenta es que no tiene por qu elegirse una sola estrategia. Puede
utilizarse una estrategia de manera dominante y utilizar otras de complemento. Algunos
autores como Krutchen, Pressman, Pfleger, Cardoso y Sommerville afirman que el proceso
de ejecucin de pruebas debe ser considerado durante todo el ciclo de vida de un proyecto,
para as obtener un producto de alta calidad. Su xito depender del seguimiento de una
Estrategia de Prueba adecuada.
Estrategia analtica.
Las estrategias de pruebas analticas tienen en comn el uso de alguna tcnica analtica
formal o informal normalmente durante la etapa de gestin de requisitos y de diseo del
proyecto. Por ejemplo:
a) Estrategia orientada a objetos. Para determinar el enfoque de las pruebas, se presta
atencin a los requisitos, el diseo, y la implementacin de objetos. Estos objetos pueden
incluir especificaciones de requisitos, especificaciones de diseo, diagramas UML, casos de
uso, cdigo fuente, esquemas de base de datos y diagramas entidad-relacin. Este enfoque

Departamento/Proyecto/ Subttulo
8
se basa en una buena documentacin, por lo que la ausencia de la misma implica no poder
utilizarla.
b) Estrategia basada en riesgos. Consiste en identificar riesgos estudiando el sistema,
documentacin de proyectos anteriores, objetivos de la configuracin y cualquier otro dato
que pueda encontrarse o que pueda aportar la gente involucrada en el proyecto. El diseo,
desarrollo y ejecucin de pruebas basadas en el conocimiento previo puede ser beneficioso.
Este enfoque es apropiado si se dispone de tiempo para investigar el sistema.
Los elementos que estn siendo analizados a menudo se denominan base de las pruebas.
Los resultados del anlisis guan el esfuerzo de pruebas, a menudo a travs de algunas
formas de anlisis de cobertura durante el diseo, desarrollo de la ejecucin y obtencin de
resultados de las pruebas. Estas estrategias tienden a ser minuciosas y buenas a la hora de
mitigar riesgos de calidad y encontrar errores. Sin embargo, se requiere una inversin de
tiempo importante.
Estrategia basada en modelo Las estrategias de pruebas basadas en modelo desarrollan
modelos que representan cmo el sistema debera comportarse o trabajar. Las estrategias
de pruebas basadas en modelo tienen en comn la creacin o seleccin de algn modelo
formal o informal para simular comportamientos de sistemas crticos, normalmente durante
las etapas de requisitos y diseo del proyecto. Existen distintos tipos de estrategias basadas
en modelos: a) Con una estrategia basada en escenario se realizan pruebas acorde a
escenarios del mundo real. Estos escenarios deberan abarcar la funcionalidad del sistema.
En el mundo orientado a objetos, se podra usar una estrategia basada en casos de uso,
donde se confe en documentos de diseo orientados a objetos conocidos como casos de
uso. Estos casos de uso son modelos de cmo el usuario, clientes y otras partes
involucradas en el negocio utilizan el sistema y cmo debera trabajar bajo estas
condiciones.
Con una estrategia basada en el dominio se pueden analizar diferentes dominios de datos
de entrada aceptados por el sistema, procesamiento de datos del sistema, y datos de salida
entregados por el sistema. Se decidir cul ser el mejor caso de pruebas para cada
dominio, se determinar la probabilidad de errores, frecuencia de uso y entornos
desplegados. c) Con una estrategia basada en un modelo, se disean, desarrollan y
ejecutan las pruebas que cubran los modelos que se hayan construido. Esta estrategia ser
til dependiendo de la capacidad del modelo para capturar los aspectos esenciales o
potencialmente problemticos del sistema.
Estrategia metdica La estrategia metdica tiende a seguir una lnea relativamente informal
pero con un enfoque ordenado y predecible que ayuda a comprender dnde probar.
a) Estrategia basada en el aprendizaje. Se utilizan listas de control que se han desarrollado
para guiar el proceso de pruebas. Para desarrollar estas listas de control puede ser de
ayuda el basarse en los errores que se han encontrado previamente, en lecciones
aprendidas de otros proyectos y en cualquier otra fuente.

Departamento/Proyecto/ Subttulo
9
b) Estrategia basada en funciones. Se identifica y se prueba cada funcin del sistema por
separado. Lo mismo ocurre con la estrategia basada en estados, donde se identifica y
prueba cada estado y cada posible transicin de estados que pueda ocurrir.
c) Estrategia basada en la calidad: Se utiliza una jerarqua de calidad, como la que ofrece la
ISO 9126, para identificar y probar la importancia de cada una de las caractersticas de la
jerarqua como, por ejemplo, la facilidad de uso, el rendimiento, la funcionalidad o la
escalabilidad. Con una estrategia de pruebas metdica, se siguen estos estndares como
objetivos de pruebas. Estas estrategias pueden ser rpidas y efectivas en contra de
sistemas que permanecen relativamente estables, o sistemas que son similares a otros ya
probados. Los cambios significativos pueden frenar temporalmente estas estrategias hasta
que se puedan volver a ajustar los objetivos de las pruebas a la nueva situacin del sistema.
Estrategia orienta al proceso o estndar conformista Las estrategias de pruebas orientadas
al proceso llevan el enfoque metdico un paso ms all a la hora de regular el proceso de
pruebas. Estas estrategias siguen un desarrollo externo orientado a pruebas a menudo con
pocas posibilidades de personalizacin.
Estrategia dinmica Las estrategias de pruebas dinmicas, como las estrategias de pruebas
giles, minimizan la planificacin por adelantado y prueban el diseo. Adaptan todo lo
posible el sistema bajo prueba a las condiciones que habr cuando se libere. Tpicamente,
enfatizan las ltimas etapas de pruebas. Se trata de crear un pequeo conjunto de pautas
de pruebas que se enfoquen en debilidades conocidas del software.
a) Con una estrategia de pruebas intuitiva, se puede probar acorde a la experiencia e
instinto del equipo de pruebas.
b) Con una estrategia de pruebas exploratoria, se puede aprender simultneamente sobre el
comportamiento y diseo de pruebas, a la vez que las pruebas se van ejecutando y se van
encontrando errores. Se ir refinando el enfoque de las pruebas en funcin de los resultados
obtenidos de las pruebas. Las estrategias de pruebas dinmicas valoran la flexibilidad y la
facilidad de encontrar errores. Estas estrategias no producen buena informacin
normalmente acerca de cobertura, mitigacin sistemtica de riesgos ni ofrecen la
oportunidad de detectar defectos en las primeras fases del ciclo de vida del producto.
Obviamente, aplicar estas estrategias es mejor que no realizar ningn tipo de pruebas y,
cuando van unidas a estrategias analticas, pueden servir como una excelente herramienta
para identificar el vaco dejado por las mismas.
Estrategia de pruebas filosfica Las estrategias de pruebas filosficas comienzan con una
filosofa o creencia de las pruebas.
a) Cuando se usa una estrategia de pruebas exhaustiva, se asume que todo puede tener
errores. Es decir, se decide que la posibilidad de que haya fallos latentes es inaceptable por
lo que se soportar un considerable esfuerzo al encontrar todos los errores.
b) Con la estrategia de pruebas shotgun, se asume que todo y nada puede tener y tendr
errores. Sin embargo, en este caso, se acepta que no se puede probar todo. Cuando se

Departamento/Proyecto/ Subttulo
10
llegue al punto de no tener una idea slida acerca de por PRUEBAS DE SOFTWARE 29
CIBERTEC CARRERAS PROFESIONALES dnde empezar a probar, se intentar distribuir
de manera aleatoria el esfuerzo de pruebas teniendo en cuenta las restricciones de recursos
y la agenda.
c) Con una estrategia guiada externamente, no slo se acepta que no se puede probar
todo, sino que tambin se asume que no se sabe dnde estn los errores. Sin embargo, se
confa en que otras personas puedan tener una buena idea sobre dnde estn. Para ello, se
pedir ayuda a estas personas sobre la decisin a tomar acerca de si los resultados
obtenidos son o no correctos. Por ejemplo, se puede preguntar a los usuarios, personas que
den soporte tcnico, analistas de negocio o desarrolladores del sistema sobre qu probar o
incluso confiar en ellos para hacer las pruebas. Enfatizan las ltimas etapas de pruebas
simplemente debido a la falta de reconocimiento del valor de pruebas tempranas. 1.2.1.7.
Regresin La regresin es la mala conducta de una funcin, atributo o caracterstica
previamente correctos. La palabra regresin tambin se suele usar para definir el
descubrimiento de un error que previamente no se encontr durante la ejecucin de una
prueba. La regresin normalmente est asociada a algn cambio en el sistema, como aadir
una caracterstica o arreglar un error. La regresin puede ser de tres tipos: a) Regresin
local: al producirse un cambio o arreglarse un error se crea un nuevo error. b) Regresin de
exposicin: al producirse un cambio o arreglarse un error se identifican errores ya
existentes. c) Regresin remota: un cambio o el arreglo de un error en un determinado rea
produce un fallo en otro rea del sistema. La regresin remota es la regresin ms difcil de
detectar, ya que los usuarios, clientes y el resto de los interesados en el proyecto tienden a
confiar en las caractersticas ya existentes del sistema. Por ello, los tcnicos de pruebas
deberan tener estrategias que sean efectivas en contra de todas las causas y efectos de las
regresiones. Una posible estrategia para enfrentarse a la regresin, quizs el enfoque ms
simple, es la fuerza bruta. Para la mitigacin del riesgo de regresin, la estrategia de la
fuerza bruta consiste en repetir todas las pruebas. Imaginemos que se ha desarrollado un
conjunto de pruebas bien alineadas con la calidad. En este caso, se habr desarrollado un
anlisis de riesgos de calidad slido y se tendr tiempo y recursos suficientes para cubrir
todos los riesgos crticos de calidad. Si se repiten todas las pruebas despus del ltimo
cambio realizado, se deberan encontrar todos los errores de regresin importantes. 30
CARRERAS PROFESIONALES CIBERTEC d) La automatizacin. Se puede considerar la
automatizacin como una estrategia para aumentar la calidad de un producto a un bajo
coste y optimizar el esfuerzo de las pruebas. La automatizacin es la nica manera de
repetir todas las pruebas sobre sistemas complejos y grandes. La automatizacin es
prctica cuando los costes del diseo e implementacin de pruebas automatizadas sean
recuperables, y se vayan a ejecutar de manera frecuente. A pesar de su gran utilidad, en
ocasiones, la inversin extra que supone para el proyecto y la necesidad de ciertas
habilidades por parte de miembros de la organizacin hacen que la automatizacin sea un
proceso costoso. Sin embargo, algunas de sus ventajas son: - La automatizacin puede
reducir drsticamente el esfuerzo de las pruebas de regresin. - La automatizacin permite
realizar validaciones durante los ciclos de cambios, cosa que sera imposible hacer

Departamento/Proyecto/ Subttulo
11
manualmente debido a restricciones de tiempo. - La automatizacin habilita la consistencia y
cobertura lgica. No hay riesgo alguno de excluir casos de prueba o pasar por alto errores si
se disea correctamente. Esta estrategia suele envolver pruebas funcionales automatizadas
antes de la liberacin del producto, pero algunas veces, se centra por completo en funciones
liberadas con anterioridad. Por ejemplo, se puede intentar automatizar todas las pruebas de
sistemas de tal forma que cuando se produzca cualquier cambio se pueda volver a ejecutar
cada prueba para asegurarse de que ningn rea se ha visto afectada. Pero, incluso con
una automatizacin efectiva, no siempre es posible repetir todas las pruebas ya que no
resulta prctico o su gestin es insostenible. Por ello, en ocasiones se necesitar realizar
una seleccin sobre el conjunto de pruebas a automatizar. 1.2.2. Roles y Responsabilidades
En RUP se definen los siguientes roles: - Administrador de pruebas - Analista de pruebas -
Diseador de pruebas - Ejecutor de pruebas 1.2.2.1. Administrador de pruebas Es el
responsable del xito total de la pru

CRITERIOS DE TRANSICIN

2.6. CRITERIOS DE ENTRADA

Los criterios de entrada en este caso son:
- Proceso de testing
- Descripcin general del entorno
- Interfaz de usuario
- Modelo del proceso
2.7. CRITERIOS DE SALIDA
- Realizar plan de pruebas
- Especificacin de los niveles de pruebas
2.8. CRITERIOS DE SUSPENSIN
La suspensin de las pruebas se deben suspender si el software presenta fallas en el 70 por
ciento de su codigo, ya que de esta manera es imposible crear o continuar con las
siguientes fases. de esta manera se cancelaran los procesos de prueba y se revisar
nuevamente todo el cdigo del software.

2.9. CRITERIOS DE REANUDACIN

La reanudacin de las pruebas se hace despus de que el cdigo haya sido revisado y
mejorado, despus de ello se puede pasar nuevamente al plan de prueba

Departamento/Proyecto/ Subttulo
12
2.10. CRITERIOS DE XITO Y FALLO
- El software corre con normalidad y los recursos que consumen son mnimos
- Al ejecutar el programa el sistema no muestra ningn tipo de incompatibilidad
- El tiempo que demora en cargar la informacin a la base de datos es la correcta
- Los usuarios registrados en la base de datos pueden ingresar correctamente
- La interfaz de software es dinmica y de fcil interactividad

3. ESTRATEGIA DE PRUEBAS

- En este punto nos enfocaremos en realizar tres diferentes tipos de pruebas las
cuales son:

+ Prueba Unitaria: Verificar la funcionalidad y estructura de cada componente.

+ Prueba de Implantacin: Verificar el funcionamiento del programa y su rendimiento
con hardware, software y aceptacin de usuario.
+ prueba del sistema: Verificar el sistema completamente incluyendo todos los
subsistemas con sus respectivas interfaces y el correcto acople a el resto de los
componentes.

Departamento/Proyecto/ Subttulo
13
4. PLANIFICACIN Y RECURSOS
4.1. PLANIFICACIN
Esta seccin debera incluir una lista de hitos clave en las pruebas. Puede incluir:
- Aprobacin del plan de pruebas
- Informacin de relevancia
- Estudio de los sistemas de informacin
- Definicin y organizacin de los planes de prueba
- Definicin de la arquitectura requerida para el software
RECURSOS
4.1.1. Hardware
Requisito mnimo de hardware:
- Espacio disponible en disco duro de 250GB
- Memoria RAM de 1GB
- Procesador de 1,60 Ghz en adelante

4.1.2. Software
- Sistema operativo de 32 o 64 bits.

4.1.2.1. Herramientas
- Quabook
- Selenium
- Funkload

4.1.3. Dotacin de personal

4.1.3.1. Responsabilidades
- miembros del equipo de aseguramiento de la calidad y sus responsabilidades:
- Edward Leandro Hurtado Mina - Anlisis y soporte
- Diana Marcela Tilano - Anlisis y soporte
4.1.3.2. Formacin
- Edward Leandro Hurtado - Desarrollador de software y Analista de Calidad
- Diana Marcela Tilano - Desarrolladora de software y Analista de Calidad

5. REVISIN DEL PLAN DE PRUEBAS

El Plan de Pruebas, contiene la definicin de las metas y objetivos a probar dentro del
alcance de cada iteracin del proyecto. Proporciona el marco de trabajo en el que el equipo
llevar a cabo la prueba dentro de el horario coordinado.
Departamento/Proyecto/ Subttulo
14
- El Resumen de Resultados de Pruebas, organiza y presenta un anlisis resumen de los
resultados de las pruebas y las medidas clave para revisar y definir estas, tpicamente por
los Stakeholders claves. Adems, puede contener una declaracin general de calidad
relativa, puede mantener las recomendaciones de las pruebas que se realizarn a futuro.

- La Lista de los Problemas, proporciona una manera de registrar para el Administrador del
Proyecto los: problemas, excepciones, anomalas, u otras tareas incompletas que requieren
atencin que relaciona a la direccin del proyecto.
- Cambios de Requerimientos. Se proponen cambios a los artefactos de desarrollo a travs
de Cambios de requerimientos (CR). Se usan los Cambios de Requerimientos para
documentar los problemas, las mejoras solicitadas y cualquier otro tipo de solicitud para un
cambio en el producto. El beneficio de CR es que proporcionan un registro de decisiones,
debido a su proceso de valoracin, asegura los impactos del cambio que puedan
darse en el proyecto.

Departamento/Proyecto/ Subttulo
15