SlideShare una empresa de Scribd logo
1 de 86
Descargar para leer sin conexión
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
Material RAP - 1
Material RAP - 1
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
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
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
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.
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
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
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
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
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
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
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
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.
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
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
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
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
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
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.
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
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.
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
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.
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
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
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
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
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
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.
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
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
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
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
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
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
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
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.
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
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.
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
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.
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
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.
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
Material RAP - 2
Material RAP - 2
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
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
Creative Commons ............................................................................................20
Tabla de Contenido
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
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.
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
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
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
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
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
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
de rendimiento SOFIA Plus
Fuente: SENA
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
7
Figura 3. Descripción resultados de pruebas
de rendimiento SOFIA Plus
Fuente: SENA
Figura 4. Ejemplo herramienta utilizada en pruebas
de rendimiento SOFIA Plus
Fuente: SENA
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
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.
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
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.
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
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.
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
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.
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
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
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
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.
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
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.
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
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.
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
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
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
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
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
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.
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
19
8. Referencias bibliográficas
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
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
20
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.
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
Material RAP - 3
Material RAP - 3
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
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
7. Referencias bibliográficas ............................................................................23
Créditos..............................................................................................................24
Creative Commons ............................................................................................24
Tabla de Contenido
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
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.
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
4
2. Estructura de Contenido
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
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
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
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
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.
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
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
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
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
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
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
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
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
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
11
Figura 5. Imagen ingreso de datos Bugzilla
Fuente: https://www.youtube.com/watch?v=vBAKYRJgV64 minuto 11
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
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.
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
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
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
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/
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
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.
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
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/
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
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
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
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
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
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:
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
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.
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
21
Figura 16. Imagen Test Studio
Fuente: http://www.telerik.com/teststudio
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
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.
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
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.
7. Referencias bibliográficas
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
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
24
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.
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
Material RAP - 4
Material RAP - 4
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
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
5. Referencias bibliográficas ............................................................................19
Créditos..............................................................................................................20
Creative Commons ............................................................................................20
Tabla de Contenido
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
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.
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
4
2. Estructura de Contenido
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
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
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
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
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.
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
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
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
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.
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
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
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
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)
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
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
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
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:
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
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
FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje
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
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
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

Más contenido relacionado

La actualidad más candente

Metodologia para el desarrollo de sistemas de informacion
Metodologia para el desarrollo de sistemas de informacionMetodologia para el desarrollo de sistemas de informacion
Metodologia para el desarrollo de sistemas de informacionEdgarBetancourt13
 
03 7n2is trabajo-interfaz usuario
03 7n2is trabajo-interfaz usuario03 7n2is trabajo-interfaz usuario
03 7n2is trabajo-interfaz usuarioManuel Mujica
 
Tipos de pruebas de software
Tipos de pruebas de softwareTipos de pruebas de software
Tipos de pruebas de softwareGuillermo Lemus
 
Unidad 3 topicos avanzados de programacion
Unidad 3 topicos avanzados de programacionUnidad 3 topicos avanzados de programacion
Unidad 3 topicos avanzados de programacionIrving Che
 
Ventajas y desventajas de moprosoft
Ventajas y desventajas de moprosoftVentajas y desventajas de moprosoft
Ventajas y desventajas de moprosoftChuyito Alvarado
 
Patrones de diseño de GoF
Patrones de diseño de GoFPatrones de diseño de GoF
Patrones de diseño de GoFYaskelly Yedra
 
Metodologias Para El Analisis Y Diseño De Sistemas.
Metodologias Para El Analisis Y Diseño De Sistemas.Metodologias Para El Analisis Y Diseño De Sistemas.
Metodologias Para El Analisis Y Diseño De Sistemas.German Rodriguez
 
Ventajas y desventajas de cmmi
Ventajas y desventajas de cmmiVentajas y desventajas de cmmi
Ventajas y desventajas de cmmiSandrea Rodriguez
 
Modelado del análisis
Modelado del análisisModelado del análisis
Modelado del análisisJavier Rivera
 
BPMN 2.0 en el Proceso de Desarrollo de Software
BPMN 2.0 en el Proceso de Desarrollo de SoftwareBPMN 2.0 en el Proceso de Desarrollo de Software
BPMN 2.0 en el Proceso de Desarrollo de SoftwareJohan Robles Solano
 

