Machine Translated by Google

Machine Translated by Google

PRUEBAS DE SOFTWARE

REVELÓ

LIBRO DE ENTRENAMIENTO

SEGUNDA EDICION

POR EL INSTITUTO INTERNACIONAL DE PRUEBAS DE SOFTWARE™

www.test-institute.org

© COPYRIGHT INTERNATIONAL SOFTWARE TEST INSTITUTE™

Machine Translated by Google

Dedicación

A todos los estudiantes del International Software Test Institute™, gracias por inspirarnos,
mantenernos enfocados y asegurarnos de que hacemos todo lo posible para ayudarlos a
crecer en su carrera con sus habilidades y conocimientos. Sin usted, su compromiso y su leal
apoyo, International Software Test Institute™ no podría llegar a donde está hoy.
Machine Translated by Google

TABLA DE CONTENIDO CLICABLE

BIENVENIDOS 6 ................................................ .................................................... ......................

ACERCA DEL INSTITUTO INTERNACIONAL DE PRUEBAS DE SOFTWARE™ 7 .................................. ..........

Introducción a las pruebas de software 8 ............................................... ...............................

¿Qué es la garantía de calidad del software? 12 .................................................. ..................

¿Qué es la prueba de software? 18 .................................................. ......................................

Fundamentos de las pruebas de software 21 ............................................... ..........................

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

Métodos de prueba de software 36 ............................................... ........................................

Niveles de prueba de software 38 ............................................... ............................................

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

Pruebas manuales de software 49 .............................................. ..........................................

Machine Translated by Google

Pruebas de software automatizadas51 ............................................... .....................................

Ciclo de vida de la ingeniería de software en cascada 55 .................................... .............

Ciclo de vida de la ingeniería de software ágil 59 ....................................... .......................

Gestión de proyectos de software 62 .............................................. ..................................

Ciclo de vida de las pruebas de software y operaciones de pruebas de software 64 ..................

Entregables del Equipo de Pruebas de Software 66 ........................................... .....................

¿Qué es el riesgo de software y la gestión de riesgos de software? 71 ....................................

Procesos para apoyar las pruebas de software 75 ............................................... ...................

gracias 80 .............................................................. .................................................... ...................

Machine Translated by Google
BIENVENIDOS
¡Hola! Soy Yeliz.
Me encanta que se tome su tiempo para leer su libro Pruebas
de software. Quiero compartir brevemente con usted por qué
queríamos escribir este libro para usted y cómo puede
aprovecharlo al máximo.
En el contexto de nuestro programa de certificación de Pruebas
de software, realizamos una investigación exhaustiva en el
espacio educativo de Pruebas de software.
La conclusión fue: ¡Fallamos en encontrar un solo libro de texto
que sinceramente pudiéramos recomendar a nuestros
estudiantes!
Hablamos con nuestros estudiantes exitosos y descubrimos
que casi ninguno de los libros de pruebas de software en el
mercado realmente podría ayudarlos a hacer una entrada sin
problemas a las pruebas de software. Una cantidad significativa
de libros de pruebas de software en el mercado afirman que
cubren todos los detalles de las pruebas de software, pero lo
que no dicen es que no tienen un contenido comprensible,
claro y lógico para ayudar a sus lectores a comprender y, lo
que es más importante, a amar las pruebas de software. !
Por lo tanto, escribimos para usted Software Testing Revealed
y lo trajimos para su servicio.
Estamos absolutamente seguros de que Software Testing
Revealed lo hará competente en las pruebas de software, por
lo que tendrá una excelente oportunidad de amar las pruebas
de software y seguir disfrutando de los beneficios tangibles de
ser un profesional de las pruebas de software.
Tome un café para disfrutar y un poco de papel para tomar
sus notas, y pase un rato tranquilo para leer su libro de
Pruebas de software.
Luego, tendrá una gran comprensión sobre el dominio de
Pruebas de software y estará preparado para aprobar su
examen de certificación de Pruebas de software. ¡Estará listo
para ofrecer excelentes productos y servicios a sus clientes y
empleadores y construir su brillante carrera y futuro!
Yeliz Obergfell
Vicepresidente - Experiencia Estudiantil
Instituto Internacional de Pruebas de Software™
6
Machine Translated by Google
ACERCA DEL INSTITUTO INTERNACIONAL DE PRUEBAS DE SOFTWARE™
International Software Test Institute™ es un instituto
independiente que ayuda a organizaciones y profesionales a
acreditarse con programas de certificación de pruebas de
software válidos y de renombre mundial y demostrar su
competencia en el dominio de pruebas de software.
Capacitamos a los profesionales de todo el mundo para que
construyan sus carreras y a las empresas para que creen y
vendan sus productos y servicios sobresalientes.
Sus Programas de Certificación Accredited Software Tester,
Accredited Software Test Manager y Accredited Software Test
Automator han demostrado su aceptación y reputación en
todo el mundo al ser la elección de más de 349.000
profesionales de pruebas de software en 143 países.
La prueba de software es un proceso abierto que se puede
combinar con otros procesos y marcos de ingeniería de
software y, sin embargo, antes de que se estableciera el
International Software Test Institute™, no solía haber una
forma razonable para que los profesionales de prueba de
software como usted obtuvieran certificaciones de prueba de
software y probaran su competencia en el dominio de pruebas
de software. Los profesionales de pruebas de software
tuvieron que pagar costosas tarifas por el
Programas de Certificación de Pruebas de Software de otras
Entidades de Certificación con ánimo de lucro.
International Software Test Institute™ tiene como objetivo
eliminar las barreras impuestas a los profesionales de pruebas
de software en los mercados desarrollados y emergentes al
evitar que paguen tarifas irrazonables por los cursos de
capacitación en el aula de pruebas de software y los exámenes
de certificación de pruebas de software antes de que
certifiquen sus conocimientos en pruebas de software.
Además, no dude en consultar "¿Qué hace que sus programas
de certificación sean los mejores de la industria?" sección en
nuestro www.test-institute.org portal web para leer por qué
nos desempeñamos y le servimos mucho mejor que nuestra
competencia.
International Software Test Institute™ ofrece 3 importantes
programas de certificación de pruebas de software en línea
que están diseñados por nuestro consorcio de renombrados
líderes empresariales y personas, entrenadores, mentores,
expertos y autoridades de las principales industrias.
Puede consultar sus programas de certificación de pruebas
de software en esta lista de certificaciones de pruebas de
software.
7
Machine Translated by Google

Introducción a las pruebas de software miles de líneas de código y corregir un error no es una tarea
fácil. Nunca se sabe que al corregir un error, puede introducir
otro error sin saberlo en el sistema.
Las pruebas de software no son más que un arte de investigar
el software para garantizar que su calidad bajo prueba esté
en línea con los requisitos del cliente. Las pruebas de
software se llevan a cabo de manera sistemática con la
intención de encontrar defectos en un sistema. Es necesario
para evaluar el sistema. A medida que avanza la tecnología,
vemos que todo se digitaliza. Puede acceder a su banco en
línea, puede comprar desde la comodidad de su hogar y las
opciones son infinitas.
¿Se ha preguntado alguna vez qué pasaría si estos sistemas
resultan defectuosos? Un pequeño defecto puede causar una
gran pérdida financiera. Es por esta razón que las pruebas
de software ahora están emergiendo como un campo muy
poderoso en TI.

Aunque al igual que otros productos, el software nunca sufre

Metodología de Pruebas de Software en Software
ningún tipo de desgaste o corrosión, pero sí, los errores de
Ingeniería
diseño definitivamente pueden dificultarle la vida si no se
detectan. Las pruebas periódicas garantizan que el software
se desarrolle según los requisitos del cliente. Sin embargo, si
Las pruebas de software son ahora una parte muy importante
el software se envía con errores integrados, nunca se sabe
e integral del desarrollo de software. Idealmente, es mejor
cuándo pueden crear un problema y luego será muy difícil
introducir pruebas de software en cada fase del ciclo de vida
rectificar el defecto porque escanear cientos y
del desarrollo de software. En realidad, la mayor parte del
tiempo de desarrollo de software ahora se dedica a las pruebas.

8
Machine Translated by Google

persona tiene la tendencia a cometer un error. No es posible

crear software con cero defectos sin incorporar pruebas de
software en el ciclo de desarrollo.

6 No importa qué tan bien se vea el diseño del software en el

papel, una vez que comience el desarrollo y comience a
probar el producto, definitivamente encontrará muchos
defectos en el diseño.

No se puede lograr la calidad del software sin pruebas de software.

Incluso si los evaluadores no están involucrados en la codificación
real, deben trabajar en estrecha colaboración con los desarrolladores
Introducción a las pruebas de software
para mejorar la calidad del código. Para obtener los mejores
resultados, es importante que las pruebas de software y la
codificación vayan de la mano.
Entonces, para resumir podemos decir que:
1 Se requiere una prueba de software para verificar la
Descripción general de las
confiabilidad del software
pruebas de software Los defectos surgen en el software debido a
2 Las pruebas de software aseguran que el sistema esté libre de
muchas razones. De hecho, se dice que cada aplicación de software
cualquier error que pueda causar cualquier tipo de falla
tiene algunos defectos integrados, pero no todos los defectos son
una amenaza para el sistema. Hay mucho que se puede lograr con
3 Las pruebas de software aseguran que el producto está en línea
la ayuda de las pruebas de software. Las pruebas ayudan a evaluar
con los requisitos del cliente
la calidad del software.
4 Es necesario asegurarse de que la versión final
el producto es fácil de usar
5 Al final, el software es desarrollado por un equipo de
Hay muchas razones por las que las pruebas de software han
desarrolladores humanos, todos con diferentes puntos de
ganado tanta importancia en el campo de la
vista y enfoque. Incluso el más inteligente

9
Machine Translated by Google
tecnologías de la información. En primer lugar, las pruebas
ayudan a reducir el costo total del proyecto de desarrollo de
software. Si se ignoran las pruebas en las etapas iniciales de
desarrollo para ahorrar una pequeña cantidad de dinero, es
posible que luego resulte ser un asunto muy costoso porque, a
medida que avanza en el proceso de desarrollo, se vuelve cada
vez más difícil rastrear los defectos y corregirlos. defecto en
algún lugar puede introducir otro defecto en algún otro
módulo.
El requisito se finaliza después de varias conversaciones con el
cliente. Las pruebas aseguran que el software se comporta y se
ve exactamente como se menciona en el documento de
especificación de requisitos, de modo que cuando el software se
entrega al cliente no hay argumentos sobre la variación de los
requisitos originales. Las pruebas de software ayudan a fortalecer
la reputación de mercado de una empresa. El software bien
probado es de buena calidad y buena calidad significa mejores
comentarios y revisiones.
Para lograr los mejores resultados, es importante organizar
todos sus esfuerzos de prueba y de eso se trata esta capacitación
de prueba de software proporcionada por el Instituto Internacional
de Pruebas de Software. Las pruebas de software no pueden
ser fructíferas sin una planificación adecuada. para estar a la altura
a las expectativas del cliente es importante planificar cada paso
cuidadosamente. Se deben considerar muchas cosas para
planificar sus esfuerzos de prueba.
Las pruebas de software deben planificarse teniendo en cuenta
el presupuesto, el cronograma y el rendimiento para lograr los
mejores resultados.
Todas las actividades de prueba requieren planificación. Es
importante delinear un plan de prueba que proporcione detalles
sobre cómo se llevará a cabo cada actividad. También se
requiere un plan de prueba para garantizar que todos los
aspectos del software se cubran a fondo y que no haya repetición
del proceso de prueba para que no se desperdicie tiempo ni esfuerzo.
La última tendencia ahora es involucrar al equipo de pruebas en
el proceso de redacción de especificaciones. Es importante que
el equipo de pruebas comprenda claramente los requisitos del
cliente, ya que todo el desarrollo se basa en los requisitos
definidos por el cliente.
Cualquier cosa que no esté en línea con el requisito es un
defecto. Por lo tanto, el equipo de pruebas debe tener una idea
clara sobre cómo debería ser el resultado final de ejecutar el
software. De hecho, es importante comenzar a escribir casos de
prueba en paralelo a la escritura de especificaciones. Esto
ayudará a los probadores a analizar si todos los requisitos son
comprobables o no. Cuando escribe casos de prueba en paralelo
al proceso de escritura de especificaciones
10
Machine Translated by Google

pensará críticamente sobre las especificaciones y

sabrá si hay un problema con el requisito o si hay
algo que no se puede desarrollar.

11
Machine Translated by Google

¿Qué es la garantía de calidad

del software?

Cuando hablamos de la calidad del software, en realidad

estamos hablando de la evaluación del software en función
de ciertos atributos. La calidad de un software se define en
base al estudio de las características externas e internas del
software. La calidad externa se define en función de cómo se
desempeña el software en un escenario de tiempo real en
modo operativo y qué tan útil es para sus usuarios.
La calidad interna, por otro lado, se enfoca en los aspectos
intrínsecos que dependen de la calidad del código escrito. El
usuario se enfoca más en cómo funciona el software a nivel
externo, pero la calidad a nivel externo se puede mantener
solo si el codificador ha escrito un código significativo de
buena calidad.
¿Qué es la garantía de calidad del software?
Actualmente hay dos enfoques importantes que se utilizan
para determinar la calidad del software: 1 Enfoque de gestión
de defectos 2 Enfoque de atributos de calidad
Calidad del software
Como se mencionó anteriormente, cualquier cosa que no
esté en línea con los requisitos del cliente puede considerarse
un defecto. Muchas veces, el equipo de desarrollo no logra
comprender completamente los requisitos del cliente, lo que
eventualmente conduce a un error de diseño. Además de
eso, el error puede deberse a una lógica funcional deficiente,
una codificación incorrecta o un manejo inadecuado de los
datos. Para realizar un seguimiento de los defectos, se puede
aplicar un enfoque de gestión de defectos. En la gestión de
defectos, las categorías de defectos se definen en función de la gravedad
Se cuenta el número de defectos y se toman medidas según
la gravedad definida. Se pueden crear gráficos de control
para medir la capacidad del proceso de desarrollo.

