PRUEBAS DE SOFTWARE

REVELADO

FORMACIÓN BOOK

SEGUNDA EDICION

POR INTERNACIONAL DEL INSTITUTO DE PRUEBA SOFTW

www.test-institute.org

© derechos de autor internacionales software de prueba INSTITUTO ™




Dedicación

A todos los estudiantes del Instituto Internacional de Pruebas de Software ™, gracias por inspirarnos, manteniendo
enfocados, y asegurarse de que hacemos todo lo posible para ayudarle a crecer en su carrera con sus habilidades y
conocimientos. Sin usted, su compromiso y su apoyo leal, Instituto Internacional de Pruebas de Software ™ no podía venir
donde está hoy.
TABLA DE CONTENIDO se puede hacer clic

BIENVENIDO
........................................................................................................................ 6

ACERCA DE PRUEBA SOFTWARE INSTITUTO INTERNACIONAL

.....................................................
™ 7

Introducción Pruebas de Software Para ............................................................................8

Qué es el Software de Control de Calidad? ................................................................... 12

¿Qué es la Prueba de Software? ....................................................................................... 18

Fundamentos de Pruebas de Software ........................................................................21

Funciones y responsabilidades de pruebas de software .......................................................30

Los métodos de pruebas de software

......................................................................................36

Los niveles de pruebas de software

..........................................................................................38

Tipos de pruebas de software............................................................................................43

Pruebas de Software Manual ........................................................................................49

Automated Software Testing ...................................................................................51

Cascada del ciclo de vida del software Ingeniería .........................................................55

Agile Software Ingeniería del Ciclo de Vida ................................................................... 59

Gestión de Proyectos de Software ...............................................................................62

Software Ciclo de Vida operaciones de prueba y Pruebas de Software ........................ 64

Entregables del Team Software Testing ................................................................66

Qué es el software de Riesgos y software de gestión de riesgos? ................................... 71

Apoyo a los procesos de Pruebas de Software ............................................................... 75

Gracias ....................................................................................................................80
BIENVENIDO

¡Hola! Estoy Yeliz.
Me encanta que usted está tomando su tiempo para leer su libro de pruebas
de software. Quiero brevemente compartir con ustedes por qué queríamos
escribir este libro para usted y cómo usted puede conseguir el mejor uso de
ella.
En el marco de nuestro programa de certi fi cación de Pruebas de Software
hicimos una investigación a fondo en el espacio de la educación pruebas de
software.
La conclusión fue: No fue posible hallar un solo libro de texto, podríamos
sinceramente recomendamos a nuestros estudiantes!
Hablamos con nuestros estudiantes exitosos y descubrimos que, casi
ninguno de los libros de pruebas de software en el mercado podría
realmente ayudarlos a tomar una entrada suave de pruebas de
software. número signi fi cativo de libros pruebas de software en la
demanda del mercado que cubren todos los detalles de pruebas de
software, pero lo que no dicen es que, ellos no tienen contenido
comprensible, clara y lógica para ayudar a sus lectores comprendan y
lo más importante aman Pruebas de Software !
Por lo tanto, escribimos para usted Pruebas de Software revelados y
se lo llevó a su servicio!
Estamos absolutamente con fi mella que las pruebas de Software
revelados le hará per fi ciente en pruebas de software, por lo que
tendrá una excelente oportunidad para el amor Pruebas de Software y
seguir teniendo los beneficios tangibles de ser un profesional de
Pruebas de Software.
Tómese su co ff ee para disfrutar y un poco de papel para tomar
notas, y pasar un tiempo tranquilo para leer su libro Pruebas de
Software!
Después de que tendrá una gran comprensión acerca de pruebas de
software de dominio y estar preparado para pasar su examen de certi fi
cación pruebas de software. Usted estará listo para entregar productos
y servicios a sus clientes y los empleadores y para construir su brillante
carrera y el futuro!
Yeliz Obergfell
Vicepresidente - Instituto Internacional de Pruebas
de Software Student Experience ™

6
ACERCA DE PRUEBA SOFTWARE INSTITUTO INTERNACIONAL ™

Instituto Internacional de Pruebas de Software ™ es un instituto
independiente que ayuda a las organizaciones profesionales y
acreditarse con los programas internacionales reconocidos y válidos
Software Testing Certification y demostrar su competencia en el
dominio de pruebas de software. Autorizamos a los profesionales de
todo el mundo para construir sus carreras, y las empresas a crear y
vender sus productos y servicios excepcionales.
Su acreditados Software Tester, Acreditado Software Test Manager y
acreditado software de pruebas de Automator Certi fi cación de los
programas han demostrado su aceptación en todo el mundo y
reputación por ser la elección de más de 349'000 Software Testing Los
profesionales en 143 países.
Las pruebas de software es un proceso abierto que se puede combinar
con otros procesos de ingeniería de software y los marcos, y sin
embargo, antes de la creación de software de prueba Instituto
Internacional ™, que solía haber ninguna manera razonable para los
profesionales de pruebas de software como usted para obtener fi
caciones de pruebas de software cados y probar su competencia en el
dominio de pruebas de software. Los profesionales de pruebas de
software tenían que pagar tarifas costosas para el uno
Software de Pruebas Certi fi cación programas de otras entidades de certi fi
cación manera per fi t-conducido.
Instituto de Pruebas de Software Internacional ™ tiene por objeto
suprimir las barreras establecidas frente a los profesionales de pruebas
de software en los mercados desarrollados y emergentes guardándolos
del pago de tasas razonables para pruebas de software Formación
presencial y pruebas de software cados Exámenes fi cación antes de
que certifican su know-how en pruebas de software.
Por otra parte, se siente libre de visitar "Lo que hace que su Certificación
Programas mejor de la industria?" sección en nuestro www.test-institute.org
portal web para leer por qué llevamos a cabo y servirle mucho más mejor
que nuestra competencia.
Instituto Internacional de Pruebas de Software ™ ofrece 3 principales
programas en línea fi cación de pruebas de software cados que están
diseñados por nuestro consorcio de renombre de negocios y personas
líderes, entrenadores, mentores, expertos y autoridades de las principales
industrias. Usted puede ver sus programas fi cación de pruebas de
software cados de esta Lista de Software de Pruebas Certi fi caciones .

7
 miles de líneas de código y fi jar un error no es una tarea fácil. Nunca
Introducción Pruebas de Software Para se sabe que mientras que fijan un bicho puede introducir otro error sin
saberlo en el sistema.
Las pruebas de software no es más que un arte de la investigación de
software para asegurarse de que su calidad sometida a prueba está en
línea con el requisito del cliente. Las pruebas de software se lleva a cabo
de manera sistemática con la intención de defectos hallazgo en un
sistema. Se requiere para la evaluación del sistema. A medida que la
tecnología avanza, vemos que todo se está digitalizada. Puede acceder a
su banco en línea, usted puede comprar desde la comodidad de su
hogar, y las opciones son infinitas. ¿Se ha preguntado qué pasaría si
estos sistemas resultan ser defectuoso? Una pequeño defecto puede
causar una gran cantidad de pérdida financiera. Es por esta razón que
las pruebas de software está emergiendo como un poderoso campo de
TI.

Aunque al igual que otros productos de software nunca SU ff ers de

Metodología de pruebas de software en el software
cualquier tipo de desgaste o rotura o corrosión, pero sí, los errores de
Ingenieria
diseño pueden de fi nitivamente hacer su vida di fi culto si no se
detectan. La comprobación periódica garantiza que el software se
desarrolla según el requisito del cliente. Sin embargo, si el software es
Las pruebas de software es ahora un signi fi cante muy y parte integral del
enviado con los insectos incrustados en ella, nunca se sabe cuando se
desarrollo de software. Idealmente, lo mejor es introducir las pruebas de
puede crear un problema y entonces será muy di fi culto para corregir
software en cada fase del ciclo de vida del software de desarrollo. En
defectos porque la detección y cientos
realidad, la mayoría del tiempo de desarrollo de software se utiliza ahora
para la prueba.

8
 persona tiene la tendencia a cometer un error. No es posible
crear un software con cero defectos sin la incorporación de las
pruebas de software en el ciclo de desarrollo. 6 No importa cuán
bien el software de diseño miradas

en el papel, una vez que se inicia el desarrollo y empezar a probar el

producto que se de fi nitivamente encontramos un montón de defectos
en el diseño.

No se puede conseguir una calidad de software sin pruebas de software. Incluso

si los probadores no están implicados en la codificación real que deben trabajar
en estrecha colaboración con los desarrolladores para mejorar la calidad del
Introducción Pruebas de Software Para
código. Para obtener los mejores resultados, es importante que las pruebas de
software y codificación debe ir de la mano.

Por lo tanto, para resumir, podemos decir que:

1 Las pruebas de software se requiere para comprobar el

Software de ensayo general
fiabilidad del software
surgen defectos en el software debido a muchas razones. Como cuestión
2 pruebas de software asegura que el sistema está
de hecho, se dice que todas las aplicaciones de software tiene algunos
Libre de cualquier error que puede hacer cualquier tipo de fallo
defectos incrustados en ella, pero no todos los defectos es una amenaza
para el sistema. Hay mucho que se puede lograr con la ayuda de pruebas
3 pruebas de software garantiza que el producto está disponible
de software. La prueba ayuda en la evaluación de la calidad del software.
línea con el requerimiento del cliente 4
Es necesario asegurarse de que el producto fi nal es fácil de
usar
5 Al final del software es desarrollado por un equipo de
Hay muchas razones por las pruebas de software ha adquirido tanta
desarrolladores humanos al l que tiene di ff puntos de vista Erent
importancia en el campo de la
y enfoque. Incluso los más inteligentes

9
tecnologías de la información. En primer lugar, la prueba ayuda a
reducir el coste total del proyecto de desarrollo de software. Si la
prueba se tiene en cuenta en las etapas iniciales de desarrollo a
ahorrar una pequeña cantidad de dinero, entonces puede llegar a ser
un asunto muy caro más tarde debido a medida que se mueve adelante
con el proceso de desarrollo se hace más y más di fi culto a defectos de
espalda traza y la rectificación de un defecto en algún lugar puede
introducir otro defecto en algún otro módulo.
El requisito se nalizado fi después de varias discusiones con el cliente.
Las pruebas aseguran que se comporta el software y es exactamente
igual a lo que se menciona en los requisitos específicos del documento
fi cación, de manera que cuando el software se entrega al cliente no
hay argumentos sobre la variación de los requisitos originales. Las
pruebas de software ayuda a fortalecer la reputación de mercado de
una empresa. software bien probado es de buena calidad y los medios
de buena calidad mejor retroalimentación y comentarios.
Con el fin de lograr mejores resultados, es importante organizar todas sus
pruebas e Orts ff y esto es lo que esta Ensayos Formación software
proporcionado por el Instituto Internacional de Pruebas de Software se trata.
Las pruebas de software no puede ser fructífera sin una planificación
adecuada. A la altura
a las expectativas del cliente es importante para planificar cada paso con
cuidado. Muchas cosas deben tenerse en cuenta en el plan de la orden
sus pruebas e Orts ff. Las pruebas de software debe ser planeado
mantener el presupuesto, el horario y el rendimiento en mente con el fin
de lograr mejores resultados.
Todas las actividades de prueba requieren una planificación. Es importante
delinear un plan de prueba que le dará los detalles sobre cómo se llevará a
cabo cada actividad. También se requiere un plan de pruebas para asegurar
que todos los aspectos del software están completamente cubiertos y no
hay repetición de proceso de pruebas para que el tiempo y e ff ORT no se
desperdicia. La última tendencia ahora es involucrar al equipo de pruebas
en el proceso de escritura especi fi cación. Es importante que el equipo de
pruebas comprende los requisitos del cliente claramente como todo el
desarrollo se basa en el requisito definido por el cliente.
Todo lo que no está de acuerdo con el requisito es un defecto. Por lo tanto, el
equipo de prueba debe tener una idea clara acerca de lo que el resultado fi
nal de ejecutar software como deben ser. Como cuestión de hecho, es
importante empezar a escribir casos de prueba en paralelo a la escritura
especí fi cación. Esto ayudará a los probadores de analizar si todos los
requisitos son comprobables o no. Cuando se escribe casos de prueba en
paralelo al proceso de escritura específica de cationes
10
que va a pensar críticamente sobre las especificaciones y usted sabrá
si hay un problema con el requisito o si hay algo que no se puede
desarrollar.

11
Qué es el Software de Control
de Calidad?

Cuando hablamos de la calidad del software, en realidad estamos

hablando de la evaluación del software basado en ciertos atributos. A
la calidad del software se define en base al estudio de las
características externas e internas del software. La calidad externa se
define sobre la base de cómo funciona el software en el escenario en
tiempo real en modo de servicio y lo útil que es para sus usuarios. La
Calidad del software
calidad interna, por otra parte se centra en los aspectos intrínsecos
que dependen de la calidad del código escrito. El usuario se centra
más en el funcionamiento del software a nivel externo, pero la calidad
a nivel externo sólo puede mantenerse si el codificador ha escrito un Como se mencionó antes cualquier cosa que no está en línea con el

código de buena calidad significativa.
requisito del cliente puede ser considerado como un defecto. Muchas
veces el equipo de desarrollo no comprende plenamente el requisito del
cliente que finalmente conduce a diseñar error. Además de eso, el error
puede ser causado debido a la mala lógica funcional, mal de codificación
o la manipulación de datos incorrecta. Con el fin de mantener un

¿Qué es el Software de Control de Calidad?

seguimiento de defecto de un enfoque de gestión de defectos se pueden

En la actualidad hay dos enfoques importantes que se utilizan para aplicar. En gestión de defectos, las categorías de defectos se definen en

determinar la calidad del software: Enfoque de gestión de defectos 1 base a la gravedad. El número de defectos se cuenta y las acciones se

2 Atributos de Calidad enfoque toma como por la gravedad de fi nido. Los gráficos de control se pueden
crear para medir la capacidad de los procesos de desarrollo.

12
 Enfoque de gestión de defectos
Atributo de Calidad Enfoque en los otros enfoques a mano en seis
características de calidad que se enumeran a continuación:
1. Funcionalidad: se refiere al conjunto completo de funciones importantes que
son proporcionados por el software
• Idoneidad: si las funciones del software son apropiados
• Exactitud: son las funciones implementado correctamente?
• Interoperabilidad: ¿Cómo funciona el software interactúan con
otros componentes del sistema?
Atributos de Calidad Enfoque
• Cumplimiento: es el software de acuerdo con las leyes y
directrices necesarias?
• Seguridad: Es el software capaz de manejar datos de transacción
relacionados con seguridad?
2. Fiabilidad: esto se refiere a la capacidad de software para llevar a cabo
bajo ciertas condiciones para una duración definida de fi. Esto también
define la capacidad del sistema para soportar fallo de un componente.
• Madurez: Frecuencia de fallo de software
13
 • Recuperabilidad: esto da una idea de la capacidad de un sistema para obtener
de nuevo en pleno funcionamiento después de un fallo.
3. Facilidad de uso: se refiere a la facilidad de uso de una función.
• Comprensibilidad: la facilidad con que las funciones se pueden
entender
• Aprender la habilidad: ¿Cuánto e ff ORT los usuarios de di ff Erent
necesidad de poner en nivel de entender las funciones.
4. E fi ciencia: depende en general sobre la arquitectura buena y prácticas de
codificación seguidas mientras que el desarrollo de software.
5. Capacidad de mantenimiento: también conocido como compatibilidad. Es
dependiente en gran medida de código readabi l dad y complejidad y se refiere
a la capacidad de identificar y fi x un fallo en un software:
• Analizabilidad: identificación de la causa principal del fracaso.
• Mutabilidad: fi nes de la dirección ff ORT que va en modi fi cación
de código para eliminar un fallo.
• Estabilidad: qué tan estable es un sistema está en su rendimiento
cuando hay cambios realizados a la misma
• La capacidad de prueba: ¿cuánto ORT e ff va en la prueba del sistema.
6. Portabilidad: Capacidad del sistema para adoptar a los cambios en
su entorno
• Adaptabilidad: facilidad con que un sistema se adapta a los cambios
logrados en las especificaciones
• Capacidad de instalación: la facilidad con que se puede instalar un sistema.
• Conformidad: este es el mismo que el cumplimiento en la
funcionalidad.
• Reemplazabilidad: lo fácil que es para reemplazar un
componente del sistema en un entorno determinado.
Costo de la Calidad del Software
Costes de la calidad es importante porque cuando se decide llevar a
cabo las pruebas de software para su producto en realidad se va a
invertir su tiempo, dinero y e ff ORT en conseguir controles de calidad
hecho. Mediante la realización de un análisis de coste de la calidad del
software usted sabe lo que el rendimiento de la inversión (ROI) es.
14

