Expo Calidad Final

AO DEL BUEN SERVICIO AL
CIUDADANO
CONTROL DE CALIDAD DE SOFTWARE

DOCENTE: ING. MORALES LOAIZA, ALONSO
EJECUCIN DE PRUEBAS
MISAYCO BAUTISTA EDISON

NEYRA CHALCO JOS
PACHAS TASAYCO PERCY
TORRES PACHAS JAVIER

VALDIVIEZO FLORES JESS
VIII CICLO 2017
ICA - PERU
UNIVERSIDAD NACIONAL SAN LUIS GONZAGA DE ICA
DEDICATORIA
El presente trabajo va
dedicado a nuestros padres ya
que gracias
a ellos nosotros podemos
seguir alcanzando nuestras
metas.
INGENIERIA DE SISTEMAS Pgina 1

INTRODUCCIN PAG. 04
1. EJECUCION DE PRUEBAS PAG. 05
1.1 DEFINICION PAG. 05
1.2 FASES PAG. 06
1.3 HERRAMIENTAS PARA IMPLEMENTAR Y
EJECUTAR PRUEBAS PAG. 07
1.3.1 E-TESTER PAG. 08
1.3.2 RATIONAL FUNCTIONAL TESTER PAG. 08
1.3.3 QUICK TEST PRO PAG. 10
1.3.4 RATIONAL ROBOT PAG. 10
1.3.5 TESTPARTNER PAG. 11
1.3.6 WINRUNNER PAG. 11
2. CASOS DE PRUEBAS PAG. 12
2.1 CASOS DE PRUEBAS PAG. 13
2.2 DISEO DE CASOS DE PRUEBAS PAG. 14
2.2.1 CARACTERISTICAS QUE DEBE TENER
UNA BUENA PRUEBA PAG. 15
2.2.2 ESTRUCTURA DE LOS CASOS DE PRUEBA PAG. 15
2.2.3 ACTIVIDADES DE LOS CASOS DE PRUEBA PAG. 16
2.2.4 RESULTADOS PAG. 16
2.3 MODELOS BASICOS PAG. 16
2.3.1 OTROS MODELOS PAG. 16
3. CLASES DE EQUIVALENCIA PAG. 18
3.1 DEFINICION PAG. 18
3.2 PASOS PAG. 19
3.2.1 PAUTAS PAG. 19
3.2.2 DEFINIR LOS CASOS DE PRUEBA PAG. 20
3.3 DIECTRICES PAG. 21
4. INFORME DE PRUEBAS PAG 23
4.1 MODELO 1 PAG. 24
4.2 MODELO 2 PAG. 26
5. SEGUIMIENTO DE PRUEBAS PAG. 29
5.1 PROCESOS DE SEGUIMIENTOS DE PRUEBAS PAG. 29
5.1.1 ANALISIS Y PLANEACIN PAG. 29
5.1.2 DISEO DE PUEBAS PAG. 30
5.2 CASOS DE PRUEBAS PAG. 30
5.2.1 MATRICES DE PRUEBAS PAG. 31
5.2.2 GENERAR EL PROCEDIMIENTO DE PRUEBAS PAG. 31
5.3 EJECUCIN DE PRUEBAS PAG. 31
5.3.1 EJECUCIN DEL TESTWARE PAG. 31
5.3.2 EVALUACIN DE PRUEBAS PAG. 31
5.4 ESTABILIZACIN PAG. 32
5.4.1 PRUEBAS PERFORMANCE PAG. 32
5.4.2 PRUEBAS DE REGRESIN PAG. 32
5.4.3 INFORMAR DE LA LIBERACIN PAG. 32

5.5 ACEPTACIN PAG. 32

5.5.1 PLAN DE PRUEBAS ACEPTACIN PAG. 32
5.5.2 EJECUCION DE PRUEBAS DE ACEPTACIN PAG. 33
5.5.3 CREAR EL REPORTE DE PRUEBAS DE
ACEPTACIN PAG. 33
5.5.4 TIPS PARA LA ETAPA DE ACEPTACIN PAG. 34
5.6 CIERRE DEL PROYECTO PAG. 34
5.6.1 IDENTIFICAR MEJORES PRCTICAS Y AREAS
DE OPORTUNIDAD PAG. 34
5.6.2 JUNTA DE CIERRE DE PROYECTO PAG. 34
5.6.3 REPORTE DE CIERRE DE PROYECTO PAG. 34
CONCLUSIONES PAG. 35
SUGERENCIAS PAG. 36
BIBLIOGRAFIA PAG. 37
INDICE DE IMGENES
1. Figura 1.1 Proceso de ejecucin de pruebas PAG.05
2. Figura 1.2 Curva de Registro de Hallazgos PAG.06
o No Conformidades
3. Figura 1.3 Prueba de Caja Blanca PAG.14
4. Figura 1.4 Prueba de Caja Negra PAG.15
5. Figura 1.5 Cuadro Comparativo de Modelos PAG.17
6. Figura 1.6 Testing Funcional Caja PAG.18
7. Ejemplo de Claves de Equivalencia PAG.18
INDICE DE TABLAS
1. Tabla 1.1 Rango de Valores PAG.19
2. Tabla 1.2 Nmero de Valores PAG.19
3. Tabla 1.3 Conjunto de Valores PAG.19
4. Tabla 1.4 Debe ser PAG.20
5. Tabla 1.5 Lista de Factores PAG.23
6. Tabla 1.6 Evaluacin de Mtricas de Calidad PAG.24
7. Tabla 1.7 Informe del Cumplimiento de ITEM PAG.25
8. Tabla 1.8 Informe de Ejecucin de pruebas PAG.26
9. Tabla 1.9 Conceptos del Informe PAG.28

Las pruebas de software (en ingls software testing) son las investigaciones
empricas y tcnicas cuyo objetivo es proporcionar informacin objetiva e
independiente sobre la calidad del producto a la parte interesada o stakeholder.
Es una actividad ms en el proceso de control de calidad.
Las pruebas son bsicamente un conjunto de actividades dentro del desarrollo

de software. Dependiendo del tipo de pruebas, estas actividades podrn ser
implementadas en cualquier momento de dicho proceso de desarrollo. Existen
distintos modelos de desarrollo de software, as como modelos de pruebas. A
cada uno corresponde un nivel distinto de involucramiento en las actividades
de desarrollo.
Lo que veremos a continuacin en el desarrollo del proyecto son los diversos

Casos de Pruebas que existen en la actualidad, sus clases de equivalencia para
poder lograr la elaboracin de un informe en el cual este detallado si el software
cumple con los requerimientos necesarios, una vez logrado esto se le da un
seguimiento a las pruebas con el fin de terminar de manera ptima el proceso
del desarrollo del Software.

1. EJECUCIN DE PRUEBAS
1.1. DEFINICIN
s la actividad donde los procedimientos de pruebas o scripts son especificados
E combinando los casos de prueba en un orden particular e incluyendo cualquier

otra informacin necesaria para la ejecucin de pruebas, el ambiente se
preparar y se ejecutan las pruebas.
Se ejecutan las pruebas mediante la definicin de las actividades requeridas para
ejecutar los requerimientos de pruebas identificados en la fase de diseo de pruebas,
reportar los hallazgos y asegurar su correccin por parte del equipo de desarrollo de
software.
Figura 1.1 Proceso de ejecucin de pruebas

La fase de ejecucin de pruebas se realiza por iteraciones de pruebas. (Total o un

subconjunto de los requerimientos de pruebas).
En cada iteracin de pruebas se registran los hallazgos o No Conformidades de
software tal como se muestra en la figura 1.2.
El objetivo de esta etapa es contrastar el comportamiento esperado del software con
su comportamiento real, analizar las diferencias y reportar los resultados.
Durante la etapa de ejecucin, los responsables de pruebas deben ejecutar la mayor
cantidad posible de iteraciones y regresiones de prueba hasta poder demostrar
grficamente que existe una tendencia sostenida a la baja en la cantidad de no
conformidades encontradas.
Figura 1.2 Curva de Registro de Hallazgos o No Conformidades
El resultado real de ejecucin debe cumplir con dos caractersticas fundamentales que
permiten evidenciar su cumplimiento:
La correctitud: exactitud de los resultados reales versus los esperados.

