UNIVERSIDAD MAYOR DE SAN SIMÓN

FACULTAD DE CIENCIAS Y TECNOLOGÍA

DIRECCIÓN DE POSTGRADO

HERRAMIENTAS PARA AUTOMATIZAR

EL PROCESO DE CONTROL DE CALIDAD

TRABAJO FINAL PRESENTADO PARA OBTENER EL

CERTIFICADO DE DIPLOMADO EXPERTO EN DESARROLLO DE
APLICACIONES EMPRESARIALES VERSIÓN I

POSTULANTE : IVER EDUARDO MAMANI APE

TUTOR : MSc. VALENTIN LAIME ZAPATA

Cochabamba - Bolivia
2018
 Agradecimientos
A mis padres, por su ayuda y la paciencia que han tenido conmigo.
A mis hermanos por estar siempre ahí cuando los necesitaba.
A mi universidad por brindarme oportunidades para desarrollarme a nivel profesional.
Y a mí tutor que siempre estaré agradecido por el tiempo y los consejos que me brindo.

2
ÍNDICE DE CONTENIDO
ÍNDICE DE FIGURAS................................................................................................................... 4
ÍNDICE DE TABLAS .................................................................................................................... 5
1. RESUMEN ......................................................................................................................... 6
INTRODUCCIÓN ........................................................................................................................ 7
2. ANTECEDENTES ................................................................................................................. 7
3. DEFINICIÓN DEL PROBLEMA .............................................................................................. 7
4. OBJETIVO GENERAL ........................................................................................................... 7
4.1 OBJETIVOS ESPECÍFICOS .....................................................................................................7
5. ALCANCE ........................................................................................................................... 8
6. JUSTIFICACIÓN .................................................................................................................. 8
7. CALIDAD DE SOFTWARE .................................................................................................... 9
7.1 COSTO DE LA CALIDAD .....................................................................................................10
8.2 ¿CÓMO ALCANZAR LA CALIDAD? ......................................................................................12
8. TEST DE SOFTWARE ......................................................................................................... 13
8.1 AMBIENTE DE TEST ...........................................................................................................17
9. BIENVENIDO A LA ERA DE LA AUTOMATIZACIÓN .............................................................. 22
9.1 PRINCIPIOS DE LA AUTOMATIZACIÓN ..............................................................................23
9.2 AUTOMATIZACIÓN TEST ...................................................................................................23
9.3 TESTS MANUALES POR TESTS AUTOMATIZADOS .............................................................23
9.4 CUESTIONES ACERCA DE LA AUTOMATIZACIÓN...............................................................24
10. DIFERENCIA ENTRE PRUEBAS FUNCIONALES, PRUEBAS NO FUNCIONALES .................... 24
11. HERRAMIENTAS DE AUTOMATIZACIÓN PÁRA EL PROCESO DE CONTROL DE CALIDAD ... 25
11.1 HERRAMIENTAS DE PRUEBA UNITARIA ............................................................................25
11.2 HERRAMIENTAS DE PRUEBA FUNCIONAL .........................................................................31
11.3 HERRAMIENTAS DE PRUEBAS DE RENDIMIENTO .............................................................36
11.4 HERRAMIENTAS DE SEGUIMIENTOS DE BUGS ..................................................................39
12. CONCLUSIONES ........................................................................................................... 43
13. BIBLIOGRAFÍA.............................................................................................................. 44

3
ÍNDICE DE FIGURAS

Figura 1. Costo relativo a corregir un error ..................................................................... 12

Figura 2. Test de caja blanca ......................................................................................... 14
Figura 3. Test de caja negra .......................................................................................... 14
Figura 4. Concepto V test de software ........................................................................... 15
Figura 5. Modelo de ciclo de vida de los tests ................................................................ 16
Figura 6. Estrategia de test ............................................................................................ 20
Figura 7 Logo de JUnit .................................................................................................. 27
Figura 8 Logo de NUnit ................................................................................................. 28
Figura 9 Logo de TestNG .............................................................................................. 29
Figura 10 Logo de Selenium IDE ................................................................................... 32
Figura 11 Logo Selenium Remote Control...................................................................... 32
Figura 12 Logo de Selenium WebDriver......................................................................... 33
Figura 13 Logo de Selenium Grid .................................................................................. 33
Figura 14 Logo de Canoo WebTest ............................................................................... 34
Figura 15 Logo de Cucumber ........................................................................................ 34
Figura 16 Logo de HP UFT ............................................................................................ 35
Figura 18 Logo de WebLOAD ........................................................................................ 38
Figura 19 Logo de Bugzilla ............................................................................................ 39

4
ÍNDICE DE TABLAS

Tabla 1. Descripción de los profesionales que componen el equipo de test .................... 17

Tabla 2 Anotaciones de JUnit ........................................................................................ 27
Tabla 3 Atributos de NUnit ............................................................................................. 29
Tabla 4 Anotaciones de TestNG .................................................................................... 30
Tabla 5 herramientas de Test unitario ........................................................................... 30
Tabla 6 Herramientas de Prueba Funcional ................................................................... 36
Tabla 7 Herramientas de Test de rendimiento ................................................................ 39
Tabla 8 Herramientas de Seguimiento de Bugs.............................................................. 42

5
 1. RESUMEN

Esta monografía describe la importancia de la realización de pruebas de calidad dentro el

ciclo de vida de un producto de software y como la automatización de estas pruebas
mejoran notablemente tanto para los usuarios como para los productos resultantes.
También se mostrará las herramientas más relevantes para la automatización.

6
INTRODUCCIÓN

2. ANTECEDENTES

Actualmente en Bolivia existe una creciente demanda de exportación de productos de

software. Este hecho representa una gran oportunidad y a la vez un desafío debido a que
nuestro país posee importantes capacidades para desarrollar software a medida.
Para conseguir y asegurar mercados internacionales es necesario desarrollar productos
de calidad, es decir desarrollar el producto que el cliente o mercado desea, con el
conocimiento bien difundido, hoy tenemos a disposición diversas herramientas de
automatización open sources, con los cuales es posible crear scripts de tests eficientes
que validan las funcionalidades del sistema tantas veces como sea necesario de forma
automática.

3. DEFINICIÓN DEL PROBLEMA

¿Por qué se escogió este tema?, en la era de la Ingeniería de Software existe muchas
empresas que se dedican al desarrollo de software a nivel nacional y en Bolivia se
desarrolla productos de la talla mundial.
Se forma una pregunta ¿Cómo desarrollar un producto de software de calidad?

4. OBJETIVO GENERAL

El objetivo principal de la monografía es realizar un estudio de las herramientas de

automatización para el proceso de control de calidad.

4.1 OBJETIVOS ESPECÍFICOS

 Comprender la importancia de realizar pruebas de software si se quiere alcanzar

un producto final que sea de calidad.
 Conocer cuales, son las diferencias entre las pruebas funcionales y no
funcionales.
 Conocer las herramientas de automatización más relevantes.

7
 5. ALCANCE

La presente monografía mostrará herramientas de automatización para el control de

calidad de software, y entender la importancia de estas herramientas para el desarrollo de
software de calidad.

6. JUSTIFICACIÓN

La evolución de la industria del software, en nuestro país y en el mundo, demanda

profesional altamente capacitados para desempeñarse apropiadamente en procesos de
desarrollo de software, el propósito de esta monografía es el de realizar un estudio de las
herramientas de control de calidad, desarrollando un cuadro comparativo de las
herramientas para un mejor entendimiento de las mismas.

8
 7. CALIDAD DE SOFTWARE

Es una actividad esencial en cualquier empresa de software para asegurar la calidad de

sus productos, la competitividad frente a la oferta del mercado.
Según en un nivel pragmático, David Garvin de Harvard Business School sugiere que la
calidad es un concepto complejo y de facetas múltiples que puede describirse en 5
diferentes puntos de vista que veremos a continuación:

 Visión transversal: Sostiene que la calidad es algo que se reconoce de

inmediato, pero que no es posible definir explícitamente.

 Visión del usuario: La calidad en términos de las metas específicas del usuario