12
Machine Translated by Google
Enfoque de gestión de defectos
El enfoque de atributos de calidad, por otro lado, se centra
en seis características de calidad que se enumeran a
continuación:
1. Funcionalidad: se refiere al conjunto completo de
funciones importantes que proporciona el software
•
Idoneidad: si las funciones del software son
apropiadas
• Precisión: ¿las funciones están implementadas
correctamente? • Interoperabilidad: ¿cómo interactúa
el software con otros componentes del sistema?
Enfoque de atributos de calidad
• Cumplimiento: ¿cumple el software con las leyes y
directrices necesarias? • Seguridad: ¿El software es
capaz de manejar transacciones relacionadas con datos
de forma segura?
2. Confiabilidad: esto se refiere a la capacidad del software
para funcionar bajo ciertas condiciones por una duración
definida. Esto también define la capacidad del sistema para
resistir la falla de los componentes.
•
Madurez: frecuencia de falla del software
13
Machine Translated by Google
• •
Capacidad de recuperación: esto da una idea de la capacidad
de un sistema para volver a funcionar por completo después
de una falla.
3. Usabilidad: se refiere a la facilidad de uso de una función.
• Comprensibilidad: con qué facilidad las funciones pueden
ser entendido
• Capacidad de aprendizaje: cuánto esfuerzo deben realizar los
usuarios de diferentes niveles para comprender las funciones.
4. Eficiencia: generalmente depende de la buena arquitectura y las
prácticas de codificación seguidas durante el desarrollo del software.
5. Mantenibilidad: también conocida como capacidad de soporte.
Depende en gran medida de la legibilidad y la complejidad del código y
se refiere a la capacidad de identificar y corregir una falla en un software:
• Analizabilidad: identificación de la principal causa de fallo.
• Cambiabilidad: define el esfuerzo que se dedica a la modificación
del código para eliminar una falla.
• Estabilidad: qué tan estable es un sistema en su desempeño
cuando se le hacen cambios
Capacidad de prueba: cuánto esfuerzo se dedica a probar el
sistema.
6. Portabilidad: capacidad del sistema para adaptarse a los cambios
en su entorno • Adaptabilidad: con qué facilidad se adapta un sistema
a los cambios realizados en las especificaciones Instalabilidad: con
qué facilidad se puede instalar un sistema. • Conformidad: esto
•
es lo mismo que el cumplimiento en la funcionalidad.
•
Capacidad de reemplazo: qué tan fácil es reemplazar un
componente del sistema en un entorno dado.
Costo de la calidad del software
El costo de la calidad es importante porque cuando decide realizar
pruebas de software para su producto, en realidad va a invertir su
tiempo, dinero y esfuerzo en realizar controles de calidad. Al realizar un
análisis del costo de la calidad del software, sabrá cuál es el retorno de
esa inversión (ROI).
14
Machine Translated by Google
Costo de la calidad del software
El costo de la calidad se calcula analizando los costos de conformidad
y los costos de no conformidad. Un costo de conformidad está
relacionado con:
1 Costos de prevención: cantidad gastada en asegurar que todas
las prácticas de aseguramiento de la calidad se sigan
correctamente. Esto incluye tareas como capacitar al equipo,
revisiones de código y cualquier otra actividad relacionada con
el control de calidad, etc.
2 Costos de evaluación: esta es la cantidad de dinero gastada en
planificar todas las actividades de prueba y luego llevarlas a
cabo, como desarrollar casos de prueba y luego ejecutarlos.
El costo de no conformidad por su parte es el gasto que surge por: 1
Fallas internas: es el gasto que surge cuando se ejecutan casos de
prueba por primera vez a nivel interno y algunos de ellos fallan. Los
gastos surgen cuando el programador tiene que rectificar
todos los defectos descubiertos de su pieza de código en el
momento de la prueba unitaria o de componentes.
2 Fallos externos: es el gasto que se produce cuando el defecto lo
encuentra el cliente en lugar del probador. Estos gastos son
mucho más de los que surgen a nivel interno, especialmente
si el cliente queda insatisfecho o escala la falla del software.
Costo de la falla del software
Sabemos que un fallo de software se produce cuando:
1 Muestra falta de capacidad para mantenerse al día: esto
generalmente sucede cuando el software comienza a
envejecer. A medida que envejece, el tamaño aumenta porque
la forma más fácil de agregar una función es agregar código
nuevo sin tocar ninguna parte del código escrito anteriormente.
Con el tiempo, se vuelve voluminoso y se vuelve difícil
identificar las secciones de código que deben cambiarse.
15
Machine Translated by Google
2 Se observa una disminución del rendimiento: todas las
aplicaciones generalmente se ralentizan con el tiempo y
tienden a ocupar más y más memoria de la computadora,
por lo que 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 corregir un error, se introducen más defectos
en el sistema.
Sorprendentemente, esta es una de las principales razones
del aumento de las tasas de fallas y, para salvar la situación,
siempre es mejor deshacerse del proyecto o renunciar a la
corrección de errores.
Pruebas de software VS Garantía de calidad En
la industria de TI, a menudo se observa que las personas
generalmente no diferencian entre la garantía de calidad del
software y las pruebas de software. Los evaluadores a menudo se
consideran profesionales de aseguramiento de la calidad del
software porque los objetivos de las pruebas de software y el
aseguramiento de la calidad son los mismos, es decir, garantizar
que el software sea de la mejor calidad.
Como su nombre indica, los procesos de garantía de calidad se
llevan a cabo para garantizar que la calidad del producto esté en
línea con los requisitos del cliente. Los profesionales de
aseguramiento de la calidad trabajan en el desarrollo e
implementación de todos los procesos necesarios para
asegurarse de que todos los procedimientos necesarios del ciclo
de vida del desarrollo de software se sigan correctamente. El
control de calidad es una actividad proactiva que se centra en: 1
Prevención de defectos
2 Procesos
3 Mejora continua de estos procesos
Las pruebas de software, por otro lado, se llevan a cabo para
identificar o descubrir defectos y errores en el software.
Se trata de pruebas rigurosas reales del software para ver si hay
defectos o variaciones de los requisitos del cliente que deben
corregirse. Las pruebas de software son parte del proceso de
control de calidad y se enfocan solo en actividades orientadas al
producto. La prueba del software se lleva a cabo durante la fase
de prueba y solo los defectos se identifican y no se corrigen en
este proceso. La reparación de defectos no forma parte de las
pruebas de software.
Garantía de Calidad VS Control de Calidad
Otro tema que está estrechamente relacionado con la garantía de
calidad es el control de calidad. La gente a menudo se confunde
entre los dos, pero hay una gran diferencia. Mientras que el
aseguramiento de la calidad tiene que ver con las actividades
preventivas, el control de la calidad se enfoca en los procesos
correctivos.
dieciséis
Machine Translated by Google
Esto es lo que debe comprender: las pruebas de software son
un subconjunto del control de calidad y el control de calidad es
un subconjunto de la garantía de calidad. Todo el enfoque del
aseguramiento de la calidad está en la implementación de
procesos y procedimientos que se requieren para la verificación
del software en desarrollo y los requisitos del cliente.
Garantía de Calidad VS Control de Calidad
El control de calidad, por otro lado, se ocupa de las actividades
reales que aseguran que el producto se desarrolle de acuerdo
con los requisitos definidos. Se ocupa de todas las acciones
que son importantes para controlar y verificar ciertas
características del producto, incluidas las pruebas. El examen
y la prueba de los productos es el aspecto más importante del
control de calidad.
Las empresas emplean un equipo de control de calidad para
identificar si hay algún producto o servicio que no cumpla con
el estándar de calidad de la empresa. Si hay un problema, el
equipo de control de calidad tiene la autoridad para detener la
producción de ese producto hasta que se resuelva el problema.
La importancia de la auditoría y la
inspección La auditoría se compone de algunos procesos
muy sistemáticos que definen cómo se llevan a cabo las
pruebas de software en la organización. El equipo de auditoría
examina todos los procesos que se llevan a cabo en el momento de la pru
IEEE define la auditoría como una revisión de los procesos
documentados para garantizar que la organización o un equipo
siga todos los procesos según los estándares definidos.
La inspección puede ser una revisión formal o informal de los
requisitos, el diseñador o el código del software. Lo lleva a
cabo un equipo o una persona individual que no sea el autor
para verificar si hay violaciones o desviaciones de los
estándares de desarrollo definidos.
Los siguientes procesos se consideran parte de la inspección:
1 Planificación 2 Resumen Preparación 3 Reunión de
inspección 4 Reelaboración 5 Seguimiento
17
Machine Translated by Google

¿Qué es la prueba de software? llevado a cabo en todos los niveles de pruebas de software: unidad,
integración, sistema y aceptación.

Entonces, finalmente llegamos al tema principal que es la prueba de

software en sí. Ya ha entendido el significado de las pruebas de
software y por qué es importante al pasar por las secciones anteriores.
Aquí, a partir de esta sección, profundizaremos en el tema, pero antes
de continuar, revisemos la definición de pruebas de software.

La prueba de software no es más que el proceso de evaluar la

funcionalidad del software para garantizar que esté en línea con los
requisitos del cliente.

Las pruebas se clasifican ampliamente en: Pruebas de caja negra

1 Pruebas Dinámicas: realizadas mediante la ejecución del programa
2 Prueba estática: implica el examen del código
y documentos relacionados.
Las pruebas dinámicas y estáticas a menudo se usan juntas.
Pruebas de caja negra
Las pruebas de caja negra se centran únicamente en la funcionalidad
del software. El probador no examina los detalles internos del software.
La prueba de caja negra es
Los procedimientos de prueba para las pruebas de caja negra son
muy simples. El evaluador solo se enfoca en lo que se supone que
debe hacer el software. Se supone que el probador no debe centrarse
en cómo el software gestiona la función internamente. Los casos de
prueba para las pruebas de caja negra se crean teniendo en cuenta
solo las especificaciones y los requisitos. No se crea ningún caso de
prueba para comprobar la lógica interna del software. El probador solo
ingresa entradas válidas e inválidas y verifica la salida para estos
valores.

18
Machine Translated by Google
Pruebas de caja blanca
A diferencia de las pruebas de caja negra, las pruebas de caja
blanca se llevan a cabo en profundidad hasta el nivel del código
fuente. En esta forma de probar la lógica interna, se examina su
implementación y funcionamiento y se escriben los casos de
prueba para comprobar cómo funciona el software a nivel interno.
Las pruebas de caja blanca se pueden realizar a nivel de unidad,
integración y sistema.
Las pruebas de caja blanca a menudo se utilizan para detectar
errores de diseño internos que, de otro modo, serían muy difíciles
de descubrir; sin embargo, esta forma de prueba no verifica si
faltan requisitos o especificaciones.
Pruebas de caja blanca
Cobertura de estado de cuenta
La cobertura de declaraciones es una forma de prueba en la que
el código se prueba de tal manera que cada declaración de
el código se ejecuta al menos una vez. La idea detrás de esta
forma de prueba es garantizar que cada declaración en cada
bloque de código se ejecute al menos una vez y se observen los
resultados. Esta forma de prueba también se conoce como forma
de prueba de cobertura de línea o cobertura de segmento.
El punto a tener en cuenta aquí es que cada declaración se ejecuta
una vez, lo que significa que puede haber algunas condiciones en
algunos bloques que no se pueden probar de esta manera. Por lo
tanto, existe la posibilidad de que algunos errores pasen
desapercibidos en el proceso de cobertura de estados de cuenta.
Cobertura de decisión
La cobertura de decisión o cobertura de sucursal se ocupa de
probar todas las condiciones verdaderas y falsas del código.
La razón por la que también se denomina cobertura de sucursal es
porque una sucursal es el resultado de una decisión. Se considera
que es una forma de prueba más efectiva que la simple cobertura
de declaraciones. Una declaración de decisión puede ser:
1 Una declaración IF
2 Una declaración de control de bucle como do-while
3 Una declaración que puede tener dos o más
resultados también conocido como sentencia CASE.
19
Machine Translated by Google

Lo bueno de la cobertura de decisiones es que puede validar todas Por ejemplo:

las ramas en el código y puede verificar la eficiencia del código de
una mejor manera que el enfoque de cobertura de declaraciones. Si (x=verdadero O y=verdadero)
Después
Imprimir ("Hola")
Cobertura de condición Más
La prueba de cobertura de condición se lleva a cabo para verificar Imprimir ("Adiós")
condiciones que generalmente son expresiones booleanas y
proporcionan un resultado VERDADERO o FALSO. La cobertura de Aquí, en este caso hay cuatro posibles combinaciones de condiciones:
condición puede o no cubrir la cobertura de decisión completa. En
este proceso solo se prueban aquellas condiciones que devuelven
verdadero o falso. Las expresiones que devuelven una condición Testcase1: x=verdadero; y=verdadero

booleana generalmente juegan un papel muy importante en la Testcase2: x=verdadero; y=falso

decisión final. Esta es la razón por la que se llevan a cabo las Testcase3: x=falso; y=verdadero
pruebas de cobertura de condición. Testcase4: x=falso; y=falso

Cobertura de decisión/condición De manera similar, para 3 expresiones habrá 8 combinaciones de

Como sugiere el nombre, la metodología de cobertura de decisión/ condiciones.
condición 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
sólida de probar el software.

Cobertura de condiciones múltiples

La cobertura de condiciones múltiples o la cobertura de combinación
de condiciones se lleva a cabo para verificar la salida de múltiples
combinaciones de condiciones.

20
Machine Translated by Google

detectados, se pueden rectificar fácilmente y se puede mejorar la

Fundamentos del Software
calidad del software. Por lo tanto, las pruebas de software son

Pruebas necesarias para que se puedan desarrollar y entregar aplicaciones

libres de errores. Cuando una empresa decide desarrollar software
para un cliente, existen ciertos requisitos legales, contractuales y
Las pruebas de software son un tema muy amplio. Hay aplicaciones
específicos de la industria basados en el trato que se realiza. Una
de software y sistemas diseñados para numerosos dominios e
empresa consciente de la calidad definitivamente incluirá pruebas de
industrias, y para un probador, cada proyecto de prueba es un nuevo
software en sus mejores prácticas.
desafío porque debe comprender el punto de vista del cliente y el
dominio antes de continuar con las actividades de prueba. De un
proyecto a otro, un probador también puede tener que cambiar las
Es difícil decir cuántas pruebas son suficientes, pero el hecho es que
metodologías de prueba. Por lo tanto, es muy importante mantener los
si las pruebas se planifican cuidadosamente y se realizan buenos
fundamentos correctos. Tener los fundamentos correctos en primer
casos de prueba, es muy posible entregar software de alta calidad.
lugar es el requisito previo más importante para tener éxito en las
pruebas de software.

¿Quién hace las pruebas de software?

A menudo hay un debate sobre quién debería probar el software. La
gente a menudo se pregunta por qué los desarrolladores no pueden
¿Por qué son necesarias las pruebas de software?
realizar pruebas. Bueno, un desarrollador generalmente revisa su
Los desarrolladores pueden causar un error, un defecto o un error. No
código varias veces antes de enviarlo para la prueba y aún así, en la
es intencional, pero teniendo en cuenta la complejidad con la que se
mayoría de los casos, nunca está libre de errores porque un
están desarrollando varios software en estos días, es muy posible que
desarrollador generalmente es ciego a sus propios errores.
un desarrollador malinterprete e implemente una lógica incorrecta y
produzca un código incorrecto.

Un probador, por otro lado, mira el software desde el punto de vista

del cliente. Es imparcial y se enfoca solo en las especificaciones y el

Las pruebas son necesarias porque nos ayudan a identificar las fallas
en el software. Una vez que estos defectos han sido

21
Machine Translated by Google

requisitos Por lo tanto, un probador puede buscar áreas que un El escenario de tiempo en el que se implementará el software
desarrollador puede haber ignorado. Por lo tanto, las pruebas puede ayudar al evaluador a comprender cómo llevar a cabo las
siempre deben ser realizadas por probadores independientes. pruebas para el proyecto. Es muy importante saber lo que
Este enfoque tiene algunas desventajas. Cuando los equipos de realmente se debe probar para diseñar una estrategia de prueba.
desarrollo y prueba son diferentes, a menudo hay una brecha de
comunicación y, a veces, los desarrolladores se vuelven
descuidados con la codificación y no revisan su código porque
piensan que todo es trabajo de un probador, lo que aumenta la
carga sobre el probador.

Muchas veces los desarrolladores comparten su trabajo entre

ellos y prueban el trabajo de los demás. Esto se conoce como
prueba de compañeros. Cada equipo de desarrollo debe tener
probadores dedicados y cada proyecto generalmente tiene al
menos un equipo de prueba dedicado. Algunas empresas creen
en tener equipos separados para diferentes tipos de pruebas, lo
que significa diferentes equipos para la usabilidad, el rendimiento,
la seguridad y otras formas de prueba. Algunas empresas creen
en la subcontratación del trabajo de prueba de software, lo que
significa que contratan a una empresa o evaluadores o consultores ¿Qué tiene que ser realmente probado?
independientes para que analicen y prueben su proyecto.

¿Cuándo se realiza la prueba del software?

Cuanto antes comience el equipo de pruebas a probar el software,
¿Qué tiene que ser realmente probado? más fácil será para los desarrolladores completar el proyecto a
El probador debe tener una buena comprensión de los requisitos tiempo y esto también ahorrará mucho tiempo, dinero y esfuerzo.
del proyecto. Una idea justa sobre lo real. Comenzando la prueba

22
Machine Translated by Google

en las últimas etapas de desarrollo puede resultar un asunto

costoso, ya que es muy difícil rectificar los defectos una vez que
el software ha llegado a las etapas finales de desarrollo. Dividir
el desarrollo de software en etapas y luego probar el trabajo
realizado en cada etapa antes de continuar a la siguiente etapa
ayuda a terminar el desarrollo del software a tiempo con buenos
resultados. Esto también ayuda a una mejor integración de los
diferentes módulos porque ya sabe que cada módulo se ha
probado de forma independiente y funciona según las
especificaciones dadas.

¿Con qué frecuencia tenemos que hacer la prueba?

La frecuencia con la que debe realizar la prueba depende de la