La completitud: cobertura de los resultados reales versus los esperados.
1.2. FASES
a) El proceso de ejecucin de pruebas segn el estndar IEEE Std. 829, abarca las
siguientes fases:
Ejecutar las pruebas, cuyos casos y procedimientos han sido ya diseados
previamente.
Comprobar si se ha concluido el proceso de prueba (segn ciertos criterios de
complecin de prueba que suelen especificarse en el plan de pruebas).
En el caso que hayan terminado las pruebas, se evalan los resultados; en
caso contrario hay que generar las pruebas adicionales para que se satisfagan
los criterios de complecin de pruebas.
b) El proceso de ejecucin propiamente dicho, consta de las siguientes fases:

Se ejecutan las pruebas.
Se comprueba si ha habido algn fallo al ejecutar.

Si lo ha habido, se puede deber a un defecto del software, lo que nos lleva al

proceso de depuracin o correccin del cdigo. Se puede deber tambin a un
defecto en el propio diseo de las pruebas. En ambos casos, las nuevas
pruebas o las corregidas se debern ejecutar.
De no existir fallos, se pasar a la comprobacin de la terminacin de las

pruebas.
c) Las fases del proceso de comprobacin de la terminacin de las pruebas son:
Tras la ejecucin, se comprueba si se cumplen los criterios de complecin de

pruebas descritos en el correspondiente plan de pruebas.
En caso de terminar las pruebas, se pasa a la evaluacin de los productos

probados sobre la base de los resultados obtenidos (terminacin normal).
En caso de no terminar las pruebas se debe comprobar la presencia de

condiciones anormales en la prueba.
Si hubiesen existido condiciones anormales, se pasa de nuevo a la evaluacin;

en caso contrario, se pasa a generar y ejecutar pruebas adicionales para
satisfacer cualquiera de las dos terminaciones.
Los criterios de complecin de pruebas hacen referencia a las reas (caractersticas,

funciones, etc.) que deben cubrir las pruebas y el grado de cobertura para cada una
de esas reas. Como ejemplos genricos de este tipo de criterios se pueden indicar
los siguientes:
Se debe cubrir cada caracterstica o requerimiento del software mediante un

caso de prueba o una excepcin aprobada en el plan de pruebas.
En programas codificados con lenguajes procedurales, se deben cubrir todas
las instrucciones ejecutables mediante casos de prueba.
1.3. HERRAMIENTAS PARA IMPLEMENTAR Y EJECUTAR PRUEBAS

Sabemos que las pruebas de software es el acto de la ejecucin de software para
satisfacer una, algunas o todas de las siguientes metas:
Para asegurar que el software cumple con los requisitos especificados.
Identificar los defectos en el software (estos defectos se refieren a menudo
como "bugs").
Para entender el nivel de calidad del software.
En la actualidad, para cumplir estos objetivos, muchas organizaciones utilizan las

pruebas de software manual, es decir, la gente se sienta delante de un ordenador y
usa los scripts para realizar sus pruebas. A menudo, muchos de estos scripts de
prueba deben ser ejecutados en varias ocasiones, como emisiones sucesivas del
software. Esto no slo puede resultar montono y aburrido para los individuos que han
de ejecutar las pruebas, pero desde una perspectiva organizacional puede ser muy
intensivo en el uso de recursos. Con el fin de ayudar a aliviar este problema, algunas
compaas desarrollaron herramientas automatizadas de prueba. En trminos simples,
una vez la gente utiliza estas herramientas para crear scripts automatizados de prueba.
Estas herramientas pueden ejecutar los scripts cada vez que lo indique, con poca

supervisin necesaria de los seres humanos. Esto permite a los probadores que
normalmente ejecutan el script manualmente, automatizar las pruebas para
concentrarse en otros aspectos ms interesantes en el desarrollo del software. Ahora
estamos a lo largo de varias generaciones en trminos de herramientas de pruebas
automatizadas. En su mayor parte, en las primeras generaciones eran difciles de usar,
y las secuencias de comandos automatizadas que se utilizan para crear no eran fciles
de mantener. Sin embargo, las ltimas herramientas que se han desarrollado son ms
fciles de utilizar, de manera que pueda ser utilizado por un mayor nmero de personas
que tienen diferentes niveles y tipos de habilidades. En este captulo tratare de explicar
cules son las herramientas que se emplean para implementar y ejecutar pruebas
funcionales y de regresin, as como ver cules son sus caractersticas. Entre las
herramientas ms usadas para realizar pruebas funcionales y de regresin tenemos
las siguientes:
1.3.1. E-TESTER
Empirix e-Tester es una herramienta de prueba automatizada que forma parte

de la suite de e-test de aplicaciones. E-Tester proporciona a los usuarios la
capacidad de crear scripts automatizados de prueba de funcionamiento.
Est diseado para ser utilizado para probar web, soluciones inalmbricas y
aplicaciones multimedia.
CMO FUNCIONA?
Un usuario inicia la generacin de una secuencia de comandos mediante e-

Tester para grabar su interaccin con la aplicacin que se estudia. E-Tester
registra todos los objetos en cada pgina web que se ve, y valida estos objetos
cuando el script se ejecuta. El script se puede personalizar para utilizar los
valores de los archivos de datos como entradas de prueba.
Empirix afirma que las secuencias de comandos utilizables prueba puede ser
creado sin ningn tipo de codificacin que sea.
Facilidad de uso es una de las principales caractersticas de este producto. Sin

embargo, para extender la funcionalidad de scripts registrados, los usuarios
pueden utilizar Visual Basic para Aplicaciones (VBA).
E-Tester utiliza el entorno de desarrollo de VBA para proporcionar a los

usuarios avanzados con script de prueba las funciones de depuracin y la
capacidad de crear funciones reutilizables. C + +, J + +, VBScript y JavaScript
tambin puede utilizarse para mejorar e-Tester scripts. Scripts de prueba
creada con e-Tester tambin se puede utilizar para la realizacin de pruebas
de rendimiento en Empirix e-carga. Adems, E-Tester se integra con e-
Manager, la herramienta de gestin de pruebas de Empirix.
1.3.2. RATIONAL FUNCTIONAL TESTER
Rational Functional Tester antes conocida como XDE Tester, es una

herramienta de prueba que permite a los usuarios grabar, editar y ejecutar
scripts de prueba funcional automatizada. Un usuario puede crear y modificar
los scripts de prueba utilizando Java o Visual Basic .Net, por lo que algunos
conocimientos de programacin y la experiencia es esencial.

Fue diseado para probar aplicaciones Java, .Net y aplicaciones Web, mas no
en aplicaciones Cliente/Servidor.
CARACTERSTICAS
Soporte para pruebas de aplicaciones java, web y visual studio .net basadas
en winform: A menudo se le requiere a los equipos de pruebas el evaluar
aplicaciones construidas sobre ms de una base tecnolgica. Provee el mismo
soporte robusto de automatizacin para aplicaciones construidas usando
tecnologa Java, HTML/DHTML y Visual Studio .NET en WinForm.
Eleccin del lenguaje - java o visual basic .net - para la customizacin de los
test script: La customizacin de los test scripts es mandatorio en orden a
realizar algn test que no sea el ms bsico. Rational Functional Tester da la
opcin de seleccionar entre lenguajes poderosos de scripting para hacerlo
posible, siendo las posibilidades tanto Java como Visual Basic .NET - ambas
opciones pueden ser usadas con todas las tecnologas de interfaz de usuario
soportadas. Al trabajar con el Functional Tester, los testeadores aprenden
rpidamente a trabajar con construcciones bsicas del lenguaje adquiriendo
experiencia de programacin que facilitar una comunicacin ms productiva
con los desarrolladores.
Editor y debugger nativos para testeadores avanzados java y visual basic .net:
Esta herramienta proporciona opciones ms fuertes de la industria para estos
fines, los testeadores que usan Java pueden trabajar con el Eclipse Java
Development Toolkit (JDT), y los que usan Visual Basic .NET pueden hacerlo
en Visual Studio .NET. Ambos ambientes integrados de desarrollo ofrecen una
gran cantidad de opciones para simplificar la optimizacin de los test,
incluyendo una caracterstica til de completamiento del cdigo que sugiere la
sentencia para acelerar la edicin. Los desarrolladores GUI encontrarn esta
caracterstica particularmente til, ya que podrn accederla desde la misma
interfaz a la que acceden para construir la interfaz de usuario.
Tecnologa scriptassure para adecuar los cambios frecuentes a las interfaces
de usuario: Los cambios frecuentes a la interfaz de usuario de las aplicaciones
pueden desbaratar las pruebas que involucran asunciones respecto a la forma
en que se identificarn los objetos de la interfaz durante el playback.
Permite a los probadores automatizar las pruebas de forma flexible cuando se
realizan cambios frecuentes en la interfaz de usuario de las aplicaciones con la
tecnologa ScriptAssure.
Correlacin automatizada de datos y testing orientado al dato eliminando la
necesidad de codificacin manual: Las pruebas funcionales generalmente
necesitan de variar los datos para simular adecuadamente los usuarios reales.
Rational Functional Tester puede detectar automticamente los datos
ingresados durante la grabacin del test y preparar el test para orientarlo a los
datos.
Usando una hoja de clculo como editor de datos, de esta manera se pueden
crear juegos de datos customizados para ser insertados dentro del script
durante el playback. De esta manera, se pueden producir pruebas altamente
personalizados sin codificacin manual.
Soporte para ejecucin y edicin de test bajo linux: Para los testeadores
interesados en Java, Rational Functional Tester ofrece capacidad de scripting
para crear, editar y ejecutar pruebas sobre plataforma Linux - incluyendo todo
excepto el grabador de test. Tambin soporta la plataforma Windows para
todas las capacidades de grabacin, edicin y ejecucin.

