Propuesta de un "Plan de desarrollo de calidad del área de pruebas” para una empresa

colombiana de desarrollo de software, soluciones de mantenimiento IM

Carlos Alberto Robayo Caicedo (Código: 1411026685)

Fernando Rodríguez Caro (Código 1311070271)
Rincón Martínez Luis Alfredo. Código: 1011000115
Diego Alejandro López Garzón. Código: 1821982429
Michael Alexander Espinosa Rico. Código: 1821981046

Septiembre 2019.

Institución Universitaria Politécnico Gran Colombiano.

Ingeniería, Diseño e Innovación.
Pruebas y calidad de software
 2

Tabla de Contenidos

1. Introducción 5
2. Objetivos 7
3. MODELOS DE CALIDAD DE SOFTWARE 8
McCall: 8
Boehm 10
Arthur 12
Modelo de FURFPS 14
Modelo de CMM 15
Modelo de Gilb 16
Modelo de Dromey 17
Modelo ISO 9000 19
Modelo Mosca 20
4. Línea de tiempo modelos de calidad 22
5. Selección de modelos para trabajar en soluciones en mantenimiento IM 22
Modelos a nivel de productos 26
6. Evaluación de la organización encuestas 27
7. DOFA ORGANIZACIONAL 28
9. Aseguramiento de la calidad del software 30
9.1 Pruebas 30
9.2 Principios de las pruebas 31
9.3 Modelo en V en pruebas de calidad de software 32
9.4 Tipos de Pruebas del SQA 32
9.4.1 Pruebas Software Funcionales: 32
9.4.2 Pruebas no funcionales 33
9.4.3 Pruebas estructurales 33
9.4.4 Pruebas de Aceptación 34
9.4.5 Pruebas de Integración 34
9.4.5 Pruebas de Sistema 34
9.5 Técnicas de caja negra 34
10. Metodología de actividades y procedimientos para aplicar en “soluciones de mantenimiento
IM” 1
11. ACTIVIDADES PROCESOS Y PROCEDIMIENTOS PLAN DE PRUEBAS 1
Lista de referencias 9
 3

Lista de tablas

Tabla 1, Características modelo Arthur, elaboración propia 14

Tabla 2, Atributos modelos FURPS, elaboración propia 15
Tabla 3, características modelo dromey, elaboración propia 19
Tabla 4, Cuatrecasas,Luis, "Gestion Intgral de la Calidad", Gestion 2000, Barcelona, 2005, 3d
ed, 356p ,ISBN 84-8088-609-9 23
 4

Lista de ilustraciones

Ilustración 1, Características modelo de Boehm, elaboración propia. 11

Ilustración 2, Esquema general modelo dromey 18
 5

1. Introducción

En la actualidad las empresas de desarrollo de software se ha convertido en uno de los

principales aliados en las organizaciones a nivel mundial, dando soluciones a diferentes

necesidades, optimizando y mejorando procesos, razón por la cual el software debe contar con

criterios que garanticen su calidad, siendo esto un factor fundamental para el desarrollo de las

mismas como expresa (Valencia 2009): “La industria del software está directamente relacionada

con la globalización, proporcionando a las empresas herramientas para dar cuenta de los desafíos

de la internacionalización de la economía, tales como la innovación, el control logístico, la

transformación productiva, la posibilidad de comunicarse rápidamente con todo el mundo, la

necesidad de asegurar la calidad de productos, entre otros. De acuerdo con lo anterior, y si se

considera que la Calidad del Software es: “La concordancia con los requerimientos funcionales y

de rendimiento explícitamente establecidos, con los estándares de desarrollo documentados y con

las características implícitas que se esperan de todo software desarrollado profesionalmente”

(Pressman 2002).

De acuerdo con esto, diferentes investigadores han propuesto varios modelos,

metodologías y normas de calidad que brindan apoyo al desarrollo de un producto software y

permiten evaluar si efectivamente tiene un nivel de calidad durante su ciclo de vida.

En este documento se contextualiza inicialmente diversos modelos de calidad que se

pueden aplicar al desarrollo de productos de software, realizando un comparativo entre ellos,

 6

posteriormente se realizaron una serie de entrevistas con el objetivo de realizar la evaluación en

la empresa “soluciones de mantenimiento IM” En los diferentes procesos de la empresa.

Este trabajo se centrará en ofrecer una propuesta de mejora en los diferentes procesos de

software de esta pyme.

 7

2. Objetivos

2.1 Objetivo general.

Establecer un plan detallado y la documentación necesaria para realizar un plan de

pruebas con estándares de calidad que faciliten y optimicen los procesos de software en la

empresa “soluciones de mantenimiento IM”

1.2.2 Objetivos específicos. 

Diagnosticar la situación actual de la empresa con respecto a un modelo de calidad y

pruebas de software. 

Proponer un plan de acción para mejorar el proceso de calidad y pruebas actual. 

Identificar y comparar diferentes modelos de calidad asociados al desarrollo de software.

 8

3. MODELOS DE CALIDAD DE SOFTWARE

Modelos Fijos

McCall:

Tiene varios nombres uno es modelo GE (General Electric) debido al patrocinio de esta

empresa; también se conoce como FCM (Factores, Criterios, Métricas). Fue desarrollado

primeramente para la Fuerza Aérea de los Estados Unidos, aparte es el más antiguo y ha servido

como guía para otros modelos y consiste en acortar el camino entre el usuario y el desarrollador

y su planteamiento va encaminado a un número de factores de calidad que muestren las

prioridades de los dos.

Factores:

Se determinan entre el cliente y la administración para así poder conformar el punto de