Costo de la Calidad del Software
Costes de la calidad se calcula mediante el análisis de los costes de
conformidad y los costos de no conformidad. Un costo de la conformidad se
relaciona con:
Prevención costes 1: cantidad que se gasta en asegurar
que todas las prácticas de control de calidad se siguen correctamente. Esto incluye
tareas como la preparación del equipo, las revisiones de código y cualquier otra
actividad relacionada con el control de calidad, etc.
Precio: 2 Balance: esta es la cantidad de dinero
gastado en la planificación de todas las actividades de prueba y luego
llevarlos a cabo, tales como el desarrollo de casos de prueba y luego
ejecutarlas.
El costo no conformidad por el contrario es el gasto que surge debido
a: 1
fallas internas: es el gasto que surge cuando los casos de
prueba se ejecutan para la primera vez a nivel interno y algunos
de ellos fallan. surgen los gastos cuando el programador tiene
que corregir todos los defectos descubiertos de su pieza de
código en el momento de la unidad o las pruebas de
componentes.
2 fallos externos: es el gasto que se produce
cuando el defecto se encuentra por el cliente en lugar del
probador. Estos gastos son mucho más de lo que surgen al
interior nivel,
especialmente si el cliente obtiene insatisfecha fi cado o se intensifica
el fallo de software.
Coste de un fallo de software
Sabemos que un fallo de software se produce cuando: 1
Se muestra la falta de capacidad de continuar: esto sucede
generalmente cuando se inicia el software de envejecimiento. A
medida que crece el tamaño de edad aumenta debido a que la forma
más fácil de añadir una característica está añadiendo nuevo código
sin tocar ninguna parte del código escrito anteriormente. Durante un
período de tiempo se hace voluminosa y se hace di fi culto para
identificar las secciones de código que tienen que ser modificado.
15
 2 se observa caída de rendimiento: Cada
aplicación ralentiza generalmente con la edad y tiende a
ocupar más y más memoria de la computadora por lo tanto, es
mejor cambiar a otro software. 3
No parece ser fiable: Es un hecho conocido que cada vez que
se realizan cambios en el código del software para fi jar un error,
más defectos se introducen en el sistema. Sorprendentemente,
esta es una de las principales razones para el aumento de las
tasas de fracaso y con el fin de salvar la situación siempre es
mejor para deshacerse de proyecto o renunciar a fallo de fi
jación.
Las pruebas de software VS Aseguramiento de la Calidad
En la industria de TI a menudo se observa que las personas
generalmente no di ff erentiate entre el aseguramiento de la calidad del
software y pruebas de software. Los examinadores son a menudo
considerados como profesionales de software de garantía de calidad ya
que los objetivos de las pruebas de software, así como la garantía de
calidad son los mismos .es para asegurar que el software es de calidad
superior. Como su nombre indica los procesos de garantía de calidad se
llevan a cabo para asegurar la calidad del producto está en línea con el
requisito del cliente. Los profesionales de control de calidad del trabajo en
el desarrollo y ejecución de todos los procesos necesarios para
garantizar que todos los procedimientos necesarios de ciclo de vida de
desarrollo de software se siguen correctamente. aseguramiento de la calidad
es una actividad proactiva que se centra en: 1 Prevención de Defectos 2
Procesos
3 mejora continua de este procesos
Las pruebas de software, por otro lado se realiza para identificar o defecto
destape y los errores en el software. Se trata de pruebas rigurosas real del
software para ver si hay algún defecto o variaciones de los requerimientos
del cliente que necesita ser fi ja. Las pruebas de software es una parte del
proceso de control de calidad y que se centra sólo en las actividades
orientadas a productos. Las pruebas de software se lleva a cabo durante la
fase de prueba y solamente los defectos son identificados y no se corrige
en este proceso. La fijación de los defectos no es una parte de las pruebas
de software.
Aseguramiento de Calidad Control de Calidad VS
Otro tema que está estrechamente relacionado con la garantía de calidad
es el control de calidad. La gente a menudo se confunden entre los dos,
pero hay una enorme di ff rencia. Mientras que la garantía de calidad tiene
que ver con las actividades de prevención, el control de calidad se centra
en los procesos correctivos.
dieciséis
Esto es lo que hay que entender: las pruebas de software es un
subconjunto de control de calidad y control de calidad es un
subconjunto de aseguramiento de la calidad. Todo el enfoque de
garantía de calidad es la implementación de los procesos y
procedimientos que se requieren para la la verificación del software en
desarrollo y los requerimientos del cliente.
Aseguramiento de Calidad Control de Calidad VS
Control de calidad de las otras ofertas de la mano con las actividades
reales que aseguren que el producto está siendo desarrollado según las
necesidades de fi nido. Se ocupa de todas las acciones que son
importantes para controlar y verificar ciertas características del producto
incluyendo las pruebas. Examen y pruebas de los productos es el
aspecto más importante del control de calidad.
Empresas emplean equipo de control de calidad para identificar si hay algún
producto o servicio que no cumple con estándares de calidad de la compañía.
Si hay un problema el equipo de control de calidad tiene la autoridad para
detener la producción de ese producto hasta que el problema se ha resuelto.
Importancia de Auditoría e Inspección
Auditoría consta de algunos procesos muy sistemáticas que definen cómo
las pruebas de software está llevando a cabo en la organización. Los
equipos de auditoría examina todos los procesos que se llevan a cabo en el
momento de la prueba. IEEE auditoría de fi ne como una revisión de los
procesos documentados para asegurar que la organización o un equipo está
siguiendo todos los procesos de acuerdo con las normas de fi nidas.
La inspección puede ser un formal o una revisión informal del requisito
de software, diseñador o código. Se lleva a cabo por un equipo o una
persona individual que no sea el autor para comprobar si hay
violaciónes o desviaciones de las normas de desarrollo de fi nidas.
Los siguientes procesos se consideran como parte de inspección: 1
Planificación 2 Descripción general Preparación 3
Inspección Reunión 4
retrabajo 5 Seguimiento

17
 llevado a cabo en todos los niveles de las pruebas de software - unidad, de
¿Qué es la Prueba de Software? integración, y aceptación del sistema.

Así que, finalmente llegamos al tema principal que es un software de

prueba en sí. Usted ya ha entendido el significado de las pruebas de
software y por qué es importante, mientras que ir a través de las secciones
anteriores. Aquí, desde esta sección en adelante vamos a tener una mirada
en profundidad en el tema, pero antes de seguir adelante vamos a revisar
la definición de las pruebas de software.

Las pruebas de software es más que el proceso de evaluación de la

funcionalidad del software para asegurarse de que está en línea con
los requisitos del cliente.

La prueba es ampliamente clasificarse en: Pruebas de Caja Negro

1 Prueba dinámica: lleva a cabo mediante la ejecución de la
programa
2 Prueba estática: implica el examen de código
y los documentos relacionados.
Dinámica y pruebas estáticas se utilizan a menudo juntos.
Pruebas de Caja Negro
pruebas de caja negro se centra sólo en la funcionalidad del software.
El probador no se ve en los detalles internos del software. pruebas de
caja negro es
Los procedimientos de prueba para las pruebas de caja negro son muy
simples. El probador sólo se centra en lo que se supone que el software
para hacer. El probador no se supone que se centran en la forma en que el
software es la gestión de la función interna. Los casos de prueba para las
pruebas de caja negro se crean manteniendo sólo las especificaciones y
requisitos en mente. No caso de prueba se crea para comprobar la lógica
interna del software. El probador solo se alimenta en las entradas y
controles de la salida de estos valores válidos y no válidos.

18
Pruebas de Caja Blanca
A diferencia de las pruebas de caja negro, pruebas de caja blanca se lleva
a cabo en profundidad al nivel del código fuente. En esta forma de probar
la lógica interna, su aplicación y de trabajo se examina y los casos de
prueba se escriben para comprobar la forma en que el software está
trabajando a nivel interno. pruebas de caja blanca se puede llevar a cabo a
nivel de unidad, integración y nivel de sistema. pruebas de caja blanca se
utiliza con frecuencia para detectar errores de diseño internas que de otro
modo son muy di fi culto para descubrir sin embargo, este tipo de pruebas
no comprueba los requisitos faltantes o especificaciones.
Pruebas de Caja Blanca
Cobertura declaración
la cobertura de sentencias es una forma de poner a prueba en el que se
prueba el código de tal manera que cada estado de
el código se ejecuta al menos una vez. La idea detrás de este tipo de
prueba es asegurar que cada declaración en cada bloque de código se
ejecuta al menos una vez y se observan los resultados. Esta forma de
prueba también se conoce como cobertura de línea o segmento forma la
cobertura de las pruebas.
El punto a destacar aquí es que se ejecuta cada vez comunicado que
significa que puede haber algunas condiciones de algunos bloques que no
puede hacerse la prueba de esta manera. Por lo tanto existe la posibilidad
de que algunos errores pueden pasar desapercibidos en el proceso de
cobertura de sentencias.
Cobertura decisión
la cobertura de decisión o de ofertas de cobertura de la rama con las
pruebas de todas las condiciones verdaderas y falsas del código. La razón
por la cual también se le llama cobertura de sucursales se debe a una rama
es un resultado de la decisión. Se considera que es un correo ff forma más
reflexiva de probar que la cobertura simple declaración. Una declaración
decisión puede ser:
Una declaración 1 SI
2 Una declaración de control de bucle tales como do-while 3 Una
declaración de que puede tener dos o más
los resultados también conocido como instrucción CASE.
19
Lo bueno de la cobertura de decisión es que usted es capaz de validar Por ejemplo:
todas las ramas en el código y es capaz de comprobar la eficiencia e fi
del código de una manera mejor que enfoque la cobertura de Si (x = true o Y = true) Luego
sentencias. de impresión ( “Hola”) Else
Print ( “adiós”)
Cobertura condición
Condición para pruebas de rendimiento se lleva a cabo para verificar las
condiciones que generalmente son expresiones booleanas y dar resultado
en VERDADERO o FALSO. la cobertura condición puede o no puede cubrir Aquí, en este caso hay cuatro condiciones posibles combinaciones:
toda la cobertura de decisión. En este proceso se prueban sólo aquellas
condiciones que devuelven verdadero o falso. Las expresiones que
devuelve una condición booleana general juega un papel muy importante en Testcase1: x = true; y = verdadero

la decisión final. Esta es la razón por la cobertura de las pruebas de Testcase2: x = true; y = false Testcase3:

condición se lleva a cabo. x = false; y = verdadero Testcase4: x =

false; y = false

Decisión / Cobertura Condición Del mismo modo, durante 3 expresiones habrá 8 combinaciones de
Como su nombre indica metodología de cobertura de decisión / condición condiciones.
incluye probar todas las decisiones y todas las condiciones lógicas con todos
los escenarios posibles que pueden generar un resultado verdadero o falso.
Se considera que es una forma muy fuerte de las pruebas de software.

Cobertura Múltiple Condición

Mul t IPLE condi t ion cobertura o t cobertura combinación ion condi se
lleva a cabo para comprobar de salida para múltiples combinaciones
de condiciones.

20
 detectaron que pueden ser fácilmente recti fi cado y la calidad del software se
Fundamentos de Pruebas de pueden mejorar. Por lo tanto, las pruebas de software es necesario para que

Software las aplicaciones libres de errores pueden ser desarrollados y entregados.

Cuando una empresa decide desarrollar un software para un cliente hay ciertas
especificaciones de la industria-fi requisitos legales, contractuales y c Sobre la
Las pruebas de software es un tema muy amplio. Hay aplicaciones de
base se hizo el trato. Una empresa consciente de la calidad será de fi
software y sistema de ingeniería para numerosas industrias y
nitivamente incluyen pruebas de software en sus mejores prácticas.
dominios, y por un probador, cada proyecto de la prueba es un nuevo
reto, porque tiene que entender el punto de vista y el dominio del
cliente antes de continuar con las actividades de prueba. A partir de un
proyecto a otro, un probador puede tener que cambiar las
Es dif'ıcil decir la cantidad de pruebas es suficiente, pero el hecho es
metodologías de prueba también. Por eso es muy importante
que si la prueba se planea cuidadosamente y se hacen buenos casos
mantener los fundamentos derecha. Obtención de los fundamentos de
de prueba, entonces es muy posible para entregar software de alta
derecho en el primer lugar es el mayor requisito previo para tener éxito
calidad.

en el software
¿Quién hace las pruebas de software?
pruebas.
A menudo hay un debate sobre quién en realidad debería probar el software. La

gente a menudo se preguntan por qué los desarrolladores que no están autorizados
¿Por qué pruebas de software es necesario?
a prueba. Bueno, un desarrollador comprueba generalmente sus tiempos de código
Un error, defecto o un error puede ser causado por los desarrolladores. No
de varios antes de que lo somete a la prueba y todavía en la mayoría de los casos
es intencional, pero teniendo en cuenta la complejidad con la que distintos
nunca se libre de errores debido a que un desarrollador está generalmente ciego a
programas informáticos se están desarrollando en estos días, es muy
sus propios errores.
posible que un desarrollador no comprender e implementar la lógica
equivocada y producir un código incorrecto.

Un probador por el contrario se ve en el software desde el punto de

vista del cliente. Él es imparcial y su atención se centra sólo en el
La prueba es necesaria, ya que nos ayuda en la identificación de los defectos en
pliego de condiciones y la
el software. Una vez que estos defectos han sido

21
requisitos. Por lo tanto, un probador es capaz de mirar hacia áreas que t iempo Scenar io donde el software de wi ll ser implementado puede
un desarrollador ha ignorado. Por lo tanto, la prueba siempre debe ser ayudar a entender el probador de cómo llevar a cabo las pruebas para el
llevada a cabo por los probadores independientes. Este enfoque tiene proyecto. Es muy importante saber lo que tiene que ser puesto a prueba
algunas desventajas. Cuando el desarrollo y equipos de pruebas son di con el fin de diseñar una estrategia de ensayo.
ff Erent a menudo hay una falta de comunicación y, a veces, los
desarrolladores se convierta en descuido hacia la codificación y no
revisar su código porque piensan que todo es el trabajo de un probador
lo que aumenta la carga en el probador.

Muchos desarrolladores veces compartir su trabajo entre sí y poner a

prueba el trabajo del otro. Esto se conoce como la prueba de amigos.
Cada equipo de desarrollo debe tener probadores dedicados y cada
proyecto en general tiene al menos un equipo de pruebas dedicado.
Algunas empresas creen en tener equipos separados para di ff tipos Erent
de pruebas, este medio di ff equipos Erent para la facilidad de uso,
rendimiento, seguridad y otras formas de pruebas. Algunas empresas
creen en la externalización de software de pruebas de trabajo que
significa que contratar a un fi rme o probadores o consultores
independientes para echar un vistazo a su proyecto y probar.
Lo que tiene que ser realmente una prueba?

Cuando se hace el Software Testing?

El anterior equipo de pruebas comienza las pruebas del software más fácil
Lo que tiene que ser realmente una prueba?
que sería para los desarrolladores para completar el proyecto a tiempo y
El probador debe tener un buen conocimiento acerca de los requisitos del
esto también ahorrar una gran cantidad de tiempo, dinero y e ff ORT. A
proyecto. Una idea clara acerca de la verdadera
partir de pruebas

22
en las etapas posteriores del desarrollo puede llegar a ser un asunto
caro, ya que es muy dif'ıcil para corregir defectos una vez que el
software ha alcanzado las etapas finales de desarrollo de software
development.Dividing en etapas y el trabajo a continuación, las pruebas
realizadas en cada etapa antes de pasar a la siguiente etapa de
acabado ayuda en el desarrollo de software en el tiempo con buenos
resultados. Esto también ayuda a una mejor integración de los módulos
di ff Erent porque ya sabes que cada módulo ha sido probado de forma
independiente y está funcionando según las especificaciones dadas.

¿Con qué frecuencia necesitamos prueba Para?

¿Con qué frecuencia usted necesita prueba depende de la importancia

de la calidad es para usted. Idealmente, la prueba debe ir de la mano
con el desarrollo y un probador debe centrarse en el descubrimiento
de número máximo de defectos durante las fases iniciales de
desarrollo de software de manera que si el diseño del software ¿Con qué frecuencia necesitamos prueba Para?

requiere ningún cambio, entonces puede hacerse temprano, ya que

será muy di fi culto y caros de hacer grandes cambios en el proyecto ¿Cuáles son las normas de pruebas de software?

durante las etapas posteriores del desarrollo.
normas de pruebas de software son de gran importancia desde el
consumidor Es así como el punto de vista del productor. Un
consumidor invierte en el software y si el software es de buena calidad,
entonces al final del día en que se satisface que ha comprado lo
correcto para sí mismo.

