PRUEBAS MANUALES DE SOFTWARE (TESTING)

Modalidad

Prácticas en empresa

Presentado por

Juan José Prieto Sánchez

Tutor

Ing. Paola Mora Holguín

Corporación Universitaria UNITEC

Facultad de Ingeniería

Ingeniería en Telecomunicaciones

Prácticas profesionales

Bogotá D.C.

Octubre 2020

1
 CONTENIDO

LISTADO DE FIGURAS ............................................................................................................... 3

INTRODUCCION .......................................................................................................................... 4

1. PLANTEAMIENTO DEL PROBLEMA ................................................................................ 5

1.1. DESCRIPCIÓN DEL PROBLEMA ................................................................................ 5

1.2. DELIMITACIÓN DEL PROBLEMA ............................................................................. 5

1.3. PREGUNTAS DE INVESTIGACIÓN ............................................................................ 6

1.4. JUSTIFICACIÓN............................................................................................................. 6

1.5. OBJETIVOS..................................................................................................................... 7

2. MARCO DE REFERENCIA................................................................................................... 8

2.1. MARCO CONTEXTUAL ............................................................................................... 8

2.2. MARCO TEÓRICO CONCEPTUAL ............................................................................. 9

2.3. MARCO DE REFERENCIA LEGAL ........................................................................... 11

3. DISEÑO METODOLÓGICO ............................................................................................... 16

4. PROPUESTA DEL PROYECTO O PRÁCTICA ................................................................. 20

4.1. PLAN DE TRABAJO .................................................................................................... 20

4.2. CRONOGRAMA DE TRABAJO.................................................................................. 23

BIBLIOGRAFIA .......................................................................................................................... 24

ANEXOS ...................................................................................................................................... 25

2
 LISTADO DE FIGURAS

Figura 1. Calidad Externa e Interna ............................................................................................. 12

Figura 2. Modelo de Calidad Noma ISO/IEC 9126..................................................................... 13

3
 INTRODUCCION

El propósito de este trabajo es realizar pruebas de software para la empresa OPENTIC, en el cual
se explica todo el proceso de cómo se ejecutan las pruebas unitarias de acuerdo con los planes de
prueba establecidos, además se explica el modo de documentación del resultado de las pruebas y
como se reporta mediante casos las incidencias resultados de las mismas.

Con estas pruebas se busca garantizar el buen funcionamiento del software desarrollado, por
esta razón solicité a la compañía OPENTIC una oportunidad para brindarle mis servicios y así
buscar una solución que sirva para optimizar los procesos que con llevan las pruebas de software
realizadas para los diferentes clientes que tiene la compañía.

4
 1. PLANTEAMIENTO DEL PROBLEMA

1.1.DESCRIPCIÓN DEL PROBLEMA

La compañía Transmilenio S.A. realiza control, seguimiento y vigilancia de las obligaciones

de los concesionarios administradores de los vehículos automotores tanto SITP como
Transmilenio, sin embargo, este proceso se realizar de manera manual cargando la
documentación requerida por parte de los concesionarios en documentos Excel, los cuales no
son oportunos, son susceptibles a errores y modificaciones, por lo que no es posible realizar
el proceso de manera eficiente. Por consiguiente, se requiere para su flota de buses un
sistema de información en el cual se pueda realizar control seguimiento y vigilancia en
tiempo real de las obligaciones de los concesionarios. La implementación de dicho sistema
de información se hace necesaria para sistematizar las inspecciones diarias de los vehículos
con el fin de verificar el aseo, la imagen y estado mecánico de los buses, verificar que los
vehículos cumplan con los requisitos establecidos y en general la vida útil de los mismos.

De acuerdo con los anteriores requerimientos la compañía decide contratar los servicios
de la compañía ITM Consulting de Colombia para que ellos a su vez realicen la construcción
e implementación del sistema de información requerido. Así mismo ITM Consulting de
Colombia con el fin de garantizar la correcta construcción del software toma la decisión de
contratar los servicios profesionales de la compañía OPENTIC por su alta experiencia en
calidad de software.

1.2. DELIMITACIÓN DEL PROBLEMA

Como la contratación se realizó con la compañía OPENTIC, el alcance de la práctica consiste

en realizar el plan de pruebas y la ejecución de pruebas de calidad para el sistema de
información de control, seguimiento y vigilancia de la compañía Transmilenio S.A.

