Post on 26-Jun-2020
transcript
DETERMINACION DE OPORTUNIDADES DE SINERGIA Y PLAN DE
RECOMENDACIONES PARA METODOLOGIAS DE DESARROLLO AGIL
ENFOCADO EN PRUEBAS PARA APLICACIONES DE DISPOSITIVOS
MOVILES
Maria Paula Lesmes Saenz
Weimar Pena Hernandez
Universidad Distrital Francisco Jose de Caldas
Facultad de Ingenieria
Ingenieria de Sistemas
Bogota, Colombia
2017
DETERMINACION DE OPORTUNIDADES DE SINERGIA Y PLAN DE
RECOMENDACIONES PARA METODOLOGIAS DE DESARROLLO AGIL
ENFOCADO EN PRUEBAS PARA APLICACIONES DE DISPOSITIVOS
MOVILES
Maria Paula Lesmes Saenz
Weimar Pena Hernandez
Trabajo de grado presentado como requisito parcial para optar al tıtulo de:
Ingeniero(a) de Sistemas
Directora:
Lilian Astrid Bejarano Garzon MsC
Revisor:
Sandro Bolanos Castro PhD
Universidad Distrital Francisco Jose de Caldas
Facultad de Ingenieria
Ingenieria de Sistemas
Bogota, Colombia
2017
DEDICATORIA
“A mi mama quien me dio todo y gracias a ella soy una mejor persona cada dıa, a
mi familia por ser mi fuerza para estar donde estoy y a ti amor que me apoyaste en
todo momento.”
Maria Paula Lesmes Saenz
“Somos lo que los recuerdos nos ensenan, como los recuerdos nos forman.
Somos cada aprendizaje que queda en nuestro ser.
Somos las alegrıas y amor que nuestros seres queridos compartieron y comparten.
Somos parte de todos, como lo somos de un todo.
Somos y seremos todo lo que queramos ser.”
Weimar Pena Hernandez
NOTAS DE ACEPTACION
Jurado
Jurado
Jurado
Jurado
Bogota D.C., Septiembre 2017
Tabla de Contenido
INTRODUCCION 1
I. CONTEXTUALIZACION DE LA INVESTIGACION 3
1. DESCRIPCION DE LA INVESTIGACION 5
1.1. Planteamiento/Identificacion del Problema . . . . . . . . . . . . . . . . . . . 5
1.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.1. Objetivo General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.2. Objetivos Especificos . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3. Justificacion de la Investigacion . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4. Hipotesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.5. Marco de Referencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.5.1. Marco Teorico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.5.2. Marco Conceptual . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.6. Metodologıa de la Investigacion . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.6.1. Tipos de Estudio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.6.2. Metodos de Investigacion . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.6.3. Fuentes y Tecnicas para Recoleccion de Informacion . . . . . . . . . . 21
1.7. Organizacion del Trabajo de Grado . . . . . . . . . . . . . . . . . . . . . . . 22
1.8. Estudio de Sistemas Previos . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
x Tabla de Contenido
II. DESARROLLO DE LA INVESTIGACION 25
2. IMPORTANCIA DE LAS PRUEBAS EN APLICACIONES MOVILES 27
3. IDENTIFICACION DE FALENCIAS EN METODOLOGIAS EXISTENTES 32
4. MEJORAS ENFOCADAS EN PRUEBAS PARA METODOLOGIAS AGILES 34
4.1. Complemento por Parte del Equipo de Pruebas . . . . . . . . . . . . . . . . 34
4.2. Correlacion Entre Equipos y Pruebas por Ciclos . . . . . . . . . . . . . . . . 34
4.3. Procesos de Seleccion del Equipo de Trabajo . . . . . . . . . . . . . . . . . . 40
4.4. Mejoras a Curvas de Aprendizaje . . . . . . . . . . . . . . . . . . . . . . . . 41
5. VENTAJAS DEL USO DE LAS MEJORAS PRESENTADAS 44
6. ANALISIS MATEMATICO DE LA IMPLEMENTACION DE LAS MEJORAS 47
III. CIERRE DE LA INVESTIGACION 49
7. CONCLUSIONES 51
7.1. Verificacion, Contraste y Evaluacion de los Objetivos . . . . . . . . . . . . . 51
7.1.1. Verificacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
7.1.2. Contraste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
7.1.3. Evaluacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
7.2. Sıntesis del Modelo Propuesto . . . . . . . . . . . . . . . . . . . . . . . . . . 52
7.3. Aportes Originales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
8. PROSPECTIVA DEL TRABAJO DE GRADO 55
8.1. Lıneas de Investigacion Futura . . . . . . . . . . . . . . . . . . . . . . . . . . 55
8.2. Trabajos de Investigacion Futuros . . . . . . . . . . . . . . . . . . . . . . . . 55
BIBLIOGRAFIA Y REFERENCIAS WEB 57
Tabla de Contenido xi
IV. ANEXOS 59
.1. Anexo: Analisis Documental . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
.2. Anexo: Analisis Para Deteccion y Reporte Errores . . . . . . . . . . . . . . . 62
.2.1. Identificacion de un Error . . . . . . . . . . . . . . . . . . . . . . . . 62
.2.2. Elementos para el reporte de errores . . . . . . . . . . . . . . . . . . 65
Tabla de Ilustraciones
1-1. Metodologıas Tradicionales Vs Metodologıas Agiles . . . . . . . . . . . . . . 10
1-2. Metodologıa Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1-3. Metodologıa MOBILE-D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1-4. Metodologıa TDD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1-5. Metodologıa Espiral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1-6. Tipos de prueba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2-1. Play Store 25 de Enero 2017 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2-2. Play Store 10 de Febrero 2017 . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2-3. Crecimiento exponencial de WhatsApp . . . . . . . . . . . . . . . . . . . . . 29
2-4. Version de pruebas WhatsApp . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4-1. Trabajo en equipo y apoyo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4-2. Ciclos de pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4-3. Tablero de trabajo (Tipo Scrum) . . . . . . . . . . . . . . . . . . . . . . . . 38
4-4. Niveles de seleccion del equipo de trabajo . . . . . . . . . . . . . . . . . . . . 41
4-5. Etapas de aprendizaje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5-1. Reporte de errores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5-2. Asignador de tareas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
6-1. Documentacion Vs Vacıos funcionales . . . . . . . . . . . . . . . . . . . . . . 48
INTRODUCCION
Actualmente el auge de las tecnologıas y comunicaciones han traıdo consigo un incre-
mento exponencial de los dispositivos moviles y sus desarrollos, teniendo en cuenta que se
convirtio en parte fundamental el uso de dispositivos moviles se hizo necesaria la masificacion
de las aplicaciones moviles. Con esto, el crecimiento de las aplicaciones moviles trae consigo
problematicas en el ciclo del desarrollo al hacer infinito el proceso de desarrollo de software
por ser actualizacion tras actualizacion de aplicaciones mal controladas antes de su entrega
al usuario final.
El proyecto de recomendaciones para metodologıas de desarrollo agil enfocado en prue-
bas pretende dar solucion a tanta iteracion sobre los errores que reportan los usuarios finales
al mantener un control del proyecto desde las etapas iniciales con el fin de reducir costos
e iteraciones, trayendo beneficios tanto para todos los entes implicados desde el equipo de
desarrollo hasta el usuario final. Este proyecto se basa en una investigacion del ambito de
las pruebas en el desarrollo de aplicaciones para dispositivos moviles como tambien en las
experiencias que tienen tanto usuarios finales como el equipo que saca una aplicacion al
mercado.
Las caracterısticas principales del plan se concentran en implantar un modelo de prue-
bas en cada fase del proyecto donde se vean implicados cada uno de los participantes y esten
involucrados en el proceso, siendo ası una participacion continua partiendo de los requeri-
mientos hasta la entrega final dando como resultado procesos que eviten la iteracion continua
en errores y una entrega al usuario final en optimas condiciones.
2 Tabla de Ilustraciones
Este plan requiere de una guıa continua donde durante cada ciclo los integrantes puedan
reconocer que pruebas o elementos a revisar deben tener en cuenta para que la etapa sea
exitosa y se cumpla con unas metas trazadas desde el comienzo de cada fase, como se especi-
fica en las metodologıas agiles con las cuales se desarrollan las aplicaciones para dispositivos
moviles.
El interes en este tema nace de ver como los usuarios finales reportan error tras error
en los centros de descarga, mostrando que se liberan aplicaciones sin control de errores y
generando costos elevados a quienes publican las aplicaciones con el fin de mantener su
software y reputacion en los centros de descarga.
Parte I.
CONTEXTUALIZACION DE LA
INVESTIGACION
1. DESCRIPCION DE LA
INVESTIGACION
1.1. Planteamiento/Identificacion del Problema
El desarrollo de aplicaciones para dispositivos moviles y las metodologıas de desarrollo
de dicha tipologıa de aplicaciones estan enfocadas en un modelo agil, dado que las pruebas
solo se realizan en las ultimas etapas del proceso de software, es necesario plantear una nueva
propuesta donde las pruebas sean tenidas en cuenta en las distintas etapas e iteraciones del
proceso, trayendo consigo de esta manera, reduccion tanto en costos como de iteraciones del
proyecto. [1]
Teniendo en cuenta lo planteado y sumado a que las personas desconocen las meto-
dologıas de pruebas existentes, se disenara un plan de recomendaciones para metodologıas
de desarrollo enfocadas en pruebas que faciliten el proceso, el desarrollo agil del proyecto y
reduzca los costos del producto final al evitar el exceso de iteraciones.
Debido a la carencia de una nueva metodologıa o una mejora profunda de alguna ya
existente, seguiran existiendo proyectos llenos de actualizaciones y cambios en medio de la
exposicion al usuario; actualmente en muchas plataformas presentan gran cantidad de re-
portes de errores por parte de los usuarios finales, los cuales son los mas importantes en el
proceso ya que son ellos quienes reciben el producto final y esperan que sea un producto
optimo que cumpla con lo que requieren en el momento de utilizarlo.
6 1 DESCRIPCION DE LA INVESTIGACION
Se propone desarrollar una serie de recomendaciones las cuales ayuden a atenuar la
cantidad de errores comunmente encontrados en etapas finales del ciclo de vida de software,
con base en pruebas de software disenadas para cada etapa con procesos paralelos de diseno
y documentacion de las mismas incluyendo el analisis de la documentacion e inclusion en los
procesos de diseno de la plataforma con el fin de buscar oportunidades de sinergia en todo
el proceso.
1.2. Objetivos
1.2.1. Objetivo General
Formular un plan de recomendaciones para la metodologıa de desarrollo agil enfocada
en aplicaciones moviles que mediante el uso de pruebas induzcan la optimizacion del desa-
rrollo y reduccion de costos dentro del proyecto evidenciando sinergia en todo el proceso de
creacion de una aplicacion.
1.2.2. Objetivos Especificos
Crear nuevos procesos y plantillas de validacion funcionales, generando la inclusion de
pruebas en cada una de las fases del ciclo de vida del software partiendo de las re-
comendaciones dadas por el mercado, trayendo consigo un acompanamiento continuo
con el fin de reducir los errores en la etapa de finalizacion y entrega del software.
Demostrar que el uso de cada uno de los componentes del plan de recomendaciones
evidenciara la sinergia del proyecto, tomando como punto de referencia principal el
analisis de cada uno de los stakeholders, con el fin de mostrar que el sistema actua
mejor frente al medio.
1.3 Justificacion de la Investigacion 7
Facilitar a desarrolladores de aplicaciones para dispositivos moviles el uso de meto-
dologıas agiles mas robustas, con la inclusion de las recomendaciones en las etapas
del proyecto, mejorando la calidad de sus entregables y la percepcion de los usuarios
finales, brindando un apoyo al desarrollador emprendedor el cual desea publicar su
proyecto en las tiendas de aplicaciones.
1.3. Justificacion de la Investigacion
El presente trabajo tiene como objeto de estudio investigar una serie de recomenda-
ciones y ajustes basados en los estandares dados por el mercado en una metodologıa agil
usada para el desarrollo de aplicaciones moviles. Se pretende plantear un modelo teorico
basado en la relacion Calidad-costo-tiempo en los entregables e iteraciones a que de lugar la
aplicacion de dicho plan, lo cual permitira a los usuarios obtener mejores productos y a los
proyectos mayor calidad y organizacion en sus desarrollos sin tantas iteraciones ni errores.
Este plan de recomendaciones se disena con el proposito de ser implementado en desarrollos
y metodologıas agiles enfocadas principalmente en dispositivos Android y IOS, debido a que
la mayorıa de usuarios de aplicaciones moviles en sus dispositivos cuentan con estos sistemas
operativos y acceden a sus centros de descarga.
El resultado de la investigacion es un planteamiento teorico-practico que muestra las re-
comendaciones a seguir y los pasos a tener en cuenta para que estas surjan efecto. El caso de
estudio verifica la eficacia del planteamiento realizado por lo tanto se pretenderıa que fuera
implementado con una metodologıa agil en un prototipo de desarrollo y posteriormente que
se pueda aceptar y adaptar en otras metodologıas existentes.
La finalidad de la investigacion consistira en que los usuarios finales puedan obtener
mejores productos con menor cantidad de errores e iteraciones que los solucionen, ya que
8 1 DESCRIPCION DE LA INVESTIGACION
no existe en la actualidad una metodologıa agil que lo pueda lograr con gran precision, sin
aumentar costos y tiempos de manera excesiva; para ello el plan debe ser adaptable y ma-
leable a los cambios que puedan existir entre las diferentes metodologıas existentes y con eso
convertirse en un plan mas general.
Los resultados se veran reflejados al final del caso de estudio cuando se haga la diferencia
de tiempo con datos comparativos del uso de las metodologıas actuales antes y despues del
uso del plan de recomendaciones. Esta tambien sera una solucion concreta a problemas socio-
economicos que permitiran mejorar la vida del micro empresario que intenta competir en
centros de descarga abarrotados de aplicaciones, en los cuales su oportunidad es que los
usuarios finales aprueben y califiquen sus aplicaciones entre los mas altos puntajes para que
esta sea llamativa a los demas usuarios.
1.4. Hipotesis
La generacion de nuevas ideas e inclusion de mejoras en los procesos, tal como lo son
optimizar las curvas de aprendizaje con estandares y guıas claras al interior del equipo, gene-
rar herramientas que apoyaran la seleccion de nuevos recursos y ayudar al equipo en obtener
un resultado agil de cada fase del ciclo de vida del software, implican que se realizara un
trabajo sincronizado, organizado, en total sinergia y estableciendo con ello la homeostasis
en el proyecto.
1.5. Marco de Referencia
1.5.1. Marco Teorico
Ingenierıa de software
La ingenierıa del software [1] es una disciplina de la ingenierıa que comprende todos los
aspectos de la produccion del software desde las etapas iniciales de la especificacion del sis-
1.5 Marco de Referencia 9
tema, hasta el mantenimiento de este despues de que se utiliza. En esta definicion existen
dos frases claves: Disciplina de la ingenierıa y Todos los aspectos de produccion de software.
En general, los ingenieros de software adoptan un enfoque sistematico y organizado en su
trabajo, ya que es la forma mas efectiva de producir software de alta calidad. Sin embargo,
aunque la ingenierıa consiste en seleccionar el metodo mas apropiado para un conjunto de
circunstancias, un enfoque mas informal y creativo de desarrollo podrıa ser efectivo para
algunas circunstancias.
El ciclo de vida de software como sistema
Un sistema se define como un conjunto de elementos interrelacionados que cumplen un
objetivo en el cual se tiene una entrada y salida, se encuentra inmerso en un medio, tiene
lımites ademas de tener caracterısticas propias como la sinergia, homeostasis y el holismo.
Es ası como el ciclo de vida de software puede verse como un sistema dentro del cual se
pueden determinar los diferentes elementos (como lo son los participantes dentro del proce-
so, la documentacion, los disenos, Etc.), la entrada que corresponde a los requerimientos del
cliente, la aplicacion como la salida del sistema y el objetivo de crear una aplicacion en medio
de un ambiente competitivo que crece diariamente debido a la expansion de las tecnologıas
moviles y la necesidad de los usuarios por tener aplicaciones estables y nuevas.
Pero como entran aquı las caracterısticas propias de un sistema, teniendo en cuenta que
la suma de las partes es mayor que el todo, se puede mostrar que la documentacion, las
pruebas, los disenos o lo demas por sı solo no son nada, y el todo se puede ver como la
aplicacion pero por debajo la suma de las partes anteriormente nombradas demuestran que
es una aplicacion estable es decir que el sistema es sinergico. Se puede decir que el sistema
es homeostatico por regularse a sı mismo y teniendo en cuenta que la idea es identificar los
errores para corregirlos antes de salir al usuario final se mostrara como se regula el sistema
sin necesidad de entes externos ya que el plan de pruebas dara las mejoras en procesos previos.
10 1 DESCRIPCION DE LA INVESTIGACION
Por ultimo se podra decir que el holismo se presenta dentro de este sistema al mostrar al
observador (el usuario) la muestra de un solo sistema mientras que para un ente dentro del
sistema sentira cada una de las partes y las etapas del mismo.
Metodologıas agiles
Las metodologıas agiles, a diferencia de las metodologıas tradicionales, se componen de ca-
racterısticas importantes como lo son la flexibilidad en cuanto a ser adaptables a los equipos
y proyectos, y por ser ordenadas en cuanto a la determinacion de las tareas, fases y tiempos.
Cuando se trata de proyectos cortos se facilita el uso de estas metodologıas las cuales
toman un periodo corto de tiempo de 2 a 6 semanas aproximadamente en las cuales la co-
municacion con el cliente es constante, mostrando que el proyecto se convierte en una suma
de conocimiento de todos los participantes en el y genera que el proyecto sea adaptable para
poder soportar el constante cambio de requerimientos.
Ilustracion 1-1.: Metodologıas Tradicionales Vs Metodologıas Agiles
Fuente: Revision de metodologıas agiles para el desarrollo de software. [2]
Metodologıa SCRUM
Scrum es un marco de trabajo de procesos que ha sido usado para gestionar el desarrollo
de productos complejos desde principios de los anos 90. Scrum no es un proceso o una tecnica
1.5 Marco de Referencia 11
para construir productos; en lugar de eso, es un marco de trabajo dentro del cual se pueden
emplear varias tecnicas y procesos. Scrum muestra la eficacia relativa de las practicas de
gestion de producto y las practicas de desarrollo, de modo que se pueda mejorar [3]
Ilustracion 1-2.: Metodologıa Scrum
Fuente: Why scrum? Why agile development? [4]
Metodologıa Mobile-D
Mobile-D es la metodologıa de VTT, Valtion Teknillinen Tutkimuskeskus, en ingles Tech-
nical Research Centre of Finland, para el desarrollo agil de software. Ademas del desarrollo
de software para moviles, es conveniente para los varios contextos, por ejemplo, la seguridad,
logıstica y aplicaciones de simulacion de productos. [5]
12 1 DESCRIPCION DE LA INVESTIGACION
Ilustracion 1-3.: Metodologıa MOBILE-D
Fuente: MOBILE-D [5]
Se compone de distintas fases: exploracion, inicializacion, fase de producto, fase de esta-
bilizacion y la fase de pruebas. Cada una tiene un dıa de planificacion y otro de entrega.
En la fase de exploracion se centra la atencion en la planificacion y a los conceptos basicos
del proyecto. En la iniciacion se configura el proyecto identificando y preparando todos los
recursos necesarios, en la fase de producto se repiten iterativamente las subfases. Se usa el
desarrollo dirigido por pruebas, en la fase de estabilizacion en la que se realizan las acciones
de integracion para enganchar los posibles modulos separados en una unica aplicacion y la
fase de pruebas donde una vez parado totalmente el desarrollo se pasa una fase de validacion
hasta llegar a una version estable segun lo especificado en las primeras fases por el cliente.
Si es necesario se reparan los errores, pero no se desarrolla nada nuevo.[6]
Metodologıa TDD, Test Driven Development, Desarrollo Basado En Pruebas
Es una tecnica de programacion que consiste en escribir primero las pruebas, despues
escribir el codigo fuente que pase la prueba satisfactoriamente y, por ultimo, rehacer el
codigo escrito. Esta tecnica trae consigo un codigo mas robusto, mas seguro, mas mantenible
y una mayor rapidez en el desarrollo.
1.5 Marco de Referencia 13
Ilustracion 1-4.: Metodologıa TDD
Fuente: Test Driven Development and Agile [7]
Metodologıa Desarrollo en Espiral para Moviles
Esta propuesta metodologica utiliza el modelo de desarrollo en espiral como base, e in-
corpora procesos de evaluacion de la usabilidad, priorizando la participacion del usuario en
todos los procesos del ciclo de vida de diseno, con el fin de garantizar un diseno centrado
en el usuario, aun cuando se trata de un modelo de proceso orientado a proyectos grandes y
costosos, ya que esta destinado a ser un modelo de reduccion de riesgos. [8]
14 1 DESCRIPCION DE LA INVESTIGACION
Ilustracion 1-5.: Metodologıa Espiral
Fuente: Tema: Ingenierıa de Software I Modelos de desarrollo: espiral. [9]
Caracterısticas del Desarrollo de Aplicaciones Moviles
El desarrollo de aplicaciones moviles a diferencia del desarrollo convencional debe satisfacer
caracterısticas especiales como lo son:
Canal radio: la disponibilidad, las conexiones, la variabilidad del ancho de banda, la
heterogeneidad de redes o los riesgos de seguridad.
Movilidad: la migracion de direcciones o la gestion de la informacion dependiente de
localizacion.
Portabilidad: aquı difiere el tipo de equipo por su interfaz fısica como lo son tamano
de pantalla, procesador, RAM, etc.
1.5 Marco de Referencia 15
Time-to-market: corresponde a los tiempos y requisitos para el lanzamiento de aplica-
ciones al mercado. [10]
Pruebas de Software
Las pruebas de software, testing en ingles, son los procesos que permiten verificar y revelar
la calidad de un producto software antes de su puesta en marcha [11]. Dichas pruebas pueden
clasificarse segun el enfoque como pruebas de caja blanca, el codigo, y pruebas de caja negra
donde se validan segun las funcionalidades que tenga el desarrollo es decir la entrada y salida
de datos sin importar el procesamiento interno de los datos.
Ilustracion 1-6.: Tipos de prueba
Fuente: Tema: Ingenierıa de Software I Modelos de desarrollo: espiral. [9]
Tipos o Categorıas de Pruebas
Dentro del ambito de las pruebas existen diferentes categorıas en las cuales se pueden
clasificar las pruebas dentro de las cuales se pueden seleccionar dependiendo de la aplicacion
desarrollada, a continuacion, se presentan los diferentes tipos con su propia definicion:
Unitarias: Se focaliza en ejecutar cada modulo.
16 1 DESCRIPCION DE LA INVESTIGACION
Integracion: Identifica errores al combinar modulos probados unitariamente
Regresion: identifica si hay cambios tras una actualizacion o cambio en el desarrollo
Smoke: corresponde a una prueba del sistema de forma constante con poco esfuerzo
asegurando las pruebas unitarias
Sistema: se enfoca en el ingreso y procesamiento de los datos
Desempeno: asociadas al tiempo de respuesta y funcionalidad especifica del negocio
teniendo en cuenta el volumen normal o el maximo posible
Carga: maneja los tiempos de respuesta de una accion especıfica.
Stress: se relaciona especıficamente con casos bajo condiciones como memoria baja, sin
conexion al servidor, maximo numero de usuarios conectados, multiplicidad de acciones
con los mismos datos.
Volumen: corresponde con el maximo numero de usuarios ejecutando una misma accion
o multiples consultas en la base de datos.
Recuperacion: valida los procesos de recuperacion del sistema a partir de un fallo hasta
un estado deseado.
Compatibilidad: busca errores en la compatibilidad entre sistemas es decir por cambio
en exploradores, sistemas operativos, etc.
Seguridad: comprende los niveles de seguridad de la aplicacion frente al usuario y los
niveles de seguridad del sistema que corresponden al acceso.
Logica de negocio: se detalla que el sistema funcione como lo especifica el modelo de
negocio estipulado.
Flujos y navegacion: corresponde con todo lo que tiene que ver con interfaz grafica de
usuario (colores, posiciones, tamanos, funcionalidad de botones, campos, listas, etc.)
1.5 Marco de Referencia 17
Configuracion: tiene que ver con el como funciona el sistema al realizar la instalacion
y configuracion para el funcionamiento de la plataforma.
Funcionales: corresponden con la integracion de las anteriores categorıas es decir que
tiene en cuenta el funcionamiento, el flujo de los datos, la navegacion y los resultados
obtenidos
Documentacion: corresponde con la evaluacion de la documentacion a entregar al
cliente.[11]
1.5.2. Marco Conceptual
A continuacion, se definiran los terminos que se usaron en la investigacion:
Metodologıa: Una metodologıa es una coleccion de procedimientos, tecnicas, herramien-
tas y documentos auxiliares que ayudan a los desarrolladores de software en sus esfuerzos
por implementar nuevos sistemas de informacion. Una metodologıa esta formada por fases,
cada una de las cuales se puede dividir en sub-fases, que guiaran a los desarrolladores de
sistemas a elegir las tecnicas mas apropiadas en cada momento del proyecto y tambien a
planificarlo, gestionarlo, controlarlo y evaluarlo.[12].
Prueba: Es una actividad en la que un sistema o un componente es ejecutado bajo condi-
ciones especificadas, los resultados son observados o registrados, y una evaluacion es realizada
de un aspecto del sistema o componente. [13].
Sinergia: Se define como la accion de dos o mas causas que generan un efecto superior
al que se conseguirıa con la suma de ambos en forma individual. Se le considera como la
integracion de partes o sistemas que conforman un nuevo elemento u objeto, dos elementos
que se unen y forman una sinergia ofrecen un resultado que amplıa las cualidades de cada
uno, ya que suelen mostrar y resaltar las cualidades del trabajo en equipo para realizar o
conseguir un mismo objetivo. [14]
18 1 DESCRIPCION DE LA INVESTIGACION
Homeostasis: Es la caracterıstica de un sistema abierto o de un sistema cerrado o una
conjugacion entre ambos, mediante la cual se regula el ambiente interno para mantener una
condicion estable y constante. [15]
Planeacion de Pruebas: Es la etapa en donde se ejecutan las primeras actividades co-
rrespondientes al proceso de pruebas y tiene como resultado el plan de pruebas el cual debe
estar conformado por el Alcance, tipo de pruebas, estrategias y otros aspectos. Se puede
dividir en la planeacion realizada por el lıder de pruebas frente a todo el proyecto con una
propuesta macro y organizacion de las pruebas contra la planeacion de un analista que con-
siste en la estimacion de cada uno de las nuevas funcionalidades.
Defecto: Imperfeccion en un componente o sistema que puede causar que el componente o
sistema falle en desempenar las funciones requeridas. Se puede interpretar como las falencias
detectadas en ambientes de calidad o pruebas.
Falla: Es la discrepancia visible que se produce al ejecutar un programa con un defecto,
el cual es incapaz de funcionar correctamente. Se puede interpretar como las falencias detec-
tadas por el usuario final.
Error de software: Accion humana que produce un resultado incorrecto. Se puede in-
terpretar como las falencias detectadas en ambientes de desarrollo.
Usuario: Es la persona que utiliza el software o hardware despues de que ha sido com-
pletamente desarrollado, comercializado, e instalado.
Aplicacion: Es un programa de software que se ejecuta en el ordenador, navegadores
web, programas de correo electronico, procesadores de texto, juegos y utilidades son todas
las aplicaciones. La palabra “aplicacion” se utiliza porque cada programa tiene una aplica-
1.5 Marco de Referencia 19
cion especıfica para el usuario.
Tiendas de aplicaciones: Hace referencia a los mercados de aplicaciones existentes como
AppStore, PlayStore o Windows Store Marketplace.
Aprendizaje por intuicion: Comprende el analisis realizado por las experiencias del
usuario y su posterior aprendizaje de dichas experiencias, por ejemplo: tocar una tecla de un
piano y entender que genera un sonido. Gracias a dicho proceso permite al usuario interpre-
tar las diferentes circunstancias del entorno, como dice Wolfgang Kohler: “el aprendizaje se
produce debido a una captacion repentina o subita de relaciones del problema, es decir por
intuicion o discernimiento. Supone una interrelacion de conductas e informacion, es decir,
el sujeto llega subitamente a la solucion mediante una reorganizacion del campo perceptivo,
capta, internaliza o comprende, una “verdadrevelada.”
Requerimiento: Descripcion detallada del funcionamiento a desarrollar, tambien se pue-
de comprender como las caracterısticas necesarias para el funcionamiento del software.‘
Requerimientos Funcionales: Comprende la definicion del comportamiento, entradas
y salidas de uno o varios de los componentes del software.
Requerimientos No Funcionales: Corresponde a los requerimientos que no implican
actividad con la informacion a guardar o funciones del software, es decir conciernen a carac-
terısticas de funcionamiento, por eso suelen denominarse Atributos de calidad. Como lo son
Rendimiento, disponibilidad, accesibilidad, usabilidad, estabilidad, portabilidad, entre otros.
20 1 DESCRIPCION DE LA INVESTIGACION
1.6. Metodologıa de la Investigacion
1.6.1. Tipos de Estudio
La investigacion ha llevado a hacer una aproximacion por primera vez al conocimiento
del problema, dado que las metodologıas agiles han sido una interesante forma de abarcar
las distintas soluciones planteadas en forma de aplicaciones moviles lo cual es relacionado
con el plan de mejoras a implementar para generar un producto estable y optimo.
Para la implementacion de un plan de recomendaciones para metodologıa de desarrollo
agil enfocado en pruebas para aplicaciones de dispositivos moviles y la sostenibilidad del
desarrollo, el tipo de estudio que mejor se ajusta a la investigacion es el correlacional; ya que
este tiene el proposito de medir el grado de relacion que existe entre 2 a mas conceptos o
variables, y en la investigacion las principales variables son: los usuarios, las aplicaciones y las
metodologıas entre otras, donde se van a interrelacionar para su respectivo funcionamiento.
Se hace una recopilacion de tipo teorica. Este trabajo puede servir como antesala a la
ampliacion conceptual del plan de recomendaciones planteado o la implementacion en otros
tipos de metodologıas de desarrollo a usar. El problema abarca comportamientos de tipo
social y empresarial de una colectividad como lo son los desarrolladores o proyectos los cuales
su nicho de negocio sean las aplicaciones moviles, debido a que la baja calidad en las primeras
iteraciones de las aplicaciones puede generar un impacto negativo en el comportamiento de
los usuarios como por ejemplo rechazos y crıticas que muestren la inconformidad de las
personas y perdida de potenciales usuarios.
1.6.2. Metodos de Investigacion
Para el proceso de investigacion de una determinacion de oportunidades de sinergia y
plan de recomendaciones para metodologıa de desarrollo agil enfocado en pruebas para apli-
caciones de dispositivos moviles se utilizara el metodo inductivo, dado que se va a aplicar
conceptos previamente analizados en el marco teorico y se va a implementar en el entorno del
1.6 Metodologıa de la Investigacion 21
problema de investigacion, utilizando para ello una muestra de desarrollo de una aplicacion
movil y verificar su acogida en las tiendas de aplicaciones.
Basados en que existen estandares y metodologıas ya aprobados se utilizara la investi-
gacion descriptiva, con proposito de analizar los procesos actuales y determinar mejoras a
los problemas comunes de los equipos de pruebas junto con los demas equipos del proceso
del software.
1.6.3. Fuentes y Tecnicas para Recoleccion de Informacion
En el proceso de investigacion como referencias primarias se usaron el libro virtual “A
timeline: the evolution of testing tolos” el cual corresponde a un resumen realizado por va-
rios expertos en pruebas de software publicado por ThoughtWorks en el ano 2014; tambien
se utilizo la tesis de grado “Estado del arte y tendencias en Test-Driven Development” de
Carlos Fontanela de la Universidad Nacional de La Plata [16]. En el cual hace un completo
analisis de TDD y del desarrollo agil.
La tecnica para el proceso investigativo comprende tanto la experiencia vivida tras tra-
bajar como analistas de calidad, tambien la colaboracion con otros companeros que manejan
la creacion de aplicaciones moviles, ademas de ello se incluye un proceso de observacion de
creacion de las mismas aplicaciones con el fin de tener el analisis completo de los errores
cometidos al utilizar metodologıas agiles sin tener en cuenta las pruebas.
Para la creacion del plan de mejoras se basan en las metodologıas agiles existentes junto
con la amplia variedad de estandares y conceptos de pruebas los cuales no se encuentran
unificados pero junto con listas de chequeo se planteara como realizar las pruebas o cuales
pueden hacer parte del proyecto.
En el proceso de aplicacion se utilizan herramientas como Testlink y Mantis en los cuales
se plantean las diferentes etapas del desarrollo, en cuanto a la generacion de las listas de
22 1 DESCRIPCION DE LA INVESTIGACION
chequeo y el estado del proyecto se realizara en Bitrix24 la cual es una herramienta que esta
disenada para organizar las etapas de un proyecto agil y Trello que corresponde a un tablero
para la visualizacion de las tareas y estados de las mismas.
1.7. Organizacion del Trabajo de Grado
El trabajo se dividira en cinco capıtulos dentro de los cuales se analizaran la impor-
tancia, falencias, posibles mejoras y ventajas de las pruebas de software para dispositivos
moviles. Adicional a ellos se adiciona un analisis matematico del porque la documentacion
se convierte en parte primordial del proceso de creacion y mantenimiento del software.
1.8. Estudio de Sistemas Previos
Se realiza una revision bibliografica referente al plan de recomendaciones metodologıas
de pruebas expuestas en el presente proyecto en los marcos tanto teorico como conceptual,
ası mismo se revisa el contenido y desarrollo de la Manifiesto por el Desarrollo agil de Soft-
ware [17] donde exponen lo siguiente:
Los “Metodos agiles” surgen como alternativa a las metodologıas formales (CMMI,
SPICE) las cuales se caracterizaban por ser extensas por su caracter normativo y fuerte
dependencia de planificaciones detalladas previas al desarrollo. Se denomina Manifiesto agil
al documento compuesto por los siguientes postulados:
A los individuos y su interaccion, por encima de los procesos y las herramientas
El software que funciona, por encima de la documentacion exhaustiva.
La colaboracion con el cliente, por encima de la negociacion contractual.
La respuesta al cambio, por encima del seguimiento de un plan.
1.8 Estudio de Sistemas Previos 23
Teniendo en cuenta que aunque hay valor en los elementos de la derecha, valoramos
mas los de la izquierda. De estos postulados nacen todas las metodologıas agiles y se tienen
extensos trabajos donde se analiza una a una.
Tambien se revisa el contenido de Trabajo Final de Especializacion en Ingenierıa de
Software: Estado del arte y tendencias en Test-Driven Development de Carlos Fontanela
donde explica con claridad la importancia de las pruebas de software teniendo en cuenta que
la “TDD es una tecnica que combina pruebas, especificacion y diseno en una unica actividad
holıstica”, y que tiene como objetivo acortar los ciclos de desarrollo con caracterısticas como
una regresion completa.
En este caso en particular se presentan diferentes tipos de TDD con diferentes carac-
terısticas segun la necesidad o enfoque de quien determine la metodologıa a utilizar sin
embargo no se tiene una TDD integrada la cual aplique para todas las etapas del proyecto
e involucre a cada uno de los equipos(requerimientos, pruebas y desarrollo). El conocimien-
to e investigacion dieron resultado al analisis anterior que termina especificando de forma
practica los tipos de TDD y su forma de aplicacion mas sencilla.
Aunque se tienen extensas propuestas del uso de pruebas en las diferentes metodologıas
y por otro lado analisis y mejoras a las metodologıas agiles, se detecta que no se tienen en
cuenta la compatibilidad entre dichos analisis.
Parte II.
DESARROLLO DE LA
INVESTIGACION
2. IMPORTANCIA DE LAS PRUEBAS
EN APLICACIONES MOVILES
Desde los modelos de desarrollo en cascada hasta las ultimas metodologıas agiles, se ha
visto un crecimiento de las pruebas de software que terminan correspondiendo a un proceso
de control de cada una de las etapas del software para generar objetivos con mayor calidad
y confiabilidad frente a lo realizado. Las pruebas de software en el desarrollo de cualquier
tipo de aplicacion corresponde a un proceso fundamental en la produccion del mismo, por
ello al realizar una aplicacion movil se hacen necesarias para los resultados que requiere el
usuario final.
Para una aplicacion movil se intensifican la cantidad de pruebas por existir diferentes
dispositivos, sistemas operativos, dimensiones de pantalla, herramientas de los equipos, entre
otros; lo cual muestra que para realizar una aplicacion movil no se debe depender de una
sola tecnologıa sino debe ser adaptable. Dadas estas caracterısticas en el desarrollo de las
pruebas, puede definirse objetivos segun cada una de las etapas del proyecto donde se debe
tener en cuenta la tipologıa de pruebas.
Las pruebas garantizan el exito de la aplicacion debido a que la percepcion del usuario
final corresponde a las valoraciones positivas o negativas de la aplicacion, lo cual asegura
una respuesta asertiva del publico. Por ejemplo una aplicacion con suficientes calificaciones
positivas aseguran el aumento de descargas de la misma, resultando una bola de nieve de
descargas y calificaciones, como se puede ver en las siguientes ilustraciones se ve la relacion:
28 2 IMPORTANCIA DE LAS PRUEBAS EN APLICACIONES MOVILES
Ilustracion 2-1.: Play Store 25 de Enero 2017
Fuente: Play Store. Yu-Gi-Oh! Duel Links [18]
Ilustracion 2-2.: Play Store 10 de Febrero 2017
Fuente: Play Store. Yu-Gi-Oh! Duel Links [18]
29
Aunque no se puede afirmar que esta situacion suceda con todas las aplicaciones, otro
ejemplo claro de como las calificaciones positivas de una aplicacion puede resultar en un
aumento excesivo de descargas, como se muestra en la siguiente imagen se evidencia el au-
mento de la aplicacion WhatsApp en los ultimos anos.
Ilustracion 2-3.: Crecimiento exponencial de WhatsApp
Fuente: ¿Vale WhatsApp 14.000 millones? [19]
Es tanta la versatilidad y el uso de pruebas para esta aplicacion que se abrieron gru-
pos de pruebas Beta, es decir pruebas de limitados usuarios finales los cuales descargan la
aplicacion para validar su comportamiento antes de ser masificada a los demas usuarios.
Dichas pruebas se pueden realizar con tan solo permitir a Play Store la monitorizacion de
30 2 IMPORTANCIA DE LAS PRUEBAS EN APLICACIONES MOVILES
las acciones sobre la aplicacion y la descarga temprana de la aplicacion que estara disponible
tras la aceptacion de terminos y condiciones dictados por Play Store.
Ilustracion 2-4.: Version de pruebas WhatsApp
Fuente: WhatsApp Messenger [20]
El uso de pruebas funcionales generaran un resultado positivo en cuanto a lo que espera
el usuario de la aplicacion sin importar como se vea, dado que estas consisten en realizar el
analisis de errores susceptibles al usuario que se relacionen con la especificacion funcional y
los objetivos principales de la aplicacion.
Las pruebas de compatibilidad para dispositivos moviles corresponden al modulo de
pruebas mas largo debido a la cantidad de dispositivos con caracterısticas diferentes en las
cuales la aplicacion debe adaptarse. Los diferentes procesadores, dimensiones de pantalla,
accesos a componentes como acelerometros, camaras, memoria, entre otros, generan la ne-
cesidad de probar en al menos tres dispositivos con caracterısticas diferentes para dar la
fiabilidad de la aplicacion. Estas pruebas se vuelven tan importantes como las pruebas de
compatibilidad ya que si la aplicacion solo funciona en un tipo especıfico de dispositivo limita
el mercado para la aplicacion representando crıticas por el funcionamiento sesgado.
En cuanto a la correcta validacion entre las pruebas funcionalidad y las de compa-
tibilidad se llegan a realizar pruebas de rendimiento donde se ve una composicion de las
pruebas nombradas representando que el sistema puede soportar caracterısticas mınimas y
31
dar respuesta a las necesidades del desarrollador frente a los requerimientos mınimos y ajus-
tes posibles en la aplicacion. Con todo esto, se puede comprobar que una aplicacion con
mayor cantidad de pruebas y filtros antes de salir al publico junto con una muy buena idea,
representan el exito que se espera de la aplicacion.
3. IDENTIFICACION DE FALENCIAS
EN METODOLOGIAS EXISTENTES
Actualmente para el desarrollo de aplicaciones moviles se utilizan diferentes metodo-
logıas agiles, las cuales bajo el uso de desarrollos rapidos generan versionamientos rapidos
que incluyen mejoras de seguridad y adicion de modulos con nuevas funcionales con el fin de
tener una aplicacion activa en el mercado generando mayor expectativa en el usuario final,
el problema de ello es que aunque esten de moda y sea lo que mas se utilice contienen varias
falencias como las que se nombraran a continuacion.
Una de las mayores falencias de las metodologıas agiles es que todos los integrantes
del grupo de trabajo deben conocer de dicha metodologıa y estar dispuestos a cumplir con
los tiempos pactados para ello, desde que se disena hasta que se prueba. Este conocimiento
cooperativo genera dependencia dentro del proyecto por las curvas de aprendizaje, es decir
un nuevo integrante en un proyecto que use una metodologıa agil puede generar retrasos de
una o dos semanas segun el acople del nuevo integrante.
Los tiempos de retraso pueden representar la estabilidad de la plataforma, y si se tiene
en cuenta la metodologıa escogida se puede aumentar los riesgos en la plataforma por la
adaptacion de un nuevo integrante tanto en el equipo como con los vacıos funcionales frente
a la ejecucion de la misma. Por ejemplo en Scrum se necesita de tiempo en reuniones cortas
diarias y si existe un nuevo integrante puede que este no comprenda por completo dichas
reuniones por lo tanto la informacion estara dividida y comprendera vacıos frente al resto
33
del equipo. Un integrante del equipo sin el conocimiento de la aplicacion de la metodologıa
agil implica que se tendran demoras porque correspondera con una mala aplicacion de la
metodologıa.
Otra de las fallas detectadas corresponde a la falta de documentacion debido a que los
tiempos de documentacion y diseno son muy cortos frente a la cantidad de iteraciones y la
velocidad con la cual se genera cada una de las actualizaciones de la aplicacion. Ademas de
esto se debe tener en cuenta que el uso de una metodologıa agil implica la menor inclusion
posible de personal en el proyecto para limitar los desacuerdos, preguntas y retrasos.
Tambien se puede encontrar que en la etapa de pruebas, por las falencias descritas ante-
riormente, no se realiza una correcta identificacion de escenarios y tipos de pruebas a realizar
segun las etapas presentes dentro del proyecto, las pruebas no se encuentran estandarizadas
ya que dependen del analisis realizado por el analista.
4. MEJORAS ENFOCADAS EN
PRUEBAS PARA METODOLOGIAS
AGILES
Entre las mejoras posibles a realizar, teniendo en cuenta que no debe importar el tipo
de metodologıa agil que se escoja y que existen factores de acoplamiento mayores segun tipo
de metodologıa seleccionada, se encuentran las citadas a continuacion:
4.1. Complemento por Parte del Equipo de Pruebas
Aunque las metodologıas enfocadas en pruebas ya hacen uso de esto, se debe hacer un
enfasis en la inclusion de los analistas de calidad o pruebas dentro de todas las fases del
proyecto con el fin de dar otro punto de vista dentro de este. El acompanamiento continuo
del equipo de calidad generara una mayor cohesion dentro del proyecto por el grado de
pertenencia del equipo y el analisis colectivo durante el proceso de analisis y desarrollo. Con
esto se muestra que generacion de dudas tempranas y la contemplacion de casos de prueba
previos al desarrollo complementan el ciclo de vida de cada una de las iteraciones posibles.
4.2. Correlacion Entre Equipos y Pruebas por Ciclos
Cada uno de los stakeholders deben comprometerse dentro del proyecto debido a que
con el uso de diferentes perspectivas, la aclaracion de requerimientos y el sentido de per-
tenencia en el proyecto presentan mejoras de comunicacion en el equipo. La aplicacion de
4.2 Correlacion Entre Equipos y Pruebas por Ciclos 35
estas mejoras se puede presentar comenzando por la formacion de equipos de trabajo cola-
borativo entre ramas de especializacion, una vez conformados los equipos de requerimientos,
desarrollo y pruebas, se constituyen alianzas estrategicas entre los mismos.
El equipo de requerimientos tendra un acompanamiento constante del lıder de desarro-
llo para que este ayude a dimensionar los alcances de cada uno de las funcionalidades del
software solicitados y del lıder de pruebas para valorar la capacidad de respuesta del equipo,
debido a que no constituye lo mismo un requerimiento que corresponda un cambio de color
contra la inclusion de un nuevo modulo.
Una vez terminadas las primeras reuniones del analisis, la composicion de la docu-
mentacion debera complementarse con un analista de pruebas capacitado, el cual realizara
analisis adicionales sobre el requerimiento para la deteccion de vacıos o dudas previas a la
publicacion de la documentacion al desarrollador y la posterior entrega de la funcionalidad
desarrollada. Esto no solo traera complementos a la documentacion y desarrollo sino tambien
se complementara el proceso de pruebas al tener analisis de posibles escenarios de pruebas,
particularidades de la funcionalidad y posibles enfoques del equipo dando continuidad al
equipo en el proceso.
Con la deteccion de posibles escenarios, el desarrollador tendra un enfoque claro y un
complemento al analisis inicial dado en la documentacion como en cada una de las reuniones
de la metodologıa, podra realizar un bosquejo mas rapido a la entrega completa de la docu-
mentacion con la determinacion previa de los escenarios de prueba y con ello la realizacion de
pruebas previas para la deteccion de errores en los diferentes dispositivos por adaptabilidad
de los mismos.
El acompanamiento constante en pruebas al equipo de requerimientos complementa el
proceso documental y da cabida al analisis como usuario final, precisando y aclarando el
impacto que un cambio puede tener para dichos usuarios conllevando al analisis del mer-
36 4 MEJORAS ENFOCADAS EN PRUEBAS PARA METODOLOGIAS AGILES
cado, acaba con los tiempos muertos de pruebas mientras culmina el desarrollo dando un
nuevo punto de vista de los posibles escenarios o particularidades posibles en el desarrollo
de un futuro requerimiento completan el ciclo dando continuidad al equipo y haciendo de
este un sistema holıstico. Como complemento se pueden tener en cuenta que con analisis
adicionales de pruebas beta de la plataforma serviran encontrar incidentes previos a salidas
de produccion.
Ilustracion 4-1.: Trabajo en equipo y apoyo
Fuente: Los Autores
4.2 Correlacion Entre Equipos y Pruebas por Ciclos 37
La ventaja de la inclusion constante de los diferentes equipos es el cambio del enfoque
individual de las metodologıas agiles dentro de las cuales y en cada una de sus reuniones
implican un particionamiento del proceso a eventos individuales, todo esto impactara parte
de los equipos en el inicio del ciclo por implicar mas tiempos de discusion pero reduciran
notablemente los tiempos de respuesta esperados en una metodologıa agil por la claridad de
las funcionalidades requeridas.
Ilustracion 4-2.: Ciclos de pruebas
Fuente: Los Autores
38 4 MEJORAS ENFOCADAS EN PRUEBAS PARA METODOLOGIAS AGILES
El posible desconocimiento de los tipos de pruebas a utilizar en el desarrollo de una
aplicacion puede evitarse con el uso de filtros para conocer el tipo de pruebas a realizar, sin
importar el tipo de aplicacion (juegos, comunicacion, otros) los filtros presentados a conti-
nuacion corresponden a las pruebas basicas a tener en cuenta en el momento de la creacion
de una aplicacion movil.
Teniendo en cuenta que al utilizar metodologıas agiles se utilizan ciclos de desarrollo en
los cuales el ciclo inicial corresponde a un prototipo, solo se realizaran pruebas funcionales
con el fin de validar las funcionalidades esperadas en la version inicial. En los ciclos siguientes
se tienen en cuenta las pruebas de funcionalidad para validar nuevos desarrollos y las pruebas
no funcionales como compatibilidad con el fin de validar que los cambios realizados no se
vean afectados en los diferentes dispositivos, esto incluye pruebas en diferentes tamanos de
dispositivos, marcas, versiones de sistema operativo, entre otros.
Ilustracion 4-3.: Tablero de trabajo (Tipo Scrum)
Fuente: Trello.com - Proyecto: Los Autores
Para las ultimas etapas se tienen en cuenta pruebas unitarias las cuales corresponden
a las pruebas especıficas sobre los elementos afectados, pruebas no funcionales para validar
4.2 Correlacion Entre Equipos y Pruebas por Ciclos 39
que los cambios no representen cambios visuales o de rendimiento en diferente hardware y
adicionalmente pruebas de regresion para validar que los cambios realizados no afecten las
funcionalidades existentes.
Para conocer el estado de cada una de las funcionalidades o requerimientos se pueden
tener en cuenta herramientas como Trello en las cuales mediante la creacion de tarjetas se
pueden validar las tareas pendientes y adicionar comentarios por parte de todos los partici-
pantes del proceso.
Si no se tiene claridad de las pruebas a realizar, se pueden tener en cuenta las listas de
chequeo del anexo 1 con las cuales se puede determinar las pruebas a realizar incluyendo los
analisis a realizar cuando se apoya el proceso documental. Al encontrar un NO en cualquiera
de las listas de chequeo se debera entrar a analizar la correccion por el equipo correspondiente.
Dependiendo del tipo de aplicacion (Juegos, comunicacion, navegacion, productividad,
entre otros) se podran realizar mas tipos de pruebas como las listadas a continuacion con
las cuales se realizaran analisis mas profundos sobre el funcionamiento de la aplicacion.
Pruebas de acciones del usuario: comportamiento de la aplicacion ante distintas
acciones como tocar, arrastrar, rotar, extender los dedos, cerrar los dedos, etc.
Pruebas de usabilidad y accesibilidad: corresponden a la validacion de la Presen-
tacion de la informacion en el diseno de pagina para moviles, Facilidad para completar
tareas, Eficiencia y exactitud, y Integracion de aplicaciones nativas, aplicaciones web
movil e hıbridas.
Pruebas de localizacion: prueban el desempeno de la aplicacion cuando el dispositivo
movil esta en movimiento.
Pruebas de compatibilidad: Sirven para probar el desempeno de la aplicacion al
conectarse a las redes en distintos protocolos y distintas condiciones, por ejemplo:
Wi-Fi, Bluetooth, Red analogica (3G o 4G).
40 4 MEJORAS ENFOCADAS EN PRUEBAS PARA METODOLOGIAS AGILES
Pruebas de seguridad: Su finalidad busca validar la resistencia de la aplicacion a
ataques maliciosos, como por ejemplo: ataques vıa la red, ataques al servidor, ataques
al dispositivo, entre otros.
4.3. Procesos de Seleccion del Equipo de Trabajo
Dado que la aplicacion de una metodologıa agil implica que cada uno de los participantes
tenga el conocimiento de la misma, se recomienda que antes de comenzar un proyecto bajo
alguna metodologıa agil se realice un adecuado proceso de seleccion de los participantes para
ello deben tener en cuenta los siguientes parametros:
Conocimiento de la metodologıa agil a utilizar.
Conocimiento tecnico en el area a ejercer (requerimientos, desarrollo y pruebas).
Experiencia en el area a ejercer (requerimientos, desarrollo y pruebas).
Experiencia en trabajo en equipo.
Al ser un proceso de seleccion se deben realizar examenes para validar los conocimientos,
los cuales contribuiran a la categorizacion de los participantes. Los parametros correspon-
dientes a conocimiento nombrados se deben medir mediante porcentajes segun la siguiente
categorizacion.
4.4 Mejoras a Curvas de Aprendizaje 41
Ilustracion 4-4.: Niveles de seleccion del equipo de trabajo
Fuente: Los Autores
En cuanto a la experiencia sera cuantificable entre la cantidad de tiempo, tareas desem-
penadas y referencias entregadas por las personas referenciadas en la hoja de vida, ademas
de un analisis completo realizado en entrevistas.
Bajo las premisas anteriores, es ideal que los lıderes de las areas comprometidas tengan
un nivel alto cercano al 99 %, teniendo en cuenta que nunca se llega a un 100 % de conoci-
miento por las actualizaciones del mercado, con el fin de lograr una alta cohesion entre los
lıderes. Con respecto a los demas participantes del proyecto, se necesita como mınimo un
nivel medio de conocimiento debido a que es uno de los requerimientos mınimos para el uso
de las metodologıas agiles, ademas de una alta capacidad para el trabajo en equipo.
4.4. Mejoras a Curvas de Aprendizaje
Como cualquier proyecto no se pueden asegurar la continuidad del equipo, por lo tanto
se deben manejar protocolos de aseguramiento del conocimiento incluidos en cada uno de
los ciclos o semanas de desarrollo siendo por cada iteracion una nueva inclusion a una par-
ticularidad del proceso. A continuacion se presenta la propuesta de inclusion al equipo de
trabajo para integrantes nuevos en etapas avanzadas del proyecto.
42 4 MEJORAS ENFOCADAS EN PRUEBAS PARA METODOLOGIAS AGILES
Ilustracion 4-5.: Etapas de aprendizaje
Fuente: Los Autores
Ciclo uno: En la primera semana se espera que por interaccion de la aplicacion se com-
prendan comportamientos basicos y con el equipo comience la correcta relacion tanto laboral
como de relacion con el equipo, con esta relacion establecida se fortalecera el equipo y hara
mas sencilla la generacion de dudas.
Ciclo dos: Tras intentar realizar un acercamiento intuitivo a la aplicacion, se podra com-
pletar el conocimiento junto con la lectura del funcionamiento de la aplicacion. Con el fin de
no malgastar el tiempo de los participantes del proyecto se espera que las dudas presentadas
en el ciclo se resuelvan inmediatamente.
Ciclo tres: Tras tener el conocimiento basico de la aplicacion, podra ingresar a las reunio-
nes de seguimiento para conocer el futuro de la aplicacion, ademas de esto se asignaran tareas
basicas para comenzar la alineacion dentro del equipo(Analista de requerimientos: analisis
funcional inicial complementado por el analista lıder, Analista de pruebas: analisis de crea-
cion de casos de prueba y ejecucion de casos de prueba sencillos, Analista de desarrollo:
inclusion en desarrollos pequenos y adaptacion de otros desarrollos, documentacion de codi-
go por la comprension (lectura) del mismo.
Ciclo cuatro: Corresponde a la ultima semana de acople al equipo dentro de esta ya
se realizara la asignacion normal como a cualquier miembro del equipo, podra participar
activamente de las reuniones y dar puntos de vista.
Lo anterior se considera con el fin de tener en cuenta que al ingresar un nuevo inte-
4.4 Mejoras a Curvas de Aprendizaje 43
grante al equipo, sin importar la tarea a realizar, hay curvas de aprendizaje las cuales en
los proyectos avanzados implican desgaste del tiempo de los demas integrantes por tiempos
en capacitaciones, resolucion de preguntas, acoplamiento al equipo, entre otros. La solucion
a esto se plantea bajo el uso de etapas de inclusion de las personas al equipo en el menor
tiempo posible y sincronizadamente con los ciclos de desarrollo de la aplicacion, teniendo
en cuenta que dicha inclusion aplica cuando ya se tienen equipos consolidados que traba-
jan sobre la aplicacion y el nuevo integrante cumple con los requisitos del perfil bajo las
calificaciones dadas en el anterior numeral. Bajo esto se considera que el nuevo integrante
tendra la capacidad de asumir responsablemente el aprendizaje por intuicion y asociacion
dando oportunidad a explorar requerimientos funcionales, identificando pequenos errores que
al ser persistentes los analistas con mas tiempo en el proyecto se omiten, y no funcionales
del software, como la usabilidad o eficiencia, demostrando como un posible usuario final se
entenderıa con la aplicacion.
5. VENTAJAS DEL USO DE LAS
MEJORAS PRESENTADAS
Las ventajas actuales del uso de una metodologıa agil implican la satisfaccion del clien-
te al verse involucrado a lo largo del proyecto, el conocimiento del estado del proyecto por
todos los miembros del equipo y evidencias de la eficiencia por implicar un menor intervalo
de tiempo en una version funcional del producto. Con el uso de las mejoras descritas ante-
riormente se lograran cambios aun mas significativos en el momento de la creacion de una
aplicacion movil.
La eficiencia inherente en el uso de una metodologıa agil se ve mejorada con el uso
del plan descrito, evidenciando un alto nivel de cohesion en el equipo con el cual las tareas
se veran mejor equilibradas, para lo cual se realizara una distribucion de las tareas en una
mayor cantidad de personas en el equipo con diferentes enfoques, limitando ası la aparicion
de espacios sin productividad y eventuales problemas en el desarrollo los cuales incluyen
tiempos muertos y contradicciones por vacıos funcionales.
Al evitar tiempos muertos la aplicacion se tendra lista en menor tiempo por lo cual el
cliente se encontrara mas satisfecho y este al estar incluido en cada uno de los ciclos encon-
trara a satisfaccion el producto final entregado.
El uso de las listas de chequeo del anexo “Analisis documental” simplificara las tareas
de analisis del equipo de pruebas en cuanto al proceso de apoyo documental y junto con el
45
anexo “analisis para deteccion y reporte de errores” el cual apoyara tanto la deteccion de
errores como permitira a los integrantes del equipo de pruebas generar la mayor cantidad
de insumos para el equipo de desarrollo y simplificar las tareas del mismo. Adicionalmente
intenta ayudar el equipo de desarrollo al entregar la mayor cantidad de informacion posible
de los errores. Con el uso de herramientas de reporte de errores como Bugzilla o Mantis
(Open Source) se puede visualizar la aplicacion de las mejoras planteadas como por ejemplo
la ilustracion 5-1 la cual corresponde a un formulario de reporte de errores.
Ilustracion 5-1.: Reporte de errores
Fuente: MantisHub - Proyecto: Los Autores
46 5 VENTAJAS DEL USO DE LAS MEJORAS PRESENTADAS
Con el uso de estas herramientas se pueden simplificar el reporte de errores y con ello
hacer mas simple para el desarrollador la solucion de este, adicionalmente se tiene la traza-
bilidad del error al tener asignada la persona la cual se encuentra solucionando el error o el
vacıo funcional.
En cuanto a la mejora de la comunicacion entre todos los equipos se tienen herramien-
tas de trabajo como Bitrix24 dentro de las cuales se puede llevar el control del estado del
proyecto, la asignacion de tareas, el reporte de las tareas realizadas por persona, creacion de
canales de comunicacion, entre otras, y con el uso de estas tener un mayor control y enfoque
de las tareas.
Ilustracion 5-2.: Asignador de tareas
Fuente: Bitrix24 - Proyecto: Los Autores
Con la asignacion de tareas tambien se puede llevar el control de la curva de aprendizaje
de los nuevos integrantes ası como el registro de los indicadores del estado del proyecto.
6. ANALISIS MATEMATICO DE LA
IMPLEMENTACION DE LAS
MEJORAS
Si se tiene en cuenta esto las pruebas realizadas a una funcionalidad pueden verse
desenfocadas porque al no existir informacion concreta y documentada las pruebas seran
dependientes de la interpretacion del analista mas no dependientes de la verdadera funcio-
nalidad del modulo, en pocas palabras se plantea la siguiente ecuacion:
E ≈ D∗VR
Donde R corresponde a la cantidad de requerimientos o funcionalidades que se entrega-
ran en la version de la aplicacion, D corresponde al porcentaje de documentacion entregado,
V corresponde a la cantidad de vacıos o preguntas documentales y la E son los posibles
defectos encontrados en la ejecucion por el analista. Esto quiere decir que existe mayor po-
sibilidad de defectos si se entrega menor cantidad de documentacion porque existiran mayor
cantidad de preguntas para una menor cantidad de requerimientos.
48 6 ANALISIS MATEMATICO DE LA IMPLEMENTACION DE LAS MEJORAS
Ilustracion 6-1.: Documentacion Vs Vacıos funcionales
Fuente: Los Autores
Teniendo en cuenta que como nombra la ISQTB “un error introduce un defecto y un
defecto causa un fallo” la ecuacion anterior solo es la prueba de la importancia en la calidad
con la que se realizan los analisis tanto en el proceso documental como en los demas procesos
del ciclo de vida del software.
Parte III.
CIERRE DE LA INVESTIGACION
7. CONCLUSIONES
7.1. Verificacion, Contraste y Evaluacion de los Objetivos
7.1.1. Verificacion
La aplicacion de los objetivos planteados demuestra que el uso de listas de chequeo com-
plementa el proceso de identificacion de error y simplifican la tarea del equipo de pruebas en
especial de los nuevos integrantes del equipo agrupando y clasificando los hallazgos segun su
tipologıa, que junto con el proceso de curva de aprendizaje conlleva a plantear nuevas ideas
para lograr una mejor transicion de ingreso al equipo en un corto plazo de tiempo.
Es posible verificar que la constante interaccion entre los equipos de requerimientos
y pruebas genera una notable disminucion de reporte de vacıos o inquietudes funcionales,
ademas del acompanamiento en el proceso de afinamiento de los insumos del desarrollo,
entregando la documentacion completa de la plataforma, por lo cual se evidencia una re-
duccion en costos de los recursos del proyecto, disminuye la cantidad de desarrollos erroneos
inherentes a fallas en la especificacion de soluciones y de manera paralela la revalidacion de
los errores. Tambien impacta de manera positiva al proyecto la interrelacion constante del
equipo de pruebas con el equipo de desarrollo debido a que ayuda a la resolucion oportuna
de los errores o ajustes no planeados.
52 7 CONCLUSIONES
7.1.2. Contraste
Dado el manejo que se le otorga a la documentacion dentro de las metodologıas agiles y
aunque va en contra de sus principales postulados, es posible denotar que la documentacion
se convirtio en punto focal para identificar los errores, definir claramente el funcionamiento
correcto de la aplicacion y su dedicacion. La documentacion clara y tipificada de los errores
genera organizacion y sinergia dentro de los procesos del proyecto y evidencia dentro del
balance final del proceso el impacto positivo en el costo de cada etapa.
7.1.3. Evaluacion
Los objetivos propuestos se cumplieron gracias a la creacion de los nuevos procesos y
plantillas, con los cuales fue posible facilitar dentro del equipo de trabajo la socializacion de
errores, brindando el apoyo constante por parte del equipo de pruebas a todos los stakehol-
ders. Con esto poder demostrar que el desarrollo agil de aplicaciones moviles que posean
un proceso mas claro, que en lo posible genere la mınima cantidad de iteraciones gracias a
los ajustes en documentacion, genera un equipo de trabajo acoplado que interactua en un
estado dinamico, es decir, como un sistema, a su vez lograr una robusta clasificacion de las
tareas, se evidenciara la sinergia del equipo.
7.2. Sıntesis del Modelo Propuesto
El objetivo principal de este trabajo de grado es la propuesta de un plan de recomen-
daciones para la optimizacion y mejora continua de una metodologıa agil con enfasis en
pruebas, esta basado principalmente en el uso de listas de chequeo y se apoya en su meto-
dologıa practica que genera cohesion con el analista de pruebas, lo cual aprovecha aun mas
sus capacidades beneficiando el proceso completo. Los proyectos hoy en dıa estan limitados
en el enfoque del set de pruebas a ejecutar, generando con esto deficiencias notables en los
entregables de cada fase del ciclo de vida del software y evidenciando retrasos y extra costos
muy comunes en la industria del desarrollo de aplicaciones moviles, tambien provocan re-
procesos, dependencias y perdidas de conocimiento dentro de los recursos del personal del
7.2 Sıntesis del Modelo Propuesto 53
proyecto dada la baja documentacion y fallas en los procesos ejecutados sobre cada equipo
de trabajo que interviene en la construccion del software final.
Los interrogantes para la investigacion que surgen para proponer el Plan de recomenda-
ciones, se refieren al analisis del ciclo de vida del software, y posterior estudio de la eficiencia
del proceso y la rentabilidad/esfuerzo, a efectos de identificar los factores crıticos de exito,
como tambien la experiencia que entrega la industrias. De la percepcion del analista de prue-
bas y en general los demas stakeholders del proyecto que trabajan con ellos, se definiran las
condiciones a considerar para la implementacion o mejora del Plan propuesto.
Este trabajo de grado se ha desarrollado de acuerdo a las pautas de la investigacion
exploratoria, y, por tanto, es de tipo cualitativa. La principal fuente de informacion primaria
son la experiencia recogida dentro del mercado y las entrevistas a analistas de pruebas con
trayectoria en el mercado de desarrollo de aplicaciones moviles, ingenieros de sistemas con
roles funcionales y de lıderes tecnicos, gerentes, y los conocimientos adquiridos por observa-
cion, principalmente de la manera de pensar del analista de pruebas, quien conoce el trabajo
diario, su impacto y los reprocesos comunes que la metodologıa tradicional obliga y no es
flexible. Ası mismo, se realizaron validaciones del modelo sobre productos del mercado de
aplicaciones moviles y en general sobre el comportamiento del ciclo de vida del software,
respetando las caracterısticas intrınsecas del sistema actual y los beneficios atractivos para
las necesidades de un nicho de mercado creciente e importante en la actualidad. Su verifica-
cion estuvo respaldada por la ejecucion de pruebas de forma escalonada teniendo en cuenta
la estabilidad de la aplicacion, mediante la prueba de concepto del producto, sostenida en
base al conocimiento de expertos de mercado y demanda del proyecto. El proyecto debe
estar pendiente de validar los conocimientos de los integrantes del equipo, nuevos o antiguos,
con el objetivo de generar equipos de trabajo solidos, directamente impactando de manera
positiva al proyecto y asegurando el proceso de aprendizaje para nuevos integrantes con los
procesos establecidos.
54 7 CONCLUSIONES
Finalmente, el presente proyecto sugiere considerar la implementacion del Plan de reco-
mendaciones, como base para que se planteen futuras investigaciones respecto de los factores
crıticos de exito: forma de asociatividad y cohesion entre los stakeholders del proyecto, de-
bera dirigirse a metodologıas de cualquier tipo y con inclusion de nuevos equipos dentro de
las etapas de desarrollo del software.
7.3. Aportes Originales
Dentro de los aportes que se plantean y ejecutan, se aporta las listas de chequeo enfo-
cadas e influenciando directamente el mejoramiento de las curvas de aprendizaje, debido a
que normalmente las empresas no tienen en cuenta estos procesos los cuales pueden incurrir
en disminucion del trabajo para los integrantes del equipo que entran a apoyar el proceso
de capacitacion y socializacion del conocimiento, disminuyendo las tareas en la asignacion
de los antiguos integrantes del equipo ya que se deben nivelar las actividades y entre ellas
adicionar los apoyos prestados para las explicaciones. Por ello se convierte en un aporte ori-
ginal e importante para el proyecto teniendo en cuenta que la curva de aprendizaje como se
plantea en lo expuesto contempla un aprendizaje por intuicion, asociacion y profundizacion,
en ese orden generando un impacto positivo en todo el equipo de trabajo.
8. PROSPECTIVA DEL TRABAJO DE
GRADO
8.1. Lıneas de Investigacion Futura
Las mejoras propuestas estan dirigidas a metodologıas agiles enfocadas en ciclos, para
futuras investigaciones puede dirigirse a metodologıas de cualquier tipo y con inclusion de
nuevos equipos dentro de las etapas de desarrollo del software.
8.2. Trabajos de Investigacion Futuros
Como trabajos futuros de investigacion se proponen los siguientes:
Aplicacion de las mejoras a otros tipos de metodologıas
Inclusion de nuevos equipos colaboradores en el desarrollo con determinacion de listas
de chequeo para su comportamiento holıstico.
Replanteamiento de las metodologıas agiles basados en el manifiesto agil pero contem-
plando los tiempos y necesidades de los clientes actuales.
Crear una herramienta tecnologica para la deteccion de errores basado en listas de
chequeo
Crear una herramienta tecnologica para soporte a las curvas de aprendizaje en el
desarrollo agil.
BIBLIOGRAFIA Y REFERENCIAS WEB
[1] I. Sommerville. Ingenierıa del software, 2010.
[2] A. Navarro, J. Fernandez, and J. Morales. Revision de metodologıas agiles para el
desarrollo de software., 2013.
[3] S. Ghosh. Systemic comparison of the application of evm in traditional and agile softwa-
re project. urlhttp://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-ES.pdf.
[4] Why scrum? why agile development? urlhttp://calvinx.com/2014/05/22/why-scrum-
why-agile-development.
[5] Mobile-d. urlhttp://agile.vtt.fi/mobiled.html.
[6] Metodos aplicables para el desarrollo de aplicaciones moviles.
urlhttp://www.genbetadev.com/desarrollo-aplicaciones-moviles/metodos-aplicables-
para-el-desarrollo-de-aplicaciones-moviles.
[7] Kristine. Test driven development and agile. urlhttp://www.boost.co.nz/blog/2012/05/test-
driven-development-and-agile/, 2012.
[8] A. Nosseir, D. Flood, R. Harrison, and O. Ibrahim. Mobile development process spiral,
2012.
[9] Tema: Ingenierıa de software i modelos de desarrollo: espiral.
urlhttp://www.aprenderaprogramar.com/foros/index.php?topic=2144.0/.
58 BIBLIOGRAFIA Y REFERENCIAS WEB
[10] J. Blanco, J. Camarero, A. Fumero, A. Werterski, and P. Rodriguez. Me-
todologıa de desarrollo agil para sistemas moviles introduccion al desa-
rrollo con android y el iphone. urlhttp://www.adamwesterski.com/wp-
content/files/docsCursosAgile doc TemasAnv.pdf.
[11] Tipos de pruebas de software. urlhttp://ing-sw.blogspot.com.co/2005/04/tipos-de-
pruebas-de-software.html.
[12] D. Avison and G. Fitzgerald. Information system development., 2006.
[13] Instituto de Ingenieros Electricos y Electronicos. (IEEE Computer Dictionary. Soft-
ware Engineering Terms. 1990). Ieee 610-1990. urlhttp://web.fi.uba.ar/˜cfonte-
la/Fontela EstadoDelArteTDD UNLP EIS.pdf, 1990.
[14] Introduccion a la teorıa general de sistemas, 2004.
[15] O. Johansen Bertoglio. Capıtulo 3. iagp 2005/06. metodologıas usadas en ingenierıa del
software. urlhttp://www.um.es/docencia/barzana/IAGP/Iagp3.html, 2005.
[16] C. Fontanela. Trabajo final de especializacion en ingenierıa de software estado
del arte y tendencias en test-driven development. urlhttp://web.fi.uba.ar/˜cfonte-
la/Fontela EstadoDelArteTDD UNLP EIS.pdf, 2011.
[17] K. Beck, M. Beedle, A. Bennekum, A. Cockburn, W. Cunningham, M. Fowler,
J. Grenning, J. Highsmith, A. Hunt, R. Jeffries, J. Kern, B. Marick, R. Mar-
tin, S. Mellor, K. Schwaber, J. Sutherland, and D. Thomas. Manifiesto agil.
urlhttp://www.agilemanifesto.org.
[18] Play store. yu-gi-oh! duel links. urlhttps://play.google.com/store/apps/details?id=jp.konami
.duellinks&hl=es.
[19] ¿vale whatsapp 14.000 millones? urlhttp://economia.elpais.com/economia/2014/02/20/
actualidad/1392907095 894321.html.
[20] Whatsapp messenger. urlhttps://play.google.com/apps/testing/com.whatsapp.
BIBLIOGRAFIA Y REFERENCIAS WEB 59
[21] Metodologıasagiles en el desarrollo de aplicaciones para dispositivos movi-
les. Estado actual. urlhttp://www.uelbosque.edu.co/sites/default/files /publicacio-
nes/revistas/revista tecnologia/volumen12 numero2 /12Articulo Rev-Tec-Num-2.pdf
[22] Garrido Cordoba, J. TFC Desarrollo de aplicaciones moviles.
urlhttp://openaccess.uoc.edu/webapps/o2/bitstream/ 10609/18528/6/ jugarrido-
coTFC0113memoria.pdf, 2013
[23] Gasca, M. AND Camargo, L AND Medina, B. Metodologıa para el desarrollo de apli-
caciones moviles. urlhttp://www.scielo.org.co/pdf/tecn/v18n40/v18n40a03.pdf, 2013
[24] ISO/IEC/IEEE 29119 Software Testing Standard. urlhttp://in2test.lsi.uniovi.es/gt26
/#presentacion, 2015
[25] Pruebas Unitarias para Haskell. urlhttp://osl2.uca.es/wikihaskell/index.php/ Prue-
bas Unitarias para Haskell, 2015
[26] End user Definition. urlhttp://techterms.com/definition/enduser
[27] La importancia de las pruebas en dispositivos moviles.
urlhttps://www.globetesting.com/2012/08/pruebas-en- dispositivos-mviles/, 2012
[28] Que son las metodologıasagiles y su aplicacion en el mercado actual.
urlhttp://www.uv.es/capgeminiuv/documents/Capgemini Charla Agile UV.pdf,
2016
Parte IV.
ANEXOS
.1 Anexo: Analisis Documental 63
.1. Anexo: Analisis Documental
La tabla a continuacion presenta los elementos basicos para la validacion de la docu-
mentacion
SI NO Observaciones
1. Se encuentra clara la funcionalidad descrita
2. Se describen los elementos afectados con los
cambios
3. Describe el alcance de la funcionalidad
4. Contiene el objetivo de la funcionalidad
5. Se presentan los mockups de la interfaz
6. Encontro inconsistencias en el documento
64
.2. Anexo: Analisis Para Deteccion y Reporte Errores
Teniendo en cuenta que para la identificacion de los errores se debe realizar segun la
categorıa del error acontinuacion se exponen las tablas de principal uso para el equipo de
pruebas.
.2.1. Identificacion de un Error
La siguiente tabla tiene como objetivo entregar la mayor cantidad de informacion posible
al equipo de desarrollo
SI NO Observaciones
1. El error bloquea el flujo
de la funcionalidad
2. El error cambia la interfaz
grafica definida inicialmente
Si la respuesta es Si se debe a un cambio
en los componentes o frente a la compati-
bilidad de los equipos
3. El error depende del dis-
positivo en el cual se realiza
la prueba
Si la respuesta es Si se debe a un error de
compatibilidad del equipo, por la pantalla
o por temas de rendimiento del equipo
4. El error corresponde a
un comportamiento no re-
producible facilmente
Si la respuesta es Si puede analizarse co-
mo cache, respuesta de memoria, rendi-
miento, o funcionalidades compuestas no
contempladas
5. El error corresponde a
un comportamiento no do-
cumentado
De ser ası debe reportarse el vacıo docu-
mental al equipo de requerimientos con el
fin de evitar esfuerzos al equipo de desa-
rrollo
Las siguientes tablas tienen como objetivo entregar la mayor cantidad de informacion
posible al equipo de desarrollo segun el tipo o categorıa del error.
.2 Anexo: Analisis Para Deteccion y Reporte Errores 65
Categorıa: Funcional
SI NO Observaciones
1. El comportamiento corresponde con lo defi-
nido documentalmente
2. Permite realizar el flujo completo de la fun-
cionalidad
3. Se puede realizar configuraciones de la fun-
cionalidad desde otra funcionalidad
Si la respuesta es Si con-
testar los numerales deri-
vados
3.1 Permite realizar la configuracion previa
3.2 La configuracion realizada se encuentra apli-
cada correctamente sobre la funcionalidad prin-
cipal
3.3 Al eliminar la configuracion previa se per-
mite el flujo normal de la funcionalidad
Categorıa: Compatibilidad
SI NO Observaciones
1. La aplicacion se adapta al tamano de la pan-
talla
2. La aplicacion se adapta a la orientacion de la
aplicacion
3. La aplicacion permite el despliegue del tecla-
do sin danar la distribucion de los componentes
de la interfaz
4. Se permite el acceso a la aplicacion y su na-
vegacion en diferentes versiones de sistema ope-
rativo
66
Categorıa: Rendimiento
SI NO Observaciones
1. Se puede realizar la navegacion correctamente
sobre un dispositivo de gama baja
2. Se puede realizar la navegacion correctamente
sobre un dispositivo de gama media
3. Se puede realizar la navegacion correctamente
sobre un dispositivo de gama alta
4. Permite el ingreso de llamadas, visualizacion
de notificaciones sin afectar la navegacion
5. Permite realizar la navegacion sobre la apli-
cacion mientras se encuentren en uso otras apli-
caciones
6. Permite la navegacion en la aplicacion con
baja capacidad de memoria
7. Permite la navegacion en la aplicacion para
versiones de sistema operativo antiguas
.2 Anexo: Analisis Para Deteccion y Reporte Errores 67
.2.2. Elementos para el reporte de errores
Corresponde a los elementos mınimos a entregar al equipo de desarrollo.
SI NO Observaciones
1. Contiene el resumen completo del error
2. Se describen los pasos completos para la re-
produccion del error
3. Se adjuntan los registros generados por la
aplicacion(trazabilidad de los mensajes servidor
aplicacion, bitacora de acciones, etc.)
Registros no visibles de
cara al usuario
4. Se ajuntan las pantallas correspondientes al
error y son congruentes con los pasos del error