UNIVERSIDAD MAYOR DE SAN SIMON

FACULTAD DE CIENCIAS Y
TECNOLOGIA
DIRECCIÓN DE POSGRADO

“La Rueda del Software Testing ¿Cuáles son los

diferentes factores de calidad y cómo los
probamos?”

TRABAJO FINAL PRESENTADO PARA OBTENER EL CERTIFICADO

DE DIPLOMADO EXPERTO EN DESARROLLO DE APLICACIONES
EMPRESARIALES VERSIÓN I
.

POSTULANTE : Juan Marcelo Equise Choque

TUTOR : Ing. Mauricio Viscarra

Cochabamba – Bolivia 2018

Dedico este proyecto a:

Mi mamá, que siempre estuvo, está y estará

a mi lado.

Mis tíos, por su constante apoyo y aliento a

seguir adelante.

Mi papá y hermanos, por su tiempo y ayuda

constante.
ÍNDICE
2. Resumen 1
3. IntroduccióN 3
4. Generalidades 5
4.1 Antecedentes Generales 5
4.2 Antecedentes Específicos 5
5. Metodología 5
6. Tipos de pruebas 6
6.1 Pruebas funcionales (Functional Testing) 6
6.2 Pruebas no funcionales (Non-functional Testing) 7
6.3 Pruebas de caja blanca (White-box Testing) 7
6.4 Pruebas relacionadas con el cambio (Change-related Testing) 8
7. Idoneidad Funcional como un factor de la Calidad de Software 9
7.1 Atributos de la Idoneidad Funcional 9
7.2 Pruebas asociadas a la Idoneidad Funcional 9
8. Eficiencia de Desempeño como un factor de la Calidad de Software 17
8.1 Atributos de la Eficiencia de Desempeño 17
8.2 Pruebas asociadas a la Eficiencia de Desempeño 17
9. Compatibilidad como un factor de la Calidad de Software 20
9.1 Atributos de la Compatibilidad 20
9.2 Pruebas asociadas a la Compatibilidad 20
10. Usabilidad como un factor de la Calidad de Software 22
10.1 Atributos de la Usabilidad 22
10.2 Pruebas asociadas a la Usabilidad 23
11. Fiabilidad como un factor de la Calidad de Software 24
11.1 Atributos de la Fiabilidad 24
11.2 Pruebas asociadas a la Fiabilidad 25
12. Seguridad como un factor de la Calidad de Software 26
12.1 Atributos de la Seguridad 26
12.2 Pruebas asociadas a la Seguridad 26
13. Mantenibilidad como un factor de la Calidad de Software 29
13.1 Atributos de la Mantenibilidad 29
13.2 Pruebas asociadas a la Mantenibilidad 29
14. Portabilidad como un factor de la Calidad de Software 29
14.1 Atributos de la Portabilidad 30
14.2 Pruebas asociadas a la Portabilidad 30
15. Conclusiones 33
16. Bibliografía 35
ÍNDICE DE CUADROS, GRÁFICOS Y FIGURAS

Figura 7-1 Niveles de Pruebas (Autoría propia) ........................................................................ 10

Figura 8-1 Representación de algunos tipos de pruebas de rendimiento. (Sofia Palamarchuk -

Types of Perfomance Tests, https://abstracta.us/blog/performance-testing/types-of-performance-

tests/) ........................................................................................................................................ 20

