SENA: Planificación de pruebas para el módulo de registro en SOFIA Plus

FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
Material RAP - 1
Material RAP - 1

2
1. Introducción......................................................................................................3
2. Estructura de contenido...................................................................................4
3. Gestión de pruebas..........................................................................................5
4. Diagrama del proceso......................................................................................6
5. Planificación de pruebas..................................................................................7
5.1. Plan de pruebas............................................................................................9
6. Certificación y Estándares de Pruebas..........................................................14
6.1. Certificación de pruebas..............................................................................14
7. Estándares de pruebas: Definición y fases....................................................16
7.1. Estándar IEEE-829 de1983.........................................................................16
7.2. Estándar IEEE-1008 de 1987.....................................................................17
7.3. Estándar CMMI...........................................................................................18
7.4. Plan SQA....................................................................................................19
8. Glosario .........................................................................................................20
9. Referencias bibliográficas..............................................................................21
Créditos..............................................................................................................22
Creative Commons ............................................................................................22
Tabla de Contenido

3
1. Introducción
El proceso de gestión de pruebas de un software, permite establecer
las fases, plan de trabajo y la organización general de las acciones a realizar
por parte del equipo de trabajo que participará en este.
La generación de pruebas, es un componente muy importante en el
proceso de creación de un software, ya que permite encontrar fallas, mejoras
y ajustes en etapas tempranas del proyecto, evitando incurrir en costos altos
o fallas grandes al momento de implementar el proyecto.
Dadalaimportanciadeesteproceso,existenestándaresinternacionales
que permiten la unidad en la aplicación de pruebas y que ayudan a tener
presentes todos los aspectos que son necesarios probar en una aplicación o
desarrollo de software.
De esta manera en el presente contenido se dará a conocer el proceso
de gestión de pruebas, la fase inicial para la elaboración de la planificación de
pruebas, la cual contempla la creación de un documento inicial denominado
plan de pruebas y finalmente la presentación del contenido de los estándares
de pruebas más reconocidos, sus fases y la respectiva información de roles
del equipo de trabajo que se encarga del proceso de pruebas de un software.

4
2. Estructura de contenido Introducción al manejo
de pruebas de Software
Procesos de gestión
de pruebas
Diagrama del
proceso
Certificación y
estándares de
pruebas
Certificación de
pruebas
Estándares de
pruebas, definición
y fases
Estándar IEE-829
de 1983
Estándar IEE-1008
de 1987
Estándar CMMI
Plan SQA
ISTQB
Planificación
de pruebas
Plan de pruebas
conocer
contiene
tiene como resultado
que contiene
representado en
Para lo cual se requiere
1dentificar

5
3. Gestión de pruebas
Todo desarrollo de software, contempla
un proceso y unas fases establecidas que
permiten que sea construido según los
requerimientos del cliente.
En el marco de este ciclo de vida,
hay algo muy importante que corresponde
a la ejecución de pruebas. De esta manera
los objetivos de este proceso de gestión
de pruebas son: mejorar los tiempos de
desarrollo, evitar entregar fallas al usuario
final en la parte final del proyecto y evitar una
alta inversión económica por reprocesos.
Por lo tanto a continuación se presenta
un diagrama con el proceso completo de un
software y la gráfica con relación a los costos,
dependiendo del momento en el que esté
siendo encontrado el error:
Figura 1. Bosquejo de costos de ajustes
Fuente Sena
1. Verificación del diseño.
2. Requerimientos técnicos.
3. Análisis y diseño técnico.
4. Implementación.
5. Pruebas.
6. Integración.
7. Pruebas de aceptación de usuario.
Cambios en el tiempo
Influencia de funcionales
en los requerimientos
1 2 3 4 5 6 7
Desarrollo e implementación del software
Tiempo
Costo

6
Otro de los objetivos es optimizar el
proceso de pruebas que permita generar
una estabilidad en el software. Para ser más
eficaces (es decir, con más alta probabilidad
de encontrar errores), las pruebas deberían
ser realizadas por un equipo independiente al
que realizó el software.
4. Diagrama del proceso
El diagrama de proceso de gestión
de pruebas puede variar dependiendo del
estándar que se esté aplicando o del enfoque
de pruebas que se quiera implementar.
Sin embargo, a continuación se presenta
una imagen que enmarca las principales
actividades para este proceso:
Figura 2. Diagrama Gestión de Pruebas
Fuente SENA
Validación y
control de cambios
Gestión de pruebas

7
• Planificación de pruebas: contempla las
actividades iniciales del proceso de pruebas
en el que se plantea la generalidad de pruebas
a realizar.
• Diseño de pruebas: a partir de lo definido en
la fase inicial, se realiza el análisis detallado
de la documentación del software con el fin de
establecer las técnicas a utilizar y documentar
las condiciones para realizar las pruebas, los
elementos a probar, los pasos, entre otros
elementos importantes antes de iniciar la
ejecución de las pruebas.
• Ejecución de pruebas: para iniciar el
desarrollo de pruebas es necesario contar
con los requerimientos de datos de prueba y
ambiente de hardware y software indicado en
la fase de diseño. En la fase de ejecución de
las pruebas es importante tener claro cuáles
son los roles que ejecutarán las pruebas y el
plan de trabajo para las mismas. A partir de
esto es necesario empezar a documentar cada
una de las pruebas que se realizan para que
sea reportada.
• Validación y control de cambios: posterior
al reporte de errores o ajustes requeridos,
se debe proceder a volver a realizar pruebas
que permitan validar que todo ha sido
resuelto. Adicionalmente es necesario validar
que los ajustes realizados no afecten otras
funcionalidades del software.Apartir de esto es
necesario iniciar el cierre del ciclo de pruebas.
5. Planificación de pruebas
La fase de planificación de pruebas contempla
el inicio de actividades de prueba y tiene como
resultadolageneracióndeldocumentodenominado
Plan de pruebas.
Un plan de pruebas, permite describir el
alcance de las pruebas dependiendo del software
que se va a probar, los objetivos y enfoque. Algo
muy importante es el análisis del impacto que
podría causar el tener fallas en el software, para lo
cual es importante conocer la documentación del
mismo y su funcionalidad.
De esta manera, se puede representar este
proceso de planificación así:
• Conocimiento del software: lectura de
documentación, interacción con el software,
conocimiento de objetivos, entre otros.
• Lista de la necesidad de pruebas en el software
y de ítems a probar.
• Elaboración del plan de pruebas.

8
Con el fin de ilustrar el proceso, se va a tomar un
ejemplo de software existente para representar
la información del plan de pruebas. El Software
será el Sistema optimizado para la formación
profesional integral y activa SOFIA Plus.
En términos generales las funcionalidades más
representativas del sistema son:
Figura 3. Paquetes funcionales SOFIA Plus
Fuente SENA

9
Este sistema, como se sabe es el que maneja
diferentes procedimientos que permiten gestionar
algunos procesos del SENA. Teniendo en cuenta
la complejidad de este software, a continuación
se tomarán como ejemplo, sólo algunas de las
funcionalidades para la presentación del plan de
pruebas.
5.1. Plan de pruebas
El documento de Plan de pruebas, contiene
la documentación de lo analizado y propuesto en
la fase de planificación de ejecución de pruebas y
a partir de esta información se podrá iniciar la fase
de ejecución de pruebas.
Retomando el ejemplo de SOFIA Plus, a
continuación se presentará un ejemplo de un plan
de pruebas que estará enfocado únicamente a
algunas funcionalidades del módulo de registro de
este software.
El contenido que tiene un Plan de pruebas es el
siguiente:
• Descripción del software: descripción general
del software que será probado. Indicar para
qué fue creado, funcionalidades, personas que
pueden utilizarlo, dispositivos en los que se
encuentra disponible, entre otros.
• Condiciones de pruebas: lista de condiciones
o necesidades específicas para el desarrollo de
las pruebas. Cómo se conducirán las pruebas,
cuáles son las orientaciones generales.
• Objetivos de las pruebas: definir cuáles son
las expectativas de las pruebas a realizar y el
alcance las mismas.
• Elementos requeridos para la prueba:
definir qué ambientes informáticos, espacios,
servidores, sistemas operativos o software
adicionales son requeridos para probar el
software en cuestión.
• Lista de ítems que deberán ser probados:
se deben listar las funcionalidades o módulos
que se probarán del software y el tipo de roles
que deben ser validados. Es muy importante
la precisión de esta información ya que a partir
de esto, el equipo asignado para realizar las
pruebas, accederá a las funcionalidades o
módulos que sean indicados en este ítem para
ejecutar las respectivas pruebas.
• Lista de ítems que no deben ser probados:
se deben listar las funcionalidades o módulos
que no se probarán del software de tal manera
que el equipo que desarrollará la prueba no

10
genere esfuerzos en funcionalidades o eventos
del software que no forman parte del objetivo
de la prueba.
• Entregables en la documentación de
pruebas: de acuerdo con el tipo de pruebas
que se van a realizar, es necesario listar qué
se espera tener documentado, por ejemplo:
casos de prueba, scripts de prueba, reportes
de prueba, entre otros.
• Roles y responsabilidades: lista de los
roles que estarán incluidos y sus respectivas
funciones.
• Plan de trabajo general: definición de
actividades y tiempos estimados para la
ejecución de pruebas.
• Riesgos identificados a la hora de realizar las
pruebas.
A continuación se presenta el ejemplo del plan de
pruebas para el sistema SOFIA Plus.
Contenido ejemplo:
• Portada
Nombre del software: SOFIA Plus
Versión 1
• Introducción: en este apartado se debe
describir qué se pretende lograr con el
documento de plan de pruebas.
• Ejemplo: el plan de pruebas se establece para
identificar las posibles fallas en el paquete
funcional o módulo de registro del sistema
SOFIA Plus.
También permitirá establecer las pruebas
que son necesarias ejecutar, así como los
requerimientos y condiciones para este proceso
de prueba.
Este plan de pruebas es el insumo para la
ejecución de las pruebas.
• Descripción del software: se debe describir
cuál es la finalidad del software, es decir
para qué fue creado y en términos generales
indicar las características como: funcionalidad,
personas que pueden utilizarlo, dispositivos en
los que se encuentra disponible, entre otros.
Sistema informático centralizado para la
administración educativa y gestión de la
formación profesional integral del SENA, que
soporta la ejecución de acciones de formación
profesional basadas en competencias, a partir
del diseño conceptual, lógico y físico de sus
componentes y de su interrelación con los
demás sistemas de información del SENA.