23
Todas las empresas de renombre aseguran que la calidad del software
del producto se rige por algunos conjuntos de normas que han sido
aprobados por el público. Al seguir estas normas una empresa da
garantías sobre sus productos y es capaz de dar garantía a sus
clientes sólo cuando se ha seguido algunas normas y sabe que el
software se comportará de una manera determinada. Por lo tanto, el
consumidor sabe que está comprando lo correcto si se trata de la
norma correcta.
Desde el punto de vista de las normas de un productor ayudar en la
mejora de la calidad del producto fi nal. Una vez que una empresa ha fi
nalizado el estándar que tiene que seguir a continuación, se hace más
fácil para ellos para trabajar en otros proyectos de software y cada vez
que se inicia un nuevo proyecto que no es necesario empezar todo de
scratch.There muchos tipos de estándares de pruebas de software de fi
nido para evaluación de la calidad del software que puede mejorar en
gran medida el e ff cacia de las pruebas de software, sin embargo se cree
que hasta ahora se han hecho tales patrones que pueden cubrir todos los
aspectos de las pruebas de software.
Normas que hacen hincapié en tener las pruebas como parte del
requisito más grande o más normas de apoyo
las pruebas de software son los que pueden ser de utilidad para las pruebas de
software.
Qué es el software Comprobabilidad?
la capacidad de prueba de software se utiliza para medir la facilidad con un
sistema de software puede ser probado. La capacidad de prueba se calcula en
las primeras fases de desarrollo de software con el fin de hallar cuántos recursos
serán necesarios para fi nal del proceso de prueba. Mientras que la prueba
ayuda en la detección de deficiencias, la capacidad de prueba juega un papel
significativo en la identificación de las áreas clave en las que los insectos
permanecen ocultas a la vista de un probador. Cuando la capacidad de prueba
es alta significa que la prueba es más fácil y más bajo significa la capacidad de
prueba que la prueba e ff ORT se debe aumentar. La capacidad de prueba
puede ser determinada por:
1 controlabilidad: proceso de pruebas puede ser optimi-
zeta sólo si podemos controlarlo. 2 Observabilidad: Lo que ves
es lo que puede ser
probado. Factores de un ff ión de la fi nal resultados son visibles.
3 Disponibilidad: Con el fin de poner a prueba un sistema que tenemos
para llegar a ella.
4 Simplicidad: Cuando el diseño es auto-consistente,
características no son muy complejas y prácticas de codificación son
simples entonces hay menos de prueba.
24
 Cuando el software no es sencilla ya que se convierte en dif'ıcil
a prueba.
5 Estabilidad: Si se producen demasiados cambios a la
Diseñar vez en cuando habrá gran cantidad de interrupciones en las
pruebas de software. 6
Información: e fi ciencia de las pruebas en gran medida depende de
la cantidad de información está disponible para el software.
Esto es lo que necesita saber acerca de la capacidad de prueba: 1 más alto significa la
foco de Veri fi cación está en la calidad del software que se está
desarrollando, si sigue todas las normas o no, está bien diseñado?
Así, mientras que las comprobaciones de validación si el pliego de
condiciones han sido correctamente diseñado para satisfacer las necesidades
del cliente, los cheques de veri fi cación si el software ha sido desarrollado de
acuerdo con las reglas y normas de la organización de ingeniería de software
de calidad de software.

capacidad de prueba mejores pruebas y menos

cantidad de errores

2 Baja capacidad de prueba significa que las pruebas no son de

gran calidad y existe la posibilidad de más errores en el

sistema de

Software de Veri fi cación VS software de validación

La verificación y la validación son dos términos muy importantes en las
pruebas de software. La gente a menudo se confunden entre los dos sin
embargo, estos dos términos están relacionados con dos tipos di ff Erent de
análisis. La validación se ayuda en la construcción del sistema de derecho.
Mientras lleva a cabo la validación nos fijamos en si el sistema está en línea Software de Veri fi cación VS software de validación
con los requerimientos del cliente o no.

Algunas teorías sugieren que la veri fi cación se lleva a cabo en cada

fase del ciclo de vida de desarrollo de software, pero la misma no es el
La verificación por el contrario ayuda a garantizar que el sistema está caso con la validación. Validaciones son cruciales en el principio y
siendo desarrollado de la manera correcta. los hacia el final de

25
el proyecto, es decir, durante la prueba de análisis de requisitos y la
aceptación. Esta táctica no es totalmente correcta y casi imposible de
seguir. La realidad es que hasta hoy se ha observado que es muy
dif'ıcil para capturar todo el conjunto de las necesidades del cliente
durante el inicio del proyecto. Requisitos de software suelen someterse
a varios cambios incluso después de que el desarrollo ha comenzado.
Muchas veces los cambios son solicitados por el equipo de desarrollo
propio. Por tanto, es importante llevar a cabo los procesos de
fiscalización validación y en todas las fases de desarrollo de software.
Hoy en día, los probadores suelen tener en cuenta Veri fi cación y validación
también conocido como V & V como una poderosa manera de mirar varios
aspectos del software.
Pruebas de software VS software de depuración
Este es otro tema en el que la gente en general se confunden. Las
pruebas de software y depuración pueden sonar como una y la misma
cosa, pero eso no es realmente el caso. Para empezar, el proceso de
depuración se inicia cuando las pruebas de software se vuelve más.
Mientras que las pruebas de software defectos destapa, la depuración
de defectos elimina del sistema.
Una vez que la prueba se haya completado los probadores faciliten los
informes y el equipo de desarrollo empieza a buscar la causa de los
defectos. En este proceso, el desarrollador escanea todos los módulos y
trata relacionados Para averiguar el problema en el código; una vez hecho
esto ya es hora de rectificar el defecto. Por lo tanto, la depuración es el
proceso en el que la causa de defectos notificados se encuentra fuera y
luego defectos son rectos paso fi ed a paso. La depuración es el proceso
de resolver los problemas existentes.
No sabia para rectificar un defecto hasta que todas las posibles razones
detrás de él se conoce por completo. Si se inicia la depuración sin un
conocimiento completo sobre el defecto, hay posibilidades de que en el
proceso de rectificación de un defecto que puede introducir algún otro en
cualquiera de los módulos relacionados entre sí. Los desarrolladores
deben evitar la experimentación en el momento de la depuración ya que
esto puede causar muchos problemas. Una vez que un defecto es fi ja el
promotor presenta la obra al probador, que va a probar a fondo todo el
módulo. 1 Software de prueba descubre defectos y
depuración localiza y corrige. 2 Las pruebas de software es un
aspecto muy importante de
sof tware desarrollo CYC Le mientras que la depuración es el
resultado de actividades de prueba.
26
 Prueba 3 comienza poco después del comienzo de desarrollo.
La depuración de los probadores se inicia cuando comienzan los defectos de

notificación.

4 Las pruebas de software implica veri fi cación y

validación (V & V) del software de depuración mientras que
mira adentro a causa real detrás del defecto y lo corrige.

¿Qué es un defecto?
Defecto es cualquier cosa que no esté en línea con el requisito de
software especí fi caciones. Defecto generalmente existe ya sea en el
código del programa o en su diseño. Esto se traduce en una salida
incorrecta en el momento de ejecución del programa.

1 Un trozo de código se llama con errores cuando se tiene demasiado

muchos defectos.

2 Bug informa de los detalles acerca de la naturaleza de la

error. ¿Qué es un defecto?

3 seguimiento de fallos de herramientas se emplean para insectos de la pista

en un sistema. ¿Cuáles son de gravedad y prioridad?

4 Existe una técnica muy interesante en las pruebas
que los defectos se inyectan a propósito en el código y luego el
resultado se supervisa para comprobar si el sistema funciona
como se espera en caso de ciertos temas.
La severidad de fi ne qué tan grave será el impacto de un defecto en el
rendimiento del sistema. La severidad puede ser de uno de los
siguientes tipos: 1 crítico: Tal defecto no permite la
aplicación para que funcione correctamente debido a un fallo del sistema o

corrupción de datos. defectos críticos hacen

27
 No se permita al usuario moverse más allá y los pone en una
posición miserable.
2 Mayor: Los principales defectos son poco menos severa
de defectos críticos. Ellos pueden hacer que falle el sistema, sin
embargo, en caso de defecto principal hay otra posible vía para
alcanzar el resultado deseado y el usuario no necesita recibir
entrenamiento para esto.
3 Moderado: Estos defectos no hacen que el
sistema falle, sino producir una salida errónea o contradictoria.
2 Medio: El defecto debe resolverse pronto
después se han resuelto los defectos con mayor prioridad.
3 de alta: el defecto con medios de alta prioridad que
que requiere atención inmediata y debe ser resuelto lo más
pronto posible.
Así, una vez que se le proporciona el informe de la gravedad y la
prioridad de los defectos Esto es lo que necesita saber:

4 Menor: Los defectos que no causan un fallo del sistema

o una ff ect la facilidad de uso del sistema y puede ser fácilmente rectos ed

fi son conocidos como defectos menores. 5 cosméticas: Los defectos

relacionados con las perspectivas o

apariencia del sistema se denominan defecto cosmético.

Cuando se informa de un defecto, el informe de la prueba menciona

prioridad junto con la gravedad del defecto. Prioridad en realidad le dice
al desarrollador el orden en que los defectos deben ser resueltos. Puede
ser de los siguientes tipos:

1 Bajo: el defecto no requiere inmediata

¿Cuáles son de gravedad y prioridad?
atención y debe ser rectificada fi cado después de que los
defectos con mayor prioridad se han resuelto.

28
1 Si un defecto tiene alta prioridad y alta severidad, entonces
significa que hay un problema en la funcionalidad básica del
sistema y el usuario no está en condiciones de utilizar el
sistema. Tales defectos deben ser rectos fi ed inmediatamente.
2 Los defectos que tienen alta prioridad y baja severidad

puede ser algo como error de ortografía en el nombre de la

empresa o problemas con el logotipo. Tales defectos son de
baja severidad, pero deben ser rectos ed fi inmediatamente y
deben considerarse como defecto de alta prioridad.

3 de alta gravedad y el medio de defecto de baja prioridad

que hay un defecto importante en algún módulo, pero el usuario
no sería utilizar de inmediato por lo que el defecto puede ser recti fi
có un poco más tarde. 4 defectos de baja prioridad y de baja
severidad son
generalmente cosmético en la naturaleza y no un ff ect la
funcionalidad del sistema, por tanto, tales defectos son rectos
ed fi en el final.

29
 • Basándose en la información adquiridos en la etapa anterior
Funciones y responsabilidades de decidir cómo se va a ensayar.
•
pruebas de software Informar al conductor de prueba sobre lo que serán necesarios todos los

recursos para las pruebas de software.

• Desarrollar casos de prueba y actividades de prueba priorizar.

En el caso de las pruebas de software todas las empresas de fi ne su propio nivel

de jerarquía, funciones y responsabilidades, pero en un nivel más amplio, si se

• Ejecutar todos los casos de prueba y los defectos del informe, definen la
toma un aspecto que será siempre encontramos los dos niveles siguientes en un
gravedad y la prioridad de cada defecto.
equipo de pruebas de software:
• Llevar a cabo pruebas de regresión cada vez que se realizan
cambios en el código para fi x defectos.

Prueba de plomo / gerente: Una prueba de plomo es responsable de:

Vista general del software del equipo de ingeniería
• De fi nir las actividades de prueba para los subordinados
¿Cómo da forma a una aplicación de software durante el proceso de
- probadores o ingenieros de pruebas.
desarrollo depende enteramente de la forma en que el equipo de
• Todas las responsabilidades de planificación de las pruebas.
ingeniería de software organiza el trabajo e implementos diferentes
• Para comprobar si el equipo cuenta con todos los recursos necesarios
metodologías. Para que una aplicación se desarrolla adecuadamente, es
para ejecutar las actividades de prueba.
importante que todos los procesos incorporados durante el desarrollo de
• Para comprobar si la prueba va de la mano con el desarrollo de
software son estables y sostenibles. Muchos desarrolladores veces
software en todas las fases.
vienen bajo presión a medida que la fecha de entrega se acerca más
• Preparar el informe de estado de las actividades de prueba.
cerca de esto a menudo una ff refleja la calidad del software. Corriendo a
• Las interacciones con los clientes requeridos.
través de los procesos a fi nal del proyecto a tiempo sólo se producirá
• Actualización de director del proyecto con regularidad sobre el progreso de
una aplicación de software que tiene un uso mínimo o nulo para los
actividades de prueba.
clientes. Por lo tanto, la organización del trabajo y la planificación es
importante y seguir con el plan es muy importante. El director del
Los ingenieros de prueba / probadores QA / QC probadores son responsables
proyecto debe asegurarse de que no existen
de:

• Para leer todos los documentos y entender lo que necesita ser

probado.