vista externo del software, que es lo que le importa al usuario. Estos factores pueden ser:

confiabilidad, mantenibilidad y usabilidad.

Criterios:

Se establece en el nivel de la persona encargada de diseñar el software y es como se debe

construir los componentes de este, ósea las tecnologías, aspectos y funciones que solo le

competen a él. Acá es donde vemos la característica de Prueba y Eficiencia.

Métricas:
 9

Son quienes usan el producto final y consiste en preguntas cuyas respuestas (alfabéticas o

numéricas) indican la presencia del atributo evaluado. Por ejemplo, si evaluamos el criterio de

Simplicidad, vamos a verificar que las funciones en la prueba sean fáciles de experimentar.

McCall Propuso dividir la suma de las métricas que cubrían aspectos de calidad entre el

número total de ellas, para llegar al resultado del criterio. Este modelo ofrece tres factores para

definir la calidad del producto del software:

Operación del producto:

El cual hace referencia a las características de operación las cuales se dividen en:

Corrección:
Es aquel que mide el grado de satisfacción de un programa consiguiendo los objetivos del

usuario.

Fiabilidad:

Este mide el grado de lo que se espera que un programa haga.

Ventajas:

Se enfoca en el producto final teniendo en cuenta el punto de vista del usuario y buscando

los atributos claves.

También identifica criterios como simplicidad, capacidad de expansión, rastreabilidad,

etc.

Desventajas:

A veces no existe relación lineal entre las características que se estiman con los valores

métricos.
 10

Los factores de calidad siempre serán los mismos, y se asume que algunos de ellos serán

suficientes para realizar cualquier evaluación.

Boehm

Este modelo fue propuesto por Barry Boehm en el año de 1978 y se basa en que el

software debe hacer lo que el usuario quiere que haga. Esto es lo que se espera del software:

● Que utilice los recursos del computador correcta y eficientemente.

● Que sea fácil de usar y de aprender para los usuarios.

● Que esté bien diseñado, codificado y que sea probado y mantenido de una manera

fácil.

La estructura presenta 3 niveles para las características: de alto nivel, de nivel intermedio

y características primitivas.

Cada una de estas características contribuye al nivel general de calidad.

 11

Características de alto nivel

Estas características representan requerimientos generales de uso:

• Utilidad: cuando es usable, confiable y eficiente el producto en sí mismo.

• Mantenimiento: cuando es fácil modificarlo, entenderlo y resetearlo.

• Utilidad general: se puede seguir usando así se cambia el ambiente.

Características de nivel intermedio

Estas características representan los factores de calidad de Boehm:

• Portabilidad (Utilidad general)

• Fiabilidad (Utilidad per-se)

• Eficiencia (Utilidad per-se)

• Usabilidad (Utilidad per-se)

• Capacidad de prueba (Mantenibilidad)

• Flexibilidad (Mantenibilidad)

Características Primitivas:

Este es el nivel más bajo y corresponde a características directamente asociadas a una o

dos métricas de calidad:

Portabilidad

• Independencia de dispositivos

• Autocontención de confiabilidad.

• Autocontención
 12

• Exactitud

• Completitud

• Consistencia

• Robustez/Integridad

Ventajas

• Involucra menos criterios y factores lo que nos lleva a usar menos tiempo en el

desarrollo y se puede utilizar uno a uno y no para varios proyectos.

Desventajas

• No es específico con todo lo relacionado con el usuario.

Arthur

Creado por Arthur Andersen en 1985 cuyo objetivo es favorecer la transmisión de

información, determinándola como valiosa, esto desde el usuario hacia la institución y generando

que esta vuelva al usuario generando beneficios para él.

Este modelo presenta una variable propuesto por Mc Call que consta de dos acciones:

Añadir tres nuevos criterios de valoración que son complejidad, seguridad y audibilidad.

Permite la auditoria lo que implica un mayor grado de confiabilidad ante el riesgo.

Ventajas

• Tiene en cuenta el factor de calidad de corrección que muchos modelos no tienen.

• Permite la auditoria; lo que implica un mayor grado de confiabilidad ante el

riesgo.

Desventajas
 13

• Incluye criterios; lo que hace que se incluyan más métricas y esto conlleva más

esfuerzo, tiempo y costo.

Algunas de sus características:

Tabla 1, Características modelo Arthur, elaboración propia

Factores Criterios
Corrección Complejidad
Consistencia
Seguimiento
Fiabilidad Complejidad
Consistencia
Modularidad preciso
Simplicidad
Tolerante a errores
Eficiencia Concisión
Eficiencia de ejecución
Operatividad
Integridad Audibilidad
Instrumentación
seguridad
Utilizable Entrenamiento
Operatividad
Mantenible Autodocumentado
Concisión
Consistencia
Instrumentación
Modularidad
 14

Modelo de FURFPS

Desarrollado por Hewlett-Packard (1987). Vemos en este modelo que se desarrollan un

conjunto de factores de calidad de software, bajo el acrónimo de FURPS: funcionalidad,

usabilidad, confiabilidad, desempeño y capacidad de soporte. La tabla 2 que relacionamos a

continuación trae la clasificación de los atributos de este modelo y las características asociadas a

cada uno:

Tabla 2, Atributos modelos FURPS, elaboración propia

Factor de Calidad Atributos

Funcionalidad Capacidad y características del programa
Generalidades de las funciones
Seguridad del sistema
Facilidad de uso Factores humanos
Factores estéticos
Consistencia de la interfaz
Documentación
Confiabilidad Frecuencia y severidad de las fallas
Exactitud de las salidas
Tiempo medio de fallos
Capacidad de recuperación ante fallas
Capacidad de predicción
Rendimiento Velocidad del procesamiento
Tiempo de respuesta
Consumo de recursos
Rendimiento efectivo total
Eficacia
Capacidad de Soporte Extensibilidad
Adaptabilidad
Capacidad de pruebas
Capacidad de configuración
 15