11
• Condiciones de pruebas: indicar si existen
condiciones o necesidades específicas del
espacio en el que se realizarán las pruebas e
indicar cómo se conducirán las pruebas, cuáles
son las orientaciones generales.
• Objetivos de las pruebas: definir cuáles son
las expectativas de las pruebas a realizar.
Objetivos generales y objetivos específicos.
Este plan de pruebas tiene como objetivo
validar algunas de las funcionalidades del
sistema SOFIA Plus para el rol de aprendices.
Los objetivos específicos son: realizar
las pruebas funcionales como usuario de la
comunidad SENA en el sistema SOFIA Plus
para validar el paquete funcional o módulo
denominado Registro.
Realizar las pruebas técnicas
• Elementos requeridos para la prueba:
definir qué ambientes informáticos, espacios,
servidores, sistemas operativos o software
adicionales son requeridos para probar el
software en cuestión.
De acuerdo con el objetivo de lo que se va
a probar, se pueden identificar las distintas
pruebas a realizar.
Por ejemplo, si se analiza el paquete funcional
o módulo de registro de SOFIA Plus, se
puede identificar qué se requiere validar que
efectivamente cada una las acciones definidas se
puedan ejecutar de manera correcta.
De lado técnico, se puede evidenciar que al
ser este sistema para el SENA, se tiene un alto
impacto en la cantidad de usuarios que pueden
acceder al tiempo a interactuar con este software.
Es allí donde es necesario realizar pruebas de
recurrencia y pruebas de stress, es decir pruebas
que permiten simular varios usuarios conectados
al tiempo y accediendo al software.
De esta manera, cada una de las pruebas define el
tipo de requerimientos de hardware o de software
que deben estar disponibles.
En el marco del ejemplo, los requerimientos serían:

Pruebas funcionales con usuario final:
disponibilidad del sistema, datos de prueba,
documentación para el registro de pruebas,
documentación y orientación para el desarrollo de
la prueba.

12
Figura 4. Lista de ítems que no deben probarse
Fuente SENA
Pruebas de stress: identificar las funcionalidades
que serán probadas. Servidores que serán
probados, herramienta que simulará la prueba.
• Lista de ítems que deberán ser probados:
• Ingresar o modificar datos básicos persona
• Ingresar o modificar datos básicos empresa
• Ingresar o modificar tipos de población
• Ingresar, modificar o eliminar estudios
• Ingresar, modificar o eliminar experiencia
laboral
• Ingresar o modificar contacto
• Recordar usuario o generar contraseña
nueva
• Verificar existencia
Ítems que no deben ser probados:
Módulos o paquetes funcionales diferentes al
de registro tales como: inscripción, selección,
matrícula, ejecución de la formación, diseño
curricular, desarrollo curricular y certificación.

13
• Entregables en la documentación
de pruebas: listar qué se espera tener
documentado, por ejemplo casos de prueba,
scripts de prueba, reportes de prueba, entre
otros.
Para el caso de pruebas del ejemplo que se está
utilizando, la documentación esperada sería:
• Casos de prueba.
• Documentación de pruebas integrales.
• Pruebas de stress.
• Roles y responsabilidades
Se requiere el equipo técnico que realizará las
pruebas de carga, así como la herramienta de
software requerida para esto. La persona debe ser
el ingeniero técnico de pruebas.
Se requiere el equipo funcional que ejecutará las
pruebas del software y registrará los hallazgos
encontrados. Las pruebas funcionales requieren
de dos personas, el líder funcional que orienta la
prueba y el usuario final que realiza las acciones y
la interacción con el software.
• Plan de trabajo general
El Plan de pruebas que se presenta a continuación
bosqueja todo este proceso, desde la fase de
planeación hasta los ajustes finales.
Para la elaboración de este plan, de pruebas
es necesario validar con el equipo de trabajo la
definición de los tiempos que se requieren para
el desarrollo de cada una de las actividades y así
garantizarquelostiemposestimadoscorresponden
a las labores reales a ejecutar.
Con la información de actividades y tiempos, se
hace necesario utilizar un diagrama que permita
bosquejar la información y sacar las fechas más
aproximadas a la realidad para el cumplimiento
de objetos. Para esto existen varias herramientas
utilizadas pero la más común y recomendada es el
diagrama de Gantt ya que es un diagrama sencillo
que permite relacionar las actividades, los tiempos,
el recurso humano requerido, la definición de la
dependencia de actividades y la representación
gráfica de las actividades.
Figura 5. Plan de
pruebas
Fuente SENA

14
En este Plan de pruebas se está estimando
un tiempo de tres días para la fase inicial de
planificación, dos días para la fase de diseño, 45
días para la ejecución de pruebas y 15 días para
ajustes y control de cambios.
• Riesgos identificados a la hora de realizar
las pruebas.
Fallo de alguna de las funcionalidades que pueden
atrasar el cronograma previsto.
Fallo en los datos de prueba.
Suspensión de las pruebas: en caso que se
presente alguna irregularidad que no permita
ejecutar la prueba planteada, es necesario detener
el proceso.
6. Certificación y estándares de pruebas
6.1. Certificación de pruebas
La Certificación Internacional en Pruebas de
Software, contempla la formación y evaluación de
personas que se enfocan en realizar estas labores
en la ingeniería de software.
El que genera estas certificaciones es el Comité
Internacional de Calificación en Pruebas de
Software, en inglés, “International Software Testing
Qualifications Board” (ISTQB).
A continuación se presentan los niveles y módulos:
Figura 6. Niveles y módulos de ISTQB
Fuente: International Software Testing Qualifications Board

15
Esteorganismofuecreadoenel2002porempresas,
organizaciones y personas especializadas en el
campo de pruebas y de ingeniería de software.
Tiene como objetivo mantener una comunidad
de pruebas internacional, promoviendo la
investigación.
Su misión es:
• “Promover la ocupación de pruebas de
software como una profesión para individuos
y organizaciones”.
• Ayudar a las personas que realizan pruebas
de software a ser más eficientes y efectivos
en su trabajo a través de certificaciones de
competencias.
• Proporcionar una ruta de certificación
multinivel que permite a los profesionales
crecer progresivamente en habilidades y
conocimientos.
• Incremento del conocimiento aplicando las
mejores prácticas de la industria y el desarrollo
de investigación, dejándola disponible para
todos.
• Establecer criterios de acreditación de los
proveedores de entrenamiento para asegurar
la unidad de conocimientos.
• Regular el contenido de los exámenes, el
proceso de calificación y la expedición de
certificaciones por organismos oficiales de
pruebas.
• Certificar a profesionales en competencias de
pruebas de software.
• Proporcionar un punto de referencia para
evaluar la efectividad de los servicios de
pruebas de software de las organizaciones.
• Fomentar buenas relaciones con sectores
académicos, gobierno, medios de
comunicación, asociaciones profesionales y
otros interesados.
• Expandir las certificaciones de pruebas de
software en todo el mundo, mediante la
admisión de juntas de miembros en el ISTQB®.
Estas juntas se adhieren a la constitución,
estatutos y procesos definidos por el ISTQB®,
y participan en auditorías regulares. (ISTQB,
2016)
El ISTQB aplica estándares internacionales para
la aplicación de pruebas ya que esto permite tener
una alineación de parámetros, procedimientos y
objetivos a la hora de realizar pruebas.
El ISTQB ofrece tres niveles de certificación, el
básico (Foundations), el nivel avanzado y el nivel
experto.

16
Dentro de las certificaciones que se pueden
realizar están:
• Líder de pruebas.
• Analista de pruebas.
• Analista de pruebas técnicas
• Mejora continua del proceso de pruebas
• Gerencia de pruebas.
• Automatización de pruebas (actualmente en
elaboración).
• Pruebas de seguridad (actualmente en
elaboración).
7. Estándares de pruebas: definición y fases
Los estándares de prueba, son normatividad que
permite unificar las estrategias y procedimientos
que se realizan a nivel mundial en la generación
de pruebas de software.
Por lo general estos estándares definen
convenciones para la denominación de la
información, reglas para estructurar la información
y un código de documentación.
La aplicación de estándares genera beneficios
como:
• Aplicacióndemetodologíasyprocedimientos
de alto nivel en ingeniería de software.
• Unidad interna del trabajo en equipo que
facilita la coordinación de actividades y que
favorece la producción de software.
• Permite aprovechar el potencial en la unidad de información
que se ha generado en la industria.
• Favorece la comunicación entre los clientes y proveedores.
Por lo tanto, existen varios estándares que se describen a continuación:
7.1. Estándar IEEE-829 de1983
Este estándar aplica para las pruebas de unidad de software. El estándar
especifica los documentos y formatos que deben ser producidos en cada
fase, sin embargo no detalla el contenido de cada uno. Tampoco limita a la
producción de unos o todos, por lo cual es necesario evaluar su producción
de acuerdo con lo que se espera como resultado de la aplicación de pruebas.
Figura 6. Documentación de pruebas según estándar IEEE-829
Fuente: Sena
Registro de pruebas
Informe de incidentes
de pruebas
Informe de resumen
de pruebas
Informe de transferencia
de elementos de prueba
Procedimiento de prueba
Especificación de casos
de prueba
Especificación del diseño
de prueba
Plan de pruebas

17
Plan de pruebas: descripción del alcance,
enfoque, recursos y Plan de pruebas.
Especificación del diseño de pruebas: detalla
los casos de prueba y los resultados esperados
así como los criterios de aceptación.
Especificación de casos de prueba:
especificación de caso de prueba indicando los
datos de prueba para el inicio de las mismas.
Procedimientos de prueba: detalle de cómo
realizar las pruebas incluyendo los requerimientos
previosyelpasoapasodeejecucióndeactividades.
Informe de elementos de prueba: contiene un
record cronológico de detalles relevantes acerca
de la ejecución de pruebas, el orden de ejecución
de casos de prueba y el resultado de las mismas.
Reporte de incidentes de prueba: incluye los
procesos ocurridos durante las pruebas que deben
ser evaluados y profundizados, es decir los que
no son normales al comportamiento esperado del
software. Estos pueden ser tomados como errores,
incidentes o defectos. De esta forma es necesario
describir los pasos del suceso, la evidencia y el
impacto.
Informe de resumen de pruebas: permite resumir
los resultados obtenidos en las actividades de
pruebas y contiene recomendaciones según el proceso
realizado.
Registro de pruebas: Contiene el registro de las
pruebas realizadas, el estado y las recomendaciones.
7.2. Estándar IEEE-1008 de 1987
Este estándar especifica las normas para la ejecución de
pruebas unitarias de software. Está compuesto por tres
fases, que contienen ocho actividades. A continuación
el diagrama:
Figura 7. Estándar IEEE 28
Fuente: Amazonaws