30
obstáculos en el proceso de desarrollo y en todo caso hay un
problema que debe ser resuelto con una atención inmediata.
Vista general del software del equipo de pruebas
¿Qué tan pronto y lo bien que puede alcanzar sus objetivos de prueba
depende únicamente de las capacidades del equipo de pruebas. Dentro del
propio equipo de pruebas que es importante contar con la mezcla correcta de
los probadores que pueden e fi cientemente trabajar juntos para lograr los
objetivos comunes de ensayo. Mientras que la formación de un equipo para el
ensayo, es importante asegurarse de que los miembros del equipo de
jointlyhave una combinación de todos los conocimientos de dominio relevante
que se requiere para probar el software en fase de desarrollo.
Es muy importante asegurarse de que el equipo de pruebas de software
tiene una estructura adecuada. La jerarquía y funciones deben ser
claramente de fi nido y responsabilidades también debe estar bien de fi
nido y debidamente distribuido entre los miembros del equipo. Cuando el
equipo está bien organizado el trabajo se puede manejar bien. Si cada
miembro del equipo sabe qué tareas que él o ella tiene que realizar
entonces serán capaces de fi nal de sus funciones según sea necesario
dentro del límite de tiempo. Es importante hacer un seguimiento del
rendimiento de los probadores. Es muy importante comprobar qué tipo de
defectos de las
probador es capaz de descubrir y qué tipo de detecciones tiende a fallar.
Esto le dará una idea clara acerca de la gravedad de su equipo es sobre
el trabajo.
Todos los miembros del equipo deben trabajar juntos para preparar un
documento que claramente de fi ne las funciones y responsabilidades
de todos los miembros del equipo. Una vez preparado el documento de
la función de cada miembro debe comunicar claramente a todos. Una
vez que los miembros del equipo tengan claro quién va a manejar en
qué área del proyecto, a continuación, en caso de cualquier problema
será fácil determinar quién debe ser contactado.
Cada miembro del equipo debe contar con los documentos necesarios
que proporcionan información sobre cómo se organiza la tarea, qué
enfoque será seguido, cómo se programan las cosas, ¿cuántas horas
se han asignado a cada miembro y todos los detalles relacionados con
las normas aplicables y procesos de calidad.
Software Tester Rol
Un probador de software (ingeniero de pruebas de software) debe ser capaz de
diseñar conjuntos de pruebas y debe tener la capacidad de entender los problemas
de usabilidad. Se espera que un probador tal de tener un buen conocimiento de
pruebas de software
31
diseñar y metodologías de ejecución de pruebas. Es muy importante para un
probador de software que tiene grandes habilidades de comunicación para
que pueda interactuar con el equipo de desarrollo e fi cientemente. Las
funciones y responsabilidades de un probador de software de usabilidad son
los siguientes:
1 Un probador de software es responsable del diseño
probando escenarios para las pruebas de usabilidad. 2 Es el
responsable de la realización de la prueba,
a partir de entonces analizar los resultados y luego presentar sus
observaciones al equipo de desarrollo. 3 Él puede tener que
interactuar con los clientes a
entender mejor los requisitos del producto, o en caso de que el
diseño requiere ningún tipo de modi fi caciones.
4 probadores de software a menudo son responsables de
la creación de documentación de prueba de producto y también tiene que
participar en la prueba de caminata a través relacionada.
Un probador de software tiene di ff conjuntos Erent de funciones y
responsabilidades. Él debe tener un conocimiento profundo acerca de las
pruebas de software. Él debe tener una buena comprensión sobre el sistema
que significa técnica (interfaz gráfica de usuario o de las interacciones humanas
no GUI), así como los aspectos funcionales del producto. Con el propósito de
crear
casos de prueba, es importante que el software probador es consciente
de las diversas técnicas de prueba y qué método es el mejor para un
sistema particular. Él debe saber cuáles son las diversas fases de
pruebas de software y pruebas de cómo debe llevarse a cabo en cada
fase.
Las responsabilidades del software probador incluyen: 1 Creación de diseños
de prueba, los procesos de prueba, test
casos y datos de ensayos.
2 Llevar a cabo las pruebas de acuerdo con la de fi nida dimientos
res.
3 Participar en recorridos de prueba dimientos
res.
4 Preparar todos los informes relacionados con las pruebas de software
llevado a cabo.
5 Asegúrese de que todos los trabajos relacionados probado se lleva
cabo de acuerdo con las normas y procedimientos de fi ne.
El papel del software Administrador de pruebas
La gestión o la dirección de un equipo de prueba no es una tarea fácil. La
compañía espera que el director de pruebas para saber probando
metodologías en detalle. Un director de pruebas tiene que tomar
decisiones muy importantes en relación con el medio ambiente ing
prueba que se requiere, cómo la información flujo sería administrado y
cómo probar procedimiento sería ir de la mano con el desarrollo.
32
Él debe tener un buen conocimiento acerca tanto manual como
automatizado de pruebas para que pueda decidir cómo tanto las
metodologías se pueden juntar para probar el software. Un gestor de
prueba debe tener un buen conocimiento sobre la zona de negocios y
el requisito del cliente, basado en que él debe ser capaz de diseñar
una estrategia de prueba, meta y los objetivos de prueba. Él debe ser
bueno en la planificación de proyectos, tareas y personas de
coordinación, y él debe estar familiarizado con los diferentes tipos de
herramientas de prueba. Muchas personas se confunden entre las
funciones y responsabilidades de un administrador de prueba y prueba
lead.For una aclaración, un conductor de prueba se supone que tiene
una experiencia técnica que incluye, programación, manejo de
tecnologías de bases de datos y varios sistemas operativos, mientras
que él no puede ser tan fuerte como el software Administrador de
pruebas en relación con la gestión y coordinación de proyectos de
prueba.
1 Dado que el director de pruebas representa el equipo que él
es responsable de todo interdepartamental
reuniones. 2
La interacción con los clientes cuando sea necesario.
3 Un director de pruebas es responsable del reclutamiento
las pruebas de software y siguientes sta. Él tiene que supervisar todo
Las actividades de prueba llevadas a cabo por el equipo e identificar los
miembros del equipo que requieren más capacitación.
4 Calendario de Pruebas actividades, presupuesto para crear
de prueba y preparar e ff prueba ORT estimaciones. 5 Selección de los
instrumentos de medida adecuados después de interactuar
con los vendedores. Integración de las actividades de prueba y
desarrollo. 6 Carry cabo mejora proceso de prueba continuo
ment con la ayuda de las métricas. 7 Compruebe la calidad de
los requisitos, lo bien
que están de fi nidas.
8 procedimientos de prueba de rastreo con la ayuda de la prueba
matriz de trazabilidad.
Test Software Automator Rol
automator prueba de software o un ingeniero de pruebas automatizado
deben tener muy buena comprensión de lo que necesita para diseños de
interfaz gráfica de usuario, los Ensayos de carga o las pruebas de estrés. Él
debe ser pro fi ciente en la automatización de pruebas de software, y él debe
ser capaz de diseñar conjuntos de pruebas en consecuencia. Un automator
pruebas de software deben ser cómodos usando varios tipos de
herramientas de automatización y debe ser capaz de mejorar sus habilidades
con las tendencias cambiantes. También debe tener conocimientos de
programación para que sea capaz de escribir scripts de prueba sin ningún
problema. los
33
responsabilidades de un probador en esta posición son los siguientes:
1 Él debe ser capaz de entender el
procedimientos y requisitos de prueba de diseño y casos de prueba
para las pruebas de software automatizado. 2 Diseño scripts de prueba
automatizados que son
reutilizable.
3 Asegúrese de que todos los ensayos automatizado relacionado
las actividades se llevan a cabo según los estándares definido
por la empresa.
Las interacciones entre el software de prueba del equipo y Negocios
Equipos
Si es un cliente tiene cualquier problema relacionado con las
actividades de ensayo y las cuestiones operativas del proyecto,
entonces es el software de prueba gerente que es responsable de
comunicar los datos al cliente con respecto a cómo se están
manejando las cosas. El director de pruebas de software no sólo
responde a las consultas de los clientes, sino que también asegura
que el proyecto se termine a tiempo según el requisito del cliente.
Las interacciones entre el equipo de equipos de desarrollo y prueba de
software
Con el fin de producir buenas aplicaciones de software, es importante
que los equipos de pruebas de software y desarrollo de software
trabajan juntos con un buen entendimiento. Para ello, es importante
que los probadores y desarrolladores se sienten cómodos con papel
de cada uno y entender bien que tienen un objetivo común y es sabio
escuchar entre sí. Una buena habilidad de comunicación es muy
importante tanto para los probadores y desarrolladores.
Antes de comenzar con la prueba de trabajo es importante para
discutir las directrices y expectativas básicas para que no haya
confusión en las etapas posteriores. La crítica debe ser tomada en un
sentido positivo. Es importante entender que los desarrolladores y
probadores tienen un objetivo común de producir software de alta
calidad. Un probador no es el descubrimiento de errores para mostrar
a alguien, la idea es aprender de los errores y no repetirlos en el
futuro. Una cultura de la crítica constructiva puede ser de gran ayuda.
Las interacciones entre el software de prueba del equipo y la liberación de los
equipos de gestión
Los equipos de gestión de versiones son responsables de mover el
software de desarrollo en
34
producción. Este equipo es responsable de la planificación de los director del proyecto y proporcionar el apoyo necesario en la planificación y
lanzamientos de hardware, software y pruebas. También es responsable programación de proyectos para que el proyecto puede completarse con éxito
del desarrollo de los procedimientos de desarrollo de software y de la en el tiempo dentro de los límites especi fi cado financiero del presupuesto.

coordinación de las interacciones y la formación de los comunicados. Las
pruebas de software se considera que es un aspecto muy importante del
ciclo de vida de ingeniería de software, pero no consigue más con el
desarrollo. Las pruebas y la verificación es una parte muy importante del
ejercicio de gestión de versiones.

Las interacciones entre Software Test Manager y el Administrador

de Proyectos
El trabajo de un director de pruebas de software no es una tarea fácil. Él tiene
que reclutar equipo de pruebas y asumir la responsabilidad de conseguir los
entrenaron. Un administrador de software tiene que realizar un análisis continuo
de los diversos procesos de prueba y asegurarse de que el equipo de pruebas
está llevando a cabo todos los procesos correctamente. Este trabajo es de gran
responsabilidad como gerente de pruebas de software es el que selecciona,
introduce y poner en práctica diversas herramientas para la prueba. Un director
de pruebas de software es responsable de las plantillas de la fi nalización de
documentos de pruebas, informes de pruebas y otros procedimientos.

Desde un gestor de probador de software tiene que lidiar con todos los
detalles de diversas actividades de prueba, que es muy importante para él
estar en contacto constante con el

35

Los métodos de pruebas de software
Hemos discutido cuadro negro y caja blanca técnicas de la sección 3.
Aquí echamos un vistazo a algunas de las metodologías más pruebas
pruebas:
• Pruebas de Caja Gris
• Prueba incremental
• Prueba de enhebrar
Pruebas de Caja Gris
Cuando las metodologías de pruebas de caja negra y metodologías de
pruebas de caja blanca se utilizan en una combinación de pruebas de
software entonces se llama la prueba de caja gris o gris. Este tipo de
prueba se verá en los aspectos lógicos, así como funcionales del
software. En esta forma de probar el probador tiene poco y no un
conocimiento profundo de lo que se supone que el código para hacerlo.
Idealmente, el probador debe saber acerca de las estructuras de datos y
algoritmos internos.
pruebas de caja gris se lleva a cabo cuando hay una necesidad de probar
ambos lados del software (funcionales e internos de una sola vez). El probador
debe ser capaz de escribir casos de prueba que pueden probar el software a
fondo con la ayuda de datos que se pueden comprobar todos los posibles
lógica interna también.
pruebas de caja gris es una forma muy inteligente de las pruebas, donde se
espera que el probador de conocer la funcionalidad, la arquitectura del
software, cómo los datos serían flujo y la forma en que se maneja
excepciones. Para proyectos de gran tamaño siempre es mejor a la
automatización de pruebas para comprobar incorporar la funcionalidad y la
interfaz de usuario de la aplicación ya que esto podría ahorrar una gran
cantidad de tiempo y el probador no se sentirá demasiado estresado.
Prueba incremental
prueba incremental entra en el cuadro una vez que el probador ha
completado las pruebas de unidad. Este tipo de prueba se utiliza en la
integración de las pruebas donde hay necesidad de comprobar cómo
varios módulos independientes interactúan entre sí. En esta forma de
poner a prueba los desarrolladores se les pide a los módulos
correspondientes utilizando sistemáticamente talones o controladores.
Esta forma de la metodología de las pruebas de integración se conoce
como la prueba incrementales. prueba incremental puede clasificarse en
tres tipos:
1 De arriba hacia abajo integración: En este caso el
la integración de los módulos se realiza de arriba hacia abajo. Todos
los módulos que no están disponibles se sustituyen por los talones.
2 hasta la integración inferior: En este caso el
la integración de los módulos se realiza desde
36
 abajo hacia arriba. Todos los módulos que no están disponibles son
reemplazar por los conductores.
3 incrementales funcional: esta forma de prueba
se lleva a cabo de acuerdo con los documentos fi caciones
funcionales. La integración de los módulos y su prueba se lleva a
cabo de acuerdo con el definido especí funcional fi cación.
La principal ventaja de la prueba incremental es que puede ayudar en la
detección de deficiencias muy temprano en el tiempo. La desventaja es que el
desarrollo de los talones y los controladores puede llevar tiempo.
Prueba de enhebrar
metodología de prueba de hilo se utiliza en las pruebas de aplicaciones
basadas en la arquitectura cliente-servidor. Un hilo es la unidad más
pequeña de trabajo que puede ser llevada a cabo por el sistema.
Durante las etapas iniciales de la integración de un sistema que es muy
importante saber si el sistema será capaz de llevar a cabo las tareas
funcionales requeridas como por la exigencia. Es muy importante
comprobar si el software será capaz de llevar a cabo todas las
transacciones como por la exigencia. La manera ideal de llevar a cabo
las pruebas de hilo es integrar hilos incrementalmente primera a nivel
de subsistema y luego en el nivel del sistema y después se prueba.
37
Los niveles de pruebas de software

Las pruebas de software tiene varios niveles. Sin embargo, en las

pruebas de software escala más amplia se pueden clasificar en (1)
Functionaltesting y pruebas (2) no funcional. Estos temas serán
discutidos en detalle.

Descripción general de niveles de Software Testing

Aquí vamos a entender los distintos niveles de la prueba, a saber:

• Examen de la unidad

• Pruebas de integración

• Prueba del sistema

Descripción general de niveles de Software Testing
• Test de aceptación

Examen de la unidad
Hay varios beneficios de las pruebas unitarias. En primer lugar, se
La parte más pequeña independiente y comprobable del código fuente se
obtiene la confianza para seguir adelante con la integración de la prueba
conoce como una unidad. Es el paso primero en el entorno de pruebas de
sólo cuando esté seguro de que todas las unidades están funcionando
software y por lo general se lleva a cabo por los desarrolladores o sus
correctamente. Al iniciar unidad de pruebas en paralelo con el desarrollo
compañeros de equipo. Este tipo de prueba se realiza con poca frecuencia por
que puede parecer un proceso lento, ya que muchos defectos son
los probadores de software. Con el fin de realizar pruebas de integración es
descubiertos durante esta etapa y se hacen varios cambios al código. Sin
importante primero completar la unidad de prueba para todas las unidades. Con
embargo, con el tiempo el código se re fi nida y el número de defectos
el fin de realizar pruebas unitarias que es importante contar con casos bien de
comienza a disminuir. Así, la fundación del software es fuerte y en la
Plan de pruebas fi nida y unidad de pruebas unitarias.
tarde etapas de la

38
desarrollo de software se lleva a cabo a un ritmo mucho más rápido lo que se
ahorra mucho tiempo.
Examen de la unidad
Si la unidad de pruebas se lleva a cabo adecuadamente, entonces también
daría lugar a una gran cantidad de ahorro como el costo de fi jar un defecto en
las etapas finales de desarrollo de software de costos son mucho mayores que
ellas fi jación en las etapas iniciales. Prueba de la unidad se realiza en el
componente más pequeño comprobable del proyecto por lo que el número de
casos de prueba y datos de prueba son menos, y no siempre es posible
comprobar todos los escenarios para el dia y la información de flujo de la
aplicación de software. Por lo tanto, hay muchos casos de prueba que se
pueden probar sólo después de la
la unidad se ha combinado con otras unidades para formar un componente más
grande.
Pruebas de integración
Una vez que la fase de prueba de la unidad ha terminado, es hora de pasar
a las pruebas de integración. Durante la integración a prueba los controles
probador cómo una o más unidades interactúan entre sí y los productos de
salida para varios escenarios. Este tipo de prueba se lleva a cabo un
ingeniero de pruebas de software.
En esta forma de probar un montón de defectos relacionados con el
funcionamiento, los niveles de exigencia y rendimiento están al descubierto.
Unidad de prueba con fi rms que varias unidades son capaces de realizar
como por la exigencia de forma individual, pero rms pruebas de integración
con fi si estas unidades independientes son capaces de realizar de acuerdo
con las expectativas una vez integrados. Las pruebas de integración puede
ser en términos generales clasificarse en: 1 Big bang 2 arriba hacia abajo y 3
enfoque hasta Bottom
Como el nombre sugiere, la forma de explosión grande de pruebas de todos los
módulos se combinan para formar un sistema completo y luego la prueba de
errores.
39

Pruebas de integración
De arriba hacia abajo es enfoque sistemático donde los módulos de nivel
superior son primera prueba y, a continuación uno por uno el sub se añaden y
se ensayaron módulos. El enfoque bottom es justo lo contrario de arriba hacia
abajo. En este caso la mayoría de los módulos inferiores se prueban primero y
paso a paso se añaden y se ensayaron los módulos de nivel superior. En
general, el enfoque de abajo arriba es seguida en primer software de ensayo
seguido por la prueba de arriba hacia abajo.
De arriba hacia abajo y de abajo hacia arriba Pruebas de Integración
De arriba hacia abajo en la integración enfoque talones de prueba pueden
utilizarse como asas en caso de módulos o subprogramas que no están
disponibles o no listo. Estos son módulos ficticios utilizados en niveles
bajos. En forma similar, en el caso de aproximaciones a fondo es un
programa principal no está disponible, llamando programa referido como
conductor puede ser utilizado como un reemplazo para el proceso de
prueba completo.
Prueba del sistema
Una vez que la fase de pruebas de integración se completó con éxito es
el momento de pasar a las pruebas del sistema en el que el sistema en
su conjunto con todos los componentes bien integrados está listo para
realizar más pruebas. Aquí es donde el software no sólo es la prueba de
rendimiento, sino también para la adherencia a los estándares de calidad.
A medida que el sistema se prueba en su conjunto para ver si cumple
con las especi fi caciones funcionales y técnicas y los estándares de
calidad definido por la organización, es importante que este tipo de
prueba se lleva a cabo por un equipo de pruebas altamente calificado.
Para este tipo de pruebas es muy importante para crear un escenario
similar al escenario en tiempo real, donde se desplegará el sistema.
40
 software es la prueba de precisión. La prueba de aceptación se ve en
el sistema desde varios ángulos: recto, desde miradas cosméticos a
funcionamiento interno. Esta forma de prueba es muy importante
porque hay requisitos legales, así como contractuales asociados con el
software para que pueda ser aceptado por el cliente.

Las pruebas de aceptación puede ser de los tipos siguientes: Las pruebas de

aceptación 1 Usuario: Este tipo de prueba es

llevado a cabo por el propio usuario antes de aceptar el

Prueba del sistema
Las pruebas del sistema es la prueba de caja puramente negro. El
sistema se comprueba como por la exigencia especí fi caciones. La
prueba se lleva a cabo desde el punto de vista del usuario. Este tipo
software. Se puede realizar en el sitio del usuario o en la
organización de software donde se desarrolló el software.
pruebas 2 Operación de aceptación: esta forma de
la prueba se realiza para asegurar que todos los procesos y

de prueba se realiza para comprobar el comportamiento de la procedimientos están en su lugar para que el sistema pueda ser utilizado

aplicación, diseño de software y expectativas del usuario final. Sistema fácilmente y también puede mantener fácilmente.

de prueba valida y Veri fi que la arquitectura de aplicaciones y

