HERRAMIENTAS DE PRUEBA

MANUAL
Pruebas:
 El proceso de identificación de errores en un software (proyecto/producto) se conoce
como "Pruebas".
 El ingeniero de pruebas tiene que comprobar (validar) si el software desarrollado
cumple o no los requisitos del cliente. Es responsable de entregar software de calidad al
cliente.

**Nota: La principal responsabilidad del ingeniero de pruebas es comprobar (validar) si la

aplicación (software) desarrollada es útil o no para el usuario final.

Bug: La desviación del requisito se conoce como bug o defecto.

Calidad:Justificar todos los requisitos del cliente con facilidad de uso y seguridad se conoce
como calidad.
 Tomemos un ejemplo: Entregado/Liberado

Analista de negocio Documento requerido Empresa DesarrolladorProyecto/producto

Yo Arquitecto Plan Constructo Constructor Inicio
r
Cliente

Plan
Supervisor

Ingeniero de pruebas

Proyecto:
Se desarrollará en función de los requisitos del cliente; una vez desarrollado, se entregará al
cliente. Los miembros del equipo (usuarios finales) lo utilizarán en función de las necesidades
del cliente.
Ej: Spicejet.com, selenium4testing.com, Construir nuestra propia casa con nuestros
requisitos.
Producto:
Se desarrollará en función de las necesidades de la empresa. Una vez desarrollado, se lanzará
al mercado en función de las necesidades del cliente, que elegirá el producto.
Por ejemplo:aplicación móvil, calculadora, Facebook, Yahoo, MS Office, sistema
operativo Mac, sistema operativo Windows, Gmail, etc.
Tipos de pruebas:

Herramientas de prueba

Pruebas funcionales Pruebas no funcionales

Pruebas de carga

Pruebas manuales Pruebas de automatización Pruebas de rendimiento

Pruebas de estrés con Selenium, win runner

QTP, RFT, silktest, Water, Watin Soak Testing

Aplicaciones basadas en Internet:

Se puede acceder a estas aplicaciones en todo el mundo con un número ilimitado de usuarios.

Ej: Gmail, Facebook, selenium 4testing

Aplicaciones basadas en Intranet:

También se puede acceder a estas aplicaciones en todo el mundo, pero con un número limitado
de usuarios.

Ej: Aplicaciones limitadas a una organización específica.

Licitación del proyecto:

Funciones implicadas:
1. Analista comercial de marketing (BA)
2. Gestor de compromisos (EM)

 Analista comercial de marketing (BA):

El BA de marketing se reunirá con el cliente y le convencerá con la propuesta. Una vez que el
cliente esté satisfecho con la propuesta, el cliente y la empresa firmarán el proyecto.
 Firma:

El acuerdo oficial entre el cliente y la empresa sobre la entrega del proyecto se conoce
como "sign off".

Reunión de lanzamiento:

Una vez aprobado el proyecto, la empresa celebrará una reunióninicial. Es una reunión
rápida en la que participan todos los altos directivos y en la que se anuncia el proyecto,
el cliente y se elige al gestor del proyecto. El gestor de proyectos es responsable del
SDLC.

 Gestor de compromisos (EM):

El Engagement Manager es responsable de mantener la relación entre el cliente y la empresa.

Actúa como puente entre el Cliente y la Empresa.

Licitación del proyecto

1 Cr
Cliente
Acerca de la 1 año
empresa

Historia
Propuesta Firmar
Estimaciones

Tiempo y coste
Reunión inicial
C1 C2 C3

2cr 1,5 cr 1 cr Jefe de proyecto

2 años 1,5 años 1 año

Jerarquía de proyectos o jerarquía de designaciones o jerarquía de funciones

LLM: Gestión de bajo nivel

MLM: Mandos intermedios

HLM: Gestión de alto nivel

CICLO DE VIDA DEL

DESARROLLO DE SOFTWARE (SDLC):
Consta de las siguientes fases,

1. Fase de requisitos
2. Fase de análisis
3. Fase de diseño
4. Fase de codificación
5. Fase de pruebas
6. Fase de entrega y mantenimiento.
PIN:Nota de inicio/intimación del proyecto:

Se trata de un correo electrónico, que preparará el gestor del proyecto y en el que figuran la
fecha de inicio y la fecha de finalización del proyecto. El correo se enviará al cliente y a la alta
dirección.
El PIN indica el inicio del proyecto.

1) Fase de requisitos:
Funciones:Analista de negocio
Gestor de compromisos
Jefe de proyecto

 El BA se encarga de recopilar todos los requisitos en un documento de plantilla de

requisitos (RTD).
 Una vez recogidos todos los requisitos en la plantilla de requisitos, los firmarán,
 El documento firmado se conoce como SRS (especificación de requisitos de
software/sistema) o BRS (especificación de requisitos de negocio) oFRS(especificación de
requisitos funcionales) oBDD(documento de diseño de negocio) o BD (documento de
negocio).
 Una vez definido el documento SRS, el BA es responsable de la prueba de concepto.
 Durante el POC, el BA es responsable de desarrollar el prototipo y se lo presentará al
cliente.

Prototipo: Es una Aplicación de muestra tosca y rápidamente desarrollada; no contiene

ninguna de las funcionalidades reales. Simplemente describe cómo va a ser el proyecto
y cómo se va a mostrar. El objetivo principal del prototipo es recopilar adecuadamente
todos los requisitos y comprenderlos.

 El Engagement Manager es responsable de mantener la relación entre el cliente y la

empresa. También se concentrará en los requisitos adicionales, el coste extra y el
tiempo extra del proyecto.
 El Jefe de Proyecto es responsable de supervisar las fases y ayudará tanto al BA como al
EM a completar sus actividades adecuadamente.
Nota: El resultado de la fase de requisitos es el SRS y el prototipo.

2) Fase de análisis:Análisis de los requisitos.

Funciones:Gestión de alto nivel
Mandos intermedios
 Jefe de proyecto
BA

 Todos los roles anteriores se reunirán y realizarán las siguientes actividades

a. Estudio de viabilidad
b. Selección de tecnología
c. Plan de recursos
d. Plan de salud y seguridad
a. Estudio de viabilidad: Factible significa posible o no. Las funciones anteriores
asumirán todos y cada uno de los requisitos del documento SRS. Se analizarán
los requisitos y se determinará si es posible desarrollarlos o no. En caso
afirmativo, se determinará el tiempo necesario para el desarrollo, las pruebas y
la entrega al cliente. Si no es posible desarrollar algún requisito, se lo
comunicarán al cliente.
b. Selección de tecnologías: La lista de tecnologías como Java, .net, MSSQL,Oracle,
selenium etc. son requeridas para el desarrollo del proyecto, pruebas y entrega
al cliente serán descritas aquí.Basado en las tecnologías contratarán los recursos.
c. Plan de recursos:aquí se describe el número de recursos necesarios para el
desarrollo y las pruebas del proyecto, como desarrolladores, ingenieros de
pruebas e ingenieros de bases de datos.
d. Plan de hardware y software:Aquí se describirá el número de hardware
necesario para el proyecto, como ordenadores de sobremesa, portátiles,
móviles, impresoras, etc., junto con el software correspondiente.

 Todo lo anterior se documentará en un documento denominado plan de proyecto. Se

enviará al cliente, para su revisión.

3) Fase de diseño:
Funciones: Arquitecto/arquitecto jefe
Analista de negocio (BA)
Jefe de proyecto

 El arquitecto revisará todos los requisitos del documento SRS y, en caso de que sea
necesaria alguna aclaración, el BA se encargará de aclarar todos los requisitos
pendientes.
 Una vez que el arquitecto tenga claros todos los requisitos, los dividirá en varios
módulos ysubmódulos.
  Una vez divididos todos los módulos, proporcionará el diagrama arquitectónico
(diagrama de flujo) de todo el proyecto con la ayuda de UML (lenguaje de modelado
unificado).
 Todo lo anterior se documentará en un documento denominado Documento de diseño
o SRS.

4) Fase de codificación:
Funciones: Equipo de desarrollo
Equipo de pruebas
BA
Jefe de proyecto

 Una vez divididos los módulos por arquitecto, se asignarán a los desarrolladores y al
equipo de pruebas.
 Los desarrolladores son responsables de desarrollar el código fuente de los módulos.
Una vez que el código fuente sea estable, lo registrarán en el repositorio central.
 El jefe de desarrollo comprueba el código fuente en su sistema local, lo compila y lo
envía al equipo de pruebas para que lo compruebe.

Repositorio central:
 Repositorio significa una carpeta de almacenamiento. Por repositorio central se entiende la
carpeta comúnmente accesible a todos los recursos de la organización. Contiene todos los
archivos seguros.
Ex: SVN- Sub Versión
VSS- Visual source safe
TFS- Servidor Team Foundation
CVS- Sistema de versiones concurrentes
Perforce, Github
Check in:El proceso de subir los archivos desde el sistema local al repositorio central se conoce
como Check in o Commit.

Check out:El proceso de descarga de los archivos desde el repositorio central al sistema local se
conoce como Check out.

Compilación:El proceso de convertir el código fuente en código ejecutable se conoce como

compilación.

5) Fase de pruebas:
Funciones:Ingenieros de pruebas
Equipo de desarrollo
Analista de negocio (BA)
Jefe de proyecto

 Una vez que el documento SRS esté alineado (completado), se enviará tanto al equipo
de desarrollo como al equipo de pruebas.
 El equipo de desarrollo es responsable de revisar el documento SRS, comprenderlo y
desarrollar la compilación.
 El equipo de pruebas también es responsable de revisar el documento SRS. Durante la
revisión, si se identifican requisitos poco claros (dudas), se actualizarán en el documento
denominado "Informe de revisión (RR)".
 El informe de revisión se enviará al jefe de equipo, que consolidará (en un único
documento) todos los informes de revisión en un único documento denominado
"Informe de revisión consolidado(CRR)" y lo enviará al BA.
 El BA es responsable de revisar todos los requisitos poco claros y de proporcionar las
aclaraciones necesarias. A continuación, se enviará el "Informe de revisión
actualizado(URR)" al equipo de pruebas.
 El equipo de pruebas revisará de nuevo el documento SRS con aclaraciones.
 Una vez que el equipo de pruebas tenga muy claros todos los requisitos, tomará la
plantilla de casos de prueba y escribirá los casos de prueba para todos los requisitos.
 Los documentos de los casos de prueba se enviarán al BA. Lo revisará y comentará si es
necesario añadir nuevos casos de prueba.
 Basándose en los comentarios de los BA, el equipo de pruebas actualizará los casos de