importancia de la calidad para usted. Idealmente, las pruebas
deben ir de la mano con el desarrollo y un probador debe
centrarse en descubrir el máximo número de defectos durante
¿Con qué frecuencia tenemos que hacer la prueba?
las fases iniciales del desarrollo del software para que, si el
diseño del software requiere algún cambio, pueda hacerse
pronto, ya que será muy difícil. difícil y costoso hacer cambios ¿Qué son los estándares de prueba de software?
importantes en el proyecto durante las últimas etapas de Los estándares de prueba de software son de gran importancia
desarrollo. tanto desde el punto de vista del consumidor como del productor.
Un consumidor invierte en el software y si el software es de
buena calidad, al final del día está satisfecho de haber comprado
lo correcto para él.

23
Machine Translated by Google
Todas las empresas de renombre se aseguran de que la calidad del
software del producto se rija por algunos conjuntos de estándares que
han sido aprobados por el público. Al cumplir con estos estándares, una
empresa brinda seguridad sobre sus productos y puede brindar garantías
a sus clientes solo cuando ha seguido algunos estándares y sabe que el
software se comportará de cierta manera. Por lo tanto, el consumidor
sabe que está comprando lo correcto si cumple con los estándares
correctos.
Desde el punto de vista del productor, las normas ayudan a mejorar la
calidad del producto final. Una vez que una empresa ha finalizado el
estándar que debe seguir, se vuelve más fácil para ellos trabajar en
otros proyectos de software y cada vez que comienzan un nuevo
proyecto no necesitan comenzar todo desde cero. Hay muchos tipos de
estándares de prueba de software definidos para evaluar la calidad del
software que puede mejorar en gran medida la eficacia de las pruebas
de software; sin embargo, se cree que hasta ahora no se han elaborado
tales estándares que puedan cubrir todos
aspectos de las pruebas de software.
Estándares que enfatizan tener pruebas como parte de un requisito más
grande o estándares que respaldan
Las pruebas de software son las que pueden ser de utilidad para las
pruebas de software.
¿Qué es la capacidad de prueba del software?
La capacidad de prueba del software se utiliza para medir la facilidad
con la que se puede probar un sistema de software. La capacidad de
prueba se calcula en las primeras fases del desarrollo del software para
averiguar cuántos recursos se necesitarán para finalizar el proceso de
prueba. Si bien las pruebas ayudan a descubrir defectos, la capacidad
de prueba juega un papel importante en la identificación de las áreas
clave donde los errores permanecen ocultos a la vista de un evaluador.
Cuando la capacidad de prueba es alta, significa que la prueba es más
fácil y una capacidad de prueba más baja significa que se debe aumentar
el esfuerzo de prueba. La capacidad de prueba se puede determinar
mediante:
1 Controlabilidad: el proceso de prueba se puede optimizar solo si
podemos controlarlo.
2 Observabilidad: lo que ves es lo que se puede probar. Los factores
que afectan el resultado final son visibles.
3 Disponibilidad: Para probar un sistema tenemos que llegar a él.
4 Simplicidad: cuando el diseño es autoconsistente, las características
no son muy complejas y las prácticas de codificación son
simples, entonces hay menos para probar.
24
Machine Translated by Google

Cuando el software ya no es simple, se vuelve difícil de el enfoque de la verificación está en la calidad del software que se
probar. está desarrollando, ya sea que siga todos los estándares o no,
5 Estabilidad: si se realizan demasiados cambios en el diseño de ¿está bien diseñado?
vez en cuando, habrá muchas interrupciones en las pruebas
de software. Entonces, mientras que la validación verifica si las especificaciones
6 Información: La eficiencia de las pruebas depende en gran se diseñaron correctamente para cumplir con los requisitos del
medida de la cantidad de información disponible para el cliente, la verificación verifica si el software se desarrolló de acuerdo
software. con los estándares y normas de calidad del software de la
organización de ingeniería de software.
Esto es lo que necesita saber sobre la capacidad de prueba:
1 Mayor capacidad de prueba significa mejores pruebas y menos
cantidad de errores
2 Una menor capacidad de prueba significa que las pruebas no
son de gran calidad y existe la posibilidad de que haya más
errores en el sistema.

Verificación de software VS Validación de software

Verificación y validación son dos términos muy importantes en las
pruebas de software. Las personas a menudo se confunden entre
los dos; sin embargo, estos dos términos están relacionados con
dos tipos diferentes de análisis. La validación ayuda a construir el
sistema correcto. Mientras llevamos a cabo la validación, Verificación de software VS Validación de software
observamos si el sistema está en línea con los requisitos del cliente
o no. Algunas teorías sugieren que la verificación se lleva a cabo en cada
fase del ciclo de vida del desarrollo del software, pero no ocurre lo
La verificación, por otro lado, ayuda a garantizar si el sistema se mismo con la validación. Las validaciones son cruciales al principio
está desarrollando de la manera correcta. los y hacia el final de

25
Machine Translated by Google
el proyecto, es decir, durante el análisis de requisitos y las pruebas
de aceptación. Esta táctica no es del todo correcta y es casi imposible
de seguir. El hecho real es que hasta el día de hoy se ha observado
que es muy difícil capturar todo el conjunto de requisitos del cliente
durante el inicio del proyecto.
Los requisitos de software a menudo sufren varios cambios incluso
después de que se ha iniciado el desarrollo.
Muchas veces los cambios son solicitados por el propio equipo de
desarrollo. Por lo tanto, es importante llevar a cabo procesos de
validación y verificación en cada fase del desarrollo del software.
Hoy en día, los probadores suelen considerar la verificación y la
validación, también conocidas como V&V, como una forma poderosa
de ver varios aspectos del software.
Pruebas de software VS Depuración de software
Este es otro tema en el que la gente generalmente se confunde. La
prueba y la depuración de software pueden sonar como la misma
cosa, pero ese no es realmente el caso. Para empezar, el proceso
de depuración comienza cuando finaliza la prueba de software.
Mientras que las pruebas de software descubren defectos, la
depuración elimina los defectos del sistema.
Una vez que se completan las pruebas, los evaluadores envían los
informes y el equipo de desarrollo comienza a buscar la causa raíz
de los defectos. En este proceso, el desarrollador escanea todos los
módulos relacionados e intenta encontrar el problema en el código;
una vez hecho esto es hora de rectificar el defecto. Entonces, la
depuración es el proceso en el que se descubre la causa de los
defectos informados y luego se rectifican los defectos paso a paso.
La depuración es el proceso de resolución de problemas existentes.
No es prudente rectificar un defecto hasta que se conozcan por
completo todas las posibles razones detrás de él. Si comienza a
depurar sin un conocimiento completo sobre el defecto, entonces
hay posibilidades de que en el proceso de rectificación de un defecto
pueda introducir algún otro en cualquiera de los módulos
interrelacionados. Los desarrolladores deben evitar la experimentación
en el momento de la depuración, ya que esto puede causar muchos
problemas. Una vez que se soluciona un defecto, el desarrollador
envía el trabajo al probador, quien probará a fondo todo el módulo.
1 Las pruebas de software descubren defectos y la depuración
los localiza y corrige.
2 Las pruebas de software son un aspecto muy importante del
ciclo de desarrollo de software, mientras que la depuración
es el resultado de las actividades de prueba.
26
Machine Translated by Google

3 Las pruebas comienzan poco después de que comience el desarrollo.

La depuración comienza cuando los evaluadores comienzan a
informar defectos.

4 Las pruebas de software implican la verificación y validación (V&V)

del software, mientras que la depuración busca la causa real
detrás del defecto y la corrige.

¿Qué es un defecto?
Defecto es cualquier cosa que no esté en línea con las especificaciones
de requisitos de software. El defecto generalmente existe en el código del
programa o en su diseño.
Esto da como resultado una salida incorrecta en el momento de la
ejecución del programa.
1 Un fragmento de código se denomina buggy cuando tiene demasiados
defectos.
2 Error informa los detalles sobre la naturaleza de la
insecto.
¿Qué es un defecto?

3 Las herramientas de seguimiento de errores se emplean para rastrear

errores en un sistema. ¿Qué son la gravedad y la prioridad?

4 Existe una técnica de prueba muy interesante en la que los defectos La gravedad define la gravedad del impacto de un defecto en el

se inyectan deliberadamente en el código y luego se monitorea el
resultado para verificar si el sistema funciona como se espera en
caso de ciertos problemas.
rendimiento del sistema. La gravedad puede ser de uno de los siguientes
tipos:
1 Crítico: tal defecto no permite que la aplicación funcione
correctamente debido a una falla del sistema o corrupción de
datos. Los defectos críticos sí

27
Machine Translated by Google

no permite que el usuario se mueva más y lo pone en 2 Medio: el defecto debe resolverse poco después de que se
una posición miserable. hayan resuelto los defectos con mayor prioridad.
2 Mayor: Los defectos mayores son un poco menos severos
que los defectos críticos. Pueden hacer que el sistema 3 Alto: El defecto con alta prioridad significa que requiere
falle; sin embargo, en caso de un defecto importante, atención inmediata y debe ser resuelto lo antes posible.
existe otra forma posible de lograr el resultado deseado
y el usuario no necesita capacitación para ello.
Entonces, una vez que reciba el informe de gravedad y prioridad
3 Moderado: Estos defectos no causan la de los defectos, esto es lo que necesita saber:
el sistema falle pero produzca resultados erróneos o
contradictorios.
4 Menores: Los defectos que no causan fallas en el sistema
ni afectan la usabilidad del sistema y que pueden
corregirse fácilmente se conocen como defectos menores.
5 Cosmético: Defectos relacionados con el aspecto o
apariencia del sistema se denomina defecto cosmético.

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

la prioridad junto con la gravedad del defecto. La prioridad en
realidad le dice al desarrollador el orden en que se deben
resolver los defectos. Puede ser de los siguientes tipos: 1 Baja:
el defecto no requiere atención inmediata y debe ser subsanado
una vez resueltos los defectos de mayor prioridad.
¿Qué son la gravedad y la prioridad?

28
Machine Translated by Google

1 Si un defecto tiene alta prioridad y alta gravedad,

significa que hay un problema en la funcionalidad
básica del sistema y el usuario no está en
condiciones de utilizar el sistema. Dichos defectos
deben corregirse inmediatamente.
2 Los defectos que tienen alta prioridad y baja gravedad
pueden ser errores ortográficos en el nombre de la
empresa o problemas con el logotipo. Dichos
defectos son de baja gravedad, pero deben
corregirse de inmediato y deben considerarse
como defectos de alta prioridad.
3 Defecto de alta gravedad y baja prioridad significa
que hay un defecto importante en algún módulo,
pero el usuario no lo usaría de inmediato, por lo
que el defecto se puede corregir un poco más tarde.
4 Los defectos de baja prioridad y baja gravedad son
generalmente de naturaleza cosmética y no afectan
la funcionalidad del sistema, por lo que dichos
defectos se rectifican al final.

29
Machine Translated by Google

Roles de prueba de software y • Basándose en la información obtenida en el paso anterior,

Responsabilidades
En el caso de las pruebas de software, cada empresa define su
propio nivel de jerarquía, roles y responsabilidades, pero en un nivel
más amplio, si observa, siempre encontrará los siguientes dos
niveles en un equipo de pruebas de software:
decida cómo se va a probar.
• Informar al líder de prueba sobre lo que todos los recursos
será necesario para las pruebas de software.
• Desarrollar casos de prueba y priorizar actividades de prueba.
• Ejecutar todos los casos de prueba y reportar defectos, definir
severidad y prioridad para cada defecto. • Realizar pruebas
de regresión cada vez que se realicen cambios en el código para
corregir defectos.

Líder de prueba/gerente: un líder de prueba es responsable de:

Descripción general del equipo de ingeniería de
• Definición de las actividades de prueba para los subordinados
software La forma en que se perfila una aplicación de software
– probadores o ingenieros de pruebas.
durante el proceso de desarrollo depende completamente de cómo
•
Todas las responsabilidades de planificación
el equipo de ingeniería de software organiza el trabajo e implementa
de pruebas. • Verificar si el equipo cuenta con todos los recursos
diversas metodologías. Para que una aplicación se desarrolle
necesarios para ejecutar las actividades de prueba. •
correctamente, es importante que todos los procesos incorporados
Comprobar si las pruebas van de la mano con el desarrollo del
durante el desarrollo del software sean estables y sostenibles.
software en todas las fases. • Preparar el informe de estado
Muchas veces, los desarrolladores se ven presionados a medida
de las actividades de prueba. • Interacciones requeridas con los
que se acerca la fecha de entrega, lo que a menudo afecta la
clientes. • Actualizar al gerente del proyecto regularmente sobre
calidad del software. Acelerar los procesos para terminar el proyecto
el progreso de las actividades de prueba.
a tiempo solo producirá una aplicación de software que tiene un uso
mínimo o nulo para los clientes. Por lo tanto, la organización y la
planificación del trabajo son importantes y cumplir con el plan es
Los ingenieros de prueba/los probadores de control de calidad/los probadores de
muy importante.
control de calidad son responsables de:
• Para leer todos los documentos y entender
El director del proyecto debe asegurarse de que no haya
lo que hay que probar.