requisitos de negocio del cliente.
Test de aceptación
Una vez que el sistema ha sido probado a fondo a través de la unidad, la
integración y las pruebas del sistema es el momento para el equipo de
control de calidad para venir y echar un vistazo al sistema y prueba para la
calidad con la ayuda de fi nida escenarios de prueba PREDE y casos de
prueba. los
3 Contrato y pruebas de aceptación de la regulación: es
llevado a cabo para asegurar que el software está en línea con
todas las normas del gobierno es necesario, legales y de
seguridad.
4 pruebas Alfa: se realiza para asegurar que la
el producto es de buena calidad y también para preparar el
sistema para pruebas beta. Este tipo de prueba se lleva a cabo
hacia el final del desarrollo de software en el que el sistema
puede

41
 ser probado como un todo. Esto puede ser un proceso largo
que los probadores están investigando calidad, así como la
ingeniería de los aspectos del software desarrollado. Este tipo
de prueba se lleva a cabo por los ingenieros de pruebas y
otros miembros del equipo y el producto se prueba desde el
punto de vista de un cliente.

5 Las pruebas beta: Una vez que el alfa de prueba es más,

pruebas beta sigue con el fin de mejorar la calidad del producto
y ver que el producto es según el requisito del cliente. Este tipo
de prueba se lleva a cabo un par de días o semanas antes del Test de aceptación

lanzamiento del producto. Las pruebas beta puede tomar unos

pocos días, pero no puede tomar tanto tiempo como alfa de
pruebas como las posibilidades de detección de defectos son
bastante bajos durante este tiempo. Se realiza en el escenario
del mundo real con la gente que realmente se va a utilizar el
producto.

42
 3 La salida de la solicitud de los datos de prueba
Tipos de pruebas de software proporcionado debe ser revisado según el funcional especí fi
cación de fi nido. 4 Los casos de prueba deben cubrir todas las
pruebas posibles
escenarios.
5 El resultado real para una entrada dada debe ser
grabado y se comprueba con la salida esperada.

Tipos de pruebas funcionales incluyen: 1 Unidad de

Pruebas 2

Tipos de pruebas de software Integración Testing 3

Sistema de prueba de 4 pruebas

Pruebas funcionales de regresión de 5 pruebas de

Las pruebas funcionales es una especie de prueba de caja negro, donde se aceptación

preparan los casos de prueba manteniendo las especificaciones en mente. Este

tipo de prueba se hace para verificar si el sistema se encuentra en compl iance Las pruebas no funcionales

wi th requisitos del cl ient 's. Básicamente en el caso de las pruebas funcionales En un sistema de software que hay muchos requisitos tales como el

los siguientes comprobaciones son importantes: rendimiento, la seguridad, la interfaz de usuario, etc., que no son funcionales
en la naturaleza sin embargo, es muy importante para poner a prueba estos

1 Las necesidades del probador a ser muy claro acerca de la atributos. Las pruebas de software llevado a cabo con los atributos de

funcionalidad que la aplicación se supone que debe realizar. 2 pruebas no funcionales de un sistema se llama la prueba no funcional. Los
tipos de metodologías de pruebas no funcionales son los siguientes: 1

Con el fin de probar la aplicación es muy importante contar con el Pruebas de rendimiento 2 pruebas de usabilidad 3 Pruebas de seguridad

conjunto adecuado de datos (válidos y no válidos entradas)

43
 4 Prueba de Portabilidad
Las pruebas de usabilidad
Las pruebas de usabilidad es un proceso en el que los probadores probar el
producto para comprobar lo fácil que sería para que el usuario utilice la
interfaz de usuario o en otras palabras, el software ha sido probado por su
facilidad de uso. Es una forma de pruebas de caja negro. El software ha sido
probado por tres cosas: (1) Que conveniente que el software será para el
usuario? (2) ¿El usuario podrá usarlo? (3) ¿El usuario será capaz de
aprenderlo?
Usabilidad presenta los siguientes aspectos asociados a ella:
• La facilidad con que los usuarios pueden adaptarse al sistema la primera
vez que tratan de utilizar el sistema.
• ¿Cómo e fi ciente del sistema es que el usuario? La ciencia e fi
del sistema depende en gran medida de la rapidez con la que
los usuarios son capaces de realizar sus tareas.
• ¿Qué tan fácil o di fi culto que es para los usuarios trabajar en un sistema
cuando llegan a usarlo después de un largo período de tiempo.
• ¿Los usuarios se encuentran errores? Si es así, la facilidad
con que son capaces de salir de la cuestión?
• ¿Es capaz de proporcionar satisfacción a sus usuarios?
Pruebas de usabilidad asegura al usuario final que el software es de
buena calidad y fácil de usar. Este tipo de pruebas muy esencial con el
fin de satisfacer a los clientes y tiene que ser planeado así. Si se
planifica adecuadamente, esta actividad puede ser altamente
beneficioso y económico. Puesto que el software se utiliza de manera
aleatoria en este tipo de pruebas, muchas veces se descubre defectos
que han escapado a los procedimientos normales de prueba.
Prueba de Interfaz Gráfica de Usuario
La forma de prueba llevado a cabo con la prueba si la interfaz gráfica de usuario de
una aplicación está funcionando en la forma correcta se denomina interfaz gráfica de
usuario o pruebas de la interfaz gráfica de usuario. La interfaz gráfica de usuario no
sólo se comprueba la funcionalidad adecuada, sino también por su adhesión a las
normas de fi nido de calidad. Las siguientes son algunas de las cosas más
importantes que deben ser verificados durante las pruebas de interfaz gráfica de
usuario:
• Diseño
• Colores
• Fuentes
• Tamaño de fuente
• Etiquetas
• Funciones de las carpetas de prueba
• ¿Cómo se formatea el texto
44
 • subtítulos
• Botones
• Liza
• iconos
• Enlaces
• Contenido
• Teclas de atajo
• Reloj de arena mientras el sistema está procesando datos
Este tipo de prueba puede ser manual o automático de todo lo que es
conveniente para el probador. Las pruebas de interfaz gráfica de usuario a
veces se lleva a cabo por organizaciones de terceros y no por el equipo de
desarrollo o ensayo de la empresa.
No Interfaz Gráfica de Usuario de Pruebas
Interfaz gráfica de usuario es la apariencia de una aplicación. Ensayo
distintos de la apariencia de una aplicación nada como las interfaces
de líneas de comandos, procesos por lotes y diversos eventos que
desencadenan ciertos casos de uso en una aplicación de software
vienen debajo de la prueba interfaz de usuario gráfica no.
Pruebas de portabilidad
las pruebas de portabilidad se lleva a cabo a prueba de cómo el
cambio de ambiente cambia el rendimiento del software. Por ejemplo,
cómo funciona el software
en sistemas operativos di ff Erent o si se trata de una aplicación basada
en web, que sería comprobado para un rendimiento de di ff Erent
navegadores web. Este tipo de prueba es importante si el cliente tiene la
intención de utilizar la aplicación de software para más de una
plataforma.
Esta forma de prueba es un subconjunto de pruebas del sistema. Aquí, el
software puede ser instalado en más de un medio ambiente o sus
ejecutables se puede crear y ejecutar en di ff Erent plataformas. Con el fin
de llevar a cabo las pruebas de portabilidad sin ningún tipo de problemas,
es importante mantener todos los requisitos de portabilidad en cuenta al
diseñar y desarrollar el software. Este tipo de pruebas se realiza después
de las pruebas de integración. Es importante tener el entorno de pruebas
adecuado para llevar a cabo las pruebas de portabilidad.
La seguridad, la autenticación y la autorización de pruebas
Una aplicación de software ha sido probado para cualquier tipo de AWS fl
seguridad en las pruebas de seguridad. Autenticación y autorización se
considera que son dos aspectos muy importantes de las pruebas de
software. Es crucial para llevar a cabo este tipo de pruebas para
garantizar que el software es seguro y capaz de almacenar información
con fi dencial al cliente cuando sea necesario.
45
La autenticación es un proceso en el que se pide a la persona que
intenta acceder al software de un nombre de usuario y una contraseña.
Una combinación incorrecta de los dos parámetros indican que la
persona no es lo que se dice ser y no se le permite ir más allá. Se trata
de una comprobación de autenticación que asegura que las
credenciales de inicio de sesión de un uso autorizado aplicación de
software se comprueban.
Autorización por el contrario se trata de privilegios para utilizar ciertas
funciones limitadas de una aplicación de software. El hecho de que
haya pasado el proceso de autenticación no significa que haya sido
autorizado el acceso a todos los datos, características y casos de uso
en la aplicación de software. Por ejemplo, en el caso de los sitios de
medios sociales una vez que se alimenta en el nombre de usuario y la
contraseña correcta, sólo se puede acceder a los detalles de su cuenta
y no cualquier otra cuenta, además de eso.
Además de la autenticación y la autorización, las pruebas de seguridad
también se ocupa de la confidencialidad, integridad,
disponibilidad, no repudio, seguridad de datos de software, SQL de inserción fl
AWS, los ataques de cross-site scripting y otra preocupación relacionada con la
seguridad que es una completa di ff Erent sujeta experiencia cuestión por sí
mismo.
Los datos y base de datos Prueba de integridad
En pruebas de integridad de los datos que necesitamos para comprobar si los datos
almacenados en la base de datos es correcta y produce resultados de acuerdo con
las expectativas. Algunos de los cheques son muy importantes para la integridad de
los datos de prueba, como si es posible recuperar la información en blanco de la
base de datos o no, son datos validados adecuadamente antes de ser guardado en
la base de datos, se pueden actualizar los datos almacenados en la base de datos,
se le capaz de ejecutar pruebas para todo tipo de datos de archivos, etc. en otras
palabras, las pruebas de integridad de los datos se lleva a cabo para asegurar que
los datos sean exactos y consistentes durante todo su ciclo de vida.
la integridad de la base de datos sobre las otras ofertas de la mano con
las pruebas de todos los métodos y procesos necesarios que son
importantes para el acceso a la base de datos y la gestión de los datos
dentro. Se trata también de cómo se procesan todas las funciones de
métodos de acceso y datos. Los datos no deben se corrompe y no deben
recibir eliminado, actualizado o creado sin saberlo, y no debe haber casos
de prueba para hacer estas validaciones.
Tolerancia a fallos y de prueba de fallos
las pruebas de tolerancia a fallos se lleva a cabo para comprobar cómo
reaccionaría una aplicación si se produce algún fallo en el escenario en
tiempo real. En este tipo de pruebas de diversos escenarios se consideran
como error de conexión
46
con la red, problema de conexión con el servidor de aplicaciones, no ser
capaz de conectarse a una base de datos, etc.
Pruebas de fallos en el otro lado se lleva a cabo para poner a prueba la
capacidad del software para recuperarse de graves problemas
inesperados, como un fallo de hardware o un accidente. Este tipo de
pruebas se explica cómo funciona el sistema restaurará a su estado
original en caso de cualquier tipo de fallo.
Con fi guración y probar la distribución
Con fi guración de la prueba se lleva a cabo para verificar cómo un
sistema realiza para varios tipos de fi guraciones del sistema. Hay
varias razones para llevar a cabo las pruebas de con fi guración.
Puede ayudar a determinar el tiempo de reacción del sistema en el
entorno de prueba y la con fi guración óptima requerida para que el
sistema funcione como se espera. Con fi guración de las pruebas
también juega un papel muy importante en situaciones donde hay una
necesidad de migrar un software de una plataforma a la otra. Esto
ayuda en verificar si el sistema es compatible con el nuevo entorno
como lo requiere el hardware especí fi caciones.
Una vez que el sistema ha sido implementado, es importante llevar a cabo
ciertas comprobaciones para asegurarse de que va a
trabaja correctamente. Esto incluye la comprobación del sistema para sus
problemas de rendimiento, tales como baja velocidad o de las posibilidades de
accidentes, cómo la aplicación está funcionando en el escenario en tiempo real, es
el software utilizado correctamente en la carpeta correcta, etc. Todo esto es parte de
la prueba de despliegue.
Pruebas de regresión
Una vez que se detecta un defecto en el sistema que se envía
inmediatamente para fi jar. Sin embargo, una vez que el defecto es fi jo es
importante para llevar a cabo intensas pruebas con el fin de comprobar que
los cambios realizados en el código no tiene un FF eja cualquier otra área
del sistema. Las pruebas de regresión se lleva a cabo para asegurar que
fijan error no ha causado ninguna funcionalidad o negocio violación lógica.
Las pruebas de regresión ayuda a minimizar las brechas en el proceso de
prueba. Se asegura de que la aplicación no tiene defectos antes de ser
enviada para la próxima fase de prueba.
Pruebas de rendimiento
Temas tales como retardo de la red, la representación de datos, el procesamiento de
transacciones de base de datos, balanceo de carga
entre los servidores son generalmente descubiertos durante las pruebas
de rendimiento. En otras palabras, en lugar de defectos hallazgo en el
software real, pruebas de rendimiento se centra en probar los problemas
de rendimiento. Es
47
importante llevar a cabo pruebas de rendimiento en cualquier software para lo
cual es importante contar con la estabilidad, escalabilidad y velocidad lo que
significa buen tiempo de respuesta y el rendimiento de datos.
Pruebas de carga y rendimiento de Benchmarking
El proceso de pruebas de carga es también muy interesante; aquí el
comportamiento del software ha sido probado bajo carga máxima. Las pruebas
de carga se lleva a cabo para verificar el grado de software o las lleva a cabo
comporta bajo condiciones de carga máxima. Hay varias herramientas
disponibles para las pruebas de carga tales como JMeter, la carga Runner, Seda
Intérprete y así sucesivamente. Estas herramientas se utilizan para pruebas de
carga automatizada del software en el que se pueden crear varios usuarios
virtuales y luego una secuencia de comandos se ejecuta para comprobar cómo
se comporta el software cuando varios usuarios intentan acceder al sistema al
mismo tiempo.

Pruebas de descargas Tipos Resumen
El probador puede controlar el número de usuarios virtuales y ver cómo
se comporta el sistema.
Pruebas de estrés
En las pruebas de estrés del software se somete intencionalmente a
condiciones anormales y luego su rendimiento se controla. En las
pruebas de estrés el software se prueba mediante la aplicación de
carga que es mucho más allá del límite aceptable y los recursos se
retiran Para averiguar el punto en que éste deje de realizar. Hay
muchas maneras de crear condiciones anormales de las pruebas de
estrés, la base de datos se puede activar o FF y sigue, y puertos de
red puede ser cerrada o se reinicia al azar. La forma más común de
realizar las pruebas de estrés es mediante procesos que consumen
una gran cantidad de recursos de inicio.


48

Pruebas de Software Manual
Las pruebas manuales es el camino más completo de la realización de
pruebas de software más antiguo y. Aunque muchas organizaciones han
comenzado a incorporar la automatización de pruebas en las pruebas de
proyectos, automatización de pruebas nunca se puede sustituir por completo
las pruebas manuales. El proceso de prueba manual depende en gran medida
de las habilidades y la dedicación del probador.
Pruebas de Software Manual
Manual de Pruebas de software Aspectos generales
Con el fin de realizar pruebas manuales del probador tiene que ser
absolutamente claro acerca de los procesos de prueba. Hay una gran
cantidad esperada del probador. Él tiene que entender la funcionalidad
del programa, porque toda la actividad de la prueba puede llevarse a
cabo de la manera correcta sólo si se ha entendido el requisito
correctamente. El probador tendrá que crear un entorno de prueba y
luego preparar los casos de prueba en consecuencia. El proceso de
ejecución de los casos de prueba y verificación de los resultados también
se realiza manualmente.
El probador tiene para grabar manualmente qué pruebas han pasado y los
que no han podido crear un informe detallado para el análisis. Las pruebas
manuales es de gran ayuda cuando se incorporan en las etapas iniciales de
las pruebas de software.
Las pruebas manuales puede ser incorporar tanto para proyectos grandes y
pequeños y donde hay problemas de presupuesto en la empresa o no
pueden ff ord una de invertir en herramientas de automatización de pruebas,
las pruebas manuales resulta ser de gran ayuda. Las pruebas manuales
todavía se considera a veces ser más fiable que las pruebas de
automatización pesar de que lleva ya pruebas de software automatizado.
49
Estrategia de Pruebas de Software Manual

La estrategia para las pruebas de software se define en el plan de pruebas. El

documento de plan de pruebas de multas:

1 El entorno de prueba en el que el software

será probado
2 El objetivo de realizar la prueba 3 El alcance y el objetivo del
equipo de pruebas 4 ¿Cómo las actividades de prueba son los
horarios 5 El enfoque para la realización de las pruebas manuales
6 Hitos

7 Funciones y responsabilidades de los diversos miembros

del equipo de pruebas