18
con algún otro estándar al momento de realizar
pruebas, como por ejemplo el estándar de
documentación de pruebas.
7.3. Estándar CMMI
Este estándar es el modelo de Integración de
Madurez de la Capacidad y es un modelo de
calidad de software. Este modelo contempla seis
características que permiten la validación de
calidad interna y externa.
• Planeación de la prueba: plan general,
recursos y cronograma.
• Adquisición del conjunto de pruebas:
diseño de pruebas, implementación de plan de
diseño.
• Medidas de unidades de prueba: ejecución
de procedimientos de pruebas, chequeo de
finalización y evaluación de las unidades de
prueba. (IEEE, 1986)
• Este estándar detalla las acciones a seguir para
la ejecución de pruebas y puede ser combinado
Figura 8. Diagrama modelo CMMI
Fuente SENA

19
Figura 9. Diagrama modelo CMMI
Fuente SENA
Este modelo contempla la ejecución de pruebas
con métricas que permiten realizar la medición del
software y de esta manera validar la calidad del
producto.
7.4. Plan SQA
El Plan SQA permite la validación de la
aplicación de pruebas correcta mediante el uso de
estándares. Esto implica realizar un seguimiento
a la ejecución de pruebas a manera de auditoría
que permitirá garantizar la aplicación de la
normatividad.
Este plan incluye los siguientes elementos:
propósito, documentos de referencia, gestión,
organización, tareas, roles y responsabilidades,
recursos estimados de garantía de calidad,
documentación, propósito, requisitos mínimos
de documentación, descripción de requisitos de
software, descripción de diseño de software, planes
de validación y verificación, informe de resultados
de verificación, documentación de usuario, plan
de la gestión de documentación de software,
estándares, prácticas, convenciones y métricas,
gestión del riesgo, formación, herramientas,
además de otra información que complementa el
modelo de calidad.

20
8. Glosario
Estándares de pruebas: normatividad que
establece lineamientos que permiten unificar los
procesos, en este caso de ejecución de pruebas
a un software.
IEEE: Institute of Electrical and Electronics
Engineers. Asociación internacional sin ánimo
de lucro con alrededor de 370.000 miembros.
Busca permanente actualización profesional en
el campo de las ciencias electromagnéticas, de la
electrotecnología y de la informática (Colombia,
2010)
ISTQB:InternationalSoftwareTestingQualifications
Board. “Organización sin ánimo de lucro formada
por instituciones, empresas, organizaciones y
personas cuyo interés se centra en el la industria
del software y en el campo de las pruebas. El
objetivo principal es la profesionalización de las
pruebas con la definición de un esquema concreto
de certificación internacional de personas” (Board,
2015)
Plan de pruebas: Documento que se crea en la
planificación de pruebas para orientar la forma en
la cual se enfocarán y desarrollarán las mismas.
Plan SQA: documento de calidad (SQA – Software
Quality Assurance) que contiene la documentación
de pruebas a realizar a un software.

21
9. Referencias bibliográficas
Board, S. S. (2015). Spanish Software Testing Qualification Board. Recuperado de
http://www.sstqb.es/ recuperado el 25 de mayo de 2017.
The Institute of Electrical and Electronics Engineers, I. (2010). IEEE. Recuperado de
http://www.ieee.org.co/acerca-de-ieee.php recuperado el 25 de mayo de 2017.
IEEE. (1986). amazon. Standard for Software Unit Testing. Recuperado de
https://s3.amazonaws.com/akitaonrails/files/std1008-1987.pdf recuperado el 25 de
mayo de 2017.
Inc., P. T. (2013). SlideShare. Recuperado de https://es.slideshare.net/dumethvah/pruebas-
software-c2 recuperado el 25 de mayo de 2017.
ISTQB. (2016). Certifying Software Testers Worldwide. Recuperado de
http://www.istqb.org/about-as/vision-mission.html recuperado el 25 de mayo de 2017.

22
Créditos
Equipo de Adecuación Gráfica
Centro de Comercio y servicios
SENA Regional Tolima
Línea de Producción
Director Regional
Félix Ramón Triana Gaitán
Subdirector de Centro
Álvaro Fredy Bermúdez Salazar
Coordinadora de Formación Profesional
Gloria Ines Urueña Montes
Senior Equipo de Adecuación
Claudia Rocio Varón Buitrago
Experta Temática
Catalina Ropero Acero
Asesora Pedagógica
Ángela Patricia Frasser Castaño
Guionistas
Genny Carolina Mora Rojas
Jesús Bernardo Novoa Ortiz
Diseño y Diagramación
Diana Katherine Osorio Useche
Pedro Nel Cabrera Vanegas
Ismael Enrique Cocomá Aldana
Programadores
Davison Gaitán Escobar
Héctor Horacio Morales García
Creative commons
Atribución, no comercial, compartir igual.
Este material puede ser distribuido, copiado y exhibido por terceros
si se muestra en los créditos. No se puede obtener ningún beneficio
comercial y las obras derivadas tienen que estar bajo los mismos
términos de licencia que el trabajo comercial.

Material RAP - 2
Material RAP - 2

2
1. Introducción......................................................................................................3
2. Estructura de contenido...................................................................................4
3. Tipo de pruebas................................................................................................5
3.1. Funcionales...................................................................................................5
3.2. No funcionales...............................................................................................5
4. Técnicas de pruebas........................................................................................8
4.1 Caja negra......................................................................................................8
4.2 Caja blanca.................................................................................................. 11
4.3 Estáticas.......................................................................................................13
4.4 Basada en la experiencia.............................................................................14
5. Casos de pruebas..........................................................................................14
6. Material de apoyo...........................................................................................17
7. Glosario..........................................................................................................18
8. Referencias bibliográficas ............................................................................19
Créditos..............................................................................................................20
Tabla de Contenido

3
1. Introducción
En la fase del Diseño de pruebas de software
se establecen los criterios que permitirán orientar el
enfoque de las mismas y el objetivo de estas de acuerdo
con lo que se espera obtener del software. Esto indica
que se debe analizar el alcance de las pruebas, el nivel
de acceso y de conocimiento del software que permita
determinar las técnicas que se deben aplicar al momento
de realizar las pruebas y establecer los pasos y criterios
que orientarán la ejecución de las mismas.
Teniendo en cuenta lo anterior, en este resultado
de aprendizaje, se presentarán las técnicas de pruebas
de software existentes, los tipos que se pueden ejecutar
y la información acerca de la elaboración de casos de
prueba de un software.

4
2. Estructura de Contenido
Diseño de pruebas
Tipos de pruebas Casos de prueba
Técnicas de diseño
de pruebas
Funcionales Caja de negra
Caja blanca
Basada en la
experiencia
No funcionales
definición elaboración
que contempla
identificar

5
3. Tipo de pruebas
Cuando se van a realizar las Pruebas de
un software, se pueden tener varios escenarios
y alcance de estas pruebas, lo cual depende de
lo que es necesario validar en el software y de
la disponibilidad del mismo para la ejecución de
pruebas.
En términos generales podría decirse que
un software puede dividirse en dos partes, la parte
de lógica y programación. Lo que se denominará
la parte interna del software y la parte externa que
contempla los elementos visuales y de interacción
por parte del usuario con este.
De acuerdo con esto, a continuación se presentarán
los tipos de prueba de software definidos por el
ISTQB: pruebas funcionales, no funcionales y de
estructura o arquitectura.
3.1. Funcionales
Las pruebas funcionales de un software,
hacen referencia al cumplimiento de los
requerimientos iniciales establecidos para el diseño
de este con el cliente y su correcta implementación
en el sistema. De esta manera estas pruebas
hacen referencia al comportamiento del software
de cara al cliente, es decir a la interfaz o interfaces
que pueda tener; a los eventos que debe realizar el
usuario para la consulta y obtención de resultados.
Dentro de las pruebas funcionales, se
validan los diferentes datos que pueden ser
ingresados en el software, los diferentes roles que
pueden interactuar, los estados que puede tener
cada uno de esos roles, los datos de salida, entre
otros.
Parte de estas pruebas también se refleja
en la interoperabilidad del software con otros
sistemas o aplicativos en los cuales se valida la
comunicación entre estos a partir del ingreso
y retorno de datos desde los distintos roles del
sistema.
3.2. No funcionales
Las pruebas no funcionales contemplan la
validación de aspectos técnicos como:
• Rendimiento del software, prueba de carga y
desempeño.
• Seguridad
• Confiabilidad
• Configuración/ instalación
• Fiabilidad / cualidades
• Documentación
• Respaldo / recuperación
• Almacenamiento
• Performance, carga, tensión
• Volumen

6
De esta manera se realiza la validación de estos
componentes aplicando diferentes metodologías o
software existentes que permitan realizar este tipo
de validaciones.
Por ejemplo, a continuación se presenta la
validación de prueba de estrés realizada a algunos
paquetes funcionales de SOFIA Plus:
Figura 1. Descripción objetivo de pruebas
de rendimiento SOFIA Plus
Fuente: SENA
Figura 2. Descripción datos de pruebas
Fuente: SENA

7
Figura 3. Descripción resultados de pruebas
Fuente: SENA
Figura 4. Ejemplo herramienta utilizada en pruebas
Fuente: SENA

