Pruebas automatizadas en Interfaz de Usuario

En una entrada anterior, escribía sobre la existencia de SeleniumIDE, un plugin para Firefox con el cual podemos ejecutar pruebas en la interfaz de usuario de una manera un poco más automatizada.

En realidad puede ser muy útil, tiene muchos comandos que sirven para simular casi todo lo que un usuario humano podría hacer.

Por ejemplo, el siguiente video que hice, muestra una prueba muy sencilla pero en un Sistema real implementado en ambiente productivo (claro, la prueba fue hecha en un ambiente de test).

La prueba es tan sencilla que solo consta de comandos click, doubleClick, select, y un assertConfirmation el cual sirve cuando la aplicación lanza un cuadro de confirmación con JavaScript y con este comando Selenium da por hecho que debe aceptar la confirmación.

En YouTube existen algunos pocos tutoriales que pueden servir de inicio.

Desarrollo Rápido de Aplicaciones con Oracle

INTRODUCCIÓN


Cuando escuchamos Oracle, a la gran mayoría nos viene a la mente esa Base de Datos Relacional que tiene fama de ser la mejor de entre las actuales, sin embargo, hace algunos días conocí "Oracle Application Express" conocida como APEX, la cual es una Herramienta para el Desarrollo Rápido de Aplicaciones (RAD) que utilizan una Base de Datos Oracle y se basa en una interfaz web, lo mejor de esto es que se puede descargar gratuitamente y utilizarse incluso sobre Oracle DataBase Express Edition. Con APEX podemos crear rápidamente aplicaciones web que hagan uso de una base de datos Oracle, incluso con APEX podemos conectar con servicios web.


Voy a mostrar de una forma muy rápida de como crear un sencillo formulario de registro, por lo que tenemos dos formas de seguir este tutorial,

1. Descargar e Instalar localmente APEX, lo que incluye también tener instalado Oracle DataBase. Queda fuera de este tutorial los pasos de instalación y configuración.
2. Crear una cuenta gratuita en http://apex.oracle.com , la cual esta sujeta a una previa aprobación. Al final de los pasos de la creación de la cuenta, se te pedirá una justificación por la que deseas obtener una cuenta demo, basta con poner alguna palabra como "education", que en mi caso, la cuenta fue aprobada casi automáticamente.

LA INTERFAZ WEB DE APEX

Como lo comentamos, APEX esta basado en una interfaz web y con muy pocas líneas de código, podremos tener una aplicación web profesional.

Una vez creada nuestra cuenta, veremos una interfaz similar a la imagen. Podemos crear y administrar aplicaciones web, navegar por las tablas contenidas en nuestro esquema, ejecutar sentencias SQL, administrar usuarios, servicios y monitorear actividad, etc.

En este momento, nos centraremos en la opción "Application Builder"

CREANDO LA APLICACIÓN

Seleccionando la opción Application Builder,

• Click en botón Create
• Seleccionar DataBase en el Application Type
• Crearemos una aplicación desde cero, seleccionando From Scratch
• Tecleamos un nombre para nuestra aplicación y un ID que ya nos da por defecto, así como seleccionamos el nombre del Schema a utilizar.
• Con esto ya tenemos creada una aplicación, sin embargo, una aplicación esta compuesta por Pages, por lo que ahora debemos seleccionar el tipo de página que deseamos. Cabe resaltar dos opciones,

• Form: Creará un clásico formulario donde existirán cajas de texto, introducimos los valores y damos click en guardar.

• Tabular Form: Creara como su nombre lo indica, un formulario tabular, es decir, nos mostrará los datos existentes en una determinada tabla de base de datos en forma tabular y con la posibilidad de actualizar directamente los datos que deseamos.

• Seleccionamos Form y en la parte de abajo el nombre de la tabla sobre la cual basaremos el formulario. Por el hecho de crear nuestra cuenta demo en APEX, tenemos una serie de tablas ejemplo, dos de ellas son EMP y DEPT, seleccionamos DEPT por ser la más sencilla y click al botón Add Page.
• Click en Siguiente.
• Seleccionamos No Tabs y click en Next.
• Seleccionamos que NO deseamos copiar componentes compartidos.
• Una parte importante de las aplicaciones web es un sistema de autenticación de usuarios, APEX nos proporciona ya unos mecanismos muy sencillos de utilizar, seleccionaremos las opciones como lo muestra la imagen,

• Ahora debemos seleccionar un Theme para nuestra aplicación. Afortunadamente también tenemos posibilidad de crear temas propios. En este caso, yo seleccionaré el Theme 20. Click en Next
• Finalmente verificamos que la información sea correcta y damos click al botón Create.

Ya tenemos la aplicación creada y podemos ver que esta compuesta de dos página, una de ellas es la página que creamos en los pasos anteriores y la otra es la página de autenticación que en la imagen aparece como "101 - Conectar" debido a la mala traducción :)