prueba.
 Una vez completados los casos de prueba, se enviarán al cliente para su revisión final.
 Una vez que la compilación se entrega al equipo de pruebas, éste ejecuta todos los
casos de prueba en la compilación.
 Mientras se prueba la compilación, si se identifica algún error se informará (enviará) al
equipo de desarrollo. El desarrollador lo corregirá y lo devolverá al equipo de pruebas
para que lo comprueben.
 El ingeniero de pruebas comprobará si el error se ha corregido realmente o no y, al
mismo tiempo, buscará otros errores.
 Si se identifica, se comunicará al promotor.
 El mismo proceso continuará hasta que la compilación sea estable (sin errores o con
errores).
 La versión estable se entregará al cliente.
 6) Entrega y mantenimiento:
Funciones:Ingenieros de pruebas
Equipo de desarrollo
Analista de negocio (BA)
Jefe de proyecto
Cliente

Entrega:Una vez que la compilación sea estable en el entorno de pruebas, el equipo de

pruebas (TL) enviará un correo electrónico al gestor del proyecto indicando que la compilación
es estable y, a continuación, el gestor del proyecto entregará la compilación al cliente.

 El cliente desplegará la compilación en el entorno escénico y realizará las pruebas.

 El entorno de pruebases el entorno común en el que el equipo de pruebas y el equipo
del cliente prueban la aplicación antes de que salga al mercado .
 Una vez que la compilación es estable en el entorno de escenario, el cliente desplegará
la compilación en el entorno en vivo o de producción.
 Una vez que la compilación se ha desplegado correctamente en el entorno de
producción/vivo, podemos concluir que el proyecto se ha entregado correctamente al
cliente.
Mantenimiento:
En vivo" significa que el cliente o los usuarios finales están utilizando la aplicación. El
mantenimiento continuará mientras la aplicación esté activa.

MantenimientoFase TAT
Corrección de
Cliente
Plazo de entrega errores, CR
BA/PM/TL
3 errores
(Mejora)
3 RC Empresa

12/24 horas 3 Bichos - 3 días

3 CRS - 4 días

7 días

 Una vez que el proyecto se haya entregado con éxito al cliente y se haya desplegado con
éxito en un entorno real/de producción, se iniciará el mantenimiento del proyecto.
 Durante el mantenimiento, la empresa es responsable de dos actividades.
a) Arreglar los fallos.
b) Actualización de las mejoras/solicitudes de cambio CRs.
 Mientras el proyecto esté en marcha, se continuará con su mantenimiento.
 Según el acuerdo inicial, la empresa ofrecerá mantenimiento gratuito durante un
periodo de 3 a 5 años (en función de la firma del proyecto).
 Una vez finalizado el periodo de mantenimiento gratuito, el cliente renovará el contrato
de mantenimiento.
  Siempre que el cliente envíe errores y CRS, alguien de la empresa (desarrollador, BA,
probador) debe enviar el correo electrónico de confirmación al cliente en el plazo
acordado según el acuerdo, que puede ser de 12 a 24 horas.
 El correo contiene el número de horas que vamos a tardar en arreglar y entregar la
nueva construcción al cliente.
 El mantenimiento del proyecto continuará mientras esté en marcha.

Q. ¿Qué tipo de aplicaciones ha probado?

TIPOS DE APLICACIONES:

Hay tres tipos de aplicaciones que se pueden probar;

1) Aplicaciones web
2) Aplicaciones de escritorio
3) Aplicaciones móviles

1) APLICACIONES WEB:

A estas aplicaciones se accede con la ayuda de algún navegador.

Es de dos tipos
a) Aplicaciones de arquitectura de 3 niveles.
b) Aplicaciones de arquitectura N-Tier.

Entorno/Sistema:

Todas las aplicaciones son combinaciones del entorno.

El medio ambiente contiene:
1. Capa de presentación.
2. Capa empresarial.
3. Capa de base de datos.
MEDIO AMBIENTE

SOLICITUD
CAPA DE PRESENTACIÓN/CLIENTE

Solicitar respuesta
SERVIDOR
CAPA DE NEGOCIO

Solicitar respuesta
BASE DE
DATOS CAPA DE BASE DE DATOS

1. Capa de presentación:

El Front end al que va a acceder el usuario final se conoce como capa de

presentación/cliente.

2. Capa empresarial:

Es el servidor el responsable de servir la petición. Esto significa que tomará la

petición de la aplicación, la enviará a la base de datos, tomará la respuesta de la
base de datos y la enviará de vuelta a la aplicación. Todo el proceso se conoce
como servir la solicitud.

Ej: Tomacat, JBoss, Weblogic, WebSphere, IIS

3. Capa de base de datos:

La capa de base de datos se encarga de almacenar los datos en forma de tablas.

Ej: MS SQL, My SQL, ORACLE

a) Aplicaciones de arquitectura de 3 niveles:

En las aplicaciones de arquitectura de 3 niveles, las 3 capas anteriores están disponibles en

tres máquinas diferentes (capas) que llamaremos niveles. De ahí que se denominen
aplicaciones de arquitectura de 3 niveles.

Ej: PL - Navegador
SErver - Tomacat
Base de datos - Oracle
b) Aplicaciones de arquitectura N-Tier:

Al igual que las aplicaciones de arquitectura de 3 niveles, en función del número de usuarios
(carga), tendremos más servidores y bases de datos.

En función de la carga solicitada, la lógica de negocio se distribuirá entre los servidores y las
bases de datos. De ahí que lo denominemos aplicaciones de entorno distribuido.

PL PL PL

Servidor Servidor Servidor

BL

DB DB DB

DBL

2) APLICACIONES DE ESCRITORIO:

Se puede acceder a estas aplicaciones sin necesidad de un navegador.

Por ejemplo: Skype, calculadora, MS Office, vlc player, etc.
Es de dos tipos:
 1 nivel
 2 niveles

 1-Tier:

Estas aplicaciones están limitadas a un sistema específico (PC). Las 3 capas PL, BL y DBL sólo
estarán disponibles en ese sistema específico.
Ej: VLC player , Calc

 2 niveles:
 La capa de presentación estará disponible en un sistema, la capa de negocio y la capa de
base de datos estarán disponibles en otro sistema, con la ayuda de LAN/WAN podemos
acceder a estas aplicaciones desde múltiples sistemas. Por lo tanto, las llamaremos
aplicaciones de 2 niveles, también conocidas como aplicaciones de arquitectura cliente-
servidor.
Por ejemplo: Skype

NOTA:Para Aplicaciones de Escritorio necesitamos instalar la aplicación en el lado del

usuario/cliente, entonces solo nosotros podremos acceder a ella. Para realizar pruebas de
aplicaciones de escritorio necesitamos realizarlas tanto en el cliente como en el servidor.

Para la aplicación Web, necesitamos probarla sólo en el cliente.

(BL)

Servidor + DBL

Aplicaci
ón

LAN WAN LAN

M1 M2 M3
PL

3) APLICACIONES MÓVILES:
Las aplicaciones a las que se puede acceder en la plataforma móvil se conocen como
aplicaciones móviles.
Por ejemplo: Android, IOS, Blackberry, Windows, etc.
Son de tres tipos

a. Aplicaciones nativas
b. Aplicaciones web
c. Aplicaciones híbridas

a. Aplicaciones nativas:

Se puede acceder a estas aplicaciones sin necesidad de un navegador.

Ej: Viber, funcionalidad de llamada, msg, reloj, etc.

b. Aplicaciones web:

Se puede acceder a estas aplicaciones con la ayuda del navegador del móvil.
Ej: selenium4testing.com

c. Aplicaciones híbridas:

Se puede acceder a estas Aplicaciones tanto sin navegador como con navegadores .
Por ejemplo: Gmail/aplicación de correo electrónico, Facebook/aplicación de Facebook, sitios
web/aplicaciones bancarias, etc.

NOTA:Para Aplicaciones Web no es necesario instalar la aplicación en el lado del usuario/cliente

ya que podemos acceder con la ayuda del navegador. Para realizar pruebas de aplicaciones web
necesitamos realizarlas sólo en cliente.

METODOLOGÍAS DE ENSAYO:

P:¿Quién es responsable de las pruebas? A qué nivel participará el ingeniero de pruebas en

las pruebas

Son de tres tipos

a. Pruebas de caja negra

b. Pruebas de caja blanca
c. Pruebas de caja gris

a. Pruebas de caja negra:

Si el recurso está realizando pruebas en la parte funcional de la aplicación, entonces

será tratado como "probador de caja negra".
La parte funcional se refiere a si la aplicación desarrollada se ajusta a los requisitos del cliente o
no. Los probadores realizarán pruebas de caja negra en un entorno de prueba y en un entorno
de preproducción.

b. Pruebas de caja blanca:

Si el recurso está probando la parte estructural (programación) de la aplicación,

entonces será tratado como "probadorde caja blanca".Los desarrolladores son responsables de
las pruebas de caja blanca en el entorno de desarrollo.

c. Pruebas de caja gris:

Si el recurso tiene experiencia en ambas pruebas (pruebas de caja blanca y pruebas de

caja negra). Entonces será tratado como "Probador de caja gris".

NIVELES DE PRUEBAS:
Si un proyecto tiene que pasar de la fase de aprobación a la de producción, debe someterse a
los siguientes niveles de pruebas.

1) Pruebas unitarias
2) Pruebas a nivel de módulo
3) Pruebas de integración
4) UAT (Pruebas de aceptación del usuario)
5) Pruebas del sistema

1) Nivel unitario de las pruebas: Porunidad se entiende el flujo o escenario más pequeño
de la aplicación.
 El desarrollador es responsable de las pruebas a nivel de unidad.
 Dividirá el módulo asignado en varias unidades y desarrollará el código de todas
ellas.
 Es responsable de comprobar si todas y cada una de las unidades funcionan
como se espera o no.

2) Pruebas a nivel de módulo:

 De las pruebas a nivel de módulo son responsables tanto el equipo de pruebas
como el equipo de desarrollo.
 El desarrollador combinará todas las unidades relacionadas para formar un
módulo.
  Una vez desarrollado el módulo, el desarrollador es responsable de las pruebas
de caja blanca en el entorno de desarrollo.
 Una vez que el módulo se entrega al equipo de pruebas, éste se encarga de
realizar las pruebas de caja negra en el entorno de pruebas.

3) Pruebas a nivel de integración:

 El proceso de combinar todos los módulos desarrollados se conoce como
integración.
 Comprobar si el flujo de datos pasa de un módulo a otro se conoce como prueba