8
Teniendo estos dos grandes grupos de
pruebas, es necesario tener en cuenta que este
proceso se inicia de forma escalada, es decir que
es necesario tomar las partes más pequeñas del
software para irlas validando y luego de a poco ir
sumando el resto de componentes, funcionalidades
e interacciones que tiene el software. De esta
manera es importante tener en cuenta la estrategia
de pruebas que a continuación se define:
“La estrategia que se ha de seguir a la hora
de evaluar dinámicamente un sistema software
debe permitir comenzar por los componentes
más simples y más pequeños e ir avanzando
progresivamente hasta probar todo el software
en su conjunto. Más concretamente, los pasos a
seguir son:
• Pruebas unitarias: comienzan con la prueba
de cada módulo.
• Pruebas de integración: a partir del esquema
del diseño, los módulos probados se vuelven a
probar combinados para probar sus interfaces.
• Prueba del sistema: el software ensamblado
totalmenteconcualquiercomponentehardware
que requiere se prueba para comprobar que
se cumplen los requisitos funcionales.
• Pruebas de aceptación: el cliente comprueba
que el software funciona según sus
expectativas.” (Sevilla, pág. 11)
4. Técnicas de pruebas
Dentro de las Técnicas de pruebas que se
tienen disponibles, las que más se utilizan son las
técnicas de caja negra y caja blanca, que a su
vez contienen en su interior técnicas que facilitan
identificar los casos de prueba que necesariamente
se deben implementar de acuerdo con las
funcionalidades del software y que a continuación
se describen.
4.1. Caja negra
Esta técnica, se aplica para validar el
cumplimiento de las funcionalidades externas del
software, es decir que no requiere conocimiento
de la lógica ni de la programación, ni requiere tener
acceso al código del mismo.
Es así como con esta técnica se evalúan
los aspectos tales como los datos de entrada al
software,losparámetrosdeconfiguración,losdatos
de salida así como la interacción y comunicación
con otros sistemas de información.
De acuerdo con el funcionamiento del software,
dentro de estas pruebas se aplican a su vez
técnicas como:
• Análisis de valor al límite: valores mínimos y
los valores máximos de los datos que pueden
ser ingresados en el software.

9
• Partición de equivalencias: agrupación de
datos para la validación de resultados iguales
en el software.
• Combinación de datos y parámetros y su
correspondiente resultado en el software.
• Los cambios de estado que pueden
representarse en el sistema.
• Los caminos o rutas ejecutadas en el software
que generan un resultado.
Estos datos pueden contemplar datos de entrada
desde interfaces o directamente ingresadas por el
usuario.
Para la ejecución de estas pruebas, el
equipo que sea asignado para la realización de
las mismas, debe tener el conocimiento de las
reglas de negocio del software para la validación
funcional y debe tener un conocimiento técnico
para la validación de interoperabilidad en caso que
exista.
Es así que para analizar los diferentes tipos
de prueba funcional que son necesarias realizar,
es necesario desagregar los requerimientos del
software con el mayor detalle posible. Por ejemplo,
si se toma el paquete funcional de registro del
sistema SOFIA Plus, es necesario empezar a
analizar cada una de sus funcionalidades. Para
el ejemplo se utilizará la del registro de “Ingresar
datos básicos aspirante”. A partir de esto es
necesario tener acceso a la documentación de los
requerimientos del software y las reglas de negocio
que pueden estar representadas en diagramas
de caso de uso, diagramas de estado, diagrama
de actividad u otras, tal y como se muestra a
continuación:
Caso de uso: Registrar datos – SOFIA Plus
Registrar Datos
Nombre:
Descripción:
Una persona, funcionario (Instructor,funcionario Call Center,etc) y empresa debe estar registrada en
el sistema para poder acceder a ciertos servicios del sistema de información.
Para acceder al proceso de registro se podrá realizar de dos formas (El Funcionario del SENA/Call
Center,podrá servir como medio para que la persona/funcionario/empresa pueda registrarse):
• Pulsando directamente sobre el enlace de registrarse como usuario del sistema de información.
• Al aplicar a una oferta educativa el sistema validara que la persona se encuentre registrada de lo
contrario le dará la opción de realizar la inscripción inmediatamente.
Al ingresar a la opción de registro el sistema le solicitara a la persona/funcionario/empresa el ingreso
de su número de identificación o NIT para verificar que no exista un registro anterior de lo contrario
le dará la opción a usuario de ingresar la información requerida para finalizar el proceso.
Actores:
Persona
Funcionario
Empresa
Funcionario SENA/Call Center
Precondiciones:
• Si el registro es realizado con la ayuda de un funcionario SENA/Call Center se debe validar
que dicho funcionario se encuentre autenticado en el sistema para poder realizar el registro.
• Si el registro es realizado directamente por la persona, funcionario o empresa interesada el
acceso no requiere ningún tipo de validación de autenticidad.

10
Flujo Principal:
1. El Funcionario SENA/Call Center o persona/funcionario/empresa selecciona uno de los siguientes
tipos de registro:
• Empresa
• Funcionario
• Aspirante
2. El sistema le pide al Funcionario SENA/Call Center o persona/funcionario/empresa ingresar los
siguientes datos:
• Tipo de documento de identificación (Cédula,Tarjeta de Identidad,Cédula de Extranjería,NCS)
o NIT.
• Número de Documento de Identificación o NIT
3. El sistema valida que el número de documento de identificación no se encuentre registrado en la
Base de Datos del SENA. [A1]
Include::Validar Existencia de Registro de Persona
4. El sistema verifica que el número de documento de identificación se encuentre registrado en una
Base de Datos externa. [A2]
Include::Verificar Documento de Identidad en BD externa
5. De acuerdo a la selección (Aspirante,Instructor,Empresa) el sistema carga los datos que el usuario
debe ingresar.
6. El Funcionario SENA/Call Center o la persona/funcionario/empresa debe ingresar los datos
solicitados por el sistema.
Include::Ingresar Datos Básicos
7. El sistema verifica que todos los campos de carácter obligatorio se encuentren diligenciados para
continuar con el proceso. [A3]
8. El sistema le da la opción al Funcionario SENA/Call Center o la persona/funcionario de ingresar
datos adicionales. [A4]
Extend:: Ingresar Datos Adicionales
9. El sistema guarda los Datos Personales ingresados anteriormente y envía una notificación al
correo ingresado anteriormente confirmando el éxito del registro.
10. El sistema le asigna a la persona/funcionario/Empresa un número de identificación SENA (NIS) y
una contraseña y le envía esta información al correo electrónico registrado anteriormente.
Flujo Alternativo:
A1. Si el número de identificación ingresado se encuentra registrado en la base de datos del SENA el
sistema le indicara al Funcionario SENA/Call Center o persona/funcionario/Empresa que debe
ingresar su NIS y Contraseña para visualizar la información almacenada en su registro.

11
A2. Si la persona/funcionario/Empresa se encuentra registrada en la Base de Datos Externa el
sistema tomara los datos que allí se encuentran almacenados con el número de identificación
y diligenciara los campos posibles, de lo contrario deberá diligenciar la totalidad de los campos
que sean de carácter obligatorio.
A3 Si el Funcionario SENA /Call Center o la persona/funcionario/Empresa no ingresa en su totalidad
los datos básicos el sistema no le permitirá continuar con el proceso de registro.
A4. En el caso de la empresa, no se activara la opción de ingresar los datos adicionales
Poscondiciones
• El sistema despliega formulario de registro según perfil de usuario.
Figura 5. Diagrama de caso de uso de Registrar persona SOFIA Plus
Fuente: SENA
De este diagrama se pueden analizar cuáles
son los caminos que pueden recorrer el usuario
y la manera en la que puede terminar cada uno
dependiendo de los datos ingresados. Cada una
de estas opciones, representa un caso de prueba.
4.2. Caja blanca
La técnica de caja blanca se realiza para
analizar las condiciones internas del software, es
decir lo correspondiente al código desarrollado
para su funcionamiento. Por lo tanto, la ejecución
de estas pruebas requiere del conocimiento de
la lógica del software y también requiere que el
equipo asignado para la ejecución de pruebas,
tenga el conocimiento técnico necesario para la
validación de las mismas.
La evaluación interna del código, implica listar la
cantidad de funcionalidades del software tales
como condiciones, decisiones y condiciones
múltiples.
Para la ejecución de estas pruebas existen varias
técnicas que a continuación se mencionan:
• Pruebas de bucles: análisis de los
condicionales que se tienen en el grafo, su
complejidad y estructura.
• Determinar la lista de caminos
independientes: es decir identificar aquellos
pasos en los que se están ejecutando algunas
acciones donde se obtiene un resultado en el
sistema. Por ejemplo, si se ingresa un número
y tipo de identificación en el paquete funcional
de registro, el sistema indicará que ya existe,
por lo tanto ese sería uno de los caminos.

12
• Mutaciones: consiste en tomar una copia del
código y cambiar por ejemplo alguna de las
operaciones que están siendo ejecutadas en el
software.
• Diagrama de grafos: en el cual se determina
cuáles son los nodos (es decir cada acción y
evento que se ejecuta), cuáles son los arcos
(cantidad de flechas que se tienen en el
diagrama), regiones (espacios delimitado por
cada grupo de flechas).
A continuación se presenta un diagrama
de flujo que resume la funcionalidad detallada
en el caso de uso. Se generaliza en el siguiente
diagrama con el fin de hacer énfasis en los criterios
de la técnica de caja blanca de manera que se
puedan identificar los nodos, arcos y regiones
anteriormente mencionados:
Figura 6. Diagrama de flujo general para la
funcionalidad de registro en un sistema.
Fuente: SENA
Inicio
Ingresar datos
Ingresar
usuario y
contraseña
Se encuentra
registrado en el
sistema
Ingreso
funcionalidades
registro
Registrarse
Ingresar datos
Validar campos
obligatorios
Registro
satisfactorio
Fin
Si No

13
A partir de la funcionalidad del software o
en este caso del módulo que se está analizando, y
del diagrama de flujo que lo representa, se realiza
el diagrama de grafos; este permite identificar los
caminos que pueden existir dependiendo de las
acciones que realiza el usuario o de las validaciones
del sistema a partir de los datos ingresados:
Figura 7. Representación de diagrama de grafo
Fuente: SENA
De esta manera se pueden identificar los siguientes
caminos:
Camino 1: 1, 2, 3, 6, 7, 8, 9
Camino 2: 1, 2, 3, 4, 5
La cantidad de caminos que se identifican,
permiten plantear casos de prueba para analizar
los resultados esperados al momento de validar el
software.
• Pruebas de condición: en la cual se valida
el código de las condiciones que componen
el software identificando si existen errores de:
operador lógico, variable, operación aritmética.
• Prueba de flujo de datos
4.3. Estáticas
La técnica estática, hace referencia a
revisiones manuales pero que también contemplan
la aplicación de herramientas. Usualmente con
estas pruebas se logra identificar cuáles con
las causas de los problemas o fallas que puede
presentar el software, razón por la cual estas
pruebas son complementarias a las de caja negra
y caja blanca.
Management Review: es una revisión que
permite la toma de decisiones que permitan
cambiar la dirección del proyecto de acuerdo con
las necesidades del cliente y la necesidad de un
plan alternativo en caso de ser requerido.