5
 Realizar pruebas es la forma de asegurar que lo que quiere que haga el programa lo haga
y lo haga sin errores. Para apoyar la solución de la problemática actual, se decidió realizar
pruebas manuales, es decir que requieren de interacción humana, la persona que realiza las
pruebas se pone en el rol del usuario final y ejecuta el plan de pruebas, esto con el fin de
verificar el estado de la construcción del software y en caso de presentar inconsistencias en
las pruebas realizadas, se debe reportar la incidencia a los ingenieros desarrolladores para que
realicen las correcciones correspondientes.

1.3. PREGUNTAS DE INVESTIGACIÓN

¿Cuál es la importancia de las pruebas de calidad de software en la construcción de un

sistema de información?

1.4. JUSTIFICACIÓN

La problemática principal que tiene el sistema de transporte público es el hecho que no se

tiene tiempo de verificar el vehículo automotor, está revisión debe hacerse a diario en horas
de la mañana antes que el vehículo salga a realizar sus recorridos, la cual consiste en verificar
los documentos del vehículo, documentos del conductor de turno y realizar el peritaje del
vehículo; como sabemos que estos vehículos están dispuestos a realizar hasta dos jornadas
continuas es necesario realizar una buena revisión del vehículo automotor a diario, para esto
se decidió diseñar e implementar un sistema de información que facilite la verificación
documental y el peritaje del vehículo.

Al tratarse de una problemática que actualmente afecta e impacta negativamente la ciudad

de Bogotá, donde diariamente transitan miles de personas que se afectan por los trancones y
las constantes fallas de los buses utilizados en el transporte masivo, personalmente me sentí
muy atraído de poder participar en este proyecto y aportar mis conocimientos profesionales a
la comunidad y a su vez apoyar al mejoramiento del desarrollo de la ciudad. Es así como

6
decidí aprovechar la oportunidad de la práctica profesional y poderme involucrar en este
proyecto, el cual consiste en diseñar y ejecutar el plan de pruebas técnicas y funcionales al
sistema de información, esta es una fase fundamental e importante a la hora de implementar
un sistema de información, ya que con estas pruebas se busca verificar y garantizar que los
requerimientos del cliente se cumplen a satisfacción con la solución de software
implementada.

1.5.OBJETIVOS

Objetivo general

Adquirir conocimientos de como diseñar y ejecutar un plan de pruebas a un sistema de

información, con el fin de que a futuro yo pueda trabajar en esta área o buscar un
emprendimiento relacionado con la misma.

Objetivos específicos

• Aprender a diseñar un plan de pruebas a partir de los requerimientos

• Adquirir conocimientos lógicos para poder orientar las pruebas de software y que
estas cumplan con criterios de calidad necesarios
• Contribuir al mejoramiento del desarrollo de la ciudad

7
 2. MARCO DE REFERENCIA

2.1.MARCO CONTEXTUAL

Las pruebas de software son técnicas cuyo objetivo es proporcionar información objetiva
sobre la calidad del producto, es una actividad más en el proceso de calidad. Las pruebas son
básicamente un conjunto de actividades dentro del desarrollo de software. Dependiendo del
tipo de pruebas, estas actividades podrán ser implementadas en cualquier momento de dicho
proceso de desarrollo.

La historia de las pruebas de software siendo organizadas por un criterio de orientación se

pueden dividir en cinco intervalos temporales que son:

• Antes del año 1956. Periodo orientado a debugging: En 1949 el autor A.Turing
redacta el artículo “Checking a Large Routine” donde habla sobre el uso de pruebas
de corrección. En esa época todas las pruebas estaban enfocadas en corregir el código
fuente. Estas pruebas las realizaban los programadores y no había diferencia entre
checkout, debugging y testing. (SQASA, 2020)

• Entre los años 1957 y 1978. Periodo orientado a demostración: Periodo en que las
pruebas se centraban en asegurar que el programa funcione “Debugging” y que el
programa resuelva el problema “testing”. Para este tipo de pruebas es necesario
realizar una prueba de forma masiva al final del desarrollo del software para garantizar
que se cumplan las especificaciones. (SQASA, 2020)

• Entre los años 1979 y 1982. Periodo orientado a destrucción: En 1979 el autor
G.J.Myers publica un artículo donde expone que las pruebas de software son el
proceso de ejecutar un programa con la intención de encontrar errores. Myers cambia
el paradigma de las pruebas, realizando pruebas intencionales hasta hacerlo fallar.
(SQASA, 2020).