La actualidad más candente (20)

Roles desarrollo del software
Roles desarrollo del softwareRoles desarrollo del software
Roles desarrollo del software
 
Metodologia para el desarrollo de sistemas de informacion
Metodologia para el desarrollo de sistemas de informacionMetodologia para el desarrollo de sistemas de informacion
Metodologia para el desarrollo de sistemas de informacion
 
Java swing
Java swingJava swing
Java swing
 
03 7n2is trabajo-interfaz usuario
03 7n2is trabajo-interfaz usuario03 7n2is trabajo-interfaz usuario
03 7n2is trabajo-interfaz usuario
 
Metodología RUP
Metodología RUPMetodología RUP
Metodología RUP
 
Tipos de pruebas de software
Tipos de pruebas de softwareTipos de pruebas de software
Tipos de pruebas de software
 
Unidad 3 topicos avanzados de programacion
Unidad 3 topicos avanzados de programacionUnidad 3 topicos avanzados de programacion
Unidad 3 topicos avanzados de programacion
 
Ventajas y desventajas de moprosoft
Ventajas y desventajas de moprosoftVentajas y desventajas de moprosoft
Ventajas y desventajas de moprosoft
 
Interrupciones
InterrupcionesInterrupciones
Interrupciones
 
Patrones de diseño de GoF
Patrones de diseño de GoFPatrones de diseño de GoF
Patrones de diseño de GoF
 
Gestión de la Calidad en Proyectos de Software
Gestión de la Calidad en Proyectos de SoftwareGestión de la Calidad en Proyectos de Software
Gestión de la Calidad en Proyectos de Software
 
Metodologias Para El Analisis Y Diseño De Sistemas.
Metodologias Para El Analisis Y Diseño De Sistemas.Metodologias Para El Analisis Y Diseño De Sistemas.
Metodologias Para El Analisis Y Diseño De Sistemas.
 
Requerimientos del software
Requerimientos del software Requerimientos del software
Requerimientos del software
 
Modelo v
Modelo vModelo v
Modelo v
 
Ventajas y desventajas de cmmi
Ventajas y desventajas de cmmiVentajas y desventajas de cmmi
Ventajas y desventajas de cmmi
 
Tolerancia a fallos
Tolerancia a fallosTolerancia a fallos
Tolerancia a fallos
 
Modelado del análisis
Modelado del análisisModelado del análisis
Modelado del análisis
 
Metodologia kendall y Kendall
Metodologia kendall y KendallMetodologia kendall y Kendall
Metodologia kendall y Kendall
 
Metodo espiral
Metodo espiralMetodo espiral
Metodo espiral
 
BPMN 2.0 en el Proceso de Desarrollo de Software
BPMN 2.0 en el Proceso de Desarrollo de SoftwareBPMN 2.0 en el Proceso de Desarrollo de Software
BPMN 2.0 en el Proceso de Desarrollo de Software
 

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

Control de lectura
Control de lecturaControl de lectura
Control de lecturaelssalinas
 
Taller 3 calidad_de_software_jcom
Taller 3 calidad_de_software_jcomTaller 3 calidad_de_software_jcom
Taller 3 calidad_de_software_jcomJuan Carlos Ospina
 
Aplicación web para el registro y seguimiento de los recursos asignados en pr...
Aplicación web para el registro y seguimiento de los recursos asignados en pr...Aplicación web para el registro y seguimiento de los recursos asignados en pr...
Aplicación web para el registro y seguimiento de los recursos asignados en pr...Gerardo Jose Inciarte Villalobos
 
Actividad 3 prueba de software juan esteban uribe m
Actividad 3 prueba de software juan esteban uribe mActividad 3 prueba de software juan esteban uribe m
Actividad 3 prueba de software juan esteban uribe mjuanesellanza1
 
Unidad 3 aseguramiento de la calidad de los
Unidad 3 aseguramiento de la calidad de losUnidad 3 aseguramiento de la calidad de los
Unidad 3 aseguramiento de la calidad de lospabloreyes154
 