1.3.3. QUICK TEST PRO
Herramienta para realizar pruebas automatizadas, es tan fcil de usar como

el WinRunner.
Muchas de las cosas que requiere de la escritura de cdigo en WinRunner,

como agregar bucles IF a los scripts de pruebas automatizadas se pueden
realizar a travs del Quick Test Pro que es una funcionalidad integrada y no
existe la necesidad de escribir el cdigo.
Funcionalidad que permite a individuos con poca o sin conocimiento de
programacin podr hacer uso de esta herramienta.
1.3.4. RATIONAL ROBOT
El objetivo de IBM Rational Robot es facilitar la creacin y ejecucin de scripts

automatizados para probar la funcionalidad de una aplicacin mediante la
simulacin de un usuario que interacta con la interfaz grfica de la aplicacin.
Rational Robot tambin permite a los usuarios crear datapools, que vienen a
ser un conjunto de datos de prueba que pueden ser utilizados por los scripts
automatizados para variar los valores de entrada durante la ejecucin del
script.
CARACTERSTICAS
Brinda soporte a mltiples tecnologas de interfaz de usuario (ui) para
cualquier entorno, desde Java y la web hasta todos los controles de
VS.NET, incluidos VB.NET, J#, C# y C++ gestionado.
Incluye herramientas para administracin de Pruebas y est integrado
a las soluciones propuestas en el Rational Unified Process para el
seguimiento de defectos, administracin de cambios y trazabilidad de
requerimientos.
Simplifica la configuracin de pruebas - Rational Robot puede usarse
para distribuir las pruebas funcionales entre varias mquinas, cada una
de ellas configurada en forma diferente. Se pueden correr
simultneamente los mismas Pruebas funcionales, reduciendo el
tiempo necesario para identificar los problemas con configuraciones
especficas.
Asegura la Profundidad de las pruebas - Prueba ms all de la interfaz
de usuario de la aplicacin los cientos de propiedades de los objetos
componentes de la misma - tales como Controles ActiveX, OCXs,
applets Java y muchos otros - con solo un click.
Prueba los controles y objetos usuales - Rational Robot permite hacer
pruebas a cada componente de la aplicacin bajo variadas condiciones
proveyendo casos de prueba para mens, listas, caracteres
alfanumricos, bitmaps y muchos otros objetos.
Facilita el rehso - Rational Robot permite que las mismas pruebas de
scripts, sin ninguna modificacin, se pueden rehusar para probar una
aplicacin que corre sobre Microsoft Windows XP, Windows, ME,
Windows 2000, Windows 98 o Windows NT.
Ayuda a analizar rpidamente los problemas - Rational Robot registra
automticamente los resultados del test en el Rational Repository
integrado y colorea el cdigo par un rpido anlisis visual. Haciendo
doble clic sobre una entrada, se posiciona directamente sobre la lnea

correspondiente de la prueba de script, asegurando en consecuencia

un rpido anlisis y correccin de los errores del test script.
1.3.5. TESTPARTNER
TestPartner de Compuware es una herramienta que permite a los usuarios

para crear scripts automatizados de prueba que valide funcionalidad de la
aplicacin que se est probando.
CARACTERSTICAS
Puede ser utilizado para probar web y las aplicaciones cliente / servidor.
TestPartner tambin tiene una funcionalidad integrada que permite a los
usuarios probar los sistemas SAP.
TestPartner scripts se crean utilizando Microsoft Visual Basic para
Aplicaciones (VBA), que es un lenguaje no propietario que tiene una
base de usuarios bastante grande fuera del campo de pruebas de
software automatizadas.
TestPartner tambin proporciona algunas de las caractersticas del
entorno de Microsoft VBA, incluida la asistencia con la depuracin y la
informacin sobre las variables de tiempo de ejecucin. Wizards estn
disponibles para ayudar a crear los controles que los artculos validar
tales como propiedades de objetos y datos del sistema.
TestPartner tambin tiene la capacidad para probar el lado del cliente y
los objetos del lado del servidor COM, que permite las pruebas para
comenzar antes de interfaz de la aplicacin se est probando se ha
creado.
1.3.6. WINRUNNER
WinRunner es una herramienta empresarial para pruebas funcionales que

asegura que los procesos de negocio funcionen perfectamente la primera vez
y mantiene la fiabilidad.
Consiste en capturar, reproducir y verificar las interacciones entre usuarios de

forma automtica, con el fin de identificar los defectos y determinar si los
procesos de negocio trabajan como fue diseado.
ETAPAS DE PRUEBA DEL WINRUNNER
1. CREACIN DE PRUEBAS
Crear pruebas con la grabacin y la programacin.
Mientras se realizan las pruebas de grabacin, se puede aadir puntos
de control para comprobar el comportamiento de la aplicacin.
2. PRUEBAS DE FUNCIONAMIENTO
Mientras se ejecuta una prueba, WinRunner emula un usuario humano
mediante la utilizacin del mouse y teclado en la aplicacin.
3. ANLISIS DE LOS RESULTADOS DE LA PRUEBA
Cuando una ejecucin de prueba termina, WinRunner realiza una lista
de todos los eventos importantes que tuvieron lugar durante la

realizacin de la prueba, tales como puntos de control, los errores o

mensajes.
2. CASO DE PRUEBA
n caso de prueba o test case es, en ingeniera del software, un conjunto de
U condiciones o variables bajo las cules un analista determinar si una

aplicacin, un sistema software (software system), o una caracterstica de stos
es parcial o completamente satisfactoria.
Se pueden realizar muchos casos de prueba para determinar que un requisito es
completamente satisfactorio. Con el propsito de comprobar que todos los requisitos
de una aplicacin son revisados, debe haber al menos un caso de prueba para cada
requisito a menos que un requisito tenga requisitos secundarios. En ese caso, cada
requisito secundario deber tener por lo menos un caso de prueba. Algunas
metodologas como RUP recomiendan el crear por lo menos dos casos de prueba para
cada requisito. Uno de ellos debe realizar la prueba positiva de los requisitos y el otro
debe realizar la prueba negativa.
Si la aplicacin es creada sin requisitos formales, entonces los casos de prueba se
escriben basados en la operacin normal de programas de una clase similar.
Lo que caracteriza un escrito formal de caso de prueba es que hay una entrada
conocida y una salida esperada, los cuales son formulados antes de que se ejecute la
prueba. La entrada conocida debe probar una precondicin y la salida esperada debe
probar una postcondicin.
Bajo circunstancias especiales, podra haber la necesidad de ejecutar la prueba,
producir resultados, y luego un equipo de expertos evaluara si los resultados se
pueden considerar como "correctos". Esto sucede a menudo en la determinacin del
nmero del rendimiento de productos nuevos. La primera prueba se toma como lnea
base para los subsecuentes ciclos de pruebas/lanzamiento del producto.
Los casos de prueba escritos incluyen una descripcin de la funcionalidad que se
probar, la cul es tomada ya sea de los requisitos o de los casos de uso, y la
preparacin requerida para asegurarse de que la prueba pueda ser dirigida.
Los casos de prueba escritos se recogen generalmente en una suite de pruebas.
Las variaciones de los casos de prueba son comnmente utilizadas en pruebas de
aceptacin. La prueba de aceptacin es realizada por un grupo de usuarios finales o
los clientes del sistema, para asegurarse que el sistema desarrollado cumple sus
requisitos. La prueba de aceptacin de usuario se distingue generalmente por la
incorporacin de un trayecto feliz o casos de prueba positivos.
La fase de pruebas es una de las ms costosas del ciclo de vida software.
Deben realizarse pruebas de todos los artefactos generados durante la construccin
de un producto software, lo que incluye las especificaciones de requisitos, casos de
uso, diagramas de diversos tipos y, por supuesto, el cdigo fuente y el resto de
elementos que forman parte de la aplicacin.
Se aplican diferentes tcnicas de prueba a cada tipo de producto software.