de nivel de integración.
 Tanto el equipo de desarrollo como el de pruebas son responsables de las
pruebas a nivel de integración.
Ejemplo: Cree una cuenta en Gmail y compruebe si puede iniciar sesión en la
aplicación con la cuenta creada. A continuación, redacte el correo y envíelo,
compruebe si se ha entregado correctamente o no.
 Durante la integración, si falta algún módulo obligatorio, el jefe de desarrollo
sustituirá el módulo obligatorio por un código ficticio conocido como stub o
driver.

D1 D2 D3 D4 D5
+ + + + +
Credenciales de acceso Componga Enviar Cierre
de sesión

Stub/Driver:Ambos no son más que un código ficticio, no contiene ninguna

funcionalidad.

 Si el jefe de desarrollo utiliza un enfoque descendente para integrar los módulos,

si falta algún módulo obligatorio durante la integración, será sustituido por Stub.
  Si el jefe de desarrollo utiliza un enfoque ascendente para integrar los módulos,
durante la integración si falta algún módulo obligatorio lo sustituirá por Driver.

4) Pruebas de aceptación del usuario:

 Se conoce como prueba de aceptación del usuario/cliente. Una vez que la versión
sea estable en el entorno de pruebas, planearemos entregarla al cliente. Antes
de entregar la compilación al cliente, éste enviará los casos de prueba de
aceptación del usuario al equipo de pruebas para su ejecución.
 El equipo de pruebas ejecutará todos los casos de prueba de la UA en el entorno
de pruebas; si se superan todos, el gestor del proyecto entregará la compilación
al cliente.
 El cliente ejecutará de nuevo todos los casos de prueba UA en el entorno del
cliente (entorno de escenario). Si todos son aprobados, el cliente desplegará la
compilación en el entorno Live o Production.
 La UAT es de dos tipos:

a.Pruebas alfa
b. Pruebas beta UAT

Pruebas alfa Pruebas beta (UATCS)

(UATCs) Entorno de pruebaEntorno de escenario

 a. Pruebas alfa: La ejecución de todos los casos de prueba de la UA en un entorno de
prueba por parte del equipo de pruebas se conoce como "pruebas alfa".

b. Pruebasbeta:La ejecución de todos los casos de prueba de la UA en el entorno del

cliente por parte del equipo del cliente o del equipo de pruebas se conoce como
"pruebas beta".

Una vez superadas las pruebas beta, el cliente pasará al entorno real.

Entorno de prueba Cliente

Pase de construcción (UATCS)

Equipo de pruebas Inicio
Entregar

UATCS

5) Pruebas del sistema:

 También se conoce como prueba no funcional. Una vez que la aplicación es
estable, podemos pasar a las pruebas no funcionales.
 En las pruebas no funcionales se identificará el rendimiento (tiempo de
respuesta) de la aplicación.
 El tiempo transcurrido entre la solicitud y la respuesta se conoce como tiempo de
respuesta. Se identificará con la ayuda de múltiples tipos de pruebas no
funcionales como pruebas de carga, pruebas de rendimiento, pruebas de estrés,
pruebas de punto de ruptura.
MODELOS DE DESARROLLO DE SOFTWARE:
Q. ¿Qué proceso ha seguido para desarrollar su proyecto?

Los modelos son los siguientes.

1) Modelo en cascada
2) Modelo en espiral
3) Modelo V
4) Modelo de pez
5) Proceso ágil

1) Modelo en cascada:
Fue el proceso o modelo inicial introducido para el desarrollo de software (proceso
antiguo). La ejecución secuencial de todas las fases del SDLC se conoce como modelo de
caída de agua. Una vez finalizada la fase, la dirección de alto nivel analizará dicha fase.

NOTA: Como cascadas de un nivel a otro, de la misma manera se implementarán

las fases del SDLC.

Ventajas:

 Es muy fácil poner en marcha el proyecto porque es de Ejecución Secuencial.

Desventajas:
  El riesgo térmico no puede identificarse en la fase inicial del ciclo de vida, por lo
que no puede prevenirse.
 Es un proceso largo y costoso.
 No podemos aceptar que los requisitos cambien en mitad del proyecto. Si aún
así es necesario aceptarlo, aceptaremos el cambio de requisitos en forma de
solicitudes de cambio (CR). Las solicitudes de cambio se realizan al final del
proyecto y las CR corren a cargo de la empresa.

mes

2) Modelo en espiral:

 El modelo en espiral es una combinación del modelo en cascada y el prototipo.

  En lugar de recopilar todos los requisitos de una vez, el BA recopila unos pocos
requisitos, que se analizarán y diseñarán con ayuda del prototipo. Luego se
entregará al desarrollo.
 Una vez que el desarrollador desarrolle la compilación, se entregará al equipo de
pruebas. Se seguirá el mismo proceso para todos los requisitos.
 Una vez que se hayan cumplido todos los requisitos y la versión sea estable, se
entregará al cliente.

Ventajas:

 Podemos ahorrar tiempo y costes porque ejecutamos todas las fases en paralelo.
 El riesgo puede identificarse en la fase inicial del SDLC y puede prevenirse en la fase
inicial del ciclo de vida.
 El cambio de requisitos puede aceptarse en mitad del proceso.

Desventajas:

 El riesgo de entrega es enorme, debido a los plazos agresivos (menos tiempo).

 No puede aceptar el cambio de requisitos en la fase final del proyecto para evitar el
riesgo de entrega.

3) Modelo V (modelo de verificación y validación):

Validación:
 También se conoce como "QC" (control de calidad). El equipo de pruebas es
responsable de la validación. El equipo de pruebas comprobará si el software
desarrollado cumple o no los requisitos del cliente.

Los ingenieros de pruebas son validadores.

Verificación:

Def1: Comprobar si todos y cada uno de los documentos de resultados de las fases se
ajustan o no a las directrices de la empresa y del cliente.

Def2:Compruebe si todas y cada una de las funciones de la organización funcionan de acuerdo

con los
Empresas y clientes líneas directrices o no. La verificación también se conoce como QA
(Quality assurance).

El grupo de gestión de proyectos/procesos (GGP) o el grupo de auditoría son los responsables

de laverificación.

 A partir del modelo V, incluso el equipo de pruebas participará en la recopilación de

requisitos.
 El BA se encarga de recopilar los requisitos, mientras que el equipo de pruebas los
analiza para comprobar si es posible probarlos o no.
 Una vez definido el SRS, el equipo de validación es responsable del plan de pruebas.
 A partir de las fases de análisis y diseño, el equipo de validación prepara el plan de
pruebas del sistema y el plan de diseño.
 Una vez desarrollado el código, se entregará al equipo de pruebas, que realizará
todos los niveles de comprobación. Una vez que la versión sea estable, se entregará
al cliente.

Ventajas:

 Las actividades de comprobación se inician a partir de la fase de requisitos para

garantizar la calidad.
  El equipo de verificación y validación comprobará cada una de las fases para
garantizar la calidad.
 El riesgo puede detectarse en una fase temprana porque tenemos una actividad
paralela de pruebas, así que puede prevenirse.
 Podemos aceptar el cambio de requisitos a mitad de la fase.

Desventajas:

 Es un proceso largo y costoso, pero podemos garantizar la calidad.

4) Modelo de pez:

 Es igual que el modelo V.

 En el modelo de pescado contaremos con varios equipos de verificación del cliente y
la empresa para comprobar el proceso y proporcionar más calidad y seguridad.
 Es más caro que el modelo en V.
 Proporciona más seguridad y se aplica en proyectos de seguridad de alto nivel como
la NASA, la Fuerza Aérea, la Marina, el Ejército, etc.
Nota: El equipo de validación revisará los resultados de las pruebas unitarias cuando
la compilación esté en desarrollo.
5) Proceso ágil:

 Tiene múltiples submodelos, como el modelo adaptativo, Scrum, iterativo, etc. El

modelo que vamos a utilizar es el modelo Scrum.
 Se trata de un modelo iterativo e incremental. El modelo Scrum tiene las siguientes
actividades.
a. Scrum master
b. Historias de usuarios
c. Scrum meeting/scrum calls/DSM
d. Plan Sprint
e. Reunión Sprint
f. Atrasos

a. Scrum master:

El scrum master es quien va a dirigir el proyecto. El director del proyecto o el cliente

actuarán como scrum master. El Scrum Master es responsable de las reuniones del
Scrum y de las reuniones de los sprints.

b. Historias de usuarios:
Los requisitos se plasmarán en forma de flujos utilizados por el usuario final (vías
utilizadas por el usuario final). De ahí que lo llamemos historias de usuario. BA es
responsable de recoger

c. Reunión Scrum:

 Diariamente, todos los miembros del equipo participarán en una reunión rápida
en la que se describirán las actividades realizadas ayer y las tareas previstas para
hoy, así como si existe algún reto.
 Todos los miembros del equipo, incluidos el scrum master y el cliente, tienen que
describir.
 El objetivo principal de la reunión de scrum es hacer un seguimiento de los
recursos y mantener la transparencia.

d. Plan Sprint:

 Sprint es un periodo de tiempo fijo que puede ser de una semana, dos semanas,
tres semanas, etc. Lo decidirá el scrum master.
 El plan del sprint consiste en recopilar las historias de los usuarios, analizarlas,
desarrollarlas, probarlas y entregarlas al cliente.
 Si durante el sprint no somos capaces de completar alguno de los requisitos, el
sprint no se ampliará. Y los requisitos pendientes deben trasladarse al siguiente
sprint. Sprint es un periodo de tiempo fijo

e. Reunión Sprint:

Una vez finalizado el sprint, se decidirá el plan del siguiente sprint en la reunión del
sprint. Debatirán si el sprint actual se ha llevado a cabo con éxito o no, si se ha
afrontado algún reto.

f. Atrasos:

Durante el plan de sprints, si alguna historia de usuario no se puede llevar a cabo, se

tomará como Backlogs. Estos backlogs deben completarse en el siguiente sprint.

Es de dos tipos,

(i) Lista de productos pendientes

(ii) Sprint backlog
 Backlog del producto: Los Requisitos (historias de usuario) que vamos a recoger,
desarrollar, probar y entregar al cliente como parte del plan de sprints se conoce
como backlogs de producto.
Sprint Backlog: Los requisitos que no se completen como parte del plan del
sprint se tratarán como backlog del sprint.

Ventajas:

 Todos y cada uno de los sprint serán probados varias veces por el equipo de pruebas y el