8
 • Entre los años 1983 y 1984. Periodo orientado a evaluación: En el año 1983 NBS
FIPS (National bureau of standards) propone y describe una metodología que integra
análisis, revisión y testing en el ciclo de vida del desarrollo del software. Esto con el
fin de confirmar la calidad de los sistemas software ejercitando sistemáticamente el
software en unas circunstancias cuidadosamente controladas. (SQASA, 2020)

• Entre los años 1985 en adelante. Periodo orientado a prevención: En este año se
implementan STEP (Systematic Test and Evaluation Process) sobre los estándares
formales IEEE 829-1983 y 828-1998. Con esta práctica se obtiene que las pruebas del
software cobren una mayor importancia en el ciclo de desarrollo de software con lo
que se abre la posibilidad de integrar pruebas en las diferentes fases. (SQASA, 2020)

Durante esta época las pruebas se diversifican para cubrir todas las fases del desarrollo,
poder comprobar todos los tipos de artefactos, prototipos, modelos, módulos, subsistemas
y sistemas que componen los productos software del momento. Las buenas prácticas de
pruebas de calidad de software actualmente se realizan el todo el mundo, con el objetivo
de garantizar la calidad del software, mitigar errores en desarrollo y las diferencias entre
los que requieren los usuarios y el producto finales que se les entrega. Estas buenas
prácticas deben ir de la mano de una metodología y en especial ágil, con el fin de
identificar errores a tiempos tempranos y se pueda corregir lo más pronto posible las
falencias encontradas.

2.2.MARCO TEÓRICO CONCEPTUAL

Importancia de las pruebas en desarrollo de software: Es importante realizar pruebas en

el desarrollo del software ya que pueden aparecer errores en cualquier etapa del ciclo de vida
del desarrollo, normalmente el código final presenta errores de requerimientos, como fallas
de diseño o funcionalidad para esto es necesario realizar pruebas de software, este tipo de
pruebas son costosas, pero si comparamos con las fallas que pueda llegar a tener el software
en funcionamiento puede llegar a ser mucho mayor. Además de esto cuando se realizan

9
pruebas de software se valida que lo que el usuario final requiere en realidad sea lo que se
desarrolló, es decir que lo que se definió en los requerimientos coincida con el desarrollo de
software realizado.

En resumen, podemos decir que los objetivos principales de realizar pruebas son:

• Detectar un error especifico

• Validar e identificar que el desarrollo de software no impacte las demás funcionalidades
que se encuentran en desarrollo o incluso que ya se encuentran estabilizadas en
operación.
• Validar y garantizar que los requerimientos estén acordes con la funcionalidad
desarrollada

Otro tema importante de recordar son los atributos que debería tener una buena prueba

• Intentar obtener la más alta probabilidad de encontrar un error

• No debe ser redundante
• No debe ser ni demasiado sencilla ni demasiado compleja

Hay dos clases de pruebas que son: Las pruebas manuales y las pruebas automatizadas, en
nuestro caso para el proyecto se realizaron pruebas manuales.

Para está aplicación se realizaron pruebas unitarias con el fin de comprobar el correcto
funcionamiento de cada módulo según el plan de pruebas y los requerimientos definidos.
Esto nos permite asegurar que todos los módulos del sistema desarrollado funcionen
correctamente por separado.

Otro tipo de nivel de pruebas son las de integración la cual consiste en unir las pruebas que
se realizaron unitariamente y construir una estructura de programa que determine el diseño.
Logrando validar e identificar si al integrar los diferentes códigos fuentes se presenten
errores.

Una vez terminadas las pruebas de integración se debe realizar una validación al software,
estas pruebas se concentran en las acciones visibles para el usuario.

10
 Cuando el software se encuentra integrado al sistema se deben realizar pruebas de estrés o
resistencia, la cual nos demuestra como responderá el sistema a situaciones anormales de
recursos y pruebas de recuperación y de rendimiento.

Para finalizar se realiza la entrega al cliente con una prueba de aceptación, el usuario
prueba el software en su propio entorno y confirma la aceptación o rechazo de la entrega.
(YUNBIT, 2016)

2.3.MARCO DE REFERENCIA LEGAL