30
Machine Translated by Google
obstáculos en el proceso de desarrollo y si hay algún problema,
debe resolverse con atención inmediata.
Descripción general del equipo de prueba
de software Qué tan pronto y qué tan bien puede lograr sus
objetivos de prueba depende únicamente de las capacidades del
equipo de prueba. Dentro del propio equipo de pruebas, es
importante contar con la combinación correcta de probadores que
puedan trabajar juntos de manera eficiente para lograr los objetivos
comunes de las pruebas. Al formar un equipo para la prueba, es
importante asegurarse de que los miembros del equipo tengan una
combinación de todos los conocimientos de dominio relevantes que
se requieren para probar el software en desarrollo.
Es muy importante asegurarse de que el equipo de pruebas de
software tenga una estructura adecuada. La jerarquía y los roles
deben estar claramente definidos y las responsabilidades también
deben estar bien definidas y distribuidas adecuadamente entre los
miembros del equipo. Cuando el equipo está bien organizado, el
trabajo se puede manejar bien.
Si cada miembro del equipo sabe qué deberes tiene que realizar,
entonces podrá terminar sus deberes según lo requerido dentro
del límite de tiempo. Es importante realizar un seguimiento del
rendimiento de los probadores.
Es muy importante comprobar qué tipo de defectos
probador es capaz de descubrir y qué tipo de detecta que tiende a
pasar por alto. Esto le dará una idea clara de qué tan serio es su
equipo con respecto al trabajo.
Todos los miembros del equipo deben trabajar juntos para preparar
un documento que defina claramente las funciones y
responsabilidades de todos los miembros del equipo. Una vez que
se prepara el documento, el papel de cada miembro debe
comunicarse claramente a todos. Una vez que los miembros del
equipo tengan claro quién se encargará de qué área del proyecto,
entonces, en caso de cualquier problema, será fácil determinar a
quién se debe contactar.
Cada miembro del equipo debe contar con los documentos
necesarios que brinden información sobre cómo se organizaría la
tarea, qué enfoque se seguirá, cómo se programan las cosas,
cuántas horas se han asignado a cada miembro y todos los detalles
relacionados con los estándares aplicables. y procesos de calidad.
Rol del probador de
software Un probador de software (ingeniero de prueba de software)
debe ser capaz de diseñar conjuntos de pruebas y debe tener la
capacidad de comprender los problemas de usabilidad. Se espera
que dicho probador tenga un conocimiento sólido de la prueba de software.
31
Machine Translated by Google
metodologías de diseño y ejecución de pruebas. Es muy importante que
un probador de software tenga grandes habilidades de comunicación
para que pueda interactuar con el equipo de desarrollo de manera
eficiente. Las funciones y responsabilidades de un probador de software
de usabilidad son las siguientes:
1 Un probador de software es responsable de diseñar escenarios de
prueba para las pruebas de usabilidad.
2 Es responsable de realizar las pruebas, luego analizar los resultados
y luego enviar sus observaciones al equipo de desarrollo.
3 Es posible que tenga que interactuar con los clientes para comprender
mejor los requisitos del producto o en caso de que el diseño
requiera algún tipo de modificación.
4 Los probadores de software a menudo son responsables de crear la
documentación del producto de prueba y también deben participar
en el recorrido relacionado con las pruebas.
Un probador de software tiene diferentes conjuntos de roles y
responsabilidades. Debe tener un conocimiento profundo sobre las
pruebas de software. Debe tener una buena comprensión del sistema, lo
que significa aspectos técnicos (GUI o interacciones humanas no GUI),
así como aspectos funcionales del producto. Con el propósito de crear
casos de prueba es importante que el evaluador de software conozca
varias técnicas de prueba y cuál es el mejor enfoque para un sistema en
particular. Debe saber cuáles son las diversas fases de las pruebas de
software y cómo se deben realizar las pruebas en cada fase.
Las responsabilidades del probador de software incluyen:
1 Creación de diseños de prueba, procesos de prueba, casos de
prueba y datos de prueba.
2 Realice las pruebas según el procedimiento definido.
res.
3 Participar en tutoriales de procedimientos de prueba
res.
4 Preparar todos los informes relacionados con las pruebas de software
realizadas.
5 Asegúrese de que todo el trabajo relacionado probado se lleva a cabo
de acuerdo con los estándares y procedimientos definidos.
res.
Función de administrador de pruebas
de software Administrar o liderar un equipo de pruebas no es un trabajo fácil.
La empresa espera que el director de pruebas conozca en detalle las
metodologías de prueba. Un administrador de pruebas tiene que tomar
decisiones muy importantes con respecto al entorno de prueba que se
requiere, cómo se administraría el flujo de información y cómo el
procedimiento de prueba iría de la mano con el desarrollo.
32
Machine Translated by Google
Debe tener un conocimiento sólido sobre las pruebas tanto manuales
como automatizadas para que pueda decidir cómo se pueden
combinar ambas metodologías para probar el software. Un gerente de
prueba debe tener un conocimiento sólido sobre el área comercial y
los requisitos del cliente, en base a eso, debe poder diseñar una
estrategia de prueba, una meta y objetivos de prueba. Debe ser bueno
en la planificación de proyectos, la coordinación de tareas y personas,
y debe estar familiarizado con varios tipos de herramientas de prueba.
Mucha gente se confunde entre las funciones y responsabilidades de
un administrador de pruebas y un líder de pruebas. Para aclarar, se
supone que un líder de pruebas debe tener una rica experiencia
técnica que incluye programación, manejo de tecnologías de bases
de datos y varios sistemas operativos, mientras que puede no serlo.
tan fuerte como Software Test Manager con respecto a la gestión y
coordinación de proyectos de prueba. Las responsabilidades del jefe
de pruebas son las siguientes:
1 Dado que el jefe de pruebas representa al equipo, es responsable
de todas las reuniones interdepartamentales.
2 Interacción con los clientes siempre que
requerido.
3 Un administrador de pruebas es responsable de contratar personal
de pruebas de software. Tiene que supervisar todo
actividades de prueba realizadas por el equipo e identificar a
los miembros del equipo que requieren más capacitación.
4 Programe actividades de prueba, cree un presupuesto para las
pruebas y prepare estimaciones del esfuerzo de prueba.
5 Selección de las herramientas de prueba adecuadas después de
interactuar con los proveedores. Integración de las actividades
de testing y desarrollo.
6 Llevar a cabo una mejora continua del proceso de prueba con la
ayuda de métricas.
7 Verificar la calidad de los requisitos, qué tan bien están definidos.
8 Rastree los procedimientos de prueba con la ayuda de la matriz
de trazabilidad de prueba.
Rol del automatizador de pruebas de
software El automatizador de pruebas de software o un ingeniero de
pruebas automatizado debe tener una muy buena comprensión de lo
que necesita probar: diseños de GUI, pruebas de carga o estrés. Debe
ser competente en la automatización de pruebas de software y debe
poder diseñar conjuntos de pruebas en consecuencia. Un automatizador
de pruebas de software debe sentirse cómodo usando varios tipos de
herramientas de automatización y debe ser capaz de actualizar sus
habilidades con las tendencias cambiantes. También debe tener
habilidades de programación para poder escribir scripts de prueba sin
ningún problema. los
33
Machine Translated by Google
Las responsabilidades de un probador en esta posición son las
siguientes:
1 Debe ser capaz de comprender los requisitos y diseñar
procedimientos de prueba y casos de prueba para pruebas
de software automatizadas.
2 Diseñe scripts de prueba automatizados que sean reutilizables.
3 Asegurarse de que todas las actividades relacionadas con las
pruebas automatizadas se lleven a cabo de acuerdo con los
estándares definidos por la empresa.
Interacciones entre el equipo de prueba de software y los equipos
comerciales Si un cliente tiene algún problema relacionado con las
actividades de prueba y los asuntos operativos del proyecto, entonces
es el gerente de prueba de software quien es responsable de
comunicar los detalles al cliente sobre cómo se gestionan las cosas.
El gerente de pruebas de software no solo responde las consultas de
los clientes, sino que también se asegura de que el proyecto se
complete a tiempo según los requisitos del cliente.
Interacciones entre el equipo de prueba de software y los equipos
de desarrollo Para producir buenas aplicaciones de software, es
importante que los equipos de prueba y desarrollo de software
trabajen juntos con un buen entendimiento. Para esto, es importante
que los evaluadores y los desarrolladores se sientan cómodos con el
rol del otro y entiendan bien que tienen un objetivo común y que es
prudente escucharse mutuamente. Una buena habilidad de
comunicación es muy importante tanto para los evaluadores como
para los desarrolladores.
Antes de comenzar con el trabajo de prueba, es importante discutir
las pautas y expectativas básicas para que no haya confusión en
etapas posteriores. La crítica debe tomarse en un sentido positivo.
Es importante comprender que los desarrolladores y evaluadores
tienen el objetivo común de producir software de alta calidad. Un
probador no está descubriendo errores para mostrar a alguien, la idea
es aprender de los errores y evitar repetirlos en el futuro. Una cultura
de crítica constructiva puede ser de gran ayuda.
Interacciones entre el equipo de prueba de software y
Equipos de gestión de versiones
Los equipos de administración de versiones son responsables de
mover el software desde el desarrollo hasta el
34
Machine Translated by Google

producción. Este equipo es responsable de planificar los gerente del proyecto y brindar el apoyo necesario en la
lanzamientos de hardware, software y pruebas. También es planificación y programación del proyecto para que el proyecto
responsable del desarrollo de los procedimientos de desarrollo pueda completarse con éxito a tiempo dentro de los límites
de software y de la coordinación de las interacciones y la del presupuesto financiero especificado.
capacitación de los lanzamientos. Las pruebas de software
se consideran un aspecto muy importante del ciclo de vida de
la ingeniería de software, pero no se superan con el desarrollo.
Las pruebas y la verificación son una parte muy importante
del ejercicio de gestión de versiones.

Interacciones entre el administrador de pruebas de

software y el administrador de proyectos de software El
trabajo de un administrador de pruebas de software no es
fácil. Tiene que reclutar un equipo de pruebas y asumir la
responsabilidad de capacitarlos. Un administrador de software
debe realizar un análisis continuo de varios procesos de
prueba y asegurarse de que el equipo de prueba lleve a cabo
todos los procesos correctamente. Este trabajo es de gran
responsabilidad ya que el gerente de pruebas de software es
quien selecciona, introduce e implementa varias herramientas
para las pruebas. Un administrador de pruebas de software
es responsable de finalizar las plantillas para los documentos
de prueba, los informes de prueba y otros procedimientos.

Dado que un gerente de probadores de software tiene que

lidiar con todos los detalles de varias actividades de prueba,
es muy importante para él estar en contacto constante con el

35
Machine Translated by Google
Métodos de prueba de software
Hemos discutido las técnicas de prueba de caja negra y caja
blanca en la sección 3. Aquí echamos un vistazo a algunas
metodologías de prueba más: • Prueba de caja gris • Prueba
incremental • Prueba de subprocesos
Pruebas de caja
gris Cuando las metodologías de prueba de caja negra y las
metodologías de prueba de caja blanca se utilizan en
combinación para las pruebas de software, se denomina
prueba de caja gris o caja gris. Esta forma de prueba analizará
los aspectos lógicos y funcionales del software. En esta forma
de prueba, el probador tiene poco y no un conocimiento
profundo sobre lo que se supone que debe hacer el código.
Idealmente, el evaluador debe conocer las estructuras de
datos y los algoritmos internos.
La prueba de caja gris se lleva a cabo cuando es necesario
probar ambos lados del software (funcional e interno a la vez).
El probador debe poder escribir casos de prueba que puedan
probar el software a fondo con la ayuda de datos que también
pueden verificar toda la lógica interna posible.
La prueba de caja gris es una forma muy inteligente de prueba
en la que se espera que el probador conozca la funcionalidad,
la arquitectura del software, cómo fluirían los datos y cómo se
manejarían las excepciones.
Para proyectos de gran tamaño, siempre es mejor incorporar
pruebas de automatización para verificar la funcionalidad y la
interfaz de usuario de la aplicación, ya que esto ahorraría
mucho tiempo y el probador no se sentirá demasiado estresado.
Pruebas incrementales
Las pruebas incrementales entran en escena una vez que el
evaluador ha completado las pruebas unitarias. Esta forma de
prueba se utiliza en la integración de pruebas donde es
necesario verificar cómo varios módulos independientes
interactúan entre sí. En esta forma de prueba, se pide a los
desarrolladores que integren los módulos sistemáticamente
utilizando stubs o drivers. Esta forma de metodología de
prueba de integración se conoce como prueba incremental.
Las pruebas incrementales se pueden clasificar en tres tipos:
1 Integración de arriba hacia abajo: En este caso la
integración de los módulos se realiza de arriba hacia
abajo. Todos aquellos módulos que no están disponibles
se sustituyen por talones.
2 Integración bottom up: En este caso la integración de los
módulos se realiza desde
36
Machine Translated by Google
abajo hacia arriba. Todos los módulos que no están
disponibles se reemplazan por controladores.
3 Incremental funcional: esta forma de prueba se lleva a cabo
según los documentos de especificación funcional. La
integración de los módulos y su prueba se lleva a cabo
según la especificación funcional definida.
La principal ventaja de las pruebas incrementales es que pueden
ayudar a descubrir defectos muy pronto. La desventaja es que el
desarrollo de stubs y drivers puede llevar tiempo.
Prueba de
subprocesos La metodología de prueba de subprocesos se utiliza
para probar aplicaciones basadas en la arquitectura del servidor
del cliente. Un hilo es la unidad de trabajo más pequeña que
puede llevar a cabo el sistema. Durante las etapas iniciales de
integración de un sistema, es muy importante saber si el sistema
podrá llevar a cabo las tareas funcionales requeridas según el
requisito. Es muy importante verificar si el software podrá realizar
todas las transacciones según el requisito. La forma ideal de
realizar pruebas de subprocesos es integrar los subprocesos de
forma incremental, primero a nivel de subsistema y luego a nivel
de sistema y luego probados.
37
Machine Translated by Google

Niveles de prueba de software

Las pruebas de software tienen varios niveles. Sin embargo,

en una escala más amplia, las pruebas de software se pueden
clasificar en (1) Pruebas funcionales y (2) Pruebas no
funcionales. Estos temas serán discutidos en detalle.

Descripción general de los niveles de prueba de software

Aquí entenderemos varios niveles de pruebas, a saber: •
Pruebas unitarias • Pruebas de integración • Pruebas del
sistema • Pruebas de aceptación

Descripción general de los niveles de prueba de software

Pruebas
Hay varios beneficios de las pruebas unitarias. En primer
unitarias La parte independiente y comprobable más pequeña
lugar, obtiene la confianza para continuar con las pruebas de
del código fuente se denomina unidad. Es el primer paso en
integración solo cuando está seguro de que todas las unidades
el entorno de prueba de software y generalmente lo llevan a
funcionan correctamente. Cuando comienza las pruebas
cabo los desarrolladores o sus compañeros de equipo.
unitarias en paralelo con el desarrollo, puede parecer un
Esta forma de prueba rara vez la realizan los probadores de
proceso lento, ya que se descubren muchos defectos durante
software. Para realizar la prueba de integración, es importante
esta etapa y se realizan varios cambios en el código.
completar primero la prueba unitaria para todas las unidades.
Sin embargo, con el tiempo, el código se refina y la cantidad
Para realizar pruebas unitarias, es importante tener un plan
de defectos comienza a reducirse. Por lo tanto, la base del
de pruebas unitarias y un plan de pruebas unitarias bien definidos.
casos. software es sólida y en las etapas posteriores el

38
Machine Translated by Google
el desarrollo de software se lleva a cabo a un ritmo mucho más
rápido, lo que ahorra mucho tiempo.
Examen de la unidad
Si las pruebas unitarias se llevan a cabo correctamente,
también resultaría en un gran ahorro de costos, ya que el costo
de corregir un defecto en las etapas finales del desarrollo del
software es mucho más alto que repararlo en las etapas iniciales.
Las pruebas unitarias se llevan a cabo en el componente
comprobable más pequeño del proyecto, por lo que la cantidad
de casos de prueba y datos de prueba es menor, y no siempre
es posible verificar todos los escenarios para el flujo funcional
y de información de la aplicación de software. Por lo tanto, hay
muchos casos de prueba que se pueden probar solo después de la
unidad se ha fusionado con otras unidades para formar un
componente más grande.
Pruebas de integración
Una vez finalizada la fase de pruebas unitarias, es el momento
de pasar a las pruebas de integración. Durante las pruebas de
integración, el probador verifica cómo una o más unidades
interactúan entre sí y producen resultados para varios
escenarios. Esta forma de prueba la lleva a cabo un ingeniero
de pruebas de software.
En esta forma de prueba, se descubren muchos defectos
relacionados con los niveles funcionales, de requisitos y de
rendimiento. Las pruebas unitarias confirman que varias
unidades pueden funcionar según el requisito individualmente,
pero las pruebas de integración confirman si estas unidades
independientes pueden funcionar según las expectativas
cuando se integran juntas. Las pruebas de integración se
pueden clasificar en términos generales en: 1 Big bang 2
Enfoque de arriba hacia abajo y 3 Enfoque de abajo hacia
arriba
Como sugiere el nombre, todos los módulos se combinan para
formar un sistema completo y luego se prueban en busca de
errores.
39
Machine Translated by Google
Pruebas de integración
De arriba hacia abajo es un enfoque sistemático en el que los módulos de
nivel superior se prueban primero y luego, uno por uno, se agregan y
prueban los submódulos. El enfoque de abajo hacia arriba es justo lo
contrario de arriba hacia abajo. En este caso, primero se prueban los
módulos más bajos y, paso a paso, se agregan y prueban los módulos de
nivel superior. En general, el enfoque de abajo hacia arriba se sigue primero
en las pruebas de software, seguido de las pruebas de arriba hacia abajo.
Pruebas de integración de arriba hacia abajo y de abajo hacia arriba
En el enfoque de arriba hacia abajo, los apéndices de prueba de integración
se pueden usar como identificadores en el caso de módulos o subprogramas
que no están disponibles o no están listos. Estos son módulos ficticios
utilizados en niveles bajos. De manera similar, en el caso de un enfoque de
abajo hacia arriba si un programa principal no está disponible, el programa
de llamada denominado controlador se puede usar como reemplazo para
completar el proceso de prueba.
Pruebas del sistema
Una vez que la fase de pruebas de integración se completa con éxito, es
hora de pasar a las pruebas del sistema, donde el sistema como un todo
con todos los componentes bien integrados está listo para realizar más
pruebas. Aquí es donde no solo se prueba el rendimiento del software, sino
también el cumplimiento de los estándares de calidad. Dado que el sistema
se prueba como un todo para ver si cumple con las especificaciones
técnicas y funcionales y los estándares de calidad definidos por la
organización, es importante que esta forma de prueba la lleve a cabo un
equipo de pruebas altamente calificado. Para esta forma de prueba es muy
importante crear un escenario similar al escenario en tiempo real donde se
implementará el sistema.
40
Machine Translated by Google

el software se prueba para la exactitud. La prueba de aceptación

analiza el sistema desde varios ángulos: desde el aspecto cosmético
hasta el funcionamiento interno. Esta forma de prueba es muy
importante porque existen requisitos tanto legales como
contractuales asociados con el software para que sea aceptado por
el cliente.

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