8 Herramientas y Prueba de la metodología entrenamientos en caso de haberlas

necesario-
9 ¿Qué tipo de pruebas se tienen que realizar 10 cómo realizar
un seguimiento de defectos

50

Automated Software Testing
automatización de pruebas es un proceso en el que una herramienta de
prueba que es también otra aplicación de software se utiliza para probar el
sistema. scripts de prueba son creados y ejecutados y luego los resultados de
estas pruebas se comparan con los resultados esperados. Siempre es
aconsejable para automatizar procesos de pruebas repetitivas pero esenciales,
ya que ahorra mucho tiempo.
Automated Software Testing
Software Test Automation general
las pruebas de software automatizado se lleva a cabo con la ayuda de
herramientas de pruebas de automatización. herramienta de automatización de
pruebas es una aplicación de software en sí mismo con la ayuda de los cuales
un probador puede escribir scripts de prueba y luego usar este software para
probar el sistema real bajo prueba. Las herramientas de automatización se
utilizan para automatizar ciertas secciones de la prueba manual. La mayor
ventaja de la automatización de pruebas es que ahorra un montón de tiempo y
aplicación de software puede ser probado a fondo en un corto espacio de
tiempo. herramientas de prueba de automatización están disponibles para
realizar la regresión, pruebas de carga y estrés. Sin embargo, las pruebas de
automatización no puede sustituir completamente a las pruebas manuales. Junto
a tiempo, las pruebas de automatización ahorra dinero y e ff Ort y ayuda a
mejorar la precisión del software.
Todos los aspectos del software no pueden ser cubiertos a través de pruebas de
automatización. Sin embargo, las pruebas de automatización es de gran ayuda
en la prueba de los aspectos de la GUI, la conectividad de base de datos, etc.
Lo mejor es ir para la automatización de pruebas cuando se está trabajando en
proyectos grandes y complejos donde hay una necesidad de probar ciertas
áreas con frecuencia. automatización de pruebas también es bueno para probar
esas aplicaciones que serán finalmente utilizados por varios usuarios al mismo
tiempo. Esta forma de
51
prueba ayuda a ahorrar mucho tiempo para que el equipo se vuelve más
tiempo para centrarse en la calidad del software. Con el fin de realizar pruebas
de automatización, lo que necesita saber los siguientes detalles:
1 ¿Qué secciones del software requieren
automatización de pruebas
2 ¿Qué herramientas serán ideales para este propósito 3 El proceso
de escribir scripts de prueba y
ejecutarlas
4 Usted debe ser capaz de identificar el potencial de errores
y saber cómo crear informes de resultados.
Es bueno incluir la automatización de los exámenes para mejorar la calidad del
software de automatización de pruebas, pero no es la única forma de lograr la
calidad y de ninguna manera debe considerarse un sustituto de las
inspecciones y procedimientos de recorrido. Muchas organizaciones siguen
considerando que las pruebas de automatización es la última forma de
detectar los defectos que pueden haber pasado desapercibidas.
Estrategia de automatización de pruebas de software
No hay duda de que las pruebas de automatización hace la vida mucho más
fácil, pero sólo tener las herramientas adecuadas no es su ciente FFI para lograr
el éxito en las pruebas de automatización. Es muy importante desarrollar una
estrategia para la automatización de pruebas que lo haría claramente definen la
cual
secciones del software requieren pruebas, cómo se llevaría a cabo
esta tarea, cómo y dónde se mantendrán los guiones, cómo el
proyecto podría beneficiarse de esta actividad y cuánto dinero se
ahorraría en este proceso. La fi más especí co usted es la hora de
definir la estrategia; cuanto más éxito tendrá en la consecución de los
objetivos de prueba.
Mientras que de fi nir la estrategia es importante romper su objetivo en metas
más pequeñas y comprobar si son capaces de lograr lo que necesita con la
ayuda de una herramienta de automatización de pruebas. Si el proyecto es
demasiado grande y se intenta probar áreas complejas en el primer ir entonces
hay posibilidades de cometer errores. Por lo tanto, es conveniente empezar
poco a poco al principio y luego poco a poco creciendo.
automatización de pruebas puede llevarse a cabo en la unidad de pruebas,
integración y pruebas de nivel de sistema. Es siempre mejor a los defectos
máximos Destape en las primeras etapas de desarrollo de software es, por
tanto, es mejor automatización plan de pruebas tan pronto como es posible.
Software de automatización de pruebas y su retorno de la inversión
(ROI)
ROI de software de automatización de pruebas se calcula saber cómo
la empresa se beneficiaría mediante la incorporación de esta
metodología en sus pruebas
52
procesos. Se da una idea justa sobre el ahorro de costes, el alcance de la
mejora de la e fi ciencia y de la calidad del software.
ROI = (Gain- invirtió cantidad) / cantidad invertida Los métodos más
comúnmente utilizados para el cálculo de ROI para las pruebas de
automatización son:
• cálculo del ROI sencilla para saber cómo la empresa podría
beneficiarse de ahorro de costes. Este cálculo es de gran
importancia cuando una empresa quiere saber cómo se
beneficiaría sobre la base monetaria mediante la incorporación
de las pruebas de automatización. El coste de la inversión
incluiría la cantidad gastada en la adquisición de la licencia,
hardware y formación para ff sta, el desarrollo de guiones, su
mantenimiento y análisis.
• E fi ciencia de cálculo de ROI dice acerca de los beneficios en
términos de mayor eficiencia e fi. A diferencia de retorno de la
inversión sencilla, este cálculo sólo se basa en las ganancias de
inversión de tiempo. Cuando una empresa ya cuenta con las
herramientas de automatización de pruebas y se ha estado usando
durante bastante tiempo, no hay necesidad de que sabe acerca de los
cálculos de ROI simples, ya que no va a realizar ninguna inversión
monetaria fresco en este caso.
• cálculo de la reducción del riesgo indica ROI reducción del
riesgo y el alcance de la mejora de la calidad. automatización
de pruebas ahorra tiempo y ofrece equipo con más tiempo
para llevar a cabo el análisis y llevar a cabo ad hoc y
exploratoria probar esto lleva a una cobertura completa
reduciendo así las posibilidades de fracaso.
Casos de prueba para automatizar
Es dif'ıcil y no sabia para automatizar todas las pruebas. Por lo tanto, se debe
determinar claramente qué casos de prueba deben ser automatizadas. Debe fi
mirada primero en las secciones del software que requieren repetir la prueba.
Los casos de prueba que tienen que ser ejecutado varias veces y que
requieren una gran cantidad de datos para su ejecución deben ser
automatizados. Además, las pruebas repetitivas, también debe centrarse en la
automatización:
1 Los casos de prueba que requieren múltiples conjuntos de datos para
ejecución y son di fi culto para llevar a cabo manualmente.
2 de carga y estrés pruebas que son di fi culto a con-
conducto manualmente.
3 Pruebas que se ejecutan para comprobar la perfor-
Mance de software en múltiples plataformas. 4 pruebas
de GUI.
53
Casos de prueba no permite automatizar
Hay ciertos casos de prueba que no se prefieren para ser
automatizado. Como:
1 Los casos de prueba que se ejecuta sólo una vez o
muy poca frecuencia.
2 ad hoc o exploratoria prueba no puede ser
llevado a cabo con la ayuda de pruebas de automatización. 3 Los casos
de prueba que requieren sólo la ejecución manual
o una opinión humana.
¿Cómo queremos Automat?
Automatización de un caso de prueba comienza con de fi nir lo que desea
probar. Siempre ir a esos casos de prueba que son independientes y
estable. Siempre es mejor para ejecutar los casos de prueba
independientes más pequeños en lugar de unos pocos grandes y
complejos. Grandes guiones son di fi culto a mantener y puede ser di fi
culto para ejecutar si se han realizado cambios importantes en el software.
Si un script de prueba requiere un cambio, entonces siempre es más fácil
realizar cambios en un guión corto que uno largo.
Antes de la automatización de un caso de prueba es mejor para ejecutar el caso
de prueba manualmente. Como los casos de prueba automatizados son las que
uno tiene que utilizar para pruebas repetitivas, por tanto, antes de diseñar un caso
de prueba tales que es mejor para ejecutar de forma manual y la nota abajo todo
el
pasos que le gustaría grabar o poner en su escritura de la prueba. Este le
ayudará a diseñar todas las condiciones requeridas para la prueba a través de
una función. Asegúrese de que ha tomado el cuidado de todas las validaciones
en los scripts de prueba. Si usted está planeando para transacciones de bases
de datos de prueba, entonces usted necesita para asegurarse de que la base
de datos contiene los datos necesarios que se requieren para la prueba. Antes
de ejecutar el caso de prueba, es importante entender cómo la herramienta de
software automatizado ha sido diseñado. Esto es importante porque una vez
que comience la prueba no se quiere quedar interrumpido por cuestiones
desconocidas.
Herramientas de software de automatización de pruebas
Las herramientas de automatización tienen un impacto muy positivo en la
eficiencia y la productividad e fi de software. Es importante tener herramientas de
automatización de pruebas de software para su uso en pruebas de simplificar.
Ciertos procesos de pruebas manuales pueden ser mucho tiempo. Con la ayuda
de herramientas de automatización que puede lograr más en menos tiempo. Sin
embargo, no depender por completo de herramientas de automatización. Usted
debe indicar claramente definen lo que tiene que ser probado de forma manual y
donde hay una necesidad de implementar herramientas de automatización de
pruebas. La mayoría de las herramientas de prueba de automatización de buena
reputación vienen con sus precios, aunque vale la pena desplegarlos en los
proyectos, ya que son de gran ayuda.

54
 Las secuencias de fases en modelo de cascada son los siguientes:
Cascada del ciclo de vida del software
1 Requisito y la recolección: El requisito
Ingeniería
del cliente es capturado y la documentación necesaria se hace.
2 Diseño del Sistema: basado en el requisito
El modelo de cascada es un modelo lineal y secuencial definida para
el ciclo de vida del software de ingeniería. Es un modelo clásico y muy
reunida el sistema está diseñado; esto ayuda a la hora de definir
popular que claramente de fi ne diversas fases y los objetivos que
en la creación de la arquitectura del sistema y también ayuda a la
cada fase tiene que alcanzar. Se llama un modelo de cascada porque
hora de definir el requisito de hardware y software del sistema. 3
al igual que una cascada una vez que el curso del ciclo de vida ha
comenzado no es mirar hacia el agua back.The fluirá desde la parte
Implementación: Basado en el sistema de diseño comienza la
superior a la inferior y no revertir su curso. De manera similar, en este
codificación. El programa se divide en pequeños
ciclo de vida del proceso de desarrollo de software no se puede
unidades independientes que se integran más tarde para
revertir. En el modelo de cascada el enfoque es muy estricto y bien de
formar el sistema completo. Una vez que las unidades están listas
fi nido, pero no hay mucho margen para la revisión. La prueba es una
que se prueban según las define específicas cationes de. 4
fase y no va de la mano con el desarrollo. Por lo tanto, no es posible
detectar defectos temprano en fase de desarrollo.
Las pruebas de integración: Una vez que las unidades se han
probado que se integren en un sistema y luego todo el sistema se
prueba de una sola vez para los defectos.

5 Despliegue: El sistema está listo para

despliegue una vez que los defectos descubiertos durante las
pruebas de integración han sido fijada. Después de las pruebas
del sistema integrado, los defectos son fi ja y la prueba se realiza
de nuevo para verificar todos los defectos se han cerrado. El
sistema es

Cascada del ciclo de vida del software Ingeniería

55
 Ahora está listo para su lanzamiento al mercado y pueden ser
desplegados en el entorno del cliente. 6 Mantenimiento: Si cualquier
defecto o problema surge después de
el software ha sido entregado al cliente a continuación,
parches o una nueva versión del software se libera a lidiar con
el problema.
El cliente, el equipo directivo y el equipo de soporte técnico de la
empresa discutir el requisito del software en detalle completo. se
analizan estos requisitos, discuten varias veces y luego documentados
hasta que son clara y completa.

Todas las fases mencionadas anteriormente se conectan en cascada entre

sí y una fase puede comenzar sólo después de la fase anterior se ha cerrado
con éxito.

modelo de cascada se puede utilizar en situaciones en las que los

requisitos están bien de fi nido y claro, el producto es estable y hay
suficiente cantidad de recursos disponibles para cada fase. modelo de
cascada se debe aplicar en la práctica sólo en proyectos pequeños y
fácilmente manejables. No se debe utilizar en proyectos en los que los
requisitos están en riesgo moderado a alto.
Requisito usuario Speci fi catión

Requisitos especí fi cación y análisis

Los requisitos pueden ser documentados en el formato definido por la
El desarrollo de una aplicación de software depende de una sola cosa
empresa, como la descripción de documentos de Word, flujo de
y que es lo bien que se capturan y se documentan los requisitos. Este
gráficos, dibujos, etc. El resultado de todo el ejercicio es un documento
proceso de identificación y documentación de los requisitos para el
detallado que describa lo que quiere el cliente. Esto es necesario para
desarrollo de software se llama Requisito especí fi cación y análisis.
que uno es capaz de entender el requerimiento del cliente
correctamente. En nuestros días se dice que es defecto de cualquier
cosa que no está en consonancia con el requisito de

56
el cliente. Si capturamos el requisito de forma incorrecta vamos a • Esto ayuda en la programación de las actividades y la estimación de costos.

iniciar el proyecto en el pie izquierdo.

• SRS sirve como base para la validación y veri fi cación.

Requisito usuario Speci fi catión

Este documento de multas lo que un usuario quiere y cuáles son sus
expectativas desde el software son. Este documento da una idea clara
acerca de las necesidades de negocio de un cliente. Este documento ha
sido escrito por los usuarios finales. Estos requisitos se prueban en el
ensayo de aceptación del usuario. Este documento no es de naturaleza
técnica. Se habla de la necesidad de la empresa del usuario y constituye
la base para la planificación de los próximos pasos en la captura de
requisitos y el sistema de diseño.

Requisito de software especí fi cación

El requisito de software especí fi cación de fi ne la forma en que el usuario
desea que el software funcione. El propósito de este documento es la
Requisito de software especí fi cación
siguiente:
• El cliente y el proveedor de acuerdo en este requisito. En él se
Diseño de software
describe la funcionalidad del software en detalle completo.
El software de diseño puede ser de los siguientes tipos:
• Diseño de software de alto nivel
• El diseño del software se prepara sobre la base del documento
• Nivel de diseño detallado del software
SRS.
• SRS misma jugada y documentan simplificada fi ca el desarrollo y
proceso de pruebas.

57
 se detalla información sobre el sistema y no se puede crear hasta el
HLD está listo.

Los procesos de diseño de software

Los procesos de diseño de software pueden ser clasificados como:

• Enfoque de arriba hacia abajo Diseño

• Enfoque de abajo hacia arriba Diseño

Diseño de software
Enfoque de arriba hacia abajo Diseño

enfoque de arriba hacia abajo es un enfoque muy sistemático en el que

Diseño de software de alto nivel
el primer esquema del sistema se diseñó sin de fi nir los detalles de
diseño de alto nivel de software proporciona una imagen clara sobre el
cualquier subsistema. Una vez que el esquema para el sistema está
diseño y la arquitectura de base de datos de función del sistema.
listo, es hora de moverse hacia abajo paso a paso para cada
Software de diseño de alto nivel sirve como una guía para el equipo de
subsistema. Cada sistema de sub se define en detalle completo hasta la
desarrollo. Siempre hay alguna duda en cuanto al diseño flujo, los
especificación llega a los elementos de base.
desarrolladores se refieren al diseño de alto nivel (DAN) de
documentos. Con el fin de crear este documento, es importante que
los requisitos de software especí fi cación (SRS) documento debe ser
Enfoque de abajo hacia arriba Diseño
absolutamente claro.
enfoque de diseño hasta la parte inferior es exactamente lo contrario de
enfoque de arriba hacia abajo. En este caso, el primer paso consiste en de fi
nir los elementos de base en completo detalle y luego enlazan estos
elementos para formar varios subsistemas que están vinculados más juntos
Nivel de diseño detallado del software
hasta el momento en que se forma el sistema completo. Este enfoque puede
diseño de los niveles de software detallada o Diseño de niveles bajos
ser comparada con la plantación de un árbol en el que al principio en todo lo
(LLD) consiste en romper el diseño de alto nivel en secciones más
que tenemos en la mano en una semilla, pero a medida que comenzamos a
pequeñas y anotando la lógica que serviría como especí fi cación del
trabajar en ella se forma un árbol.

programa. LLD ofrece

58
 Este proceso iterativo y combina enfoque gradual que ayuda en el