final, si un producto las satisface, tiene calidad.

 Visión del fabricante: Se define en términos de las especificaciones originales del

producto. Si este las cumple tiene calidad.

 Visión del producto: Sugiere que la calidad tiene que ver con las características
inherentes (funciones y características) de un producto.

 Visión del valor: se mide de acuerdo con lo que un cliente está dispuesto a pagar
por un producto.

Factores de calidad

Los factores de calidad que contempla ISO/IEC 9126 no son necesariamente usados para
mediciones directas, pero proveen una valiosa base para medidas indirectas y una
excelente lista para determinar la calidad de un sistema.

La ISO/IEC 9126 fue desarrollado en un intento de identificar los atributos clave de calidad
de software, esta norma nos indica las características de la calidad y los alineamientos
para su uso. El estándar identifica 6 atributos clave de calidad:

 Funcionalidad: el grado en que el software satisface las necesidades indicadas

por los siguientes suba tributos:

o Adaptabilidad.
o Corrección.
o Interoperabilidad.
o Conformidad.
o Seguridad.

9
  Confiabilidad: cantidad de tiempo que el software está disponible para su uso.
Está referido por los siguientes suba tributos:

o Madurez,
o Tolerancia a fallos.
o Facilidad de recuperación.

 Usabilidad: grado en que el software es fácil de usar. Viene reflejado por los
siguientes suba tributos:

o Facilidad de comprensión.
o Facilidad de aprendizaje.
o Operatividad.

 Eficiencia: grado en que el software hace óptimo el uso de los recursos del
sistema. Está indicado por los siguientes suba tributos:

o Tiempo de uso.
o Recursos utilizados.

 Facilidad de mantenimiento: la facilidad con que una modificación puede ser

realizada. Está indicada por los siguientes suba tributos:

o Facilidad de análisis.
o Facilidad de cambio.
o Estabilidad.
o Facilidad de prueba.

 Portabilidad: la facilidad con que el software puede ser llevado de un entorno a

otro. Está referido por los siguientes suba tributos:

o Facilidad de instalación.
o Facilidad de ajuste.
o Facilidad de adaptación al cambio.

7.1 COSTO DE LA CALIDAD

Costo de la calidad engloba todos los costos involucrados en la búsqueda de la calidad.

Se realizan estudios sobre el costo de calidad para proporcionar una línea base del costo
actual de calidad, para identificar oportunidades de reducir este costo, y proporcionar una
base normalizada de comparación. La base de normalización siempre tiene un precio.

10
Una vez que se han normalizado los costos de calidad sobre un precio base, tenemos los
datos necesarios para evaluar el lugar en donde hay oportunidades de mejorar nuestros
procesos.
Es más, podemos evaluar como los cambios en términos de dinero. Los costos de calidad
engloban todos los costos involucrados en la búsqueda, y se clasifican en:
Costo de prevención:
Incluye el costo de las actividades de gestión necesarias para planificar y coordinar todas
las actividades de control y garantía de calidad. El costo de actividades técnicas
adicionales para desarrollar modelos completos de requisitos y diseño. Costos de
planificación de tests y el costo de todo el entrenamiento asociado a esas actividades.

Costo de evaluación:
Incluyen actividades para la comprensión de profundidad de la condición del producto.
Entre los ejemplos de costos de evaluación tenemos:
 Costo para la realización de revisiones técnicas para productos resultantes de
Ingeniería de Software.
 Costo para la recolección de datos y la evaluación de métricas.
 Costo de test y depuración.

Costo de fallas:
Son aquellos que no existirían si ningún error hubiera surgido antes o después de la
entrega de un producto a clientes. Estos costos se pueden subdividir en costos de fallas
internas y costos de fallas externas.

Costos por fallas internas:

Son aquellos costos, ocasionados por fallas o defectos, por incumplimiento de requisitos
establecidos. Detectados dentro de la empresa, antes de la salida del producto. Entre
estos se incluyen:
 Revisión.
 Reparación
 Análisis de las modalidades de fallos.

Costos de fallas externas:

Son aquellos costos ocasionados al rectificar los fallos o defectos en el producto debido al
incumplimiento de los parámetros de calidad establecidos. Son detectados después de su
entrega al cliente. A continuación se incluyen algunos ejemplos de costos de fallos
externos:
 resolución de quejas.
 Devolución y sustitución de productos.
 Soporte en línea de ayuda.
 Trabajo de garantía.

11
En cuanto al valor aproximado de los costos, esto queda relativo a la media de un error se
ejemplifica este escenario a través de una gráfica.

16000
14102 $
14000

12000

10000

8000 7134 $

6000

4000

2000 977 $
139 $ 455 $
0
Requisitos Proyecto Codificación Tests Mantenimiento

Figura 1. Costo relativo a corregir un error

Fuente: Roger Perssman Ingeniería de Software un enfoque práctico

Como se muestra en la figura 1 el costo promedio de la industria de software para corregir

un error durante la generación de código es aproximadamente 977 $ por error. El costo
promedio para corregir el mismo error si se descubrió durante los tests (fallo interno) del
sistema, pasa a ser 7.136 $ por error. Y ese costo se puede duplicar, si el error es
detectado por el usuario final (fallo externo), llegando a un valor de aproximadamente de
14.102 $ por error.

8.2 ¿CÓMO ALCANZAR LA CALIDAD?

La calidad de software es el resultado de una buena gestión de proyectos y una práctica

consistente de Ingeniería de Software, esta administración y práctica se aplica en el
contexto de grandes actividades que ayudan a un equipo a alcanzar el alto nivel de
calidad en el software, que son las siguientes:

Métodos de Ingeniería de Software:

Si la expectativa es construir software de calidad, es importante entender el problema a
ser resuelto. Tener la capacidad de crear un proyecto que sea adecuado al problema y al
mismo tiempo presentar características que lleven a un software con las dimensiones y
factores de calidad.
A continuación, se explicará los métodos y técnicas para alcanzar la calidad.

12
Técnicas de Gestión de Software:
La calidad de software se ve afectada positivamente cuando un gerente de proyecto
utiliza estimaciones para comprobar que las fechas de entregas no se corrompen.
Control de Calidad:
Se aplica una serie de pasos de test para descubrir errores en la lógica de procesamiento,
manipulación de los datos y comunicación de interfaz. Una combinación de medios y
retroalimentación permite a un equipo de software ajustar el proceso cuando cualquiera
de estos productos resultantes deje de cumplir las metas establecidas para la calidad.

Garantía de Calidad:
Consiste en un conjunto de funciones de auditoria e informes que posibilita una
evaluación de efectividad y de la completitud de las acciones de control de calidad. Se
pretende proporcionar al personal técnico administrativo los datos del producto, ganando,
por lo tanto, entendimiento y confianza de que las acciones para alcanzar la calidad
deseada del producto están funcionando.

Incidencia de Software

La incidencia de software es conocido como bug, se produce cuando el software no

trabaja adecuadamente, y estas se clasifican en:

 Error:
Acción humana que produce un resultado incorrecto, por ejemplo, un error de
programación.

 Defecto:
Imperfección en un componente o sistema que puede causar que el componente
sistema falle en desempeñar las funciones requeridas, por ejemplo, si se localiza
un defecto durante una ejecución puede causar un fallo en un componente de
sistema.

 Fallo:
Manifestación física o funcional de un defecto, por ejemplo, desviación de un
componente o sistema respecto a la presentación, servicio o resultado esperado.

8. TEST DE SOFTWARE

Test de Software es una buena práctica realizada en un desarrollo de software, donde su

principal objetivo es reducir los riesgos y un buen test es aquello que posee una serie de
características que permiten encontrar el mayor número de errores posibles con el mínimo
esfuerzo.
Las actividades de tests son identificadas por las áreas de verificación y validación:

13
Verificación: ¿La forma en que construimos el software?
Test que permite verificar si el software está siendo construido correctamente.

Validación: ¿El software que construimos, es correcto?

Test que permite validar si el software está haciendo lo que se ha definido en los
requisitos.

Test de caja Blanca:

Figura 2. Test de caja blanca