Existen unos estándares de calidad del software con el fin de ofrecer una mayor
confiabilidad, mantenibilidad en concordancia con los requisitos exigidos como son
utilización de metodologías para el diseño, programación, prueba y análisis del software
desarrollado, sin embargo, ninguno es camisa de fuerza a la hora de implementar un
proyecto, lo ideal es que el líder del proyecto elija el estándar que mejor se adapta a las
necesidades del proyecto y de la organización.

• NORMA ISO/IEC

La norma ISO/IEC 9126 de 1991, norma para evaluar los productos de software, indica las
características de la calidad y los lineamientos para su uso, fue desarrollada para dar soporte
a aquellas necesidades; las características de calidad y sus métricas asociadas, es útil tanto
como para evaluar el producto como para definir los requerimientos de la calidad y otros
usos.

La norma presenta dos modelos de calidad, el primero referido a la calidad interna y

externa y el segundo modelo referido a la calidad en uso, a continuación, se describe cada
uno de ellos.

La calidad externa es la totalidad de las características del producto software desde una
perspectiva externa. También podemos decir que es la calidad del software cuando es
ejecutado, la cual es medida y evaluada mientras se prueba en un ambiente simulado, con
datos simulados y usando métricas externas. Durante las pruebas, muchas fallas serán

11
descubiertas y eliminadas. Sin embargo, algunas fallas todavía pueden permanecer después
de las pruebas. Como es difícil corregir la arquitectura de software u otros aspectos
fundamentales del diseño del software, el diseño fundamental permanece sin cambios a
través de las pruebas.

Figura 1. Calidad Externa e Interna

Fuente: tomada de (MGINFORMATICA, s.f.)

• NORMA ISO/IEC 9126

Define la calidad en uso como la perspectiva del usuario de la calidad del producto software
cuando éste es usado en un ambiente específico y un contexto de uso específico. Se encarga
de medir la extensión para la cual los usuarios pueden conseguir sus metas en un ambiente
particular, en vez de medir las propiedades del software en sí mismo.

El modelo de la calidad en uso muestra un conjunto de 4 características: efectividad,

productividad, integridad, y satisfacción.

12
 Figura 2. Modelo de Calidad Noma ISO/IEC 9126

Fuente: tomada de (Carreras Montoto, 2012)

• SQuaRE

Está formada por las siguientes divisiones:

✓ ISO/IEC 2500n. División de gestión de calidad. Los estándares que forman esta
división definen todos los modelos comunes, términos y referencias a los que se indica en
las demás divisiones de SQuaRE.

✓ ISO/IEC 2501n. División del modelo de calidad. El estándar que conforma esta
división presenta un modelo de calidad detallado, incluyendo características para la
calidad interna, externa y en uso.

✓ ISO/IEC 2502n. División de mediciones de calidad. Los estándares pertenecientes a

esta división incluyen un modelo de referencia de calidad del producto software,
definiciones matemáticas de las métricas de calidad y una guía práctica para su
aplicación.

✓ ISO/IEC 2503n. División de requisitos de calidad. Los estándares que forman parte de
esta división ayudan a especificar los requisitos de calidad. Estos requisitos pueden ser
usados en el proceso de especificación de requisitos de calidad para un producto software

13
 que va a ser desarrollado ó como entrada para un proceso de evaluación. El proceso de
definición de requisitos se guía por el establecido en la norma ISO/IEC 15288 (ISO,
2003).

✓ ISO/IEC 2504n. División de evaluación de la calidad. Estos estándares proporcionan

requisitos, recomendaciones y guías para la evaluación de un producto software, tanto si
la llevan a cabo evaluadores, como clientes o desarrolladores.

✓ ISO/IEC 25050–25099. Estándares de extensión SQuaRE. Incluyen requisitos para la

calidad de productos de software “Off-The-Self” y para el formato común de la industria
(CIF) para informes de usabilidad.

• SPICE

Es un estándar importante iniciativa internacional para apoyar el desarrollo de una Norma

Internacional para la Evaluación de Procesos de Software. El proyecto tiene tres objetivos
principales: Para desarrollar un proyecto de trabajo para un estándar para la evaluación de
procesos de software. Para llevar a cabo los ensayos de la industria de la norma emergente.
Para promover la transferencia de tecnología de la evaluación de procesos de software en la
industria mundial del software a nivel mundial. (Simón Sánchez & Díaz Sarmiento, 2009)

El estándar SPICE creciente en número de métodos de evaluación disponibles, y la creciente