Figura 15-1 Representación de la rueda del software testing (Federico Toledo - The Software

Testing Wheel, https://abstracta.us/blog/software-testing/the-software-testing-wheel/) .............. 34

 1

RESUMEN

Las normas de la ISO 25010 (Systems and software engineering — Systems and software Quality
Requirements and Evaluation (SQuaRE) — System and software quality models) concluyen que la calidad
de un producto de software es la suma total de diferentes atributos de calidad que están agrupados dentro
de varios factores de calidad. Por ejemplo, el performance es un factor compuesto del tiempo de respuesta,
capacidad, uso de recursos, etc.
Existe también una clasificación de factores internos y externos. Entre los internos tenemos a la
mantenibilidad y todo lo demás respecto a la calidad de código. Entre los externos tenemos al desempeño,
la funcionalidad y la usabilidad.
Por otra parte, estos factores externos e internos no son siempre muy claros, existen muchos factores que
son parcialmente internos y externos como la seguridad.
Es sabido que cada atributo de calidad tiene asociado un tipo de prueba de software que verifica si la calidad
alcanza las expectativas del cliente o usuario. En este trabajo de investigación todos los factores, atributos
y pruebas de calidad son puestos en una Rueda del Software Testing, para representar que el Testing es algo
que rodea y protege la calidad de software, que se encuentra en el centro de la rueda.
Se examina cada factor de calidad (Idoneidad Funcional, Eficiencia en el desempeño, Compatibilidad,
Usabilidad, Confiabilidad, Seguridad, Mantenibilidad y Portabilidad), sus atributos y las pruebas asociadas
con cada factor.
Palabras clave: Software, Testing, Calidad, Pruebas, Factores, Atributos
 3

INTRODUCCIÓN
La calidad de software comprende muchos factores, en muchos casos al desarrollar un producto de
software; el equipo de desarrollo no toma en cuenta todos estos factores. Lo que deriva en que el producto
presente defectos, baja performance, clientes y/o usuarios insatisfechos y otra serie de problemas que en
resumen indican una baja calidad en el software desarrollado.
Como se mencionó anteriormente, la calidad de software está asociada a muchos factores, para este trabajo
de investigación se tomó como base los factores mencionados en las normas de la ISO 25010 (Systems and
software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — System
and software quality models). Haciendo énfasis en los siguientes factores: Idoneidad funcional, Eficiencia
en el desempeño, Compatibilidad, Usabilidad, Confiabilidad, Seguridad, Mantenibilidad y Portabilidad.
Cada uno de estos factores tiene un conjunto de atributos y pruebas asociadas que son mencionados y
analizados a lo largo del documento.
La unión de cada factor de calidad forma la llamada Rueda del Software Testing, que tiene en su capa
externa los distintos tipos de pruebas de software correspondientes a cada factor de calidad, en la capa
media se tiene los atributos de cada factor y en la capa interna los factores calidad.
Con esta investigación se pretendió colaborar con el desarrollo de productos de software de mejor calidad.
Examinando diferentes factores de calidad que forman parte de la Rueda del Software Testing, que rodea y
protege la “calidad del software”, que se encuentra en el centro de la rueda. Y así cumplir de mejor manera
las expectativas del usuario o cliente al momento de entregar un producto de software y no descuidar ningún
aspecto que pudiera afectar a la calidad del mismo.
 5

GENERALIDADES
4.1 Antecedentes Generales
La expresión “calidad” se utiliza con frecuencia en cualquiera de los ámbitos de nuestra sociedad, sin
importar el sector del que procede el comentario ni la vertiente hacia la que se dirige.
Las organizaciones o empresas tienen entre sus metas:
 Cumplir las expectativas del cliente y despertar en él nuevas necesidades
 Reducir o eliminar al máximo los defectos que se producen a lo largo del proceso productivo
 Dar respuesta inmediata a las solicitudes de los clientes
 Disfrutar de una categoría empresarial que aspira siempre a la excelencia
Ante estas finalidades, la noción de “calidad” aparece como un concepto de integración en la actividad
desarrollada por cualquier organización.
Calidad representa un proceso de mejora continua, en el cual todas las áreas de la empresa buscan satisfacer
las necesidades del cliente o anticiparse a ellas, participando activamente en el desarrollo de productos o en
la prestación de servicios.
1.2 Antecedentes Específicos
La calidad de software está definida en la norma ISO 25010, el término calidad en uso se refiere al impacto
que un sistema de software tiene en sus clientes o usuarios. El mismo sistema podría tener diferente calidad
en uso para diferentes personas, dependiendo de sus deseos y comportamiento. Esto es calidad subjetiva:
depende de quien la juzgue.
La presente monografía se centra en el modelo de calidad de un producto de software, este modelo trata de
características de la calidad de software que son inherentes a un sistema de software y que pueden ser
juzgadas en producción. Las ocho características de la calidad de un producto de software son: Idoneidad
funcional, Eficiencia en el desempeño, Compatibilidad, Usabilidad, Confiabilidad, Seguridad,
Mantenibilidad y Portabilidad.
Estos ocho factores son independientes de los usuarios y el contexto.
METODOLOGÍA
Para el presente trabajo se utilizó los siguientes métodos de investigación:
 Método Bibliográfico, debido a que se realizará la lectura y compilación de libros relacionados al
tema de estudio.
 Método Analítico, debido a que se procederá a revisar y analizar ordenadamente documentos
relacionados al tema de estudio, para la redacción del presente trabajo.
 6

TIPOS DE PRUEBAS
Antes de mencionar los diferentes factores de calidad de un producto de software, en este apartado se
mencionan los diferentes tipos de pruebas que existe y como están agrupados.
Un tipo de prueba es un grupo de actividades de prueba destinadas a probar características específicas de
un sistema de software, o una parte de un sistema, basado en objetivos de prueba específicos. Tales objetivos
pueden incluir: [1, p. 39]
 Evaluar características de calidad funcional, como integridad, correctitud y apropiación
 Evaluar características de calidad no funcionales, como la confiabilidad, la eficiencia de
rendimiento, seguridad, compatibilidad y usabilidad.
 Evaluar si la estructura o arquitectura del componente o sistema es correcta, completa, y como se
ha especificado
 Evaluar los efectos de los cambios, como confirmar que se han solucionado los defectos (pruebas
de confirmación) y buscando cambios no deseados en el comportamiento que resultan de cambios
en el software (pruebas de regresión)

1.3 Pruebas funcionales (Functional Testing)

Las pruebas funcionales de un sistema involucran pruebas que evalúan las funciones que el sistema debe
realizar. Los requisitos funcionales se pueden describir en productos de trabajo, como especificaciones de
requisitos comerciales, epics, historias de usuario, casos de uso o especificaciones funcionales, o pueden
estar sin documentar.
Las funciones son "qué" debería hacer el sistema. Las pruebas funcionales deben realizarse en todos los
niveles de prueba (por ejemplo, las pruebas para componentes pueden basarse en una especificación del
componente). [1, p. 39]
Las pruebas funcionales consideran el comportamiento del software, por lo que se pueden utilizar técnicas
de caja negra para derivar condiciones de prueba y casos de prueba para la funcionalidad del componente
o sistema.
La minuciosidad de las pruebas funcionales se puede medir a través de la cobertura funcional. La cobertura
funcional es la medida en que algún tipo de elemento funcional ha sido ejercido por pruebas, y es expresado
como un porcentaje del tipo(s) de elemento cubierto.
El diseño y la ejecución de pruebas funcionales pueden involucrar habilidades o conocimientos especiales,
como el conocimiento del problema empresarial particular que resuelve el software (por ejemplo, el
software de modelado geológico para industrias de petróleo y gas) o la función particular que cumple el
 7

software (por ejemplo, software de juegos de computadora que proporciona entretenimiento interactivo).
[1, p. 40]
1.4 Pruebas no funcionales (Non-functional Testing)
La prueba no funcional de un sistema evalúa las características de los sistemas y el software, como la
facilidad de uso, eficiencia de rendimiento o seguridad. La prueba no funcional es la prueba de "qué tan
bien" se comporta el sistema. Contrariamente a las percepciones erróneas comunes, las pruebas no
funcionales pueden y, a menudo, deben realizarse en todos los niveles de pruebas, y debe ser hecho tan
pronto como sea posible. El descubrimiento tardío de defectos no funcionales puede ser extremadamente
peligroso para el éxito de un proyecto.
Pueden utilizarse técnicas de caja negra para derivar condiciones de prueba y casos de prueba para pruebas
no funcionales Por ejemplo, el análisis del valor límite se puede usar para definir las condiciones de estrés
para pruebas de rendimiento. [1, p. 40]
La minuciosidad de las pruebas no funcionales se puede medir a través de una cobertura no funcional. Una
cobertura no funcional es la medida en que algún tipo de elemento no funcional ha sido ejercido por pruebas,
y se expresa como un porcentaje del tipo (s) de elemento que se cubre. Por ejemplo, usando trazabilidad
entre pruebas y dispositivos compatibles para una aplicación móvil, el porcentaje de dispositivos los cuales
se abordan mediante pruebas de compatibilidad pueden calcularse, identificando potencialmente brechas
de cobertura.
El diseño y la ejecución de pruebas no funcionales pueden involucrar habilidades o conocimientos
especiales, como el conocimiento de las debilidades inherentes de un diseño o tecnología (por ejemplo,
vulnerabilidades de seguridad asociadas con lenguajes de programación). [1, p. 40]
1.5 Pruebas de caja blanca (White-box Testing)
Las pruebas de caja blanca derivan pruebas basadas en la estructura interna o la implementación del sistema.
La estructura interna puede incluir código, arquitectura, flujos de trabajo y / o flujos de datos dentro del
sistema.
La minuciosidad de las pruebas de caja blanca se puede medir a través de la cobertura estructural. Cobertura
estructural es la medida en que algún tipo de elemento estructural ha sido ejercido por pruebas, y se expresa
como el porcentaje del tipo de elemento siendo cubierto.
En el nivel de prueba de componentes, la cobertura del código se basa en el porcentaje de código de
componente que ha sido probado, y se puede medir en términos de diferentes aspectos del código
(elementos de cobertura) como el porcentaje de sentencias ejecutables probadas en el componente, o
porcentaje de resultados de decisión probado. Estos tipos de cobertura se denominan colectivamente
 8

cobertura de código. En el nivel de pruebas de integración de componentes, la prueba de caja blanca puede
basarse en la arquitectura del sistema, como las interfaces entre los componentes, y la cobertura estructural
puede medirse en términos del porcentaje de interfaces ejercitado por pruebas.
El diseño y la ejecución de pruebas de caja blanca pueden involucrar habilidades o conocimientos
especiales, como la forma en que el código es construido (por ejemplo, para usar herramientas de cobertura
de código), cómo se almacenan los datos (por ejemplo, para evaluar posibles consultas de base de datos), y
cómo utilizar las herramientas de cobertura e interpretar correctamente sus resultados. [1, p. 41]
1.6 Pruebas relacionadas con el cambio (Change-related Testing)
Cuando se realizan cambios en un sistema, ya sea para corregir un defecto o debido a una nueva o cambiante
funcionalidad, se deben realizar pruebas para confirmar que los cambios han corregido el defecto o
implementado la funcionalidad correctamente, y no han causado consecuencias adversas imprevistas. [1, p.
41]
 Pruebas de confirmación: una vez que se soluciona un defecto, el software se puede probar con
todos los casos de prueba que fallaron debido al defecto, que debe volver a ejecutarse en la nueva
versión del software. El software también se puede probar con nuevas pruebas si, por ejemplo, el
defecto era una falta de funcionalidad. Lo mínimo seria ejecutar los pasos para reproducir los fallos
causados por el defecto en la nueva versión del software. El propósito de una prueba de
confirmación es confirmar si el defecto original ha sido arreglado exitosamente
 Pruebas de regresión: es posible que un cambio realizado en una parte del código, ya sea una
corrección u otro tipo de cambio, puede afectar accidentalmente el comportamiento de otras partes
del código, ya sea dentro del mismo componente, en otros componentes del mismo sistema, o
incluso en otros sistemas. Los cambios pueden incluir cambios en el entorno, como una nueva
versión de un sistema operativo o sistema de gestión de bases de datos. Tales efectos secundarios
no deseados se denominan regresiones. Las pruebas de regresión implican la ejecución de pruebas
para detectar dichos efectos secundarios no deseados.

Las pruebas de confirmación y las pruebas de regresión se realizan en todos los niveles de prueba.
Especialmente en los ciclos de vida de desarrollo iterativo e incremental (por ejemplo, Agile), nuevas
características, cambios en las características existentes y la refactorización del código dan como resultado
cambios frecuentes en el código, lo que también requiere pruebas relacionadas con el cambio. Debido a la
naturaleza evolutiva del sistema, las pruebas de confirmación y regresión son muy importantes. Esto es
particularmente relevante para los sistemas de Internet de las cosas donde los objetos individuales (por
ejemplo, dispositivos) son frecuentemente actualizados o reemplazados.
 9

Los conjuntos de pruebas de regresión se ejecutan muchas veces y generalmente evolucionan lentamente,
por lo que las pruebas de regresión son un fuerte candidato para la automatización. La automatización de
estas pruebas debe comenzar al principio del proyecto. [1, p. 41]
IDONEIDAD FUNCIONAL COMO UN FACTOR DE LA CALIDAD DE SOFTWARE
Se pretende mencionar los atributos y pruebas asociadas a la Idoneidad Funcional vista como una
característica de la calidad de software.
1.7 Atributos de la Idoneidad Funcional
La idoneidad funcional representa la capacidad del producto software para proporcionar funciones que
satisfacen las necesidades declaradas e implícitas, cuando el producto se usa en las condiciones
especificadas. Esta característica se subdivide a su vez en las siguientes subcaracterísticas [2, p. 1]:
 Completitud funcional. Grado en el cual el conjunto de funcionalidades cubre todas las tareas y
los objetivos del usuario especificados.
 Corrección funcional. Capacidad del producto o sistema para proveer resultados correctos con el
nivel de precisión requerido.
 Pertinencia funcional. Capacidad del producto software para proporcionar un conjunto apropiado
de funciones para tareas y objetivos de usuario especificados.
1.8 Pruebas asociadas a la Idoneidad Funcional
A continuación se mencionan un conjunto de pruebas asociadas a la idoneidad funcional
1.8.1 Pruebas funcionales (Functional Testing)
 10

Las pruebas funcionales pueden organizarse por niveles. Los niveles de pruebas son grupos de actividades
de pruebas que se organizan y administran juntas. Cada nivel de prueba es una instancia del proceso de
prueba, realizadas en relación con el Software a un nivel dado de desarrollo, desde unidades individuales o
componentes hasta sistemas completos o, en su caso, sistemas de sistemas. Los niveles de prueba están
relacionados con otras actividades dentro del ciclo de vida del desarrollo de software.
Los niveles de prueba utilizados son: [1, p. 30]
 Pruebas de Componentes (Component Testing)
 Pruebas de Integración (Integration Testing)

Pruebas de
Aceptación

Pruebas de Sistema

Pruebas de Integración

Pruebas Unitarias / Pruebas de Componentes

Figura 0-1 Niveles de Pruebas.

Fuente: Propia

 Pruebas de Sistema (System Testing)

 Pruebas de Aceptación (Acceptance Testing)

Los niveles están caracterizados por los siguientes atributos:

 Objetivos específicos
 Bases de prueba
 Objeto de prueba (es decir, lo que se está probando)
 Defectos y fallas típicas
 Enfoques y responsabilidades especificas
 11

Para cada nivel de prueba, se requiere un entorno de prueba adecuado. En las pruebas de aceptación, por
ejemplo, un entorno de prueba similar al de producción es ideal, mientras que en las pruebas de
componentes los desarrolladores suelen utilizar el entorno de desarrollo propio.
1.8.1 Pruebas de Componentes

Objetivos.- Las pruebas de componentes (también conocidas como pruebas de unidad o módulo) se enfocan
en componentes que se pueden probar por separado. Los objetivos de las pruebas de componentes incluyen:
 Reducir el riesgo.
 Verificar si los comportamientos funcionales y no funcionales del componente son los diseñados y
especificados.
 Fomento de la confianza en la calidad del componente.
 Encontrar defectos en el componente.
 Evitar que los defectos se escapen a niveles de prueba más altos

En algunos casos, especialmente en modelos de desarrollo incrementales e iterativos (por ejemplo, Agile)
donde los cambios en el código son continuos, las pruebas automatizadas de regresión de componentes
desempeñan un papel clave en la creación de confianza de que los cambios no han roto los componentes
existentes.
Las pruebas de componentes a menudo se realizan en forma aislada del resto del sistema, dependiendo del
modelo de ciclo de vida de desarrollo del software y el sistema, que pueden requerir objetos simulados,
virtualización de servicios, etc. Las pruebas de componentes pueden cubrir la funcionalidad (por ejemplo,
la corrección de cálculos), características no funcionales (por ejemplo, búsqueda de fugas de memoria) y
propiedades estructurales (por ejemplo, pruebas de decisión). [1, p. 31]
Defectos y fallos típicos.- Ejemplos de defectos y fallas típicos para la prueba de componentes incluyen:
 Funcionalidad incorrecta
 Problemas de flujo de datos
 Código y lógica incorrectos

Los defectos se suelen solucionar tan pronto como se detectan, a menudo sin una gestión formal de los
defectos. Sin embargo, cuando los desarrolladores reportan defectos, esto proporciona información
importante para el análisis de la causa raíz y la mejora de procesos.
Enfoques y responsabilidades específicas.- Las pruebas de componentes generalmente las realiza el
desarrollador que escribió el código, pero al menos requiere acceso al código que se está probando. Los
desarrolladores pueden alternar el desarrollo de componentes con la búsqueda y arreglo de defectos. Los
 12

desarrolladores a menudo escriben y ejecutan pruebas después de haber escrito el código para un
componente.
Sin embargo, especialmente en el desarrollo ágil, escribir casos de prueba de componentes automatizados
puede preceder a la escritura código de aplicación.
Por ejemplo, considere el desarrollo guiado por pruebas (TDD). El desarrollo guiado por pruebas es
altamente iterativo y es basado en ciclos de desarrollo de casos de pruebas automatizadas, y luego
compilación e integración de pequeñas piezas de código, luego, ejecutando las pruebas de componentes,
corrigiendo cualquier problema y volviendo a factorizar el código. Este proceso continúa hasta que el
componente se ha construido completamente y todas las pruebas de componentes pasan. [1, p. 32]
1.8.2 Pruebas de Integración

Objetivos.- Las pruebas de integración se centran en las interacciones entre componentes o sistemas. Los
objetivos de las pruebas de integración incluyen: [1, p. 33]
 Reducir el riesgo
 Verificar si los comportamientos funcionales y no funcionales de las interfaces son como se
diseñaron y especificaron
 Fomento de la confianza en la calidad de las interfaces.
 Encontrar defectos
 Evitar que los defectos se escapen a niveles de prueba más altos

Las pruebas de integración se centran en las interacciones entre los componentes La prueba de integración
de componentes se realiza después de la prueba de componentes, y es generalmente automatizado. En el
desarrollo iterativo e incremental, las pruebas de integración de componentes son usualmente parte del
proceso de integración continua.
Defectos y fallos típicos.- Ejemplos de defectos y fallas típicos para las pruebas de integración de
componentes incluyen: [1, p. 33]
 Datos incorrectos, datos faltantes o codificación de datos incorrecta
 Secuenciación incorrecta o sincronización de llamadas de interfaz
 Desajuste de interfaz
 Fallos en la comunicación entre componentes.
 Fallos de comunicación no manejados o manejados incorrectamente entre componentes
 Suposiciones incorrectas sobre el significado, las unidades o los límites de los datos que se pasan
entre componentes
 13

Enfoques y responsabilidades específicas.- Las pruebas de integración de componentes y las pruebas de

integración de sistemas deben concentrarse en la integración en sí misma. Por ejemplo, si se integra el
módulo A con el módulo B, las pruebas deberían centrarse en la comunicación entre módulos, no la
funcionalidad de los módulos individuales, como debería haber sido cubierto durante las pruebas de
componentes. Si integra el sistema X con el sistema Y, las pruebas deben centrarse en la comunicación
entre los sistemas, no la funcionalidad de los sistemas individuales, ya que eso debería haber sido cubierto
durante la prueba del sistema. Son aplicables los tipos de prueba funcional, no funcional y estructural.
Las pruebas de integración de componentes a menudo son responsabilidad de los desarrolladores. La prueba
de integración del sistema es en general, la responsabilidad de los probadores. Idealmente, los probadores
que realizan pruebas de integración de sistemas deberían comprender la arquitectura del sistema, y debería
haber influido en la planificación de la integración.
Si las pruebas de integración y la estrategia de integración se planifican antes de que se construyan los
componentes o sistemas, esos componentes o sistemas se pueden construir en el orden requerido para las
pruebas más eficientes. Las estrategias de integración sistemática pueden basarse en la arquitectura del
sistema (por ejemplo, de arriba a abajo y de abajo a arriba), tareas funcionales, secuencias de procesamiento
de transacciones, o algún otro aspecto del sistema o componentes. A fin de que simplifique el aislamiento
de defectos y detecte los defectos de manera temprana, la integración normalmente debería ser incremental
(es decir, un pequeño número de componentes o sistemas adicionales a la vez) en lugar del "big bang" (es
decir, integrando todos componentes o sistemas en un solo paso). Un análisis de riesgo de las interfaces
más complejas puede ayudar a enfocar las pruebas de integración.
Cuanto mayor sea el alcance de la integración, más difícil será aislar los defectos de un determinado
componente o sistema, lo que puede llevar a un mayor riesgo y tiempo adicional para la solución de
problemas. [1, p. 34]
1.8.3 Pruebas de Sistema

Objetivos.- Las pruebas del sistema se centran en el comportamiento y las capacidades de todo un sistema
o producto, a menudo considerando las tareas de extremo a extremo que el sistema puede realizar y los
comportamientos no funcionales que exhibe al realizar esas tareas Los objetivos de las pruebas del sistema
incluyen: [1, p. 34]
 Reducir el riesgo
 Verificar si los comportamientos funcionales y no funcionales del sistema son como los diseñados
y especificados
 Validar que el sistema está completo y funcionará como se espera
 14

 Generar confianza en la calidad del sistema en su conjunto

 Encontrar defectos
 Evitar que los defectos se escapen a niveles de prueba o producción más altos

Para ciertos sistemas, verificar la calidad de los datos puede ser un objetivo. Al igual que con la prueba de
componentes y de integración, en algunos casos, las pruebas automatizadas de regresión del sistema
proporcionan la confianza de que los cambios no han roto características existentes. Las pruebas del sistema
a menudo producen información que se utiliza por los stakeholders para tomar decisiones sobre la liberación
del producto.
El entorno de prueba debería corresponder idealmente con el objetivo final o el entorno de producción.
Defectos y fallos típicos.- Los ejemplos de defectos y fallas típicos para las pruebas del sistema incluyen:
[1, p. 35]
 Cálculos incorrectos
 Comportamiento funcional o no funcional del sistema incorrecto o inesperado
 Flujos incorrectos de control y / o datos dentro del sistema
 Fallos al realizar correcta y completamente las funcionales de extremo a extremo
 Fallos del sistema para funcionar correctamente en el (los) entorno(s) de producción
 Falla del sistema para funcionar como se describe en los manuales del usuario y del sistema

Enfoques y responsabilidades específicas.- Las pruebas del sistema deben centrarse en el comportamiento
global de extremo a extremo del sistema en su conjunto. Las pruebas del sistema deben utilizar las técnicas
más apropiadas para el (los) aspecto(s) del sistema a probar. Por ejemplo, se puede crear una tabla de
decisiones para verificar si el comportamiento funcional es como se describe en las reglas de negocio.
Los probadores independientes suelen realizar pruebas de sistema. Defectos en las especificaciones (por
ejemplo, historias de usuarios faltantes, requisitos de negocio incorrectamente establecidos, etc.) pueden
llevar a una falta de comprensión o desacuerdos sobre, el comportamiento esperado del sistema. Tales
situaciones pueden causar falsos positivos y falsos negativos, que causan perdida de tiempo y reducen la
eficacia de detección de defectos, respectivamente. Participación temprana de los probadores en el
refinamiento de las historias de usuario o las actividades de prueba estática, como las revisiones, ayudan a
reducir la incidencia de tales situaciones. [1, p. 35]
1.8.4 Pruebas de Aceptación
 15

Objetivos de las pruebas de aceptación.- Las pruebas de aceptación, al igual que las pruebas del sistema,
generalmente se enfocan en el comportamiento y las capacidades de todo el sistema o producto. Los
objetivos de las pruebas de aceptación incluyen: [1, p. 36]
 Establecer confianza en la calidad del sistema en su conjunto
 Validar que el sistema está completo y funcionará como se espera
 Verificar que los comportamientos funcionales y no funcionales del sistema son los especificados

Las pruebas de aceptación pueden producir información para evaluar la preparación del sistema para su
implementación y uso por parte del cliente (usuario final). Se pueden encontrar defectos durante las pruebas
de aceptación, pero a menudo no es un objetivo encontrar defectos, y encontrar un número significativo de
defectos durante las pruebas de aceptación puede ser considerado en algunos casos un gran riesgo para el
proyecto.
Las formas comunes de pruebas de aceptación incluyen lo siguiente:
 Pruebas de aceptación del usuario (User Acceptance Testing)
 Pruebas de aceptación operacional (Operational Acceptance Testing)
 Pruebas de aceptación contractuales y regulatorias
 Pruebas alfa y beta (Alpha y Beta Testing)

Defectos y fallos típicos.- Ejemplos de defectos típicos para cualquier forma de prueba de aceptación
incluyen: [1, p. 38]
 Los flujos de trabajo del sistema no cumplen con los requisitos del negocio o del usuario
 Las reglas de negocio no se implementan correctamente.
 El sistema no cumple con los requisitos contractuales o reglamentarios.
 Fallos no funcionales, como vulnerabilidades de seguridad, eficiencia de rendimiento inadecuada
bajo cargas elevadas u operación incorrecta en una plataforma compatible

Enfoques y responsabilidades específicas.- Las pruebas de aceptación a menudo son responsabilidad de los
clientes, usuarios comerciales, propietarios de productos o los operadores de un sistema y otras partes
interesadas también pueden estar involucrados.
Las pruebas de aceptación a menudo se consideran el último nivel de prueba en un ciclo de vida de
desarrollo secuencial, pero también puede ocurrir en otros momentos, por ejemplo: [1, p. 39]
 Las pruebas de aceptación de un producto de software pueden ocurrir cuando está instalado o
integrado
 16

 Las pruebas de aceptación de una nueva mejora funcional pueden ocurrir antes de las pruebas del
sistema

En el desarrollo iterativo, los equipos del proyecto pueden emplear varias formas de pruebas de aceptación
durante y al final de cada iteración, como las que se centran en la verificación de una nueva característica
con respecto a sus criterios de aceptación y aquellos enfocados en validar que una nueva característica
satisface las necesidades de los usuarios. Además, pruebas alfa y beta pueden ocurrir, ya sea al final de cada
iteración, después de la finalización de cada iteración, o después de una serie de iteraciones. Pruebas de
aceptación del usuario, pruebas de aceptación operacional, pruebas de aceptación regulatoria y pruebas de
aceptación contractual también pueden ocurrir, ya sea al final de cada iteración, después de la finalización
de cada iteración, o después de una serie de iteraciones.
1.8.5 Pruebas de Regresión (Regression Testing)

Cuando se realizan modificaciones o cambios en la aplicación o incluso cuando se realiza un pequeño

cambio en el código, puede ocasionar problemas inesperados. Junto con los nuevos cambios, es muy
importante probar si la funcionalidad existente está intacta o no. Esto se puede lograr ejecutando pruebas
de regresión. [3]
 El propósito de las pruebas de regresión es encontrar los errores que pueden introducirse
accidentalmente debido a los nuevos cambios o modificaciones.
 Durante la prueba de confirmación, el defecto se corrigió y esa parte de la aplicación comenzó a
funcionar según lo previsto. Pero puede haber una posibilidad de que la solución haya introducido
o descubierto un defecto diferente en otro lugar del software. La forma de detectar estos "efectos
secundarios inesperados" de las correcciones es realizar pruebas de regresión.
 Esto también asegura que los errores encontrados anteriormente NO sean reproducibles.
 Por lo general, las pruebas de regresión las realizan las herramientas de automatización, ya que para
corregir el defecto, la misma prueba se lleva a cabo una y otra vez, y será muy tedioso y lento
hacerlo manualmente.
 Durante las pruebas de regresión, los casos de prueba se priorizan en función de los cambios
realizados en la función o el módulo en la aplicación. La característica o el módulo donde se
realizan los cambios o las modificaciones se toma como prioridad para la prueba.
 Esta prueba se vuelve muy importante cuando hay modificaciones continuas o mejoras realizadas
en la aplicación o producto. Estos cambios o mejoras NO deberían introducir nuevos problemas en
el código probado existente.
 17

 Esto ayuda a mantener la calidad del producto junto con los nuevos cambios en la aplicación.

EFICIENCIA DE DESEMPEÑO COMO UN FACTOR DE LA CALIDAD DE

SOFTWARE
Se pretende mencionar los atributos y pruebas asociadas a la Eficiencia de Desempeño vista como una
característica de la calidad de software.
1.9 Atributos de la Eficiencia de Desempeño
Esta característica representa el desempeño relativo a la cantidad de recursos utilizados bajo determinadas
condiciones. Esta característica se subdivide a su vez en las siguientes subcaracterísticas [2, p. 1]:
 Comportamiento temporal. Los tiempos de respuesta y procesamiento y los ratios
de throughput de un sistema cuando lleva a cabo sus funciones bajo condiciones determinadas en
relación con un banco de pruebas (benchmark) establecido.
 Utilización de recursos. Las cantidades y tipos de recursos utilizados cuando el software lleva a
cabo su función bajo condiciones determinadas.
 Capacidad. Grado en que los límites máximos de un parámetro de un producto o sistema de
software cumplen con los requisitos.
1.10 Pruebas asociadas a la Eficiencia de Desempeño
Entre los diversos tipos de pruebas de desempeño generalmente mencionadas en el entorno de prueba, hay
algunos nombres estándar que suenan familiares con diferentes conceptos derivados de los nombres de
varias herramientas.
A continuación se encuentran algunos de los tipos más comunes de pruebas de rendimiento, con una
explicación de las diferencias entre ellos: [4]
8.2.1 Pruebas de Carga (Load Testing)
La prueba de carga es un subtipo especial de prueba de rendimiento relacionado con el comportamiento del
producto bajo condiciones de carga especificadas.
La carga tiene dos aspectos, a saber:
 Múltiples usuarios con números realistas ordinarios de usuarios
 Grande, aunque todavía realista número (volumen) de usuarios concurrentes

Las cargas que se espera que el producto pueda manejar y las aplicaciones y los tiempos de respuesta deben
expresarse en los requisitos de carga. Tenemos que pensar en cargar el sistema desde el principio durante
la especificación de requisitos. Es importante lograr un equilibrio en los requisitos de carga para que estén
dentro de lo razonable, pero aun teniendo en cuenta el futuro.
 18

Las pruebas de carga pueden ser bastante costosas. A veces se tiene que cuestionar los requisitos: ¿son
realistas? Para mantener los gastos bajo control en las pruebas de carga, se debe usar el análisis de riesgos
para priorizar y planificar pruebas de tareas. Existen herramientas que se pueden usar para generar y / o
simular cargas. Las pruebas de carga y las pruebas de rendimiento a veces están relacionadas en el sentido
que la carga puede ser parte de las especificaciones de condición para los requisitos rendimiento. [5, p. 266]
8.2.2 Pruebas de Estrés (Stress testing)
El estrés es una expresión de la capacidad del producto para manejar condiciones extremas de acciones. Al
planificar los requisitos para el manejo del estrés, es una buena idea recordar la ley de Murphy:
"Si algo puede ir mal lo hará." O "Lo impensable a veces sucede de todos modos".
En los requisitos de manejo del estrés, nos enfrentamos al riesgo del sistema de no ser capaz de manejar
situaciones extremas. Estamos lidiando con riesgos como: personas, dinero, datos y el medio ambiente,
riesgos que se materializarán si el sistema no puede hacer frente a una situación de estrés.
El manejo del estrés está estrechamente relacionado con otras áreas no funcionales. Ahí la relación entre la
fiabilidad y el estrés es que el estrés analiza la fiabilidad en situaciones extremas. Con respecto a la
usabilidad, el estrés trata de fallas de manejo con gracia, para que el usuario no quede a oscuras sobre lo
que está sucediendo. El estrés en relación con la carga se refiere a la carga pico en un lapso corto de tiempo.
Cuando se trabaje con requisitos relacionados con el estrés, se tendrá que pensar sobre lo que puede salir
mal. Para los datos esto podría ser en situaciones con demasiados datos, muy poca información o datos
defectuosos. Para el uso, podría ser demasiados usuarios simultáneamente, uso prolongado, o tal vez dejar
caer el sistema o parte del sistema. Los eventos externos como la falla de energía también pueden causar
estrés en el sistema. El manejo del estrés es particularmente importante para las aplicaciones web, como
productos electrónicos y e-business; en telecomunicaciones, seguridad y protección crítica de sistemas; y
sistemas en tiempo real.
El estrés en un sistema puede ser manejado en gran medida por un programa defensivo. Esto significa que
las pruebas de estrés pueden comenzar temprano con la revisión del diseño y código.
Las pruebas de estrés deben tener una alta cobertura del "producto". Incluso si con algo de estrés la
prevención funciona en un lugar, puede que no funcione en otra parte del sistema.
Las pruebas de estrés deben ser imaginativas, pero por otro lado no deberían ir por la borda. Al planear las
pruebas de estrés, necesitamos hacer un análisis de riesgo. Incluso lo impensable puede ocurrir muy
raramente para justificar una prueba. [5, p. 267]
8.2.3 Pruebas de Resistencia (Endurance/Soak Testing)
 19

Las pruebas de resistencia se refieren a ejecutar un sistema con altos niveles de carga durante periodos de
tiempo prolongados. Una prueba de resistencia normalmente ejecutaría varias veces más transacciones en
un día completo (o noche) de lo que se esperaría en un día ocupado para identificar cualquier problema de
rendimiento que aparece después de que un gran número de transacciones se han ejecutado. Es posible que
un sistema pueda dejar de trabajar después de que se haya procesado una cierta cantidad de transacciones a
fugas de memoria u otros defectos. Las pruebas de resistencia brindan la oportunidad de identificar tales
defectos, mientras que las pruebas de carga y las pruebas de estrés pueden no encontrar tales problemas
debido a su relativamente corta duración. [6, p. 223]
8.2.4 Pruebas de Aceleración (Throttle Testing)
La prueba de aceleración es una simulación de la carga, con velocidad de conexión limitada de usuarios
virtuales (todos ellos o solo un grupo) para analizar el tiempo de respuesta obtenido por aquellos usuarios
conectados a través de redes de menor velocidad (3G, áreas distantes, a través de Internet, etc.) Los
simuladores de velocidad o modeladores de tráfico se usan en estas pruebas, además de algunas
herramientas que tienen esta funcionalidad incluida. [7]
8.2.5 Pruebas Pico (Peak Testing)
Las pruebas de pico se usan para analizar el comportamiento del sistema cuando se expone a picos de
intensidad mezclados con carga normal, mostrando la recuperación luego de la carga incrementada. Este
tipo de situaciones ocurren en realidad, por lo que es interesante analizar el comportamiento del sistema en
tales casos. [4]
Las pruebas pico se usan para verificar cómo funciona su servidor durante los períodos de mayor actividad.
La prueba máxima es similar a la prueba de resistencia, pero con una carga mucho más pesada y una
duración más corta. [8]
8.2.6 Pruebas de Escalabilidad (Scalability Testing)
La escalabilidad es la capacidad del producto para cumplir los requisitos de eficiencia futuros.
Esto no es realmente una prueba, ya que, naturalmente, no podemos realizarla contra los existentes
requisitos. Esta técnica es más una evaluación de escalabilidad; a lo que apuntamos es averiguar cómo
reacciona el producto al crecimiento en, por ejemplo, el número de usuarios o cantidades en datos. La
capacidad del producto para mantener sus requisitos de rendimiento también puede ser monitoreada de
forma continua durante el despliegue para proporcionarnos la oportunidad de actuar antes de que el
producto se rompa bajo la carga. [5, p. 268]
 20

La siguiente figura muestra una forma de representar algunas de estas pruebas de rendimiento (prueba de
carga, prueba de resistencia, prueba de estrés y prueba de pico), y cómo sería la gráfica de usuarios virtuales
activos durante todo el tiempo de prueba.

Figura 0-1 Representación de algunos tipos de pruebas de rendimiento.

Fuente: Tests, https://abstracta.us/blog/performance-testing/types-of-performance-tests/

COMPATIBILIDAD COMO UN FACTOR DE LA CALIDAD DE SOFTWARE

Se pretende mencionar los atributos y pruebas asociadas a la Compatibilidad vista como una característica
de la calidad de software.
1.11 Atributos de la Compatibilidad
Capacidad de dos o más sistemas o componentes para intercambiar información y/o llevar a cabo sus
funciones requeridas cuando comparten el mismo entorno de hardware o software. Esta característica se
subdivide a su vez en las siguientes subcaracterísticas [2, p. 2]:
 Coexistencia. Capacidad del producto para coexistir con otro software independiente, en un
entorno común, compartiendo recursos comunes sin detrimento.
 Interoperabilidad. Capacidad de dos o más sistemas o componentes para intercambiar
información y utilizar la información intercambiada.
1.12 Pruebas asociadas a la Compatibilidad
A continuación se mencionan algunos tipos de pruebas asociadas a asegurar la compatibilidad del sistema.
 21

1.12.1 Pruebas de Conformidad (Compliance Testing)

Es un tipo de prueba de software no funcional con las siguientes características: [9]

 Se relaciona con los estándares de TI seguidos por la compañía y es la prueba realizada para
encontrar las desviaciones de los estándares prescritos por la compañía.
 Determina si estamos implementando y cumpliendo los estándares definidos.
 Debemos tener cuidado al hacer esta prueba. ¿Hay algún inconveniente en la implementación de
estándares en nuestro proyecto y es necesario hacer análisis para mejorar los estándares?
 Es básicamente una auditoría de un sistema llevado a cabo contra un criterio conocido.
1.12.2 Pruebas de Compatibilidad (Compatibility testing)

La prueba de compatibilidad es un tipo de prueba de software utilizada para garantizar la compatibilidad

del sistema / aplicación / sitio web creado con otros objetos, como otros navegadores web, plataformas de
hardware, usuarios (en caso de que sea un tipo de requisito muy específico, como un usuario que habla y
puede leer solo un idioma en particular), sistemas operativos, etc. Este tipo de prueba ayuda a determinar
qué tan bien funciona un sistema en un entorno particular que incluye hardware, red, sistema operativo y
otro software, etc. [10]
1.12.3 Prueba de Interoperabilidad (Interoperability Testing)

Las características de las pruebas de Interoperabilidad son: [11, p. 38]

 Comprobar si el software de la prueba interactúa correctamente con otro programa, dispositivo o
sistema externo.
 Prueba de interoperabilidad simple, es como una prueba de funcionamiento: prueba los dos
sistemas juntos. ¿Se portan bien juntos?
 Para agregar profundidad a esta prueba, puedes añadir pruebas de diseño que se enfocan
específicamente en formas en las que sospechas que el software puede no funcionar correctamente
con el otro programa, dispositivo o sistema.
 Un encargado centrado en la interoperabilidad probablemente probará desde una lista de problemas
comunes.
1.12.4 Pruebas de Conversion (Convertion Testing)

Las pruebas de conversión son un tipo de prueba en la que un formato de datos se convierte a otro formato
para que la aplicación pueda usar correctamente el nuevo formato de datos.
 22

La prueba de conversión autentica la corrección del formato convertido. La conversión de datos es tan
simple como la conversión de texto.
Considere un ejemplo si queremos probar la conversión de documentos de Microsoft Word a páginas
HTML, entonces no necesitamos verificar las páginas html con navegadores como Firefox u otros
navegadores. Necesitamos verificar las páginas html con las especificaciones W3C.
Cada computadora tiene su propia forma de manejar los programas de diferentes maneras. Cuando se
cambia cualquiera de las variables del programa, los datos deben convertirse a otro formato diferente para
que los datos recién formados puedan ser utilizados por diferentes programas de computadora o sistema
operativo. [12]
Ejemplos de prueba de conversión:
 Conversión del lenguaje de programación.
 Conversión de archivo de base de datos
 Conversión de documentos.
 Conversión de medios como conversión de audio, conversión de video, conversión de imagen.

USABILIDAD COMO UN FACTOR DE LA CALIDAD DE SOFTWARE

Se pretende mencionar los atributos y pruebas asociadas a la Usabilidad vista como una característica de
la calidad de software.
1.13 Atributos de la Usabilidad
Capacidad del producto software para ser entendido, aprendido, usado y resultar atractivo para el usuario,
cuando se usa bajo determinadas condiciones. Esta característica se subdivide a su vez en las siguientes
subcaracterísticas [2, p. 2]:
 Capacidad para reconocer su adecuación. Capacidad del producto que permite al usuario
entender si el software es adecuado para sus necesidades.
 Capacidad de aprendizaje. Capacidad del producto que permite al usuario aprender su aplicación.
 Capacidad para ser usado. Capacidad del producto que permite al usuario operarlo y controlarlo
con facilidad.
 Protección contra errores de usuario. Capacidad del sistema para proteger a los usuarios de hacer
errores.
 Estética de la interfaz de usuario. Capacidad de la interfaz de usuario de agradar y satisfacer la
interacción con el usuario.
 23

 Accesibilidad. Capacidad del producto que permite que sea utilizado por usuarios con
determinadas características y discapacidades.
1.14 Pruebas asociadas a la Usabilidad
Entre las pruebas asociadas a la usabilidad podemos mencionar las siguientes.
1.14.1 Pruebas de Experiencia de Usuario (UX Testing)

En este subtitulo hay una breve lista de los métodos comunes de prueba de la experiencia del usuario y sus
características. Todos estos pueden caer ampliamente bajo el término "prueba de usuario", aunque eso ha
tomado una connotación más específica con la proliferación de softwares de prueba de usuario remoto.
Prueba moderada del usuario
La prueba del usuario es básicamente probar un producto o experiencia con usuarios reales. Los usuarios
se presentan tradicionalmente con una serie de tareas para completar y medir en su efectividad al hacerlo.
Hay dos tipos principales:
 Moderado
 No moderado

La prueba de usuario moderada trata cuando el usuario está siendo observado directamente por un
investigador en tiempo real. Podría ser en persona o remotos, pero están siguiendo al usuario a medida que
realizan las tareas.
En una prueba de usuario moderada, puede guiar a los usuarios a través de tareas, responder preguntas y
escuchar sus comentarios en tiempo real. Una prueba de usuario moderada tiene el beneficio de una mayor
flexibilidad y conexión, pero tiene la desventaja de que posiblemente esté influenciada por el sesgo.
Prueba de usuario no moderada
La prueba de usuario no moderada es, por supuesto, muy similar a la moderada, pero se hace prescribiendo
una lista predeterminada de tareas para que complete un usuario y permitiéndole completarla en su tiempo.
Son muchas las empresas que optan por este formato porque es barato, es escalable y no se pueden sesgar
los resultados.
Pero también hay algunos contras.
A menos que sea muy concienzudo al reclutar candidatos para la prueba de usuario, puede obtener algunas
pruebas de usuario de mala calidad, lo que lo lleva a creer cosas incorrectas sobre su experiencia de usuario.
[13]
1.14.2 Pruebas de Accesibilidad (Accessibility Testing)
 24

La prueba de accesibilidad es una forma especial de prueba de usabilidad que se centra en personas que
tienen necesidades o restricciones particulares que afectan la forma en que usan la tecnología. Hay varios
estándares y regulaciones que pueden ser útiles en el diseño de pruebas de usabilidad y en la detección de
defectos relevantes. Por supuesto, si está obligado a cumplir, estas normas y regulaciones no son solo útiles;
son obligatorias
La accesibilidad debe diseñarse en el sistema. Intentando adaptar una interfaz de usuario para ser accesible
después de su construcción es poco probable que funcione.
Dado que la accesibilidad es básicamente una forma especial de prueba de usabilidad, como las pruebas de
usabilidad, debe considerarse una prueba de validación. También al igual que las pruebas de usabilidad,
solo puede ocurrir una vez que el sistema está suficientemente desarrollado para realizar tareas reales, lo
que generalmente significa que sucede durante las pruebas de integración de componentes, las pruebas del
sistema y las pruebas de aceptación del usuario. [14, p. 225]
1.14.3 Pruebas de localización e internalización (Localization and Internalization
Testing)

Son un tipo de prueba no funcional con las siguientes características: [15]

 La internacionalización es un proceso de diseño de una aplicación de software para que pueda
adaptarse a varios idiomas y regiones sin ningún cambio. En Internalization Testing, el probador
verifica si la aplicación se adapta con éxito a otros idiomas y regiones sin cambios.
 Considerando que la localización es un proceso de adaptación de software internacionalizado para
una región o idioma específico al agregar componentes específicos locales y traducir texto. En las
pruebas de localización, el probador verifica si la aplicación se muestra y se comporta como se
espera después de localizar la aplicación.

FIABILIDAD COMO UN FACTOR DE LA CALIDAD DE SOFTWARE

Se pretende mencionar los atributos y pruebas asociadas a la Fiabilidad vista como una característica de la
calidad de software.
1.15 Atributos de la Fiabilidad
Capacidad de un sistema o componente para desempeñar las funciones especificadas, cuando se usa bajo
unas condiciones y periodo de tiempo determinados. Esta característica se subdivide a su vez en las
siguientes subcaracterísticas [2, p. 2]:
 25

 Madurez. Capacidad del sistema para satisfacer las necesidades de fiabilidad en condiciones
normales.
 Disponibilidad. Capacidad del sistema o componente de estar operativo y accesible para su uso
cuando se requiere.
 Tolerancia a fallos. Capacidad del sistema o componente para operar según lo previsto en
presencia de fallos hardware o software.
 Capacidad de recuperación. Capacidad del producto software para recuperar los datos
directamente afectados y reestablecer el estado deseado del sistema en caso de interrupción o fallo.
1.16 Pruebas asociadas a la Fiabilidad
Entre las pruebas asociadas a la fiabilidad tenemos las siguientes.
1.16.1 Pruebas de Recuperación (Recovery Testing)

La capacidad de recuperación es la capacidad del producto para restablecer su nivel requerido de

rendimiento. Y recuperar los datos directamente afectados después de una falla.
Esto puede cubrir aspectos como: [5, p. 264]
 Tiempo de inactividad después de una falla de severidades especificadas en períodos específicos
de tiempo para partes específicas del sistema
 Tiempo de actividad durante períodos de tiempo especificados para partes específicas del sistema
durante un período de tiempo especificado
 Tiempo de inactividad durante períodos de tiempo especificados para partes específicas del sistema
durante un período de tiempo especificado
 Tiempo para restablecer datos consistentes en caso de falla que cause datos inconsistentes
 Instalaciones de respaldo integradas
 Necesidad de duplicación (máquina de reserva)
 Redundancia en el sistema de software
 "Consejo" en relación con el reinicio
1.16.2 Pruebas de Recuperación de Desastres (Disaster Recovery Testing)

Este es un proceso para verificar el éxito de los procedimientos de restauración que se ejecutan después de
que ocurre una falla o interrupción crítica de TI. Esto podría incluir las siguientes pruebas:
 ¿Qué sucede con la carga de trabajo si parte de la infraestructura deja de estar disponible por algún
motivo?
 ¿Cuánto tiempo lleva recuperar datos si ocurre una corrupción o pérdida de datos?
 26

 ¿Cómo funciona la aplicación si parte de la red se cae?

Este tipo de prueba a veces se lleva a cabo junto con la prueba de carga. Las pruebas de recuperación de
desastres son mucho más realistas si las pruebas se llevan a cabo mientras la aplicación está ocupada
atendiendo una carga de trabajo del usuario. [16]
SEGURIDAD COMO UN FACTOR DE LA CALIDAD DE SOFTWARE
Se pretende mencionar los atributos y pruebas asociadas a la Seguridad vista como una característica de la
calidad de software.
1.17 Atributos de la Seguridad
Capacidad de protección de la información y los datos de manera que personas o sistemas no autorizados
no puedan leerlos o modificarlos. Esta característica se subdivide a su vez en las siguientes
subcaracterísticas [2, p. 3]:
 Confidencialidad. Capacidad de protección contra el acceso de datos e información no
autorizados, ya sea accidental o deliberadamente.
 Integridad. Capacidad del sistema o componente para prevenir accesos o modificaciones no
autorizados a datos o programas de ordenador.
 No repudio. Capacidad de demostrar las acciones o eventos que han tenido lugar, de manera que
dichas acciones o eventos no puedan ser repudiados posteriormente.
 Responsabilidad. Capacidad de rastrear de forma inequívoca las acciones de una entidad.
 Autenticidad. Capacidad de demostrar la identidad de un sujeto o un recurso.
1.18 Pruebas asociadas a la Seguridad
La seguridad es un tema candente hoy en día ya que cada vez más empresas están tomando medidas para
evitar infracciones de seguridad. Algunas de las pruebas que analizan estos atributos de seguridad son los
siguientes:
1.18.1 Pruebas de Penetración (Penetration Testing)

La prueba de penetración (también llamada Pen Testing) es la práctica de probar un sistema de

computadora, red o aplicación web para encontrar vulnerabilidades que un atacante podría explotar.
Las pruebas de penetración se pueden automatizar con aplicaciones de software o se pueden realizar
manualmente. De cualquier manera, el proceso incluye la recopilación de información sobre el objetivo
antes de la prueba (reconocimiento), la identificación de posibles puntos de entrada, el intento de entrar
(virtualmente o de hecho) y el informe de los hallazgos.
 27

El objetivo principal de las pruebas de penetración es determinar las debilidades de seguridad. Una prueba
de penetración también se puede utilizar para probar el cumplimiento de la política de seguridad de una
organización, la conciencia de seguridad de los empleados y la capacidad de la organización para identificar
y responder a incidentes de seguridad.
Las pruebas de penetración a veces se llaman ataques de White Hat porque en una prueba de penetración,
los buenos intentan entrar.
Las estrategias de prueba de penetración incluyen: [17]
Pruebas dirigidas
Las pruebas dirigidas las realiza el equipo de TI de la organización y el equipo de pruebas de penetración
que trabajan en conjunto. A veces se lo conoce como un enfoque de "lights-turned-on" porque todos pueden
ver que la prueba se lleva a cabo.
Pruebas externas
Este tipo de prueba de penetración se dirige a los servidores o dispositivos visiblemente externos de una
empresa, incluidos los servidores de nombres de dominio (DNS), servidores de correo electrónico,
servidores web o firewalls. El objetivo es averiguar si un atacante externo puede entrar y qué tan lejos
pueden entrar una vez que hayan obtenido acceso.
Pruebas internas
Esta prueba imita un ataque interno detrás del firewall por un usuario autorizado con privilegios de acceso
estándar. Este tipo de prueba es útil para estimar cuánto daño podría causar un empleado descontento.
Pruebas a ciegas
Una estrategia de prueba ciega simula las acciones y procedimientos de un atacante real al limitar
severamente la información dada a la persona o equipo que está realizando la prueba de antemano. Por lo
general, solo se puede dar el nombre de la compañía. Debido a que este tipo de prueba puede requerir una
cantidad considerable de tiempo para el reconocimiento y puede llegar a ser costoso.
Prueba doblemente ciega
La prueba doblemente ciega toma la prueba ciega y la lleva un paso más allá. En este tipo de prueba, solo
una o dos personas dentro de la organización pueden estar al tanto de que se está realizando una prueba.
Las pruebas doblemente ciegas pueden ser útiles para probar la supervisión de seguridad de una
organización y la identificación de incidentes, así como sus procedimientos de respuesta.
1.18.2 Pruebas de Vulnerabilidad (Vulnerability Testing)

Las pruebas de vulnerabilidad son una técnica de prueba de software realizada para evaluar la cantidad de
riesgos involucrados en el sistema con el fin de reducir la probabilidad del evento. [18]
 28

Prueba de vulnerabilidad - Lista de verificación:

 Verifique la fortaleza de la contraseña ya que proporciona cierto grado de seguridad.
 Verifique los controles de acceso con los sistemas operativos / tecnología adoptados.
 Verifica cuán fácilmente el sistema puede ser tomado por los atacantes en línea.
 Evalúa el nivel de seguridad de los datos del sistema.
 Comprueba si la configuración del sistema o los archivos de configuración de la aplicación están
protegidos.
 Comprueba si el sistema permite al usuario ejecutar secuencias de comandos maliciosas.

Prueba de vulnerabilidad - Métodos:

 Pruebas activas y pasivas
 Red y pruebas distribuidas
 Verificar el acceso al archivo / sistema
1.18.3 Hackeo Ético (Ethical Hacking)

El hacker ético y hackeo ético son términos utilizados para describir el hackeo realizado por una empresa
o individuo para ayudar a identificar amenazas potenciales en una computadora o red. Un hacker ético
intenta eludir la seguridad del sistema y buscar cualquier punto débil que pueda ser explotado por hackers
malintencionados. Esta información luego es utilizada por la organización para mejorar la seguridad del
sistema, en un esfuerzo por minimizar o eliminar cualquier posible ataque. [19]
1.18.4 Análisis Estático (Static Analysis)

El análisis estático es un tipo de prueba donde, a diferencia de las pruebas dinámicas, el código en el análisis
estático NO se ejecuta.
Las pruebas estáticas, especialmente de código, generalmente se realizan con la (s) herramienta (s), pero lo
único que se ejecuta durante el análisis estático es la herramienta.
Tradicionalmente se han realizado pruebas estáticas en código, pero aquí está también se expande a la
arquitectura.
Muchas herramientas dedicadas al análisis estático están disponibles en el mercado. Sus capacidades varían
mucho y dependen mucho de la codificación e idioma. Algunas herramientas de desarrollo estándar, como
compiladores o vinculadores, son capaces de realizar un análisis estático limitado. [5, p. 223]
Las técnicas de análisis estático para el código son:
 Análisis del flujo de control
 Análisis del flujo de datos
 29

 Cumplimiento de estándares
 Cálculo de métricas de código

MANTENIBILIDAD COMO UN FACTOR DE LA CALIDAD DE SOFTWARE

Se pretende mencionar los atributos y pruebas asociadas a la Mantenibilidad vista como una característica
de la calidad de software.
1.19 Atributos de la Mantenibilidad
Esta característica representa la capacidad del producto software para ser modificado efectiva y
eficientemente, debido a necesidades evolutivas, correctivas o perfectivas. Esta característica se subdivide
a su vez en las siguientes subcaracterísticas [2, p. 3]:
 Modularidad. Capacidad de un sistema o programa de ordenador (compuesto de componentes
discretos) que permite que un cambio en un componente tenga un impacto mínimo en los demás.
 Reusabilidad. Capacidad de un activo que permite que sea utilizado en más de un sistema software
o en la construcción de otros activos.
 Analizabilidad. Facilidad con la que se puede evaluar el impacto de un determinado cambio sobre
el resto del software, diagnosticar las deficiencias o causas de fallos en el software, o identificar las
partes a modificar.
 Capacidad para ser modificado. Capacidad del producto que permite que sea modificado de
forma efectiva y eficiente sin introducir defectos o degradar el desempeño.
 Capacidad para ser probado. Facilidad con la que se pueden establecer criterios de prueba para
un sistema o componente y con la que se pueden llevar a cabo las pruebas para determinar si se
cumplen dichos criterios.
1.20 Pruebas asociadas a la Mantenibilidad
Las pruebas que están asociadas con la mantenibilidad incluyen revisión de pares, análisis estático, para lo
cual, como ejemplo, podríamos usar la herramienta, SonarQube y/o una verificación similar.
PORTABILIDAD COMO UN FACTOR DE LA CALIDAD DE SOFTWARE

Se pretende mencionar los atributos y pruebas asociadas a la Portabilidad vista como una característica de
la calidad de software.
 30

1.21 Atributos de la Portabilidad

Capacidad del producto o componente de ser transferido de forma efectiva y eficiente de un entorno
hardware, software, operacional o de utilización a otro. Esta característica se subdivide a su vez en las
siguientes subcaracterísticas [2, p. 3]:
 Adaptabilidad. Capacidad del producto que permite ser adaptado de forma efectiva y eficiente a
diferentes entornos determinados de hardware, software, operacionales o de uso.
 Capacidad para ser instalado. Facilidad con la que el producto se puede instalar y/o desinstalar
de forma exitosa en un determinado entorno.
 Capacidad para ser reemplazado. Capacidad del producto para ser utilizado en lugar de otro
producto software determinado con el mismo propósito y en el mismo entorno.
1.22 Pruebas asociadas a la Portabilidad
Las pruebas de portabilidad están diseñadas para asegurar la calidad de los atributos que forman parte de
esta característica de la calidad de software.
1.22.1 Pruebas de Portabilidad (Portability Testing)

El ciclo de desarrollo iterativo e incremental implica que las pruebas de portabilidad se realizan
regularmente de forma iterativa e incremental.
Las pruebas de portabilidad deben automatizarse si se realizan pruebas de regresión adecuadas.
Los objetivos de la prueba de portabilidad son:
 Validar parcialmente el sistema (es decir, para determinar si cumple con sus requisitos de
portabilidad):
o Determine si el sistema puede ser portado a cada uno de sus entornos requeridos:
 Hardware, memoria ram y espacio en disco
 Procesador de hardware y velocidad del procesador
 Resolución del monitor
 Sistema operativo, arquitectura y versión
 Marca y versión del navegador
o Determinar si la apariencia de las páginas web es similar y funcional en los distintos tipos
de navegadores y sus versiones.
 Causar fallas relacionadas con los requisitos de portabilidad que ayudan a identificar defectos que
no se encuentran de manera eficiente durante las pruebas de unidad e integración.
 31

 Informar estos fallos a los equipos de desarrollo para que los defectos asociados se puedan
solucionar.
 Ayudar a determinar en qué medida el sistema está listo para el lanzamiento.
 Ayudar a proporcionar métricas de estado del proyecto (por ejemplo, porcentaje de rutas de casos
de uso probadas con éxito).
 Proporcionar información sobre el esfuerzo de análisis de tendencias de defectos.

Las pruebas de portabilidad incluyen pruebas para: [20]

Instalabilidad: las pruebas de instabilidad se realizan en el software utilizado para instalar otro software
en su entorno objetivo.
Coexistencia o compatibilidad: la coexistencia es la capacidad del producto de software para coexistir con
otros productos de software independientes en entornos comunes que comparten recursos comunes.
Adaptabilidad: la adaptabilidad es la capacidad del producto de software para adaptarse a diferentes
entornos específicos sin aplicar acciones o medios distintos de los previstos para este fin para el sistema.
Reemplazabilidad: la capacidad de reemplazo es la capacidad del producto para ser utilizado en lugar de
otro producto especificado para el mismo propósito en el mismo entorno.
Ejemplos de pruebas de portabilidad de una aplicación que debe ser portátil a través de múltiples:
 Plataformas de hardware (incluidos clientes, servidores, dispositivos de conectividad de red,
dispositivos de entrada y dispositivos de salida).
 Sistemas operativos (incluidas versiones y service packs).
 Navegadores (incluidos ambos tipos y versiones).
 33

CONCLUSIONES

Todos los factores mencionados a lo largo de la monografía forman la Rueda del Software Testing. Algo
muy importante a tener en cuenta, es que se dijo al principio que la calidad es la suma ponderada de los
factores de calidad, pero uno no debe olvidar que la calidad es subjetiva. La subjetividad está en definir el
peso de cada uno de los factores. Cada usuario, grupo de usuarios, mercado objetivo, etc. pesarán cada
factor de manera diferente. Por ejemplo, para un usuario, puede ser fundamental que sea fácil de entender
la aplicación (simple, amigable para el usuario) y siempre que satisfaga ese requisito, es posible que no le
importe si se ejecuta un poco más lento. Entonces, puede haber otros usuarios que ni siquiera consideren
utilizar una aplicación si no se ejecuta lo suficientemente rápido ni utiliza un consumo mínimo de recursos.
Siempre habrá variaciones dentro de los tipos de usuarios, a quienes se debe tener en cuenta al momento de
desarrollar y probar el software. Por ejemplo, un tester se preocupa por los diferentes aspectos de calidad
cuando se diseña para niños, adolescentes, el público en general, los ancianos, etc. y en qué contextos se
usará: en la calle, la oficina, el hogar, etc. Los testers tienen el desafío de mirar la rueda de pruebas y
determinar qué pruebas enfocar más, de acuerdo con el peso de los diferentes factores que los usuarios les
asignarán.
Se puede mencionar como ejemplos los programas de contabilidad donde el factor de confiabilidad es uno
de los más importantes y no tanto así el de usabilidad. Otro ejemplo podría ser el software para gestión de
flotas, en esta área de trabajo la portabilidad toma un rol más importante que otros factores. En los sistemas
de Help Desk la compatibilidad es un factor con mayor relevancia que el resto. En las herramientas de
Inteligencia de Negocios, la seguridad toma un papel primordial debido a la cantidad y el tipo de
información que es manejado. En los sistemas telefónicos la performance es vital debido a la gran cantidad
de usuarios y constante flujo de peticiones que manejan estos sistemas. Por ultimo podemos mencionar al
software del área de la medicina donde se requiere una confiabilidad muy alta, debido a que estos sistemas
se usan en pacientes que podrían sufrir algún percance si ocurriese una falla.
En la siguiente figura se muestra una gráfica que engloba todos los factores y tipos de pruebas hablados en
la presente monografía.
 34

Figura 0-1 Representación de la rueda del software testing

Fuente https://abstracta.us/blog/software-testing/the-software-testing-wheel/
 35

Bibliografía

[1] ISTQB, Certified Tester Foundation Level Syllabus (v. 2018), 2108.

[2] ISO 25010, “ISO 25000 Software product quality,” 2018. [Online]. Available:

https://iso25000.com/index.php/en/iso-25000-standards/iso-25010.

[3] T. QA, “What is Regression Testing in Software,” [Online]. Available:

http://istqbexamcertification.com/what-is-regression-testing-in-software/.

[4] S. Palamarchuk, “Abstracta,” 2016. [Online]. Available:

https://abstracta.us/blog/performance-testing/types-of-performance-tests/.

[5] A. M. J. Hass, Guide to Advanced Software Testing, Artech House, 2008.

[6] J. L. Mitchell, Advanced Software Testing—Vol. 3, Rocky Nook , 2015.

[7] S. Palamarchuk, “Abstracta,” 2016. [Online]. Available:

https://abstracta.us/blog/performance-testing/types-of-performance-tests/.

[8] SmartBear, “SmartBear,” 2018. [Online]. Available:

https://support.smartbear.com/readyapi/docs/loadui/configure/new/templates/peak.html.

[9] T. QA, “What is Compliance testing in software testing?,” 2018. [Online]. Available:

http://tryqa.com/what-is-compliance-testing-in-software/.

[10] T. QA, “What is Compatibility testing in software testing?,” 2018. [Online]. Available:

http://tryqa.com/what-is-compatibility-testing-in-software/.

[11] C. KANER, BLACK BOX SOFTWARE TESTING: INTRODUCTION TO TEST

DESIGN: A SURVEY OF TEST TECHNIQUES, BBST Test Design , 2011.

 36

[12] HackingIG, “What is conversion testing in software testing?,” 2017. [Online]. Available:

http://hackingig.com/what-is-conversion-testing-in-software-testing/.

[13] A. Birkett, “CXL,” 2017. [Online]. Available: User Experience Testing: A Conversion-

Focused Guide.

[14] R. Black, Advanced Software Testing—Vol. 1, Rocky Nook, 2016.

[15] T. QA, “What is Internationalization testing and Localization testing in software?,” 2017.

[Online]. Available: http://tryqa.com/what-is-internationalization-testing-and-localization-

testing-in-software/.

[16] T. Performance, “Disaster Recovery Testing Services,” 2017. [Online]. Available:

http://www.testingperformance.org/definitions/what-is-disaster-recovery-testing/.

[17] M. Rouse, “pen test (penetration testing),” 2011. [Online]. Available:

https://searchsoftwarequality.techtarget.com/definition/penetration-testing.

[18] V. Testing, “Tutorials Point,” 2018. [Online]. Available:

https://www.tutorialspoint.com/software_testing_dictionary/vulnerability_testing.htm.

[19] C. Hope, “Ethical Hacking,” 2017. [Online]. Available:

https://www.computerhope.com/jargon/e/ethihack.htm.

[20] T. QA, “What is Portability testing in software?,” 2017. [Online]. Available:

http://tryqa.com/what-is-portability-testing-in-software/.

[21] T. QA, "What is Functionality Testing in Software," [Online]. Available:

http://tryqa.com/what-is-functionality-testing-in-software/.
 37

[22] T. QA, “what-is-system-testing,” [Online]. Available:

http://istqbexamcertification.com/what-is-system-testing/.

[23] P. C. Jorgensen, Software Testing A Craftsman's Approach, Fourth Edition, CRC Press,

2014.