Compatibilidad
Requisitos de instalación
Ventajas

• Antes de comercializarlo este modelo dispone de una serie de test para las

diferentes etapas del producto y así obtener un ledd-back.

• Cuenta con un plan de soporte definido que incluye una base de datos con los

errores registrados.

• Este modelo también incluye restricciones de diseño y requerimientos de

implementación físicos y de interfaz.

• También cuenta con criterios claros para su fácil utilización.

Desventajas

• Este diseño no tiene en cuenta la portabilidad de los productos de software que se

estén considerando, algo que se debe considerar en función de las exigencias actuales que recaen

sobre el proceso de desarrollo del software

• Necesita muchas métricas lo que implica mayor esfuerzo en tiempo y económico.

Modelo de CMM

Es el máximo estándar en ingeniería de software ya que tiene innovación, velocidad y lo

más importante satisfacción del usuario. En el principio este modelo fue aplicado en programas

de defensa teniendo una gran aceptación, llegando a realizar modelos para diversos ámbitos más

allá del software.

 16

Cuenta con cinco niveles definidos que son: Inicial, Repetible, Definido, Gestionado y

Optimizado.

Ventajas

• La gestión y la ingeniería de las actividades se encuentran entrelazadas de una

manera explícita, tan es así que facilita el reconocimiento de los objetivos del negocio.

• Permite hacer la incorporación de la experiencia adquirida en otras zonas de las

mejores prácticas.

• Se puede aplicar prácticas de alta madurez mucho más robustas.

• Cumplir de forma mucho más completa con las normas ISO.

Desventajas

• El gran problema es su falta de adecuación al enfoque del servicio que está

experimentando en el sector de la T.I en todas sus líneas de actividad, así como el alto esfuerzo

de implementación que exige.

Modelo de Gilb

Aparece entre los años 1986-1988 y este modelo utiliza el termino de “atributos”, lo que

hace referencia a la medida de calidad que determinado sistema a evaluar tiene. Este modelo

muestra particular interés en atributos de calidad para satisfacer las necesidades del usuario. Este

modelo se puede dividir en:

Capacidad de trabajo: busca medir la capacidad del sistema para ejecutar tareas, para lo cual
tiene en cuenta almacenamiento, proceso y respuesta.
Disponibilidad: capacidad para desarrollar un trabajo de manera útil.
Adaptabilidad: capacidad del sistema para sufrir modificaciones.
 17

Usabilidad: facilidad con el cual las personas serán capaces para hacer uso del sistema.
Este modelo proporciona algunas características que muestran indicadores útiles la cual
describe la calidad de la aplicación del sistema.

Ventajas

Evalúa el producto de manera independiente. También utiliza niveles de jerarquía para

delegar trabajos, facilidad en su mantenimiento y su uso e integridad.

Desventajas

Evalúa demasiados factores lo que ocasionan mayor trabajo en tiempo y costos.

Modelo de Dromey

Este es un modelo de calidad a medida propuesto en 1995 y su propósito es trabajar con

una estructura que permita construir y utilizar un modelo práctico con el fin de evaluar las etapas

de los requerimientos. Adicional a esto debemos tener en cuenta que esta información se puede

usar para elaborar, comparar y evaluar la calidad de los productos de software. Este modelo

también plantea la calidad del producto a través de sub características, las cuales se pueden medir

y evaluar como características.

Dromey propone 3 modelos para cada etapa del proceso de desarrollo, ver ilustración 2
 18

Tabla 3, características modelo dromey, elaboración propia

Propiedades del producto Características de calidad

Corrección Funcionabilidad
Confiabilidad
Internas Mantenibilidad
Eficiencia
Confiabilidad
Contextuales Mantenibilidad
Reusabilidad
Portabilidad
Confiabilidad
Descriptivas Mantenibilidad
Reusabilidad
Portabilidad
Usabilidad

Ventajas

Resalta que la calidad del producto es altamente determinada por los componentes de este

tales como documentos de requerimientos, guías de usuarios, diseños y códigos.

Sugiere el uso de cuatro categorías implícitas en la calidad que son: correctitud, internas,

contextuales y descriptivas.

Desventajas

Se basa solo en la calidad del producto y no en su desarrollo ni en su análisis.

Modelo ISO 9000

 19

El estándar ISO 9126 presenta su primera versión en 1991 y después, en el año 2001 se

reemplaza por la ISO 9126:1.

Este modelo cuenta con 8 principios básicos de gestión los cuales son:

• Enfoque al cliente

• Liderazgo

• Participación del personal

• Enfoque basado en procesos

• Enfoque de sistema para la gestión

• Mejora continua

• Enfoque basado en hechos para la toma de decisión

• Relaciones mutuamente beneficiosas con el proveedor

Ventajas

• Modelo de carácter internacional. Tecnología clara y precisa. Involucra el uso de

la ISO. Se puede usar en varios proyectos.

Desventajas

• Como casi todos los modelos, en este se destaca el mucho tiempo y dinero, pero

de todos este es el más costoso.

Modelo Mosca
 20

(Modelo Sistémico de Calidad de Software): es en el LISI-USB (Mendoza et al., 2001),

que integra el modelo de calidad del producto (Ortega, et al., 2000) y el modelo de calidad del

proceso de desarrollo (Pérez et al., 2001), y soporta estos conceptos de calidad sistémica (Callaos

y Callaos, 1993; Pérez et al., 1999). De acuerdo al producto este modelo plantea 6 características