PRUEBAS DE SISTEMA
Las pruebas de software (testing) son los procesos que permiten verificar y revelar la
calidad de un producto software.
Son utilizadas para identificar posibles fallos de:
Implementacin
Calidad
Usabilidad
2.1 CASOS DE PRUEBAS

La forma de verificar de las diversas funcionalidades de un producto de software,
descritas en el formato de ncora o en Casos de Uso, son el punto de partida para la
preparacin de casos de prueba y, en ocasiones, de procedimientos de prueba. Las
funcionalidades o prestaciones de un sistema pueden separarse en dos grupos:
a) Aquellas que reciben un conjunto de entradas ms o menos simultneas

y a partir de ellas generan un resultado
Ocurre cuando las entradas deben completarse antes de que el sistema se lance
a realizar una funcin, bsicamente sin retroalimentacin que pueda influir en el
usuario.
Es el caso de una sola variable, una sola accin a travs de un botn o de un Enter,
pero tambin incluye la lectura de listas de datos cuyo proceso se realiza cuando
la lista ha terminado.
Ejemplo
En interfaces grficas, donde resulta muy comn que deban llenarse varios
campos (por ejemplo, nombre, direccin, telfono y rfc) y al final se oprime un
botn el cual indica al sistema que la entrada est completa y puede aplicar la
funcin seleccionada.
b) Las que requieren una serie de interacciones con el actor(usuario), en

cada una de las cuales ste introduce una serie de datos.
Ocurre cuando la entrada ocurre en varias etapas donde una de ellas genera
una respuesta parcial del sistema, la cual influye en la siguiente, ya que el
usuario no puede indicar las entradas sin tomar en cuenta la salida intermedia.
Sin embargo, la funcin completa requiere de terminar todas las etapas.
Ejemplo
El empleado selecciona la opcin Consultar y el sistema le muestra una lista
de productos; el empleado marca los productos que le interesan y al terminar
oprime el botn Cotizar; el sistema le muestra la lista de productos
seleccionados y los precios de cada uno, as como la disponibilidad; tambin
deja un espacio a la derecha de cada producto para anotar la cantidad deseada;
el empleado marca la cantidad deseada de cada uno; los no deseados los
marca con un cero. Al concluir oprime el botn Listo.
El sistema genera una orden y le solicita que indique la forma de pago; el

empleado marca Tarjeta y escribe el nmero y la compaa y oprime
Termina; el sistema verifica los datos con el banco y, si est de acuerdo, enva

mensaje y una muestra un botn Imprimir factura; el empleado oprime el

botn Imprimir factura y el sistema lo hace.
En el ejemplo es claro que existen cinco etapas de entrada de datos para

completar una sola funcin. Lo que el empleado puede ingresar en cada una
depende de la anterior. En las tres subsecciones siguientes se describen los
aspectos generales de la preparacin de casos de prueba y los detalles cuando
ocurre cada uno de los casos mencionados.
2.2 DISEO DE CASOS DE PRUEBAS
El diseo de casos de prueba se puede realizar basndose en los enfoques y en sus

tcnicas y las estrategias de prueba.
Objetivo: Conseguir confianza aceptable en que se encontraran todos defectos
existentes, sin consumir una cantidad excesiva de recursos.
TCNICAS DE DISEO DE CASOS DE PRUEBA
PROPSITO
Producir el nmero de casos de prueba manteniendo la efectividad de la prueba.
ENFOQUES PRINCIPALES
Caja blanca (como lo hace)
Caja negra (que es lo que hace)
1. PRUEBAS DE CAJA BLANCA

Consiste en realizar pruebas para verificar que lneas especficas del cdigo
funcionan tal como est definido.
Tambin usa la estructura de control del diseo procedimental para obtener los
casos de prueba.
Figura 1.3 Prueba de Caja Blanca

2. PRUEBAS DE CAJA NEGRA
La prueba verifica que el tem que se est probando, cuando se dan las entradas
apropiadas produce los resultados esperados. Los datos de prueba se escogern
atendiendo a las especificaciones al problema, sin importar los detalles internos
del programa, al fin de verificar que el programa corra bien.
Figura 1.4 Prueba de Caja Negra
2.2.1 CARACTERSTICAS QUE DEBE TENER UNA BUENA PRUEBA
Una buena prueba tiene una alta probabilidad de encontrar un error.

El ingeniero de software debe tener un alto nivel de entendimiento del software
a construir.
Una buena prueba no debe ser redundante.

Uno de los objetivos de las pruebas es encontrar el mayor nmero de errores
con la menor cantidad de tiempo y esfuerzo posibles.
Una buena prueba debera ser la mejor de la cosecha.

La limitacin en tiempo y recursos puede impedir que se ejecuten todos los
casos de prueba.
Una buena prueba no debera ser ni demasiado sencilla ni demasiado

compleja.
2.2.2 ESTRUCTURA DE LOS CASOS DE PRUEBA

Formalmente, los casos de prueba escritos consisten principalmente en tres partes
con subdivisiones:
Introduccin/visin general: Contiene informacin general acerca de los Casos de
Prueba.
Identificador: Es un identificador nico para futuras referencias, por ejemplo,
mientras se describe un defecto encontrado.
Caso de prueba dueo/creador: Es el nombre del analista o diseador de
pruebas, quien ha desarrollado pruebas o es responsable de su desarrollo.
Versin: La actual definicin del caso de prueba.
Nombre: El caso de prueba debe ser un ttulo entendible por personas, para la
fcil comprensin del propsito del caso de prueba y su campo de aplicacin.

Identificador de requerimientos: el cul est incluido por el caso de prueba.

Tambin aqu puede ser un identificador de casos de uso o de especificacin
funcional.
Propsito: Contiene una breve descripcin del propsito de la prueba, y la
funcionalidad que chequea.
Dependencias: Indica qu otros subsistemas estn involucrados y en qu
grado.
2.2.3 ACTIVIDADES DE LOS CASOS DE PRUEBA

Ambiente de prueba/configuracin: Contiene informacin acerca de la
configuracin del hardware o software en el cul se ejecutar el caso de
prueba.
Inicializacin: Describe acciones, que deben ser ejecutadas antes de que los
casos de prueba se hayan inicializado. Por ejemplo, debemos abrir algn
archivo.
Finalizacin: Describe acciones, que deben ser ejecutadas despus de
realizado el caso de prueba. Por ejemplo, si el caso de prueba estropea la base
de datos, el analista debe restaurarla antes de que otro caso de prueba sea
ejecutado.
Acciones: Pasos a realizar para completar la prueba.
Descripcin de los datos de entrada.
2.2.4 RESULTADOS
Salida esperada: Contiene una descripcin de lo que el analista debera ver
tras haber completado todos los pasos de la prueba.
Salida obtenida: Contiene una breve descripcin de lo que el analista encuentra
despus de que los pasos de prueba se hayan completado.
Resultado: Indica el resultado cualitativo de la ejecucin del caso de prueba, a
menudo con un Correcto/Fallido.
Severidad: Indica el impacto del defecto en el sistema: Grave, Mayor, Normal,
Menor.
Evidencia: En los casos que aplica, contiene informacin, bien un link al print
de pantalla (screenshot), bien una consulta a una base de datos, bien el
contenido de un fichero de trazas, donde se evidencia la salida obtenida.
Seguimiento: Si un caso de prueba falla, frecuentemente la referencia al
defecto implicado se debe enumerar en esta columna. Contiene el cdigo
correlativo del defecto, a menudo corresponde al cdigo del sistema de tracking
de bugs que se est usando.
Estado: Indica si el caso de prueba est: No iniciado, En curso, o terminado.
2.3 MODELOS BSICOS