Pruebas del sistema
Las pruebas del sistema son puramente pruebas de caja negra. El
sistema se comprueba según las especificaciones de requisitos. La
prueba se lleva a cabo desde el punto de vista del usuario. Este
tipo de prueba se lleva a cabo para comprobar el comportamiento
de la aplicación, el diseño del software y las expectativas del usuario
final. Las pruebas del sistema validan y verifican tanto la arquitectura
de la aplicación como los requisitos comerciales del cliente.
Pruebas de aceptación
Una vez que el sistema se ha probado exhaustivamente a través
de las pruebas unitarias, de integración y del sistema, es hora de
que el equipo de control de calidad venga y eche un vistazo al
sistema y pruebe su calidad con la ayuda de escenarios de prueba
y casos de prueba predefinidos. los
1 Prueba de aceptación del usuario: esta forma de prueba la
lleva a cabo el usuario real antes de que se acepte el
software. Puede realizarse en el sitio del usuario o en la
organización de software donde se desarrolló el software.
2 Pruebas de aceptación de operación: esta forma de prueba se
realiza para garantizar que todos los procesos y
procedimientos estén en su lugar para que el sistema se
pueda usar y mantener fácilmente.
3 Pruebas de aceptación de contratos y regulaciones: se llevan
a cabo para garantizar que el software cumple con todos
los estándares gubernamentales, legales y de seguridad
necesarios.
4 Prueba alfa: se lleva a cabo para garantizar que el producto
sea de buena calidad y también para preparar el sistema
para la prueba beta. Esta forma de prueba se realiza hacia
el final del desarrollo del software, cuando el sistema puede

41
Machine Translated by Google

ser probado como un todo. Este puede ser un

proceso largo, ya que los evaluadores analizan la
calidad y los aspectos de ingeniería del software
desarrollado. Esta forma de prueba la llevan a
cabo ingenieros de prueba y otros miembros del
equipo, y el producto se prueba desde el punto de
vista del cliente.
5 Prueba beta: una vez que finaliza la prueba alfa,
sigue la prueba beta para mejorar la calidad del
producto y ver que el producto cumpla con los
requisitos del cliente. Esta forma de prueba se Test de aceptación
realiza un par de días o semanas antes del
lanzamiento del producto. Las pruebas beta
pueden demorar algunos días, pero es posible que
no tomen tanto tiempo como las pruebas alfa, ya
que las posibilidades de detección de defectos son
bastante bajas durante este tiempo. Se lleva a
cabo en el escenario del mundo real con las
personas que realmente van a utilizar el producto.

42
Machine Translated by Google
Tipos de pruebas de software
Tipos de pruebas de software
Pruebas funcionales
Las pruebas funcionales son una especie de pruebas de caja
negra donde los casos de prueba se preparan teniendo en
cuenta las especificaciones. Esta forma de prueba se realiza
para verificar si el sistema cumple con los requisitos del cliente.
Básicamente, en el caso de las pruebas funcionales, las
siguientes comprobaciones son importantes: 1. El evaluador
debe tener muy claro la funcionalidad que se supone que debe
realizar la aplicación.
2 Para probar la aplicación, es muy importante tener el conjunto
correcto de datos (entradas válidas e inválidas)
3 La salida de la aplicación para los datos de prueba
proporcionados debe verificarse según la especificación
funcional definida.
4 Los casos de prueba deben cubrir todas las posibles
escenarios.
5 El resultado real de una entrada dada debe registrarse y
compararse con la salida esperada.
Los tipos de pruebas funcionales incluyen:
1 unidad de prueba
2 Pruebas de integración
3 Pruebas del sistema
4 Pruebas de regresión
5 Pruebas de aceptación
Pruebas no funcionales En
un sistema de software hay muchos requisitos, como el
rendimiento, la seguridad, la interfaz de usuario, etc., que son
de naturaleza no funcional; sin embargo, es muy importante
probar estos atributos. Las pruebas de software realizadas para
probar los atributos no funcionales de un sistema se denominan
pruebas no funcionales. Los tipos de metodologías de pruebas
no funcionales son las siguientes: 1 Pruebas de rendimiento 2
Pruebas de usabilidad 3 Pruebas de seguridad
43
Machine Translated by Google
4 Pruebas de portabilidad
Pruebas de
usabilidad Las pruebas de usabilidad son un proceso en el
que los probadores prueban el producto para verificar qué tan
fácil sería para el usuario usar la interfaz de usuario o, en
otras palabras, se prueba la facilidad de uso del software. Es
una forma de prueba de caja negra. El software se prueba
para tres cosas: (1) ¿Qué tan conveniente será el software
para el usuario? (2) ¿Podrá el usuario usarlo? (3) ¿Podrá el
usuario aprenderlo?
La usabilidad tiene los siguientes aspectos asociados:
• Con qué facilidad los usuarios pueden adaptarse al sistema
la primera vez que intentan utilizar el sistema. • ¿Qué
tan eficiente es el sistema para el usuario? La eficiencia del
sistema depende en gran medida de la velocidad con
la que los usuarios pueden realizar sus tareas. • Qué
tan fácil o difícil es para los usuarios trabajar en un
sistema cuando llegan a usarlo después de un largo período
de tiempo. • ¿Los usuarios encuentran errores? En
caso afirmativo, ¿con qué facilidad pueden salir del
problema?
• ¿Es capaz de proporcionar satisfacción a su
usuarios?
Las pruebas de usabilidad aseguran al usuario final que el
software es de buena calidad y fácil de usar. Este tipo de
prueba es muy esencial para satisfacer a los clientes y debe
planificarse bien. Si se planifica adecuadamente, esta actividad
puede ser muy beneficiosa y económica. Dado que el software
se utiliza de forma aleatoria en este tipo de pruebas, muchas
veces descubre defectos que han escapado a los
procedimientos normales de prueba.
Pruebas de interfaz gráfica de usuario
La forma de prueba que se lleva a cabo para comprobar si la
interfaz gráfica de usuario de una aplicación funciona
correctamente se denomina prueba de GUI o interfaz gráfica
de usuario. La GUI no solo se comprueba para comprobar su
funcionalidad adecuada, sino también su cumplimiento de los
estándares de calidad definidos. Las siguientes son algunas
de las cosas más importantes que deben verificarse durante
las pruebas de GUI:
• Diseño •
Colores •
Fuentes •
Tamaño de
fuente •
Etiquetas • Funciones del
cuadro de prueba • Cómo se formatea el texto
44
Machine Translated by Google
• Subtítulos •
Botones
• Liza
• Iconos •
Enlaces •
Contenido •
Teclas de acceso
directo • Reloj de arena mientras el sistema procesa datos
Esta forma de prueba puede ser manual o automática según sea
conveniente para el probador. Las pruebas de GUI a veces las
realizan organizaciones de terceros y no el equipo de desarrollo o
pruebas de la empresa.
Pruebas de interfaz de usuario no gráfica La
interfaz gráfica de usuario es la apariencia de una aplicación. La
prueba de cualquier cosa que no sea la apariencia de una aplicación,
como las interfaces de líneas de comando, los procesos por lotes y
varios eventos que activan ciertos casos de uso en una aplicación
de software, se encuentran bajo pruebas de interfaz de usuario no
gráfica.
Pruebas de portabilidad
Las pruebas de portabilidad se llevan a cabo para probar cómo el
cambio de entorno cambia el rendimiento del software. Por ejemplo,
cómo funciona el software.
en diferentes sistemas operativos o si se trata de una aplicación
basada en la web, se verificará su rendimiento en diferentes
navegadores web. Esta forma 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 las pruebas del sistema.
Aquí, el software puede instalarse en más de un entorno o sus
ejecutables pueden crearse y ejecutarse en diferentes plataformas.
Para llevar a cabo pruebas de portabilidad sin ningún problema, es
importante tener en cuenta todos los requisitos de portabilidad al
diseñar y desarrollar el software. Este tipo de prueba se realiza
después de la prueba de integración. Es importante contar con el
entorno de prueba adecuado para llevar a cabo las pruebas de
portabilidad.
Pruebas de seguridad, autenticación y autorización Una
aplicación de software se prueba para detectar cualquier tipo de
falla de seguridad en las pruebas de seguridad. La autenticación y
la autorización se consideran dos aspectos muy importantes de las
pruebas de software. Es crucial llevar a cabo esta forma de prueba
para garantizar que el software sea seguro y capaz de almacenar
información confidencial del cliente cuando sea necesario.
45
Machine Translated by Google
La autenticación es un proceso en el que a la persona que intenta
acceder al software se le solicita un nombre de usuario y una
contraseña. Una combinación incorrecta de los dos parámetros indica
que la persona no es lo que dice ser y no se le permite ir más allá.
Esta es una verificación de autenticación que garantiza que se
verifiquen las credenciales de inicio de sesión de un uso de aplicación
de software autorizado.
La autorización, por otro lado, tiene que ver con los privilegios para
usar ciertas funciones restringidas de una aplicación de software. El
hecho de que haya borrado el proceso de autenticación no significa
que haya sido autorizado para acceder a todos los datos, funciones y
casos de uso de la aplicación de software. Por ejemplo, en el caso de
los sitios de redes sociales, una vez que ingresa el nombre de usuario
y la contraseña correctos, solo puede acceder a los detalles de su
cuenta y a ninguna otra cuenta además de esa.
Además de la autenticación y la autorización, las pruebas de seguridad
también se ocupan de la confidencialidad, la integridad, la disponibilidad,
el no repudio, la seguridad de los datos del software, las fallas de
inserción de SQL, los ataques de secuencias de comandos entre sitios
y otras preocupaciones relacionadas con la seguridad, que es una
experiencia en un tema completamente diferente en sí misma.
Pruebas de integridad de datos y bases de datos
En las pruebas de integridad de datos, debemos verificar si los datos
almacenados en la base de datos son precisos y producen resultados
según las expectativas. Algunas comprobaciones son muy importantes
para las pruebas de integridad de los datos, como si es posible
recuperar información en blanco de la base de datos o no, si los datos
se validan correctamente antes de guardarlos en la base de datos, si
se pueden actualizar los datos almacenados en la base de datos, si
puede ejecutar pruebas para todo tipo de archivos de datos, etc. En
otras palabras, las pruebas de integridad de datos se llevan a cabo
para garantizar que los datos sean precisos y consistentes durante
todo su ciclo de vida.
La integridad de la base de datos, por otro lado, se ocupa de probar
todos los métodos y procesos necesarios que son importantes para
acceder a la base de datos y administrar los datos que contiene.
También se trata de cómo se procesan todas las funciones y datos de
los métodos de acceso.
Los datos no deben corromperse y no deben eliminarse, actualizarse o
crearse sin saberlo, y debe haber casos de prueba para realizar estas
validaciones.
Pruebas de tolerancia a fallas y conmutación por
error Las pruebas de tolerancia a fallas se llevan a cabo para verificar
cómo reaccionaría una aplicación si ocurre alguna falla en un escenario
en tiempo real. En este tipo de pruebas se consideran varios escenarios
como error de conexión
46
Machine Translated by Google
con la red, problema de conexión con el servidor de aplicaciones,
no poder conectarse a una base de datos, etc.
La prueba de conmutación por error, por otro lado, se lleva a
cabo para probar la capacidad del software para recuperarse de
problemas graves inesperados, como una falla de hardware o un
bloqueo. Esta forma de prueba explica qué tan bien se restaurará
el sistema a su estado original en caso de cualquier tipo de falla.
Pruebas de configuración e implementación
Las pruebas de configuración se llevan a cabo para verificar
cómo funciona un sistema para varios tipos de configuraciones
de sistema. Hay varias razones para llevar a cabo pruebas de
configuración. Puede ayudarlo a determinar el tiempo de reacción
del sistema en el entorno de prueba y la configuración óptima
requerida para que el sistema funcione según lo esperado. Las
pruebas de configuración también juegan un papel muy importante
en escenarios donde existe la necesidad de migrar un software
de una plataforma a otra. Ayuda a verificar si el sistema es
compatible con el nuevo entorno según lo exigen las
especificaciones de hardware.
Una vez que el sistema se ha implementado, es importante
realizar ciertas comprobaciones para asegurarse de que va a funcionar. se enfocan en probar problemas de rendimiento. Está
trabaja correctamente. Esto incluye verificar el sistema en busca
de problemas de rendimiento, como baja velocidad o posibilidades
de fallas, cómo funciona la aplicación en un escenario en tiempo
real, si el software se emplea correctamente en la carpeta
correcta, etc. Todo esto es parte de las pruebas de implementación.
Pruebas de regresión
Una vez que se detecta un defecto en el sistema, se envía
inmediatamente para su reparación. Sin embargo, una vez que
se corrige el defecto, es importante realizar pruebas intensas
para verificar que los cambios realizados en el código no hayan
afectado a ninguna otra área del sistema.
Las pruebas de regresión se llevan a cabo para garantizar que la
corrección de errores no haya causado ninguna violación de la
lógica comercial o de la funcionalidad. Las pruebas de regresión
ayudan a minimizar las brechas en el proceso de prueba.
Garantiza que la aplicación no tenga defectos antes de enviarla a
la siguiente fase de prueba.
Pruebas de rendimiento
Temas como el retraso de la red, la representación de datos, el
procesamiento de transacciones de bases de datos y el equilibrio
de carga entre servidores generalmente se descubren durante
las pruebas de rendimiento. En otras palabras, en lugar de
encontrar defectos en el software real, las pruebas de rendimiento
47
Machine Translated by Google
importante realizar pruebas de rendimiento en cualquier software
para el que es importante tener estabilidad, escalabilidad y
velocidad, lo que significa un buen tiempo de respuesta y
representación de datos.
Pruebas de carga y benchmarking de rendimiento El
proceso de pruebas de carga también es muy interesante; aquí
se prueba el comportamiento del software bajo carga máxima.
La prueba de carga se lleva a cabo para verificar cómo funciona
o se comporta el software en condiciones de carga máxima. Hay
varias herramientas disponibles para pruebas de carga, como
JMeter, Load Runner, Silk Performer, etc. Estas herramientas se
utilizan para
pruebas de carga automatizadas del software donde se pueden
crear varios usuarios virtuales y luego se ejecuta un script para
verificar cómo se comporta el software cuando varios usuarios
intentan acceder al sistema al mismo tiempo.
Resumen de tipos de pruebas de software
El probador puede controlar la cantidad de usuarios virtuales y
ver cómo se comporta el sistema.
Pruebas de
estrés En las pruebas de estrés, el software se somete
intencionalmente a condiciones anormales y luego se supervisa
su rendimiento. En las pruebas de estrés, el software se prueba
aplicando una carga que está mucho más allá del límite aceptable
y los recursos se retiran para averiguar el punto en el que no
funcionará. Hay muchas formas de crear condiciones anormales
para las pruebas de estrés, la base de datos se puede apagar y
encender, y los puertos de red se pueden cerrar o reiniciar
aleatoriamente. La forma más común de realizar pruebas de
estrés es iniciando procesos que consumirían muchos recursos.
48
Machine Translated by Google
Pruebas manuales de software
Las pruebas manuales son la forma más antigua y completa de
realizar pruebas de software. Aunque muchas organizaciones
ahora han comenzado a incorporar pruebas de automatización
en proyectos de prueba, las pruebas de automatización nunca
pueden reemplazar por completo las pruebas manuales.
El proceso de prueba manual depende en gran medida de las
habilidades y la dedicación del probador.
Pruebas manuales de software
Descripción general de las pruebas
manuales de software Para realizar pruebas manuales, el
probador debe tener absolutamente claros los procesos de prueba.
Se espera mucho del probador. Necesita comprender la
funcionalidad del programa porque toda la actividad de prueba
se puede llevar a cabo de la manera correcta solo si 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 de
forma manual.
El probador tiene que registrar manualmente qué pruebas han
pasado y cuáles han fallado para crear un informe detallado
para el análisis. Las pruebas manuales son de gran ayuda
cuando se incorporan en las etapas iniciales de las pruebas de
software.
Las pruebas manuales se pueden incorporar tanto para
proyectos grandes como pequeños y cuando hay problemas de
presupuesto o la empresa no puede permitirse invertir en
herramientas de pruebas de automatización, las pruebas
manuales demuestran ser de gran ayuda. A veces, las pruebas
manuales todavía se consideran más confiables que las pruebas
de automatización, aunque las pruebas de software
automatizadas requieren más tiempo.
49
Machine Translated by Google

Estrategia de prueba de software manual