Software quality assurance (sqa) parte iii-plan de calidad y prueba v3.0
Software quality assurance (sqa)  parte iii-plan de calidad y prueba v3.0Software quality assurance (sqa)  parte iii-plan de calidad y prueba v3.0
Software quality assurance (sqa) parte iii-plan de calidad y prueba v3.0Renato Gonzalez
 
RMyA - Presentación Jornada ORT Estandar ISO IEC 29119 - 2011 v1.0
RMyA - Presentación Jornada ORT Estandar ISO IEC 29119 - 2011 v1.0RMyA - Presentación Jornada ORT Estandar ISO IEC 29119 - 2011 v1.0
RMyA - Presentación Jornada ORT Estandar ISO IEC 29119 - 2011 v1.0Pilar Barrio
 
AF3-Investigación sobre SQA V1.docx
AF3-Investigación sobre SQA V1.docxAF3-Investigación sobre SQA V1.docx
AF3-Investigación sobre SQA V1.docxErickdowski9Gamer
 
14 Unidad-4. Aseguramiento de Calidad de Software QA, 4.1. Aplicación del ase...
14 Unidad-4. Aseguramiento de Calidad de Software QA, 4.1. Aplicación del ase...14 Unidad-4. Aseguramiento de Calidad de Software QA, 4.1. Aplicación del ase...
14 Unidad-4. Aseguramiento de Calidad de Software QA, 4.1. Aplicación del ase...Luis Fernando Aguas Bucheli
 
Ces cacic07-automatizacion y-gestion_pruebas_funcionales
Ces cacic07-automatizacion y-gestion_pruebas_funcionalesCes cacic07-automatizacion y-gestion_pruebas_funcionales
Ces cacic07-automatizacion y-gestion_pruebas_funcionalesginacris
 
Diseã±os de planes_de_pruebas_de_software1
Diseã±os de planes_de_pruebas_de_software1Diseã±os de planes_de_pruebas_de_software1
Diseã±os de planes_de_pruebas_de_software1naviwz
 
Implementacion de software
Implementacion de softwareImplementacion de software
Implementacion de softwareTom Rodriguez
 
Metodologia xp
Metodologia xpMetodologia xp
Metodologia xp0202278446
 

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

Fundamentos Rational Tester
Fundamentos Rational TesterFundamentos Rational Tester
Fundamentos Rational Tester
 
Pruebas de software
Pruebas de softwarePruebas de software
Pruebas de software
 
Control de lectura
Control de lecturaControl de lectura
Control de lectura
 
Ciclo de vida
Ciclo de vidaCiclo de vida
Ciclo de vida
 
Taller 3 calidad_de_software_jcom
Taller 3 calidad_de_software_jcomTaller 3 calidad_de_software_jcom
Taller 3 calidad_de_software_jcom
 
Aplicación web para el registro y seguimiento de los recursos asignados en pr...
Aplicación web para el registro y seguimiento de los recursos asignados en pr...Aplicación web para el registro y seguimiento de los recursos asignados en pr...
Aplicación web para el registro y seguimiento de los recursos asignados en pr...
 
Guia 4 de mantenimiento
Guia  4 de mantenimientoGuia  4 de mantenimiento
Guia 4 de mantenimiento
 
Actividad 3 prueba de software juan esteban uribe m
Actividad 3 prueba de software juan esteban uribe mActividad 3 prueba de software juan esteban uribe m
Actividad 3 prueba de software juan esteban uribe m
 
Unidad 3 aseguramiento de la calidad de los
Unidad 3 aseguramiento de la calidad de losUnidad 3 aseguramiento de la calidad de los
Unidad 3 aseguramiento de la calidad de los
 
Software quality assurance (sqa) parte iii-plan de calidad y prueba v3.0
Software quality assurance (sqa)  parte iii-plan de calidad y prueba v3.0Software quality assurance (sqa)  parte iii-plan de calidad y prueba v3.0
Software quality assurance (sqa) parte iii-plan de calidad y prueba v3.0
 
RMyA - Presentación Jornada ORT Estandar ISO IEC 29119 - 2011 v1.0
RMyA - Presentación Jornada ORT Estandar ISO IEC 29119 - 2011 v1.0RMyA - Presentación Jornada ORT Estandar ISO IEC 29119 - 2011 v1.0
RMyA - Presentación Jornada ORT Estandar ISO IEC 29119 - 2011 v1.0
 