Test Maturity Model (TMM)
Test Process Improvemente (TPI)
Critical Test Process (CTP)
Systematic Test and Evolution Process (STEP)

2.3.1 OTROS MODELOS

ITIL V3 Pruebas concebidas como un servicio, estableciendo la organizacin
de prueba utilizando los procesos ITIL y buenas prcticas.
TIM Test Imprevement Model, modelo de proceso de mejora centrado en la
eficiencia de coste.
TMap Test Management, enfoque para pruebas orientadas al resultado.
SQR Software Quality Rank, mejora de la calidad software a nivel de
componente.
Criterios Comunes
Iniciar
Medir
Priorizar/Planificar
Redefinir
Operar
Validar
Evolucionar
Figura 1.5 Cuadro Comparativo de Modelos

3.- CLASES DE EQUIVALENCIA
3.1 DEFINICIN
os datos de entrada y los resultados de salida se agrupan en clases diferentes,
L en las que todos los miembros de dicha clase estn relacionados

Cada una de estas clases es una clase de equivalencia o particin de
equivalencia en la que el programa se comporta de la misma forma para cada
miembro de la clase
Se supone que la prueba de un valor representativo de cada clase sea equivalente a
la prueba de cualquier otro valor.
Las clases de equivalencia deberan corresponder a casos similares (para los cuales
el SUT (Caja Negra) se comportara de la misma manera).
Figura 1.6 Testing Funcional Caja

Negra
Motivacin: Si el SUT funciona correctamente para un test en una clase, se supone

que lo har para el resto de los casos de la misma clase.
Problema: definir una poltica de particionado adecuada. Se debe analizar la

especificacin y definir clases de equivalencia de test, identificando los inputs para
los cuales se especifican distintos comportamientos.
Figura 1.7 Ejemplo de clases de equivalencia

3.2 PASOS
1. Identificar las clases de equivalencia
Se toma cada condicin de entrada o salida (usualmente frase o sentencia en la

especificacin) y se la divide en 1 o ms grupos. Se identifican dos tipos de clase de
equivalencias:
Validas
Invalidas
Una cierta combinacin de clases de entrada dar como resultado una combinacin
de clases de salida.
3.2.1 PAUTAS
a) Rango de Valores: Si una condicin de entrada especifica un rango de valores

(rango entre 1 y 99).
Clases validas Clase invalidas

1<nro. <99 nro. < 1
nro > 99
Tabla 1.1 Rango de Valores
b) Nmero de Valores: Si una condicin de entrada especifica el nmero de

valores (1 a 6 propietarios por automvil)

1<propietarios<6 no hay propietarios
hay ms de 6 propietario
Tabla 1.2 Nmero de Valores
c) Conjunto de Valores: Si una condicin de entrada especifica un conjunto de

valores y existen razones para creer que el programa los trata distintos
(vehculo puede ser: mnibus, camin, taxi, moto)

Uno por cada uno Todos los que no son esos,
por ejemplo: trailer
Tabla 1.3 Conjunto de Valores

d) Debe ser: Si una condicin de entrada especifica un debe ser (el primer
carcter debe ser un dgito)

Primer carcter un dgito Primer carcter distinto
de dgito
Tabla 1.4 Debe ser
3.2.2 DEFINIR LOS CASOS DE PRUEBA
Crear Casos de Prueba
*Por cada dato de entrada y salida elegimos un valor perteneciente a una clase de
equivalencia.
*Un caso de prueba est formado por un dato de prueba para cada dato de entrada y
salida (resultado esperado).
Ejemplo: result function (x, y, z). Sean Vi las clases vlidas y Ni las clases invlidas
Clases de x: V1, N1, N2
Clases de y: V2, N3
Clases de z: V3, N4, N5
Clases de result: V4, N6, N7
Un posible caso de prueba sera: (x1 en V1, y1 en V2, z1 en V3, r1 en V4)
Pautas
El objetivo es probar todas las clases vlidas y no vlidas al menos una vez
cada una de ellas
Cada caso debe cubrir el mximo nmero de entradas
En un caso de prueba pueden aparecer varias clases de entrada vlidas
En un caso de prueba solamente puede aparecer una entrada no vlida. El
criterio para las clases no vlidas impide que los errores se enmascaren
mutuamente
Se debe especificar el resultado esperado
Ejemplo: result function(x,y)
Clases de x: V1, N1,N2
Clases de y: V2,V3
Clases de result: V4, N3

Casos de Prueba:
(V1,V2,V4)
(V1,V3,V4)
(N1,V2,N3)
(N2,V3,N3)
*No es necesario probar todas las combinaciones.
3.3 DIRECTRICES
Las clases de equivalencia se pueden definir de acuerdo con las siguientes
directrices: Si un parmetro de entrada debe estar comprendido en un cierto
rango, aparecen 3 clases de equivalencia:
Por debajo del rango
En el rango
Por encima del rango.
Si una entrada requiere un valor de entre los de un conjunto, aparecen 2 clases
de equivalencia:
En el conjunto.
Fuera del conjunto.
Si una entrada es booleana, hay 2 clases:
Si
No
Los mismos criterios se aplican a las salidas esperadas: hay que intentar generar
resultados en todas y cada una de las clases.
Aplicando estas directrices se ejecutan casos de pruebas para cada elemento de
datos del campo de entrada a desarrollar. Los casos se seleccionan de forma
que ejerciten el mayor nmero de atributos de cada clase de equivalencia a la
vez.
Para aplicar esta tcnica de prueba se tienen en cuenta los siguientes pasos:
Primero se deben identificar las clases de equivalencia lo cual se hace

tomando cada condicin de entrada y aplicndole las directrices antes
expuestas.
Para definir las clases de equivalencia hace falta tener en cuenta un conjunto de
reglas:
Si una condicin de entrada especifica un rango, entonces se
confeccionan una clase de equivalencia vlida y 2 invlidas.
Si una condicin de entrada especifica la cantidad de valores, identificar
una clase de equivalencia vlida y dos invlidas.
Si una condicin de entrada especifica un conjunto de valores de entrada
y existen razones para creer que el programa trata en forma diferente a
cada uno de ellos, identificar una clase vlida para cada uno de ellos y
una clase invlida.

Si una condicin de entrada especifica una situacin de tipo debe ser,

identificar una clase vlida y una invlida.
Si existe una razn para creer que el programa no trata de f orma idntica
ciertos elementos pertenecientes a una clase, dividirla en clases de
equivalencia menores.
Luego de tener las clases vlidas e invlidas definidas, se procede a definir
los casos de pruebas, pero para ello antes se debe haber asignado un
identificador nico a cada clase de equivalencia.
Luego entonces se pueden definir los casos teniendo en cuenta lo siguiente:
Escribir un nuevo caso de cubra tantas clases de equivalencia vlidas
no cubiertas como sea posible hasta que todas las clases de
equivalencia hayan sido cubiertas por casos de prueba.
Escribir un nuevo caso de prueba que cubra una y solo una clase de
equivalencia invlida hasta que todas las clases de equivalencias
invlidas hayan sido cubiertas por casos de pruebas.
Con la aplicacin de esa tcnica se obtiene un conjunto de pruebas que reduce el
nmero de casos de pruebas y nos dicen algo sobre la presencia o ausencia de
errores. A menudo se plantea que las pruebas al software nunca terminan,
simplemente se transfiere del desarrollador al cliente. Cada vez que el cliente usa el
programa est llevando a cabo una prueba.
Aplicando el diseo de casos de pruebas al software en cuestin se puede conseguir
una prueba ms completa y descubrir y corregir el mayor nmero de errores antes de
que comiencen las pruebas del cliente.

4.- INFORME DE PRUEBAS DE SOFTWARE

a calidad del software es el conjunto de cualidades que lo caracterizan y que
L determinan su utilidad y existencia, la cual plantea un adecuado balanceo de

eficiencia, confiabilidad, facilidad de mantenimiento, portabilidad, facilidad de
uso, seguridad e integridad.
Para ello, se suele manejar un informe de avance de cmo van las pruebas, el cual
segn la criticidad del proyecto puede ser solicitado una o varias veces al da.
La intencin es comunicar a todos los involucrados de las reas de pruebas, desarrollo,