Agile Software Ingeniería del Ciclo de rápido desarrollo del proyecto. El proyecto se divide en compilaciones
incrementales y luego se somete a cada construcción iteraciones que
Vida
pueden durar 2-3 semanas. En cada iteración equipos funcionales
cruzados trabajan juntos en varios aspectos del derecho proyecto
La metodología ágil cree que cada proyecto debe ser manejada de
desde el análisis de requisitos para las pruebas de aceptación. Al final
una manera ff Erent di.
de cada iteración se muestra el resultado para el cliente.

Requisitos de un proyecto varían de un cliente a otro y por lo tanto no es

aconsejable atenerse a un solo método de desarrollo de software. En el
software de ciclo de vida de ingeniería todos los proyectos se dividen en
Visión general de Agile Software Ingeniería del Ciclo de Vida
pequeños marcos de tiempo, con cada marco de tiempo a centrarse en la
ciclo de vida de ingeniería de software ágil es di ff Erent desde otro
entrega de ciertas secciones de la liberación.
enfoque de desarrollo de software, ya que es adaptable en la
naturaleza como en comparación con otros que son predictivos. la
planificación predictiva requiere en la planificación profundidad que
consume mucho tiempo y ss e ORT e incluso un pequeño cambio en el
requisito después del desarrollo ha comenzado a ff refleja el proceso
de desarrollo. métodos predictivos son completamente dependientes
de análisis y planificación de necesidades en el inicio del proyecto.

metodología ágil no requiere una planificación detallada, se inicia el

desarrollo de mantenimiento de las funciones y características del
software en la mente y el equipo cambia el curso del desarrollo

Agile Software Ingeniería del Ciclo de Vida dinámicamente cada vez que un cambio en el requisito es

59
pedido. Este enfoque se centra más en la interacción con el cliente y
menos en la documentación para que el equipo de desarrollo está seguro
de que está en el camino correcto.
Aunque ágiles de desarrollo de software sigue un enfoque muy realista
que no es ideal para proyectos complejos y siempre hay un riesgo de
sostenibilidad, mantenibilidad y extensibilidad. Este proceso tiene
necesidades de recursos mínimos y es ideal para proyectos en los que
el requisito se someten a cambios frecuentes. Dado que la
documentación es menor y la atención se centra por completo en la
interacción con el cliente, todo el proyecto depende de lo bien que el
cliente es capaz de comunicar sus necesidades. metodología ágil
permite el desarrollo concurrente; las reglas son nominales que se
pueden emplear fácilmente.
La integración del software continua y continuar con las pruebas de
software
En forma tradicional de desarrollo de software, los desarrolladores
trabajan en piezas individuales de código para varios días y una vez
que se hayan completado las unidades individuales se mueven a la
integración de las unidades. Dado que en cada iteración esta
metodología cree en hacer el proyecto se centran en el desarrollo de
código de alta calidad, integración continua debe ser seguido. El
concepto de integración continua
requiere de mucha disciplina y teorías pueden variar de una compañía
a otra. Por ejemplo, algunas empresas creen que al final del día, un
desarrollador debe asegurarse de que nada se deja sin integrar. En tal
escenario, el desarrollador tiene que planificar todas sus tareas
correctamente. Si bien, esto puede parecer una tarea dif'ıcil, el mayor
beneficio de este enfoque es que el cliente puede caminar en cualquier
momento y ver cómo se está desarrollando el producto y puede dar su
opinión sobre lo que se presenta a él.
Pruebas y papel de las pruebas En Agile Software Ingeniería del
Ciclo de Vida
Las formas tradicionales de desarrollo de software no utiliza un
probador a su potencial completo. Como cuestión de hecho
probadores comenzó a trabajar sólo después de que el requisito
funcional se ha desarrollado por completo. En un entorno ágil el
probador es un miembro muy importante del equipo y está involucrado
en todas las fases de cada iteración, ya sea planeando o análisis de
requisitos.
En esta prueba la metodología es tan importante como el desarrollo y
el producto se somete a prueba cont ing inuous. El probador está
trabajando continuamente en la metodología ágil y así, por el final del
proyecto el número de defectos en el
60
sistema son muy inferior en número porque la mayoría de ellos han
sido descubiertos en las fases iniciales de desarrollo de software.

61

Gestión de Proyectos de Software
La gestión de proyectos de software incluye toda la información y
herramientas que se requieren para gestionar el proceso de proyectos
de desarrollo de software necesario. Con el fin de ejecutar un plan de
proyecto de desarrollo de software correctamente, el administrador
elabora un plan que describe cómo se llevará a cabo el desarrollo.
El plan también se centra en cómo se mantienen los estándares de
calidad durante el proceso de desarrollo. El gerente también fi ne de
cómo se organizará el equipo de desarrollo, cómo se llevará a cabo la
gestión de riesgos.
Planificación de proyectos
Software de planificación se requiere con el fin de controlar y supervisar los
complejos procesos que intervienen en el desarrollo de software. La
planificación del proyecto se hace para asegurar que el proyecto está
terminado y en el tiempo, el producto final es de buena calidad y el proyecto
se completó y en el tiempo. Con el fin de seguir adelante con la
planificación del proyecto, es importante tener en cuenta la complejidad del
proyecto, su tamaño y el nivel de incertidumbre estructural. Un plan de
proyecto de software se compone de:
• Alcance: de fi ne el problema y qué hay que hacer para
resolverlo.
• Estimación: define el correo ff ORT y el tiempo que pasará a
completar el proyecto.
• Riesgo: define la obstrucción que el equipo puede enfrentar
durante el desarrollo del software y la forma en que pueden
abordarse.
• Horario: Asignación de recursos para que el proyecto pueda fi
nal en el tiempo.
• Estrategia de control: nes de fi cómo hacer para control de
calidad.
Proyecto Sta fi ng
Para llevar a cabo el proyecto sta fi ng es importante para definir diversas
funciones, habilidades requeridas para cada función, cómo sta fi ng serán
programadas y cómo sta fi ng se llevará a cabo para cada función. Para cada
papel es necesario para definir las competencias y los requisitos de
competencia, el nivel de experiencia, disponibilidad y expectativas salariales.
Proyecto de iones coordinat y Al ignment de los Actores
Es responsabilidad del coordinador del proyecto de TI para alinear los
miembros de los equipos internos con los grupos de interés externos.
Esto se hace mediante la coordinación de varias fases y programas de
proyectos, seguimiento del progreso y hacer los arreglos para pedir
suministros y
62
Servicios de apoyo. El director del proyecto supervisa las actividades de
coordinación del proyecto.

63
 • Área que requiere pruebas de automatización y los que
Software Ciclo de Vida operaciones de requieren pruebas manuales se identifican.

prueba y Pruebas de Software

Diseño de pruebas y desarrollo
Este proceso consiste en:
ciclo de vida del software de prueba tiene las siguientes fases: Estudio
• Preparación de casos de prueba y scripts de prueba (si la prueba
1 Requisito: donde el requisito de
automatizada está involucrado)
el cliente se entiende y documentación funcional está hecho.
• Preparación de los datos para las pruebas

2 Plan de pruebas: Teniendo en cuenta el requisito de la

Ejecución de pruebas
proyecto, se han previsto actividades de ensayo y se preparó el
Ejecución de prueba consiste en:
documento plan de pruebas.
• La ejecución de casos de prueba
3 Diseño de casos de prueba: escenarios de prueba son
• Utilice una herramienta de seguimiento de errores para registrar errores
casos fi cados y de prueba identi están diseñados en consecuencia.
• resultados de las pruebas de documentos

• Usar la RTM para mapear defectos al requisito

4 casos requisito y de prueba se asignan y
matriz requisito de trazabilidad está preparado. 5 Ejecución de
• Un seguimiento del estado del insecto
casos de prueba: las pruebas deben ser
ejecutados y los errores deben ser reportados. 6 Una vez que los
Cierre de prueba
defectos son XED fi, volver a probar y
Cierre prueba consiste en:
pruebas de regresión debe llevarse a cabo. 7 Los informes
• métricas de ensayo se prepara teniendo en cuenta la cobertura de pruebas,
de prueba deben estar preparados. Se completó 8 Pruebas de
costo, tiempo, calidad, etc.
actividad.
• Preparación del informe de cierre de prueba.

• distribución de defectos por tipo y la gravedad se calcula.

requisitos Estudio
En este proceso:
• análisis informal y resolución (CAR) se prepara.
• matriz requisito de trazabilidad está preparado.
• prioridades sabios módulo y el enfoque se ajusta.

64
Proceso de prueba del análisis

Se requiere el análisis de procesos de prueba antes de empezar con las

pruebas de software. Documentos que proporcionan información para
iniciar o FF con las pruebas se llaman los documentos básicos de la
prueba. Estos incluyen SRS, el diseño del sistema, la arquitectura, interfaz,
etc. Con la ayuda de estos documentos los probadores de entender el
sistema y el aspecto de las condiciones de prueba o posibilidades que
formarán parte del caso de prueba. Una vez que las condiciones de la
prueba han sido identi fi cado que se priorizan y se crean casos de prueba.

sesenta y cinco

Entregables del Team Software Testing
Prueba entregables son documentos que se dan a las partes
interesadas cuando se desarrolló el software. En esta sección vamos a
discutir los siguientes resultados de las pruebas:
Entregables del Team Software Testing
• Estrategia de Pruebas de Software
• Plan de Pruebas de Software
• Escenarios de prueba de software y casos de prueba
• Las métricas de software de prueba
• Las métricas del producto
• métricas de procesos
• Documentación de software de prueba
• Los informes de pruebas de software
• Informes de estado de prueba al día
• Los informes de incidentes
• Informe Final de estado (proyecto de la prueba de cierre) Prueba
Estrategia de Pruebas de Software
Una estrategia de pruebas de software es una hoja de ruta para el ensayo de
las actividades de un proyecto. Las pruebas pueden ser un di fi culto muy si
no se descompone en los procesos de fi nida así de pequeños. Una
estrategia de prueba ayuda a la hora de definir el proceso de prueba y sobre
la base de las cuales el equipo de pruebas evalúa el tiempo, e ff ORT y los
recursos necesarios para todo el proceso. Una buena estrategia es la que
permite una buena planificación, gestión y seguimiento de los procesos.
Plan de Pruebas de Software
Un plan de pruebas define la estrategia general para el ensayo de sof
tware. E s explica el rojo de prueba requi ing medio ambiente y lo que se
llevará a cabo a nivel de las pruebas. La información que imparte plan de
pruebas, cómo se analizarán los resultados de las pruebas y las métricas
que serán utilizados para el propósito. Criterios de salida para cada fase
se de fi nen y estimación de prueba e ff TRO y el costo se mencionan en
el plan.
66
 proceso muy complicado. A continuación, la industria ha llegado con
algo que era fácil de usar.

Plan de Pruebas de Software

Escenarios de prueba de software y casos de prueba

Prueba de escenarios es un caso hipotético hecho para ayudar a la

prueba del probador del software en un fi manera bien de nido. Los casos Escenarios de prueba de software y casos de prueba

de prueba en el otro lado son muy simples y directos que explican lo que
hay que hacer. Por lo general son Declaraciones de una línea y hay que
alimentar en una entrada y comprobar la salida esperada para cada Los casos de prueba en el otro lado son muy directos. Ellos dicen lo que
entrada. Los escenarios de prueba pueden ser complejas y convincente el probador debe hacer y cómo tiene que ser probado el software.
como una historia. Es una situación dada a un probador para evaluar el
software.

El concepto de escenarios de prueba entró en funcionamiento en el año

2003 después de que se observó que el mantenimiento de casos de
prueba con la descripción paso a paso, los datos de entrada y resultados Escenarios de prueba de software y casos de prueba

esperados era una

67
Las métricas de software de prueba
Como su nombre indica métricas de software no es más que los estándares de
medición de fi nido para evaluar el software. Cualquier unidad que se utiliza para
medir cualquier atributo del software se llama una métrica. métricas de prueba
de software se utiliza para medir la calidad del software. Estas métricas dan una
idea clara acerca de la disposición de un sistema mientras se encuentra todavía
en fase de desarrollo. Ahora se puede preguntar ¿por qué necesitamos una
métrica de prueba de software?
Bueno, la respuesta es muy simple-sólo podemos mejorar aquellas cosas que
podemos medir, porque cualquier cosa que se puede medir es controlable.
Las decisiones de todas las fases de desarrollo de software se utilizan
únicamente después de referirse a las métricas de software de prueba de la
fase anterior. métricas de prueba de software pueden ser de dos tipos: 1
medida directa / Base de Métrica: estos datos es cruda
y es recogida por un analista de prueba. métricas de base
proporciona la información sobre el estado del proyecto como el
número de casos de prueba se han creado, cuántos se han
ejecutado y así sucesivamente. 2
medida indirecta / métricas calculadas: datos sin procesar
recogidos de las métricas de base cuando se convierte a
información más útil que proporciona información precisa sobre
el proyecto como% de
la finalización del proyecto,% de cobertura de la prueba e hijo en se
conocen como métricas calculadas.
Las métricas del producto
métricas de productos juega un papel muy importante en las iniciativas
de mejora de la calidad del producto de fi nir. La evaluación constante
del producto ayuda al equipo a decidir si hay una necesidad de ningún
tipo de corrección de cualquier característica del producto así
a tiempo.
métricas de productos mide las características de un producto:
• Talla
• Complejidad
• aspectos de diseño
• Actuación
• Calidad
métricas de procesos
Proceso Métrica medir los procesos de manera que si hay algún ámbito de la
mejora que se pueda hacer. métricas de procesos pueden ayudar a ahorrar
mucho tiempo y e ORT y ss. Cada proceso está diseñado teniendo algún
objetivo en mente y métricas de procesos ayuda a evaluar hasta qué punto
el equipo ha tenido éxito en el logro de la misma. métricas de procesos
juegan un papel muy importante en el seguimiento de las actividades de
pruebas de software. Las pruebas de software es un aspecto muy importante
de desarrollo de software y
68
e fi ciencia y e ff cacia de un proyecto puede mejorar fi significativamente
mediante el control de las actividades de prueba. Desde el punto de vista de las
métricas de procesos de desarrollo de software puede ser utilizado para medir:
• Desarrollo de software
• Mantenimiento del software
proyectos y programas interesados. En cualquier punto de tiempo que el jefe
de proyecto puede echar un vistazo a la cantidad de defectos son reportados
en base diaria, cómo se ejecutan muchos casos de prueba y la cantidad de
trabajo hecho por cada probador. Un informe de estado diario tiene
información relacionada con:

• Pruebas de software Se planearon 1 ¿Cuántos casos de prueba para la

¿día?

Documentación de software de prueba 2 ¿Cuántos de ellos fueron ejecutados? 3 ¿Cuántos defectos han
Las pruebas de software documentos que prepararon durante o antes del ensayo informado por el Benn
para mantener un seguimiento de todas las actividades de prueba se denominan prueba de las personas?

documentos de prueba de software. Los documentos importantes pruebas de 4 ¿Cuántos de los defectos fueron críticos? 5 Ubicación: Donde los
software incluyen: informes de las pruebas más detalladas
• Plan de prueba se puede ver (Defecto y la Hoja de ejecución de la prueba)?
• escenario de prueba

• Caso de prueba

• Matriz de trazabilidad Los informes de incidentes

Incidente informa ayuda en la coordinación de las actividades de

Los informes de pruebas de software prueba y desarrollo. gestión de incidencias implica:
En esta sección vamos a discutir los siguientes informes:
• Informes de estado de prueba al día • La comparación de los resultados reales y esperados

• Los informes de incidentes • ¿Cuál fue la causa de la desviación en los casos en que no pasaron las

• Informe Final de estado (proyecto de la prueba de cierre) Prueba pruebas? - la automatización de pruebas defectuoso, deficiente caso de

prueba, el fracaso real de software?

Informes de estado de prueba al día

Daily informe de estado de prueba ayuda en el mantenimiento de la

transparencia dentro del equipo de pruebas y con el

69
informe de incidente tiene que estar preparado para el fracaso real. Un Informe Final de estado (proyecto de la prueba de cierre) Prueba

informe de incidente debe proporcionar los siguientes datos:
• Identi fi cación
• ¿Cuál es el ID para cada informe?
• ¿Cuál es el objeto de prueba?
• Versión del Software de aplicación bajo prueba
• Los detalles del entorno de prueba - hardware y software
Prueba de informe de cierre del proyecto se crea cuando el criterio de salida
del proyecto se alcanza o cuando toda la actividad de la prueba se ha
completado. Este informe es creado por el conductor de prueba y
posteriormente revisado por todas las partes interesadas y los clientes. Este
informe tiene todos los detalles de los casos de prueba que se han
ejecutado con éxito y si existe algún defecto sobresaliente que los planes
del equipo para el despliegue proyecto post decisión luego que también se
mencionan en este informe.