cliente, de modo que podamos garantizar la calidad.
 Todas las fases del SDLC se realizan en paralelo y así podemos ahorrar tiempo y costes.
 El cambio de requisitos puede aceptarse en cualquier fase del proyecto (incluso después
de la entrega del sprint).
 El riesgo puede detectarse en una fase temprana y prevenirse
 Podemos mantener la transparencia del proyecto.
 El cliente también participará en las reuniones scrum, por lo que podemos obtener la
información muy rápidamente.
 Todos y cada uno de los sprints se entregan al cliente, por lo que no tenemos riesgo de
entrega.
 Podemos conseguir la satisfacción del cliente entregando todos los sprints al cliente.
 El sprint también se conoce como iterativo. Es un modelo iterativo e incremental
Desventajas:

Mantener toda la información relacionada con el sprint es una tarea muy difícil, pero podemos
superarla con la ayuda de herramientas de gestión de pruebas como Scrum wise, Quality
center, JIRA y test link etc.

Tipos de pruebas funcionales (o) Tipos de pruebas de caja negra :

1) Pruebas de humo:

 Una vez desarrollada la compilación y desplegada en cualquier entorno, se realizarán las

pruebas iniciales, conocidas como pruebas de humo. Inicialmente, el equipo de
desarrollo desplegará la compilación en el entorno de desarrollo y realizará una prueba
de humo. Comprobarán que todos y cada uno de los campos relacionados con los
módulos navegan correctamente por sus páginas o no y comprueban la funcionalidad
principal de la aplicación. El objetivo de la prueba de humo es comprobar si la
compilación está lista o no para las pruebas posteriores. El desarrollador se concentrará
en las pruebas de caja blanca
 Si todos estos campos navegan correctamente a las páginas relacionadas, entonces
concluirán que se ha superado la prueba de humo.

2) Pruebas de cordura:
 Una vez desplegada la compilación en el entorno de pruebas, el equipo de pruebas
realizará la prueba de humo en el entorno de pruebas. Es lo que se conoce como prueba
de cordura.
 En la prueba de sanidad, el equipo de pruebas realizará al menos una ronda de la
funcionalidad del flujo principal y comprobará si funciona correctamente o no.
 Si se supera la prueba de sanidad, el equipo de pruebas ejecutará todos los casos de
prueba y, si falla, rechazará la compilación al equipo de desarrollo.

Ejemplo para el flujo principal: Crear una cuenta en Gmail e iniciar sesión en esa cuenta
y redactar un correo electrónico y enviarlo a un correo electrónico válido y comprobar
que si se entrega correctamente o no.

Nota:Una vez realizada la prueba de sanidad, el equipo de pruebas (jefe de pruebas) debe
enviar un correo electrónico con los resultados de la prueba de sanidad al equipo de desarrollo.
 3) Pruebas previas a la SRN:SRN - Notas de la versión del software

 Contiene el estado de la compilación, como el número de módulos disponibles en la

compilación para las pruebas.
 Número de módulos en desarrollo.
 Número de stubs y controladores disponibles en la compilación.
 Número de errores corregidos y disponibles en la versión.
 Número de errores que están en desarrollo
 Directrices de despliegue, etc.

 Antes de entregar el documento SRN junto con la compilación al equipo de pruebas,

el equipo de pruebas realizará la prueba de humo en el entorno de desarrollo, lo que
se conoce como Prueba Pre-SRN.
 También se conoce como pruebas de aceptación de la construcción (BAT) o pruebas
de verificación de la construcción (BVT).

Nota: Una vez que la compilación se entrega al equipo de pruebas, los ingenieros de pruebas
revisarán el documento SRN para conocer el estado de la compilación (qué contiene). A
continuación, se realizará la prueba de cordura.

2. En primer lugar, el equipo de desarrollo realizará las pruebas de humo y, a continuación, el

equipo de pruebas realizará las pruebas previas a la SRN en el entorno de desarrollo. Si ambos
son correctos, el equipo de desarrollo entregará la compilación al equipo de pruebas, que
realizará las pruebas de sanidad.
 4) Pruebas GUI/UI:
Prueba de la interfaz gráfica de usuario/interfaz de usuario: las cinco actividades siguientes se
probarán en la interfaz gráfica de usuario.

 Compruebe la ortografía de todos los campos.

 Compruebe la fuente de todos los campos en los que debe mantener la coherencia.
 Compruebe el color y las alineaciones de todos los campos que debe mantener la
coherencia.
 Compruebe el aspecto general de la página

5) Pruebas de regresión:

La realización de pruebas sobre funcionalidades ya probadas en las compilaciones iterativas e

incrementales se conoce como "pruebas de regresión".

Se realizará de dos maneras:

 Cada vez que se detecte un error, se informará al desarrollador, que lo corregirá y lo

publicará en forma de nueva compilación (Build2) para el equipo de pruebas, que lo volverá
a probar para comprobar si el error se ha corregido realmente o no.
 Los casos de prueba aprobados en la versión anterior se ejecutarán de nuevo en la
nueva versión y se comprobará si funcionan igual que antes o no.
 La prueba de funcionalidades ya probadas es regression testing. Probar las nuevas
funcionalidades no es la prueba de regresión. Forma parte de la ejecución de casos de
prueba.

Nota:Si hay alguna actualización de código, entonces ese nuevo código puede afectar al
código existente, por lo que estamos realizando las pruebas de regresión.

6) Reexamen:

 Realizar pruebas sobre las mismas funcionalidades una y otra vez con múltiples
conjuntos de datos de prueba diferentes en la misma compilación se conoce como
"Repetición de pruebas".
 La ejecución de los casos de prueba fallidos en las compilaciones iterativas e
incrementales también se conoce como "Re testing".

Datosde prueba:los datos que el equipo de pruebas utiliza para realizar las pruebas se
denominan "datos de prueba".

Ex: 1. Probar la funcionalidad de inicio de sesión de Gmail con varios conjuntos de

diferentes credenciales.

2. Pruebe la búsqueda unidireccional de spicejet con los conjuntos múltiples de

diferentes orígenes y diferentes pasajeros.

P: ¿Cuál es la diferencia entre pruebas de regresión y repetición de pruebas?

P: ¿Cuál es la diferencia entre las pruebas de regresión y las pruebas de

integración?

7) Pruebas de extremo a extremo:

El ingeniero de pruebas tiene que identificar todos los escenarios utilizados por el usuario final
de la aplicación y comprobar si los escenarios de extremo a extremo funcionan correctamente
o no.

Realizando pruebas de extremo a extremo podemos lograr pruebas de nivel de integración

Ejemplo: El escenario de extremo a extremo de Gmail.

 8) Pruebas de compatibilidad:

 Comprobar si la aplicación funciona como se espera en todos los entornos se conoce

como "prueba de compatibilidad". El entorno es una combinación de sistema operativo,
navegador, servidor, base de datos, etc.
 Las pruebas de compatibilidad son de dos tipos: "pruebas entre navegadores " y
"pruebas entre plataformas".
 Comprobar si la aplicación web funciona como se espera en todos los navegadores de
destino como Firefox, Safari, Google Chrome, IE, etc. se conoce como "prueba de
navegador cruzado".
 Probar si la aplicación de escritorio funciona como se espera en diferentes plataformas
o sistemas operativos como Windows, LINUX, MAC, Solaris, etc. se conoce como
"prueba de plataforma cruzada".

Ex para Cross browser testing: Compruebe si el spicejet funciona o no en los siguientes

entornos.

Windows - Internet explorer, Firefox, Google chrome, Safari, Opera

Linux - Internet explorer, Firefox, Google chrome, Safari, Opera

MAC - Firefox, Google chrome, Safari, Opera

Ex para pruebas multiplataforma:Comprueba si Skype funciona en las siguientes plataformas o

entornos
 Windows
Linux
MAC y móvil

Nota: Cuando realizamos pruebas de compatibilidad, debemos concentrarnos más en la

interfaz gráfica de la aplicación.

9) Pruebas de usabilidad:

 Usabilidad significa facilidad de uso. El ingeniero de pruebas tiene que proporcionar

usabilidad a la aplicación para la satisfacción del usuario final.
 Depende de la aplicación que tengamos que proporcionar la usabilidad.

Por ejemplo: para aplicaciones bancarias (seguras) tenemos que ofrecer más seguridad,
mientras que para sitios sociales (Face book, twitter), tenemos que ofrecer más facilidad de
uso.

10) Pruebas ad hoc:

 Adhoc significa a nuestra manera.

 Pruebas ad hoc significa probar la aplicación a su manera, después de entender todos
los requisitos y al menos una ronda de pruebas manuales se ha completado en la
aplicación.
  El objetivo principal de las pruebas ad hoc es proporcionar usabilidad a la aplicación.

11) Pruebas exploratorias:

 Exploratorio significa identificar el nuevo requisito / la nueva característica. Una vez que
la compilación sea estable, los expertos probarán la aplicación de acuerdo con sus
conocimientos del sector. Durante las pruebas, comprobarán si los requisitos existentes
son suficientes y, si no lo son, proporcionarán nuevos requisitos.
 El objetivo principal de las pruebas exploratorias es proporcionar usabilidad y seguridad
a la aplicación.

12) Pruebas con monos/pruebas con gorilas:

 Una vez que la aplicación es estable entonces podemos ir para la prueba del mono.
 Realizar pruebas en la aplicación haciendo algunasacciones anormales se conoce como
pruebas Mono/Gorila.
 Acciones anormales significa hacer clic continuamente en algún campo durante un largo
período de tiempo y comprobar si la aplicación se bloquea o no.
 Pruebe la aplicación con datos no válidos como etiquetas HTML (<html>) y compruebe si
la aplicación se bloquea o no.
Nota: El objetivo del monkey testing es comprobar si la aplicación se bloquea o no
(Means obtendrá la excepción server not found)

13) Pruebas estáticas:

 Probar la aplicación sin realizar ninguna acción se conoce como prueba estática.

Ex:1. Pruebas GUI

2. Validaciones: la comprobación de la disponibilidad de los campos en la página
forma parte de las pruebas estáticas.

14) Pruebas dinámicas:

 Probar la aplicación realizando alguna acción se conoce como prueba dinámica.

Por ejemplo: pruebas de regresión, repetición de pruebas, pruebas ad hoc, etc.

 15) Pruebas de autenticación:

 Autenticación significa comprobar si las credenciales/datos protegidos están

disponibles en la base de datos o no.
 Prueba de autenticación significa probar la aplicación con múltiples conjuntos de
datos válidos e inválidos, para los datos válidos debe mostrar la página de inicio,
mientras que para los datos inválidos, debe mostrar el mensaje de autenticación
adecuado (mensaje de error).