14
Technical Review: validación del cumplimiento de
las especificaciones en los elementos de software
y de su desarrollo y mantenimiento según planes y
estándares de los proyectos.
Software Inspection: revisión del cumplimiento
del software con especificaciones y estándares.
Walktrough: la validación se realiza para encontrar
defectos, contradicciones u omisiones que
permitan identificar implementaciones opcionales
en el software.
Auditoría: el objetivo es validar el cumplimiento
de los productos y procesos del software según
las especificaciones y los procedimientos. Fuente
especificada no válida.
4.4. Basada en la experiencia
Teniendo en cuenta que existen personas
especializadas en la ejecución de pruebas de
software y con experiencia en el tema, se tiene esta
técnica que hace referencia a poner en práctica
las lecciones aprendidas en la evaluación de otros
software; de manera que se puedan identificar
errores en el software a partir de fallas comunes,
errores generalizados o requerimientos complejos
que requieren una fase de pruebas exhaustiva.
Es así como dentro de esta técnica, se pueden
encontrar las pruebas Ad Hoc y las pruebas
exploratorias.
Las pruebas Ad Hoc dependen totalmente de la
habilidad, intuición y experiencia del ingeniero de
pruebas.
Las pruebas exploratorias son pruebas que se van
haciendo a medida que avanza la verificación del
software y que se aplican y modifican de acuerdo
a su estructura.
La ejecución de las pruebas depende de la
disponibilidad, conocimiento y experticia de la
persona asignada para realizar este proceso.
5. Casos de pruebas
Los casos de prueba, permiten establecer
los pasos para la ejecución de pruebas funcionales
y no funcionales para el software, en donde se
establecen los parámetros y orientaciones que
el equipo de pruebas debe tener en cuenta al
momento de ejecutar las pruebas.

15
Un caso de prueba se compone de los siguientes elementos:
Caso de Prueba: nombre que permita identificar el objetivo de la prueba
Identificador
Descripción
Función a probar
Condiciones iniciales
Nombre de quien
ejecutó la prueba
Requisitos de
configuración para
la prueba
Resultado esperado
Resultado obtenido
Estado
Flujo
Usualmente se define una nomenclatura que identifica los casos de prueba.
Describir las funciones del software y del caso de prueba a realizar.
Nivel/módulo/función de la unidad que se prueba.
Indicar los datos o sucesos previos que se requieren para aplicar el caso de
prueba. Puede por ejemplo requerirse la ejecución previa de otro caso de
prueba.
Lista de pasos para ejecutar el caso de prueba. Se debe indicar qué hacer y
de qué manera.
Indicar lo que se espera con la prueba.
Pendiente de prueba, realizada, satisfactoria, fallida.
Nombre de la persona que prueba o tester.
Listado y descripción de los errores encontrados y la condición bajo la cual
se produjo.
Establecer requerimientos de ambiente de hardware o software requerido,
así como los datos de prueba necesarios para la aplicación del caso de
pruebas.

16
Los casos de prueba que tiene un software
son bastantes, es por esto que a partir de las
técnicas utilizadas, se pueden establecer cuáles
son los realmente necesarios para ser ejecutados.
Teniendo en cuenta el ejemplo del paquete
funcional de registro de SOFIA Plus que se ha
venido trabajando, a continuación se da un ejemplo
de algunos casos de prueba que se generan:
Caso de Prueba: Validación registro de usuario existente
Identificador
Descripción
Función a probar
Condiciones iniciales
Flujo
CP1.
Se ingresa con un usuario registrado en el sistema a la opción de registrarse.
Registro de usuario existente.
Los datos de prueba del usuario deben corresponder a un usuario
previamente registrado en el sistema.
1. El Funcionario SENA/Call Center o persona/funcionario/empresa
selecciona uno de los siguientes tipos de registro:
• Empresa
•Funcionario
•Aspirante
2. El sistema le pide al Funcionario SENA/Call Center o
persona/funcionario/empresa ingresar los siguientes datos:
• Tipo de documento de identificación (Cédula, T
arjeta de Identidad,
Cédula de Extranjería, NCS) o NIT.
• Número de Documento de Identificación o NIT
3. El sistema valida que el número de documento de identificación se
encuentre registrado en la Base de Datos del SENA.
Resultado esperado
Resultado obtenido
El sistema debe presentar un mensaje indicando que el usuario se encuentra
registrado y que deberá ingresar su NIS y Contraseña.
• Intento de registro con usuario previamente
registrado.
• Validación de campos obligatorios en el
formulario de registro de datos básicos.
• Registro completo con la validación del envío
de identificación SENA (NIS) y una contraseña
al correo electrónico registrado anteriormente.
A partir de esto, a continuación se presenta el caso
de prueba de la opción Intento de registro con
usuario previamente registrado.
Figura 9. Ejemplo caso de
prueba – registro usuario
existente en SOFIA Plus
Fuente: SENA

17
6. Material de apoyo
Para complementar los diferentes
conceptos adquiridos en el presente
documento,serecomiendaalosaprendices
consultar las Técnicas de caja blanca que
se puede encontrar en el archivo adjunto
Tecnicas_CajaBlanca.pdf.
Nombre de quien
ejecutó la prueba
Requisitos de configuración
para la prueba
Estado Pendiente de prueba.
Tener acceso a internet y acceso desde un computador a la página web.
Figura 9. Ejemplo caso de prueba – registro usuario existente en SOFIA Plus
Fuente: SENA

18
7. Glosario
Casos de prueba: es la documentación que
representa un conjunto de datos de entrada,
condiciones de ejecución y objetivos específicos
esperado al momento de la validación y verificación
d de un software para determinar si funciona
según lo esperado y definido en los requerimientos
iniciales.
Estándares de Pruebas: normatividad que
establece lineamientos que permiten unificar los
procesos, en este caso de ejecución de pruebas
a un software.
IEEE: Institute of Electrical and Electronics
Engineers. Asociación internacional sin ánimo
de lucro con alrededor de 370.000 miembros.
Busca permanente actualización profesional en
el campo de las ciencias electromagnéticas, de la
electrotecnología y de la informática. (Colombia,
2010)
ISTQB:InternationalSoftwareTestingQualifications
Board. “Organización sin ánimo de lucro formada
por instituciones, empresas, organizaciones y
personas cuyo interés se centra en la industria del
software y en el campo de las pruebas. El objetivo
principal es la profesionalización de las pruebas
con la definición de un esquema concreto de
certificación internacional de personas”. (Board,
2015).
Nomenclatura: es el conjunto de palabras que
permiten identificar una técnica o algo específico.

19
Board, S. S. (2015). Spanish Software Testing Qualification Board. Recuperado
de http://www.sstqb.es/
Sevilla, U. d. (s.f.). Universidad de Sevilla . Recuperado de
http://www.lsi.us.es/docencia/get.php?id=361

20
Créditos
Director Regional
Experta Temática
Asesora Pedagógica
Guionistas
Programadores
Creative commons

Material RAP - 3
Material RAP - 3

2
1. Introducción......................................................................................................3
2. Estructura de contenido ..................................................................................4
3. Gestión y control de la ejecución de pruebas..................................................5
3.1. Alistamiento...................................................................................................5
3.2. Documentación.............................................................................................6
4. Herramientas de soporte de pruebas de software...........................................8
4.1. Tipos..............................................................................................................8
4.2. Ejemplos......................................................................................................10
5. Material de apoyo...........................................................................................22
6. Glosario..........................................................................................................23
Créditos..............................................................................................................24
Tabla de Contenido

3
1. Introducción
La aplicación de pruebas de software, requiere
tener como precedente la planeación del alcance de
estas, respecto al equipo necesario que las ejecutará
y el tiempo asignado para esto, a partir de los casos
de prueba que han sido diseñados. De esta manera,
los casos de prueba serán los documentos que se
diligenciarán durante este proceso. Adicionalmente, es
necesario generar un informe con el resumen de las
pruebas que permita identificar el estado del proceso
realizado para tomar las acciones del caso en la siguiente
fase de ajustes y de cambios.
Teniendo en cuenta lo anterior, en este resultado
de aprendizaje se presentarán algunos aspectos a
tener en cuenta al momento de ejecutar las pruebas
y las técnicas de soporte de Pruebas de software que
facilitarán esta actividad.

4
Ejecución de pruebas
Pautas para su
elaboración
Tipos
Herramientas de
soporte de pruebas
Aislamiento Ejemplos
Gestión de pruebas
Pruebas funcionales
Pruebas de carga
y rendimiento
-Bugzilla testopia
-qaManager
-WebInject
-Soap T
est
-WebLoad
-Jmeter
-QA complete
-Testitool
-qaBook
-WET
-Test Studio
Documentación
conocimiento
que contempla
parámetros

5
3.1. Gestión y control de la ejecución de pruebas
El proceso de gestión de la ejecución
de pruebas, contempla el alistamiento para la
ejecución de pruebas, su seguimiento, toma de
decisiones y cierre de ciclo de pruebas. Para esto
a continuación se presentarán algunas acciones
que se deben realizar.
3.1. Alistamiento
Es necesario tener listo lo que se requiere por parte
del equipo asignado para la ejecución de pruebas
con relación a:
• Datos
Los datos del software pueden ser datos
generados, datos previamente guardados,
datos aleatorios (usados en pruebas de carga) y
en general todos los datos que sean necesarios
ingresar o visualizar en el software, por eso es
necesario tenerlos listos y configurados en el
sistema.
• Software
A nivel del software es necesario realizar la
configuración de los servidores, el alistamiento
de la información de pruebas en la base de
datos (instancia exclusiva para las pruebas),
si se requiere, el alistamiento de máquinas
virtuales, servidor web y simuladores.
• Herramientas de soporte
De igual forma, se requiere realizar la
configuración de las herramientas de software
que se desean utilizar.
• Hardware
Respecto al hardware es necesario tener
listo lo que se requiera a nivel de disco duro,
procesador, memoria, dispositivos multimedia,
entre otros.
• Cronograma de ejecución de pruebas
De acuerdo con lo que se estipuló en el plan
de pruebas, se hace necesario tener el detalle
de las pruebas que se van a realizar según los
casos de prueba identificados y las técnicas
definidas que se implementarán.
Por otra parte, también es necesario contar con
el equipo de personas que realizará las pruebas.
Este equipo, debe tener dominio del software y
conocer los requerimientos iniciales del proyecto a
nivel técnico y funcional ya que esto puede exigir
diferentes áreas de conocimiento.
Por ejemplo, cuando se hicieron las pruebas del
software SOFIA Plus se requirió que el equipo que
realiza las pruebas funcionales tuviera el dominio y
experticia en el funcionamiento de los procesos del
SENA y la manera como fueron proyectados que

