REPÚBLICA BOLIVARIANA DE VENEZUELA
MINISTERIO DEL PODER POPULAR P. LA EDUC. UNIVERSITARIA
UNIVERSIDAD POLITÉCNICA TERRITORIAL “FRANCISCO TAMAYO”
TUCUPITA, ESTADO DELTA AMACURO
PNF: INGENIERIA EN INFORMÁTICA
Desarrollo del Plan de Pruebas
Profesor: Bachilleres:
ING Edilio Velásquez Cabrera Alejandro C.I: 17.526.409
González Néstor C.I: 18.659.223
Meta Daniel C.I: 18.659.109
Romero Yasser C.I: 20.160.458
Tucupita, Diciembre de 2014
1
Índice
INTRODUCCION----------------------------------------------------------------------------------------- 03
Gerenciando el Proceso de Pruebas--------------------------------------------------------------------------- 04
Plan de Prueba------------------------------------------------------------------------------------------------------- 04
Descripción de un Plan de Pruebas---------------------------------------------------------------------------- 05
Fases en las que se Realizarán las Pruebas son: -------------------------------------------------------- 05
Niveles de Pruebas------------------------------------------------------------------------------------------------- 06
Metodologías de Pruebas---------------------------------------------------------------------------------------- 07
Principios Fundamentales de las Pruebas-------------------------------------------------------------------- 09
Reporte de Problemas, Seguimiento y Análisis de Pruebas:------------------------------------------- 12
Que Tipos de Prueba de Programa Deben ser Considerados------------------------------------------- 12
Análisis de Pruebas:------------------------------------------------------------------------------------------------ 13
CONCLUSIONES---------------------------------------------------------------------------------------- 14
BIBLIOGRAFIA------------------------------------------------------------------------------------------- 15
2
Introducción
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. Puede haber un plan
global que explicite el énfasis a realizar sobre los distintos tipos de pruebas (verificación, integración
e integración).
De igual forma permite evaluar un producto particular para determinar si un software tiene
defectos y verificar que este satisface los requisitos o identifica diferencias entre los esperados y los
resultados actuales
Es muy importante hacer pruebas de software para tener un Sistema libre de errores para
eficiencia de la aplicación y Aseguramiento de la calidad del software ya sea también para la
evaluación de la flexibilidad del software.
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.
3
Gerenciando el Proceso de Pruebas
El propósito es establecer un entendimiento común entre el cliente y los requerimientos del
proyecto de software que direccionarán el proyecto.
Los requerimientos del software identificados son controlados para orientar la ingeniería del
software y su gerencia
Planes del proyecto, productos y actividades son consistentes con los requerimientos
identificados.
El alcance del proceso de pruebas Implica establecer y mantener un acuerdo con el cliente con
relación a los requerimientos del proyecto de software El acuerdo es la base para las estimaciones,
planificación, desempeño y seguimiento de las actividades del proyecto.
Propósito: Implica Comparar resultados versus acuerdos, y estimaciones
Ajustar los planes
Metas: Tener una visión clara del progreso del proyecto a fin de gerenciarlo y tomar las
acciones adecuadas ante las desviaciones
Debemos tomar en cuenta el aseguramiento de la calidad del software que indica que mientras
el software que se está desarrollado reúne los requerimientos y su desempeño es el esperado, es
preciso que se supervisen las actividades de desarrollo del software y su rendimiento, en distintas
oportunidades durante cada fase del ciclo de vida.
En el desarrollo de software, la fase de pruebas es crítica para asegurar que el producto sea
enviado a ambiente de producción con la calidad esperada por el cliente.
Es por esto que se debe contar con un Plan de Pruebas de Software para especificar
minuciosamente las funciones a probar, como serán ejecutadas esas pruebas, quienes serán los
responsables y el cronograma para su ejecución.
El Plan de Pruebas de Software puede aplicarse a todo el Proyecto de Desarrollo de Software, o
puede acotarse a una iteración o conjunto de casos. Además, puede definir jerarquías de casos de
prueba a considerar.
Plan de Prueba:
Este documento tiene como finalidad entregar los pasos a seguir para la aplicación correcta de
las estrategias y pruebas necesarias en el sistema presente. Con el fin de verificar las funciones y
procesos de los distintos módulos del software, así como también encontrar los posibles fallos o
errores que se presenten durante el periodo de pruebas. Además validar si el sistema cumple con
los requerimientos que contemplen el funcionamiento total del mismo.
4
Descripción de un Plan de Pruebas.
PP1.5 – Plan de Pruebas
Objetivo: Elaborar una primera versión del Plan de Pruebas.
Entradas Tareas Salidas
-Determinar la estrategia de las Documento de Plan de
pruebas. Pruebas (.doc)
Especificación de
Requisitos (.doc)
-Especificar herramientas a
utilizar.
Prototipo de la Interfaz
(.html)
-Detallar el entorno en que se va a
probar.
Observaciones: Aunque en esta fase se elabora el Plan de Pruebas, éste puede ser modificado
a lo largo de la realización de pruebas.
Describe todos los métodos que se utilizarán para verificar que el software satisface la especificación
del producto y las necesidades del cliente. Incluye los objetivos de calidad, necesidades de recursos,
cronograma, asignaciones, métodos, etc.
De igual manera identifica que va a ser probado, resume el enfoque general usado para las pruebas,
los objetivos y metodologías usadas.
Las Fases en las que se Realizarán las Pruebas Son:
1. Planificación de las pruebas: Identificar los requisitos para las pruebas. Desarrollar la
estrategia de pruebas. Identificar los recursos necesarios para realizar las pruebas. Generar el Plan
de pruebas.
2. Diseño de las pruebas: Desarrollo de las pruebas. Identificar y describir los casos de prueba.
3. Implementación de las pruebas: Establecer el entorno de prueba. Desarrollar las clases de
prueba, los componentes de prueba y los datos de prueba.
4. Ejecución de las pruebas: Ejecutar los casos de prueba. Evaluar la ejecución del proceso de
prueba. Verificar los resultados. Investigar los resultados no esperados. Registrar los defectos.
5
5. Evaluación de las pruebas: Evaluar la cobertura de los casos de prueba. Evaluar la cobertura
del código. Analizar los defectos. Determinar si se han alcanzado los criterios de las pruebas. Crear
los informes de evaluación de las pruebas.
Niveles de Pruebas de Software
En un proceso de pruebas formal, suelen confundirse con mucha facilidad, los niveles de
pruebas con los tipos de prueba, y a pesar de que se encuentren íntimamente relacionadas, tienen
connotaciones diferentes en el proceso.
Para entender un poco más, vamos a partir del hecho de que las pruebas pueden ejecutarse en
cualquier punto del proceso de desarrollo de software, y es aquí donde los niveles de prueba nos
permiten entender con claridad los diferentes puntos o etapas en donde pueden ejecutarse ciertos
tipos de prueba.
Por lo anterior, es común que algunas personas se refieran a los niveles de pruebas o intenten
clasificarlos como: pruebas de desarrollador, pruebas funcionales y pruebas de usuario final.
Sin embargo, la terminología apropiada para referirse a los diferentes niveles corresponde a la
siguientes cuatro (4) clasificaciones que son: pruebas unitarias, pruebas de integración, pruebas de
sistema y pruebas de aceptación. En cada uno de estos niveles de prueba, se podrán ejecutar
diferentes tipos de prueba tales como: pruebas funcionales, no funcionales, de arquitectura y
asociadas el cambio de los productos.
A continuación una breve descripción de cada nivel de prueba:
Pruebas Unitarias o de Componente: este tipo de pruebas son ejecutadas normalmente por el
equipo de desarrollo, básicamente consisten en la ejecución de actividades que le permitan verificar
al desarrollador que los componentes unitarios están codificados bajo condiciones de robustez, esto
es, soportando el ingreso de datos erróneos o inesperados y demostrando así la capacidad de tratar
errores de manera controlada. Adicionalmente, Las pruebas sobre componentes unitarios, suelen
denominarse pruebas de módulos o pruebas de clases, siendo la convención definida por el
lenguaje de programación la que influye en el término a utilizar. Por último, es importante que toda
la funcionalidad de cada componente unitario sea cubierta, por al menos, dos casos de prueba, los
cuales deben centrarse en probar al menos una funcionalidad positiva y una negativa.
Pruebas de Integración: este tipo de pruebas son ejecutas por el equipo de desarrollo y
consisten en la comprobación de que elementos del software que interactúan entre sí, funcionan de
manera correcta.
Pruebas de Sistema: este tipo de pruebas deben ser ejecutadas idealmente por un equipo de
pruebas ajeno al equipo de desarrollo, una buena práctica en este punto corresponde a la
tercerización de esta responsabilidad. La obligación de este equipo, consiste en la ejecución de
actividades de prueba en donde se debe verificar que la funcionalidad total de un sistema fue
6
implementada de acuerdo a los documentos de especificación definidos en el proyecto. Los casos
de prueba a diseñar en este nivel de pruebas, deben cubrir los aspectos funcionales y no
funcionales del sistema. Para el diseño de los casos de prueba en este nivel, el equipo debe utilizar
como bases de prueba entregables tales como: requerimientos iniciales, casos de uso, historias de
usuario, diseños, manuales técnicos y de usuario final, etc. Por último, es importante que los tipos de
pruebas ejecutados en este nivel se desplieguen en un ambiente de pruebas / ambiente de pre-
producción cuya infraestructura y arquitectura sea similar al ambiente de producción, evitando en
todos los casos utilizar el ambiente real del cliente, debido principalmente, a que pueda ocasionar
fallos en los servidores, lo que ocasionaría indisponibilidad en otros servicios alojados en este
ambiente.
Pruebas de Aceptación: Independientemente de que se haya tercerizado el proceso de pruebas
y así la firma responsable de estas actividades haya emitido un certificado de calidad sobre el
sistema objeto de prueba, es indispensable, que el cliente designe a personal que haga parte de los
procesos de negocio para la ejecución de pruebas de aceptación, es incluso recomendable, que los
usuarios finales que participen en este proceso, sean independientes al personal que apoyó el
proceso de desarrollo. Cuando las pruebas de aceptación son ejecutadas en instalaciones o
ambientes proporcionados por la firma desarrolladora se les denominan pruebas Alpha, cuando son
ejecutadas desde la infraestructura del cliente se les denomina pruebas Beta. En los casos en que
las pruebas de aceptación del producto se hayan ejecutado en el ambiente del proveedor, el
aplicativo no podrá salir a producción, sin que se hayan ejecutados las respectivas pruebas Beta en
el ambiente del cliente, de lo anterior es importante concluir, que las pruebas Alpha son opcionales,
pero las pruebas Beta son obligatorias.
Metodología de Pruebas:
Los procesos de aseguramiento de calidad de un producto de software suelen dividirse en lo que
respecta a su componente analítico en pruebas estáticas y dinámicas. La diferencia fundamental
entre estos tipos de pruebas, radica en que las pruebas estáticas se centran en evaluar la calidad
con la que se está generando la documentación del proyecto, por medio de revisiones periódicas,
mientras que las pruebas dinámicas, requieren de la ejecución del software con el fin de medir el
nivel de calidad con la que este fue codificado y el nivel de cumplimiento en relación con la
especificación del sistema.
Realizar pruebas dinámicas a un producto de software, suele en la mayoría de los casos
confundirse con una simple actividad de ejecución de pruebas y reporte de incidencias, sin embargo,
para productos de complejidad media en adelante, lo recomendable es implementar de manera
formal una metodología de pruebas que se ajuste y acople uniformemente con la metodología de
desarrollo seleccionada por la firma desarrolladora.
7
Para procesos de desarrollo basados en la metodología RUP o métodos tradicionales,
implementar una metodología de pruebas es totalmente viable, teniendo en cuenta que estas
metodologías están orientadas a la documentación y a la formalización de todas las actividades
ejecutadas. Si por el contrario, la firma desarrolladora guía su proceso bajo lineamientos basados
en metodologías ágiles, será necesario reevaluar la conveniencia de ejecutar todas las actividades
que implica un proceso de pruebas formal, lo que en la mayoría de los casos, conlleva a reducir al
mínimo las actividades relacionadas con un proceso de pruebas, circunstancia que naturalmente
puede desencadenar en la liberación de productos con bajos niveles de calidad.
Un proceso de pruebas formal, está compuesto, cuando menos por las siguientes 5 típicas etapas:
Planeación de pruebas.
Diseño de pruebas.
Implementación de pruebas.
Evaluación de criterios de salida.
Cierre del proceso.
Planeación de Pruebas:
Es la etapa en donde se ejecutan las primeras actividades correspondientes al proceso de
pruebas y tiene como resultado un entregable denominado plan de pruebas el cual debe estar
conformado en cuando menos por aspectos tales como:
Alcance de la prueba: determina que funcionalidades del producto y/o software serán
probadas durante el transcurso de la prueba. Este listado de funcionalidades a probar se extrae con
base a un análisis de riesgos realizado de manera previa, que tienen en cuenta variables tales como
el impacto que podría ocasionar la falla de una funcionalidad y la probabilidad de falla de una
funcionalidad. Producto de este análisis, se cuenta con información adicional que permite
determinar además del alcance detallado del proceso de pruebas, la prioridad con la que las
funcionalidades deben probarse y la profundidad de las pruebas.
Tipos de Prueba: en este punto se debe determinar qué tipos de pruebas requeriría el
producto. No todos los productos de software requieren la aplicación de todos los tipos de pruebas
que existen, por esta razón, es estrictamente necesario que el líder de pruebas se plantee preguntas
que le permitan determinar qué tipos de prueba son aplicables al proyecto en evaluación. Los
posibles tipos de prueba a aplicar son: pruebas de stress, pruebas de rendimiento, pruebas de
carga, pruebas funcionales, pruebas de usabilidad, pruebas de regresión, entre otros.
Estrategia de Pruebas: teniendo en cuenta que no es viable probar con base a todas las
posibles combinaciones de datos, es necesario determinar a través de un análisis de riesgos sobre
que funcionalidades debemos centrar nuestra atención. Adicionalmente, una buena estrategia de
pruebas debe indicar los niveles de pruebas (ciclos) que aplicaremos y la intensidad o profundidad a
8
aplicar para cada nivel de pruebas definido. En este punto también es importante definir los criterios
de entrada y salida para cada ciclo de pruebas a ejecutar.
Criterios de Salida: entre las partes involucradas en el proceso, se define de manera formal,
bajo qué condiciones se puede considerar que una actividad de pruebas fue finalizada. Los criterios
de salida se deben definir para cada nivel de pruebas a ejecutar. Algunos ejemplos de criterios de
salida que pueden ser utilizados son: porcentaje de funcionalidades de alto riesgo probadas con
éxito, número defectos críticos y/o mayores aceptados, etc.
Otros aspectos: tal y como se realiza en cualquier plan de proyecto, se debe incluir una
estimación de tiempos, los roles y/o recursos que harán parte del proceso, la preparación del
entorno de pruebas, cronograma base, etc.
Diseño de Pruebas:
Una vez elaborado y aprobado el plan de pruebas, el equipo de trabajo debe iniciar el
análisis de toda la documentación existente con respecto al sistema, con el objeto de iniciar el
diseño de los casos de prueba. Los entregables claves para iniciar este diseño pueden ser: casos
de uso, historias de usuario, arquitectura del sistema, diseños, manuales de usuario (si existen),
manuales técnicos (si existen). El diseño de los casos, debe considerar la elaboración de casos
positivos y negativos. Los casos de prueba negativos permiten validar cómo se comporta el sistema
ante situaciones atípicas y permite verificar la robustez del sistema, atributo que constituye uno de
los requerimientos no funcionales indispensable para cualquier software. Por último, es necesario
definir cuáles son los datos de prueba necesarios para la ejecución de los casos de prueba
diseñados.
Implementación y Ejecución de Pruebas:
La ejecución de pruebas debe iniciar con la creación de los datos de prueba necesarios para
ejecutar los casos de prueba diseñados. La ejecución de estos casos, puede realizarse de manera
manual o automatizada; en cualquiera de los casos, cuando se detecte un fallo en el sistema, este
debe ser documentado y registrado en una herramienta que permita gestionar los defectos (Bug
Tracker). Una vez el defecto ha sido corregido por la firma desarrolladora en su respectivo proceso
de depuración, es necesario realizar un re-test que permita confirmar que el defecto fue solucionado
de manera exitosa. Por último, es indispensable ejecutar un ciclo de regresión que nos permita
garantizar, que los defectos corregidos en el proceso de depuración de la firma, no hayan
desencadenado otros tipos de defectos en el sistema.
Principios Fundamentales de las Pruebas
Evaluación de Criterios de Salida: los criterios de salida son necesarios para determinar si es posible
dar por finalizado un ciclo de pruebas. Para esto, es conveniente definir una serie de métricas que
permitirán al finalizar un proceso de pruebas, comparar los resultados obtenidos contra las métricas
9
definidas, sí los resultados obtenidos no superan la métricas definidas, no es posible continuar con el
siguiente ciclo de pruebas.
Existen varios tipos de criterios de salida dentro de los cuales se pueden mencionar: cubrimiento de
funcionalidades en general, cubrimiento de funcionalidades críticas para el sistema, Número de
defectos críticos y mayores detectados, etc. También es importante aclarar que el proceso de
pruebas puede ser suspendido y/o paralizado, debido entre otros, a aspectos relacionados con el
presupuesto y la calidad mínima del sistema requerida para el inicio formal de pruebas.
Cierre del proceso: durante este periodo de cierre el cual históricamente se ha comprobado que se
le destina muy poco tiempo en la planeación, se deben cerrar las incidencias reportadas, se debe
verificar si los entregables planeados han sido entregados y aprobados, se deben finalizar y aprobar
los documentos de soporte de prueba, analizar las lecciones aprendidas para aplicar en futuros
proyectos, etc
Las pruebas exhaustivas no son viables: para proyectos cuyo número de casos de uso o historias
de usuario desarrolladas sea considerable, se requeriría de una inversión muy alta en cuanto a
tiempo y recursos necesarios para cubrir pruebas sobre todas las funcionalidades del sistema; por
esta razón, es conveniente realizar un análisis de riesgos de todas las funcionalidades del aplicativo
y determinar en este punto cuales serán objeto de prueba y cuáles no. Naturalmente, ninguna
funcionalidad que haga parte del ciclo de negocio del aplicativo debe quedar por fuera de esta
revisión. Por otra parte, es necesario evitar para el caso de funcionalidades complejas, escribir (n)
casos de prueba, que cubran todas las posibles combinaciones de entrada y salida que puede llegar
a tener las funcionalidades.
Diseñar casos de prueba bajo estas condiciones, solo es justificable cuando la funcionalidad objeto
de prueba tiene una complejidad trivial. Por las razones ya mencionadas, es altamente sugerirle
diseñar y ejecutar pruebas de muestra, las cuales sean elegidas bajo criterios de experiencia y/o
aleatoriedad.
El proceso no puede demostrar la ausencia de defectos: independientemente de la rigurosidad con
la que se haya planeado el proceso de pruebas de un producto, nunca será posible garantizar al
ejecutar este proceso, la ausencia total de defectos de un producto en su paso a producción, debido
entre otras cosas, al principio no. 1, en el cual no se permite escribir y ejecutar casos de prueba de
manera exhaustiva. Por lo anterior, un proceso de pruebas planeado, puede garantizar una
reducción significativa de los posibles fallos y/o defectos del software, pero nunca podrá garantizar
que el software no fallará en su ambiente de producción.
Las actividades de un proceso de pruebas, deben ser incorporadas incluso desde el mismo
momento en el que se ejecutan las etapas de análisis y diseño, por esta razón, documentos de
especificación y de diseño, deben ser sometidos a revisiones, lo que ayudará a detectar problemas
en la lógica del negocio mucho antes de que se escriba una sola línea de código. En conclusión,
cuanto más temprano se detecte un defecto bien sea sobre los entregables de especificación y
10
diseño o sobre el producto, menos costoso será para el equipo del proyecto dar solución a dichos
incidentes.
Las pruebas no garantizan la calidad del Software: si bien las pruebas del Software ayudan a
mejorar la calidad de un producto, esto no es totalmente garantizarle, si estas actividades no son
incorporadas desde etapas tempranas del proyecto. Este nivel de calidad no será garantizado, entre
otros aspectos, porque existe la posibilidad de que algunas funcionalidades del software pueden
no suplir las necesidades y expectativas de los usuarios finales a los cuales va dirigido el
desarrollo, así el comportamiento del software sea correcto y responda fielmente a lo que fue
especificado. Una buena práctica que ayuda a mitigar el riesgo de que el usuario final no esté
satisfecho con el producto, es involucrarlo desde instancias tempranas en el proceso y tener en
cuenta sus apreciaciones para generar una retroalimentación a tiempo.
Ejecución de pruebas bajo diferentes condiciones: en un plan de pruebas, siempre existe un
apartado relacionado con la estrategia a utilizar por parte del equipo de pruebas, en este item, se
define entre otros aspectos, el número de ciclos de prueba que se ejecutarán sobre las
funcionalidades del negocio. La idea consiste, en que por cada ciclo de prueba ejecutado, se
generen diferentes tipos de condiciones, basados principalmente en la variabilidad de los datos de
entrada y set de datos utilizados. No es conveniente, ejecutar en cada ciclo, los casos de prueba
basados en los mismos datos del ciclo anterior, dado que con seguridad, se obtendrán los mismos
resultados. En conclusión, ejecutar ciclos bajo diferentes tipos de condiciones, permitirá identificar
posibles fallos en el sistema, que antes no eran fácilmente reproducibles.
Describe que cosas están dentro del esfuerzo de testing y que cosas no. Una forma de presentarlo
es mediante una tabla donde se indiquen que funcionalidades están y cuales no dentro del esfuerzo
de testing. El alcance es definido en base al análisis de riesgo realizado previamente.
11
Reporte de Problemas, Seguimiento y Análisis de Pruebas:
Describen los problemas encontrados al ejecutar los casos de prueba. El seguimiento de las
pruebas del software está diseñado para ayudar a asegurar la calidad de software y asistir a los
programadores y otras personas involucradas en el desarrollo y uso de sistemas informáticos en el
seguimiento de los defectos de software. Uno de los componentes principales de un sistema de
seguimiento de errores es la base de datos donde se almacenan los hechos e historia de un fallo de
software.
La mayor parte de los sistemas de seguimiento de errores identifican un ciclo de vida al cual se
le da seguimiento mediante el estado del problema desde su descubrimiento y reporte hasta su
solución final. De la misma manera, son regularmente configurables para permitir que diferentes
personas consulten o editen diferentes aspectos del reporte, así como permitir a los administradores
clasificar los diferentes estados del problema.
Control de la calidad del software: Técnicas y actividades de carácter operativo, utilizadas para
verificar los requisitos relativos a la calidad, centrados en mantener bajo control el proceso de
desarrollo y eliminar las causas de los defectos en las diferentes fases del ciclo de vida.
El control de calidad del software incluye desde el monitoreo de desarrollo de procesos haciendo
respetar los estándares y procedimientos concordados asegurándose un buen seguimiento de
programa y la detección y corrección de errores. El control de calidad del software está orientado a
la prevención.
Que Tipos de Prueba de Programa Deben ser Considerados
• Caja negra: No está basada en el conocimiento del código o diseño interno,
Determina la funcionalidad del sistema.
•Caja blanca: Está basada en la lógica interna de la aplicación y el código. Hace una cobertura de
declaraciones del código, ramas, caminos y condiciones.
•Unidad de testeo o prueba: Es la escala más pequeña de la prueba, está basada en la funcionalidad
de los módulos del programa, como funciones, procedimientos, módulos de clase, etc. En ciertos
sistemas también se verifican o se prueban los drivers y el diseño de la arquitectura.
•Integración incremental: Cuando nuevas funciones son ingresadas al sistema se hace la prueba
basándose en la funcionalidad, la dependencia con otros módulos y la integración con el programa
completo.
•Prueba de integración: Se basa en las pruebas de conexiones y comunicaciones entre diferentes
módulos. Es esencial en sistemas de cliente servidor o red.
12
•Prueba funcional: La caja negra hace la prueba funcional de los requerimientos de la aplicación y
generalmente es realizada por el programador, en cambio, la prueba funcional es realizada por los
testers.
•Prueba de sistema: Es una prueba de caja negra incluyendo todos los componentes del sistema
desde el hardware a la documentación.
•Prueba de fin a fin: Es similar a la prueba de sistema pero esta involucra la interacción con otro
hardware, bases de datos y redes entre otras.
Análisis de Pruebas:
Con los resultados de las pruebas y el informe de pruebas que se hallan obtenido, se analizan
los resultados para comprobar si se han cumplido los criterios que se especificaron para asegurar
que la prueba ha sido exitosa. Los resultados de las pruebas de cada producto de trabajo tienen que
figurar en los informes y éstos se tienen que analizar incrementalmente para poder darlos como
correctos.
Cuando el resultado de las pruebas no es el esperado y no está claro que el defecto resida en el
producto, es útil estudiar el “cómo se hizo”, para descartar que los errores se deban a problemas de
métodos, de criterios o del entorno de pruebas. De nuevo, las herramientas nos ayudarán a buscar
el "porqué" de los resultados.
13
Conclusiones
El reporte de problemas del cliente es la medida de los problemas que el cliente ha
encontrado mediante el uso total del producto. Esta medida toma en consideración que múltiples
instancias del producto puedan ser usadas al mismo tiempo, lo cual efectivamente multiplica la
longitud de tiempo que el producto ha estado operando por el número de licencias de producto. Es
utilizada por la mayoría de los desarrolladores en la industria del software.
El patrón de aparición de defectos durante esta fase brinda más información. Incluso con el
mismo valor total de defectos durante la fase de prueba, la existencia de patrones de aparición de
defectos diferentes indica un nivel de calidad diferente.
El objetivo que se persigue es lograr estabilizar la aparición de defectos a un nivel bien bajo
o hacer mayores los tiempos de aparición de fallos, antes de terminar la fase de prueba y que el
software sea entregado. En numerosos casos, tales patrones de disminución de la aparición de
defectos durante la fase de prueba son la base de muchos modelos de fiabilidad de software. Las
unidades de tiempo para la observación del patrón de aparición son usualmente semanas y
ocasionalmente, meses.
Cuando se habla de patrón de aparición de defectos durante la fase de prueba, existen tres
medidas ligeramente diferentes que deben ser analizadas simultáneamente:
Aparición de defectos (defectos reportados) durante la fase de prueba por intervalos de
tiempo. Estas apariciones no son todos defectos válidos.
El patrón de aparición de defectos válidos, cuando la determinación del problema se ha
hecho sobre la base de los defectos reportados. Este es el verdadero patrón de defectos.
El Plan de Pruebas es el documento más importante de la fase de planificación pues es en
esta fase donde se genera una primera versión de este plan. El mismo identificará el propósito,
alcance, los elementos de prueba y los recursos necesarios para la ejecución de las pruebas, se va
a definir y recomendar la estrategia de prueba.
14
Bibliografía
http://pruebas-de-calidad-y-software.blogspot.com/2012/11/analisis-de-problemas-y-reporte.html
http://www.buenastareas.com/ensayos/Desarrollo-De-Plan-De-Pruebas-De/386870.html
http://pruebasdelsoftware.wordpress.com/
http://es.scribd.com/doc/23966146/Plan-de-Pruebas#force_seo
15