Fuente: Roger Perssman Ingeniería de Software un enfoque práctico

Test de caja blanca, se a veces test de caja de cristal es un método de diseño de casos
de prueba que usa la estructura de control del diseño procedimental para obtener los
casos de prueba. Mediante los métodos de prueba de caja blanca el ingeniero de software
puede obtener los siguientes casos de prueba que:
 Garanticen que se ejercita por lo menos una vez todos los caminos independientes
de cada módulo.
 Ejercitan todas las decisiones lógicas en sus vertientes verdaderas y falsas.
 Ejecuten todos los bucles en sus límites y con sus límites operacionales.
 Ejerciten las estructuras internas de datos para asegurar la validez.

Test de Caja Negra:

Figura 3. Test de caja negra

14
 Fuente: Roger Perssman Ingeniería de Software un enfoque práctico
Test de caja negra, también denominado prueba de comportamiento, se centran en los
requisitos funcionales del software o sea la prueba de caja negra permite al ingeniero de
software obtener conjunto de condiciones de entrada que ejerciten completamente todos
los requisitos funcionales de un programa.
La técnica de caja negra intenta encontrar errores de la siguiente categoría:
 Funciones incorrectas ausentes.
 Errores de interfaz.
 Errores en estructuras de datos o en accesos a base de datos externas.
 Errores de rendimiento.
 Errores de inicialización y de terminación.

Procedimientos de test
El proceso de prueba este en paralelo al proceso de desarrollo.

Despliegue Test
Comienzo Comienzo
Verificación
Ciclo de vida
del desarrollo Validación Ciclo de vida del test

Correcciones
Completas

Figura 4. Concepto V test de software

Fuente: Roger Perssman Ingeniería de Software un enfoque práctico

Como se puede ver en la figura 4 empieza desde el mismo punto. En la etapa de

especificación, mientras el equipo de desarrollo se encarga de capturar y documentar los
requisitos con el propósito de desarrollar el sistema, el equipo de prueba realiza el mismo
procedimiento, pero con el fin de probar el sistema.
Es importante resaltar que el concepto “V” se centrar en las etapas de especificación y
ejecución del proceso de prueba. La forma más completa del proceso se describe en lo
que llamamos ciclo de vida de Test.
El ciclo se compone de seis etapas, cuatro de ellas secuenciales y dos paralelas, A
continuación, se visualizará una gráfica y se explicará cada etapa para más detalle.

15
 Planificación

Procedimientos Especificación Ejecución Entrega

Iniciales

Preparación

Figura 5. Modelo de ciclo de vida de los tests

Fuente: Roger Perssman Ingeniería de Software un enfoque práctico

Procedimientos iniciales:
Esta etapa es donde se realiza un estudio en profundidad de los requisitos de negocio del
sistema a ser desarrollado, garantizando que este completo. Deben definir las principales
actividades de prueba que se ejecutarán.

Planificación:
Etapa que consiste en la elaboración de una estrategia de prueba y un plan de prueba,
con el objetivo de minimizar los principales riesgos del negocio y proporcionar caminos
para las próximas etapas.

Preparación:
El objetivo de esta etapa es preparar el ambiente para que las pruebas se ejecuten
correctamente. Esta preparación implica la definición de configuración de equipos,
entrenamientos, instalación de herramientas de test, etc.

Especificación:
Consiste en elaborar y revisar casos de prueba de acuerdo a los requisitos definidos en
los procedimientos iniciales.

Ejecución:
En esta etapa se ejecutan los casos de prueba de forma manual o automática. En casos
de corrección de errores los ajustes de mejoras, una nueva ejecución es efectuada
garantizando la integridad del sistema.

Entrega:

16
Etapa de cierre de las pruebas, donde se elaboró una documentación con todas las
ocurrencias de tests, buscando la mejora del proceso.

8.1 AMBIENTE DE TEST

El entorno de prueba es la estructura donde se ejecutan las pruebas que va mucho más
allá de una simple configuración de software y hardware.
Es importante resaltar que el equipo de test no solo está compuesto por un ingeniero de
calidad, cuando se tiene un proyecto de pruebas se encuentran otros profesionales cuya
responsabilidad va más allá de ejecutar tests:

Líder de proyecto de Test Técnico responsable de un proyecto de

test específico, generalmente
relacionado con un sistema de
desarrollo, sea proyecto nuevo o de
mantenimiento.
Arquitecto Test Es el único responsable del montaje de
la infraestructura de test, monta el
ambiente de test escoge las
herramientas de test y capacita al equipo
para ejecutar su trabajo en ese ambiente.

Ingeniero de calidad Responsable de la ejecución de los

casos de test y script de test.

Tabla 1. Descripción de los profesionales que componen el equipo de test

Fuente: Roger Perssman Ingeniería de Software un enfoque práctico

Otro elemento importante del entorno de prueba son las herramientas de prueba. Estas
son el apoyo de los profesionales de esa área, cubren gran parte de las actividades de
prueba y son aplicables en todas las fases del ciclo de vida del software.
La elección adecuada de herramientas influye positivamente en la eficiencia y eficacia de
las pruebas, para ello es importante analizar factores como objetivos de la organización,
costos de la herramienta y el nivel de conocimiento para manejarla.

Para la mayoría de los proyectos de desarrollo de software modernos, el principal desafío

en la gestión del alcance no es eliminar la incertidumbre definiendo y cerrando los
requisitos lo antes posible. El principal desafío es manejar esta incertidumbre de una
manera que se pueda entender de lo que debe entregarse en un enfoque tradicional, se
supone que su comprensión aumentará de esta manera, se explicará a continuación, los
métodos para construir y entregar software de calidad.

Behavior Driven Development (BDD)

17
Behavior Driven Development o BDD es un conjunto de prácticas de ingeniería de
software diseñadas para ayudar a los equipos a construir y entregar software más valioso
y de mayor calidad, se basa en prácticas ágiles. Pero lo más importante es que BDD
proporciona un lenguaje común (Gherkin) basado en oraciones simples y estructuradas
que facilitan la comunicación entre los miembros del equipo del proyecto y las partes
interesadas de la empresa
BDD fue diseñado originalmente como una versión mejorada de TDD Desarrollo guiado
por pruebas, es una técnica extraordinariamente efectiva que utiliza pruebas unitarias
para especificar, diseñar y verificar el código de aplicación.

Test Driven Development(TDD)

Test Driven Development o Desarrollo guiado por pruebas de software, es un
procedimiento muy habitual entre los seguidores de metodologías ágiles. Se basa en un
desarrollo de pruebas a través de las cuales debe pasar el código, si está bien
implementado, se continúa creando código enfocado hacia la siguiente prueba, sino, se
configura hasta que pase la prueba y podamos ir a la siguiente fase, es una técnica para
diseñar software que se centra en tres pilares fundamentales:
 La implementación de las funciones que el cliente necesita.
 La minimización del número de defectos que llegan al software en fase de
producción.
 La producción de software modular, altamente reutilizable y preparado para el
cambio.

Gherkin
Es un lenguaje comprensible por humanos y por ordenadores, con el que vamos a
describir las funcionalidades, definiendo el comportamiento del software, sin entrar en su
implementación. Se trata de un lenguaje fácil de leer, fácil de entender y fácil de escribir.
Utilizar Gherkin permite crear una documentación viva a la vez que automatiza los tests,
haciéndolo además con un lenguaje que puede entender el negocio. Actualmente
Gherkin soporta más de 60 idiomas.
Lo interesante de Gherkin es que para empezar a hacer BDD solo se debe conocer 5
palabras, con las que construiremos sentencias con las que se describen las
funcionalidades:

 Feature: indica el nombre de la funcionalidad que se probará. Debe tener un título

claro y explícito. Incluimos aquí una descripción en forma de historia de usuario.

 Scenario: describe cada escenario que se probará

.
 Given: provee el contexto para el escenario el que se ejecutará el test, como
punto donde se ejecuta el test, o prerrequisitos en los datos. Incluye los pasos
necesarios para poner al sistema en el estado que se desea probar.

 When: especifica el conjunto de acciones que lanzan el test. La interacción del