de acuerdo a categorías, características y métricas asociadas que miden la calidad y hacen de este

modelo un instrumento de gran valor. Ya en cuanto al proceso este modelo se hizo sobre la base

de 5 características de calidad del estándar internacional, las cuales son:

Nivel 0 Dimensiones: Eficiencia del proceso y del producto. Efectividad del proceso y

del producto. Solo una buena interrelación entre ellas garantiza la calidad sistemática global de la

organización.

Nivel 1 Categorías: dividida en 6 pertenecientes al producto que son funcionabilidad,

fiabilidad, usabilidad, eficiencia, mantenibilidad y portabilidad y 5 al proceso de desarrollo que

son cliente-proveedor, ingeniería, soporte, gestión y organizacional.

Nivel 2 Características: cada categoría tiene asociadas un conjunto de características (56

al producto y 27 al proceso), las cuales definen las áreas claves a satisfacer para lograr, asegurar

y controlar la calidad tanto en el producto como en el proceso. Entre las características asociadas

a cada categoría del producto, se proponen en el modelo MOSCA, una serie de características del

proceso. Esto se debe a que algunas características de la calidad del proceso impactan

directamente en las categorías del producto, al igual que ciertas características de la calidad del

producto definen categorías del proceso.

Nivel 3 Métricas: la cantidad de métricas asociadas a cada una de las características que

conforman MOSCA es de 587 en total. Adicionalmente, MOSCA cuenta con un algoritmo que
 21

facilita su operacionalización y permite estimar la calidad de software. El algoritmo contempla

tres fases:

Estimación de la calidad del producto de software con un enfoque sistémico

Estimación de la calidad del proceso de desarrollo de software con un enfoque sistémico

Integración de las mediciones de los sub-modelos de la calidad del producto y la calidad

del proceso.

Ventajas

El enfoque es tanto en el proceso como en el producto

Es una herramienta efectiva de análisis y estimación de la calidad global

Desventajas

Se vuelve un proceso bien complicado si no se tiene una guía adecuada para la aplicación

del modelo.

4. Línea de tiempo modelos de calidad

5. Selección de modelos para trabajar en soluciones en mantenimiento IM

 22

Des pues de estudiar los diferentes modelos en este trabajo nos centraremos en el modelo

CMMI ya que tiene muchas prácticas de otros modelos mencionados y es muy utilizado para el

mejoramiento de los procesos de software en las organizaciones, dedicadas tanto al desarrollo

como a subcontratación de productos y servicios de software.

CMMI (Capability Maturity Model Integration), es un modelo para la mejora o

evaluación de los procesos de software, desarrollado por el instituto de ingeniera de software

(SEI) de la universidad de Carnegie Mellon en enero del 2002.

CMMI se compone de dos elementos básicos:

Modelos: Descripción de las mejores prácticas para que los procesos que permiten la

consecución de objetivos de negocios definen el que hacer.

Métodos de Evaluación: Permite medir los procesos de una organización a través de

estándares, niveles de madurez, capacidad de un área de proceso, entre otros.

El modelo CMMI contiene dos formas de representar los niveles de madurez y capacidad

son escalonada y continua.

 23

Modelo Ideal

El modelo IDEAL fue originalmente concebido como un modelo de ciclo de vida para

mejoramiento del proceso software basado en el Modelo de Capacidad y Madurez (CMM). A

continuación, se describe un poco más sobre el modelo, que en general ha mostrado gran

potencial en áreas fuera del dominio de los procesos.

IDEAL ofrece una aproximación útil y comprensible para la mejora continua, al exponer

los pasos necesarios para establecer un programa de mejora exitoso. El modelo proporciona un

enfoque disciplinado de ingeniería para la mejora, enfocándose en la gestión del programa de

mejora y estableciendo las bases para una estrategia de mejora a largo plazo. El modelo consta

de cinco fases:

I - Iniciación: Establecimiento de las bases para un exitoso esfuerzo de mejora.

D - Diagnóstico: Determinar dónde se está respecto a dónde se quiere estar.

E - Establecimiento: Planificación de los detalles de cómo se va a llegar al

destino.

A - Actuación: Realizar el trabajo de acuerdo con el plan.

L - (Learning) Aprendizaje: Aprender de la experiencia y mejorar la capacidad

para adoptar nuevas

tecnologías en el futuro.
 24

Modelo Ideal, tomado dehttp://normas--iso.blogspot.com/2009/11/normas-isoiec-12207.html

Modelos a nivel de productos

 25

Tabla 4, Cuatrecasas,Luis, "Gestion Intgral de la Calidad", Gestion 2000, Barcelona, 2005, 3d

ed, 356p ,ISBN 84-8088-609-9

 26

6. Evaluación de la organización encuestas

Por favor marque de 1 a 4, donde cada valor significa:

1. No hay practica definida

2. Existe una práctica, pero no está implementada
3. Existe una práctica, pero con resultados incompletos
4. Existe una práctica la cual se aplica con buenos resultados

Tabla 5, Encuesta – elaboración propia

1 2 3 4
Se conocen los requisitos de x
los proyectos
Existen documentos que x
soporten estos requisitos
Administración de entre el cliente y la compañía
requisitos Se realiza registro de cambios x
en los requisitos en cada
proyecto
Existe una política de manejo x
de requisitos
Se define el alcance del x
proyecto con estimaciones
Planificación de proyectos formales
Se definen las actividades a x
realizar
Se garantiza el ciclo de vida x
del proyecto

Se cuenta con un cronograma x

y presupuesto