utilización de la técnica comercial en áreas sensibles, fueron los factores clave que
impulsaron el desarrollo y la aceptación de una propuesta para desarrollar un estándar
internacional para la evaluación de procesos de software. (Simón Sánchez & Díaz Sarmiento,
2009).

Una Norma Internacional sobre Evaluación de Procesos de Software ofrecerá los siguientes
beneficios a la industria y los usuarios del software: Beneficios para la Industria del Software
Los proveedores de software se someterá a un solo esquema de proceso de evaluación. Las
organizaciones de desarrollo de software tendrán una herramienta para iniciar y sostener un
proceso continuo de mejora. Los directores de programas tendrán un medio para garantizar

14
que su desarrollo de software está en consonancia y apoya, las necesidades comerciales de la
organización. (Simón Sánchez & Díaz Sarmiento, 2009).

• CMMI

“Es un modelo de mejora de los procesos de construcción de software que provee los
elementos necesarios para determinar su efectividad. Este modelo puede ser utilizado como
guía para mejorar las actividades de un proyecto, área u organización, ya que proporciona un
marco de referencia para evaluar la efectividad de los procesos actuales, facilitando con ello
la definición de actividades, prioridades y metas para garantizar la mejora continua. Es el
estándar más conocido para la mejora de procesos en mejora de procesos para el desarrollo
de proyectos, gestión de proveedores y gestión de servicio. (Simón Sánchez & Díaz
Sarmiento, 2009) y (Karron, 2013).

El CMMI establece cinco niveles de madurez los cuales son: Nivel 0: Incompleto El proceso
no se realiza, o no se consiguen los objetivos:

✓ Nivel 1: Inicial o ejecutando: Este es el nivel en donde todas las empresas que no tienen
procesos, es donde el proceso se ejecuta y se logra su objetivo, así sea fuera de
presupuesto y de cronograma. (Simón Sánchez & Díaz Sarmiento, 2009)

✓ Nivel 2: Repetible: Se da cuando el éxito de los resultados obtenidos se puede repetir.

(Simón Sánchez & Díaz Sarmiento, 2009)

✓ Nivel 3: Definido: Significa que la forma de desarrollar proyectos está definida,

establecida, documentada y que existen métricas. (Simón Sánchez & Díaz Sarmiento,
2009)

✓ Nivel 4: Administrado: Los proyectos usan objetivos medibles y cuantificables para

alcanzar a cubrir las necesidades de los clientes y la organización. Es decir, se usan
métricas para gestionar la organización. (Simón Sánchez & Díaz Sarmiento, 2009)

15
 ✓ Nivel 5 Optimizado: Los procesos de los proyectos y de la organización están orientados
a la mejora de las actividades, que mediante métricas son identificadas, evaluadas y
puestas en práctica.” (Simón Sánchez & Díaz Sarmiento, 2009)

3. DISEÑO METODOLÓGICO

Se deben precisar de manera clara y secuencial las etapas en las que se planea llevar a cabo la
práctica, especificando la forma como se alcanzarán los objetivos propuestos, los
procedimientos y actividades a desarrollar.

• Interiorizar especificaciones técnicas y funcionales

• Diseñar plan de pruebas
• Ejecutar plan de pruebas
• Reportar errores encontrados para su respectiva corrección
• Realizar pruebas de integración
• Realizar pruebas de estrés
• Dar aceptación de pruebas para pruebas posteriores por parte de los usuarios
funcionales

FASES

Elaborar la planificación de las pruebas

• Se define la matriz de responsabilidades

• El plan de pruebas se alinea con las habilidades y conocimientos de cada persona.
• Se realiza el cronograma a partir de la estimación de las actividades.
• Se realizan las premisas a partir de la documentación de entornos y de los requisitos de
personal.

Analizar los requerimientos de desarrollo de software

16
 • Estudiar y analizar los requerimientos de usuario
• Analizar la matriz de trazabilidad
• Realizar especificaciones y diseño funcional y casos de uso.
• Verificación de historias de usuario
• Realizar entrevistas con el equipo encargado de la ingeniería de requisitos para aclarar
dudas y ampliar la información que sea necesaria.

Identificar los riesgos y definir planes de respuesta

• Identificar posibles dificultades en la disponibilidad de entornos.

• Identificar los riesgos en cada una de las dependencias por medio de mesas de trabajo y
tormentas de ideas
• Definir planes de respuesta específicos para cada situación particular y riesgo.

Identificar las funcionalidades nuevas a probar