usuario que acciona la funcionalidad que deseamos testear.

18
  Then: especifica el resultado esperado en el test. se observa los cambios en el
sistema y se verifica si son los deseados.

Ejemplo:
Feature: Usuario ingresa en la aplicación.
Scenario: Login correcto.
Given: Introducir un nombre de usuario en el campo correcto.
And: introducir un password en el campo correcto.
When: Hacer click en el botón.
Then: Debería mostrarse un mensaje.

Lo normal es probar distintos escenarios para comprobar una determinada funcionalidad.

De esta forma se pasará a las historias de usuario a pruebas de comportamiento
automatizables, para automatizar estas pruebas se necesitarán herramientas que se
explicará más adelante.

Definir los escenarios a desarrollar

Es la parte fundamental del proceso de BDD, ya que en este caso saldrán los escenarios
que guiarán todo el desarrollo del producto y serán los que generen el lenguaje común
que se usará en el proyecto.
En cada sprint deben definirse de forma clara cuáles serán las historias de usuarios que
servirán para dar por válido un sprint, por tanto, debe de implicar a todo el proyecto.
La definición debe realizarse utilizando el lenguaje Gherkin y al final de la sesión debe
existir uno o más archivos que incluyan las features y los escenarios que deberán
ejecutarse es ese sprint. Estos archivos no deberían modificarse a lo largo del desarrollo
salvo para una refactorización o una simple aclaración o corrección de los parámetros.

Crear test automáticos que validen la funcionalidad

Una vez que ya se han definido las features el siguiente paso es definir una serie de tests
automatizados que validen los escenarios. Esto se realizará antes de empezar la
codificación y debe seguir los principios de TDD:

Escribir un test.
Ver como todos los test fallan.
Escribir código.
Reescribir el test.

19
Crear un entorno de trabajo
Casi tan importante como tener que crear test automáticos que validen el producto es
tener un entorno que permita que estos test se ejecuten de manera correcta, eficiente y
eficaz. Si un test existe, pero no se ejecuta nunca, es inestable a causa del entorno o es
excesivamente lento, no se utilizará y el esfuerzo por crear un proceso eficiente no servirá
de nada.
Para crear un entorno de trabajo eficiente se debe pensar dónde se ejecutarán los tests
(en una máquina local, en una máquina de integración continua) y con qué frecuencia se
ejecutarán (se ejecutará en cada commit, de manera nocturna, cada cierto tiempo...). La
idea que debe primar es que estos tests serán los que indiquen si el sprint está terminado
y es válido, por lo que los desarrolladores podrán ejecutarlos cuando quieran y que el
resultado que proporcionen debe ser real de dónde lo estés ejecutando. Para ayudar con
esto existen herramientas como Vagrant o Docker que permiten definir máquinas
virtuales de manera sencilla y ligera que permiten al desarrollador tener un entorno "de
producción" en su propio ordenador.
Es importante que las retrospectivas de cada sprint sirvan para detectar cuales fueron los
errores y las mejoras para el siguiente sprint y servirán para ir definiendo mejor como se
escribirán los escenarios.

Técnicas de test

La técnica de prueba es un proceso que asegura el funcionamiento adecuado de algunos

aspectos del sistema o de la unidad. El ingeniero de calidad necesita conocer primero las
técnicas de prueba para luego entender que herramientas deben ser usadas para aplicar
cada técnica.

Figura 6. Estrategia de test

20
 Fuente: Bastos

Test de Unidad:
Test de unidad se aplica en el elemento más pequeño de un sistema, cada componente
es probado para asegurar que funciona correctamente. Normalmente desarrolla una única
función cohesiva. La función de la prueba unitaria es de analizar cada pequeña parte y
probar que funciona correctamente.

El test de unidad se usa mayormente por desarrolladores ágiles, especialmente en

programadores extremos, los amantes del TDD. Sin embargo, las pruebas unitarias son
más populares hoy en día y otros desarrolladores están empezando a utilizarlo.

Test de integración
Test integración es una extensión lógica de las pruebas unitarias. Dos unidades que ya
fueron probadas y combinadas en un componente y su interface son probadas entre ellas.
Un componente, se refiere a un agregado que está integrado en más de una unidad,
estas son combinadas en componentes, que son agregadas por orden en partes más
grandes del programa. El motivo del test de integración es de verificar la funcionalidad y la
seguridad entre los componentes que han sido integrados. Identifica los problemas que
ocurren cuando las unidades se combinan, y este consta de:

 Test Top-Down:
Comprueba la integración de cada módulo, empezando por el módulo de mayor
nivel.

 Test Bottom-up:
Comprueba la integración de cada módulo empezando por los módulos de bajo
nivel.

 Test de Regresión:
Re-ejecución de los mismos subconjuntos de pruebas para asegurar que la
inclusión de nuevos módulos no haya propagado efectos colaterales no deseados
en el sistema.

 Test Humo:
Rutina de test que ocurre en el sistema entero, el propósito es detectar errores a
cada uno de los módulos que se ha integrado.

Test de Validación
Test de validación en la Ingeniería de Software son el proceso de revisión que verifica que
el sistema de software producido que cumple con las especificaciones y que logra su
cometido. Es normalmente una parte del proceso de pruebas de software de un proyecto,
que también utiliza técnicas tales como evaluaciones, la validación es el proceso de
comprobar lo que se especificó es lo que el usuario realmente quiere, a continuación,
tenemos algunos test de validación:

21
  Test Alpha:
Se produce en un ambiente controlado, donde el desarrollador monitorea el uso
del sistema por los usuarios finales registrando posibles errores funcionales.

 Test Beta:
Ocurre en el propio ambiente de producción sin la presencia del desarrollador. Los
errores encontrados se registra en intervalos regulares por los propios usuarios
finales.

Test del Sistema

Test de sistema implica integrar dos o más componentes que implementan
funcionalidades del sistema o características y a continuación se prueba este sistema
integrado en un proceso de desarrollo iterativo, test de sistema se ocupa de probar un
incremento que va a ser entregado al cliente, se ejecutan las funciones asignadas a ellos:

 Test de Recuperación:
Evalúa la capacidad del sistema de recuperarse mediante las fallas, retornando el
procedimiento en poco o en ningún tiempo de parada.

 Test de Seguridad:
Comprueba si los mecanismos de protección incorporados al sistema están aptos
para protegerlos de accesos indebidos.

 Test por Esfuerzo:

Conocido como prueba de estrés, pretende colocar el sistema en condiciones
anormales para conocer hasta dónde llega la tolerancia a fallas. Para que este
límite sea superado, se utilizan los recursos al máximo, sea en cuanto a cantidad,
frecuencia o volumen.

 Test de Rendimiento:
Evalúa el rendimiento del sistema como tiempo de ejecución, uso de recursos.

 Test de Disponibilidad:
También conocido como prueba de configuración, valida la flexibilidad del sistema
en ser operado en los diversos tipos de ambientes.

9. BIENVENIDO A LA ERA DE LA AUTOMATIZACIÓN

La automatización de tests es una práctica que busca reducir tiempo de ejecución y el

tiempo de los tests.

22
 9.1 PRINCIPIOS DE LA AUTOMATIZACIÓN

Así como en cualquier proceso, la automatización de test tiene principios a fin de evitar
futuros problemas, a continuación, seguiremos algunos de los principios de
automatización:
 Diseñe los casos de prueba para automatizar
 Busque expandir el universo de la automatización en lugar de simplemente repetir
los mismos scripts. Explore lo que usted tiene en las manos y lo que necesita
hacer más.
 No piense en automatizar el 100% de todo.
 No automatice lo que no es importante
 No piense que las interfaz de usuario nunca va a cambiar. El cambio es casi una
constante en buena parte de las aplicaciones. Las herramientas tienen que
adaptarse a estas nuevas interfaces.
 Proyectos de automatización de pruebas requieren una mezcla de perfiles en el
equipo: habilidades de programación, planificación y ejecución de gestión de
proyectos.
 Diseñe la automatización de tests para facilitar las revisiones.
 Inicie la automatización de tests lo antes posible en un proyecto.