funcionales y rea de negocio cual es la situacin de las pruebas, que defectos crticos
se estn reportando y cuantos casos faltan por ejecutar.
LISTA DE FACTORES
Mide el grado en que un programa satisface sus

Correccin especificaciones y consigue los objetivos del usuario
Mide el grado en que se puede esperar que un programa
Fiabilidad lleve a cabo sus funciones esperada con la precisin
requerida.
Mide la cantidad de recursos de computadora y de cdigo
Eficiencia requerido por un programa para que lleve a cabo las
funciones especificadas.
Es el grado en que puede controlarse el acceso al software
Integridad o a los datos por personal no autorizado
Es el esfuerzo requerido para aprender un programa e
Facilidad de Uso
interpretar la informacin de entrada y de salida.
Facilidad de Es el esfuerzo requerido para localizar y arreglar
Mantenimiento programas
Facilidad de Prueba Es el esfuerzo requerido para probar un programa
Portabilidad Es el esfuerzo requerido para transferir un software de un

hardware o un entorno de sistemas a otro
Es el grado en que un programa (o partes de un programa)
Reusabilidad se puede reutilizar en otro
Facilidad de
Es el esfuerzo requerido para asociar un programa a otro
Interoperacin
Tabla 1.5 Lista de Factores

4.1 MODELO 1
CONDICIONES GENERALES PARA LA EJECUCIN DE LAS PRUEBAS DE
CALIDAD DEL SOFTWARE
Objetivo FUNCION OPTIMA DEL SOFTWARE

Hardware Requerido LAPTOP TOSHIBA CORE I5- 500DD 4GB RAM
Software Requerido NET FRAMEWORK 3.5, WINDOWS 7
No. de Usuarios 4 USUARIOS
1. Definir reunin con el usuario
2. Diligenciar la lista de chequeo adjunta. En la lista de chequeo,

Procedimiento de encontrar un conjunto de tems, en los cuales usted podr indicar si
Prueba se cumple o no y
podr consignar sus observaciones si lo considera pertinente.
3. Una vez terminada la prueba, deber remitir el resultado de ejecucin

al jefe del equipo de desarrollo.
EVALUACIN DE LAS MTRICAS DE CALIDAD

desarrollo.
C : Cumple ( Escala 1 a 5 )
CUMPLIMIENTO DE LOS FACTORES NC : No Cumple ( Escala 1 a 5 )
DE CALIDAD NR : No requerido ( Escala 1 a 5 )
VE : Valor Estimado ( Escala 1 a 5 )
Mtrica a Evaluar C NC NR VE Total Observaciones

1. Fiabilidad 5 0 0 0 5
2. Facilidad de Uso 4 0 0 0 4
3. Facilidad de Prueba 5 0 0 0 5
4. Eficiencia 5 0 0 0 5
5. Facilidad de Mantenimiento 4 0 0 0 4
6. Portabilidad 5 0 0 0 5
7. Integridad 5 0 0 0 5
8. Correccin 4 0 0 0 4
9. Reusabilidad 4 0 0 0 4
10. Facilidad de Interoperacin 5 0 0 0 5
Prueba Ejecutada por: Firma Fecha
Tabla 1.6 Evaluacin de Mtricas de Calidad

Informe Final
Para: JEFE DE PROYECTO

Cargo: INFORME DE PRUEBAS DEL SOFTWARE
Asunto:
A continuacin, me permito relacionar el informe final sobre las Pruebas de Calidad

del Software para nuestro proyecto TURIMSICA.
Prueba Funcional:
Listar Dependencias
Elaborado por: Identificador:
Objetivo Verificar el cumplimiento de la Historia de

Usuario: Crear Mdulos, Modificar Mdulos,
Listar Mdulos, Crear Dependencia, Modificar
Dependencia, Listar Dependencias.
Se cumple:
ITEM Observaciones
SI / NO
1. Se logr ingresar a la opcin requerida
2. El sistema muestra una lista de las

Links existentes en el sistema?
3. El sistema despleg un formulario para
permitir la creacin de un nuevo
Usuario?
4. Logr crear una nueva Link?
5. El sistema valid correctamente los

campos del formulario1?
6. El sistema actualiz la lista de
mdulos con el que usted cre?
7. Puede seleccionar un usuario de la
lista de usuarios?
Informe elaborado por: Firma Fecha
Tabla 1.7 Informe de Cumplimiento de ITEM

4.2 MODELO 2
Modelo de informe de ejecucin de pruebas de software

Estatus del proyecto / Requerimiento: [Cdigo asociado al proyecto] - [Nombre del proyecto]
Fecha de
Fecha % % Das Fecha Casos % casos
finalizaci Casos de Casos Casos %
comienzo avance avan de fin con con
n prueba planifica exitoso desvia
planificad planifi ce desvia prons inciden incidenci
planificad (Total) dos s cin
a cado real cin tico cia as
a
Resultados de la
Situacin actual de casos de prueba Situacin actual de defectos
jornada
En En
Con Bloquea Diferido Pendie Report Descar Correg Casos Meta
Exitosos anli proces
defectos dos s ntes ados tados idos del da diaria
sis o
Puntos de atencin y observaciones
Tabla 1.8 Informe de Ejecucin de pruebas

Modelo de informe de ejecucin de pruebas de

software
Descripcin de la informacin a completar en cada columna
Columna Instrucciones
Cdigo asociado al proyecto Cdigo del requerimiento o proyecto segn la nomenclatura
definida por la organizacin. Este cdigo se usa para
identificar todos los documentos asociados y para registrarlo
en los sistemas de gestin.
Nombre del proyecto Nombre o descripcin por lo cual se conoce al
requerimiento o proyecto. Suele estar relacionado con la
funcionalidad que se est desarrollando.
Fecha comienzo planificada Fecha calendario en la cual estaba planificado iniciar las
pruebas.
Fecha de finalizacin planificada Fecha calendario en la cual se tiene planificado finalizar las
pruebas, considerando el nmero de casos de prueba total
y las metas de casos diaria.
Casos de prueba (Total) Cantidad de casos de prueba que estn incluidos en el
diseo. Representa el nmero total de casos que ejecutarn
los Testers en el perodo definido para las pruebas.
Casos planificados Cantidad de casos de pruebas que deberan estar
completados a la fecha segn la planificacin.
Casos exitosos Cantidad de casos reales completados. Esto representa el
avance real de las pruebas. Slo se cuentan los casos que
las pruebas fueron superadas sin error, los casos con error
no cuentan para el avance.
% avance planificado Los casos de prueba planificados divididos entre el total de
casos de prueba, dan como resultado el porcentaje de
avance que deben tener las pruebas a la fecha de reporte.
% avance real Se calcula por medio de la divisin de los casos exitosos
entre el total de casos contemplados en el diseo de
pruebas.
% desviacin La diferencia entre el avance real y el planificado resulta en
la desviacin. Un nmero negativo representa que las
pruebas estn avanzando por debajo de lo esperado.
Das de desviacin Los das de desviacin se calculan multiplicando el
porcentaje de desviacin por los casos diarios. A su vez los
casos diarios se determinan dividiendo el nmero total de
casos entre los das hbiles disponibles para realizar las
pruebas.
Fecha fin pronstico Para determinar la fecha fin pronstico es necesario sumar
a la fecha fin planificada los das de desviacin.
Casos con incidencia Cantidad de casos de prueba ejecutados que presentaron
alguna incidencia. An despus de corregir la incidencia el
caso sigue siendo sumado, de esta forma al final se tendrn
cuantos casos presentaron incidencias.
% casos con incidencias Divisin de los casos que presentaron alguna incidencia
entre el total de casos. Representa un ndice de la calidad
del desarrollo e inclusive se pueden establecer acuerdos de
nivel de servicio.

Situacin actual de casos de prueba