Ejemplo: Pruebe la funcionalidad de inicio de sesión de HMS con varios conjuntos de

credenciales válidas e inválidas. Tiene que autenticar la aplicación correctamente.

16) Pruebas de URL directas:

 Inicie sesión en una página segura y tome la URL de la página segura y acceda a esa
URL en un nuevo navegador. Donde no debería ser accesible si es accesible entonces
la aplicación no es segura.

Ej: Entra en Gmail.com, copia la URL de la página de inicio. Abrir en un nuevo navegador y
acceder directamente a la URL, donde no debería ser accesible.

17) Pruebas de fugas en cortafuegos:

 Inicie sesión en la aplicación como un nivel de usuario e intente acceder a los datos
más allá de la limitación de su rol. Si es accesible, entonces concluimos que la
aplicación no está funcionando según el rol (tiene la fuga del firewall).

Ej: Accede a la aplicación HMS como Jr. Doctor y tratar de acceder a los datos de
Sr. Médico, donde no debería ser accesible

18) Pruebas de bases de datos:

  Comprobar si los datos se insertan correctamente en la base de datos de todas las
tablas o no se conoce como prueba de base de datos. Con la ayuda de consultas SQL
podemos realizar pruebas de BD.

Ejemplo: Cuando creamos un registro permanente en HMS, todos los datos del
paciente se almacenan en la base de datos de HMS. Como ingeniero de pruebas,
tenemos que iniciar sesión en la base de datos y comprobar si los datos se han
insertado correctamente en todas las tablas o no.

Pruebas de despliegue/pruebas de instalación: El equipo de despliegue o

el jefe de pruebas desplegará la compilación en varios entornos, como desarrollo,
pruebas, fase 1, fase 2, producción, etc., y comprobará si se despliega correctamente
o no.

P: Una vez publicada la compilación, ¿cómo la probará?

R: Inicialmente vamos a realizar pruebas de sanidad, si se pasa a continuación, vamos a

ejecutar todos los casos de prueba a continuación, llevará a cabo todos los tipos de pruebas
funcionales como below.By la realización de todas las pruebas a continuación, podemos
garantizar la calidad de la aplicación
Tipos de pruebas funcionales: flujo de ejecución de las pruebas funcionales en la compilación,
una vez que se entrega al equipo de pruebas.

Nota: Para cualquier aplicación, todas las pruebas anteriores se llevarán a cabo para
garantizar si la aplicación cumple con los requisitos de los clientes, la calidad y su
utilidad para el usuario final o no.

2. Si se trata de una aplicación de escritorio, no es posible realizar pruebas directas de

URL ni pruebas entre navegadores.

Plantilla de informe de revisión:

Revise el documento SRS de spice jet y proporcione el informe de revisión en la plantilla
siguiente.

Requisito ID Requisito Comentarios por TE Comentarios

Descripción
7. Caída de adultos, niños y bebés 1. ¿Cuál es la diferencia entre

Los Downs deberían estar disponibles. Niños, adultos y bebés

2. ¿Qué valores tienen los campos de adultos, niños

y bebés?

19) Pruebas de globalización:

Se trata de dos de los tipos

a. Pruebas de localización.

b. Pruebas de internacionalización.

a. Pruebas de localización:

 Probar la aplicación en todos los idiomas locales que son selectivos para
nuestro país como el hindi, bengalí, telugu, etc se conoce como pruebas
de localización.
 Admite un máximo de 10 idiomas para una única integración. De ahí que
la llamemosprueba"L10N".

Ex:1. Prueba Google.co.in en todos los idiomas locales, como hindi, bengalí,
telugu, etc.

2. Pruebe el cajero automático en idiomas locales como el hindi, el telugu y el inglés.

b. Pruebas de internacionalización:

 Probar la aplicación en todos los idiomas internacionales como el

japonés, el chino, el español, etc. es lo que se conoce como pruebas de
internacionalización. Admite un máximo de 18 idiomas para una sola
integración. De ahí que lo llamemospruebas "I18N".

Ejemplo: Prueba Gmail.com en todos los idiomas internacionales como

japonés, español, chino, etc.

CICLO DE VIDA DE LAS PRUEBAS DE SOFTWARE:

Contiene las siguientes fases:

1) Plan de pruebas de software.

2) Diseño de pruebas de software.
 3) Ejecución de la prueba.
4) Análisis de resultados.
5) Informes y BLC.
6) Entrega y mantenimiento.
7) Informe resumido de la prueba/ Informe postmortem de la construcción.

1. Plan de pruebas de software:

 Un plan es un documento estratégico que describe cómo realizar una tarea de forma
eficaz y eficiente.
 El plan de pruebas de software también es un documento estratégico que describe
cómo realizar las pruebas de forma eficaz y eficiente. El plan de pruebas será elaborado
por el jefe de pruebas; una vez preparado, se enviará al equipo de pruebas para su
revisión.
 Basándonos en el plan de pruebas, somos responsables de realizar las pruebas.
 Contiene las siguientes actividades o Índice.

Plan de pruebas Índice

1. Objetivo

1.1 Alcance de las pruebas

2. Documentos de referencia

3. Elementos de prueba

3.1 Características que deben comprobarse

3.2 Características que no deben probarse

4. Estrategia de ensayo

4.1 Tipos de pruebas

4.1.1 Tipos de pruebas funcionales

5. 5. Entorno de prueba

6. Criterios de aprobado/reprobado

7. Análisis y cierre de defectos

8. Resultados de las pruebas

9. Pruebas de automatización

10. Riesgos e imprevistos

11. Requisitos de hardware y software

12. Plan de recursos

13. 13. Informe resumido de la prueba/Informe postmortem de la construcción.

1. Objetivo:

A continuación se describe el objetivo principal del plan de pruebas. Contiene el alcance de las
pruebas.

1.1 Alcance de las pruebas:

Los tipos de pruebas que el equipo de pruebas debe realizar en la aplicación se conocen
como alcance de las pruebas.

Por ejemplo: el equipo de pruebas se encarga de las pruebas manuales y de la

automatización del proyecto.

2. Documentos de referencia:

A continuación se describe la lista de documentos que el jefe de pruebas ha utilizado para

preparar el plan de pruebas.

El jefe de pruebas utilizará los documentos SRS para preparar el plan de pruebas.

3. Elementos de prueba:

3.1 Características que deben probarse:

Aquí se describirá la lista de funcionalidades o módulos de los que es responsable el

equipo, así como la lista de pruebas que el equipo de pruebas realiza en los módulos.

Ejemplo: El equipo de pruebas es responsable de reservar un vuelo, un hotel y la gestión

de la reserva.

Para los módulos anteriores son responsables de las pruebas manuales y la

automatización.

3.2 Características que no deben probarse:

 Aquí se describe la lista de módulos y pruebas de los que no es responsable el equipo de
pruebas.

Por ejemplo: el equipo de pruebas no es responsable de los módulos de pago ni de las

pruebas de rendimiento, las pruebas de carga o las pruebas de estrés.

4. Estrategia de prueba:

Estrategia significa la lista de pasos que vamos a dar para cumplir el plan.

 Por estrategia de pruebas se entiende la lista de tipos de pruebas funcionales. Lo que el

equipo de pruebas va a tomar para realizar las pruebas se conoce como estrategia de
pruebas.
 Realizaremos todos los tipos de pruebas funcionales como regresión, re pruebas, etc...
en la aplicación
 En pocas palabras, planificar significa qué hacer. Estrategia significa cómo lograr el plan.

5. Entorno de prueba:

Entorno significa el sistema que vamos a utilizar para desplegar la construcción y para
probar la aplicación se conoce como el entorno de prueba.

Ej:Tipo de máquina : Windows server enterprise

SO : Windows
Procesador : CPU Intel Xeon
Memoria : 4GB/2.13 GHZ
Disco duro : 150 GB
Base de datos : Microsoft SQL server 2008 standard edition
Servidor web : IIS 7.0
Cliente : Microsoft internet explorer, Firefox, Google chrome

6. Test pass fail/criteria:

Si algún caso de prueba se desvía del resultado esperado, se tratará como fallo o error.

Cada fallo tiene el criterio o tipo de fallo.

Es de cinco tipos

a. Bloqueador
b. Muy alta
c. Alta
d. Medio
e. Bajo
7.Cierre del análisis de defectos:

En el momento de la entrega de la compilación, el equipo de pruebas y el director del proyecto

analizarán si existen errores o defectos. Si no es necesario corregir algún fallo, se cerrará.

8. Resultados de las pruebas:

La lista de módulos que vamos a entregar al cliente se conoce como entregables.

Todos los módulos se dividirán en varias fases y el responsable indicará el plazo previsto (fecha
de entrega).

Plazos (Fecha de
Fase No Módulos entrega)

1. BookaFlight
2. ManageMy Booking
1 3. Estado PNR 30 de junio

2 4. Horarios de vuelo 31 de julio

5. Beneficio empresarial

3 6. Conectar especias 30 de septiembre

9. Pruebas de automatización:
Aquí se describirá el número de módulos que el equipo de pruebas va a automatizar, así como
la herramienta de automatización y la estrategia que van a seguir los ingenieros de pruebas.

10. Riesgos e imprevistos:

Aquí se describirá la lista de riesgos a los que se enfrentará el equipo durante la ejecución del
proyecto, así como la solución correspondiente.

Riesgos Imprevistos
Mantener los recursos de
Déficit de recursos reserva

Cambios continuos en los requisitos Analizar los requisitos

Supervisar las revisiones

Falta de revisiones inter pares inter pares

11. Requisitos de hardware y software:

Aquí se describirá el número de máquinas como portátiles, móviles, impresoras, etc...

necesarias para las pruebas con el software correspondiente.

12. Plan de recursos:

Aquí se describirá el número de recursos necesarios para las pruebas manuales, las pruebas de
automatización y las pruebas de bases de datos.

13. 13. Informe resumido de la prueba/Informe postmortem de la construcción:

Una vez finalizadas las pruebas, el jefe de pruebas debe preparar el informe de resumen de las
pruebas, que contiene el resumen de las pruebas.

2) Diseño de pruebas de software:

El proceso de escribir los casos de prueba en la plantilla de casos de prueba después de
comprender todos los requisitos se conoce como "diseño de pruebas de software".
  Cada organización tendrá su propia plantilla basada en esa plantilla; el ingeniero de
pruebas es responsable de escribir los casos de prueba.
 Tenemos las siguientes plantillas para escribir los casos de prueba. Contiene la portada,
los casos de prueba, los datos de prueba, la matriz de trazabilidad y el informe de
prueba.