La estrategia para la prueba de software se define en el plan de
prueba. El documento del plan de prueba define:

1 El entorno de prueba en el que se probará el software

2 El propósito de realizar pruebas

3 El alcance y el objetivo del equipo de pruebas
4 Cómo las actividades de prueba son horarios
5 El enfoque para llevar a cabo pruebas manuales
6 Hitos
7 Roles y responsabilidades de varios miembros del
equipo de prueba
8 Capacitaciones sobre herramientas y metodología de prueba, si se
requiere alguna,
9 Qué tipo de pruebas deben realizarse
10 Cómo se rastrearían los defectos

50
Machine Translated by Google
Pruebas de software automatizadas
La prueba de automatización es un proceso en el que se utiliza una
herramienta de prueba que también es otra aplicación de software para
probar el sistema. Los scripts de prueba se crean y ejecutan y luego
los resultados de estas pruebas se comparan con los resultados
esperados. Siempre es aconsejable automatizar los procesos de prueba
repetitivos pero esenciales, ya que ahorra mucho tiempo.
Pruebas de software automatizadas
Descripción general de la automatización de
pruebas de software Las pruebas de software automatizadas se llevan
a cabo con la ayuda de herramientas de pruebas de automatización.
La herramienta de prueba de automatización es una aplicación de
software en sí misma con la ayuda de la cual 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 las pruebas manuales. La mayor ventaja de las pruebas
de automatización es que ahorra mucho tiempo y la aplicación de
software se puede probar a fondo en un corto período de tiempo. Las
herramientas de prueba de automatización están disponibles para
realizar pruebas de regresión, carga y estrés. Sin embargo, las pruebas
de automatización no pueden reemplazar completamente las pruebas
manuales. Además de tiempo, las pruebas de automatización ahorran
dinero y esfuerzo y ayudan a mejorar la precisión del software.
Todos los aspectos del software no pueden cubrirse mediante pruebas
de automatización. Sin embargo, las pruebas de automatización son
de gran ayuda para probar los aspectos de la GUI, la conectividad de
la base de datos, etc. Es mejor optar por las pruebas de automatización
cuando se trabaja en proyectos grandes y complejos en los que es
necesario probar ciertas áreas con frecuencia. Las pruebas de
automatización también son buenas para probar aquellas aplicaciones
que eventualmente serán utilizadas por varios usuarios simultáneos.
esta forma de
51
Machine Translated by Google
Las pruebas ayudan a ahorrar mucho tiempo para que el equipo
tenga más tiempo para concentrarse en la calidad del software.
Para realizar pruebas de automatización, debe conocer los
siguientes detalles:
1 Qué secciones del software requieren pruebas de automatización
2 Qué herramientas serán ideales para este propósito 3 El
proceso de escribir scripts de prueba y ejecutarlos 4 Debe poder
identificar errores potenciales y saber cómo crear informes de
resultados.
Es bueno incluir pruebas de automatización para mejorar la calidad
del software, pero las pruebas de automatización no son la única
forma de lograr la calidad y de ninguna manera deben considerarse
un reemplazo de las inspecciones y los procedimientos de recorrido.
Muchas organizaciones aún consideran que las pruebas de
automatización son la última forma de detectar defectos que pueden
haber pasado desapercibidos.
Estrategia de automatización de pruebas de
software No hay duda de que las pruebas de automatización hacen
la vida mucho más fácil, pero tener las herramientas adecuadas no
es suficiente para lograr el éxito en las pruebas de automatización.
Es muy importante desarrollar una estrategia para las pruebas de
automatización que defina claramente qué
secciones del software requieren pruebas, cómo se llevaría a cabo
esta tarea, cómo y dónde se mantendrán los scripts, cómo se
beneficiaría el proyecto de esta actividad y cuánto dinero se
ahorraría en este proceso. Cuanto más específico sea en la
definición de la estrategia; más éxito tendrá en el logro de sus
objetivos de prueba.
Al definir la estrategia, es importante dividir su objetivo en objetivos
más pequeños y verificar si puede lograr lo que necesita con la
ayuda de una herramienta de prueba de automatización. Si el
proyecto es demasiado grande e intenta probar áreas complejas en
el primer intento, entonces hay posibilidades de cometer errores.
Por lo tanto, es aconsejable comenzar con algo pequeño inicialmente
y luego crecer gradualmente.
Las pruebas de automatización se pueden llevar a cabo en pruebas
unitarias, integración y pruebas a nivel de sistema. Siempre es
mejor descubrir los defectos máximos en las primeras etapas del
desarrollo del software, por lo que es mejor planificar las pruebas
de automatización lo antes posible.
Automatización de pruebas de software y su retorno de
Inversión (ROI)
El ROI de la automatización de pruebas de software se calcula para
saber cómo se beneficiaría la empresa al incorporar esta metodología
en sus pruebas.
52
Machine Translated by Google
procesos. Da una idea justa sobre el ahorro de costos, el
alcance de la mejora en la eficiencia y la calidad del software.
ROI = (Ganancia-cantidad invertida) / cantidad invertida
Los métodos más utilizados para el cálculo de
El ROI para las pruebas de automatización son:
• Cálculo sencillo del ROI para saber cómo se beneficiaría la
empresa con el ahorro de costes. Este cálculo es de
gran importancia cuando una empresa quiere saber
cómo se beneficiaría económicamente al incorporar
pruebas automáticas. El costo de inversión incluiría el
monto gastado en la adquisición de la licencia, hardware
y capacitación del personal, desarrollo de scripts,
mantenimiento y análisis de los mismos. • El cálculo del
ROI de eficiencia informa sobre los beneficios en
términos de mayor eficiencia. A diferencia del ROI
simple, este cálculo solo analiza las ganancias de inversión
de tiempo. Cuando una empresa ya tiene las
herramientas de prueba de automatización y las ha
estado usando durante bastante tiempo, no es necesario
que conozca los cálculos de ROI simple porque no va a
hacer ninguna inversión monetaria fresca en este caso.
• El cálculo del ROI de reducción de riesgos indica
reducción del riesgo y alcance de la mejora de la calidad.
Las pruebas de automatización ahorran tiempo y brindan
al equipo más tiempo para realizar análisis y realizar
pruebas ad hoc y exploratorias, lo que conduce a una
cobertura exhaustiva y reduce así las posibilidades de
falla.
Casos de prueba para automatizar
Es difícil y no es aconsejable automatizar todas las pruebas.
Por lo tanto, uno debe determinar claramente qué casos de
prueba deben automatizarse. Primero debe mirar aquellas
secciones del software que requieren pruebas repetidas. Los
casos de prueba que deben ejecutarse repetidamente y
requieren una gran cantidad de datos para su ejecución deben
automatizarse. Además de las pruebas repetitivas, también
debe centrarse en la automatización:
1 Casos de prueba que requieren múltiples conjuntos de
datos para su ejecución y son difíciles de realizar
manualmente.
2 Pruebas de carga y estrés que son difíciles de con
conducto manualmente.
3 Pruebas que se ejecutan para comprobar el rendimiento
del software en múltiples plataformas.
4 Pruebas de interfaz gráfica de usuario.
53
Machine Translated by Google
Casos de prueba para no
automatizar Hay ciertos casos de prueba que no se prefieren
para ser automatizados. Como:
1 Casos de prueba que se ejecutarían una sola vez o con
muy poca frecuencia.
2 Las pruebas ad hoc o exploratorias no se pueden realizar
con la ayuda de pruebas de automatización.
3 Casos de prueba que solo requieren ejecución manual o
una opinión humana.
¿Cómo queremos Automat?
La automatización de un caso de prueba comienza con la
definición de lo que desea probar. Elija siempre aquellos casos
de prueba que sean independientes y estables. Siempre es
mejor ejecutar casos de prueba independientes más pequeños
en lugar de unos pocos grandes y complejos. Los scripts
grandes son difíciles de mantener y pueden ser difíciles de
ejecutar si se han realizado cambios importantes en el software.
Si un script de prueba requiere un cambio, siempre es más fácil
realizar cambios en un script más corto que en uno más largo.
una.
Antes de automatizar un caso de prueba, es mejor ejecutar el
caso de prueba manualmente. Dado que los casos de prueba
automatizados son aquellos que uno necesita usar para pruebas
repetitivas, por lo tanto, antes de diseñar un caso de prueba de
este tipo, es mejor ejecutarlo manualmente y anotar todos los
pasos que le gustaría grabar o poner en su guión de prueba.
Esto le ayudará a diseñar todas las condiciones requeridas para
las pruebas de una función.
Asegúrese de haberse ocupado de todas las validaciones en
sus scripts de prueba. Si planea probar las transacciones de la
base de datos, debe asegurarse de que la base de datos tenga
los datos necesarios para la prueba.
Antes de ejecutar el caso de prueba, es importante comprender
cómo se ha diseñado la herramienta de software automatizada.
Esto es importante porque una vez que comience la prueba, no
querrá que lo interrumpan problemas desconocidos.
Herramientas de automatización de
pruebas de software Las herramientas de automatización
tienen un impacto muy positivo en la eficiencia y productividad
del software. Es importante utilizar herramientas de
automatización de pruebas de software para simplificar las
pruebas. Ciertos procesos de prueba manuales pueden llevar
mucho tiempo. Con la ayuda de las herramientas de
automatización, puede lograr más en menos tiempo. Sin
embargo, nunca dependa completamente de las herramientas
de automatización. Debe definir claramente qué debe probarse
manualmente y dónde es necesario implementar herramientas
de prueba de automatización. La mayoría de las herramientas
de prueba de automatización con buena reputación vienen con
sus precios, pero vale la pena implementarlas en proyectos, ya que son de
54
Machine Translated by Google

Ingeniería de software en cascada Las secuencias de fases en el modelo de cascada son las
siguientes:

Ciclo vital 1 Requerimiento y recolección: Se captura el requerimiento

del cliente y se realiza toda la documentación necesaria.

El modelo de cascada es un modelo lineal y secuencial definido

2 Diseño del Sistema: en base al requerimiento recolectado
para el ciclo de vida de la ingeniería de software. Es un modelo
se diseña el sistema; esto ayuda a definir la creación de
clásico y muy popular que define claramente varias fases y los
la arquitectura del sistema y también ayuda a definir los
objetivos que cada fase tiene que alcanzar. Se llama modelo de
requisitos de hardware y software del sistema.
cascada porque, al igual que una cascada, una vez que el curso
del ciclo de vida ha comenzado, no hay vuelta atrás. El agua
3 Implementación: Basado en el diseño del sistema, comienza
fluirá de arriba hacia abajo y no invertirá su curso. De manera
la codificación. El programa se divide en pequeñas
similar, en este ciclo de vida, el curso del desarrollo de software
unidades independientes que luego se integran para
no se puede revertir.
formar el sistema completo. Una vez que las unidades
están listas, se prueban según las especificaciones
En el modelo de cascada, el enfoque es muy estricto y está bien
definidas.
definido, pero no hay muchas posibilidades de revisión. La
4 Pruebas de integración: una vez que las unidades han sido
prueba es una fase y no va de la mano con el desarrollo. Por lo
probadas, se integran en un sistema y luego todo el
tanto, no es posible detectar defectos en las primeras etapas de
sistema se prueba de una sola vez para detectar defectos.
desarrollo.

5 Implementación: el sistema está listo para la implementación

una vez que se hayan solucionado los defectos
descubiertos durante las pruebas de integración. Después
de la prueba del sistema integrado, se corrigen los
defectos y se vuelve a realizar la prueba para verificar
que se hayan solucionado todos los defectos. el sistema es

Ciclo de vida de la ingeniería de software en cascada

55
Machine Translated by Google

ahora está listo para su lanzamiento al mercado y se puede
implementar en el entorno del cliente.
6 Mantenimiento: si surge algún defecto o problema después de
que el software se haya entregado al cliente, se lanzan
parches o una nueva versión del software para solucionar
el problema.
El cliente, el equipo de gestión y el equipo de soporte técnico de la
empresa discuten los requisitos del software con todo detalle.
Estos requisitos se analizan, discuten varias veces y luego se
documentan hasta que son claros y completos.

Todas las fases mencionadas anteriormente están en cascada

entre sí y una fase puede comenzar solo después de que la fase
anterior se haya cerrado con éxito.

El modelo de cascada se puede utilizar en situaciones en las que el

los requisitos están bien definidos y claros, el producto es estable
y hay suficientes recursos disponibles para cada fase. El modelo
de cascada debe implementarse prácticamente solo en proyectos
pequeños y fácilmente manejables. No debe usarse en proyectos
en los que los requisitos sean de riesgo moderado a alto.
Especificación de requisitos de usuario

Especificación y análisis de requisitos El desarrollo

de una aplicación de software depende solo de una cosa: qué tan
bien se capturan y documentan los requisitos. Este proceso de
identificar y luego documentar los requisitos para el desarrollo de
software se denomina especificación y análisis de requisitos.
Los requisitos se pueden documentar en el formato definido por la
empresa, como una descripción en documentos de Word, diagramas
de flujo, dibujos, etc. El resultado de todo el ejercicio es un
documento detallado que describe lo que quiere el cliente. Esto es
necesario para que uno sea capaz de comprender correctamente
los requisitos del cliente. En la actualidad decimos que defecto es
todo aquello que no se ajusta al requisito de

56
Machine Translated by Google

•
el cliente. Si capturamos el requisito incorrectamente, Ayuda a programar actividades y estimar costos.
comenzaremos el proyecto con el pie izquierdo.
• SRS sirve como base para la validación y
verificación.
Especificación de requisitos del
usuario Este documento define lo que un usuario quiere y
cuáles son sus expectativas del software. Este documento
ofrece una imagen clara de las necesidades comerciales de
un cliente. Este documento está escrito por los usuarios finales.
Estos requisitos se prueban en las pruebas de aceptación del
usuario. Este documento no es de carácter técnico. Habla de
la necesidad comercial del usuario.
y forma la base para planificar los próximos pasos para
capturar los requisitos y el diseño del sistema.

Especificación de requisitos de software La

especificación de requisitos de software define cómo desea el
usuario que funcione el software. El propósito de este
Especificación de requisitos de software
documento es el siguiente:
• El cliente y el proveedor están de acuerdo con este
Diseño de software
requisito. Describe la funcionalidad del software con
El Diseño de Software puede ser de los siguientes
todo detalle. • El diseño del software se prepara sobre
tipos: • Diseño de Software de Alto Nivel • Diseño
la base de
de Nivel de Software Detallado
documento SRS.
• El documento SRS claro simplifica el desarrollo
ment y proceso de prueba.

57
Machine Translated by Google

información detallada sobre el sistema y no se puede crear hasta que

el HLD esté listo.

Procesos de diseño de software

Los procesos de diseño de software se pueden clasificar
como: • Enfoque de diseño de arriba hacia abajo • Enfoque
de diseño de abajo hacia arriba

Diseño de software
Enfoque de diseño de arriba hacia
abajo El enfoque de arriba hacia abajo es un enfoque muy sistemático
Diseño de software de alto nivel El
en el que primero se diseña el esquema del sistema sin definir los
diseño de software de alto nivel proporciona una imagen clara del
detalles de ningún subsistema. Una vez que el esquema del sistema
diseño de la base de datos y la arquitectura funcional del sistema. El
está listo, es hora de avanzar paso a paso a cada subsistema. Cada
diseño de software de alto nivel sirve como guía para el equipo de
subsistema se define con todo detalle hasta que la especificación llega
desarrollo.
a los elementos básicos.
Siempre que haya alguna duda con respecto al flujo de diseño, los
desarrolladores se refieren al documento de diseño de alto nivel (HLD).
Para crear este documento, es importante que el documento de
Enfoque de diseño de abajo hacia
especificación de requisitos de software (SRS) sea absolutamente claro.
arriba El enfoque de diseño de abajo hacia arriba es exactamente lo
contrario del enfoque de arriba hacia abajo. En este caso, el primer
paso consiste en definir los elementos básicos con todo detalle y luego
vincular estos elementos para formar varios subsistemas que se
Diseño de nivel de software detallado El
vinculan aún más hasta el momento en que se forma el sistema
diseño de nivel de software detallado o diseño de bajo nivel (LLD)
completo.
implica dividir el diseño de alto nivel en secciones más pequeñas y
Este enfoque se puede comparar con plantar un árbol donde al principio
escribir la lógica que serviría como especificación del programa. LLD
todo lo que tenemos en la mano es una semilla, pero a medida que
proporciona
comenzamos a trabajar en ella, se forma un árbol.