6
se manejaran en el sistema, ya que esto permite
que se pueda hacer una validación acorde con lo
inicialmente estipulado, permitiendo evitar que las
pruebas puedan afectarse por expectativas de los
usuarios fuera del marco de los requerimientos
iniciales.
Recomendaciones para la ejecución de
pruebas:
Antes de dar inicio a las actividades de pruebas,
se recomienda realizar unas pruebas exploratorias
que le permita a los usuarios estar seguros de
conocer el software y las acciones que debe
realizar a la hora de probarlo.
No conformidades:
Según las pruebas realizadas, se pueden encontrar
no conformidades que pueden ser clasificadas así:
• Fatales: son errores que se encuentran en el
software que no permiten continuar el desarrollo
de la prueba.
• Mejoras: son situaciones que no estaban
previstas en los requerimientos iniciales pero
que pueden ser implementadas en el software.
• Funcionales:cuandonoseobtienenresultados
esperados en determinadas validaciones,
por ejemplo cuando se evidencia que faltan
algunas por realizar.
• Visualización: son errores a nivel visual
para el usuario que pueden ser errores de
diagramación, por ejemplo si un botón no
está alineado con otro, errores de ortografía o
errores en el cumplimiento con estándares.
Cuando se encuentran inconformidades, es
necesarioenalgunoscasos,especialmentecuando
se tiene una funcionalidad que se utiliza varias
veces en diferentes módulos o funcionalidades
del software, realizar una segunda validación que
permita confirmar los errores encontrados.
• Alcance de las pruebas: las pruebas se
realizan desde la primera versión del software
y pueden tener varias iteraciones, dependiendo
de la cantidad de no conformidades que se
encuentren en el momento de realizar las
pruebas y también de la cantidad de ciclos que
se proyecten para solventarlas.
Un ciclo de pruebas puede ser cerrado cuando se
han ejecutado todas las pruebas proyectadas y las
inconformidades hayan sido resueltas.
3.2. Documentación
A nivel de documentación, se debe realizar el
registro de pruebas de acuerdo con las técnicas
definidas y los casos de prueba que previamente
se proyectaron.

7
De esta manera, es necesario diligenciar la
información de resultados obtenidos en cada caso
de prueba que fue diseñado en la primera etapa
del proceso de gestión de pruebas.
Informe de incidente de pruebas: en este
informe es fundamental la recopilación adecuada
y bien redactada de lo que evidencia el equipo de
pruebas.
De esta manera se recomienda tener un informe
con la siguiente información:
• Fecha de la prueba.
• Persona que realiza la prueba.
• Módulo/ funcionalidad.
• Código del caso de prueba.
• Nombre del caso de prueba.
• Resultado obtenido.
• Estado de ejecución (pasó, falló, no se pudo
ejecutar).
• Estos datos son adicionales a los que ya se
tengan definidos.
• En dónde se encontró el problema: unidad,
módulo, API o funcionalidad del software.
Cómo: pasos con los cuales se evidenció el error.
Condiciones: qué datos se utilizaron, qué equipo
o dispositivo (computador, celular) y en general
con cuáles condiciones se generó el incidente.
Hallazgo: descripción de lo que se encontró,
relacionar imagen el problema encontrado.
Qué se esperaba: qué estaba esperando como
respuesta de la prueba en el software.
Figura 1. Ejemplo informe incidente de pruebas
Fuente: SENA

8
Es necesario tener en cuenta que existen
herramientas de software para la gestión de
pruebas que traen reportes definidos para la
consolidación de incidentes, así como gráficas que
permiten evidenciar esta trazabilidad del estado de
las pruebas.
Resumen de pruebas: de igual manera, es
necesario tener un resumen de las pruebas
realizadas que permita identificar desde la gestión
de pruebas, el avance en porcentaje de las pruebas
realizadas, el porcentaje de no conformidades
encontradas, el porcentaje de pruebas aceptadas,
entre otros.
Por lo tanto se sugiere tener la siguiente
información:
Figura 2. Ejemplo informe resumen de pruebas
Fuente: SENA
De esta manera, los anteriores formatos
son sugerencias de la información que debe ser
registrada y que permitirá la toma de decisiones en
un proyecto de software, sin embargo es necesario
evaluar las herramientas que pueden ser útiles
en este proceso y que dependiendo de lo que se
quiera analizar puede favorecer el seguimiento del
proyecto.
4. Herramientas de soporte de pruebas de
software
4.1. Tipos
Existen diversos tipos de herramientas de soporte
de pruebas que apoyan las distintas labores, tales
como:
Gestión de pruebas: estas herramientas permiten
la organización de actividades de modo tal que
pueda realizarse un seguimiento al proceso. Por
lo tanto, en estos instrumentos se puede hacer el
registro de incidentes que se vayan encontrando,
permite asignar el equipo encargado de realizar

9
pruebas y solventar fallas, permiten usualmente
generar reportes y también gráficos que facilitan la
toma de decisiones de acuerdo con los resultados
y avances que se van obteniendo.
Pruebas funcionales: este tipo de herramientas
permiten el registro de casos de prueba y la
generación de eventos que ayudan a validar las
funcionalidades del software. De esta manera,
dependiendo de la herramienta seleccionada, se
hace necesario configurar la información, detallar
los objetivos del software y aplicar las pruebas
diseñadas. Usualmente contemplan la generación
Algunas herramientas permiten realizar todas las
pruebas anteriormente nombradas. Sin embargo
de acuerdo con las necesidades del proyecto y
las expectativas planteadas, se deben seleccionar
aquellos instrumentos que se adapten a los
requerimientos puesto que también es necesario
contemplar el costo que estas puedan representar.
De acuerdo con lo publicado en varios recursos de
internet (Software, 2013), a continuación se listan
algunas herramientas de uso libre y comercial:
Figura 3. Herramientas de uso libre
Fuente: SENA
de reportes que permiten ver la trazabilidad
de las pruebas realizadas y los resultados
obtenidos.
Pruebas de carga y rendimiento: las
herramientas de carga y rendimiento
permiten simular las condiciones con
las cuales se puede evaluar el software
en condiciones máximas de acceso y
disponibilidad. Por ejemplo, se puede
simular la ejecución de acciones por parte
de múltiples usuarios al mismo tiempo
para evaluar los niveles de respuesta, la
capacidad y los tiempos que genera el
software.
Gestión de Pruebas
• Bugzilla Testopia
• Fínese
• qaManager
• qaBook
• RTH (open source)
• Salome-tmf
• Squash TM
• Test environment Toolkit
• TestLink
• Testitool
• XQual Studio
• Radi-testdir
• Data Generator
Pruebas Funcionales
• Selenium
• Soapui
• Watir
• WatiN
• Capedit
• Canoo Webtest
• Solex
• imprimatur
• SAMIE
• ITP
• WET
• Webinject
Pruebas de carga y
rendimiento
• Funkload
• FWPTT load testing
• loadUI
• jmeter
Herramientas de uso libre

10
Figura 4. Herramientas comerciales
Fuente: SENA
4.2. Ejemplos:
Existen diversas herramientas que facilitan las
actividades que se realizan al momento de realizar
pruebas al software. Esto permite automatizar
actividades que agilizan algunas actividades
al interior de este proceso. De esta manera se
encuentran herramientas gratuitas y pagas. Cada
una tiene beneficios, a continuación se describen
algunas de estas herramientas:
Bugzilla
Es una herramienta de gestión de pruebas para
el reporte de errores. Es un software gratuito que
facilita el registro de errores por parte del equipo
de pruebas y la visibilidad y acceso por parte del
equipo desarrollador y administrativo del proyecto
que permitan dar solución a lo reportado de manera
eficiente.
Esta herramienta permite indicar la prioridad de
cada error y solicita indicar el detalle del software,
así como los responsables de la ejecución de
pruebas, el tiempo estimado para la resolución de
cada problema, el detalle de cada bug, adjuntar
un archivo si es necesario, asignar a una persona
encargada de solucionarlo, entre otras cosas.
Gestión de Pruebas
• HP Quality Center/ALM
• QA Complete
• qaBook
• T-Plan Professional
• SMARTS
• QAS.Test Case Studio
• PractiTest
• SpiraTest
• TestLog
• ApTest Manager
• Zephyr
Pruebas Funcionales
• QuickTest Pro
• Rational Robot
• Sahi
• SoapTest
• Test Complete
• QA Wizard
• Squish
• vTest
• Internet Macros
Pruebas de carga y
rendimiento
• HP LoadRunner
• LoadStorm
• Neo Load
• WedLOAD Professional
• Forecast
• ANTS - Advanced.NET
Testing System
• Webserver Stress Tool
• Load Impact
Herramientas comerciales

11
Figura 5. Imagen ingreso de datos Bugzilla
Fuente: https://www.youtube.com/watch?v=vBAKYRJgV64 minuto 11

12
Acontinuación, se puede apreciar una imagen de la trazabilidad de errores que se encuentran registrados.
El programa también notifica al correo electrónico cada vez que se realiza algún cambio.
Figura 6. Imagen ingreso de datos Bugzilla
Fuente: https://www.youtube.com/watch?v=FUiZQ2UnUTg, minuto 6:37.

13
Bugzilla Testopia
Testopia maneja extensiones para la interacción
con Bugzilla. Básicamente esta herramienta
permite la administración y seguimiento de casos
de prueba. (Network, 2005-2017)
Generatedata
Herramienta para la ejecución de pruebas que
puede ser actualizada por cualquier persona. Tiene
una versión beta gratuita y también una versión
completa. Es creada en PHP con javascript y usa
una base de datos MySQL para ayudar a generar
datos aleatorios que faciliten las pruebas.
En esta herramienta se pueden configurar los
datos de prueba que se requieren, por ejemplo si
se requiere tener una lista de nombres, apellidos
y edades, entonces se diligencian los campos y
se indica el tipo de formato en el que se requiere
dentro de los cuales están: html, Excel, xml, csv o
sql.
Figura 7. Imagen configuración de datos
Generedata
Fuente: http://www.generatedata.com/#t1