Guia actp2 aa1
Guia actp2 aa1Guia actp2 aa1
Guia actp2 aa1
 
AF3-Investigación sobre SQA V1.docx
AF3-Investigación sobre SQA V1.docxAF3-Investigación sobre SQA V1.docx
AF3-Investigación sobre SQA V1.docx
 
14 Unidad-4. Aseguramiento de Calidad de Software QA, 4.1. Aplicación del ase...
14 Unidad-4. Aseguramiento de Calidad de Software QA, 4.1. Aplicación del ase...14 Unidad-4. Aseguramiento de Calidad de Software QA, 4.1. Aplicación del ase...
14 Unidad-4. Aseguramiento de Calidad de Software QA, 4.1. Aplicación del ase...
 
Estrategias de venta
Estrategias de ventaEstrategias de venta
Estrategias de venta
 
Estrategias
Estrategias Estrategias
Estrategias
 
Ces cacic07-automatizacion y-gestion_pruebas_funcionales
Ces cacic07-automatizacion y-gestion_pruebas_funcionalesCes cacic07-automatizacion y-gestion_pruebas_funcionales
Ces cacic07-automatizacion y-gestion_pruebas_funcionales
 
Diseã±os de planes_de_pruebas_de_software1
Diseã±os de planes_de_pruebas_de_software1Diseã±os de planes_de_pruebas_de_software1
Diseã±os de planes_de_pruebas_de_software1
 
Implementacion de software
Implementacion de softwareImplementacion de software
Implementacion de software
 
Metodologia xp
Metodologia xpMetodologia xp
Metodologia xp
 

Último

SISTEMA INTEGRADO DE ADMINISTRACION FINANCIERA - SIAF MODULO ADMINISTRATIVO
SISTEMA INTEGRADO DE ADMINISTRACION FINANCIERA - SIAF MODULO ADMINISTRATIVOSISTEMA INTEGRADO DE ADMINISTRACION FINANCIERA - SIAF MODULO ADMINISTRATIVO
SISTEMA INTEGRADO DE ADMINISTRACION FINANCIERA - SIAF MODULO ADMINISTRATIVOELIAMARYTOVARFLOREZD
 
Introducción a Plone CMS - World Plone Day 2024
Introducción a Plone CMS - World Plone Day 2024Introducción a Plone CMS - World Plone Day 2024
Introducción a Plone CMS - World Plone Day 2024Leonardo J. Caballero G.
 
Semana 5-Conceptualización del lenguaje de programación C++
Semana 5-Conceptualización del lenguaje de programación C++Semana 5-Conceptualización del lenguaje de programación C++
Semana 5-Conceptualización del lenguaje de programación C++luzgaray6
 
MacOS SISTEMA OPERATIVO CARACTERISTICAS.pptx
MacOS SISTEMA OPERATIVO CARACTERISTICAS.pptxMacOS SISTEMA OPERATIVO CARACTERISTICAS.pptx
MacOS SISTEMA OPERATIVO CARACTERISTICAS.pptxcalzadillasluis134
 
Presentación de html, css y javascript.
Presentación  de html, css y javascript.Presentación  de html, css y javascript.
Presentación de html, css y javascript.CeteliInmaculada
 
Theme design in Plone 6 - World Plone Day 2024
Theme design in Plone 6 - World Plone Day 2024Theme design in Plone 6 - World Plone Day 2024
Theme design in Plone 6 - World Plone Day 2024Leonardo J. Caballero G.
 

Último (6)

SISTEMA INTEGRADO DE ADMINISTRACION FINANCIERA - SIAF MODULO ADMINISTRATIVO
SISTEMA INTEGRADO DE ADMINISTRACION FINANCIERA - SIAF MODULO ADMINISTRATIVOSISTEMA INTEGRADO DE ADMINISTRACION FINANCIERA - SIAF MODULO ADMINISTRATIVO
SISTEMA INTEGRADO DE ADMINISTRACION FINANCIERA - SIAF MODULO ADMINISTRATIVO
 