9.2 AUTOMATIZACIÓN TEST

La automatización de prueba consiste en el uso de las herramientas que imita la

interacción del probador con la aplicación, esta práctica tiene por objetivo reducir el
tiempo de ejecución y el plazo de los tests.
Aunque la intención de la automatización es de disminuir al máximo los procedimientos
manuales, garantiza que la prueba manual es algo insustituible. Incluso si la empresa
automatiza el 99% de los tests, siempre habrá una necesidad de un análisis o una
pequeña prueba a realizar.

9.3 TESTS MANUALES POR TESTS AUTOMATIZADOS

La prueba manual no se puede eliminar, sino que se reduce al máximo y se centra en

casos específicos donde es muy caro automatizar. Por otro lado, la prueba automatizada
es indispensable para un aumento de productividad y reducción de tiempo en general y
rutinario en la prueba. Ejemplo: el caso de la automatización de un login
Usted escribe el usuario y contraseña de la aplicación y confirma su login, haciendo click
en el botón entrar, ahora realizar un test que realice el login de 50 usuarios diferentes,
sería algo moroso.
Con la automatización, se podría grabar la acción de un login, parametrizando el usuario y
contraseña con datos obtenidos, a través de un bucle de 50 ejecuciones. Pronto,
tendríamos un caso de test automatizado.

23
Para tests de regresión y rendimiento, no hay duda de que test automatizado sea lo más
adecuado.

9.4 CUESTIONES ACERCA DE LA AUTOMATIZACIÓN

Incluso con todas las ventajas ya presentadas en la automatización de tests, es

importante revisar algunas cuestiones que determinan si la automatización es viable o no
para el entorno de la organización.

 ¿Por qué automatizar?

Se deben identificar los objetivos de la empresa.

 ¿Qué automatizar?
Saber que módulos y áreas a probar en el sistema

 ¿Cuándo automatizar?
Varía de acuerdo con las situaciones de la empresa. En algunos casos cuando no
hay ninguna automatización de las pruebas, otros casos cuando la empresa desea
mejorar la automatización existente.

 ¿Dónde automatizar?
Decidir si será en un ambiente la parte o compartido con el desarrollo.

 ¿Cómo automatizar?
Definir las técnicas y herramientas que se utilizarán.

 ¿Quién va automatizar?
Delegar la función para los integrantes que poseen el perfil adecuado.

 ¿Cuánto cuesta automatizar?

Tener en cuenta el costo de la inversión y el tiempo necesario de ejecución.

10. DIFERENCIA ENTRE PRUEBAS FUNCIONALES, PRUEBAS NO

FUNCIONALES

Pruebas funcionales:
Se basan en el funcionamiento del producto, buscando si la solución satisface las
necesidades por la que fue creada. Este tipo de prueba permite determinar si se ha
construido el software deseado y si es oportuno liberar la versión del producto al mercado.
Este análisis también permite a las empresas, que hacen uso intensivo de las tecnologías
de la información, determinar si han adquirido el software deseado.
Para ello, se propone una estrategia basada en el análisis de riesgos del producto,
definiendo claramente el contexto y los objetivos. Y se elabora y planifican una serie de

24
pruebas basadas en las funcionalidades prioritarias, considerando su complejidad, una
prueba funcional es una prueba basada en la ejecución, revisión y retroalimentación de
las funcionalidades previamente diseñadas para el software, hay distintos tipos, por
ejemplo:
 Pruebas unitarias.
 Pruebas de componentes.
 Pruebas de integración.
 Pruebas de sistema.
 Pruebas de aceptación.
 Pruebas de regresión.

Pruebas no funcionales:
Son complementarias a las anteriores y se centran en pruebas necesarias para medir las
características de los sistemas software, es decir tienen por objetivo evaluar “cómo”
funciona el producto software. Este tipo de prueba puede cuantificarse mediante
diferentes escalas según el análisis realizado (tiempos de respuesta, operaciones por
segundo etc.) A esta clase de test se corresponden:
 Pruebas de compatibilidad.
 Pruebas de seguridad.
 Pruebas de estrés
 Pruebas de usabilidad.
 Pruebas de rendimiento.
 Pruebas de escalabilidad.
 Pruebas de mantenibilidad.
 Pruebas de portabilidad.

11. HERRAMIENTAS DE AUTOMATIZACIÓN PÁRA EL PROCESO DE

CONTROL DE CALIDAD

Actualmente existe muchas herramientas a disposición de los equipos de desarrollo para

probar software. Para cualquier tipo de prueba como: unitarias, funcionales, rendimiento,
seguimiento de bugs. A continuación, se explicará las herramientas más relevantes para
la automatización, que aparecen en el mercado actual y que tienen potencial para ser
utilizadas como software de automatización.

11.1 HERRAMIENTAS DE PRUEBA UNITARIA

Las pruebas unitarias son una de las formas que se tiene para probar pequeñas e
individuales porciones de código. Permiten detectar efectivamente la inyección de
defectos durante fases sucesivas de desarrollo o mantenimiento. A través de estas, se
verifica que cierto módulo o funcionalidad se ejecuta dentro de los parámetros y

25
especificaciones concretadas en documentos, tales como los casos de uso y el diseño
detallado que proporcionan un contrato escrito que la porción de código debe cumplir. Las
pruebas Unitarias típicamente son automatizadas, pero pueden llevarse a cabo de forma
manual.
Una prueba unitaria es completa si cumple con los siguientes elementos:

 Automatizable: no debería requerirse una intervención manual, esto es

especialmente útil para la integración continua.

 Completas: deben cumplir la mayor cantidad de código.

 Reutilizables: no se deben crear pruebas que solo puedan ser ejecutadas una
sola vez. También es útil para integración continua.

 Independientes: la ejecución de una prueba no debe afectar a la ejecución de

otra.

 Profesionales: las pruebas deben ser consideradas igual que el código con la
misma profesionalidad y documentación.

Ventajas
Es necesario saber que las pruebas unitarias por sí solas, no son perfectas, puesto que
comprueban el código en pequeños grupos, pero no la integración total del mismo. Para
ver si hay errores de integración es necesario realizar otro tipo de pruebas de software
conjuntas y de esta manera comprobar la efectividad total del código. A continuación, se
explicará las ventajas de las pruebas unitarias:

 Proporciona un trabajo ágil: Como procedimiento ágil que es, te permite poder
detectar los errores a tiempo, de forma que puedas reescribir el código o corregir
errores sin necesidad de tener que volver al principio y rehacer el trabajo,
disminuyendo el tiempo y costo.

 Calidad del código: Al realizar pruebas continuamente y detectar los errores,

cuando el código está terminado, es un código limpio y de calidad.

 Detectar errores rápido: A diferencias de otros procesos, los tests unitarios nos
permiten detectar los errores rápidamente, analizamos el código por partes,
haciendo pequeñas pruebas y de manera periódica, además, las pruebas se
pueden realizar las veces que hagan falta hasta obtener el resultado óptimo.

 Facilita los cambios y favorece la integración: Los tests unitarios, nos permiten
modificar partes del código sin afectar al conjunto, simplemente para poder
solucionar bugs que nos encontramos por el camino.
 Proporciona información: Gracias al continuo flujo de información y la
superación de errores, se puede recopilar gran cantidad de información para
evitar bugs en un futuro.

26
  Proceso debugging: Los Tests unitarios ayudan en el proceso de debugging.
Cuando se encuentra un error o bug en el código, solo es necesario desglosar el
trozo de código testeado. Esta es uno de los motivos principales por los que los
tests unitarios se hacen en pequeños trozos de código, simplifica mucho la tarea
de resolver problemas.

 Reduce el coste: Partiendo de la base que los errores se detectan a tiempo, lo

cual implica tener que escribir menos código, poder diseñar a la vez que se crea y
optimizar los tiempos de entrega, vemos una clara relación con una reducción
económica.

Junit

Figura 7 Logo de JUnit

Fuente: JUnit

Junit es un framework que permite realizar pruebas de ejecución de clases escrito en