x
Se cuenta con un plan de
riesgos

Se realizan actas en todas las x

reuniones
 27

Existen Lideres en la ejecución x

de proyectos

Se asignan roles de acuerdo a x

las habilidades de las
personas
Existe un control de versiones x

Existe una política de x

Control y monitoria de
monitoreo en cada proyecto
proyectos

Existe control de riesgos del x

proyecto

Existen control de los actores x

del proyecto
Existe un plan de pruebas en x
las diferentes etapas del
proyecto

7. DOFA ORGANIZACIONAL

A Continuación, se presenta una lista de Debilidades, Oportunidades, Fortalezas y

Amenazas (DOFA), la cual busca entender mejor la realidad actual de la empresa, e identificar

cuales son los estímulos para el cambio.

7.1 Fortalezas:

● El clima organizacional es muy ameno al ser una organización de menos de 20

empleados.

● Ofrece una solución integral, facilitando la fidelización de los clientes.

● La compañía proyecta seriedad y organización.

● El conocimiento técnico en soluciones de mantenimiento facilita el desarrollo de

nuevos planes.
 28

7.2 Debilidades:

● La documentación del software desarrollado no es clara.

● El proceso de software después de la etapa de requisitos no está bien definido

● Los recursos humanos son muy limitados, haciendo que la organización no pueda

atender a muchos clientes a la vez.

● El servicio post venta no está completamente estructurada.

● El proceso de aseguramiento de la calidad el producto está en una edad temprana

de implementación, pues existe una práctica con resultados incompletos

● Hace falta un modelo financiero.

7.3 Oportunidades

● Por el aumento del dólar es más difícil la compra de nuevas máquinas

industriales, lo que lleva a las empresas a invertir más en mantenimiento

● Existe la tendencia a tercerizar los servicios de mantenimiento

● Las industrias colombianas son apoyadas por el gobierno.

7.4 Amenazas

● Las soluciones integrales de los proveedores de máquinas, respuestas o

servicios

● Los inversionistas extranjeros ya vienen con las soluciones de mantenimiento

● Posibles pérdidas de contratos por no tener una certificación de calidad

ejemplo ISO.
 29

9. Aseguramiento de la calidad del software

El Aseguramiento de la Calidad del Software es el conjunto de actividades planificadas y

sistemáticas necesarias para aportar la confianza que el software satisfará los requisitos dados de

calidad, según la norma ISO 9000:2000 es parte de la gestión de la calidad.

En este conjunto de actividades no son únicamente responsables el equipo de calidad,

sino todo el equipo de trabajo y deben considerarse dentro de la gestión de riesgo, un defecto o

falla en alguna parte del ciclo de vida del producto pueden generar riesgos.

9.1 Pruebas

En 1957 se conoce la prueba del Debugging1 , y Dijkstra en 1970 presenta una

afirmación: “La prueba de software puede ser usada para mostrar la presencia de bugs, pero

nunca su ausencia”. Según Swebook: “Es una actividad realizada para evaluar la calidad del

producto y mejorarla, identificando defectos y problemas”

Normalmente la mayoría de las empresas dejan el proceso de pruebas para la última

etapa, consolidando la calidad de su producto es el caso de “soluciones de mantenimiento IM”

1
la depuración es un proceso para encontrar y reducir el número de errores o defectos en un programa de
compuador.
 30

esto debería dejarse a un lado, pues como se menciona anteriormente debe hacer parte de todo el

ciclo de vida del producto.

9.2 Principios de las pruebas

ISTQB ha propuesto establecer unas pautas comunes para que las empresas de desarrollo

de software las conozcan y adapten a sus procesos de pruebas

Principio
La presencia de defectos
Las pruebas exhaustivas
Pruebas tempranas
Paradoja del pesticida
Las pruebas dependen del contexto
Descripción
Permiten identificar presencia de fallos; sin
embargo no garantiza que no existan defectos
ocultos en el software
Probar un producto de software de extremo a
extremo es muy complicado lo mejor es
analizar riesgos y tomar decisiones
Es la mejor forma de ahorrar recursos, pues
identificarlas de manera temprana evitara un
mayor desgaste a futuro
Si se repite un mismo tipo de prueba, no se
encontrar nuevos errores, la idea es probar
nuevos casos
Las pruebas dependen del tipo de producto,
por ejemplo un software financiero necesitara
un mayor nivel de complejidad

Tabla 6, principios de pruebas, elaboración propia

 31

9.3 Modelo en V en pruebas de calidad de software

Ilustración Modelo V, tomado de Sh. Lawrence Pfleeger y J. M. Atlee, Software Enginnering.

Estados Unidos: Pearson; 2009

9.4 Tipos de Pruebas del SQA

Según las directrices de ISTQB2, los tipos de prueba de software se centran en:

9.4.1 Pruebas Software Funcionales:

“Se basan en funciones, prestaciones y en su interoperabilidad con sistemas específicos, y

pueden llevarse a cabo en todos los niveles de prueba” (T. Müller, 2013)

2
International Software Testing Qualifications Board
 32

Se orientan en el comportamiento externo de un producto o aplicativo software, en las

pruebas de caja negra3

Se consideran Pruebas de Caja Negra (“black-box testing”) puesto que valoramos el

comportamiento externo del sistema. Las Pruebas de Seguridad o las Pruebas de

Interoperabilidad entre sistemas o componentes son casos especializados de las pruebas

funcionales.

9.4.2 Pruebas no funcionales

Hacen referencia a las pruebas necesarias “para medir las características de los sistemas y

software que pueden cuantificarse según una escala variable”. (ieee, “Software Engineering.

Product quality. Part 1: Quality Model” 2001) Se debe tener en cuenta que se orientan hacia el