58
Machine Translated by Google
Vida ágil de ingeniería de software
Ciclo
La metodología ágil cree que cada proyecto debe ser
manejado de una manera diferente.
Los requisitos de un proyecto varían de un cliente a otro y,
por lo tanto, no es aconsejable ceñirse a un solo método de
desarrollo de software. En el ciclo de vida de la ingeniería de
software, todos los proyectos se dividen en pequeños marcos
de tiempo, y cada marco de tiempo se enfoca en la entrega
de ciertas secciones para su lanzamiento.
Ciclo de vida ágil de la ingeniería de software
Este proceso combina un enfoque iterativo e incremental que
ayuda en el rápido desarrollo del proyecto. El proyecto se
divide en compilaciones incrementales y luego cada
compilación se somete a iteraciones que pueden durar de 2
a 3 semanas. En cada iteración, los equipos multifuncionales
trabajan juntos en varios aspectos del proyecto, desde el
análisis de requisitos hasta las pruebas de aceptación. Al
final de cada iteración, el resultado se muestra al cliente.
Descripción general del ciclo de vida de la ingeniería de
software ágil El ciclo de vida de la ingeniería de software ágil
es diferente de otros enfoques de desarrollo de software
porque es de naturaleza adaptativa en comparación con
otros que son predictivos. La planificación predictiva requiere
una planificación en profundidad que consume mucho tiempo
y esfuerzo e incluso un pequeño cambio en el requisito
después de que el desarrollo ha comenzado afecta el proceso
de desarrollo. Los métodos predictivos dependen
completamente del análisis de requisitos y la planificación al
comienzo del proyecto.
La metodología ágil no requiere una planificación detallada,
el desarrollo comienza teniendo en cuenta las funciones y
características del software y el equipo cambia el curso del
desarrollo dinámicamente cada vez que se produce un
cambio en los requisitos.
59
Machine Translated by Google
solicitado. Este enfoque se enfoca más en la interacción
con el cliente y menos en la documentación para que el
El equipo de desarrollo está seguro de que está en el camino correcto.
Aunque el desarrollo ágil de software sigue un enfoque
muy realista, no es ideal para proyectos complejos y
siempre existe el riesgo de sostenibilidad, mantenibilidad
y extensibilidad. Este proceso tiene requisitos mínimos
de recursos y es ideal para proyectos donde los
requisitos sufren cambios con frecuencia. Dado que la
documentación es menor y el enfoque está
completamente en la interacción con el cliente, todo el
proyecto depende de qué tan bien el cliente pueda
comunicar sus requisitos. La metodología ágil permite
el desarrollo concurrente; las reglas son nominales que
se pueden emplear fácilmente.
Integración continua de software y pruebas
continuas de software En la forma tradicional de
desarrollo de software, los desarrolladores trabajan en
piezas de código individuales durante varios días y, una
vez que se completan las unidades individuales, pasan
a la integración de unidades.
Dado que en cada iteración esta metodología cree en
hacer que el proyecto se centre en el desarrollo de
código de alta calidad, se debe seguir la integración
continua. El concepto de integración continua
requiere mucha disciplina y las 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 quede sin integrar. En tal
escenario, el desarrollador necesita 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 ingresar en cualquier momento y ver
cómo se está desarrollando el producto y puede dar su
opinión sobre lo que se le presenta.
Pruebas y papel de las pruebas en el ciclo de vida
de la ingeniería de software ágil Las formas
tradicionales de desarrollo de software no utilizan un
probador en todo su potencial. De hecho, los evaluadores
comenzaron a trabajar solo después de que el requisito
funcional se había desarrollado por completo. En un
entorno ágil, el probador es un miembro muy importante
del equipo y está involucrado en cada fase de cada
iteración, ya sea en la planificación o en el análisis de
requisitos.
En esta metodología, la prueba es tan importante como
el desarrollo y el producto se somete a pruebas
continuas. El probador está trabajando continuamente
en metodología ágil y así, al final del proyecto, el número
de defectos en el
60
Machine Translated by Google

son muy inferiores en número porque la mayoría de

ellos han sido descubiertos en las fases iniciales del
desarrollo de software.

61
Machine Translated by Google
Gestión de proyectos de software
La gestión de proyectos de software incluye toda la información y
las herramientas necesarias para gestionar el proceso de los
proyectos de desarrollo de software. Para ejecutar correctamente
un plan de proyecto de desarrollo de software, el gerente redacta un
plan que describe cómo se llevará a cabo el desarrollo.
El plan también se enfoca en cómo se mantendrán los estándares
de calidad durante el proceso de desarrollo.
El gerente también define cómo se organizará el equipo de desarrollo,
cómo se llevará a cabo la gestión de riesgos.
Software de
planificación de proyectos La planificación de proyectos es
necesaria para controlar y monitorear los complejos procesos
involucrados en el desarrollo de software. La planificación del
proyecto se realiza para garantizar que el proyecto se complete a
tiempo, que el producto final sea de buena calidad y que el proyecto
se complete a tiempo. Para 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: define el problema y lo que se debe hacer para
resolverlo.
• Estimación: define el esfuerzo y el tiempo que
ir a completar el proyecto.
• Riesgo: define la obstrucción que el equipo puede enfrentar
durante el desarrollo del software y cómo se puede abordar.
• Cronograma: Asignación de recursos para que la
proyecto puede terminar a tiempo.
• Estrategia de control: define cómo realizar el control de calidad.
Dotación de
personal del proyecto Para llevar a cabo la dotación de personal
del proyecto, es importante definir varios roles, las habilidades
requeridas para cada rol, cómo se programará la dotación de
personal y cómo se hará la dotación de personal para cada rol. Para
cada función es necesario definir los requisitos de habilidades y
competencias, el nivel de experiencia, la disponibilidad y las expectativas salarial
Coordinación de Proyectos y Alineación de
Partes interesadas
Es responsabilidad del coordinador del proyecto de TI alinear a los
miembros del equipo interno con las partes interesadas externas.
Esto se hace coordinando varias fases y cronogramas del proyecto,
rastreando el progreso y haciendo arreglos para ordenar suministros
y
62
Machine Translated by Google

Servicios de apoyo. El director del proyecto supervisa las

actividades de coordinación del proyecto.

63
Machine Translated by Google
Ciclo de vida de las pruebas de software y
Operaciones de prueba de software
El ciclo de vida de las pruebas de software tiene las siguientes fases:
1 Estudio de requerimientos: donde se entiende el requerimiento del
cliente y se realiza la documentación funcional.
2 Plan de prueba: teniendo en cuenta los requisitos del proyecto, se
planifican las actividades de prueba y se prepara el documento del
plan de prueba.
3 Diseño de casos de prueba: se identifican escenarios de prueba y los
casos de prueba se diseñan en consecuencia.
4 Se mapean los requisitos y los casos de prueba y se prepara la matriz
de trazabilidad de los requisitos.
5 Ejecución de casos de prueba: las pruebas deben ser
ejecutado y los errores deben ser reportados.
6 Una vez corregidos los defectos, se deben realizar nuevas pruebas y
pruebas de regresión.
7 Se deben preparar informes de prueba.
8 Se completa la actividad de prueba.
Estudio de Requerimientos
En este proceso: • Se elabora
la matriz de trazabilidad de requerimientos. • Se establecen las
prioridades y el enfoque del módulo.
• Se identifican las áreas que requieren pruebas de automatización y las
que requieren pruebas manuales.
Diseño y desarrollo de casos de prueba
Este proceso implica: •
Preparación de casos de prueba y guiones de prueba (si se trata de
pruebas automatizadas) • Preparación de datos para pruebas
Ejecución de pruebas
La ejecución de la prueba consiste en:
• Ejecución de casos de prueba • Usar
una herramienta de seguimiento de errores para
registrar errores • Documentar los resultados de las
pruebas • Usar el RTM para mapear defectos según lo requerido
mento
• Seguimiento del estado del error
Cierre de prueba
Prueba de Cierre consta de:
• Las métricas de prueba se preparan considerando la cobertura de
prueba, costo, tiempo, calidad, etc. • Preparación del informe de
cierre de prueba. • Se calcula la distribución de defectos por tipo y
gravedad.
• Se prepara análisis casual y resolución (CAR)
rojo.
64
Machine Translated by Google

Análisis del proceso de

prueba Se requiere un análisis del proceso de prueba antes
de comenzar con las pruebas de software. Los documentos
que brindan información para comenzar con las pruebas
se denominan documentos base de prueba. Estos incluyen
SRS, diseño del sistema, arquitectura, interfaz, etc. Con la
ayuda de estos documentos, los evaluadores comprenden
el sistema y buscan las condiciones o posibilidades de
prueba que formarán parte del caso de prueba. Una vez
que se han identificado las condiciones de prueba, se
priorizan y se crean los casos de prueba.

sesenta y cinco
Machine Translated by Google
Entregables de pruebas de software
Equipo
Los entregables de prueba son documentos que se entregan a las partes
interesadas cuando se desarrolla el software.
En esta sección discutiremos los siguientes entregables de prueba:
Entregables del equipo de pruebas de software
• Estrategia de prueba de software • Plan
de prueba de software • Escenarios y casos
de prueba de software • Métricas de prueba de software •
Métricas de producto • Métricas de proceso
• Documentaciones de prueba de software •
Informes de prueba de software
•
Informes diarios del estado de las
pruebas • Informes de incidentes
•
Informe de estado de prueba final (cierre del proyecto de prueba)
Estrategia de prueba de software Una
estrategia de prueba de software es una hoja de ruta para las actividades de
prueba en un proyecto. Las pruebas pueden ser muy difíciles si no se dividen
en procesos más pequeños y bien definidos. Una estrategia de prueba ayuda a
definir el proceso de prueba y sobre la base de la cual el equipo de prueba
evalúa el tiempo, el esfuerzo y los recursos necesarios para todo el proceso.
Una buena estrategia es aquella que permite una buena planificación, gestión y
seguimiento de los procesos.
Plan de prueba de software Un
plan de prueba define la estrategia general para probar el software. Explica el
entorno de prueba requerido y qué nivel de prueba se llevará a cabo. El plan
de prueba imparte información sobre cómo se analizarán los resultados de la
prueba y qué métricas se utilizarán para tal fin. Se definen los criterios de salida
para cada fase y se mencionan en el plan la estimación del esfuerzo y el costo
de la prueba.
66
Machine Translated by Google

proceso muy complicado. Luego, la industria ideó algo que era fácil
de usar.

Plan de Pruebas de Software

Escenarios de prueba de software y casos de

prueba El escenario de prueba es un caso hipotético creado para
ayudar al probador a probar el software de una manera bien definida. Escenarios de prueba de software y casos de prueba
Los casos de prueba, por otro lado, son muy simples y directos y
explican lo que se debe hacer.
Por lo general, son declaraciones de una línea y debe ingresar una Los casos de prueba, por otro lado, son muy directos. Dicen lo que
entrada y verificar la salida esperada para cada entrada. Los debe hacer el probador y cómo el software
escenarios de prueba pueden ser complejos y convincentes como necesita ser probado.
una historia. Es una situación dada a un probador para evaluar el
software.

El concepto de escenarios de prueba surgió en el año 2003 luego

de que se observara que el mantenimiento de casos de prueba con
descripción paso a paso, datos de entrada y resultados esperados Escenarios de prueba de software y casos de prueba
era un

67
Machine Translated by Google
Métricas de prueba de
software Como su nombre indica, las métricas de software no son
más que los estándares de medición definidos para evaluar el
software. Cualquier unidad utilizada para medir cualquier atributo
del software se denomina métrica. Las métricas de prueba de
software se utilizan para medir la calidad del software.
Estas métricas dan una idea clara sobre la preparación de un
sistema mientras aún está en desarrollo. Ahora puede preguntarse
por qué necesitamos una métrica de prueba de software.
Bueno, la respuesta es muy simple: solo podemos mejorar aquellas
cosas que podemos medir, porque todo lo que es medible es
controlable. Las decisiones de cada fase del desarrollo de software
se toman solo después de consultar las métricas de prueba de
software de la fase anterior. Las métricas de prueba de software
pueden ser de dos tipos:
1 Medida directa/Métrica base: estos datos son sin procesar
y es recopilada por un analista de pruebas. Las métricas
base proporcionan información sobre el estado del proyecto,
como cuántos casos de prueba se han creado, cuántos se
han ejecutado, etc.
2 Medida indirecta/Métricas calculadas: datos sin procesar
recopilados de métricas base cuando se convierten en
información más útil que brinda información precisa sobre
el proyecto, como el % de
la finalización del proyecto, el % de cobertura de la prueba
y el hijo se denominan métricas calculadas.
Métricas de productos
Las métricas de productos juegan un papel muy importante en la
definición de iniciativas de mejora de la calidad del producto.
La evaluación constante del producto ayuda al equipo a decidir con
tiempo si es necesario algún tipo de corrección en alguna
característica del producto.
Las métricas de productos miden las características de un producto:
• Tamaño • Complejidad • Aspectos de diseño • Rendimiento •
Calidad
Métricas de procesos
Las métricas de procesos miden los procesos de modo que si hay
alguna posibilidad de mejora que se pueda realizar.
Las métricas de proceso pueden ayudar a ahorrar mucho tiempo y
esfuerzo. Cada proceso está diseñado teniendo en cuenta algún
objetivo y las métricas del proceso ayudan a evaluar hasta qué
punto el equipo ha tenido éxito en lograrlo.
Las métricas de proceso juegan un papel muy importante en el
seguimiento de las actividades de prueba de software. Las pruebas
de software son un aspecto muy importante del desarrollo de software y
68
Machine Translated by Google
la eficiencia y la eficacia de un proyecto pueden mejorar significativamente
mediante el seguimiento de las actividades de prueba. Desde el punto de
vista del proceso de desarrollo de software, las métricas se pueden utilizar
para medir:
• Desarrollo de software • Mantenimiento
de software • Pruebas de software
Documentaciones de prueba de software Los
documentos de prueba de software que se prepararon durante o antes de la
prueba para realizar un seguimiento de todas las actividades de prueba se
denominan documentos de prueba de software. los
Los documentos importantes de prueba de software incluyen: • Plan
de prueba • Escenario de prueba • Caso de prueba • Matriz de
trazabilidad
Informes de pruebas de software
En esta sección discutiremos los siguientes informes:
•
Informes diarios del estado de las
pruebas • Informes de incidentes
•
Informe de estado de prueba final (cierre del proyecto de prueba)
Informes de estado de prueba diarios
El informe de estado de prueba diario ayuda a mantener la transparencia
dentro del equipo de prueba y con el
interesados en proyectos y programas. En cualquier momento, el
administrador del proyecto puede ver cuántos defectos se informan
diariamente, cuántos casos de prueba se ejecutan y cuánto trabajo realizó
cada probador. Un informe de estado diario tiene información sobre: 1
Cuántos casos de prueba se planificaron para el
¿día?
2 ¿Cuántos de ellos fueron ejecutados?
3 ¿Cuántos defectos ha informado el equipo de pruebas?
4 ¿Cuántos de los defectos fueron críticos?
5 Ubicación: ¿Dónde se pueden ver los informes de prueba más detallados
(hoja de defectos y ejecución de pruebas)?
Informes de incidentes
Los informes de incidentes ayudan a coordinar las actividades de prueba y
desarrollo. La gestión de incidentes implica:
• Comparación de los resultados reales y esperados • ¿Cuál fue la
causa de la desviación en los casos en que fallaron las pruebas? –
¿Automatización de prueba defectuosa, caso de prueba deficiente,
falla real del software?
69
Machine Translated by Google