java de manera controlada, para poder evaluar si el funcionamiento de cada uno de los
métodos de la clase se comporta como se espera, es decir, en función de algún valor de
entrada se evalúa el valor de entrono esperado, si la clase cumple con la especificación,
entonces se devolverá que el método de la clase pasó exitosamente la prueba, en caso
de que el valor esperado sea diferente al que regreso el método durante la ejecución, se
devolverá un fallo en el método correspondiente.

Anotaciones:

@ Test Indica que es un método de prueba

@TestFactory Indica que un método es una fábrica de

pruebas para pruebas dinámicas.

@BeforeEach Indica que el método anotado debe

ejecutarse antes de cada @Test

@AfterEach Indica que un método anotado debe

ejecutarse después de cada @Test

@BeforeAll Indica que el método anotado debe

ejecutarse antes de todos los @Test

@AfterAll Indica que el método anotado debe

ejecutarse después de todos los @test
Tabla 2 Anotaciones de JUnit
Fuente: JUnit

27
Nunit

Figura 8 Logo de NUnit

Fuente: NUnit

Nunit es un framework open source para pruebas unitarias de sistemas realizados con la
plataforma Microsoft.NET. Sirve al mismo propósito que realiza JUnit en el mundo java.
Consiste en probar métodos de una clase especifica fue desarrollado en C#, y pertenece
a xUnit que son todos aquellos frameworks de prueba heredados de JUnit y que, por lo
tanto, siguen las normas marcadas por el mismo.

Características:

 Soporta lenguajes C#, J# Visual Basic y C++

 Es multiplataforma, trabaja con Windows y Linux.
 Provee dos tipos de interface para ser ejecutados: interfaz gráfica y consola.
 se integra fácilmente con Visual Estudio.

Atributos:

Test Marca un método que representa una prueba.

TestCase Marca un método con parámetros como prueba y

proporciona argumentos en línea.

TestCaseSource Marca un método con parámetros como prueba y

proporciona una fuente de argumentos.

TestFixture Marca una clase como elemento de prueba y puede

proporcionar argumentos de construcción en línea.

TestFixtureSource Marca una clase como elemento de prueba y

proporciona una fuente para los argumentos del
constructor.

TestOf Indica el nombre o el tipo de la clase que se está

probando.

Timeout Proporciona un valor de tiempo de espera en

milisegundos para los casos de prueba.

28
 Values Proporciona un conjunto de valores en línea para un
parámetro de un método.

ValueSource Proporciona una fuente de valores para un parámetro

de un método de prueba.
Tabla 3 Atributos de NUnit

Fuente: NUnit

TestNG

Figura 9 Logo de TestNG

Fuente: TestNG

TestNG es un framework para pruebas desarrollado en las líneas de JUnit y NUnit, sin
embargo, introduce algunas funcionalidades nuevas que lo hacen más poderoso de
pruebas unidad, funcional,

Características:

 anotaciones
 configuración flexible
 integración con herramientas (Eclipse IDEA Maven)

Anotaciones:

@BeforeSuite Anotación que se ejecutará antes que se ejecuten todas las

pruebas en este conjunto.

@AfterSuite Anotación que se ejecutará después que se ejecuten todas las

pruebas de este suite.

@BeforeTest Anotación que se ejecutará antes que se ejecute cualquier

método de prueba perteneciente a las clases dentro de la
etiqueta <test>.

@AfterTest Anotación que se ejecutará después que se ejecutaron todos los

métodos de prueba que pertenecen a las clases dentro de las
etiquetas <test>.

29
 @BeforeGroups Lista de grupos que este método de configuración ejecutará
antes. Se garantiza que este método se ejecute poco antes de
que se invoque el primer método de prueba que pertenece a
cualquiera de estos grupos.

@AfterGroups La lista de grupos que este método de configuración ejecutará

después. Se garantiza que este método se ejecutará poco
después de que se invoque el último método de prueba que
pertenece a cualquiera de estos grupos.

@BeforeClass Anotación que se ejecutará antes de que se invoque el primer

método de prueba en la clase actual.

@AfterClass Anotación que se ejecutara después que se ejecutaron todos los

métodos de prueba actual.

@BeforeMethod Método anotado se ejecutará antes de cada método de prueba.

@AfterMethod Método anotado se ejecutará después de cada método de

prueba.
Tabla 4 Anotaciones de TestNG
Fuente: TestNG

En la siguiente tabla se visualizará las características principales de la prueba de test

Unitaria en este caso se tomó las herramientas JUnit, NUnit, TestNG,

JUnit NUnit TestNG

C#, J#, Visual Java

Lenguajes soportados Java
Basic, C++
Windows Linux
Entornos soportados Windows Linux y Mac Windows, Linux y Mac

Integración con Eclipse, Maven. IDEA, Eclipse, Maven,

Visual Estudio IDEA
herramientas NetBeans

Anotaciones Si Si Si

Alto nivel de Si
Si Si
programación
Tabla 5 herramientas de Test unitario
Fuente: propio

30
 11.2 HERRAMIENTAS DE PRUEBA FUNCIONAL

Se denominan pruebas funcionales a las pruebas de software que tienen que probar que
los sistemas desarrollados cumplan con las funciones específicas para las cuales fueron
creadas, es común que este tipo de pruebas sean desarrolladas por analistas de pruebas
con el apoyo de algunos usuarios finales, esta etapa suele ser la última etapa de prueba y
al dar conformidad sobre esta, el siguiente paso es el pase a producción.
Dentro de los importantes beneficios que tiene este tipo de pruebas esta la mitigación del
riesgo de aparición de fallos en producción, el cumplimiento de los objetivos de los
proyectos en términos de calidad y resultados esperados principalmente, pero también de
plazos y costos.
Para llevar a cabo las pruebas funcionales, es necesario seguir un procedimiento
determinado en las siguientes fases:

 Análisis de requerimientos: Corresponde a la revisión de la documentación

entregada por el Jefe de Proyecto de Desarrollo, y que es la base para elaborar
los casos de prueba.
 Elaboración de Plan de Pruebas: Corresponde a la generación del documento
que será entregado al Jefe de Proyecto donde se identifican las consideraciones
para la ejecución de las pruebas (Ambiente, Datos, Responsables, Riesgos,
Métricas de Aceptación, etc.).
 Elaboración de Casos de Pruebas: Corresponde al diseño de los casos de
prueba que se utilizarán para realizar la certificación del software validando que
cumpla con lo solicitado por el usuario.
 Ejecución: Corresponde a la ejecución de los casos de pruebas anteriormente
diseñados. Además, se realiza la detección de incidencias en la aplicación que son
reportados al Jefe de Proyecto.
 Elaboración Reporte de Cierre: Corresponde a la generación del Reporte de
Cierre con los resultados finales de la certificación del software.

A continuación, se mencionará herramientas de prueba funcional más relevantes.

Selenium
Selenium es una suite compuesta por las herramientas: selenium IDE, Selenium Remote
Control, Selenium Webdriver y Selenium Grid. Cada uno con la finalidad de garantizar la
automatización de las pruebas funcionales de forma práctica y eficiente.

¿Por qué usar selenium?

Aunque ya existan diversas herramientas de automatización de test, Selenium se destaca
por ser un conjunto de herramientas, permitiendo al usuario evaluar las aplicaciones web
en las más diversas formas de automatización.

31
Selenium no es una herramienta única, sino un conjunto de herramientas que ayuda a los
ingenieros de calidad a automatizar las aplicaciones basadas en la web de manera más
eficiente. A continuación, explicaremos cada una de las herramientas disponibles:

Selenium IDE

Figura 10 Logo de Selenium IDE

Fuente: Selenium

Selenium IDE es un entorno de desarrollo integrado para scripts de Selenium. Se

implementa como una extensión de Chrome y Firefox, y le permite grabar, editar y
depurar pruebas.
Selenium IDE no es solo una herramienta grabación, es un IDE completo puede optar por
utilizar su capacidad de grabación, o puede editar sus scripts, Selenium IDE es el entorno
ideal para crear pruebas de Selenium sin soportar el estilo de pruebas que prefiera.

