Implementación de métodos agiles en el aseguramiento de la ...
50
UNIVERSIDAD POLITÉCNICA DE SINALOA PROGRAMA ACADÉMICO DE INGENIERÍA EN INFORMÁTICA Tesina “Implementación de métodos agiles en el aseguramiento de la calidad del software” Para obtener la acreditación de las estadías profesionales y contar con los créditos para el grado de Ingeniero en Informática. Autor: Galeana Ávila Oscar Javier Asesor: M.C. Pérez Pasten Borja Alejandro Asesor OR: Lic. Ana Paola Ruiz Burgos Mazatlán, Sinaloa, 09 de agosto de 2019
Transcript of Implementación de métodos agiles en el aseguramiento de la ...
UNIVERSIDAD POLITÉCNICA DE SINALOA
PROGRAMA ACADÉMICO DE INGENIERÍA EN
INFORMÁTICA
Tesina
“Implementación de métodos agiles en el
aseguramiento de la calidad del software”
Para obtener la acreditación de las estadías profesionales y contar con los
créditos para el grado de Ingeniero en Informática.
Autor: Galeana Ávila Oscar Javier
Asesor: M.C. Pérez Pasten Borja Alejandro
Asesor OR: Lic. Ana Paola Ruiz Burgos
Mazatlán, Sinaloa, 09 de agosto de 2019
2
CARTA DONDE LA EMPRESA ACEPTA AL ALUMNO.
3
CARTA DE ACEPTACIÓN DE TEMA DE TESINA
4
CARTA DE ACETACIÓN DE REVISIÓN DE TESINA
5
CARTA DONDE LA EMPRESA APRUEBA AL ALUMNO.
6
AGRADECIMIENTOS
Agradezco enormemente a mi familia por todo su apoyo en todo momento, por
estar conmigo brindándome ánimos para nunca rendirme, por su gran sacrificio para
facilitar el apoyo económico, gracias a todo lo que han hecho han hecho por mí, me
han permitido obtener cada uno de mis logros que a su vez compartiré con ellos.
También, agradecerle a Nicole por su apoyo y afecto que me ha brindado en todo
momento desde el momento en que nos conocimos. Gracias a ella he podido salir
adelante en muchos aspectos de mi vida y me he podido superarme en aspectos
profesionales como, también, personales.
A la empresa Softtek que me brindó la oportunidad de desempeñarme
profesionalmente y ser mi base de adquisición de nuevos conocimientos.
7
ÍNDICE TEMÁTICO
ÍNDICE DE IMÁGENES ........................................................................ 10
ABSTRACT ........................................................................................... 11
INTRODUCCIÓN ................................................................................... 11
CAPITULO I .......................................................................................... 12
1- Antecedentes. .................................................................................................... 13
1.1- Localización. ............................................................................................... 13
1.2- Objetivos y prioridades de la empresa. ....................................................... 14
1.3- Organigrama de la empresa. ...................................................................... 14
1.4- Visión. ......................................................................................................... 15
1.5- Misión. ......................................................................................................... 15
2- Planteamiento del problema. ............................................................................. 16
2.1- Propuesta de investigación. ........................................................................ 17
2.2- Objetivos. .................................................................................................... 17
2.2.1- Objetivo general. .................................................................................. 17
2.2.2- Objetivos específicos. ........................................................................... 17
2.3- Preguntas de investigación. ........................................................................ 18
2.4- Hipótesis. .................................................................................................... 18
2.5- Limitaciones y supuestos. ........................................................................... 18
2.6- Relevancia. ................................................................................................. 19
CAPITULO ll ......................................................................................... 20
3- Historia del Testing. ........................................................................................... 21
8
4- QA Testing. ........................................................................................................ 22
4.1- Ciclo de Vida de Pruebas de Software. ....................................................... 23
4.1.1- Análisis de requisitos. ........................................................................... 24
4.1.2- Planificación de prueba. ....................................................................... 25
4.1.3- Desarrollo de casos de prueba. ............................................................ 25
4.1.4- Configuración del entorno de prueba. .................................................. 25
4.1.5- Ejecución de pruebas. .......................................................................... 25
4.1.6- Ciclo de prueba de cierre. .................................................................... 26
4.1.6- Casos de prueba. ................................................................................. 26
5- Metodologías Agiles. ......................................................................................... 27
5.1- Manifestó Ágil. ............................................................................................ 27
5.1.1- Valores. ................................................................................................ 28
5.1.2- Normas. ................................................................................................ 28
5.2- Scrum. ......................................................................................................... 30
5.2.1- Historia. ................................................................................................ 30
5.2.2- Procesos. ............................................................................................. 31
5.2.3- Roles. ................................................................................................... 33
6- Wrike. ................................................................................................................ 34
6.1- Organización, Planificación y Seguimiento de Proyectos. .......................... 34
6.2- Colaboración e Informes. ............................................................................ 35
6.3- Personalizaciones y Soluciones Listas. ...................................................... 35
CAPITULO llI ........................................................................................ 37
7- Diseño. .............................................................................................................. 38
8- Desarrollo. ......................................................................................................... 40
9
8.1- Proceso del Testing. ................................................................................... 40
8.1.1- Planeación y Control. ........................................................................... 40
8.1.2- Análisis y Diseño. ................................................................................. 42
8.1.3- Implementación y Ejecución. ................................................................ 44
8.1.3- Evaluación de Criterios de Salida e Informes. ...................................... 45
9- Resultados y Discusión. .................................................................................... 46
10- Conclusión. ...................................................................................................... 47
11- Bibliografía. ...................................................................................................... 47
12- Glosario. .......................................................................................................... 49
10
ÍNDICE DE IMÁGENES
Imagen 1.1- Ubicación de la institución (Google maps)………………………………..15
Imagen 1.2- Organigrama………………………………………………………………….16
Imagen 2.1- Ikurijo Nonaka (izquierda) y Hirotaka Takeuchi (derecha)………………32
Imagen 2.2- Diagrama de proceso de Scrum……………………………………………34
Imagen 2.3- Diagrama de Gantt…………………………………………………………..37
Imagen 2.4- Flujo de trabajo……………………………………………………………….37
Imagen 3.1- Wrike…………………………………………………………………………..41
Imagen 3.2- Ejemplo de un caso de prueba……………………………………………..44
11
RESUMEN
El presente documento ha sido realizado con la finalidad de acreditar la carrera
de ingeniería en informática en la Universidad Politécnica de Sinaloa. El contenido
expuesto en el presente trabajo hace mención al uso de herramientas enfocadas a QA
(Quality Assurance”, las cuales tienen como finalidad facilitar la detección y la
depuración de errores en un software. Esto sirven para mejorar la eficiencia y
rendimiento de un sistema.
ABSTRACT
This document has been written in order to earn the bachelor’s degree at
Universidad Politécnica de Sinaloa. The content in the current work mentions tools for
QA (Quality Assurance), which have as purpose the facilitate the detection and
debugging of errors in a software. These tools are use to improve the efficiency and
performance of a system.
INTRODUCCIÓN
A lo largo del tiempo hemos observado como las tecnologías se vuelven más
complejas y sofisticadas. Debido a que cada vez se ven mas desarrollos se ha hecho
necesario que estas sean lo más precisas y libre de errores, es por eso que se cuenta
con personal capacitado para desarrollar y utilizar herramientas que ayuden con la
detección de errores.
En el transcurso del año 2019 han salido al mercado tecnologías nuevas enfocadas
para satisfacer las necesidades de una clientela, brindando automatización y
optimización a procesos de diversas necesidades. Todos estos productos no saldrían
al mercado sin antes pasar por pruebas de QA y demostrar que el producto no presenta
errores de funcionamiento.
12
CAPITULO I
Antecedentes y planteamiento del problema
13
1- Antecedentes.
En diciembre de 1982, Softtek fue fundada en México como una pequeña
compañía de servicios de TI. En 1997 Softtek introdujo el modelo de
servicios Nearshore con la creación del Centro Global de Entrega en Monterrey,
México, el primero en su tipo en toda Latinoamérica. Aunque la compañía ha crecido
enormemente desde su origen, promovida por una cultura corporativa única, esta
tendencia se aceleró luego de que la actual presidente y CEO Blanca Treviño tomara
posición como CEO en el año 2000. En el 2003, Softtek adquirió el Centro Global de
Desarrollo de GE en México y expandió su portafolio de aplicaciones y servicios al
combinar las capacidades de los dos jugadores más fuertes de nearshore en México.
Softtek se transformó en un proveedor global de soluciones de TI y procesos de
negocio con 12,000 colaboradores a través de 30 oficinas en Norteamérica,
Latinoamérica, Europa y Asia.
En agosto del 2007 Softtek adquirió I.T. UNITED, empresa ubicada en China,
expandiendo sus capacidades al mercado asiático. Softtek utiliza la metodología de su
marca registrada Global™ para trabajar con clientes, conocer sus necesidades a nivel
local, regional y global a través de trabajo on-site y 15 Centros Globales de Entrega.
Con diversas clientes Fortune 500, el Modelo de Entrega Nearshore de Softtek llena
el hueco dejado por los proveedores de TI en la India; además de proporcionar una
sólida experiencia y capacidad de entrega de servicio en Latinoamérica.
1.1- Localización.
Softtek se encuentra ubicada en la ciudad de Monterrey, Nuevo León en Blvd.
Constitución 3098, en la colonia Santa María.
14
1.2- Objetivos y prioridades de la empresa.
Softtek es una empresa de talla internacional, comprometidos con la creación
de software en donde se apliquen e innoven conocimientos científicos y tecnológicos
a través de procesos y servicios orientados hacia la mejora continua bajo estándares
internacionales que satisfagan las necesidades del sector productivo a nivel mundial.
1.3- Organigrama de la empresa.
Softtek cuenta con gran variedad de áreas las cuáles desempeñan diferentes
labores.
Ubicación de la institución (Google maps).
https://www.google.com/maps/place/Softtek/
Imagen 1.1
15
1.4- Visión.
Trascender como proveedor global líder en Soluciones de TI y Procesos de
Negocio, generando relaciones mutuamente benéficas, de largo plazo y cimentadas
en una base de confianza ganada. Construiremos nuestro futuro siendo una empresa
sólida y socialmente responsable, con un historial rentable. Proporcionamos servicios
innovadores y de alta calidad, impulsados por la pasión de nuestra cultura centrada en
el elemento humano.
1.5- Misión.
Organigrama.
https://www.softtek.com/about/management-team
Imagen 1.2
16
Softtek es un proveedor global de soluciones y servicios de tecnología, que
ayuda a los clientes a prosperar en la era digital. Softtek ayuda a los clientes a mejorar
el tiempo de entrega de soluciones de negocio a sus clientes, eliminando la
complejidad de la plataforma de TI existente, ofreciendo un mejor diseño y prueba de
soluciones, y produciendo resultados predecibles para las corporaciones de primer
nivel hacia y desde toda América.
2- Planteamiento del problema.
El desarrollo de proyectos se simplifica en que el proyecto no contenga errores
para que este pueda ser funcional y que cumpla con todos los requerimientos
necesarios para poder decir que el proyecto fue concluido.
Mientras el software es más grande es necesario ser más preciso en la identificación
y corrección de errores y en sus soluciones; aquí es donde QA (Quality Assurance)
toma importancia dentro del desarrollo y administración de un proyecto.
Debido a esto (que tan grande es el proyecto) es que el “testing” es considerado
agobiante y tedioso para muchas personas, ya que se la forma más común para
identificar errores tiende a ser de funcional (manual). También existe el “testing
automatizado” que se caracteriza con la velocidad en que se ejecutan los “casos de
prueba”, ya que se desarrolla un código especifico para hacer pruebas en el software;
sin embargo, no en todos los casos de prueba se puede implementar la automatización
debido al grado de complejidad de la prueba.
La importancia de la implementación del testing se centra en la calidad del producto a
entregar, sin embargo, muchas veces la implementación suele hacerse de manera
errónea y redundante. Es por eso que es necesario que los proyectos estén
desarrollados en base de una metodología, por ejemplo: cascada, agile, modelo v, etc.
17
2.1- Propuesta de investigación.
Para hacer que un software cumpla con los requerimientos acordados en el
contrato es necesaria de la implementación de una metodología para facilitar el
desarrollo de proyectos.
Debido del resultado de la problemática planteada, se dio inicio a la investigación de
como al implementar de manera correcta la metodología “Agile” puede dar paso a que
las pruebas de testing sean mucho más efectivas y que en como la corrección e
identificación de errores son más sencillas de ejecutar.
Es importante mencionar que “Agile”, más que una metodología para el desarrollo de
proyectos que precisan de rapidez y flexibilidad, es una filosofía que supone una forma
distinta de trabajo y de organización. Cada proyecto se divide en partes que tienen que
completarse y entregarse en pocas semanas. Siempre se está trabajando.
2.2- Objetivos.
A partir del planteamiento del problema y la propuesta de investigación se
definen los objetivos.
2.2.1- Objetivo general.
Como al implementar de manera correcta la metodología “Agile” puede dar paso
a que el testing se ejecute de forma más efectiva y que la corrección e identificación
de errores pueden llegar a ser más sencillos de ejecutar.
2.2.2- Objetivos específicos.
• Expandir los conocimientos que se tienen de QA (Quality Assurance).
• Mejorar las habilidades y conocimientos del testing, para la optimización de
procedimientos e implementación de este.
18
• Implementar QA (Quality Assurance) de la mejor manera.
2.3- Preguntas de investigación.
• ¿Cuáles son las ventajas de utilizar la metodología “Agile”?
• ¿Cuáles son las ventajas de la implementación del testing?
• ¿En que circunstancias es mejor implementar el testing automatizado que el
funcional?
• ¿Cuál es la forma correcta de utilizar la metodología “Agile”?
• ¿Al implementar la metodología “Agile” se mejorar la implementación del
testing?
2.4- Hipótesis.
En base a la problemática establecida, la propuesta de investigación y las
incógnitas ya mencionadas, se establece la siguiente hipótesis:
Hipótesis general o principal.
El uso de la metodología “Agile” favorece a que en un proyecto mejore la calidad
del entregable, debido a que hay un aumento de productividad porque cada día se ven
los avances y los problemas que han surgido en el proyecto. Gracias a esto la
resolución de errores y el desarrollo de soluciones (testing) serían concluidos en menor
tiempo y de forma más eficiente.
2.5- Limitaciones y supuestos.
Los contratos que tiene la empresa con otras empresas generan limitaciones al
poder describir procesos que se llevan acabo en el transcurso del desarrollo de un
proyecto. Una de las políticas más importantes que tiene Softtek es entorno a la
privacidad que se debe de tener, ya que se manejan datos delicados que se tienen de
19
empresas que contratan a Softtek. Muchas veces estas empresas son muy celosas de
su información que piden trabajar con equipos que son de ellos.
2.6- Relevancia.
La investigación puede hacer que procesos específicos del testing puedan
optimizase y que se puedan acortar los tiempos de ejecución. También, esto implica
que la forma de ejecución de la metodología “Agile” sea más estricta en sus
requerimientos e implementación.
20
CAPITULO ll
Antecedentes y planteamiento del problema
21
A continuación, en el Capítulo ll se expondrán conceptos e información
dedicados a los lectores, la cual servirá de apoyo para una mejor comprensión de los
temas que aborda el “QA Testing”.
3- Historia del Testing.
Los orígenes de las pruebas de software como práctica se basan en los
primeros días del desarrollo de software. En este momento, a fines de la década de
1960 y principios de la década de 1970, la actividad reconocida como prueba se llamó
depuración. Un programador escribió un código, lo instaló en algún lugar para ver si
se ejecutaba. Si el programa fallaba, el programador intentaría depurar el problema
para tratar de comprender dónde falló, iniciar una solución e intentar nuevamente. En
1968, un grupo de ingenieros e informáticos se reunió en Garmisch en Alemania. Esta
fue la primera conferencia de la Organización del Tratado del Atlántico Norte (OTAN).
Se llevó a cabo en respuesta a una crisis de software que estaba surgiendo en ese
momento. La frase "crisis de software" se acuñó para encapsular los problemas de
complejidad y mala calidad. En la conferencia, se debatió la noción de que el software
es una disciplina de ingeniería. A diferencia de otras formas de ingeniería, no se
producían productos físicos, solo una noción abstracta de una estructura de software.
La segunda conferencia de la OTAN al año siguiente se celebró en Roma. Si bien hubo
poco acuerdo sobre el camino a seguir para la disciplina emergente, hubo mucho
debate enérgico entre los participantes. Hubo llamados para métodos más formales
de inspección y validación. A fines de la década de 1970, se debatieron ideas sobre
cómo podría ser un sistema confiable y se introdujeron teorías. Este período marca el
nacimiento de la literatura sobre pruebas de software y luego, en 1972, el primer
simposio de pruebas tuvo lugar en la Universidad de Carolina del Norte. Las actas del
simposio fueron publicadas como el libro Program Test Methods por Wiliam Hetzel.
Por lo tanto, los desarrolladores y gerentes tenían la sensación de una iluminación que
comenzaba lentamente a comprender que probar el código como tarea era tan
sofisticado y desafiante como desarrollarlo. Se proponían diferentes enfoques para
hacer pruebas: había voces de que los teoremas matemáticos podrían usarse para
22
garantizar la corrección. Los problemas de complejidad con los que la ingeniería de
software había estado luchando ahora se veían en las pruebas y en el debate sobre el
mejor método para lograr un alto grado de calidad del producto.
Se puede ver que Susan Gerhart y John Goodenough han desarrollado lo básico
conceptos que formaron pruebas de software a mediados de la década de 1970. Su
teoría de los errores de software tenía dos reglas: una era determinar cuándo se
habían realizado suficientes pruebas y el segundo fue una medida de los errores
restantes en el código. Su trabajo formado la base del camino que condujo a que las
pruebas se vieran en la década de 1980 como menos una tarea para
detección de errores y más a una forma de ingeniería de calidad en un sentido más
amplio.
En 1985 en la Conferencia Internacional sobre Ingeniería de Software, el entonces
Ministro de Gran Bretaña de Estado de Industria y Tecnología de la Información,
Geoffrey Pattie declaró, "para decirlo muy sin rodeos, el software demasiado entregado
sigue siendo insatisfactorio. Todavía se entrega demasiado tarde, cuesta más de lo
esperado, a veces no funciona de la manera requerida y con bastante frecuencia
consume recursos excesivos en lo que eufemísticamente se llama mantenimiento. A
medida que los costos, la complejidad y la presión aumentaron a mediados y finales
de la década de 1980 en grandes proyectos de software Los gerentes de TI y los
líderes empresariales se interesaron cada vez más en calidad de software y métodos
de prueba de software.
4- QA Testing.
La implementación de las pruebas en un software nos permite resolver y mejorar
un sistema. Es una disciplina en la ingeniería de software permite tener procesos,
métodos de trabajo y herramientas para identificar defectos en el software alcanzando
un proceso de estabilidad del mismo. El “Testing” no es una actividad que se piensa al
final del desarrollo del software, va paralelo a este. Permite que lo que se está
23
construyendo, se realice de manera correcta de acuerdo a lo que necesita un usuario
final. De ahí radica su importancia, pues es una forma de prevenir o inclusive de
corregir posibles desviaciones del software antes de que sea operable.
Para poder describir bien lo que es QA Testing es necesario desglosar los conceptos
que comparte la abreviación “QA” y la palabra “Testing”. “Q” se refiere a “quality”
en inglés que se traduce a “calidad”. “A” se refiere a “assurance” en inglés que
significa “garantía”. Y la palabra “testing” en inglés que se traduce a “prueba”. Estas
palabras forman al método para probar software.
La Calidad (Q - Quality) trata de satisfacer las necesidades y expectativas de los
clientes con respecto a la funcionalidad, diseño, confiabilidad, durabilidad y precio del
producto.
La Garantía (A - Assurance) no es más que una declaración positiva sobre un
producto o servicio, lo que da confianza. Es la certeza de un producto o servicio, que
funcionará bien. Proporciona una garantía de que el producto funcionará sin problemas
según las expectativas o requisitos.
Entonces, ¿qué es el Aseguramiento de la Calidad (QA - Quality Assurance)? Se
define como una actividad para garantizar que una organización ofrezca el mejor
producto o servicio posible a los clientes. El control de calidad se centra en mejorar los
procesos para entregar productos de calidad al cliente. Una organización debe
asegurarse de que los procesos sean eficientes y efectivos según los estándares de
calidad definidos para los productos de software [1].
4.1- Ciclo de Vida de Pruebas de Software.
El QA Testing se compone de un ciclo de vida llamado Ciclo de Vida de
Pruebas de Software (STLC – Software Testing Life Cycle). Se define como una
secuencia de actividades realizadas para realizar las Pruebas de software.
24
Contrariamente a la creencia popular, las pruebas de software no son una sola
actividad. Consiste en una serie de actividades realizadas metodológicamente para
ayudar a certificar su producto de software [2].
A continuación, se encuentran las fases de STLC:
• Análisis de requisitos.
• Planificación de prueba.
• Desarrollo de caso de prueba.
• Configuración del entorno de prueba.
• Ejecución de pruebas.
• Prueba de cierre del ciclo.
Cada una de estas etapas tiene un criterio definido de Entrada y Salida,
Actividades y Entregas asociadas [2].
Criterios de Entrada: Los Criterios de entrada brindan los requisitos previos que
deben completarse antes de que puedan comenzar las pruebas [2].
Criterios de Salida: Los Criterios de salida definen los elementos que deben
completarse antes de poder concluir la prueba [2].
4.1.1- Análisis de requisitos.
Durante esta fase, el equipo de prueba estudia los requisitos desde el punto de
vista de la prueba para identificar los requisitos comprobables.
El equipo de control de calidad puede interactuar con varias partes interesadas
(Cliente, Analista de Negocios, Responsables Técnicos, Arquitectos de Sistemas, etc.)
para comprender los requisitos en detalle.
25
Los requisitos pueden ser funcionales (que definen lo que debe hacer el software) o
no funcionales (que definen el rendimiento del sistema / disponibilidad de seguridad)
[3].
4.1.2- Planificación de prueba.
Por lo general, en esta etapa, un gerente de control de calidad superior
determinará las estimaciones de esfuerzo y costo para el proyecto y preparará y
finalizará el plan de prueba. En esta fase, también se determina la estrategia de prueba
[4].
4.1.3- Desarrollo de casos de prueba.
Esta fase implica la creación, verificación y retrabajo de casos de prueba y
scripts de prueba. Los datos de prueba se identifican / crean y se revisan y luego se
vuelven a trabajar también [5].
4.1.4- Configuración del entorno de prueba.
El entorno de prueba decide las condiciones de software y hardware en las que
se prueba un producto de trabajo. La configuración del entorno de prueba es uno de
los aspectos críticos del proceso de prueba y se puede hacer en paralelo con la Etapa
de desarrollo de casos de prueba.
Es posible que el equipo de prueba no participe en esta actividad si el cliente / equipo
de desarrollo proporciona el entorno de prueba, en cuyo caso el equipo de prueba
debe realizar una verificación de preparación (prueba de humo) del entorno dado [6].
4.1.5- Ejecución de pruebas.
26
Durante esta fase, los probadores llevarán a cabo las pruebas en función de los
planes de prueba y los casos de prueba preparados. Los errores serán reportados al
equipo de desarrollo para su corrección y se realizarán nuevas pruebas [7].
4.1.6- Ciclo de prueba de cierre.
El equipo de prueba se reunirá, discutirá y analizará los artefactos de prueba
para identificar estrategias que deben implementarse en el futuro, tomando lecciones
del ciclo de prueba actual. La idea es eliminar los cuellos de botella del proceso para
futuros ciclos de prueba y compartir las mejores prácticas para proyectos similares en
el futuro [8].
4.1.6- Casos de prueba.
Los casos de prueba son la estructura en la cual los evaluadores describen lo
que hará la prueba. Los casos de prueba se utilizan tanto en pruebas manuales como
automáticas. Escribir casos de prueba para un gran proyecto de desarrollo es una
tarea larga e importante. Si el caso de prueba está mal escrito, no importa cuántas
veces se ejecute la prueba, ya sea manual o automatizado, tendrá poco valor. Un caso
de prueba deficiente puede ser uno que prueba solo el camino feliz, que no piensa en
todas las otras permutaciones de la situación bajo prueba, uno que pone el foco de la
prueba en la parte incorrecta del sistema, uno que compara valores no válidos y puede
conducir a resultados falsos [9].
Un buen caso de prueba debe detectar principalmente defectos y debe tratar de causar
el menor mantenimiento posible. Tener casos de prueba que prueben y realicen
múltiples pruebas puede causar una complejidad innecesaria. La desventaja de esta
complejidad se ve cuando las pruebas fallan y hay múltiples puntos potenciales de
falla. Si el caso de prueba requiere una tarea principal para probar, cuando falla, el
proceso de encontrar ese error se vuelve más fácil. Escribir casos de prueba eficientes
y potentes es una habilidad que viene con entrenamiento y experiencia. Identificar las
27
pruebas correctas para ser seleccionadas de un gran conjunto de pruebas y ejecutarse
en pruebas de regresión es una tarea de prueba crucial.
Si esta selección se realiza sin la información correcta acerca de lo que la estrategia
de una ejecución particular de pruebas está tratando de lograr, la efectividad de la
ejecución de la prueba disminuirá. El área de generación de casos de prueba ha
atraído mucha atención de investigación, y existen numerosas formas de abordar
cómo producir casos de prueba [10].
5- Metodologías Agiles.
Las metodologías ágiles son aquellas que permiten adaptar la forma de trabajo
a las condiciones del proyecto, consiguiendo flexibilidad e inmediatez en la respuesta
para amoldar el proyecto y su desarrollo a las circunstancias específicas del entorno.
En esencia, las empresas que apuestan por esta metodología consiguen gestionar sus
proyectos de forma flexible, autónoma y eficaz reduciendo los costes e incrementando
su productividad [11].
Las metodologías ágiles mejoran la satisfacción del cliente dado que se involucrará y
comprometerá a lo largo de todo el proyecto. En cada etapa se informará al cliente de
los logros y progresos del mismo, con la visión de involucrarlo directamente para sumar
su experiencia y conocimiento, y así, optimizar las características del producto final
obteniendo en todo momento una visión completa de su estado [12].
5.1- Manifestó Ágil.
La mayoría de los valores y principios del Manifiesto Ágil tienen su origen en
Scrum. El cual sirve para la gestión y desarrollo de proyectos utilizando procesos
iterativos y graduales.
28
Cabe mencionar que el manifiesto ágil se resume en 4 valores y 12 principios que rigen
en todo momento el desarrollo de los proyectos a fin de que estos sean rápidos
conservando siempre su calidad [13].
5.1.1- Valores.
Los individuos e interacciones por encima de los procesos y las
herramientas. Las metodologías ágiles como Scrum saben que su principal factor
para lograr el éxito son los recursos humanos, por ende, dan gran valor a esta pieza
clave del proyecto. Contar con un equipo capacitado y motivado, es garantía de una
mayor productividad [14].
Documentar solamente lo necesario. Las metodologías ágiles reconocen la
importancia de documentar, sin embargo, hacen gran énfasis en realizar esta actividad
siempre y cuando sea estrictamente necesario [14].
Colaboración del cliente. Es importante fomentar la participación y compromiso del
cliente en el desarrollo del proyecto. Con sus aportaciones el proyecto puede alcanzar
el éxito, debido a que se minimizan riesgos porque al final del día el cliente es quien
sabe lo que necesita y es el más indicado para corregir o realizar recomendaciones
durante el desarrollo del proyecto [14].
Responder al cambio por encima del seguimiento de un plan. El equipo de trabajo
debe responder al cambio, para generar valor comercial con el cliente. Las
metodologías agiles cuentan con procesos integrados como revisiones y
retrospectivas para cambiar sus planes en función de los comentarios del cliente, para
que este quede satisfecho con el resultado final [14].
5.1.2- Normas.
29
Los principios hacen referencia a las características de las metodologías que
hacen la diferencia entre los procesos tradicionales y los ágiles [15] .
1. Satisfacer al cliente: Mediante entregas tempranas, y continuas del
proyecto.
2. Bienvenidos los requisitos cambiantes: Incluso en etapas tardías del
desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja
competitiva al cliente.
3. Iteraciones constantes: Se entregan proyectos funcionales, entre dos
semanas y dos meses, con preferencia al periodo de tiempo más corto posible.
4. Trabajo colaborativo: Los responsables de negocio y los desarrolladores
trabajamos juntos de forma cotidiana durante todo el proyecto.
5. Motivación del equipo: Los proyectos se desarrollan en torno a individuos
motivados. Hay brindarles el apoyo que necesitan, y confiarles la ejecución del trabajo.
6. Contacto directo con los clientes: El método más eficiente y efectivo de
comunicar información al equipo de desarrollo y entre sus miembros es la
conversación cara a cara.
7. Medida del progreso: El proyecto funcionando es la medida principal de
estamos avanzando.
8. Desarrollo sostenido: Los procesos Ágiles promueven el desarrollo
sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de
mantener relaciones cordiales de manera indefinida.
9. Búsqueda de la excelencia: La atención continua a la excelencia técnica y
al buen diseño mejora la Agilidad.
10. Simplicidad: como el arte de maximizar la cantidad de trabajo no realizado,
es esencial.
11. Autorregulación: Las mejores arquitecturas, requisitos y diseños emergen
de equipos auto-organizados.
12. Revisión permanente: En intervalos regulares el equipo reflexiona sobre
cómo ser más efectivo, para después ajustar y perfeccionar su comportamiento en
consecuencia.
30
5.2- Scrum.
Scrum es un proceso en el que se aplican de manera regular un conjunto de
buenas prácticas para trabajar colaborativamente, en equipo, y obtener el mejor
resultado posible de un proyecto. Estas prácticas se apoyan unas a otras y su
selección tiene origen en un estudio de la manera de trabajar de equipos altamente
productivos.
En Scrum se realizan entregas parciales y regulares del producto final, priorizadas por
el beneficio que aportan al receptor del proyecto. Por ello, Scrum está especialmente
indicado para proyectos en entornos complejos, donde se necesita obtener resultados
pronto, donde los requisitos son cambiantes o poco definidos, donde la innovación, la
competitividad, la flexibilidad y la productividad son fundamentales [16].
5.2.1- Historia.
La historia de Scrum se puede rastrear desde 1986 en un artículo de la Harvard
Business Review, “El nuevo juego para el desarrollo de productos” por Hirotaka
Takeuchi y Ikujiro Nonaka.
Este artículo describe como empresas como Honda, Canon y Fuji-Xerox producen
nuevos productos a nivel mundial utilizando un enfoque escalable y basado en equipos
integrales para el desarrollo de productos. Este enfoque enfatiza la importancia de dar
poder a los equipos auto-organizados. Scrum no es un acrónimo, sino un término
extraído del Rugby, que se refiere a la manera en cómo se reinicia el juego luego de
una falta o cuando la bola se ha ido fuera del juego.
31
En 1993, Jeff Sutherland y su
equipo en Easel Corporation
crearon el proceso de Scrum
para ser utilizado en los
procesos de desarrollo de
software combinando los
conceptos del artículo de 1986
con los conceptos del desarrollo
orientado a objetos, un control
de procesos empírico, desarrollo
iterativo e incremental, procesos
de software y mejora de la productividad, así como el desarrollo de sistemas complejos
y dinámicos.
En 1995, Ken Schwaber publica el primer informe sobre Scrum en OOPSLA 1995.
Desde esa fecha, Schwaber and Sutherland, juntos y separados, han producido y
publicado varias especificaciones para Scrum, incluyendo Desarrollo de Software Ágil
con Scrum, Gestión de Proyectos Agiles con Scrum y la Guía de Scrum [17].
5.2.2- Procesos.
El desarrollo se realiza de forma iterativa e incremental. Cada iteración,
denominada Sprint, tiene una duración preestablecida de entre 2 y 4 semanas,
obteniendo como resultado una versión del software con nuevas prestaciones listas
para ser usadas. En cada nuevo Sprint, se va ajustando la funcionalidad ya construida
y se añaden nuevas prestaciones priorizándose siempre aquellas que aporten mayor
valor de negocio [18].
Product Backlog: Conjunto de requisitos denominados historias descritos en un
lenguaje no técnico y priorizados por valor de negocio, o lo que es lo mismo, por retorno
Ikujiro Nonaka (izquierda) y Hirotaka Takeuchi (derecha).
Imagen 2.1
32
de inversión considerando su beneficio y coste. Los requisitos y prioridades se revisan
y ajustan durante el curso del proyecto a intervalos regulares.
Sprint Planning Metting: Reunión durante la cual el Product Owner presenta las
historias del backlog por orden de prioridad. El equipo determina la cantidad de
historias que puede comprometerse a completar en ese sprint, para en una segunda
parte de la reunión, decidir y organizar cómo lo va a conseguir.
Sprint Backlog: Lista de las tareas necesarias para llevar a cabo las historias del
sprint.
Sprint / Week Sprint: Iteración de duración prefijada durante la cual el equipo trabaja
para convertir las historias del Product Backlog a las que se ha comprometido, en una
nueva versión del software totalmente operativo.
Daily Sprint Meeting: Reunión diaria de cómo máximo 15 min. en la que el equipo se
sincroniza para trabajar de forma coordinada. Cada miembro comenta que hizo el día
anterior, que hará hoy y si hay impedimentos.
Sprint Review: Reunión que se celebra al final del sprint y en la que el equipo presenta
las historias conseguidas mediante una demonstración del producto. Posteriormente,
en la retrospectiva, el equipo analiza qué se hizo bien, qué procesos serían mejorables
y discute acerca de cómo perfeccionarlos.
33
5.2.3- Roles.
En Scrum, el equipo se focaliza en construir software de calidad. La gestión de
un proyecto Scrum se centra en definir cuáles son las características que debe tener
el producto a construir (qué construir, qué no y en qué orden) y en vencer cualquier
obstáculo que pudiera entorpecer la tarea del equipo de desarrollo [19].
Scrum Master: Persona que lidera al equipo guiándolo para que cumpla las reglas y
procesos de la metodología. Gestiona la reducción de impedimentos del proyecto y
trabaja con el Product Owner para maximizar el ROI [20].
Product Owner (PO): Representante de lso accionistas y clientes que usan el
software. Se focaliza en la parte de negocio y el es responsable del ROI del proyecto
(entregar un valor superior al dinero invertido). Traslada la visión del proyecto al
Diagrama de proceso de Scrum.
https://www.powerslides.com/powerpoint-business/project-management-templates/agile-scrum-process/
Imagen 2.2
34
equipo, formaliza las prestaciones en historias a incorporar en el Product Backlog y las
reprioriza de forma regular [20].
Team: Grupo de profesionales con los conocimientos técnicos necesarios y que
desarrollan el proyecto de manera conjunta llevando a cabo las historias a las que se
comprometen al inicio de cada sprint [20].
6- Wrike.
Wrike es una plataforma de colaboración de trabajo y gestión de proyectos en
línea que permite a los equipos entregar trabajo con rapidez y eficiencia. Tiene
herramientas que permiten a los usuarios simplificar la planificación de proyectos,
centralizar la comunicación y agilizar el flujo de trabajo. Puede ver fácilmente el estado
de los proyectos de todos sus equipos con informes en tiempo real. También tiene la
flexibilidad para permitir que las empresas en crecimiento escalen o implementen
rápidamente soluciones listas para requisitos específicos, como marketing o
automatización de servicios profesionales [21].
6.1- Organización, Planificación y Seguimiento de Proyectos.
Wrike simplifica la gestión de proyectos con características como formularios de
solicitud dinámicos. Estos formularios ayudan a capturar información y aseguran que
los equipos de proyecto tengan todos los detalles incluso antes de comenzar a
trabajar. El gráfico interactivo de Gantt muestra dependencias y conflictos, que se
pueden ajustar fácilmente dentro del gráfico. Los paneles son personalizables y
permiten a los usuarios ver solo lo que quieren ver. Son capaces de establecer
prioridades y mantener metas a la vista. Los flujos de trabajo personalizados muestran
una imagen clara del progreso del trabajo, sin la necesidad de actualizar reuniones de
estado o correos electrónicos. Otras características incluyen asignación de recursos y
plantillas de proyectos.
35
6.2- Colaboración e Informes.
El software de gestión y colaboración de proyectos permite a los miembros del
equipo discutir detalles de sus tareas y proyectos dentro del contexto de su
trabajo. Incluye una herramienta de prueba y aprobación que permite una revisión y
aprobación más rápidas de imágenes y documentos digitales. Los usuarios pueden
etiquetar imágenes y videos para proporcionar comentarios. Pueden actualizar las
descripciones de tareas, publicar comentarios y usar menciones en tiempo real. Los
equipos pueden compartir informes interactivos y programar notificaciones de forma
regular. Los paneles interactivos brindan funcionalidad de profundización para obtener
detalles y una visión más profunda. El trabajo puede analizarse más de acuerdo con
el proyecto, el miembro del equipo, el cronograma y otros criterios [22].
6.3- Personalizaciones y Soluciones Listas.
Wrike incluye flujos de trabajo personalizados, campos personalizados y
estructuras de carpetas de proyectos personalizadas para proporcionar flexibilidad a
los equipos. Por lo tanto, pueden crear y ajustar el trabajo para los desafíos de hoy, y
también ajustarse al crecimiento cuando llegue el momento. Las soluciones están
disponibles específicamente para equipos de marketing, equipos creativos, gestión de
proyectos, gestión de productos, operaciones comerciales, servicios profesionales o
cualquier otro tipo de equipo. Por ejemplo, los equipos de Wrike para PM están
equipados con herramientas como gráficos de Gantt, herramientas de gestión de
recursos y carga de trabajo, colaboración entre equipos, estado y flujos de trabajo
personalizados, actualizaciones de estado en tiempo real y paneles visuales e
informes [23].
También tiene aplicaciones e integraciones para mejorar y expandir la plataforma para
otras necesidades comerciales, como aplicaciones de iOS y Android para dispositivos
móviles, aplicaciones de escritorio de Windows y Mac, Salesforce y HubSpot para
CRM.
36
Diagrama de Gantt.
https://www.wrike.com/pr/
Imagen 2.3
Flujo de trabajo.
https://www.wrike.com/pr/
Imagen 2.4
37
CAPITULO llI
Diseño y desarrollo
38
7- Diseño.
Debido al enfoque de desarrollo del testing, se requiere de una buena
coordinación y comunicación entre las actividades y el personal encargado de atender
las mismas, es por ello que resulta indispensable llevar a cabo una correcta estrategia
para dar solución a las diversas necesidades. Con ello, se debe llevar también una
buena coordinación, un planteamiento estable y un equipo el cuál sea proactivo, y
también una mentalidad, de alguna forma, pesimista; siempre pensando en que el se
tiene que hacer que el programa falle.
Es por lo anterior que el desenlace adecuado para atender un proyecto reclama la
implementación de metodologías agiles, con el fin de reducir el tiempo de desarrollo e
involucrar al cliente durante todo el proceso, de esta manera, se garantiza atender las
inquietudes y brindar el mejor servicio acorde a los requerimientos analizados, por
consiguiente, se implica combinar diversas estrategias para respaldar las decisiones
tomadas durante el desarrollo.
Para tener una mejor experiencia y un mejor desarrollo, se optó por utilizar la
metodología SCRUM y usar un software de gestión de proyectos llamada Wrike. Con
SCRUM se logran agilizar los procesos y el desarrollo modular del proyecto.
Al implementar SCRUM, se establece una continua comunicación con el cliente, ya
que se generan entregables (sprints) en cierto periodo de tiempo, en el cual se discuten
los resultados logrados y a su vez si los mismos cumplen con los objetivos esperados;
de esta manera, se garantiza que cada parte del proyecto fue analizada y validada
como satisfactoria, o en su defecto es reestructurada o corregida para su próxima
evaluación.
Se optó por dar los entregables en un periodo de 2 semanas, solamente (dependiendo
del proyecto se decide el rango de tiempo que se tomará, puede ser de 2 a 4 semanas),
el equipo de testing debe gestionar y ordenar sus métodos de trabajo, esto con fin de
39
permitirse atender las actividades según su prioridad, de esta manera será posible la
obtención de contenido el cual sea considerado como aceptable de someter a
evaluación al presentarse la fecha de entrega del sprint.
Debido a la necesidad de organización, se implementa el software llamado Wrike, la
cual permite gestionar todas las actividades definidas durante las reuniones previas en
las cuales se analizan los requerimientos y se definen los objetivos, de esta manera,
se distribuyen los procesos adecuados al personal capaz de solucionarlos, permitiendo
a su vez que se definan las prioridades de atención, en las que se propone la solución
de problemas específicos antes que el resto de las tareas.
Wrike se centra en tres funciones principales con las que los usuarios interactúan:
carpetas, proyectos y tareas.
• Las carpetas son la estructura general para organizar proyectos y se pueden
segmentar en subcarpetas.
• Los proyectos incluyen información más detallada, como una fecha de inicio y
finalización o el estado del proyecto, y se pueden poner bajo el control de un
solo "propietario".
• Dentro de cada proyecto hay tareas, que describen acciones específicas que
se completarán como parte de objetivos más amplios. El propietario de un
proyecto puede asignar tareas a individuos o a múltiples miembros del equipo,
establecer fechas de vencimiento, agregar archivos adjuntos y proporcionar una
descripción más detallada del trabajo a realizar.
Wrike también proporciona una variedad de métodos visuales para seguir el progreso
del trabajo mientras está en marcha. Esto incluye tableros de estilo KANBAN, una vista
de lista, tablas de hojas de cálculo y diagramas de Gantt.
40
8- Desarrollo.
8.1- Proceso del Testing.
Las pruebas de software son realmente necesarias para señalar los defectos y
errores que se hicieron durante las fases de desarrollo. Es esencial ya que se asegura
de que el cliente encuentre la organización confiable y se mantenga su satisfacción
con la aplicación. Es muy importante garantizar la calidad del producto. El producto de
calidad entregado a los clientes ayuda a ganar su confianza. Las pruebas son
necesarias para proporcionar las instalaciones a los clientes, como la entrega de
productos o aplicaciones de software de alta calidad que requieren un menor costo de
mantenimiento y, por lo tanto, dan como resultado resultados más precisos,
consistentes y confiables [24].
8.1.1- Planeación y Control.
Wrike.
https://www.wrike.com/pr/
Imagen 3.1
41
En la fase de planificación, los clientes, las partes interesadas y los objetivos
del proyecto deben ser entendidos, esto se basa en los requerimientos que el cliente
pide que contenga el sistema. Así, los errores se minimizan.
En base a este conocimiento, se formarán las metas y objetivos que deberán ser
aprobados, se elegirá el enfoque sobre cómo se va a evaluar, el plan para las pruebas
se forma, así como la especificación de las actividades de prueba [25].
A planificación producirá un plan de prueba tangible, que debe modificarse para que
se adapte a la organización y al proyecto. En este proceso el equipo no forma parte y
no esta enterado de la planeación que se tomará, por supuesto, cuando el proyecto ya
esté en proceso, cualquier integrante del equipo puede dar ideas para la mejora del
proceso y de su planificación.
El documento de planificación debe tener una estructura similar a la siguiente:
• Introducción (alcance, riesgos y objetivos).
• Artículos de prueba (objeto (s) de prueba).
• Características a probar.
• Características que no se probarán.
• Enfoque (objetivos, técnicas, plantillas).
• Criterios de aprobación / falla del artículo (criterios de salida, incluidos los
criterios de cobertura).
• Criterios de suspensión y requisitos de reanudación.
• Entregables de prueba (productos de trabajo).
• Tareas de prueba (análisis, diseño, implementación, ejecución, evaluación,
informes y cierre; todo dividido en más actividades detalladas en una estructura
de desglose de trabajo adecuada).
• Necesidades ambientales.
• Responsabilidades.
42
• Necesidades de personal y capacitación.
• Programación.
• Riesgos y contingencias.
8.1.2- Análisis y Diseño.
Es esta parte, se dan las especificaciones y se diseñan los casos de prueba. Se
basa en la prueba ejecución que significa resultados esperados y qué entornos o
plataformas son requeridos. El propósito del diseño de la prueba es predecir cómo
funcionará el software realizar bajo ciertas condiciones. A veces los resultados de las
pruebas son insignificantes, pero si los resultados no se estiman, existe un alto riesgo
de pasar por alto algunos aspectos cruciales aspecto del software [25].
El análisis y diseño se divide en cinco partes:
Revisión de la base de prueba. La prueba base hace posible comenzar a construir
ciertas pruebas ya antes de la actual el código existe porque la documentación
proporciona cierta comprensión de qué el sistema debería hacer. Revisar la base de
la prueba también es una herramienta para encontrar brechas e ilegibilidad de las
especificaciones cuando se trata de entender claramente lo que diferentes puntos de
un sistema deberían hacer.
Identificar condiciones de prueba. Esto ayuda a construir una comprensión de alto
nivel de lo que es interesante para las pruebas. Identificando las condiciones de prueba
pueden basarse en varios aspectos y siempre es situacional. Las condiciones de
prueba pueden depender, por ejemplo, de la función, requisito o característica.
43
Diseño de pruebas. Los casos de prueba se crean dependiendo del nivel de dificultad,
a estas se les asocia un tiempo de ejecución (pueden ser horas, días o semanas).
El caso de prueba de alto nivel es un caso sin valores de entrada específicos o
resultados esperados. Los casos de prueba de alto nivel tienen reglas generales:
efectivo, que significa que los casos tienen una alta probabilidad de encontrar errores;
ejemplar, lo que significa que los casos deberían ser prácticos y evolutivo, lo que
significa estructural, flexible y mantenible. Las técnicas de prueba ayudan a identificar
los valores de entrada requeridos para la prueba de alto nivel casos, razón por la cual
no tienen que definirse en casos reales. La decisión de cuántos casos y condiciones
de prueba de alto nivel son documentado se basa en la estrategia y los riesgos
involucrados.
Ejemplo de un caso de prueba.
https://www.softwaretestinghelp.com/test-case-template-examples/
Imagen 3.2
44
El caso de prueba de bajo nivel es un caso donde también se definen una entrada y
resultados esperados. Caso de bajo nivel la documentación debe incluir al menos los
siguientes aspectos: identificación única, condiciones previas, aportes,
resultados esperados y condiciones posteriores.
El diseño de los casos de prueba se hace en diferentes herramientas de
administración. En mi caso, el cliente pidió que fuera en Excel. Softtek tiene una
plantilla para eso, así que se optó por utilizar la propia.
Evaluación de la capacidad de prueba del sistema. La capacidad de prueba del
sistema puede ser definido por si es posible probar un sistema en un entorno que
iguala el eventual entorno operativo y si es posible que se prueben todas las funciones
del sistema. En mi caso, el proyecto solo se probó en el sistema que utiliza la empresa
para la que le trabajamos, se puede decir que se limitó el proyecto a un solo sistema,
pero en realidad el sistema por si solo contiene todo lo necesario para el cliente e
incluso da la posibilidad de escalabilidad.
La capacidad de prueba para los requisitos significa que el los requisitos se han
documentado de una manera que se puede utilizar para construir pruebas, por
ejemplo, el requisito "el software debe responder rápidamente suficiente" no es
comprobable porque diferentes personas pueden entender la palabra "Suficiente" de
manera muy diferente.
Diseño y creación del entorno de prueba. En otras palabras, arregle todos los
sistemas y elementos necesarios para ejecutando la prueba.
8.1.3- Implementación y Ejecución.
En la fase de la implementación se comprende de: definición de los elementos
u objetos comprobables, la programación y la cantidad de personal incluido en el
proceso de prueba, la especificación del entorno de prueba para la construcción,
45
criterios de entrada saber cuándo se pueden iniciar las pruebas de los objetos y salir
de los criterios para saber cuándo la tarea esté terminada [25].
Una vez compilada la información se procederá a la ejecución de los casos de prueba
en el sistema. Aquí debe de probarse que lo que dice los requerimientos es lo que se
esta haciendo en el sistema, en dado caso de que sea incorrecta la acción del sistema,
se deberá tomar la decisión de la categoría que se le va a asignar: error, bug o
defecto.
Debe tenerse en cuenta quién está haciendo las pruebas, un tester experimentado o
especialistas no necesitarán descripción detallada del procedimiento como un tester
sin experiencia. Todos los procedimientos deben tener códigos de identificación
únicos, información general y los casos de prueba, organizados en un orden específico
para ejecutarse. Un procedimiento de prueba debe tener una cantidad limitada de
casos de prueba, de 2 a 20, ya que al ser más largo se hace tedioso el proceso.
Cada caso de prueba tiene su tiempo de ejecución. El tiempo de ejecución se lo asigna
el tester que desarrollo el caso de prueba.
8.1.3- Evaluación de Criterios de Salida e Informes.
En la evaluación de los criterios de salida las pruebas ejecutadas se comparan
con los criterios de aprobación / rechazo de los elementos especificados en la
planificación fase. Después de la ejecución de la prueba, el administrador de la prueba
evaluará si los criterios se han. Los criterios de salida deben ser definido por separado
para cada nivel de prueba y los criterios siempre varían en los diferentes proyectos
Con los criterios se puede establecer que cierto nivel de prueba o tarea completada.
Si no se han cumplido los criterios de salida determinados, no se puede finalizar la
prueba. Esto es cuando el proceso de prueba se ejecuta de forma iterativa, lo que
significa que une la fase se devuelve a donde se pueden repetir las pruebas, lo que
46
asegurará que el Se cumplirán los criterios. Esto significa a menudo volver a la fase
de diseño y análisis de la prueba porque aquí es donde se pueden refactorizar y crear
nuevos casos de prueba y la cobertura aumentó.
9- Resultados y Discusión.
Gracias a la implementación de la metodología ágil en el proyecto, se llego a
mejores resultados. La importancia de SCRM radica en que tiene a hacer el proceso
más rápido y también, tiene una mejor comunicación con el cliente y el equipo.
El SCRUM Master del proyecto nos ayudo en la facilitación de herramientas y a la
resolución de contratiempos que han llegado a surgir a lo largo del proyecto. Es
importante remarcar que el proyecto aún no esta finalizado, el proyecto durará 2 años
o más.
El equipo de trabajo se conformaba de 10 personas, todas ellas testers con mayor y
menor experiencia. Ese grupo de personas se dividió en dos células, a petición del
cliente: una enfocada a hardware y otra a software.
El Spring tiene duración de 2 semanas, esto hace muy rápido el proceso del proyecto,
cada día se dan un tiempo por la mañana para hablar acerca de progreso que ha tenido
cada integrante del equipo, de sus contratiempos y como el SCRUM Master los puede
solucionar, y lo que se va a hacer a lo largo del día. Dependiendo de la complejidad
de los casos de prueba, el tester dará un tiempo (que puede ser de una hora, un día o
incluso de una semana) para entregar el resultado. Gracias a la metodología SCRUM,
los módulos a los que se les han hecho pruebas han llegado a finalizarse en tiempo y
forma.
Es importante asegurarnos de que todo quedé según los requerimientos, y en dado
caso de que un requerimiento este confuso, el equipo se lo debe comunicar al SCRUM
Master y el SCRUM Master se lo debe comunicar al Product Owner, ya que este es el
47
que tiene un trato directo con el cliente; para así la duda sea resuelta y el requerimiento
pueda ser completado.
10- Conclusión.
Lo irónico del trabajo de un tester es que si principal función es encontrar errores y
hacer que un sistema falle. No solo te basas en los requerimientos que te plantea el
cliente, sino que tienes que excederte en alguna casa (situaciones que son muy poco
probables que ocurran).
La importancia de tener una organización en los procesos del proyecto es fundamental
para tener mejores resultados, ya que con una planificación se puede estar preparado
para los contratiempos que lleguen a ocurrir. Siempre se tiene la meta final del
proyecto, pero debido al tiempo que dure el proyecto es imposible tener un plan
general, así que lo que se hace es dividirlo por procesos con un tiempo de duración.
Como se demostró en los resultados, la hipótesis se cumplió y se pudo demostrar la
importancia de implementar la metodología ágil en el proceso del testing.
También, es bueno mencionar que es imposible tener un sistema libre de errores, sin
embargo, es posible tener un programa correcto.
11- Bibliografía.
[1] «IWantic,» [En línea]. Available: https://iwantic.com/que-es-un-qa-tester/.
[2] «Tutoria Point,» [En línea]. Available:
https://www.tutorialspoint.com/software_testing/software_testing_qa_qc_testing
.htm.
[3] «QA Laboratory,» [En línea]. Available: http://qalaboratory.com/quality/la-
diferencia-entre-el-testing-y-quality-assurance/.
48
[4] «Test IO,» [En línea]. Available: https://test.io/.
[5] «Software Testing Help,» [En línea]. Available:
https://www.softwaretestinghelp.com/what-is-actual-testing-process-in-practical-
or-company-environment/.
[6] «LinkedIn,» [En línea]. Available: https://www.linkedin.com/pulse/ser-qatester-
es-muy-f%C3%A1cil-s%C3%B3lo-si-tienes-estos-seis-navarro-rayo/.
[7] «Universia,» [En línea]. Available:
https://noticias.universia.com.ar/cultura/noticia/2017/05/05/1152110/ocupacione
s-tecnologicas-hace-analista-tester.html.
[8] «Jose Pablo Sarco,» [En línea]. Available:
https://josepablosarco.wordpress.com/2010/04/13/testing-vs-qa/.
[9] «Open Webinars,» [En línea]. Available: https://openwebinars.net/blog/tester-
software-tareas-principales/.
[10] «4r Soluciones,» [En línea]. Available: https://www.4rsoluciones.com/blog/que-
es-un-plan-de-qa-2/.
[11] «BBVA,» [En línea]. Available: https://www.bbva.com/es/metodologia-agile-la-
revolucion-las-formas-trabajo/.
[12] «OBS-EDU,» [En línea]. Available: https://www.obs-edu.com/int/blog-project-
management/metodologias-agiles/que-es-agile-y-cuales-son-los-12-principios-
de-su-modelo.
[13] «Agile Manifiesto,» [En línea]. Available:
https://agilemanifesto.org/iso/es/manifesto.html.
[14] «Agile Manifiesto,» [En línea]. Available:
https://agilemanifesto.org/iso/es/principles.html.
[15] «Medium,» [En línea]. Available: https://medium.com/acercamiento-a-las-
metodolog%C3%ADas-%C3%A1giles/valores-y-principios-del-manifiesto-
%C3%A1gil-aacaf3f326bf.
[16] «SCRUM,» [En línea]. Available: https://www.scrum.org/resources/blog/que-es-
scrum.
49
[17] «Netxus,» [En línea]. Available: https://netxus.org/historia-de-scrum/.
[18] «Prozess Group,» [En línea]. Available:
http://www.prozessgroup.com/procesos-de-scrum/.
[19] «Softeng,» [En línea]. Available: https://www.softeng.es/es-
es/empresa/metodologias-de-trabajo/metodologia-scrum/proceso-roles-de-
scrum.html.
[20] «Deloitte,» [En línea]. Available:
https://www2.deloitte.com/es/es/pages/technology/articles/roles-y-
responsabilidades-scrum.html.
[21] «Wrike,» [En línea]. Available: https://www.wrike.com/project-management/.
[22] «Daysoft,» [En línea]. Available: https://www.danysoft.com/wrike/.
[23] «Kefa Web,» [En línea]. Available: https://kefaweb.com/portfolio/gestion-de-
proyectos-con-wrike/.
[24] «SPRI,» [En línea]. Available:
http://www.spri.eus/euskadinnova/documentos/363.aspx.
[25] «ApiumHub,» [En línea]. Available: https://apiumhub.com/es/tech-blog-
barcelona/tecnicas-de-testeo-de-software/.
12- Glosario.
QA Testing.
Son las investigaciones empíricas y técnicas cuyo objetivo es proporcionar información
objetiva e independiente sobre la calidad del producto a la parte interesada. Es una
actividad más en el proceso de control de calidad.
Caso de prueba (Test Case).
50
Es un conjunto de condiciones o variables bajo las cuales un analista determinará si
una aplicación, un sistema software, o una característica de éstos es parcial o
completamente satisfactoria.
Metodología.
Hace referencia al conjunto de procedimientos racionales utilizados para alcanzar el
objetivo o la gama de objetivos que rige una investigación científica, una exposición
doctrinal o tareas que requieran habilidades, conocimientos o cuidados específicos.
Sistema de gestión.
Un sistema de gestión es un conjunto de políticas, procesos y procedimientos
utilizados por una organización para garantizar que pueda cumplir con las tareas
requeridas para lograr sus objetivos. Estos objetivos cubren muchos aspectos de las
operaciones de la organización.