• Después de la documentación del análisis de requisitos y de las entrevistas con el equipo

de ingeniería, se incluyen la lista de funcionalidades
• Revisar con los analistas de negocio y también con los arquitectos de software las
funcionalidades que forman parte del desarrollo del software
• Analizar todas las capas de la arquitectura
• Formación en QA Testing

Identificar las funcionalidades de sistemas existentes que deben probarse

• Se deben considerar todos los componentes afectados en todas las capas de la

arquitectura de software.
• Funcionalidades modificadas de cara al usuario
• Funcionalidades modificadas en sus componentes internos

17
 • Los Analistas de negocio o Arquitectos de software, familiarizados con el sistema
informático implementado en entorno de producción, deberán suministrar la información
necesaria adicional para el plan de pruebas.

Definir la estrategia de pruebas

• Seleccionar los tipos de pruebas de software que se deben realizar.

• Se determina el conjunto de pruebas que se van a realizar.
• Las pruebas funcionales son definidas por el ISTQB (International Software Testing
Qualifications Board) como pruebas basadas en especificación.
• Se realizan pruebas de aceptación, en las cuales el equipo de calidad e inclusive personas
del área de negocio o cliente del proyecto verifican el funcionamiento del sistema o
funcionalidad.
• Se realizan pruebas no funcionales
• Se realizan pruebas de caja blanca
• Se realizan pruebas de regresión

Criterios de inicio, aceptación y suspensión de pruebas

• Se define el nivel de tolerancia a fallos de calidad

• Se realiza un Soft Launch o un mínimo producto viable
• Después de logradas las condiciones, se darán por aceptadas las pruebas y el desarrollo
de software.
• Criterios de inicio o reanudación
• Criterios de suspensión

Identificar los entornos (ambientes) requeridos

• Se documentan las características de los entornos de Hardware y Software necesarios

para realizar la ejecución de las pruebas de software.

18
 • Se deben estudiar los requisitos que aseguran un mínimo de confiabilidad de estas
pruebas respecto al entorno de producción.
• Se definen los requisitos de sistemas operativos, software y herramientas de las
estaciones de trabajo de los Testers.
• Se definen los requisitos de harware y software para los siguientes componentes:
✓ Herramienta de gestión de calidad de software.
✓ Herramientas para automatización de pruebas.
✓ Herramientas de BDD, TDD y Testing de Web Services)."
Determinar necesidades de personal y entrenamiento

• Estimación del esfuerzo de pruebas a partir del diseño de casos de prueba.

• Si no se cuenta con la estimación, se procede a definir los tipos de perfiles de habilidades
y conocimientos en Software Testing que se necesitan.
• ¿Se necesitan conocimientos específicos en pruebas de requisitos no funcionales? Por
ejemplo, para pruebas de desempeño o estrés.
• Se define cual herramientas de gestión de calidad de software se va a utilizar.
• Se define si se necesitan conocimientos en herramientas de pruebas automatizadas.

Establecer la metodología y procedimientos de prueba

• Se define la metodología de pruebas de software dependiendo de la que se esté utilizando

para la gestión del proyecto.
• Si se utiliza una metodología predictiva, las pruebas de software comenzaran con la
estimación del diseño, esfuerzo y ejecución de las pruebas.
• Si se utilizan metodologías ágiles de desarrollo de software, se debe considerar las
diferencias de las pruebas ágiles de software respecto al enfoque predictivo.
• Se documentan los procedimientos para diseño y ejecución.

19
 4. PROPUESTA DEL PROYECTO O PRÁCTICA
4.1.PLAN DE TRABAJO
ETAPAS

• Elaborar la planificación de las pruebas:

En esta etapa se debe definir la matriz de responsabilidades, la cual deben estar alineadas
con las habilidades y conocimientos de cada persona; se realiza el cronograma a partir de
la estimación de las actividades de Software Testing realizada por el equipo.

Para que el cronograma sea realizable deben cumplirse algunas premisas. Estas se
determinan a partir de la documentación de entornos y de los requisitos de personal.

• Analizar los requerimientos de desarrollo de software

En esta fase se elabora un plan de pruebas de software dependiendo de los requerimientos

de usuario que componen el proyecto. Se debe analizar toda la ingeniería de requisitos
para ampliar la información que sea necesaria.

Se analiza la matriz de trazabilidad, incluyendo especificaciones y diseño funcional,

requisitos no funcionales, casos de uso, historias de usuario.