Características:
 Fácil grabación y reproducción.
 Autocompletar para todos los comandos comunes de Selenium.
 Depurar y establecer puntos de interrupción.
 Todo en un archivo de proyecto, que contiene todos los casos de prueba.

Selenium Remote Control

Figura 11 Logo Selenium Remote Control

Fuente: Selenium
Selenium Remote Control es una herramienta de prueba que le permite escribir pruebas
automatizadas de aplicaciones web en cualquier lenguaje de programación en cualquier
sitio web HTTP utilizando cualquier navegador convencional.
Viene en dos partes:

32
  Un servidor que automáticamente inicia y mata los navegadores, y actúa como
proxy HTTP para las solicitudes web de ellos.
 Bibliotecas cliente para su lenguaje informático favorito.

Selenium Webdriver

Figura 12 Logo de Selenium WebDriver

Fuente: Selenium

Es la versión mejorada del remote control lo que lo hizo popularmente conocido como
Selenium 2.0, se trata de una clase con la estructura más concisa, permitiendo una
interacción más eficaz con el browser y superando la limitación de su predecesor.
Selenium WebDriver es el nombre de la interfaz clave contra la cual se deben escribir las
pruebas en java, las clases de implementación que se usaran.

Características:
 Está diseñado en una interfaz de programación más simple y concisa.
 Impulsa el navegador de manera mucho más efectiva y supera las limitaciones de
Selenium 1.0 que afectaron nuestra cobertura de prueba funcional, como la carga
o descarga de archivos.
 API orientado a objetos compacta en comparación con Selenium 1.0.

Selenium Grid

Figura 13 Logo de Selenium Grid

Fuente: Selenium

33
A partir de la segunda versión Selenium, ha pasado a contar con una nueva funcionalidad
que permite la ejecución de pruebas en diversos ordenadores de forma simultánea,
independientemente del sistema operativo y navegador que estén usando.
Es una gran alternativa para aplicar algunas técnicas de pruebas, tales como el de carga,
en términos generales, hay dos razones por las cuales es posible usar Selenium Grid:
 Para ejecutar en múltiples navegadores, múltiples versiones de navegador que se
ejecuten en diferentes sistemas operativos.
 Para reducir el tiempo que tarda en completar un pase de prueba.

Canoo Webtest

Figura 14 Logo de Canoo WebTest

Fuente: Canoo WebTest

Canoo WebTest es una herramienta de código abierto para la prueba automatizada de

aplicaciones web de una manera efectiva. Llama a las páginas web y verifica los
resultados, brindando informes completos sobre el éxito o fracaso.

Características:

 webtest tiene una sintaxis sencilla con pasos que tienen nombres significativos.
 Proporciona informes que visualiza toda la información que permite comprender
rápido el error.
 Webtest está escrito en java esto quiere decir que se ejecuta en sistemas
operativos donde esté instalado el JDK
 Los scripts de Webtest se integra fácilmente con herramientas de integración
continua y soporte en IDE.

Cucumber

Figura 15 Logo de Cucumber

Fuente: Cucumber

34
Cucumber fue escrito originalmente en el lenguaje de programación Ruby y se usó para
pruebas de Ruby, ahora es compatible con una variedad de diferentes lenguajes de
programación a través de varias implementaciones incluyendo java. Ejecuta pruebas de
aceptación automatizadas escritas en un estilo de desarrollo guiado por el
comportamiento (BDD).

Gherkin es su analizador de lenguaje, permite que los comportamientos de software

esperados se especifiquen e un lenguaje lógico que los clientes puedan entender como
tal. Cucumber permite la ejecución de documentación de características escrita en texto
orientado al negocio.

HP UFT

Figura 16 Logo de HP UFT

Fuente: HP UFT

HP Unified Functional testing, propiedad de Hp y anteriormente llamado Quick Test

Professional (QTP), ofrece software de automatización de pruebas funcionales y regresión
para todas las aplicaciones de software más importantes y de entorno, incluyendo
avanzadas herramientas Web 2.0 principales tecnologías de desarrollo web services.

Al grabar un aprueba sobre una interfaz de usuario, UFT registra las líneas de código de
la prueba correspondientes con cada acción que realiza. Cada línea, por lo general,
representa una pantalla. Los componentes se llaman objetos y las acciones que se
realizan en ellos se denominan operaciones.

Algunas de las principales características:

 Pruebas de interfaz gráfica.

 Utiliza lenguaje VBScript para el desarrollo y generación de los scripts de prueba
para la modificación de los mismos.
 Permite crear casos de prueba mediante la captura de flujos directamente de las
pantallas de la aplicación. Además, los usuarios pueden tener acceso completo a
la prueba subyacente y propiedades de los objetos.

35
  Permite una mayor velocidad, cobertura de la prueba y repetición de pruebas de
menos recursos. Provocando también una reducción en los costes debido a la
posibilidad de ejecutar pruebas y la creación automática de documentos de
prueba.

En la siguiente figura se visualizará un cuadro comparativo de las herramientas de

pruebas funcional, en este caso se tomó las herramientas de Selenium y HP UFT.

Selenium HP UFT
Lenguajes java, C#, Ruby, Python, Perl VB Script
Soportados PHP, JavaScript
Navegadores Chrome, internet explorer, Chrome, internet explorer,
Soportados Firefox, Opera, Safari. Firefox, Safari
Entornos Soportados Windows, Linux, Mac, otros. Windows
Gratuito Si No
Framework Selenium + Eclipse + Maven, HP Quality center y
Jenkins, Hudson & its plug-ins, performance center
TestNG + SVN Nunit, Junit. integrados dentro de HP
ALM
Alto Nivel de Si No
Programación
Integración con Si HP Mercurial, HP Quality
herramientas center
externas
Resultado e informes Integración con jenkins Results Viewer, Screen
y análisis Recorder y soporte QC
Ayuda y Poca online Mucha dentro de la
documentación herramienta online
Tabla 6 Herramientas de Prueba Funcional
Fuente: propia

11.3 HERRAMIENTAS DE PRUEBAS DE RENDIMIENTO

Las pruebas de rendimiento son las pruebas que se realizan, desde una perspectiva, para
determinar lo rápido que realiza una tarea un sistema en condiciones particulares de
trabajo. También puede servir para validar y verificar otros atributos de la calidad del
sistema, tales como escalabilidad, fiabilidad y uso de los recursos.
Es una práctica informática que se esfuerza por mejorar el rendimiento, englobándose en
el diseño y la arquitectura de un sistema, antes incluso del esfuerzo inicial de la
codificación.

36
Ventajas

La idea principal de este tipo de pruebas es examinar la velocidad de una aplicación de

software para ayudar a determinar si la aplicación responde de inmediato o no, ayuda a
determinar cuanta carga puede manejar la aplicación, determina si la aplicación es
estable bajo diferentes cargas. Trae toda una serie de beneficios como:

 Determinar cuellos de botella como la configuración de la base de datos.

 Ayuda a determinar si una versión está preparada para la producción o no.
 Permite conocer el rendimiento real en comparación con sus expectativas.
 Aumento de ingresos en línea.

JMeter

Figura 17 Logo JMeter

Fuente: JMeter

JMeter es una herramienta libre basada en el lenguaje java, que permite realizar pruebas
de rendimiento sobre aplicaciones web. Es una herramienta se carga para llevar acabo
simulaciones sobre cualquier recurso de software.

Esta herramienta destaca por su versatilidad, estabilidad y por ser de uso gratuito.
También permite la ejecución de pruebas distribuidas entre distintos ordenadores para
realizar pruebas de rendimiento.

Entre las características de JMeter están:

 Realiza las pruebas de carga y rendimiento a diferentes tipos de servidores: web –

HTTP, HTTPS, Database vía JDBC, LDAP, JMS – POP3(S), IMAP(S).
 Completamente portable y 100% java.
 Posibilidad de realizar pruebas con varios hilos (multitheard).
 Interfaz de usuario para el manejo.
 Análisis offline.
 Estadísticas de carga.
 Manejo de script para la simulación de carga.