• Damos click sobre el ícono 1-Dept
• En la columna Page Rendering damos doble click sobre P1_DEPTNO

Editamos su propiedad Display As.. y seleccionamos Text Field. Guardamos los cambios.

Regresaremos a la pantalla anterior y solo resta presionar el botón de Run. Se nos mostrará como primer página la autenticación de usuario. Por defecto, el usuario existente es el mismo que el de nuestra cuenta demo de APEX.

Una vez que nos hemos identificado, podremos ver el pequeño formulario de registro de Departamentos, que basamos en la tabla DEPT de la base de datos Oracle que ya existía al momento de crear nuestra cuenta demo.

Podemos especificar que el Deptono sea una secuencia o un trigger para no tener que insertarlo manualmente.

En otro tutorial escribiré como hacer otras cosas más interesantes, pero este fue un primer acercamiento a esta buena herramienta de Oracle que nos puede ayudar a realizar ciertas cosas de manera muy fácil.

Mi primer texto en Illustrator CS5

Bueno, algo que siempre quise aprender desde que comencé en esto del desarrollo de software, fue algún programa de dibujo vectorial como Illustrator. Soy todo menos diseñador, pero creo que con un poco de práctica puedo mejorar significativamente!

Les comparto este video de Youtube donde muestra como poner nuestro nombre con Illustrator agregando algunos degradados y transparencias. No me quedo como en el video, pero espero ir mejorando!