Requisito- prioridad TC Prueba Pre- Prueb Actual Previsto Resulta Comentari

Prueba ID escenari producció a Resulta Resultad do os
Tipos o n tipos do o

ID

Portada:

Nombre del módulo :

Nº total de casos de prueba :

Nº de casos de prueba P1 :

Nº de casos de prueba P2 :

Nº de casos de prueba P3 :

Nº de casos de prueba P4 :

ID de requisito: Aquí se describirá el número de requisito para el que estamos escribiendo los
casos de prueba.

Tipos de prueba: El tipo de caso de prueba se conoce como tipo de prueba. Es de cinco tipos.

 GUI
 Validación
 Caso de prueba positivo (o) Caso de prueba positivo funcional.
 Caso de prueba negativo (o) Caso de prueba negativo funcional
 Caso de prueba de base de datos

Caso de prueba positivo: Probar la aplicación con todos los datos válidos se conoce
como caso de prueba positivo.
 Caso de prueba negativo: Probar la aplicación con al menos un dato no válido se conoce
como caso de prueba negativo.

Prioridad: Describe la importancia del caso de prueba: P1, P2,P3 y P4.

P1: Si el caso de prueba describe la funcionalidad principal de la aplicación/módulo, se

tratará como P1.

La funcionalidad principal significa que si el caso de prueba falla no podemos

continuar la prueba, por lo que la prioridad es "P1".

P2: Si el caso de prueba describe la funcionalidad a nivel de campo, la prioridad es "p2".

El caso de prueba a nivel de campo significa que, si falla, podemos continuar las
pruebas, pero es importante que esté presente en la aplicación según los requisitos del
cliente.

P3: Todos los casos de prueba GUI tienen prioridad P3.

P4:El ingeniero de pruebas tiene la opción de dar sugerencias a la aplicación. Esas

sugerencias se plasmarán en forma de casos de prueba y la prioridad será "P4".

ID del caso de prueba: Aquí se describirá el número de serie del caso de prueba.

Escenario de prueba:Escenario significa un flujo o la forma utilizada por el usuario final. El

requisito se dividirá en todos los flujos o escenarios utilizados por el usuario final, que se
describirán aquí. El ingeniero de pruebas tiene que identificar el máximo de flujos posibles para
el requisito o historia de usuario.

Precondición:Aquí se describirá la condición necesaria para probar el escenario.

Pasos de la prueba:Aquí se describe la lista de pasos necesarios para ejecutar el escenario. En

función de los pasos de la prueba, el ingeniero de pruebas la ejecutará en la aplicación o
compilación.

Resultado esperado:En el momento de escribir los casos de prueba no tendremos la aplicación

con nosotros. Así que estaremos esperando el resultado para el escenario. El resultado
esperado se actualizará en la columna de resultados esperados.

Resultado real:Se actualizará en el momento de ejecutar los casos de prueba. El ingeniero de

pruebas observará el comportamiento real de la aplicación para el escenario y se actualizará
aquí.
Resultado:Una vez finalizada la ejecución de la prueba, el ingeniero de pruebas comparará el
resultado real con el resultado esperado, si ambos coinciden, entonces actualizará el resultado
como correcto, si no, lo actualizará como incorrecto.

Comentarios:El BA o el cliente proporcionarán aquí los comentarios.

Consulta el documento TC de inicio de sesión de Gmail

Técnicas de diseño de pruebas:

Para realizar pruebas de forma eficaz y eficiente, debemos seguir las siguientes técnicas
de diseño de pruebas.

1. Análisis del valor límite (BVA)

2. Partición de clases de equivalencia (PCE)

3. Adivinar errores

1. Análisis del valor límite (BVA):

Cuando tenemos la necesidad de probar el rango como 1 a 100 o 1 a 1000 o 1 a 1 falta

o 1 falta a 2 faltas entonces no es posible realizar la prueba exhaustiva (prueba
completa). Así que tenemos que aplicar la técnica BVA.

 Divide el rango en múltiples límites como mín-1, mín, mín+1, medio, máx-1, máx
y máx+1.
 Para realizar la prueba positiva, pruebe el campo con min, min+1, medio, max-1
y max. Donde debe aceptar. (Su caso de prueba +ve)
 Para realizar pruebas negativas, pruebe el campo con min-1 y max+1. Donde no
debe aceptar. (Su -ve Caso de prueba)
 Si funciona según lo anterior, entonces podemos concluir que está aceptando
sólo el rango.
+Ve Escenario de Prueba: Verificar el campo con los límites como min, min+1, middle, max-1, y
max

-Ve Escenario de Prueba: Verificar el campo con los límites como min-1 y max+1

2. Partición de clases de equivalencia (PCE):

Siempre que tengamos un requisito especial, como comprobar si el campo (nombre de

usuario o contraseña) acepta caracteres como de la a a la z, de la A a la Z, del 0 al 9 y #
%@$&*. Al mismo tiempo, el campo no debe aceptar caracteres especiales como <>-
+/\.

 En este escenario no es posible realizar la prueba exhaustiva con todos los

caracteres. Así que tenemos que seguir la técnica ECP.
 Divida por igual los datos de prueba en dos clases.
a. Clase de datos de prueba válida b. Clase de datos de prueba no válida
 Prepare los datos de prueba con todas las formas posibles.
 Para realizar pruebas positivas, prueba el campo con datos de prueba válidos.
Donde tiene que aceptar. (Su caso de prueba +ve)
 Para realizar una prueba negativa, pruebe el campo con datos de prueba no
válidos. Donde no debe aceptar.(Su -Ve Caso de prueba)
 Si funciona como se espera, podemos concluir que funciona según los requisitos.
 3) Adivinar error:

Cuando el ingeniero de pruebas detecta un error, debe comunicarlo al desarrollador, que

lo corregirá y lo devolverá al equipo de pruebas. El ingeniero de pruebas comprobará si el fallo
está realmente solucionado o no. Al mismo tiempo, tiene que adivinar los errores o fallos en las
funcionalidades relacionadas. También tiene que realizar las pruebas en las funcionalidades
relacionadas. Es lo que se conoce como "Adivinar errores".

Ej: En la página PR no se muestra el mensaje de alerta, fue arreglado por el desarrollador y

probado por el tester. Donde el mensaje de alerta funciona correctamente en la página PR.
Ahora el ingeniero de pruebas tiene que ir a las funcionalidades relacionadas como el
asesoramiento de admisión y la admisión y luego buscar (adivinar) el tipo de error similar.

Matriz de trazabilidad:

Sirve para saber si el ingeniero de pruebas ha cubierto o no todos los casos de prueba de
todos los requisitos.
 Basándose en la matriz de trazabilidad, el jefe de proyecto o el cliente determinarán si el
ingeniero de pruebas ha cubierto todos los casos de prueba o no.

ID de
solicitu Id de caso
d Nº de TC de prueba Comentarios
1 1 1
2 1 2
3 1 3
4 1 4
5 1 5
6 1 6
7 1 7
8&9 5 8 a 12 años
El requisito no está
claro. A la espera de
Aún no se ha los comentarios de
10 aplicado BA

4) Ejecución de la prueba:

 El proceso de ejecución de los casos de prueba en el entorno de prueba se conoce como

ejecución de pruebas. Cada vez que la versión se entrega al equipo de pruebas, el
ingeniero de pruebas debe revisar el documento SRN para conocer el estado de la
versión.
 Basándose en el documento SRN, el jefe de pruebas desplegará la compilación y el
equipo de pruebas realizará la prueba de sanidad.
 Una vez completada la prueba de sanidad, los resultados de la misma se envían por
correo al desarrollador.
 Si se supera la prueba de sanidad, el equipo de pruebas continuará ejecutando los casos
de prueba. Si no se supera la prueba de sanidad, el equipo de pruebas rechazará la
compilación y la devolverá al equipo de desarrollo.
 Mientras se ejecutan los casos de prueba, el ingeniero de pruebas observará el
comportamiento real de la aplicación para el escenario y se actualizará en el campo de
resultado real. Lo mismo se hará con todos los casos de prueba.

5) Análisis de resultados:

 Durante la ejecución de los casos de prueba, el ingeniero de pruebas actualizará el

campo de resultado real y, a continuación, comparará el resultado real con el resultado
 esperado; si ambos coinciden, proporcionará el resultado como correcto; de lo
contrario, lo actualizará como incorrecto.
 Para el aprobado daremos el color verde, mientras que para el suspenso daremos el
color rojo. La ejecución de las pruebas y el análisis de los resultados son procesos
paralelos.

Nota: Una vez completada la ejecución de los casos de prueba, somos responsables de ejecutar
todos los tipos de pruebas funcionales en la aplicación para identificar los errores.

* ¿Cuántos casos de prueba podemos escribir en un día?

Todo depende de los requisitos y del ingeniero de pruebas, pero por término medio podemos
escribir entre 40 y 50 casos de prueba en un día. Esto significa que tardamos aproximadamente
entre 8 y 10 minutos en analizar los requisitos de un caso de prueba y preparar el caso de
prueba en la plantilla de casos de prueba con los datos de prueba.

* ¿Cuántos casos de prueba podemos ejecutar en un día?

También depende de los casos de prueba y de la aplicación, pero por término medio
podemos ejecutar entre 50 y 60 casos de prueba en un día, ya que hay que revisar el caso de
prueba y ejecutarlo en la aplicación.

Tardamos entre 5 y 8 minutos de media en ejecutar un caso de prueba.

6) Informar:

 El proceso de notificar/enviar los errores (casos de prueba fallidos) al desarrollador se

conoce como notificación.
 Es de dos tipos.

1. Notificación de errores mediante ficheros XL.

2. Informar de los fallos mediante herramientas de notificación.

1. Informe de los errores mediante el archivo XL:

En el antiguo proceso solíamos tener la siguiente plantilla para actualizar el fallo y enviarlo al
desarrollador.
Err Título del Estado Gravedad Prior Descrip Captura Constr Report Comentarios
or error/ idad ción del de uya ado asignados
ID Resumen fallo pantalla Versió Por
n a
1.

ID de error:

El número de serie del fallo se describirá aquí.

Título del fallo/resumen:

Aquí se describirá el resultado real del fallo.

Estado:

En función del fallo, tanto los ingenieros de pruebas como el desarrollador son responsables de
determinar el estado. Está por debajo de los tipos.

 Novedad:
Siempre que el ingeniero de pruebas identifique algún fallo. Inicialmente el estado del
fallo es Nuevo. El nuevo error se comunicará al desarrollador.
 Abierto:
El desarrollador comprobará si el nuevo fallo es realmente un fallo o no. En caso
afirmativo, actualizaremos el estado de nuevo a abierto.
 Fijo/Verificado:
El desarrollador tardará algún tiempo en arreglar el fallo abierto, una vez arreglado
actualizará el estado de abierto a arreglado. El error corregido se enviará al ingeniero de
pruebas.
 Cerrado:
El ingeniero de pruebas comprobará si el fallo corregido funciona realmente como se
esperaba o no. Si funciona, actualizaremos el estado de solucionado a cerrado. El estado
cerrado es el final del Bug.
  Re abierto:
El ingeniero de pruebas probará el fallo corregido; si no funciona como se espera,
actualizará el estado de corregido a reabierto y el fallo reabierto se devolverá al
desarrollador.
El desarrollador comprobará si se trata realmente de un fallo o no, en caso afirmativo lo
abrirá, corregirá el fallo y lo devolverá al equipo de pruebas.
 Rechazado/No es un error/ Retenido/Diferido:
Cuando el ingeniero de pruebas identifique algún fallo, lo comunicará al desarrollador
con un nuevo estado. Si el desarrollador no acepta un fallo, actualizará el estado de
nuevo a Rechazado/No es un fallo y lo devolverá al equipo de pruebas.

Gravedad:

Describe la gravedad del impacto del fallo en la aplicación durante las pruebas. Severidad
significa gravedad del fallo. Está por debajo de los tipos.

 Bloqueador:
Si el fallo bloquea toda la prueba del módulo, entonces la gravedad o tipo de fallo es
Bloqueador.
 Muy alto:
Si el fallo bloquea parcialmente las pruebas del módulo, entonces la gravedad del fallo
es muy alta.
 Alta:
Si el fallo bloquea sólo el escenario específico del módulo, entonces la gravedad es alta.
 Medio:
La gravedad de todos los errores de la interfaz gráfica es media.
 Bajo:
El ingeniero de pruebas también tiene la opción de hacer sugerencias. Por tanto, la
sugerencia se notificará en forma de error, cuando la gravedad sea baja.

Prioridad:

La prioridad describe el orden en que el desarrollador debe corregir el fallo. En función de la

gravedad, el ingeniero de pruebas dará prioridad al fallo de la siguiente manera

Gravedad Prioridad
 Bloqueador/urgente/ P1
crítico
P2
Muy alta
P3
Alta
P4
Medio
P5
Bajo

Descripción:

Los pasos detallados para producir/obtener el fallo se describirán aquí. Basándose en estos
pasos, el desarrollador comprobará si se trata realmente de un error o no.

Captura de pantalla:

El ingeniero de pruebas capturará la pantalla del fallo y la cargará en la plantilla de fallos. Sirve
para demostrar que el fallo notificado es válido y también para comprenderlo.

Versión de construcción:

Aquí se describirá el número de compilación en el que el ingeniero de pruebas identificó el

fallo.

Reportado por:

El ingeniero de pruebas que identificó el fallo lo describirá aquí.

Asignar a:Aquí se describirá el nombre del desarrollador o el nombre del desarrollador principal
que va a corregir el fallo.

Observaciones:

Tanto los ingenieros de pruebas como los desarrolladores pueden formular las preguntas en
forma de comentarios.

Nota:La generación de informes de archivos XL consumirá mucho tiempo, por lo que nuestro
plan es utilizar las herramientas de generación de informes.
Ex:

Título del
BUG fallo / Estad Graved Priorid
Fases ID Resumen o ad ad Descripción del fallo Captura de pantal

La aplicación 1. Abre Spicejet.com

no muestra 2. Haga clic en el botón de opción Ida
los dos y vuelta
selectores Bloquead 3. La aplicación no muestra los dos
I 1 de fecha Nuevo or P1 selectores de fecha D:\NNNagesh\SPiceje

El nombre
de Spicejet
aparece 1. Abre Spicejet.com
como 2. Observe el logotipo de Spicejet
II 2 spacejet Nuevo Medio P4 3. Se muestra como spacejet D:\NNNagesh\SPiceje

El botón de
radio 1. Abre Spicejet.com
Oneway no 2. El botón de radio Oneway no está
III 3 se muestra Nuevo MuyAlto P2 disponible Ruta
La casilla
Estudiante 1. Abre Spicejet.com
no está 2. La casilla Estudiante no está
I 4 disponible Nuevo Alta P3 disponible Ruta
Cambiar el
color de la
página de
inicio de
spicejet a
II 5 azul Nuevo Bajo P5 1. Abrir Spicejet.com Ruta

Spicejet club 1. Abre Spicejet.com

link is not 2. Haz clic en el enlace Spiceje
navigating to Connect
Spicejet club Bloquead 3. El enlace Spiceje Connect no lleva
III 6 page Nuevo or P1 a la página MySpicetrip Ruta

1. Abra
http://selenium4testing.com/hms
La aplicación 2. 2. Inicie sesión en la aplicación
no mantiene Haga clic en Buscar registro
I 7 la GUI Nuevo Medio P4 4. La aplicación no mantiene la GUI Spicejet_GUI.png
 La interfaz 1. Abra
gráfica de http://selenium4testing.com/hms
usuario de la 2. Inicie sesión en hms con
lista de usuario1/usuario1
trabajo de 3. Haga clic en ADT
admisión no 4. Haga clic en Lista de trabajo de
se actualiza admisión
correctamen 5. Observe la GUI, no se mantiene
II 8 te Nuevo Medio p4 correctamente D:Nagesh_ADWList.pn

El campo 1. Abra http://spicejet.com

Adulto no 2. Observe todos los campos
aparece en Bloquead 3. El menú desplegable Adultos no
III 9 la página Nuevo or P1 está disponible D:\NNNagesh\Spiceje

La aplicación 1. Abra http://spicejet.com

no muestra 2. Haga clic en el campo LeavingFrom
Hyderabad y 3. La aplicación no muestra
I 1 Bangalore Nuevo MuyAlto P2 Hyderabad y Bangalore D:\NNNagesh\Spiceje
P: ¿Cuál es la diferencia entre gravedad y prioridad?

P: ¿cuál es la diferencia entre Prioridad en los casos de prueba y Prioridad en la plantilla de

errores?

P.Si el desarrollador no acepta tu fallo, ¿cómo vas a demostrar que el tuyo es válido?

R: Basándonos en la descripción del fallo, el documento SRS y la captura de pantalla,

intentaremos demostrar que el fallo es válido. Si no lo aceptan, tomaré el registro del
servidor para demostrar que el fallo es válido, si aún así no lo aceptan, lo enviaré al BA, al
jefe de proyecto y, finalmente, al cliente.

Q. ¿Explique el escenario en el que el fallo tiene una gravedad alta con una prioridad baja y
una seguridad baja con una prioridad alta?

A:Prioridad de gravedad

Bloqueador - P1

Alta seguridad Muy alta - P2 Alta prioridad

Alta - P3

Medio - P4
 Baja seguridad Baja - P5 Baja prioridad

Tenemos dos bichos uno es Blocker otro es medio. El bloqueador tendrá prioridad alta
y el medio prioridad baja.

En función de la gravedad, el ingeniero de pruebas dará prioridad. Según la prioridad, el

equipo de desarrollo es responsable de corregir

Pero el jefe de desarrollo tiene la opción de cambiar la prioridad en función de la

situación.

 Los fallos relacionados con la entrega de la fase actual pasarán a tener prioridad alta,
independientemente de su gravedad.
 Los fallos que no formen parte de la entrega actual pasarán a prioridad baja
independientemente de su gravedad.

Fase Id. del fallo Título del fallo/resumen Estado Gravedad Prioridad

I. 1. Spice jetname muestra Nuevo Medio P4---P1

Como chorro espacial

2. 2. Spice jet connect link no es Nuevo Bloqueador P1----P4

Navegar por la página de spice jet connect

Informe de pruebas/informe de estado de construcción:

Una vez que se ha completado la ejecución del caso de prueba en la compilación, el

ingeniero de pruebas es responsable de enviar un informe de prueba al jefe de proyecto
y al cliente. El siguiente formato
Informe de estado de construcción/Informe de pruebas

Informe de estado de construcción / Informe de pruebas

Test Engg Name:
Construir No 1
Credenciales de acceso
Navegador FF, IE GoogleChrome
 Matriz de pruebas
Nº total de casos de prueba 200
Nº de casos de prueba
ejecutados 150
Nº de casos de prueba
pendientes 50
Nº de casos de prueba
superados 100
Nº de casos de prueba Fallidos 50
Nº de casos de prueba omitidos 10
Número de errores notificados 3

Métricas de prueba:

Métrica significa medición de la tarea. Las métricas de las pruebas significan la medición de las
pruebas.

Pendiente:

Si el desarrollador no ha dado funcionalidad alguna, entonces esos casos de prueba no pueden

ejecutarse. Está pendiente.

Saltado:

El desarrollador ha dado la funcionalidad, pero no podemos probar las

funcionalidades, debido a que las funcionalidades dependientes fallaron.

Ej: si el Login falla, no podemos ejecutar compose.

Componer casos de prueba entra en omisión.

 Los informes continuarán hasta que la versión sea estable; estable significa que la
mayoría de los casos de prueba se han superado y que no hay errores de bloqueo
disponibles en la herramienta de informes.
 La versión estable se entregará al cliente.

P: Explíqueme la estructura jerárquica de su organización

Notifique los errores mediante las herramientas de notificación:

 Cualquier herramienta de informes tiene dos tipos de usuarios: Uno es el usuario

administrador y otro es el usuario final.
 Usuario administrador: El usuario administrador es responsable de crear el proyecto,
crear usuarios como ingenieros de pruebas, desarrolladores...etc. Asignará el usuario al
proyecto
  Usuario final: Es el responsable de utilizar (informar) o recibir los fallos ej: ingenieros de
pruebas, desarrolladores...etc.

Ej: QC, JIRA, Bugzilla, Redmine, Test manager etc...

BugZilla:

 Acceda al Bugzilla mediante selenium4testing.com

 A continuación, haga clic en Bugzilla.
 mailto:jan30selenium@gmail.comInicie sesión en Bugzilla como ingeniero de
pruebas(jan30selenium@gmail.com& contraseña : selenium)
 Utilizando Bugzilla podemos realizar las siguientes actividades.
a. Informar de un fallo.
b. Busca los bichos.
c. Podemos tomar el informe.
d. Preferencia.

Introducción a Bugzilla
¿Qué es Bugzilla?
Bugzilla es un sistema de seguimiento de problemas y fallos de código abierto que
permite a los desarrolladores realizar un seguimiento eficaz de los problemas pendientes
de su producto. Está escrito enPerl y utiliza la base de datos MYSQL.