El informe de incidentes debe estar preparado para una falla real. Informe de estado de prueba final (cierre del proyecto de
Un informe de incidente debe proporcionar los siguientes detalles: prueba) El informe de cierre del proyecto de prueba se crea
cuando se alcanza el criterio de salida del proyecto o cuando se ha
completado toda la actividad de prueba. Este informe lo crea el líder
• Identificación de prueba y luego lo revisan todas las partes interesadas y los
• ¿Cuál es el ID de cada informe? • ¿Cuál clientes. Este informe tiene todos los detalles de los casos de
es el objeto de prueba? • Versión de la prueba que se han ejecutado con éxito y si hay algún defecto
aplicación de software bajo prueba pendiente que el equipo planea resolver después de la
• Detalles del entorno de prueba - hardware y implementación del proyecto, también se menciona en este informe.
software
• Nombre del desarrollador que necesita evaluar
y resolver el incidente
• ¿Cuándo se observó la falla? • Clasificación
• Estado • Gravedad Prioridad • Requisito •
Causa • Descripción del problema •
Descripción del problema Detalles del caso
•
de prueba

• Comentarios del probador

• Comentario del desarrollador después del
cambio • Cualquier referencia

70
Machine Translated by Google
¿Qué es el riesgo de software
y la gestión de riesgos de software?
El riesgo es una expectativa de pérdida, un problema potencial que
puede ocurrir o no en el futuro. Generalmente se debe a la falta de
información, control o tiempo. La posibilidad de sufrir una pérdida
en el proceso de desarrollo de software se denomina riesgo de
software. La pérdida puede ser cualquier cosa, aumento en el costo
de producción, desarrollo de software de mala calidad, no poder
completar el proyecto a tiempo. El riesgo de software existe porque
el futuro es incierto y hay muchas cosas conocidas y desconocidas
que no se pueden incorporar en el plan del proyecto. Un riesgo de
software puede ser de dos tipos (a) riesgos internos que están bajo
el control del administrador del proyecto y (2) riesgos externos que
están fuera del control del administrador del proyecto. La gestión de
riesgos se lleva a cabo para:
1 Identificar el riesgo
2 Reducir el impacto del riesgo
3 Reducir la probabilidad o posibilidad de riesgo
4 Seguimiento de riesgos
Un director de proyecto tiene que hacer frente a los riesgos
derivados de tres posibles casos:
1 Los conocimientos conocidos son riesgos de software que
en realidad son hechos conocidos por el equipo y por todo
el proyecto. Por ejemplo, no tener un número suficiente de
desarrolladores puede retrasar la entrega del proyecto.
Dichos riesgos se describen e incluyen en el Plan de Gestión
del Proyecto.
2 Las incógnitas conocidas son riesgos de los que el equipo
del proyecto es consciente, pero se desconoce que tales
existe riesgo en el proyecto o no. Por ejemplo, si la
comunicación con el cliente no es de buen nivel, entonces
no es posible capturar el requisito correctamente. Este es un
hecho conocido por el equipo del proyecto, sin embargo, el
proyecto desconoce si el cliente ha comunicado toda la
información correctamente o no.
3 Desconocidos Los desconocidos son ese tipo de riesgos
sobre los cuales la organización no tiene idea. Dichos
riesgos generalmente están relacionados con la tecnología,
como trabajar con tecnologías o herramientas de las que no
tiene idea porque su cliente quiere que trabaje de esa
manera que de repente lo expone a riesgos desconocidos
absolutamente desconocidos.
La gestión de riesgos de software tiene que ver con la cuantificación
del riesgo. Esto incluye:
1 Dar una descripción precisa del evento de riesgo que
puede ocurrir en el proyecto
71
Machine Translated by Google

2 Definición de probabilidad de riesgo que explicaría cuáles son las los factores sociales, internos o externos deben evaluarse adecuadamente.
posibilidades de que ese riesgo ocurra

3 Definición de la cantidad de pérdida que un riesgo particular puede

causa

4 Definición del potencial de responsabilidad del riesgo

La gestión de riesgos comprende los siguientes procesos:

1 Identificación de riesgos de software

2 Análisis de riesgos de software

3 Planificación de riesgos de software
4 Supervisión de riesgos de software

Estos Procesos se definen a continuación.

Identificación de riesgos de software

Identificación de riesgos de software

Para identificar los riesgos a los que puede estar sujeto su proyecto, es
En esta fase de Gestión de riesgos, debe definir procesos que son
importante estudiar primero los problemas que enfrentan los proyectos
importantes para la identificación de riesgos.
anteriores. Estudie adecuadamente el plan del proyecto y verifique todas
Todos los detalles del riesgo, como la identificación única, la fecha en que
las posibles áreas que son vulnerables a algunos u otros tipos de riesgos.
se identificó, la descripción, etc., deben mencionarse claramente.
La mejor manera de analizar un plan de proyecto es convertirlo en un
diagrama de flujo y examinar todas las áreas esenciales. Es importante
realizar algunas sesiones de lluvia de ideas para identificar las incógnitas
Análisis de riesgos de software
conocidas que pueden afectar el proyecto. Cualquier decisión tomada
El análisis de riesgos de software es un aspecto muy importante de la
relacionada con aspectos técnicos, operativos, políticos, legales,
gestión de riesgos. En esta fase se identifica el riesgo y luego se categoriza.
Luego de la categorización del riesgo, se analiza el nivel, probabilidad
(porcentaje) e impacto del riesgo. La probabilidad se define en porcentaje.

72
Machine Translated by Google

después de examinar cuáles son las posibilidades de que ocurra un Análisis de riesgo cuantitativo: se puede utilizar para el análisis de
riesgo debido a diversas condiciones técnicas. Estas condiciones riesgo de software, pero se considera inapropiado porque el nivel de
técnicas pueden ser: riesgo se define en %, lo que no brinda una imagen muy clara.

1 Complejidad de la tecnología
2 Conocimientos técnicos que posee la prueba
equipo Planificación de riesgos de software
3 Conflictos dentro del equipo La planificación de riesgos de software tiene que ver con:

4 Equipos distribuidos en una gran área geográfica
5 Uso de herramientas de prueba de mala calidad
Con impacto nos referimos a la consecuencia de un riesgo en caso
de que ocurra. Es importante conocer el impacto porque es necesario
saber cómo un negocio puede verse afectado: 1 Cuál será la pérdida
para el cliente
1 Definición de medidas preventivas que reduzcan la posibilidad o
probabilidad de varios riesgos.
2 Definir medidas que reducirían el impacto en caso de que ocurra
un riesgo.
3 Seguimiento constante de los procesos para identificar
riesgos lo antes posible.

2 ¿Cómo sufriría el negocio?

3 Pérdida de reputación o daño a la sociedad
4 Pérdidas monetarias
5 Acciones legales contra la empresa
6 Cancelación de la licencia comercial

El nivel de riesgo se identifica con la ayuda de:

Análisis Cualitativo de Riesgos: Aquí se define el riesgo como:
• Alto •
Bajo •
Medio
Planificación de riesgos de software

73
Machine Translated by Google

Monitoreo de riesgos de software

El monitoreo de riesgos de software está integrado en las actividades

del proyecto y se realizan verificaciones periódicas de los principales
riesgos. El monitoreo de riesgos de software se compone de:

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

plan real, atributo, etc.
• Elaboración de informes de estado del proyecto
administración.
• Revisar los riesgos y aquellos cuyo impacto o probabilidad haya
alcanzado el nivel más bajo posible deben ser cerrados. •
Búsqueda regular de nuevos riesgos

74
Machine Translated by Google

5 Dificultad en la gestión de cambios en el software

Procesos para apoyar el software sistema de diseño.

Pruebas

Esta sección se centra en algunos procesos muy importantes que

son esenciales para realizar un seguimiento del progreso de las
pruebas de software. En esta sección aprenderá sobre: • El ciclo
de vida de la gestión de defectos y cómo

obras
• Matriz de Trazabilidad •
Técnicas de Estimación de Pruebas de Software •
¿Qué es el ciclo de vida de la gestión de defectos y cómo
Gestión de la Configuración • Gestión del Cambio funciona?

El ciclo de vida de los defectos se define para gestionar los

¿Qué es el ciclo de vida de la gestión de defectos y cómo
defectos en el sistema. De hecho, es el viaje de un error en el
funciona?
sistema desde el momento en que se encuentra hasta el momento
El software es desarrollado por humanos y es injusto esperar que
en que se cierra. Las etapas del ciclo de vida de un defecto se
un software de millones de líneas de código esté libre de defectos. dan a continuación:
Los defectos son inducidos debido a muchos
razones:
1 Nuevo: cuando se descubre un defecto, se le asigna el estado
1 No se comunican los requisitos 'Nuevo'.
claramente
2 Abierto: cuando un nuevo defecto encontrado pasa a revisión,
2 Errores de programación causados durante el desarrollo
tiene el estado 'Abierto'
3 Duplicado: si el defecto ya se ha informado anteriormente,
3 Diseño de sistemas complejos
entonces se llama 'Duplicado'
4 Documentación de mala calidad o incompleta

75
Machine Translated by Google
4 Asignado: este estado indica que el error se ha asignado a
un desarrollador para que lo corrija.
5 Re-probado: Una vez que se corrige el defecto, el probador
realiza pruebas para comprobar si el defecto se ha
cerrado o no.
6 Reabierto/cerrado: si el defecto es reparado se le asigna
el estado de 'cerrado' o en caso contrario se 'reabierto'.
¿Qué es la matriz de trazabilidad?
La matriz de trazabilidad es una herramienta que se utiliza para
conectar y rastrear los requisitos del proyecto (relacionados
con la seguridad, la aplicación y el negocio) con los procesos
de implementación y prueba. Esto ayuda a analizar cuánto de
los requisitos del proyecto se han completado.
Una matriz de trazabilidad es de gran utilidad en proyectos
complejos de desarrollo de software. Con la ayuda de esta
herramienta, puede rastrear cómo funcionan las cosas en
cualquier sección del proyecto. Esta matriz se crea en un
documento de hoja de cálculo que consta de filas y columnas.
Un conjunto de valores se establece en la fila y otro conjunto
de valores se establece en las columnas. Si hay algún tipo de
relación entre cualquier valor de la columna y cualquier valor
de la fila entonces un
la marca de identificación se coloca en la celda donde se
cruzan la columna y la fila.
Entonces, si colocamos los diversos requisitos del proyecto en
la columna de la izquierda y varios procesos de prueba en la
parte superior de la fila. Luego, podemos mapear fácilmente
qué procesos de prueba se han completado para cada uno de
los requisitos. Esto daría una idea precisa sobre cuánto
porcentaje de requisitos se ha completado.
¿Q ué son las técnicas de estimación de pruebas de
software?
Los diferentes proyectos de software pertenecen a diferentes
dominios, por lo que las técnicas de estimación de software
pueden variar un poco de un proyecto a otro. Además, es muy
difícil acertar en la estimación a la primera. 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. Las técnicas de estimación proporcionan una estimación
del tiempo que puede ser necesario para terminar una tarea en particular.
La estimación se realiza para tener una idea aproximada de
cuánto esfuerzo se necesitaría para completar una tarea en
particular. La estimación también podría significar costo.
Muchos factores, como la experiencia pasada, las suposiciones,
los documentos, los riesgos calculados, etc., ayudan a determinar
76
Machine Translated by Google
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. La estimación
del software es necesaria para evitar las posibilidades de sobrepasar
el presupuesto durante las pruebas o la demora en la finalización del
proyecto.
1 La técnica de estimación del software Delphi es la técnica más
utilizada para la estimación. Proporciona una forma de lograr
un acuerdo dentro de un equipo sin ningún conflicto. Cada
uno del equipo proporciona un presupuesto anónimo e
individual que es valorado por el coordinador. Si la evaluación
está dentro del rango aceptable, entonces se puede tomar
una decisión o, de lo contrario, se repite el proceso nuevamente.
2 La Estructura de Desglose del Trabajo se usa en proyectos
grandes donde primero el proyecto se divide en componentes
más pequeños en una jerarquía y luego se lleva a cabo el
proceso de estimación para evaluar la programación de tareas
y la estimación detallada de costos del proyecto.
3 La técnica de estimación de tres puntos también se usa para
proyectos grandes donde el proyecto se divide primero en
subsecciones más pequeñas y luego
cada subsección primero se realiza la estimación optimista
asumiendo que nada saldrá mal y que todas las condiciones
están bien (A). El segundo enfoque es de estimación más
probable donde se supone
que existe la posibilidad de que surjan problemas pero
eventualmente todo estará bien (B). El tercer enfoque es la
estimación pesimista donde todo saldrá mal (C). Entonces, la
fórmula de estimación se define como: A+(4*B)+C/6 4 El
método de punto funcional sugiere que: (Estimación de
esfuerzo total) = (Número total de puntos de función) (estimación
de cada punto funcional).
*
La fórmula mencionada anteriormente aclara que se da más
peso a cada punto de función. Los puntos de función se
clasifican en complejos, medios y simples y luego se realiza
una estimación.
¿Qué es la gestión de la configuración?
La gestión de la configuración es necesaria para mantener la
coherencia en el rendimiento de un sistema.
La gestión de la configuración implica: Todos
•
los elementos de configuración están etiquetados con
identificadores únicos Identificación de todos los documentos
• que describen
elemento de
configuración • Los elementos de configuración relacionados deben agruparse
en líneas base
• Después de cada revisión, es importante etiquetar los elementos
de configuración y las líneas base.
77
Machine Translated by Google

El desarrollo de software es un proceso complejo donde los documentado y todas las configuraciones son fáciles de
siguientes problemas son muy comunes: identificar.
1 Muchas veces los desarrolladores tienden a sobrescribir las
modificaciones de los demás
2 Si las versiones no se mantienen adecuadamente, el proceso
de integración puede ser muy difícil.
3 A veces hay problemas de compatibilidad entre las versiones
del compilador y las herramientas de desarrollo.

4 Confusión sobre qué casos de prueba pertenecen a la versión

actual del software.

Todos estos problemas se pueden manejar con la ayuda de la

gestión de configuración que define: • Gestión de versiones:
mantener el registro de varias versiones del objeto bajo prueba
correspondiente a la versión del elemento configurado. •
Identificación de la configuración: ayuda a definir de forma
única el sistema, cada versión revisada del sistema y los
componentes de cada versión revisada.
• Documentación del estado del incidente y solicitud de cambio:
Estos documentos imparten información sobre varios
incidentes y el cambio solicitado y su estado actual.
• Auditorías de configuración: asegúrese de que los detalles de
todos los componentes del software estén bien
¿Qué es la gestión de la configuración?
¿Qué es la gestión del cambio?
Como sugiere el nombre, la gestión del cambio tiene que ver con
lidiar con el cambio en la forma en que trabajamos.
La gestión del cambio es necesaria en varios niveles, desde el
nivel de la empresa hasta el nivel individual. La gestión del cambio
se ocupa de:
1 Adaptarse al cambio: Muchas veces se vuelve sumamente
importante implementar procesos estructurados para
generar un cambio positivo en el negocio. En los tiempos
actuales de recesión o desaceleración de la economía, las
empresas deben implementar mecanismos estables que
ayuden

78
Machine Translated by Google

los miembros del personal lidian con la presión en
condiciones difíciles.
2 Control del cambio: hacer frente a los nuevos cambios en el
entorno empresarial. Independientemente de los nuevos
cambios que realice en el entorno, es
importante monitorear los cambios y rastrear los detalles
del sistema.
3 Efectuar cambios: generar ganancias a partir de los cambios
positivos.

¿Qué es la gestión del cambio?

79
Machine Translated by Google

Gracias
Me gustaría agradecerle nuevamente por tomarse el tiempo de
leer Pruebas de software reveladas. Esperamos que haya
disfrutado leyendo este libro tanto como nosotros lo habíamos
hecho mientras lo escribíamos. Es nuestro mayor placer si de
alguna manera logramos ayudarlo a construir una base sólida
de pruebas de software.

Sabemos que es un mundo muy complejo, abrumador y

superpoblado con todas las certificaciones de pruebas de
software que hay en el mercado.

Y, sin embargo, logramos construir nuestros programas de

certificación de pruebas de software más concretos, atractivos,
útiles, útiles y simples que nuestra competencia.
Es por eso que creemos que nuestros valiosos estudiantes
eligen International Software Test Institute™ en lugar de las
soluciones burocráticas, complejas, caras y a medias de nuestros
competidores.

Nuestro proceso de registro, examen y certificación, único

en su tipo, líder en la industria, es muy simple, rápido y
completamente en línea. Haga clic en este enlace para
conocer todos los detalles: Certificación de pruebas de software

Yeliz Obergfell, Instituto Internacional de Pruebas de Software™

80