Y aquí el resultado :(

CMS: Java México

javamexico

La comunidad de Java México, inicio hace unos meses el desarrollo de un Administrador de Contenidos (Foros, Blogs, Bolsa de Trabajo, etc). El proyecto será OpenSource (GPL v3) y estará desarrollado sobre las tecnologías:

• Tapestry 5
• Spring 3
• Hibernate

He descargado e instalado el proyecto, y desde luego que la idea es participar como desarrollador. Como acertadamente lo comentan, es una buena opción para hacer crecer el CV. Tapestry es un Framework para el desarrollo MVC, tipo Struts, pero hasta donde puedo ver, es mucho más simple y elegante, así que es una gran oportunidad para aprender. Aquí, Enrique Zamudio publica un introducción de Tapestry  dividida en 5 partes para despertar la curiosidad a muchos desarrolladores que no conocíamos este framework.

Los invito pues a darse una vuelta por la comunidad Java México y a participar en este proyecto, tanto si eres un desarrollador novato, es una buena oportunidad para crecer en conocimientos y participar de algún modo.

Aprendiendo Lean Software: Eliminar el Derroche

ANTECEDENTES
Cuando estudiaba el 6to Semestre de la carrera, entré a laborar a una pequeña fabrica de software en Pachuca, Hidalgo (México). De 2 años para acá comencé a interesarme en temas más específicos de Ingeniería de Software pasando por la Administración de Proyectos, Casos de Uso, hasta metodologías y procesos como MoProSoft y Personal Software Process. Confieso que desde un inicio nunca pude comprender al 100% estas prácticas de métodos formales, sin embargo las acepte en un inicio. Más adelante la relación entre estas prácticas y yo fue insostenible y las abandone para dar paso a la filosofía ágil de la cual sencillamente estoy encantado.

A partir de aquí, inicia una serie de comentarios que expresan mi opinión personal (muy posiblemente equivocada) sobre bibliografía y material que voy estudiando con el objetivo de crear notas y compartirlas principalmente con estudiantes de carreras afines.

¿QUÉ ES LEAN SOFTWARE DEVELOPMENT?
Comparto con ustedes un video-presentación que realizó Emilio Osorio donde explica lo que es Lean Software y sus principios básicos. Debajo de la presentación, comparto mi poca experiencia, opiniones personales y posiblemente no tan acertadas pero que eso es lo que hace tan valioso a la filosofía ágil, que no existe una receta a seguir y que el proceso se debe amoldar según el entorno.

¿Qué es y por qué funciona el Lean Software Development? from SG Campus on Vimeo.

PARA INICIAR...

Debo comenzar diciendo lo que digo siempre que hablo de metodologías formales. 

Martín Fowler, un Gurú en el mundo de Java comenta en su artículo The New Methodology, que las metodologías formales basan sus principios en otras Ingenierías como la Civil y la Mecánica, en donde la mayoría de sus problemas, son susceptibles de un análisis matemático y modelado previo a la construcción. Los métodos formales y nuestros maestros nos enseñaron que en el Software la mejor forma de hacer las cosas bien, son hacerlas a la primera! El error de la Ingeniería de Software tradicional es tratar al desarrollo de Software como un fenómeno predictivo de otras ingenierías, entendiendo como predictivo aquello que es susceptible de un modelado y de un análisis matemático para predecir el comportamiento de un Sistema al aplicar una fuerza.

Pueden leer este otro artículo que escribí titulado ¿Por qué fracasan los proyectos de SW?... Este artículo lo considero bien documentado, y es sencillamente una recopilación de ideas que varios autores a nivel mundial han escrito. 

PRINCIPIO 1: ELIMINAR EL DERROCHE

Como desarrolladores estamos tentados a comenzar por desarrollar aquellos módulos más fáciles o más bonitos ó con más reto personal, aunque éstos no agreguen un valor de negocio al usuario, , peor aún, desarrollamos cosas que el cliente no pide. Por ejemplo si debemos desarrollar un Sistema de Reporte de Ventas, muchas veces como desarrolladores comenzamos desarrollando la funcionalidad que grafique los datos, aunque quizá el cliente solo pidió tabularlos, peor aún, desde la filosofía ágil, nosotros debemos entregar funcionalidad cada 2 o 3 semanas, desde esta perspectiva quizá hemos omitido el desarrollo de la autenticación y autorización al sistema y hemos dado paso a desarrollar funcionalidades que no son prioridad en ese momento.

Alguien podría preguntarse ¿Y el desarrollar la funcionalidad para que grafique datos no es algo bueno?... Seguro que sí, pero si el cliente inicialmente no lo pidió, debemos mejor entregar una pieza de software funcional y usable con el que el cliente/usuario comience a trabajar. El usuario, al ver el sistema en funcionamiento seguramente pedirá los datos graficados y más funcionalidad extra, pero en ese momento, él ya estará sacando provecho al Sistema.

Finalmente en este momento puede venir una pregunta más para el lector, con lo anterior ¿no estamos propiciando a que el cliente pida y pida de forma insaciable nuevos requerimientos?... Desde luego,... Pero entonces el proyecto no será costeable para la empresa!... Bueno, desde la perspectiva tradicional efectivamente el proyecto no será costeable, saldrá de sus límites y no será un buen negocio para la empresa que desarrolla el Software, pero desde la perspectiva ágil sencillamente se pagara justo lo que se desarrolla con el plus de que tendremos a un cliente bastante contento. A diferencia de los métodos formales, los métodos ágiles te impulsan a entregar funcionalidad cada 2 o 3 semanas, de tal forma que el costo del desarrollo no se va sobre el proyecto, sino sobre funcionalidad. El cliente no pagará un Sistema, más bien pagará funcionalidad hasta completar un Sistema, de esta forma, si el cliente posteriormente agrega más requerimientos sobre algo ya desarrollado, podremos justificar más fácilmente un costo extra con el plus que el cliente al estar contento no tendrá tantos inconvenientes en pagar por mejorar o agregar funcionalidad extra de algo que ya esta usando. En el caso de una mejora, incluso la misma empresa que desarrolla, puede pensar en no realizar un cobro extra.

Como lo dice Emilio en su presentación, el derroche será todo aquello que no agrega valor al negocio del cliente. No debemos confundir "Eliminar el derroche" con no desarrollar o proponer requerimientos que tengan un valor agregado al negocio del cliente, por el contrario, siempre es buena idea dar un valor agregado al negocio del cliente, una ventaja competitiva que lo ponga un paso adelante sobre sus competidores. Debemos eliminar documentación innecesaria como Diagramas UML, planeaciones en gantt, decenas o cientos de hojas de Casos de Uso.

Lo anterior resulta muy delicado dado que el RUP y las herramientas como UML son tan aceptadas en nuestra industria, sería muy difícil de entender y aceptar que el 90% de los diagramas de UML son en su mayoría inútiles.  ¿Qué tan similares son los diagramas de clases realizados al inicio con las clases que se tienen al término del proyecto? La verdad es que son muy diferentes. Si alguien en este punto esta pensando que el Diagrama de Clases es útil por que nos da una vista rápida de como esta construido el sistema, obviamente que desconoce de las herramientas de Ingeniería inversa que nos ayudan a generar diagramas en base a las clases de un Sistema. Existen numerosos autores que ponen en duda la utilidad de UML, muchos otros autores reconocidos como Craig Larman conscientes de los puntos débiles del RUP pero convencidos de su utilidad defienden su utilización desde un punto de vista ágil. Para efectos de este punto, podemos leer un artículo de Bertrand Meyer (el creador del Lenguaje Eiffel) titulado "UML: The Positive Spin" donde verdaderamente se burla de lo absurdo que puede resultar el UML. De igual forma, podemos leer "Death by UML Fever" donde se explica que verdaderamente tenemos una Fiebre de UML. En conclusión podemos decir que UML puede resultar una buena herramienta de modelado post-development, como base para generar documentación para el mantenimiento del Sistema, pero no resulta tan bueno para generar documentación de requerimientos y análisis.

Son muchísimas cosas que agregan un derroche a nuestros proyectos, y considero yo que para este punto, solo falta un poco de sentido común para detectarlo.

Más adelante continuaré con los principios restantes de Lean Software, mientras tanto debí seguir leyendo el libro de Mary Poppendieck que me regalaron.

Saludos!