14
A partir de esto, en la herramienta se pueden
generar por ejemplo mil datos y pueden ser
visualizados y manipulados:
Figura 8. Imagen reporte de datos de prueba
generados- Generedata
Fuente: SENA
Soaptest
Es una herramienta que facilita la ejecución de
pruebas de integración, APIs, webservices, entre
otros.
Esta herramienta permite la elaboración de pruebas
funcionales, pruebas de desarrollo, pruebas de
aplicaciones en la nube, pruebas de aplicaciones
complejas.
Figura 9. Imagen Soaptest
Fuente: https://www.parasoft.com/products/

15
WebInject
Es una herramienta gratuita que facilita la automatización de pruebas
funcionales, aplicaciones web y webservices.
Figura 10. Imagen WebInject
Fuente:
https://www.youtube.com/watch?v=FQSXzQAlEqQ, minuto 3:44
Contiene un API en xml que permite evaluar
los casos de prueba. Está escrita en Perl y
puede ser instalada en Windows, Linux, Mac.

16
WebLoad
Es una herramienta que utiliza javascript para generar escenarios de prueba.
De esta manera permite simular el acceso de múltiples usuarios, lo cual
permite evaluar el rendimiento del software.
De igual manera permite generar reportes para analizar el comportamiento de
base de datos, servidores, sitio web y otros componentes utilizados durante
las pruebas.
Permite realizar acciones de:
• Correlación
• Verificación
• Parametrización
• Vista de consola
Figura 11. Imagen Webload
Fuente: http://www.radview.com/solution/web-testing-tools/

17
Jmeter
Jmeteresunaherramientaquepermiterealizarpruebasdecargayrendimiento
en el software, simulando una cantidad de usuarios específica que se puede
configurar de acuerdo con las necesidades de las pruebas.
Se configura con el número de usuarios que van a realizar las pruebas, hora
de inicio, hora de fin, se puede añadir gráfico de resultados.
Figura 12. Imagen Jmeter
Fuente: https://www.youtube.com/watch?v=1yJUyRWWOsg

18
QA complete
Es una herramienta que facilita la gestión de
pruebas; pues permite organizar los casos
de prueba, ambientes de prueba, pruebas
automatizadas, defectos y tareas de pruebas en
el proyecto.
Figura 13. Imagen QAcomplete
Fuente: http://www.testmanagement.com/qacomplete.html

19
Figura 14. Imagen QAcomplete
Fuente: http://www.testmanagement.com/qacomplete.html
Testitool
Es una herramienta gratuita para la gestión de
prueba, así permite generar casos de prueba,
asignarlos, ponerles un estado, generar informes
y generar instancias del plan de pruebas. Esta
herramienta está hecha en PHP.
qaBook
Esta herramienta tiene una versión gratuita para la
gestión de pruebas. También tiene otras versiones
que contemplan acciones específicas de acuerdo
con lo que se requiera:

20
Figura 15. Imagen QA BOOK
Fuente: http://www.qabook.com/
Wet
Es una herramienta gratuita para realizar
pruebas funcionales que permite realizar todas las
operaciones necesarias para probar aplicaciones
web, tales como prueba de acceso en enlaces,
ingreso de información en campos de texto, clic en
los botones, entre otros.
Test Studio
Hay pocas herramientas que permiten
realizar todo tipo de pruebas y que también permite
la gestión de las mismas. Este es el caso de Test
Studio. Es una herramienta que permite de manera
completa la automatización de pruebas de interfaz
de usuario, componentes, pruebas de integración,
pruebas web, pruebas móviles y para aplicaciones
de escritorio.

21
Figura 16. Imagen Test Studio
Fuente: http://www.telerik.com/teststudio

22
5. Material de apoyo
Para complementar los diferentes conceptos adquiridos
en el presente documento, se recomienda a los
aprendices consultar el documento anexo Roles para la
gestión de pruebas.

23
6. Glosario
Herramientas de soporte de pruebas: software que facilita la ejecución de
pruebas ya que permite automatizar algunas de las actividades a realizar.
Tipos de prueba: es la clasificación de las pruebas de software de acuerdo
con los objetivos de las mismas y la metodología a utilizar.
Marquéz, J. (2015). Las mejores herramientas para realizar pruebas de software.
Recuperado el 03 de junio de 2017 https://es.slideshare.net/nanotechnology/las-
mejores-herramientas-para-realizar-pruebas-de-software

24
Créditos
Director Regional
Experta Temática
Asesora Pedagógica
Guionistas
Programadores
Creative commons

Material RAP - 4
Material RAP - 4

2
1. Introducción......................................................................................................3
2. Estructura de contenido ..................................................................................4
3. Gestión de cambios y pruebas finales.............................................................5
3.1. Proceso de gestión del cambio.....................................................................5
3.1.1. Registro......................................................................................................8
3.1.2. Análisis y planificación..............................................................................10
3.1.3. Implementación........................................................................................12
3.1.4. Pruebas....................................................................................................14
3.2. Documentación...........................................................................................15
3.3. Herramientas para control de versiones ....................................................16
4. Glosario..........................................................................................................18
Créditos..............................................................................................................20
Tabla de Contenido

3
1. Introducción
El proceso de gestión de cambios en un software,
contempla la recolección y análisis de las observaciones
que puedan surgir de este. Puede ser en la versión
inicial o en una versión posterior a la inicial en la que se
evidencien nuevos requerimientos para el software.
Por lo tanto, es importante conocer el proceso de
gestión de cambios y el detalle del mismo con relación a
las herramientas que pueden ayudar en este proceso y a
la respectiva documentación que se debe realizar. Esta
información estará en el contenido de este resultado de
aprendizaje.

4
Gestión de cambios y
pruebas finales
Proceso
Herramientas
Documentación
Registro
Pruebas
Implementación
Análisis y
planificación
descripción presentación descripción
que contempla

5
3. Gestión de cambios y pruebas finales
En la creación de software, se pueden
evidenciar diferentes cambios que pueden ser
generados por nuevas solicitudes o por errores
que pueden presentarse.
De esta manera cuando se generan
cambios, se hace necesario realizar un control de
las versiones que se están generando de manera
que se puedan identificar las diferentes iteraciones
o fases de ajustes y las diferentes versiones del
software.
Para esto hay herramientas que facilitan realizar
este control; por lo tanto, a continuación se
presentarán estos contenidos, iniciando con el
detalle del proceso.
3.1. Proceso de gestión del cambio
El proceso de gestión del cambio, tiene
como objetivo analizar los ajustes requeridos en
un software y realizar las acciones necesarias
para que se realicen de la manera más ágil y
sencilla y para validar que queden correctamente
implementados. Este proceso inicia desde el
registro de las solicitudes de ajuste encontradas,
hasta la validación de su correcta implementación.
A continuación se puede ver un diagrama que lo
ilustra:
Pruebas
Registro
Gestión de
cambios
Aprovación y
planificacion
Implementación
Figura 1. Proceso de Gestión de cambio.
Fuente: SENA

6
Implementación y
documentación
Iteración
#3
Registro
Análisis
Aprobación y
planificación
Pruebas
Implementación y
documentación
Iteración
#3
Registro
Análisis
Aprobación y
planificación
Pruebas
Implementación y
documentación
Iteración
#3
Registro
Análisis
Aprobación y
planificación
Pruebas
Figura 2. Representación de iteraciones.
Fuente SENA
Retomando lo descrito en el resultado de
aprendizaje tres, en la documentación de registro
de incidentes y resumen de pruebas se puede
evidenciar el record de lo reportado en las
pruebas. Esto se genera por cada iteración o ciclo
de pruebas que se ha realizado.
Los cambios en un software, se pueden generar
desde la ejecución de pruebas que se realiza
normalmente en todos los procesos de creación
de este o también pueden surgir en las etapas de
control que se pueden implementar aun cuando el
software ya se encuentre disponible al público.

7
De esta manera se pueden tener:
• Errores evidenciados.
• Nuevos desarrollos que sean requeridos.
• Mejorasenlasfuncionalidadesimplementadas.
• Cambios debido a alguna actualización
tecnológica: cambio de algún sistema
operativo, un nuevo navegador que se
utiliza en el software y que pertenecen a un
tercero, por lo cual es necesario realizar la
actualización para garantizar la continuidad
de este. En otras ocasiones es la empresa o
la normatividad las que pueden requerir una
actualización de la infraestructura tecnológica
que soporta el software.
Por esta razón, es importante seguir el
proceso de gestión del cambio, ya que muchas
veces se disminuye esta fase considerando los
cambios como algo mínimo y gestionando los
ajustes de manera informal pensando que son
algo sencillo de modificar y aunque pueden existir
cambios que no impacten fuertemente el software,
todo cambio requiere tiempo y genera costos, por
lo tanto es importante poder recopilar la mayor
cantidad de observaciones por cada ciclo de
pruebas que se realice al software.
A continuación se puede resumir el proceso que se
realiza en la gestión de cambios:
Figura 3. Pasos en el proceso de gestión del cambio.
Fuente: https://sites.google.com/site/metodologiareq/capitulo-vi

8
3.1.1. Registro
A partir de esto es necesario realizar el registro
de las no conformidades, incidentes, mejoras o
errores encontrados.
Para esto se recomienda iniciar el registro de
incidentes con la siguiente información:
• Fecha.
• Solicitante.
• Descripción.
• Tipo de cambio (fatales, mejoras, funcionales,
visualización).
Fecha de la
prueba
Persona que
realiza la prueba
Módulo/
funcionalidad
Descripción Tipo de cambio
fatal
mejora
visualización
funcional
Figura 4. Imagen registro inicial de incidentes.
Fuente: SENA
Como complemento a este registro se deben incluir
otros aspectos como:
• Análisis e impacto.
• Funcionalidades o módulos que se afectan en
el software.
• Estado.
• Tiempo estimado de solución.
• Responsable.
• Prioridad.
Con este registro, es necesario realizar una
reunión con el equipo líder de cada funcionalidad
del software para confirmar que el impacto descrito
efectivamente no afecta ninguna otra funcionalidad
de las ya identificadas, para que el equipo conozca
el estado de las solicitudes y a partir de esto para
pasar a la fase de analizar y definir cuáles cambios
serán implementados.