Exitosos Cantidad de casos de prueba que se encuentran en estado
"Exitoso" a la fecha del informe. Son los casos que un
Analista de pruebas ha ejecutado y ha sido superado sin
error.
Con defectos Cantidad de casos de prueba que se encuentran en estado
"Fallido" a la fecha del informe. Son los casos que tienen
asociados defectos con estatus distintos de cerrado.
Bloqueados Cantidad de casos de prueba que se encuentran en estado
"Bloqueado" a la fecha del informe. Un caso puede estar
bloqueado por ejemplo cuando existe una incidencia
identificada en otro caso pero que a su vez impide la
ejecucin de otros casos.
Diferidos Cantidad de casos de prueba que se encuentran en estado
"Diferido" a la fecha del informe. Un caso puede ser diferido
por distintas razones, una de ellas por ejemplo es la no
disponibilidad de un ambiente para un componente
especifico.
Pendientes Cantidad de casos de prueba que se encuentran en estado
"Pendiente" a la fecha del informe. Son los casos que no
han sido ejecutados an.
Situacin actual de defectos
Reportados Total, de defectos (incidencias) que se han abierto a la
fecha de reporte.
En anlisis Cantidad de defectos que se encuentran en anlisis, no han
sido aceptados todava.
Descartados Cantidad de defectos descartados porque no aplicaban. Un
no aplica ocurre cuando un Tester reporta un defecto que
realmente no lo es. Una vez aclarada la situacin se registra
el defecto como descartado.
En proceso Cantidad de defectos que fueron analizados y se
encuentran en desarrollo.
Corregidos Cantidad de defectos que han sido corregidos. La
correccin del defecto implica su cierre.
Resultados de la jornada
Casos del da Casos que se lograron ejecutar como exitosos durante la
jornada (fecha de reporte).
Meta diaria Casos que se esperan ejecutar cada da. Se puede calcular
dividiendo los casos en diseo sobre los das planificados, o
cualquier otra forma de estimacin definida.
Observaciones
Puntos de atencin y Espacio para que la persona que elabora el reporte haga
observaciones mencin a los aspectos considerados relevantes para la
gerencia receptora del informe. Aqu se pueden colocar por
ejemplo alertas.
Por ejemplo los tiempos en que los ambientes de pruebas
no estn disponibles por fallas en la plataforma pueden
registrarse aqu.
Tabla 1.9 Conceptos del Informe

5. SEGUIMIENTO DE PRUEBAS
DEFINICION
ermite tener una planeacin de la aplicacin de las pruebas y el tipo de pruebas
P que harn que el sistema funcione correctamente

Al momento de liberarse por completo, se crea seguridad en los usuarios finales
de que el sistema no fallar. Existen dos actividades fundamentales para la etapa de
pruebas: las pruebas de componentes y las pruebas del sistema
En la primera se prueban las partes del sistema por separado
En la segunda se prueban los componentes ya integrados, el sistema como un todo
5.1 PROCESO DE SEGUIMIENTO PRUEBAS

5.1.1 ANLISIS Y PLANEACION
DEFINICIN
El proceso de esta fase es realizar un anlisis de la informacin existente del sistema,
para determinar el alcance, estrategia y esfuerzo que las pruebas requieran, as como
realizar la planeacin de pruebas de acuerdo a la complejidad y necesidades del
Proyecto.
Criterios de entrada
. Plan de trabajo general del proyecto

. Visin y alcance del proyecto
. Requerimientos funcionales y no funcionales
Criterios de salida
. Especificaciones de requerimientos
. Configuracin del ambiente
. Plan de trabajo
. Especificaciones de pruebas
. Casos de prueba
Qu debo de hacer?
1. Analizar la documentacin existente
2. Realizar pruebas de requerimientos (estticas)
3. Definir la estrategia (Mtodos)
4. Crear el plan de trabajo.

5.1.2 DISEO DE PRUEBAS

Dentro del proceso de pruebas existe una etapa en donde toda la informacin
analizada y estudiada se convierte en artefactos de prueba y se les da respuesta a
preguntas como las siguientes: Cmo lo voy a probar? Que voy a usar para
asegurarme que la aplicacin funcione correctamente?
Qu es lo ms adecuado para probar este sistema?
Qu debo hacer?
El objetivo de todo diseo de pruebas es plasmar todos aquellos elementos sobre
cmo debera y como no debera de funcionar una aplicacin usando diferentes
componentes del testware, siempre basados en la especificacin funcional definida
previamente.
5.2 CASOS DE PRUEBA

- Conjunto de entradas de prueba, condiciones de ejecucin y resultados esperados,
desarrollados para un objetivo concreto.
- Consideraciones
. Todos los requerimientos tienen casos de prueba
. Para cada requerimiento, siempre existe por lo menos un caso de prueba test to pass
u test to fail
. Existen casos de prueba especficos y generales.

5.2.1 MATRICES DE PRUEBAS
Es la combinatoria de todas las variantes de los casos de prueba con cada

uno de sus valores. Indicando si el resultado de la prueba fue exitoso o no
Determina las variantes y valores para un requerimiento
Documentar los datos utilizados para las pruebas
Delimitar las combinaciones que pueden tener entre las variantes y los valores
5.2.2 GENERAR EL PROCEDIMIENTO DE PRUEBAS
Objetivo y lista de casos de uso que se ejecutan con l.

Determinar el tipo de prueba a ejecutar
Requisitos especiales para la ejecucin
Secuencia necesaria de acciones para preparar la ejecucin
Acciones necesarias para iniciar la ejecucin
Acciones necesarias durante la ejecucin
Mediciones a revisar, por ejemplo, el tiempo
Acciones necesarias para suspender la prueba
Acciones necesarias para restaurar el entorno y dejarlo en la
situacin existente de las pruebas.
5.3 EJECUCIN DE PRUEBAS
Probar es el proceso de identificar defectos, cuando un defecto e cualquier variante

entre lo que existe y lo que se esperaba.
5.3.1 EJECUCIN DEL TESTWARE

Ejecutar ataques diseados para sobrepasar los lmites de entradas
y salidas
Analizar la manera en que el Software almacena y manipula los
datos
Ejecuta ataques diseados para corromper los datos
Analizar como el software realiza los clculos
Ejecutar ataques para forzar errores en el clculo
Conocer el ecosistema en el que reside sistema.
5.3.2. EVALUACIN DE PRUEBAS
Aplicar la paradoja del pesticida

Una vez terminado cada ciclo de pruebas
Pruebas de escritorio (verificacin individual)
Inspecciones (check list)
Verificacin de requerimientos
Revisiones formales
Validacin Construimos el sistema correcto?
Verificacin construimos el sistema correctamente?
5.4 ESTABILIZACIN
Una vez terminada la ejecucin de pruebas y l correccin de errores, la aplicacin
estar lista para la validacin de los usuarios finales, pero antes de llegar a este punto
se debe de asegurar que la versin del sistema mantenga su integridad, es decir que
siga funcionando de la misma forma que durante la ejecucin de pruebas
La calidad del sistema est estrechamente relacionada a la calidad con que se realizan
las pruebas del mismo.
En la estabilizacin se aplican pruebas performance, regresin y actualizacin de
documentacin.
5.4.1 PRUEBAS PERFORMANCE

Seguir el procedimiento de pruebas de performance, previamente generado en la fase
de diseo
5.4.2 PRUEBAS DE REGRESIN
Es comprobar que las modificaciones no generaron errores donde antes no los haba.
Validar nicamente los puntos a partir de los cuales sabemos que el resto de la
aplicacin permanecer estable (Happy path).
Seleccionar casos de prueba. Los casos de prueba ms representativos de negocio y
funcionalidad (happy path)
Analizar errores reportados. Verificar que los errores han sido corregidos
Ejecutar los casos de prueba seleccionados como happy path.
5.4.3 INFORMAR DE LA LIBERACIN
Una vez que nos aseguramos de que la versin est libre de defectos, se debe informar
para enviarla a Vo. Bo. Con el usuario.
Actualizar el testware: actualizar todo el restware que quedo desactualizado, es la fase
de documentacin donde se tiene que actualizar el testware.
5.5 ACEPTACION
Son las pruebas que se realizan con el usuario (o con supervisin de este), con el
objetivo de verificar que el sistema cumple con los requerimientos especficos
inicialmente.
Se debe de hacer el plan de pruebas de aceptacin, la ejecucin depruebas y reporte
de pruebas.
5.5.1 PLAN DE PRUEBAS DE ACEPTACIN
Calendarizar actividades: realizar la calendarizacin del plan de trabajo de pruebas de
aceptacin, e identificar los requerimientos que sern probados
Informar a los usuarios del plan de pruebas

5.5.2 EJECUCIN DE PRUEBAS DE ACEPTACIN
Validar las pruebas con el usuario