• Nombre del desarrollador que necesita para evaluar y resolver

el incidente
• Cuando se observó el fracaso?
• Clasi fi cación
• Estado
• Gravedad

• Prioridad

• Requisito
• Porque
• Descripción del problema

• Descripción del problema

• Los detalles del caso de prueba

• los comentarios de Tester

• comentario del desarrollador después del cambio

• cualquier referencia

70
 1 conocidos conocidos son los riesgos de software que están
Qué es el software de Riesgos y en realidad hechos conocidos por el equipo, así como a todo el

software de gestión de riesgos? proyecto. Por ejemplo no tener suficiente número de

desarrolladores puede retrasar la entrega del proyecto. Tales
riesgos se describen y se incluyen en el Plan de Gestión de
El riesgo es una expectativa de pérdida, un problema potencial que
Proyectos. 2 conocidos desconocidos el riesgo de que el
puede o no puede ocurrir en el futuro. Por lo general es causada por la
proyecto
falta de información, control o archivo.Una posibilidad de Ering Do ss de
equipo es consciente de, pero se desconoce la existencia de
la pérdida en el proceso de desarrollo de software se llama un riesgo de
dicho riesgo en el proyecto o no. Por ejemplo, si la comunicación
software. La pérdida puede ser cualquier cosa, aumento del coste de
con el cliente, no de buen nivel es entonces no es posible
producción, desarrollo de software de mala calidad, no ser capaz de
capturar el requisito correctamente. Este es un hecho conocido
completar el proyecto a tiempo. Existe riesgo de software, ya que el
que el equipo del proyecto, sin embargo si el cliente ha
futuro es incierto y hay muchas cosas conocidas y desconocidas que no
comunicado toda la información correctamente o no es
pueden ser incorporados en el plan de proyecto. Un riesgo software
desconocido para el proyecto. 3 desconocidos desconocidos son
puede ser de dos tipos (a) los riesgos internos que están bajo el control
ese tipo de riesgos
del director del proyecto y (2) los riesgos externos que están fuera del
control del director del proyecto. La gestión del riesgo se lleva a cabo a:
sobre los que la organización no tiene ni idea. Estos riesgos están

generalmente relacionados con la tecnología, tales como el trabajo con

tecnologías o herramientas que usted no tiene idea acerca debido a que

su cliente quiere que le permite trabajar de esa manera expone repente te

a riesgos desconocidos absolutamente desconocidos.

1 Identificar el riesgo

2 Reducir el impacto del riesgo

3 Reducir la probabilidad o posibilidad de la supervisión del riesgo
software de gestión de riesgos tiene que ver con el riesgo cuanti fi cación de
Riesgo 4
riesgo. Esto incluye:
1 Dar una descripción precisa de evento de riesgo que
Un gerente de proyecto tiene que lidiar con los riesgos derivados de tres casos
puede ocurrir en el proyecto
posibles:

71
 2 De fi nir la probabilidad de riesgo que explicaría social, factores internos o externos deben ser evaluados
¿cuáles son las posibilidades de que el riesgo de que ocurra 3 De fi nir la correctamente.
cantidad de pérdida de una lata riesgo particular

porque
4 De fi nir la responsabilidad potencial de riesgo

Gestión de Riesgos se compone de los procesos siguientes: 1 Software

Riesgo identificación de supervisión 2 Software de Análisis de Riesgo 3
Planificación Software Riesgo 4 Software Riesgo

Estos procesos se definen a continuación.

Software de Riesgo La identificación

Software de Riesgo La identificación

Con el fin de identificar los riesgos que su proyecto pueda ser sometido a,
En esta fase de la gestión de riesgo tenga a los procesos de finas que son
es importante estudiar la primera
importantes para la identi fi cación de riesgo. Todos los detalles del riesgo
problemas que enfrentan los proyectos anteriores. Estudiar el plan de
tales como ID exclusivo, fecha en la que se identificó, descripción y así
proyecto correctamente y comprobar todas las posibles áreas que son
sucesivamente deben mencionarse claramente.
vulnerables a algunos o el otro tipo de riesgos. Las mejores formas de
analizar un plan de proyecto es mediante la conversión a un fl owchart y
examinar todas las áreas esenciales. Es importante llevar a cabo algunas
Análisis de Riesgos de software
sesiones de lluvia de ideas para identificar las incógnitas conocidas que
Software de Riesgo analysisis un aspecto muy importante de la gestión
puede un ff ect del proyecto. Cualquier decisión tomada en relación con
de riesgos. En esta fase, el riesgo es identificados y luego categorizado.
técnica, operativa, política, jurídica,
Después de la clasificación de riesgo, el nivel, la probabilidad
(porcentaje) y el impacto del riesgo se analiza. Probabilidad se define en
porcentaje

72
después de examinar cuáles son las posibilidades de riesgo de que se produzca
debido a diversas condiciones técnicas. Estas condiciones técnicas pueden ser:
1 La complejidad de la tecnología
2 El conocimiento técnico poseído por la prueba
equipo
Análisis Cuantitativo de Riesgos: se puede utilizar para el análisis del
riesgo de software, pero se considera inadecuado, porque el nivel de
riesgo se define en% que no da una imagen muy clara.
Software de planificación de riesgos

3 Los conflictos dentro del equipo planificación del riesgo de software tiene que ver con: 1 medida preventiva
4 equipos siendo distribuidos sobre una gran De fi nir que bajaría
área geográfica por la posibilidad o probabilidad de varios riesgos.
5 Uso de las herramientas de pruebas de mala calidad

2 De las medidas de fi ne que reducirían el impacto

Con un impacto nos referimos a la consecuencia de un riesgo en caso en caso de un riesgo pasa.
de que suceda. Es importante conocer el impacto debido a que es 3 La supervisión constante de los procesos para identificar
necesario saber cómo una empresa puede obtener una ff ected: riesgos tan pronto como sea posible.

1 ¿Cuál será la pérdida para el cliente 2 ¿Cómo sería

el dueño de Su ff er 3 Pérdida de reputación o daño a
la sociedad 4 pérdidas monetarias

5 acciones legales contra la compañía 6 de

cancelación de la licencia comercial

Nivel de riesgo se identi fi ca con la ayuda de:

Análisis Cualitativo de Riesgos: Aquí se de fi ne como el riesgo:

• Alto
• Bajo
• Medio
Software de planificación de riesgos

73
Software de Seguimiento de Riesgos

seguimiento del riesgo de software está integrado en las actividades del proyecto y

controles periódicos se llevan a cabo en la parte superior riesgos. supervisión

comprende de riesgo del programa:

• Seguimiento de los planes de riesgo para cualquier cambio importante en el plan

real, atributo, etc.

• Preparación de informes de estado para la gestión de

proyectos.
• Revisar los riesgos y riesgos que por su impacto o la probabilidad
ha alcanzado el nivel más bajo posible debe ser cerrado.

• Regularmente buscar nuevos riesgos

74
 5 Di cultades fi en la gestión de los cambios en el software
Apoyo a los procesos de Pruebas de designsystem.

Software

Esta sección se centra en algunos procesos muy importantes que son muy
esenciales para mantener un seguimiento de cómo las pruebas de software
está progresando. En esta sección aprenderá sobre:

• Defecto de Gestión del Ciclo de Vida y cómo funciona

• Matriz de trazabilidad
• Las técnicas de pruebas de software de estimación
¿Qué es la Gestión del Ciclo de Vida de defectos y cómo
• Gestión de con fi guración
¿Funciona?
• Gestión del cambio

Defectos del ciclo de vida se define para gestionar defectos en el sistema. De

¿Qué es la Gestión del Ciclo de Vida de defectos y cómo
hecho, es el viaje de un error en el sistema desde el momento en que se se
funciona?
encontró que el tiempo que se cierra. Las etapas de un ciclo de vida de
El software se desarrolla por los seres humanos y es injusto esperar que un
defectos se dan a continuación:
software de millones de líneas de código para ser libre de defectos. Los
defectos se inducen debido a muchas razones:

1 Nuevo: Cuando se descubre un defecto se le da el

1 Los requisitos no se comunican
estado de 'Nuevo'.
claramente
2 Abierto: Cuando un nuevo defecto encontrado va para
2 P rog rammi ng er ro RSC aus ed du ri ng
revisarlo tiene un estado 'abierto' 3 duplicados: Si el defecto ya
desarrollo
ha sido
3 el diseño del sistema Complex
informó antes, entonces se le llama 'duplicado'
4 de mala calidad o documentación incompleta

75
 4 Asignado: Este estado indica que el insecto tiene
ha asignado a un desarrollador para la fi jación. 5 de nuevo a prueba:
Una vez que el defecto es fi ja el probador
lleva a cabo pruebas para comprobar si el defecto ha sido
cerrado o no.
6 Nuevamente abierta / cerrada: si el defecto es fijo es
le asigna el estado 'cerrado' o de lo contrario se 'volvió a abrir'.
¿Qué es la matriz de seguimiento?
matriz de trazabilidad es una herramienta que se utiliza para conectar
y rastrear los requerimientos del proyecto (empresarial, aplicaciones,
seguridad relacionados) a la implementación y procesos de prueba.
Esto ayuda a analizar qué parte de los requisitos del proyecto se han
completado.
Una matriz de trazabilidad es de gran utilidad en los proyectos de
desarrollo de software complejos. Con la ayuda de esta herramienta se
puede rastrear cómo las cosas están funcionando en cualquier sección
del proyecto. Esta matriz se crea en un documento de hoja de trabajo
que forma parte de una de las filas y columnas. Un conjunto de valores
se fijan contra la fila y otra serie de valores se sitúa en las columnas. Si
existe algún tipo de relación entre el valor de la columna y cualquier
valor de la fila y luego una
identi marca fi catión es lugar en la celda en la que la columna y la fila de
intersección.
Por lo tanto, si colocamos las diversas necesidades de la acción contra
la columna en los procesos de prueba de izquierda y diversas en la
parte superior de la fila. Entonces podemos asignar fácilmente los
procesos que las pruebas se han completado para el cual todos los
requisitos. Esto daría una idea exacta sobre la cantidad de porcentaje
de las necesidades tiene completado.
¿Cuáles son las técnicas de iones imat Sof tware prueba ing Est?
Di ff proyecto de software Erent pertenecen a di ff Erent dominios tan
técnicas de estimación de software pueden variar un poco de un proyecto a
otro. También es muy dif'ıcil para obtener el derecho de estimación en el
primer ir. Sin embargo, las técnicas de estimación de software son muy
importantes para una empresa. Desempeña un papel muy importante en el
SDLC. Estimación técnicas proporcionan una estimación del tiempo que
puede ser requerida para fi Nish una tarea particular.
La estimación se realiza para obtener una idea aproximada sobre la cantidad de
correos ff ORT que sería necesario para completar una tarea en particular. La
estimación también podría significar costos. Muchos factores tales como la
experiencia pasada, suposiciones, documentos, etc. calcularon los riesgos ayuda
a determinar
76
la estimación para un ciclo de desarrollo de software. Esta estimación ayuda a
una organización en la licitación de un proyecto. Se requiere la estimación de
software de modo que las posibilidades de rebasamiento del presupuesto,
mientras que las pruebas o retraso en la terminación del proyecto pueden ser
evitados. 1 Delphi técnica de estimación de software es la
la mayoría de las técnicas ampliamente utilizados para
estimation.It proporciona una manera de lograr un acuerdo
dentro de un equipo sin ningún conflicto. Cada uno del equipo
proporciona una estimación anónima e individual que es
evaluado por el coordinador. Si la evaluación está dentro del
rango aceptable, una decisión puede ser tomada o de lo
contrario el proceso se repite de nuevo. 2 Estructura de
Desglose del Trabajo se utiliza es grande
proyectos en los que el primer proyecto se divide en componentes
más pequeños en una jerarquía y luego el proceso de estimación
se lleva a cabo para evaluar la programación de tareas y la
estimación detallada de los costos del proyecto.
técnica de estimación de 3 de tres puntos también se utiliza
para grandes proyectos donde el proyecto es primero divide en
secciones más pequeñas y sub del sub para cada sección de la
primera estimación optimista se hace asumiendo que nada va a
salir mal y todas las condiciones son fi ne (A). El segundo
enfoque es de la mayor estimación probable cuando uno asume
que hay una posibilidad de que surjan problemas pero al final
todo será definir (B). El tercer enfoque es la estimación
pesimista en el que todo va a salir mal (C). Por lo tanto, la
fórmula estimación se define como: A + (4 B *) + C / 6 4 método
del punto funcional sugiere que: (Total
e ff ORT estimado) = (número total de puntos de función) *
(estimación de cada punto funcional). Lo anterior fórmula
clarifica que más coeficiente de ponderación se da a cada
punto de función. Los puntos de función se clasifican como
complejos, medio y simple y, a continuación una estimación se
realiza.
¿Qué es la Gestión de Con fi guración?
se requiere una gestión con fi guración para mantener la consistencia
en el rendimiento de un sistema. Con fi guración El tratamiento incluye:
• Todos los artículos con fi guración se etiquetan con singulares los identificadores
• La identificación de todos los documentos que describen con elemento fi
guración
• artículos relacionados con fi guración deben ser agrupados en líneas de
base
• Después de cada revisión es importante etiquetar los artículos y
líneas de base con fi guración.
77
El desarrollo de software es un proceso complejo, donde siguientes documentadas y todas las configuraciones fi son fáciles de identificar.

cuestiones son muy comunes: 1 Muchas veces los desarrolladores

tienden a sobrescribir cada
otras de modi fi caciones 2
Si las versiones no se mantienen adecuadamente, entonces el
proceso de integración puede ser muy di fi culto. 3 A veces hay
problemas de compatibilidad
entre las versiones de las herramientas de compilación y de
desarrollo.
4 La confusión sobre qué casos de prueba pertenecen a
versión actual del software.

Todos estos problemas se pueden manejar con la ayuda de con fi

guración de gestión que define:
• gestión de versiones: mantener el registro de varias versiones
del objeto a prueba versión de con fi gurada elemento
correspondiente.
• Con fi guración de identificación: ayuda en la forma única de fi
nir el sistema, cada versión revisada del sistema y los
componentes de cada versión revisada.
¿Qué es la Gestión de Con fi guración?
¿Qué es la Gestión del Cambio?
Como su nombre sugiere la gestión del cambio tiene que ver con
hacer frente al cambio en la forma de trabajar. se requiere un cambio
de gestión en los distintos niveles desde el nivel de la empresa a nivel
individual. ofertas de gestión del cambio con:

• Documentación del estado de incidentes y solicitudes de
cambio: Estos documentos impartir información sobre varios
incidentes y el cambio solicitado y su estado actual.
• Con fi guración de las auditorías: asegurarse de que los detalles de
todos los componentes del software están bien
1 Adaptación al cambio: Muchas veces se convierte en
extremadamente importante para implementar procesos
estructurados para lograr un cambio positivo en el negocio. En
los tiempos actuales de recesión o desaceleración de las
empresas de economía que implementar mecanismos estables
que ayudarían

78
 sta ff miembros se ocupan de presión en di fi condiciones de culto. importante vigilar los cambios y realizar un seguimiento de los detalles
del sistema.
2 El cambio que controla: trato con los nuevos cambios 3 y ss E ión de Cambio: generar bene fi cio de la
en el entorno empresarial. No importa lo que los nuevos cambios positivos.

cambios que realice en el medio ambiente es

¿Qué es la Gestión del Cambio?


79
Gracias
Me gustaría dar las gracias de nuevo por tomarse el tiempo para leer
Pruebas de Software revelados. Esperamos que haya disfrutado de la
lectura de este libro tanto como habíamos disfrutado mientras
escribíamos. Es nuestro mayor placer si nos manejamos por cualquier
medio para ayudar a construir una base sólida de Pruebas de Software.

Sabemos que es un mundo muy complejo, abrumadora y

abarrotado de todos los cationes certi fi Pruebas de software que
hay en el mercado.

Y, sin embargo logramos construir nuestros programas de certi fi cación de

pruebas de software más concreta, atractivo, útil, útil y sencillo que hizo
nuestra competencia. Es por esto que creemos que nuestros estudiantes
eligen valiosos Instituto Internacional de Pruebas de Software ™ frente a las
soluciones burocráticas, complejas, costosas y medio cocinar de nuestros
competidores.

Nuestro único en su tipo industria de registro, el examen y el proceso de certi

fi cación que lleva es muy simple, rápida y completamente en línea. Haga
clic en este enlace para hallar todos los detalles: Software de Pruebas
Certificación

Yeliz Obergfell, Instituto Internacional de Pruebas de Software ™

80