comportamiento externo del software y en la mayoría de los casos utilizan técnicas de diseño de

pruebas de caja negra.

9.4.3 Pruebas estructurales

Pueden realizarse en todos los niveles de prueba. Son las más idóneas, después de las

técnicas basadas en la especificación, “para ayudar a medir la exhaustividad de las pruebas

mediante una evaluación de la cobertura de un tipo de estructura” (T. Müller, 2011)

3
Técnica de pruebas de software en la cual la funcionalidad se verifica sin tomar en cuenta la estructura interna de
código, detalles de implementación o escenarios de ejecución internos en el software
 33

9.4.4 Pruebas de Aceptación

Las pruebas de aceptación se realizan con los usuarios finales con el fin de validar la

correcta implementación de los requisitos que fueron solicitados al inicio del proyecto.

9.4.5 Pruebas de Integración

Valida la comunicación e interacción correcta entre todos los componentes del sistema.

9.4.5 Pruebas de Sistema

Permiten comprobar el funcionamiento del flujo completo del proceso de negocio,

validando su operación global.

9.5 Técnicas de caja negra

Las pruebas de caja negra, es una técnica de pruebas de software en la cual la

funcionalidad se verifica sin tomar en cuenta la estructura interna de código, detalles de

implementación o escenarios de ejecución internos en el software.

En las pruebas de caja negra, nos enfocamos solamente en las entradas y salidas del sistema, sin

preocuparnos en tener conocimiento de la estructura interna del programa de software como

define Müller
 34

“Puede utilizarse para lograr objetivos de cobertura de entrada y salida, con entradas

humanas, vía interfaces a un sistema, o parámetros de interfaz de las pruebas de integración” (T.

Müller, 2011), basadas únicamente en los requerimientos de software y especificaciones

funcionales.

Ejemplo tomado de: Pmoinformatica.com," La Oficina de Proyectos de Informática "4

Ejemplo 1: Envió de correo electrónico al registrarse una transacción

Descripción del caso: El sistema enviará un correo electrónico cuando se registre alguna

de las siguientes transacciones: pedido de venta de cliente, despacho de mercancía al cliente,

emisión de factura a cliente y registro de cobro al cliente.

Técnica de pruebas de caja negra: Requerimiento funcional / Caso de uso

Caso 1.1: Datos de entrada: Registrar pedido de venta. Resultado esperado (Salida): El

sistema envía un correo electrónico al cliente como constancia que su pedido se ha recibido.

Caso 1.2: Datos de entrada: Registrar despacho de mercancía al cliente. Resultado

esperado (Salida): El sistema envía un correo electrónico al cliente como constancia que se ha

realizado el despacho.

4
Servicios de Amazon Associates LLC
 35

Caso 1.3: Datos de entrada: Registrar factura de cliente. Resultado esperado (Salida): El

sistema envía un correo electrónico al departamento de facturación y al cliente.

Caso 1.4: Datos de entrada: Registrar cobro. Resultado esperado (Salida): El sistema

envía un correo electrónico al departamento de cuentas por cobrar y al agente comercial

(vendedor) que lleva la cuenta del cliente.

 10. Metodología de actividades y procedimientos para aplicar en “soluciones de

mantenimiento IM”

Verificación casos de
Planeación de Diseño de pruebas
Reunión de casos de pruebas pruebas /usuarios,
pruebas/ usuarios y /analista de calidad -
contextualización funcionales anialista de calidad/
equipo SQA usuarios
desarollador

Validación de
Registro de hallazgos Ejecución pruebas
Ejecución de pruebas hallazgos /analista
Paso a producción /anaista de calidad - funcionales /analista
/ equipo SQA de calidad - equipo
equipo de desarollo de calidad
de desarollo

Ilustración proceso metodológico, elaboración propia

11. ACTIVIDADES PROCESOS Y PROCEDIMIENTOS PLAN DE PRUEBAS

El plan de pruebas se compone de los siguientes elementos:

 Nombre
 Introducción
 Objetivo
 Estrategia
 Alcance
 Entregables:
o Plan de pruebas funcionales
 Introducción
 Objeto
 Alcance
 Trazabilidad de casos de prueba – requisitos
 Definición de los casos de prueba
 Estrategia de ejecución de pruebas
 anexos
 2

 Documentación a entregar
 Características a ser probabas
 Características a no ser probadas
 Criterios de aprobación y fallo
 Criterios de suspensión y reanudación
 Tareas de las pruebas (Cronograma)
 Necesidades ambientales
 Hardware
 Planeación de costos
 Sistemas bajo pruebas – SUT
 Test- ware
 Capacitaciones
 Riesgos
 Laboratorio de usabilidad.

A continuación se describen cada uno de los elementos mencionados anteriormente:

Introducción:

Busca informar el alcance de las pruebas para el proyecto en cuestión, dando una breve

explicación o resumen de todas las secciones que integraran el plan.

Objetivo General:

Busca informar la finalidad genérica del Plan de Pruebas, no debe de señalar resultados

concretos ni medibles con la utilización de indicadores

Estrategia De Pruebas:

Corresponde al conjunto de decisiones sobre acciones y recursos a utilizar que permitirá

alcanzar el objetivo general de nuestro plan

 3

Alcance
Corresponde a presentar y delimitar la totalidad del trabajo que es necesitado para dar por

terminado nuestro plan de pruebas.

Propósito

Corresponde a la determinación firme de lo que se espera al momento de llevar a cabo la

implementación de nuestro plan de pruebas.

Documentación A Entregar

Se listarán todos los documentos que se entregaran como parte de la ejecución del plan,