• Identificar los riesgos y definir planes de respuesta

Se identifican posibles dificultades en la disponibilidad de entornos.

Se identifican los riesgos en cada una de las dependencias por medio de mesas de trabajo
y tormentas de ideas, además de definir planes de respuesta específicos para cada
situación particular y riesgo.

20
• Identificar las funcionalidades nuevas a probar

Después de la documentación del análisis de requisitos y de las entrevistas con el equipo

de ingeniería, se incluyen la lista de funcionalidades donde se revisan con los analistas de
negocio y también con los arquitectos de software las funcionalidades que forman parte
del desarrollo del software.

• Identificar las funcionalidades de sistemas existentes que deben probarse

Se deben considerar todos los componentes afectados en todas las capas de la

arquitectura de software para que los analistas de negocio o arquitectos de software,
familiarizados con el sistema informático implementado en entorno de producción,
suministren la información necesaria adicional para el plan de pruebas.

• Definir la estrategia de pruebas

En esta fase se seleccionan los tipos de pruebas de software que se deben realizar y se
determina el conjunto de pruebas que se van a realizar.

• Criterios de inicio, aceptación y suspensión de pruebas

Se debe definir el nivel de tolerancia a fallos de calidad, se realiza un Soft Launch ó un

mínimo producto viable, además se definen criterios de inicio o reanudación y criterios
de suspensión.

21
• Identificar los entornos (ambientes) requeridos

En esta fase se documentan las características de los entornos de Hardware y Software

necesarios para realizar la ejecución de las pruebas de software.

Se deben estudiar los requisitos que aseguran un mínimo de confiabilidad de estas

pruebas respecto al entorno de producción.

Se definen los requisitos de harware y software para los siguientes componentes:

1) Herramienta de gestión de calidad de software.
2) Herramientas para automatización de pruebas.
3) Herramientas de BDD, TDD y Testing de Web Services).

• Determinar necesidades de personal y entrenamiento

Se estima del esfuerzo de pruebas a partir del diseño de casos de prueba; si no se cuenta
con la estimación, se procede a definir los tipos de perfiles de habilidades y
conocimientos en Software Testing que se necesitan.

Se define cual herramientas de gestión de calidad de software se va a utilizar y define si

se necesitan conocimientos en herramientas de pruebas automatizadas.

• Establecer la metodología y procedimientos de prueba

En esta fase se define la metodología de pruebas de software dependiendo de la que se

esté utilizando para la gestión del proyecto y si se utiliza una metodología predictiva, las

22
 pruebas de software comenzaran con la estimación del diseño, esfuerzo y ejecución de las
pruebas. A su vez se documentan los procedimientos para diseño y ejecución.

4.2.CRONOGRAMA DE TRABAJO
Se anexa cronograma de trabajo, donde se detallan las actividades que se han realizado y las que se
encuentran pendientes por realizar, las actividades que se encuentran marcadas en color verde
corresponden a las actividades donde yo interactuó directamente dentro del proyecto.

23
 BIBLIOGRAFIA

Carreras Montoto, O. (15 de Marzo de 2012). http://olgacarreras.blogspot.com.es.

Obtenido de http://olgacarreras.blogspot.com.es/2012/03/estandares-formales-de-
usabilidad-y-su.html
Karron. (14 de Abril de 2013). karron10.wordpress.com. Obtenido de
karron10.wordpress.com: https://karron10.wordpress.com/2013/04/14/normas-y-
estandares-en-proyectos-de-ti-2/
MGINFORMATICA. (s.f.). www.mginformatica.com.a. Obtenido de
www.mginformatica.com.a: http://www.mginformatica.com.ar/modelo-de-calidad.htm
Simón Sánchez, E. D., & Díaz Sarmiento, L. B. (1 de Diciembre de 2009).
es.slideshare.net. Obtenido de https://es.slideshare.net/eduardo89/estndares-de-calidad-
aplicadas-al-software
SQASA. (Septiembre de 2020). https://sqasa.co. Obtenido de https://sqasa.co/un-
recorrido-por-la-historia-de-las-pruebas-de-software/
YUNBIT. (2 de Septiembre de 2016). https://www.yunbitsoftware.com. Obtenido de
https://www.yunbitsoftware.com/blog/2016/09/02/importancia-de-las-pruebas-en-
desarrollo-de-software/

24
 ANEXOS
• Se anexa cronograma del proyecto

25