37
Esta herramienta muestra los resultados de las pruebas en una amplia variedad de
informes y gráficas. Además, facilita a una rápida detección de los cuellos de botella
existentes debido al tiempo de respuesta excesivo.

WebLOAD

Figura 17 Logo de WebLOAD

Fuente: WebLOAD

WebLOAD es una herramienta de pruebas de carga, pruebas de rendimiento,

aplicaciones web de pruebas de estrés. La herramienta de prueba WebLOAD combina
rendimiento, escalabilidad e integridad como un proceso único para la verificación de
aplicaciones web y móviles.

Puede simular cientos de miles de usuarios concurrentes haciendo posible probar

grandes cargas y reportar cuellos de botellas, restricciones y puntos débiles dentro de una
aplicación.

Utilizando su soporte multiprotocolo, WebLOAD simula el tráfico de cientos de miles de

usuarios y proporciona datos de análisis sobre cómo se comporta la aplicación bajo carga,
WebLOAD supervisa e incorpora estadísticas de los diversos componentes del sistema
bajo prueba: servidores, servidor de aplicaciones, base de datos, red, equilibrador de
carga, firewall, etc. Y también puede supervisar el cumplimiento de la experiencia del
usuario final.

Características:

 La correlación automática de valores dinámicos, como los identificadores de

sesión, permite que un script se ejecute dinámicamente con múltiples clientes
virtuales.
 WebLOAD genera carga desde máquinas virtuales o desde la nube.
 Proporciona informes de análisis predefinidos y datos de rendimientos, ayudando
a los usuarios a identificar cuellos de botellas. Los informes y los datos de análisis
también se visualizan de forma remota a través de un panel web.
 Recopila estadísticas del lado del servidor durante las ejecuciones de prueba.
 Panel de control web análisis de resultados de prueba de rendimiento desde
cualquier navegador o dispositivo móvil.

38
En la siguiente tabla se visualizará un cuadro comparativo de las herramientas de test de
rendimiento, en este caso se tomó las herramientas de JMeter y WebLOAD.

JMeter WebLOAD
Protocolos soportados HTTP, HTTPS, FTP, FTP, UDP, TCP, SMTP,
SOAP/XML, RPC, JDBC, Telnet, POP, SSL
LDAP, JMS
Informes de análisis Si Si muestra gráficamente
los resultados
Monitorización y análisis Si, se amplía cuando coopera Si
en tiempo real con otros módulos
Alto nivel de Si Si
programación
Multiplataforma Windows, Linux, Mac Windows, Linux, Mac
Necesita conexión a No Si
internet
Tabla 7 Herramientas de Test de rendimiento
Fuente: propia

11.4 HERRAMIENTAS DE SEGUIMIENTOS DE BUGS

Para gestionar un proyecto no es importante conocer al 100% el funcionamiento del

código, siempre es más importante saber dónde falla el código y por qué. Hay muchos
errores que son fáciles de encontrar, ya sean porque se encuentran en un punto que da
un error crítico y la aplicación no funciona, o bien con el continuo testeo se encuentra el
error. Para ello hay otras personas y departamentos que deben realizar esta función.

Bugzilla

Figura 1918 Logo de Bugzilla

Fuente: Bugzilla

Bugzilla es una herramienta basada en web de seguimiento de errores, originalmente

desarrollada y usada por el proyecto Mozilla. Lanzado como software de código abierto
por Netscape Communications en 1998, Bugzilla permite organizar en múltiples formas

39
los defectos de software, permitiendo el seguimiento de múltiples productos. Permite
categorizar los defectos de software de acuerdo a su prioridad y severidad, así como
asignarles versiones para su solución.

Permite también anexar comentarios, propuestas de solución, designar a responsables,

todo ello llevando un seguimiento de fechas en las cuales sucede cada evento, si se
configura adecuadamente se puede enviar mensajes de correos a los interesados en el
error.

Bugzilla utiliza un servidor HTTP (como puede ser apache) y una base de datos
(normalmente Mysql) para llevar a cabo su trabajo. Los errores pueden ser enviados por
cualquiera y pueden ser asignados a un desarrollador en particular. Cada error puede
tener diferente prioridad y encontrarse en diferentes estados, así como ir acompañado de
notas del usuario o ejemplos de código que ayuden a corregir el error.

Características:

 Seguridad
 Campos personalizables
 Flujo de trabajo personalizado
 Interfaz de servicios web
 Soporte para motores de base de datos múltiples
 Controlar la visibilidad de errores

Eventum

Figura 20 Logo de Eventum

Fuente: Eventum

Eventum es un sistema de seguimiento de problemas fácil de usar y muy flexible, que

puede ser utilizado por un departamento de asistencia para realizar un seguimiento de las
solicitudes de asistencia técnica entrante, o por un equipo de desarrollo de software para
organizar rápidamente las tareas y los errores.

40
Jira Software

Figura 21 Logo de Jira Software

Fuente: Jira Software

En 2003 se creó jira para supervisar y gestionar errores de desarrollo de software. Desde
entonces, se ha ampliado para ayudar a los equipos a planificar y supervisar todos los
aspectos del ciclo de desarrollo de software. Desde la limpieza del backlog hasta la
gestión de publicaciones.

Detecta errores en cualquier parte de tus proyectos de software con Jira Software.
Cuando se encuentre un error, crea una incidencia y añade todos los datos de
importancia, incluyendo: descripciones, nivel de gravedad, captura de pantalla, versión,
etc. Las incidencias pueden representar cualquier cosa desde un error de software, una
tarea de proyecto o un formulario de solicitud.

Cuando se detecta errores se clasifica y prioriza según la importancia de la incidencia y la

carga de trabajo del equipo.

Características:

 Planificación y creación de informes ágiles.

 Priorización de tareas.
 Brinda visibilidad en tiempo real y un estado actualizado de la próxima versión de
su equipo.
 Tableros de Scrum permite aumentar la visibilidad de los elementos de trabajo en
todo su equipo y garantizar que todos trabajen siempre de mayor prioridad.
 Paneles personalizables que contienen todo lo que se necesita para planificar y
hacer un seguimiento de trabajo.

41
En la siguiente tabla se visualizará un cuadro comparativo de las herramientas de
seguimiento de bugs, en este caso se tomó las herramientas Bugzilla, Eventum y Jira
Software.

Bugzilla Eventum Jira Software

Licencia Open sources Open sources No
Arquitectura basada en la Si Si Si
web
Lenguaje de programación Perl PHP Java
Sistemas operativos Linux Windows OS Linux Unix Linux
X Windows Windows
Aplicaciones móviles Android iOS No Android iOS
Tabla 8 Herramientas de Seguimiento de Bugs
Fuente: propia

42
12. CONCLUSIONES

En esta monografía se vio la importancia de las pruebas en el área de calidad de software

y de que realizar pruebas de software no es fácil, las actividades de pruebas de software
son totalmente especificas exigiendo un conocimiento solido del equipo para ser
ejecutadas.
Las empresas que desean estar en la cima del mercado de trabajo, principalmente en lo
que se refiere a la mejora en los procesos de desarrollo de software, deben invertir en
pruebas de software, buscando siempre innovar.
Gracias a la difusión del conocimiento, hoy se cuenta con innumerables herramientas de
pruebas de código abierto que viene atendiendo bien las necesidades de los negocios,
por lo tanto se escogió las herramientas más relevantes que hoy en día se están
utilizando para la automatización explicando a detalle cada herramienta.

43
13. BIBLIOGRAFÍA

 Roger S. Pressman Ingeniería de Software un Enfoque Practico 5ta Edición.

 Ian Sommerville Ingeniería de Software 7ma Edición.
 Jeff Tian Software Quality Engineering.
 BDD in Action Jhon Ferguson Smart
 I Jornada sobre calidad del Producto de Software e ISO 25000 Fernando Suarez
Lorenzo, Javier Garza Parra
Páginas Web
 https://www.seleniumhq.org/docs/
 http://testng.org/doc/documentation-main.html
 https://junit.org/junit5/docs/current/user-guide/
 https://docs.cucumber.io/guides/
 https://www.radview.com/
 https://launchpad.net/eventum

44