especificando el nombre del documento, la persona quien entrega, la persona quien recibe, así

como la fecha planeada y la fecha que fue la entrega para cada uno de los entregables. Para esta

sección se recomienda el uso de una tabla cuyo formato del tipo de letra, color de la tabla sean

entendibles para que los involucrados en el Plan, puedan identificar rápidamente las

características de los entregables. Algunos de los documentos que debes de considerar entregar

son: Casos de pruebas, Especificación del diseño de casos, Reporte de errores (defectos),

Evidencias de las pruebas, Reportes emitidos por alguna herramienta de administración de las

pruebas y cualquier otro documento de carácter importante que sea considerado para su entrega.

Características A Ser Probadas

En esta sección se listarán todas las características que serán probadas. Algunas

características que se pueden hablar en esta sección son: características de funcionalidad, se

 4

interfaz gráfica, seguridad, etc. Es importante definirlas de manera clara y concisa para no tener

malas interpretaciones de dichas características.

Características A No Ser Probadas

En esta sección se listarán todas las características que no serán probadas, es importante

que se justifique el por qué no serán probadas las características y el riesgo que estas pueden

ocasionar al no ser probadas, Algunas características que se pueden hablar en esta sección son:

características de interfaz gráfica, seguridad, etc. Es importante definirlas de manera clara y

concisa para no tener malas interpretaciones y si ocurre algún evento que afecte al proyecto no

comenzar a repartir cumplas entre los equipos.

Criterios De Aprobación Y Fallo

Son los criterios que serán considerados para dar por completado el Plan de Pruebas, por

ejemplo: Porcentaje de la cobertura de las pruebas esperado, cierto porcentaje de casos exitosos,

cobertura de todos los componentes, porcentaje de defectos corregidos, todo error debe de ir

acompañado de un mensaje de validación, entre otros. Cuando un criterio de aprobación fue

rechazado se toma acción para el criterio utilizando el criterio de fallo para dicho criterio. Todo

criterio de aprobación lo debe de acompañar un criterio de fallo, el cual es la acción que se

tomara en la implementación del plan, cuando se ejecuten las pruebas sobre el proyecto.
 5

Criterios De Suspensión Y Reanudación

En esta sección se establecen los criterios de suspensión los cuales establece claramente

bajo qué condiciones se detienen un conjunto de casos de pruebas, por ejemplo en caso de existir

defectos que impidan la ejecución de más casos de pruebas, cierto porcentaje de casos fallidos, o

cualquier otro que se especifique. Los criterios de reanudación establece bajo qué criterios se

reanudaran las pruebas, por ejemplo: cuando nos entreguen una nueva versión de pruebas,

cuando nos realicen las configuraciones necesarias, etc. Es importante considerar que para cada

criterio de suspensión debe contar su criterio de reanudación.

Tareas De Las Pruebas (Cronograma)

En este apartado se describirán las tareas y cuando se van a ejecutar, el propósito es

mantener una buena administración de las tareas integradas en este plan. Se busca establecer el

nombre de la tarea, su descripción corta y precisa, fecha de inicio, fecha de fin, su duración, el

responsable de cada tarea y el rol que la desempeñara. Para determinar la duración de las tareas

es importe desarrollar un WBS5 en el cual se describen y se asignan las tareas de manera

desglosada para obtener dicha duración, o también podemos pedir la opinión de los expertos para

determinarla de manera más real.

Necesidades ambientales

Hardware

Se especifican los equipos tecnológicos que son requeridos para poder llevar a cabo

nuestras pruebas de software en el proyecto, las necesidades del hardware comienzan desde el

5
(Estructura de Descomposición del Trabajo)
 6

análisis de requerimientos, diseños de pruebas, administración de pruebas, ejecución de pruebas

y algún otro dispositivo necesario que es parte fundamental del proyecto, como pueden ser,

impresoras, terminales bancarias, teléfonos, que son algunos ejemplos.

Se debe considerar que los equipos y/o dispositivos con los que no se cuentan, que tan

requeridos son, para ello te debes de contestar las siguientes preguntas: ¿Es requerido el equipo

y/o dispositivo?, ¿Urge la adquisición del equipo y/o dispositivo que es requerido?, con el

objetivo de justificar porque es necesario la adquisición del equipo y/o dispositivo, de esta

manera los involucrados en el proyecto podrán determinar que parte realiza la adquisición del

hardware

Planeación De Costos

Se debe tener en cuenta el costo de la implementación de las pruebas en el proyecto. El

costo es uno de los indicadores más importantes a considerar en el plan, por lo tanto, mientras

más eficiente sea esta labor, menos recursos se invertirán en la ejecución de las pruebas y, por

consiguiente, menor será la cuantía de los gastos. Es importante tener en cuenta los recursos

humanos, costo de capacitaciones, cursos, insumos materiales; como puede ser papel, tinta etc.

Es importante que clasifiques los tipos de recursos para una mejor organización y presentación

de los mismos. También costo de capacitaciones.

Sut (Sistema Bajo Pruebas)

El sistema bajo pruebas por sus siglas en inglés SUT (System Under Test), se refiere al

sistema o modulo del sistema que está siendo probado para su funcionamiento correcto. Es

importante considerar la distribución de los módulos en los cuales el proyecto se organizó y la

 7

integración de los mismos. El propósito de esta sección es tener bien claro cuáles son los

módulos a probar, los requerimientos del proyecto por módulo y los casos de prueba para cada

módulo.

Test-ware.

En esta sección se especifican los artefactos que son requeridos para la ejecución del

proceso de pruebas, se debe de considerar la configuración del ambiente de pruebas, los