Ejecutar pruebas con el
usuario
Validar pruebas con el usuario.
Control y seguimiento de errores.
TIPOS DE PRUEBAS DE ACEPTACIN
a) Bechmarcks
El cliente prepara casos de prueba que evalan el rendimiento del sistema bajo
condiciones tpicas de operacin del sistema. Dos o ms versiones del mismo sistema
se evalan para escoger la de mayor rendimiento.
b) Pruebas piloto
Pruebas las funciones rutinarias del sistema, aquellas que normalmente se realizarn
cuando el sistema est operando regularmente.
c) Pruebas alfa y beta

Prueban el sistema con usuarios seleccionados o potenciales de la compaa de
desarrollo de software o del cliente. Las pruebas alfa son pruebas realizadas dentro de
la compaa de desarrollo de software, las pruebas beta son pruebas realizadas por el
cliente usando usuarios seleccionados.
Pruebas en paralelo
Se realizan cuando el sistema desarrollado reemplaza uno ya existente o el desarrollo
se realiza en etapas o incrementos. El sistema nuevo opera en paralelo con el existente
hasta que gradualmente los usuarios se acostumbran al nuevo.
5.5.3 CREAR EL REPORTE DE PRUEBAS DE ACEPTACIN

5.5.4 TIPS PARA LA ETAPA DE ACEPTACION:
Facilitar al usuario el testware generado
Verificar que el usuario tenga bien establecidas las reglas del negocio que va a
probar
Recomendar que el usuario que defini es quien debe realizar las pruebas
Llevar un control de los mdulos ejecutados por da.
Llevar un control de errores detectados.
Nunca olvidar solicitar al final la firma del Vo.Bo.
5.6 CIERRE DEL PROYECTO
La fase de cierre del proyecto tiene como objetivo realizar todas las actividades de
cierre del proyecto, como actualizacin del testware y realizar la ltima revisin de la
aplicacin en ambiente productivo, adems de mirar hacia atrs y revisar las cosas que
se hicieron bien y las cosas que necesitan mejorar.
QUE HACER EN EL CIERRE DEL PROYECTO?
5.6.1 IDENTIFICAR MEJORES PRCTICAS Y AREAS DE OPORTUNIDAD
. listados de las cosas que se hicieron bien y las propuestas a mejorar

. listado de las cosas que se hicieron mal y sugerencias para mejorar en futuros
proyectos
. descripcin de las mejores prcticas para futuros proyectos
5.6.2 JUNTA DE CIERRE DE PROYECTO
. categorizar y contabilizar comentarios

. enlistar comentarios frecuentes
. generar reporte de post mortem (mejores prcticas)
5.6.3 REPORTE DE CIERRE DE PROYECTO
. Posterior a la reunin, se debe generar el reporte de cierre de proyecto y publicarlo
para que el resto del equipo pueda consultarlo.
. Elementos de un reporte:
Mejores prcticas y peores prcticas

ID de la prctica
Descripcin
No. De menciones (Votos durante la reunin)
Categora
Prioridad
Acciones correctivas propuestas

Las pruebas de software permiten la ejecucin de un programa cuya intencin u objetivo

principal es el de detectar errores presentes en el software con el fin de disminuirlos y
corregirlos para que a su vez se mejore la calidad con la que se producen los diferentes
aplicativos.
Las pruebas de caja blanca poseen criterios basados en el contenido y la estructura del
cdigo fuente de los mdulos, mientras que las pruebas de caja negra poseen criterios
basados en las interfaces y las especificaciones de los mdulos.
Las pruebas no son demostraciones
Pasar las pruebas no significa que no haya errores, slo que no se han detectado
Incrementan la confianza
Son costosas, hay que planificarlas cuidadosamente
Hacer pruebas no asegura la calidad, sino que la demuestran.
Nunca un producto software se ha terminado de probar. Hay que establecer un
lmite dependiendo de la trascendencia, costes, etc. del proyecto.
Las pruebas del software no garantizan la calidad de ste: las pruebas
demuestran la calidad pero no la garantizan.
Una herramienta de pruebas sin saber tcnicas, prcticas y tener experiencia en
pruebas es tan til como un entorno de programacin sin saber el lenguaje.


https://senastage.blackboard.com/bbcswebdav/courses/150752/Formato_Prue
bas%20de%20Calidad%20del%20Software.doc

Expo Calidad Final

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Expo Calidad Final

Caricato da

Copyright:

Formati disponibili

AO DEL BUEN SERVICIO AL

CONTROL DE CALIDAD DE SOFTWARE

MISAYCO BAUTISTA EDISON

TORRES PACHAS JAVIER

VIII CICLO 2017

INGENIERIA DE SISTEMAS Pgina 1

INGENIERIA DE SISTEMAS Pgina 2

5.5 ACEPTACIN PAG. 32

INGENIERIA DE SISTEMAS Pgina 3

Las pruebas son bsicamente un conjunto de actividades dentro del desarrollo

Lo que veremos a continuacin en el desarrollo del proyecto son los diversos

INGENIERIA DE SISTEMAS Pgina 4

s la actividad donde los procedimientos de pruebas o scripts son especificados

E combinando los casos de prueba en un orden particular e incluyendo cualquier

Figura 1.1 Proceso de ejecucin de pruebas

INGENIERIA DE SISTEMAS Pgina 5

La fase de ejecucin de pruebas se realiza por iteraciones de pruebas. (Total o un

Figura 1.2 Curva de Registro de Hallazgos o No Conformidades

La correctitud: exactitud de los resultados reales versus los esperados.

b) El proceso de ejecucin propiamente dicho, consta de las siguientes fases:

Se comprueba si ha habido algn fallo al ejecutar.

INGENIERIA DE SISTEMAS Pgina 6

Si lo ha habido, se puede deber a un defecto del software, lo que nos lleva al

De no existir fallos, se pasar a la comprobacin de la terminacin de las

c) Las fases del proceso de comprobacin de la terminacin de las pruebas son:

Tras la ejecucin, se comprueba si se cumplen los criterios de complecin de

En caso de terminar las pruebas, se pasa a la evaluacin de los productos

En caso de no terminar las pruebas se debe comprobar la presencia de

Si hubiesen existido condiciones anormales, se pasa de nuevo a la evaluacin;

Los criterios de complecin de pruebas hacen referencia a las reas (caractersticas,

Se debe cubrir cada caracterstica o requerimiento del software mediante un

1.3. HERRAMIENTAS PARA IMPLEMENTAR Y EJECUTAR PRUEBAS

En la actualidad, para cumplir estos objetivos, muchas organizaciones utilizan las

INGENIERIA DE SISTEMAS Pgina 7

Empirix e-Tester es una herramienta de prueba automatizada que forma parte

Un usuario inicia la generacin de una secuencia de comandos mediante e-

Facilidad de uso es una de las principales caractersticas de este producto. Sin

E-Tester utiliza el entorno de desarrollo de VBA para proporcionar a los

1.3.2. RATIONAL FUNCTIONAL TESTER

Rational Functional Tester antes conocida como XDE Tester, es una

INGENIERIA DE SISTEMAS Pgina 8

INGENIERIA DE SISTEMAS Pgina 9

1.3.3. QUICK TEST PRO

Herramienta para realizar pruebas automatizadas, es tan fcil de usar como

Muchas de las cosas que requiere de la escritura de cdigo en WinRunner,

1.3.4. RATIONAL ROBOT

El objetivo de IBM Rational Robot es facilitar la creacin y ejecucin de scripts

INGENIERIA DE SISTEMAS Pgina 10

correspondiente de la prueba de script, asegurando en consecuencia

TestPartner de Compuware es una herramienta que permite a los usuarios

WinRunner es una herramienta empresarial para pruebas funcionales que

Consiste en capturar, reproducir y verificar las interacciones entre usuarios de

ETAPAS DE PRUEBA DEL WINRUNNER

INGENIERIA DE SISTEMAS Pgina 11

realizacin de la prueba, tales como puntos de control, los errores o

U condiciones o variables bajo las cules un analista determinar si una

INGENIERIA DE SISTEMAS Pgina 12

2.1 CASOS DE PRUEBAS

a) Aquellas que reciben un conjunto de entradas ms o menos simultneas

b) Las que requieren una serie de interacciones con el actor(usuario), en

El sistema genera una orden y le solicita que indique la forma de pago; el

INGENIERIA DE SISTEMAS Pgina 13

mensaje y una muestra un botn Imprimir factura; el empleado oprime el

En el ejemplo es claro que existen cinco etapas de entrada de datos para