9
CR Funcionales
CRDC - 006,
CREF - 005
CREF - 001
CREF - 005
CREF - 004
CRPF - 002
CRC - 005
CRC - 006
CRPF - 004
CRI - 002
CRPF - 001
N°
1
3
5
6
12
15
19
20
22
23
24
AFECTA
PF Ejecución-PF
Diseño Curricular
PF Ejecución-PF
Calendario
PF Desarrollo
Curricular
PF Ejecución de la
formación
PF Planeación
PF Planeación
PF Certificación
PF Certificación
BD-PF Planeación
PF Inscripción
PF Planeación
FECHA DE
SOLICITUD
22/08/2008
22/08/2008
18/09/2008
18/09/2008
22/08/2008
22/08/2008
22/08/2008
22/08/2008
22/08/2008
22/08/2008
22/08/2008
IMPACTO
ALTO
ALTO
ALTO
ALTO
BAJO
BAJO
BAJO
MEDIO
MEDIO
MEDIO
MEDIO
ESTADO
En definición
Por Definir
Por Definir
Por Definir
Aprobado
Aprobado
Aprobado
Aprobado
Aprobado
Aprobado
Aprobado
DESCRIPCIÓN
Se solicita el desarrollo informático para generar un gráfico que permita
ver gráficamente cada proyecto en el mapa general del programa de
formación (ver anexo 8)
Es necesario tener en cuenta la nueva medición de horas
Se requiere modificar la creación de proyectos de aprendizaje con el fin
de dejarlos asociados a resultados de aprendizaje y no a competencias
completas
se requiere que los aprendices que están actualmente en formación
continuen con la estrategia de formación antigua sin ningún cambio en el
sistema
No hay nada en el anexo 14, por lo cual no entendemos a qué se refiere
el período en el marco de la formación que imparte el SENA
Se requiere incluir otro lugar de desarrollo de la acción de formación,
diferente de la Sede y Subsede, como sedes fuera del Sena
Incluir el N° de registro del certificado y la fecha de expedición del
certificado
Contemplar un aviso que informe que sí el certificado corresponde a una
acción de formación ejecutada entre el año 2000 y 2008 deberá entrar a
la siguiente dirección...
Falta la variable de subsectores a los cuales pertenece el programa de
formación (ver anexo 3)
Actualmente el nivel de tecnólogo exige para la certificación el puntaje
del ICFES. En este sentido se requiere el campo para digitar el valor que
asume esta variable
Proponemos la modificación del Anexo 18 para que mejor se incluya el
horario en el que se desarrollará el programa, en lugar de establecer
jornadas (Anexo 4).
Figura 5. Ejemplo listado de cambios SOFIA Plus, 2008. Fuente SENA

10
3.1.2. Análisis y planificación
Con el registro de los cambio a realizar, se
hace necesario planear cuáles son los cambios
que son pertinentes implementar de acuerdo con
las necesidades del cliente, las prioridades, el tipo
de cambio, la afectación que tiene y por ende la
respectiva prioridad. De esta manera se requiere
establecer fases que permitan abordar aquellos
cambios que son imperativos de ajustar de manera
inmediata y paulatinamente aquellos cambios que
pueden irse ajustando con el tiempo.
Para esto, se sugiere realizar una propuesta
de planeación de atención de los requerimientos
de ajuste o cambios registrados y validarlos con
el cliente de tal modo que exista una aprobación
oficial de las fases a realizar, de los cambios a
implementar y del tiempo que se requiere.
Definición de prioridad
Normalmente las prioridades que se utilizan
son: baja, media y alta. Esta clasificación permite
etiquetar el registro de cambios de acuerdo a
lo que se requiere con más urgencia, según
las necesidades del público objetivo y de las
necesidades del cliente. Es necesario tener en
cuenta el impacto de afectación que tiene cada
cambio pues si es un cambio que impacta varias
áreas y funcionalidades del software, se requerirá
de un mayor tiempo para su solución.
Análisis de los cambios
Se hace necesario evaluar el costo, las
implicaciones, los riesgos asociados, qué recursos
se requieren para implementar el cambio, el
tiempo que requiere. También es necesario definir
la posibilidad de agrupar los cambios o si existe
algún cambio que requiera hacerse de manera
aislada para garantizar la estabilidad del software.
“Algunos criterios que se pueden tener en cuenta
para tomar la decisión de aprobar o rechazar las
solicitudes de cambio son los siguientes:
• Valor del cambio para el proyecto/organización
• Retorno de la inversión.
• Tamaño.
• Complejidad.
• Impacto sobre el rendimiento del producto
(uso de memoria y CPU).
• Recursos disponibles para efectuar el cambio
(humanos y materiales).
• Relación con otros cambios ya aprobados y
en progreso.
• Tiempo estimado para completar el cambio.
• relación con las políticas de la empresa
(satisfacción del cliente, competitividad, etc.)
• existencia de alternativas, etc.” (Ecured, 2014)

11
Fecha de la
prueba
Persona que
realiza la prueba
Módulo/
funcionalidad
Descripción Tipo de
cambio
fatal
mejora
visualización
funcional
Impacto Prioridad
base de datos, front
end, integración alta
baja
media
Responsable de
solucionar
aprobado
no aprobado
no se pudo
probar
no aprobado
Figura 6. Imagen documento registro de incidentes con análisis de cambios.
Fuente: SENA
Planeación
Aparte del registro de cambios, es necesario
realizar el cronograma que indica las fechas que
tomará la implementación de los cambios, las fases
que se tendrán y los tiempos estimados incluyendo
las pruebas finales y entrega del software.
De esta manera, una vez se han analizado
los impactos se debe definir el tiempo que cada
cambio requiere y definir las diferentes versiones
que se pueden tener en el software. Esto indica
que por lo general se implementan cambios por
fases, lo cual varía dependiendo de la dimensión
del software y de la cantidad de ajustes que sean
requeridos.
Fecha de la
prueba
Persona que
realiza la prueba
Módulo/
funcionalidad
Descripción Tipo de
cambio
fatal
mejora
visualización
funcional
Impacto Prioridad
base de datos,front
end,integración alta
baja
media
Responsable de
solucionar
aprobado
no aprobado
no se pudo
probar
no aprobado
Tiempo
estimado
Recursos
requeridos
Versión del
software
Fuente: SENA

12
A partir de esta información se establece el
cronograma con las fechas de inicio y fin para cada
actividad. Al interior de cada versión que se tendrá,
se deberá listar cada cambio, tiempo y recurso
asignado para el cambio o cambios requeridos.
Figura 7. Imagen
ejemplo cronograma
general de gestión de
cambios.
Fuente: SENA
3.1.3. Implementación
Es muy importante al momento de realizar
un cambio almacenar las versiones del software
y realizar el respectivo seguimiento; esto permitirá
asegurarlacorrectaimplementacióndeloscambios
y la estabilidad de cada una de las versiones del
software entregado.
Gestión de
versiones
Seguimiento
a ajustes
Pruebas
finales
Figura 8. Imagen de actividades en la implementación de cambios al software.
Fuente: SENA
Es así como se tienen entonces las siguientes
actividades:

13
El control de versiones es importante no
solamente por la seguridad de tener siempre
una versión anterior a los cambios que se van
implementando, sino también de acuerdo con
el tipo de software que se está trabajando.
Normalmente se realiza un control de versión del
software en su archivo ejecutable y también es
importanterealizarlodelcódigofuente.Sinembargo
dependiendo del software, se puede también tener
información multimedia que va a asociada a la
versión del software, tales como imágenes, audios,
videos, entre otras. Por esta razón es importante
realizar esta gestión de versiones.
Fuente:
http://www.ces.com.uy/documentos/imasd/CES-Presentacion_
Gestion_de_las_Pruebas_Funcionales.pdf P.9

14
En la actividad de control de versiones, se
puede realizar esta gestión de manera manual
y acudiendo al almacenamiento en línea de las
versiones del software, al almacenamiento en un
servidor o al almacenamiento en un equipo local.
Sin embargo, también existen herramientas que
permiten el control de estas versiones como lo
son: CVS, Subversion, SourceSafe, ClearCase,
Darcs, Bazaar, Plastic SCM, Git, SCCS, Mercurial,
Perforce, Fossil SCM, Team Foundation Server.
Actualización de requerimientos
Aparte del documento que contiene el
listado de cambios anteriormente mencionado, y
del cronograma es necesaria la actualización de
la documentación de requerimientos del software,
lo cual facilita la aprobación por parte del cliente
para garantizar que la implementación se realiza
de manera correcta.
Por ejemplo, si el software que se está probando
y ajustando fue documentado bajo la metodología
que contempla casos de uso, diagramas de caso,
diagramas de secuencia, de actividades y de base
de datos; es necesario realizar la actualización de
esos documentos para que junto con la entrega
final del software, los requerimientos queden al día.
3.1.4. Pruebas
Unavezsehanimplementadolosajustes,esnecesario
realizar las pruebas correspondientes y validar:
• El funcionamiento adecuado del servicio que
provee el software.
• La aceptación por parte de los usuarios finales
de los ajustes realizados.
• El cumplimiento de los objetivos proyectados.
• La estabilidad del software.
Pruebas de regresión: con cada cambio
implementado es necesario contemplar la
ejecución de pruebas de las funcionalidades que
pudieron afectarse en el software. Esto permitirá
que se garantice la funcionalidad correcta de este
y evitar que con cada ajuste implementado, algo
que estaba funcionando comience a presentar
fallas. A esto es lo que se le denominan pruebas
de regresión.
Por lo tanto es necesario realizar varias pruebas:
• Pruebas unitarias: aquellas que garantizan el
funcionamiento del módulo o funcionalidad que
fue modificada.
• Pruebas de regresión.
• Pruebas con el usuario final y cliente:
aquellas que permiten validar con el usuario
final la funcionalidad e implementación de
cambios solicitados previamente para asegurar
la aprobación por parte de estos.
Una vez se han tenido resultados positivos, se
procede a dar cierre al ciclo de pruebas de la
implementación del cambio.

SENA: Planificación de pruebas para el módulo de registro en SOFIA Plus

SENA: Planificación de pruebas para el módulo de registro en SOFIA Plus

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a SENA: Planificación de pruebas para el módulo de registro en SOFIA Plus

Similar a SENA: Planificación de pruebas para el módulo de registro en SOFIA Plus (20)

SENA: Planificación de pruebas para el módulo de registro en SOFIA Plus