privilegios de los diferentes usuarios que van a interactuar con el sistema, los accesos a bases de

datos, guías de pruebas, casos de prueba y la documentación especifica del proyecto.

Capacitaciones

En esta sección se deben de especificar las capacitaciones requeridas para los integrantes

del equipo, el objetivo principal de esta sección es determinar a qué personas del equipo serán

capacitadas. Se debe de considerar las capacitaciones de carácter autodidacta. Es importante

considerar al instructor, las personas que recibirán la capacitación, así como los temas, las fechas

de inicio y fin, la duración en horas y su costo.

Riesgos
 8

En esta sección se especificarán los riesgos que pueden afectar directamente o

indirectamente a los resultados de nuestras pruebas. Identificar y tener las acciones preventivas y

correctivas de los riesgos anteriormente definidos, nos permiten tomar decisiones rápidas y

eficientes, porque anteriormente ya se realizó el análisis de los riesgos y sus acciones a tomar. Es

importante que al documentar los riesgos sea de manera organizada y entendible para todos los

involucrados del proyecto. A continuación, se mencionan algunas secciones para la organización

de los riesgos que son: Id Riesgo, Nombre, Descripción, Estado inicial, Consecuencias,

Probabilidad de ocurrencia, impacto, prioridad, clasificación, síntomas, tolerancias, acciones

preventivas y correctivas.

Laboratorio De Usabilidad

En esta sección se especificarán las juntas requeridas en todo el proyecto, las citas se

pueden tener de clasificación externa que son con el cliente o internas que son con los integrantes

del equipo, es importante determinar las citas y su objetivos de cada una ya que pueden ser para

presentación y validación de diseño de pruebas, como aclaraciones con las reglas de negocio,

requerimientos, etc. Algunas opciones de definición son: Junta, clasificación, descripción,

duración, fecha y los usuarios.

 9

Lista de referencias

J. A. Mera-Paz, “Análisis del proceso de pruebas de calidad de software”, Ingeniería

Solidaria, vol. 12, no. 20, pp. 163-176, oct. 2016. doi: http://dx.doi.org/10.16925/in.v12i20.1482

Aseguramiento de Calidad - TSI. (s.f.). Recuperado 16 septiembre, 2019, de

http://www.tsitecnologia.com.co/calidad-de-software-certificacion/

International Software Testing Qualifications Board [istqb], “Certified Tester Foundation

Level Syllabus. Released version 2011”, 2011 [en línea]. Disponible en:
http://www.istqb.org/downloads/send/2-foundation-level-documents/3-foundation-level-
syllabus-2011.html4

E. W. Dijkstra, “Notes on Structures Programming”, Technical University Eindhoven,

The Netherlands, departamento de Matemáticas, Technical Report 70-WSK-03 1970, pp. 15-64
[en línea]. Disponible en: https://www.cs.utexas.edu/users/EWD/ewd02xx/EWD249.PDF

ieee Computer Society, “Guide to the Software Engineering Body of Knowledge

Swebok”, ieee Computer Society, pp. 10-40, 2004 [en línea]. Disponible en:
https://www.computer.org/web/swebok/v3

Carlos García, Modelo de Calidad Mccall, Recuperado 8 de septiembre, 2019, de

https://prezi.com/_nr9euumvog2/modelo-de-calidad-mccall/

Devys Damián Fuentes Salas, Modelo Sistémico de Calidad (MOSCA), Recuperado 10

de septiembre , 2019 de https://www.mindomo.com/es/mindmap/modelo-sistemico-de-calidad-
mosca-e16aae03e1d4418db1b36a5f414de768

Tipos de Modelos. (s.f.). Recuperado 15 septiembre, 2019, de

http://evaluaciondered.blogspot.com/p/clasi.html

Carmen Ines Baez, Procesos de Desarrollo de Software Version 1,0, Basado en

Articulación de RUP y CMMI priorizando su calidad. Boyaca,2013

Cuatrecasas,Luis, "Gestion Intgral de la Calidad", Gestion 2000, Barcelona, 2005, 3d ed,

356p ,ISBN 84-8088-609-9
 10

Álvarez Caldas, Héctor Iván, Cárcamo Zuluaga, Juan Gonzalo, Propuesta de mejoramiento del
proceso software para una empresa de soluciones integrales, 2010, recuperado 7 de septiembre
2019 de http://hdl.handle.net/10784/407

Aseguramiento de la Calidad de Software. (s.f.). Recuperado 16 septiembre, 2019, de

Aseguramiento de Calidad - TSI. (s.f.). Recuperado 16 septiembre, 2019, de

http://www.tsitecnologia.com.co/calidad-de-software-certificacion/

T. Müller, Libro Programa de Estudio de Nivel Básico para Probador Certificado, istqb,
Version 2013, p. 14. Disponible en: http://www.istqb.org/downloads/send/2-foundation-level-
documents/3-foundation-level-syllabus-2011.html4

Fernando Ch Ga, F. (2018, 7 diciembre). Plan de Pruebas de Software. Recuperado 29

septiembre, 2019, de https://mundotesting.com/plan-de-pruebas-de-software/

Plantillas Plan de Pruebas | Marco de Desarrollo de la Junta de Andalucía. (s.f.).

Recuperado 29 septiembre, 2019, de
http://www.juntadeandalucia.es/servicios/madeja/contenido/recurso/463

Pmoinformatica.com, P. M. O. (s.f.). Pruebas de software: 10 pasos para elaborar el plan

de pruebas. Recuperado 29 septiembre, 2019, de
http://www.pmoinformatica.com/2016/01/elaborar-plan-pruebas-software.html