Introducción a Plone CMS - World Plone Day 2024
Introducción a Plone CMS - World Plone Day 2024Introducción a Plone CMS - World Plone Day 2024
Introducción a Plone CMS - World Plone Day 2024
 
Semana 5-Conceptualización del lenguaje de programación C++
Semana 5-Conceptualización del lenguaje de programación C++Semana 5-Conceptualización del lenguaje de programación C++
Semana 5-Conceptualización del lenguaje de programación C++
 
MacOS SISTEMA OPERATIVO CARACTERISTICAS.pptx
MacOS SISTEMA OPERATIVO CARACTERISTICAS.pptxMacOS SISTEMA OPERATIVO CARACTERISTICAS.pptx
MacOS SISTEMA OPERATIVO CARACTERISTICAS.pptx
 
Presentación de html, css y javascript.
Presentación  de html, css y javascript.Presentación  de html, css y javascript.
Presentación de html, css y javascript.
 
Theme design in Plone 6 - World Plone Day 2024
Theme design in Plone 6 - World Plone Day 2024Theme design in Plone 6 - World Plone Day 2024
Theme design in Plone 6 - World Plone Day 2024
 

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

  • 1. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje Material RAP - 1 Material RAP - 1
  • 2. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje 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. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje 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. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje 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. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje 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. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje 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. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje 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. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje 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. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje 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. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje 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. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje 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. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje 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. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje 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. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje 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. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje 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. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje 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. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje 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. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje 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. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje 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. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje 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. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje 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. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje 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.
  • 23. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje Material RAP - 2 Material RAP - 2
  • 24. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje 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 Creative Commons ............................................................................................20 Tabla de Contenido
  • 25. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje 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.
  • 26. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje 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
  • 27. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje 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
  • 28. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje 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 de rendimiento SOFIA Plus Fuente: SENA
  • 29. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje 7 Figura 3. Descripción resultados de pruebas de rendimiento SOFIA Plus Fuente: SENA Figura 4. Ejemplo herramienta utilizada en pruebas de rendimiento SOFIA Plus Fuente: SENA
  • 30. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje 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.
  • 31. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje 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.
  • 32. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje 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.
  • 33. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje 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.
  • 34. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje 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
  • 35. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje 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.
  • 36. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje 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.
  • 37. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje 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.
  • 38. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje 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
  • 39. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje 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
  • 40. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje 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.
  • 41. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje 19 8. Referencias bibliográficas 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
  • 42. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje 20 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.
  • 43. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje Material RAP - 3 Material RAP - 3
  • 44. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje 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 7. Referencias bibliográficas ............................................................................23 Créditos..............................................................................................................24 Creative Commons ............................................................................................24 Tabla de Contenido
  • 45. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje 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.
  • 46. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje 4 2. Estructura de Contenido 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
  • 47. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje 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
  • 48. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje 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.
  • 49. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje 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
  • 50. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje 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
  • 51. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje 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
  • 52. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje 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
  • 53. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje 11 Figura 5. Imagen ingreso de datos Bugzilla Fuente: https://www.youtube.com/watch?v=vBAKYRJgV64 minuto 11
  • 54. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje 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.
  • 55. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje 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
  • 56. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje 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/
  • 57. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje 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.
  • 58. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje 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/
  • 59. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje 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
  • 60. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje 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
  • 61. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje 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:
  • 62. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje 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.
  • 63. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje 21 Figura 16. Imagen Test Studio Fuente: http://www.telerik.com/teststudio
  • 64. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje 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.
  • 65. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje 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. 7. Referencias bibliográficas 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
  • 66. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje 24 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.
  • 67. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje Material RAP - 4 Material RAP - 4
  • 68. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje 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 5. Referencias bibliográficas ............................................................................19 Créditos..............................................................................................................20 Creative Commons ............................................................................................20 Tabla de Contenido
  • 69. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje 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.
  • 70. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje 4 2. Estructura de Contenido 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
  • 71. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje 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
  • 72. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje 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.
  • 73. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje 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
  • 74. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje 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.
  • 75. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje 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
  • 76. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje 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)
  • 77. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje 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
  • 78. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje 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:
  • 79. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje 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
  • 80. FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje 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.