Informe Práctica Profesional CC59A Blue Company S.A.

Informe Práctica Profesional
CC59A
Blue Company S.A.
Autor: Gastón Jorquera Ahumada
Carrera: Ingenierı́a Civil en Computación
Matrı́cula: 24002302
E-Mail: [email protected]
Fecha: 29 de Agosto de 2008
Evaluación por Parte de la Empresa
Datos
Empresa
Blue Company S.A.
Nombre del supervisor
Emilio Davis Mendez
Teléfono del supervisor 2448900
Firma del supervisor
Fecha de inicio
3 de Diciembre de 2007
Fecha de término
2 de Enero de 2008
Evaluación1
Satisfacción con el trabajo realizado
7,0
Calidad técnica
7,0
Iniciativa e interés
7,0
Responsabilidad
7,0
Trato personal y capacidad de adaptación 7,0
1
Nota de 1,0 a 7,0.
i
Observaciones
ii
Índice
1. Resumen
1
2. Introducción
2
2.1. Lugar de Trabajo . . . . . . . . . . . . . . . . . . . . . . . . .
2
2.2. Grupo de Trabajo . . . . . . . . . . . . . . . . . . . . . . . . .
3
2.3. Equipo y Software Utilizado . . . . . . . . . . . . . . . . . . .
3
2.4. Situación Previa . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.5. Descripción General del Trabajo Realizado . . . . . . . . . . .
4
3. Trabajo Realizado
6
3.1. Bligoo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
3.1.1. Caracterı́sticas . . . . . . . . . . . . . . . . . . . . . .
6
3.1.2. Bugs y Errores de Traducción . . . . . . . . . . . . . .
8
3.2. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
3.2.1. Tipos de Pruebas . . . . . . . . . . . . . . . . . . . . .
9
3.3. Integración
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3.1. Sistema Servidor Local . . . . . . . . . . . . . . . . . . 13
3.3.2. Sistema Browser . . . . . . . . . . . . . . . . . . . . . 17
4. Conclusión
18
iii
1.
Resumen
El presente informe detalla el trabajo realizado en la Práctica Profesional
II, llevada a cabo en Blue Company S.A. Se trabajó con Bligoo2 , una red
social orientada a construir relaciones entre personas con los mismos intereses
o visiones.
En un principio el trabajo consistió principalmente en aprender a utilizar
la plataforma social junto con buscar bugs3 y revisar la traducción al Inglés.
Luego, la tarea a realizar fue investigar y analizar distintas plataformas
de testeo de código abierto que podrı́an ser utilizadas para revisar Bligoo.
Finalmente, se integraron las plataformas seleccionadas en un único sistema fácil de utilizar.
Como conclusión se puede decir que el área de testeo está bastante inmaduro, en donde las herramientas no son las mejores, debido a que son bastante
especı́ficas, no existe mucha documentación, y son difı́ciles de integrar y de
utilizar.
Junto con esto, también cabe destacar que los sistemas desarrollados no
son faciles de testear ya que, normalmente, no se programa orientado al testeo
y no se acostumbra a ir escribiendo pruebas de forma seguida, incremental
ni consistente.
2
3
http://www.bligoo.com/
Defectos en la plataforma.
1
2.
Introducción
2.1.
Lugar de Trabajo
Todo el transcurso de la práctica profesional fue realizada en la oficina de
Blue Company S.A., ubicada en Encomenderos oficina 11, en la comuna de
Las Condes, ciudad de Santiago.
Blue Company S.A. es una empresa dedicada a la consultorı́a y desarrollo
de aplicaciones Web 2.0. Se ha enfocado en el diseño y creación de tecnologı́as
que faciliten la comunicación, coordinación y colaboración entre las personas.
Bligoo, el principal producto de Blue Company S.A., es un sistema social
de sitios que ayuda no sólo a publicar o leer contenidos, sino que a construir
relaciones entre personas con los mismos intereses o las mismas visiones.
Blue Company S.A. ha crecido bastante a lo largo de sus años de vida.
Actualmente, la red social Bligoo (con menos de 1 año desde el lanzamiento
de la versión Beta) fue nominada en el Top 250 de los negocios prometedores, en la categorı́a de Consumers and Entertainment, según la publicación
AlwaysOn 4 de la Universidad de Stanford.
4
http://alwayson.goingon.com/permalink/post/26452
2
2.2.
Grupo de Trabajo
Blue Company S.A. no posee un área de Quality Assurance 5 ni de Testing 6
pero están muy conscientes sobre la importancia de aplicar estas técnicas
en el desarrollo de software. Es por esto que, en el perı́odo en el que fue
realizada la práctica profesional, Blue Company S.A. contaba con Nicolás
Fernández, Memorista de la Universidad Técnica Federico Santa Marı́a, que
trabajaba bajo la tutela de Alejandro Vera, Arquitector Senior de Sistemas,
para investigar, analizar y desarrollar una plataforma de testing y diseñar las
diferentes pruebas para someter a Bligoo.
Por lo tanto, la práctica profesional fue realizada en conjunto con Nicolás
Fernández y Alejandro Vera, y además fue supervisada por Emilio Davis,
Gerente de Tecnologı́a, y Paolo Colonello, Director.
2.3.
Equipo y Software Utilizado
Todo el desarrollo de la práctica profesional se hizo con un desktops de
desarrollo, cuya arquitectura es x86, se utilizó el servidor en donde corre la
plataforma Bligoo7 y un servidor local8 que tiene una réplica de la aplicación.
Como ya fue mencionado anteriormente, el trabajo giró completamente
en torno a la plataforma Bligoo, siendo éste el principal software utilizado.
5
Procesos planeados y sistemáticos para asegurar la efectividad de un producto o servicio.
6
Proceso de checkeo de un software, que verifica que éste satisface los requerimientos
y detecta errores.
7
http://www.bligoo.com/
8
http://www.bligoo.net/, accesable solo desde la intranet.
3
Para las herramientas de testing, se escogió trabajar con plataformas que
corran sobre Java, ya que se deseaba que estas corrieran en el servidor local
que ya soporta Java, o con plataformas que funcionen en navegadores de
internet. De esta forma no era necesario tener que instalar, configurar ni
administrar otros ambientes de desarrollo.
2.4.
Situación Previa
La plataforma social Bligoo no contaba con un sistema de testeo establecido, esto es debido a dos razones; Blue Company S.A. no cuenta con un
área de QA ni de Testing, y Bligoo no fue desarrollado orientado al Testing,
entonces no existı́a ningún tipo de prueba que revisara el funcionamiento de
éste.
2.5.
Descripción General del Trabajo Realizado
Al comienzo de la práctica, el trabajo consistió en aprender a utilizar la
plataforma Bligoo para ası́ saber y entender, a grandes rasgos, como funciona
y que tipo de cosas se pueden realizar. Básicamente, para poder tener una
“imagen” del sistema a gran escala. Junto con aprender a utilizar la red social
se buscaron bugs y errores de traducción al Inglés, ya que la versión Beta de
Bligoo habı́a sido lanzada recientemente9 .
A continuación, se investigaron y analizaron distintas plataformas de testeo de código abierto que podrı́an ser utilizadas en la validación de Bligoo.
9
Jueves 22 de Noviembre de 2007
4
Se buscaron herramientas para realizar pruebas unitarias, de integración, de
regresión, de interfaz gráfica y de carga. Esta investigación se realizó utilizando, principalmente, el sitio web Open Source Software Testing Tools 10 como
fuente de información.
Por último, se integraron las diversas plataformas seleccionadas en un
único sistema fácil de utilizar. Este sistema está basado en una Wiki, de tal
forma que las distintas pruebas pueden ser fácilmente agregadas definiéndolas
con comandos especiales al editar las distintas páginas. Además, el sistema es
suficientemente poderoso como para definir conjuntos de pruebas que pueden
ser ejecutadas a la vez o por separado. Dentro de la Wiki se implementaron
las pruebas unitarias, de integración, de regresión y de carga, mientras que
las pruebas de interfaz gráfica se realizan mediante extensiones instalables a
Mozilla Firefox.
10
http://www.opensourcetesting.org/
5
3.
Trabajo Realizado
Como ya fue mencionado anteriormente, todo el trabajo se realizó en
torno a Bligoo, por lo tanto, a continuación se explicará con un mayor nivel
de detalle la plataforma.
3.1.
Bligoo
Bligoo es un sistema social de blogs que ayuda no sólo a publicar o leer
contenidos, sino que a construir relaciones entre personas que tengan los
mismos intereses o las mismas visiones.
Actualmente, crear un blog es fácil, pero que otros lo descubran y lo lean
no lo es tanto. En este sentido, Bligoo tiene como principal desafı́o lograr que
otros lean lo que se escribe. Esto se logra recomendándole, a los usuarios,
artćulos en base a las etiquetas usadas, por lo tanto, las distintas personas
podrán saber que se escribió sobre algo que a ellos les interesa.
3.1.1.
Caracterı́sticas
Facilidad de Uso Bligoo no es distinto a las otras plataformas para mantener blogs si se sólo se visitan blogs de otras personas, se contestan
encuestas o se escriben comentarios, por lo tanto, no introduce una barrera en este aspecto. Pero, para la administración de un blog propio,
Bligoo cuenta con poderosas funciones que son utilizadas de manera
intuitiva, en particular, el diseño visual se realiza mediante el mouse
6
arrastrando y soltando cajas de contenido en distintas partes posibles.
Navegación Social Bligoo cuenta con un conjunto de funciones que permiten a las personas descubrir blogs a partir de otros, formando comunidades de blogs que se potencian entre sı́. Además, Bligoo realiza
recomendaciones de artı́culos interesantes en base a lo que la gente escribe, lee y recomienda. También, si es que uno no desea mantener su
propio blog, Bligoo permite encontrar blogs, artı́culos y personas que
son de importancia para este usuario en particular.
Privacidad Bligoo permite definir grupos de contactos con distintos privilegios en un blog, por ejemplo, limitar la lectura o escritura de comentarios a ciertos tipos de personas, manteniendo ası́ el nivel de privacidad
que el usuario desee. Además, Bligoo implementa un sistema de mensajerı́a interno para poder tener conversaciones más privadas.
Comunidades Bligoo permite definir comunidades dentro de la plataforma,
para que puedan realizar todo tipo de actividades y ası́ concentrar la
participación. Además pueden habilitar el sistema de registro, para que
sólo personas aceptadas puedan ingresar.
Estadı́sticas Bligoo permite ver una serie de indicadores de las visitas que
pasan por un blog creado por un usuario. No sólo muestra la cantidad de
visitas sino que además muestra un resumen de los perfiles, por ejemplo,
muestra histogramas con las edades, sexo, etc., junto con mostrar que
artı́culos son los más leı́dos, etc.
7
Blog Con respecto a los blogs, Bligoo permite publicar posts, agregar imágenes, videos, comentarios y encuestas.
3.1.2.
Bugs y Errores de Traducción
Luego de la creación de un blog, y de la investigación sobre como funciona, se encontraron errores de traducción en las siguientes secciones de la
plataforma:
En la página inicial (home).
En la página de registro.
En el mail de activación.
En la página de administración de un blog.
En la página de importación de información desde WordPress.
En la página de servicio DNS para un blog.
En la página de servicios.
En la página de estadı́sticas.
En la página de grupos de usuarios.
En la página de administración de comentarios.
En la página de invitación a otras personas.
8
En la página del perfil de un usuario.
También, varios tı́tulos de las páginas estaban mal, o bien decı́an “Bienvenido a Bligoo” en alguna página distinta de la inicial, o contenı́an tags
HTML11 .
Además, se encontró sólo un bug en la plataforma. Este era un problema cuando una persona tenı́a sólo un blog, en donde el sistema escribı́a un
mensaje de información como si tuviera más de uno.
3.2.
Testing
La segunda parte del trabajo consistió en investigar diversas plataformas
de testing que existen para una cierta cantidad de tipos de pruebas.
A continuación se detallan los tipos de prueba requeridos y las plataformas
investigadas.
3.2.1.
Tipos de Pruebas
Existen muchos tipos de pruebas, aunque varios de ellos son iguales solo
que se aplican en situaciones distintas. Las pruebas solicitadas para testear
la plataforma son las siguientes:
Pruebas Unitarias Es una forma de probar el correcto funcionamiento de
un módulo de código del programa. Se utiliza para asegurarse de que el nivel
11
En particular el tag span
9
más bajo de la plataforma funciona de forma correcta, es decir, los componentes indivisibles del programa funcionan por separado como se espera.
La idea es escribir casos de prueba por cada función o método no trivial
de forma que cada caso sea independiente del resto.
Debido a que existen muchas plataformas para pruebas unitarias para
Java, se decidió analizar las dos más importantes.
Cactus12 es un proyecto de Jakarta13 para realizar pruebas unitarias en
el lado del servidor (Servlets, EJBs, Tag Libs, Filters, etc). La idea es poder
crear nuevas pruebas de una forma simple y fácil. Está basado y extiende
JUnit.
JUnit14 es un framework, mantenido por Object Mentor, para escribir
y ejecutar pruebas automatizadas. Este framework es altamente utilizado
(posiblemente uno de los primeros frameworks de testing unitarios que se
escribió) y muchos otros proyectos han derivado de éste.
Si bien estos frameworks son bastante buenos, exigen que las pruebas sean
programadas en clases para luego ser ejecutadas por lı́nea de comandos. Para
poder implementar el sistema solicitado se tendrı́a que programar una interfaz
gráfica para poder escribir y ejecutar las pruebas sin tener que programar ni
compilar código.
12
http://jakarta.apache.org/cactus/index.html
Ofrecen diversas soluciones Java código libre
14
http://www.junit.org/
13
10
Pruebas de Integración Se refieren a las pruebas de todos los elementos
unitarios que componen un proceso, realizadas de una sola vez. De esta forma
se revisa que el proceso funciona correctamente de forma integral.
FitNesse15 es un servidor web, una wiki y una herramienta de testing,
basado en FIT (Framework for Integrated Test). FitNesse, más que una plataforma para pruebas de integración, es una herramienta muy completa para realizar diversos tipos de pruebas, principalmente pruebas de aceptación
(también llamadas pruebas funcionales o de caja negra), pero igual se pueden
crear pruebas unitarias y de integración.
La principal caracterı́stica de FitNesse es que no requiere que las pruebas
se programen, sólo basta con que las páginas en la Wiki se escriban de una
forma muy en particular y las pruebas son ejecutadas con un link en la Wiki.
Fit (y por lo tanto FitNesse) también utiliza JUnit como base. La diferencia es que tienen clases de pruebas genéricas (llamadas Fixtures) que
funcionan en base a parámetros.
Pruebas de Regresión Es cualquier tipo de prueba que intente descubrir
la aparición de un nuevo bug introducido por cambios realizados recientemente. Es decir, realizar pruebas unitarias y de integración a código que ha
sido recientemente modificado16 .
Debido a que este tipo de pruebas son, simplemente, las mismas anteriores
aplicadas en un contexto distinto, las plataformas de testing para este tipo
15
16
http://fitnesse.org/
Cuando se realizan optimizaciones o refactoring es conveniente realizar estas pruebas.
11
de prueba son las mismas que para pruebas unitarias y de integración.
Pruebas de Carga Son pruebas encargadas de sobrecargar una aplicación
para asegurarse de que soporte una cantidad determinada de clientes y de
que el tiempo de respuesta a éstos sea la deseada.
JMeter17 es otro proyecto de Jakarta encargado de medir el desempeño
de aplicaciónes en servidores. Realiza esto emulando muchos usuarios que
realizan diversas consultas y analiza el tiempo de respuesta. Tiene una interfaz gráfica y se pueden definir archivos de pruebas para ser ejecutados.
Además, se pueden ejecutar estos archvios de prueba por lı́nea de comandos
guardando los resultados en imágenes o archivos.
Pruebas de Interfaz Gráficas Son una de las pruebas más complicadas.
Estas aseguran que la interfaz gráfica funciona de la forma esperada. Como se
implementen estas pruebas depende mucho de la plataforma en donde corre
la aplicación a probar.
Selenium18 es una suite de herramientas para automatizar las pruebas
de interfaz para aplicaciones web. Su principal caracterı́stica es que corre en
varios navegadores web y que puede ser controlado por diversos lenguajes de
programación.
Si bien la herramienta permite la ejecución de pruebas en diversos navegadores y mediante diversos lenguajes de programación, esta funcionalidad
17
18
http://jakarta.apache.org/jmeter/
http://selenium.openqa.org/
12
no pudo ser implementada en la práctica. Esto debido a que se necesita que
el Selenium Core corra en un computador con el sistema operativo adecuado y que tenga interfaz gráfica, por lo tanto, no podı́a ser ejecutado en el
servidor local y los computadores no tienen Windows ni Mac OS instalado,
ası́ es que se redujo a Mozilla Firefox. Entonces se decidió no complicarse con
esta funcionalidad y utilizar el plugin para Mozilla Firefox para automatizar
instrucciones de usuario.
De esta forma, se separa la realización de pruebas de intefaz del resto de
las pruebas.
3.3.
Integración
Una vez investigadas las distintas herramientas para realizar las pruebas
requeridas, se decidió utilizar FitNesse, JMeter y Selenium.
El sistema integrado se compone de dos partes: una que corre en el servidor local, compuesto por FitNesse y JMeter, que realizan las pruebas unitarias, de integración y de regresión, y otra parte que corre en el navegador del
tester, compuesto por Selenium, que realiza las pruebas de interfaz gráfica.
3.3.1.
Sistema Servidor Local
Plataforma Base Para implementar el sistema en el servidor local se utilizó como base la plataforma FitNesse. La instalación era bastante directa,
sólo bastó con descomprimir el archivo descargado y modificar el script de
inicialización para que no pida parámetros. Es decir, la herramienta era un
13
servidor standalone en donde sólo es necesario ejecutarlo y se pondrá a recibir
solicitudes en un puerto en particular (en donde funcionará la Wiki).
Una vez la Wiki haya sido iniciada y se puedan editar páginas, uno puede
empezar a crear pruebas. La plataforma está hecha de tal forma que las
pruebas quedan definidas en las páginas de la Wiki (todas las páginas tienen
un link para ejecutar las pruebas definidas dentro de ésta).
Una caracterı́stica de esta Wiki es que todo el texto dentro de la página
es ignorado al momento de ejecutar las pruebas, excepto por las tablas. La
información en las tablas debe estar cuidadosamente estructurado para poder
ejecutar las pruebas.
Para crear una nueva prueba se deben realizar los siguientes pasos:
1. Todas las clases que se desean testear deben estar en una carpeta en
particular. En la página de la Wiki se puede incluir esta dirección al
classpath escribiendo un comando especial.
2. Escribir una clase que extienda a algun Fixture (clases básicas de testing) y escribir los métodos parametrizados para validar la clase. Estos
métodos deben no deben ser absolutos, sino que deben recibir argumentos para validar que el método que se desea chequear funciona
bien. Luego, en la Wiki, se establecen los valores de estos parámetros.
De esta forma basta con diseñar las pruebas para luego agregar nuevos
casos de prueba sin tener que editar ni recompilar el código.
Esta clase debe ser compilada y almacenada en una carpeta definida.
14
Un ejemplo de esta clase a continuación:
1
import f i t . ColumnFixture ;
2
3
public c l a s s B i c y c l e T e s t extends ColumnFixture {
4
5
protected B i c y c l e b ;
6
public i n t s p e e d ;
7
8
public B i c y c l e T e s t ( ) {
9
b = new B i c y c l e ( ) ;
}
10
11
public i n t speedUp ( ) {
12
13
b . speedUp ( s p e e d ) ;
14
return b . s p e e d ;
}
15
16
public i n t a p p l y B r a k e s ( ) {
17
18
b . applyBrakes ( speed ) ;
19
return b . s p e e d ;
}
20
21
22
}
3. Escribir una tabla, en la Wiki, siguiendo la estructura impuesta, es
decir, un código parecido al siguiente:
1
! | BicycleTest |
2
| s p e e d | speedUp ( ) | s p e e d | a p p l y B r a k e s ( ) |
3
|10|10|0|10|
4
| −20|10| −20|10|
5
|40|50|20|30|
6
|80|110|150|0|
15
Este código establece la variable de instancia speed como 10 y luego
ejecuta el método speedUp() y compara que el resultado retornado sea
igual a 10. Y ası́ sigue por cada columna en cada fila. Se puede notar
que se desea validar que aumentar la velocidad un número negativo o
frenar un número negativo haga nada.
Luego de realizar la prueba, la página pone las celdas cuyo resultado
está bien en verde y en rojo en caso contrario.
Extensión Para realizar las pruebas de carga fue necesario crear un nuevo
Fixture que puede ser llamado desde la Wiki. Este Fixture, llamado JmeterFixture, no necesita ser extendido por otra clase para funcionar.
Para crear una nueva prueba de carga sólo se debe crear una tabla con la
siguiente forma:
1
! | JmeterFixture |
2
| i n i t | f i l e s / s t r e s s /p |
3
| start | |
4
| o ut pu t | |
5
| graph | |
En donde init es la ruta al archivo de configuración que tiene la definición de la prueba creada con JMeter. Luego, en la celda a la derecha de
start aparece información sobre el comando JMeter ejecutado y en output
aparecerá la información de salida de la ejecución del comando. Finalmente,
en graph aparecerá el gráfico de resultado de la prueba de carga.
Otra caracterı́stica importante de FitNesse es que permite crear SubWi-
16
kis, es decir, páginas dentro de págias. Cuando se realiza esto, la opción
de ejecutar una Suite de Tests aparece. Cuando se selecciona la opción, se
ejecutan todas las pruebas de la página y de las SubWikis dentro de ésta,
resumiendo los resultados.
También, captura las excepciones mostrándolas en la página.
3.3.2.
Sistema Browser
El sistema que corre en el navegador es el Selenium IDE. Este plugin es
una plataforma de testing completa y muy fácil de usar.
La creación de pruebas puede ser escribiendo los distintos scripts o grabando las acciones directamente desde el navegador web, es decir, uno empieza a grabar y luego hace click en las distintas partes, escribe en los campos
de texto, etc.
En cualquier parte de la creación de las pruebas se pueden agregar asserts 19 para ir comprobando que la salida del navegador es la esperada.
Además tiene otras caracterı́sticas, como establecer breakpoints en los
scripts de pruebas y guardar las pruebas en archivos HTML, scripts de Ruby,
y otros formatos.
En conclusión, el sistema por sı́ sólo funciona suficientemente bien para
cumplir con los requisitos.
19
Acciones que comprueban que el estado sea el requerido.
17
4.
Conclusión
En el transcurso de la práctica profesiona se pudo ver como funciona una
empresa dedicada al rubro de la Computación, lo que fue una experiencia
muy valiosa. El ambiente laboral en Blue Company S.A. era muy agradable
y cómodo20 con una excelente disposición de todas las personas.
Se aprendió sobre los distintos tipos de pruebas y, más importante, se
pudo ver la relevancia del testing en plataformas grandes.
Finalmente, se puede decir que el área de testeo está bastante inmaduro. No existe mucha información al respecto ni buenas prácticas (aparte del
desarrollo orientado al testing), además, las plataformas de testeo no son las
mejores debido a que son bastante especı́ficas, tienen muy poca documentación, difı́ciles de integrar y de utilizar.
En particular, FitNesse, siendo una aplicación de código lbire, no tenı́a
documentación sobre el código ni en el código ni como estaba implementado,
es decir, no explicaba la interrelación entre los distintos métodos y clases,
los patrones de diseño utilizados, etc. Entonces se tuvo que leer y seguir
manualmente el orden de las instrucciones ejecutadas para poder entender
como funcionaba y como agregar nuevos componentes.
Junto con esto, también cabe destacar que los sistemas desarrollados no
son faciles de testear ya que, normalmente, no se programa orientado al testeo
y no se acostumbra a validar de forma seguida e incremental, haciendo que
20
Asistı́ a la celebración de Fin de Año en la casa en Tunquén de Ingrid Antonijevic,
Presidenta del Directorio.
18
el diseño de las pruebas sea muy complicado.
Por último, se aprendió que uno debe desarrollar siempre teniendo en
cuenta que hay que testear el código y que alguien, en algún momento ya sea
tarde o temprano, volverá a leer el código.
19