Bugzilla es una herramienta de seguimiento de defectos, pero puede utilizarse

como herramienta degestión de pruebas, por lo que puede vincularse fácilmente con otras
herramientas de gestión de casos de prueba, comoQuality Center, Testlink, etc.

Este bug-tracker abierto permite a los usuarios mantenerse en contacto con sus
clientes o empleados, para comunicar los problemas de forma eficaz a lo largo de toda la
cadena de gestión de datos.

Las principales características de Bugzilla son

 Funciones avanzadas de búsqueda

 Notificaciones por correo electrónico
 Modificar/archivar errores por correo electrónico
 Control del tiempo
 Seguridad sólida
 Personalización

¿Cómo conectarse a Bugzilla?

Paso 1) Para crear una cuenta en Bugzilla o iniciar sesión en la cuenta existente, vaya a
la opciónNueva cuenta o Iniciar sesión en el menú principal.

Paso 2) Ahora, introduzca sus datos personales para iniciar sesión en Bugzilla

1. Usuario: jan30selenium@gmail.com
2. Contraseña: selenium
3. Y luego haga clic en"Iniciar sesión"
Paso 3) Ha iniciado sesión con éxito en el sistema Bugzilla

Creación de un informe de error en Bugzilla

Paso 1) Para crear un nuevo fallo en Bugzilla, visite la página de inicio de Bugzilla y
haga clic en la pestañaNUEVOdel menú principal
Haga clic en el enlace Nuevo y la aplicación abrirá la siguiente ventana, como se muestra
a continuación.

Paso 2) En la siguiente ventana

Haga clic en el nombre del proyecto, como HMS, y la aplicación abrirá una nueva ventana
con las siguientes opciones

1. Introducir producto
2. Introducir componente
3. Descripción del componente
4. Selecciona la versión,
5. Seleccione la gravedad
6. Seleccionar hardware
7. Seleccionar sistema operativo
8. Introducir resumen
9. Introducir descripción
10. Adjuntar
11. Enviar

NOTA: Los campos anteriores variarán en función de su personalización de Bugzilla

Introduzca todos los campos necesarios respecto a su fallo como se indica a continuación,
Si tiene algún archivo adjunto en relación con su informe de error, puede adjuntarlo haciendo clic en el botón
"Añadir un archivo adjunto" y en el botón "Comprometerse" al final de la página para informar de su error.

Paso 4) Se crea el Bug Se asigna el ID# 208 a nuestro Bug. También puede añadir información adicional al
fallo asignado, como URL, palabras clave, pizarra, etiquetas, etc. Esta información extra es útil para dar más
detalles sobre el Bug que has creado.

1. Cuadro de texto grande

2. URL
3. Pizarra
4. Palabras clave
5. Etiquetas
6. Depende de
7. Bloquea
8. Archivos adjuntos
Paso 5) En la misma ventana si se desplaza hacia abajo más. Puede seleccionar la fecha límite y también el
estado del fallo.La fecha límite en Bugzilla suele indicar el plazo para resolver el fallo en un plazo
determinado.
Crear informes gráficos

Los informes gráficos son una forma de ver el estado actual de la base de datos de fallos. Puede ejecutar
informes a través de una tabla HTML o de un gráfico de líneas, tarta o barras. La idea detrás del informe
gráfico en Bugzilla es definir un conjunto de errores utilizando la interfaz de búsqueda estándar y luego elegir
algún aspecto de ese conjunto para trazar en los ejes horizontal y vertical. También puede obtener un informe
tridimensional eligiendo la opción "Varias páginas".

Los informes son útiles de muchas maneras, por ejemplo, si desea saber qué componente tiene el mayor
número de errores notificados. Para representarlo en el gráfico, puede seleccionar la gravedad en el eje X y el
componente en el eje Y y, a continuación, hacer clic en Generar informe. Generará un informe con
información crucial.

1. Haga clic en los informes en la parte superior de la ventana de la siguiente manera

2. Haga clic en Informes gráficos

La página de informes gráficos se mostrará como se indica a continuación,

Seleccione el Eje Vertical como Severidad y el Eje Horizontal como Prioridad o lo que desee, puede
seleccionarlo y obtendrá el informe gráfico correspondiente.

 Genere un informe con funciones avanzadas introduciendo más detalles sobre el error como se indica
a continuación
El gráfico de abajo muestra la representación gráfica de barras para la gravedad de errores en el
componente"Widget Gears". En el gráfico de abajo, el error más grave o bloqueadores en los componentes
son 88, mientras que los errores con la gravedad normal está en la parte superior con 667 número.

Navegar Función

Paso 1) Para localizar su error, utilice la función de búsqueda, haga clic en el botónBuscar del menú principal.
Los informes continuarán hasta que la versión sea estable. Una vez que sea estable, se
entregará al cliente y, a continuación, se procederá a la fase de entrega y mantenimiento.

Una vez que la versión se haya entregado correctamente al cliente, el jefe de

pruebas preparará un informe de resumen de las pruebas que se actualizará en el plan de
pruebas y se enviará al cliente en el momento de la entrega de la versión.

INFORME RESUMIDO DE LA PRUEBA / INFORME POST MARTUM DE LA

CONSTRUCCIÓN

 Número de versiones publicadas por el equipo de desarrollo - 50

 Nº de construcciones aceptadas por el equipo de pruebas - 25
 Nº de construcciones rechazadas por el equipo de pruebas - 25
 Nº de casos de prueba preparados por el equipo de pruebas - 1000
 P1 - 500, P2- 350, P3-100, P4-50

 Número de errores identificados: 400

o Bloqueador - 100
o Muy alto - 150
o Alta - 100
o Medio - 40
o Bajo - 10
 Número de errores identificados por el cliente: 100
o Bloqueador - 10
o Muy alto - 50
o Alta - 10
o Medio - 10
o Bajo - 20
 Casos de éxito
 Desafíos

P: ¿Cuáles son los criterios de entrada (inicio) y salida (fin) de las pruebas?

R: El plan de pruebas y el documento SRS son los criterios de entrada de las pruebas.
 Las pruebas no tienen fin. Continuará mientras la versión esté activa. Pero las actividades de
prueba cambiarán después de que se entregue la compilación al cliente. Durante el
mantenimiento no vamos a realizar todos los tipos de pruebas funcionales. Realizaremos las
pruebas de regresión.

Terminología
Compañero significa el compañero de equipo con
igual designación. Todos los compañeros
participarán en una reunión y debatirán sobre el
proyecto para aclarar todos los módulos. El objetivo
de la revisión por pares es que cada ingeniero de
pruebas adquiera conocimientos funcionales sobre
Revisión inter pares todos los módulos.
Durante la evaluación por pares, el evaluador
Informe de la revisión inter principal elaborará un documento denominado
pares Informe de evaluación por pares.
Si la misma revisión por pares se lleva a cabo
delante del jefe de proyecto, se denomina "Walk
through". El líder o PM observará si los miembros
del equipo están entendiendo el proyecto
Recorrido correctamente o no.
Mientras que Walk through el líder preparará el
documento sobre Walk through se conoce como
Informe a pie de página Walk through report
La combinación de varios casos de prueba se
Conjunto de pruebas conoce como "conjunto de pruebas".
La combinación de un conjunto de pruebas y un
entorno de pruebas se conoce como banco de
Banco de pruebas pruebas.
Informe diario de situación.
Diariamente tenemos que enviar el estado de
DSR nuestro trabajo al jefe en una plantilla
Acta de la reunión.
Siempre que participemos en una reunión, el
debate de la misma se plasmará en una nota
aproximada. Posteriormente se actualizará en un
correo y se enviará a todos los miembros del
equipo. El objetivo del MOM es mantener la
transparencia de la reunión entre los miembros del
MOM equipo.
El proceso de comprobar si la empresa sigue las
directrices o no. La inspección se realizará sin
Inspección previo aviso
También es el proceso de comprobar si la empresa
sigue las directrices o no. La auditoría se realizará
Auditoría con previo aviso
Estable significa que no se necesitan más
actualizaciones.
Una compilación estable significa que la mayoría de
Estable los casos de prueba se han superado y que no se
 han detectado errores de bloqueo en la
compilación.
AUT Aplicación sometida a prueba
Cuando se rechace la compilación, el desarrollador
analizará el fallo. Se conoce como PatchBuild a la
versión que se vuelve a entregar al equipo de
pruebas sin añadir nuevas funcionalidades.
Si el desarrollador está liberando la versión con
algunas nuevas funcionalidades se conoce como
Construcción de parches nueva versión
Póngalo a disposición de los usuarios a los que va
dirigido. Una vez que el documento de casos de
prueba o SRS esté alineado, se registrará en el
repositorio central para los usuarios destinatarios.
Publique Se conoce como publicar
Los fallos relacionados con el diseño se conocen
como defectos. Ej: Defectos GUI
Los fallos relacionados con el funcionamiento son
bugs (error del programador).
Ej: Todos los errores funcionales
Error: Las excepciones en la secuencia de
Bug/Defecto/Error comandos se conoce como error
Un caso de uso es una lista de pasos, que
normalmente definen las interacciones entre un rol
(conocido como "actor") y un sistema, para alcanzar
un objetivo. El actor puede ser un ingeniero de
pruebas o un usuario final
El BA convertirá los requisitos en una lista de
Casos prácticos pasos.
Informes de no conformidad o solicitud de cambio
NCR de no conformidad. El requisito que se debate
Se aplican acciones correctivas en respuesta a las
quejas de los clientes
Se aplican acciones preventivas en respuesta a la
CAPA identificación de fuentes potenciales
En ingeniería del software, la gestión de la
configuración del software (SCM o SWCM) es la
tarea de seguir y controlar los cambios en el
software. Las prácticas SCM incluyen el control de
SCM revisiones y el establecimiento de líneas de base.
SDN Nota de entrega del software
Subsidiando. Alejarse de la tarea
Deslizamiento El número de días que se ha alejado de la tarea
Producto defectuoso El producto con defectos
La edad del defecto (en tiempo) es la diferencia de
tiempo entre la fecha en que se notifica un defecto
y la fecha actual (si el defecto sigue abierto) o la
fecha en que se solucionó (si el defecto ya está
Edad del defecto solucionado).
Defecto latente Defecto oculto
La gestión de la cartera de productos es la gestión
centralizada de los procesos, métodos y
tecnologías utilizados por los gestores de
PPM proyectos.
 Informes de evaluación del rendimiento de los
PPR programas
MRM Gestión de recursos de marketing