Chess - antoniomartel.com

Archivos de Autor: antoniomartel

Pruebas automatizadas con Selenium

En mi última entrada hablaba de Selenium y como, gracias a herramientas como ésta, había conseguido reducir el número de errores en las aplicaciones en las que se ha utilizado.

En la entrada de hoy describiré con un ejemplo uno de los múltiples usos que puede tener un automatizador de navegadores como Selenium. Para ello utilizaré la web RottenPotatoes construido con Ruby on Rails sobre Heroku, la plataforma de aplicaciones en la nube que se utilizó en el curso CS-169.1x Software as a Service (a propósito, curso muy recomendable de edx.org)

Si quisiéramos probar una de las funcionalidades que acabamos de desarrollar en nuestra aplicación, podríamos utilizar Selenium IDE (plugin para Firefox) y escribir o grabar un pequeño test que probase que esta funcionalidad ha sido correctamente implementada.

Pongamos como ejemplo que queremos probar el nuevo filtro de películas por clasificación. Para ello, con Mozilla Firefox abierto, ejecutamos el plugin Selenium IDE y creamos un nuevo test:

Abrimos la página a testear con el comando Selenese:

 

Command Target
open http://stormy-beyond-4091.herokuapp.com/movies

 

con lo que obtendríamos una nueva pestaña con nuestra aplicación:

desmarcamos los botones G, PG-13 y R y pulsamos el botón ‘Refresh’ con los siguientes comandos:

 

Command Target Value
uncheck id=ratings_G
uncheck id=ratings_PG-13
uncheck id=ratings_R

 

check
id=ratings_PG
clickAndWait
id=ratings_submit
Con estas acciones debemos haber obtenido una página donde se muestran sólo las películas para todos los públicos (PG). Verificamos que sólo se muestran las películas ‘Los increibles’ y ‘En busca del arca perdida’. De paso comprobamos también que en los resultados no se ha devuelto por error la película ‘2001: Odisea del espacio’:

 

Command Target Value
verifyTextPresent The Incredibles
verifyTextPresent Raiders of the Lost Ark
verifyTextNotPresent 2001: A Space Odyssey

 

Además comprobamos también que el número de películas mostradas es de sólo dos. Para ello comprobaremos que en la tabla devuelta hay 3 filas (2 <tr> para las dos películas y 1 <tr> adicional para la cabecera de la tabla):

 

Command Target Value
verifyXPathCount //table//tr 3

 

Un test como éste puede ser creado para cada nueva funcionalidad que desarrollemos y ser incluida posteriormente junto al resto de tests que hayamos creado a la batería de pruebas que realiza el servidor de Integración Continua (Jenkins por ejemplo). De esta forma los test son pasados cada noche, o a la hora en que lo programemos y si hubiésemos subido al Subversion un código que hace que alguna funcionalidad muestre un error, el servidor de Integración Continua nos avisará inmediatamente.

Les dejo el test disponible para su descarga en el siguiente enlace: Selenium Test

Si te interesa saber más sobre la certificación, estimaciones, ventajas y desventajas de Scrum o cómo gestionar proyectos de forma ágil quizás te interese mi libro: Gestión práctica de proyectos con Scrum.

Si en cambio quieres poner a prueba tus conocimientos de Scrum haciendo un test en español antes de tomar el examen de scrum.org aquí tienes el Test no oficial de Scrum (aplicación realizada con Ruby on Rails y desplegada en Heroku).

Ventajas y desventajas de SCRUM (II)

No quisiera convertirme en uno de esos evangelistas de lo Ágil que pregonan por doquier lo bueno y moderno que es ser Ágil. He puesto en práctica alguna de estas técnicas y he obtenido buenos resultados con ellas, así que en este post les voy a contar la parte positiva de una metodología como SCRUM (post obligado después de hablar sobre las desventajas de SCRUM en una entrada de mayo)

Me voy a centrar en las ventajas de una de sus características fundamentales: Las Entregas Periódicas. Nuestro cliente recibe cada poco tiempo una entrega de lo que estamos haciendo. Esto le va a permitir:

Que comience a usar ya su producto 

El cliente puede decidir poner en marcha el producto aún cuando no están todas las características construidas. Cuando se haya desarrollado el 20% de las nuevas funcionalidades, que son las que serán usadas el 80% del tiempo, el producto puede comenzar a andar.

Con el feedback de los usuarios podríamos darnos cuenta de que hay nuevas funcionalidades que son mucho más importantes que el 80% de las tareas que aún teníamos por hacer en la pila del producto. Alguien puede decirnos «pero si el borrador del nuevo decreto ya no exige la entrega de la autorización firmada» o «en realidad lo que necesitamos es un botón para poder cancelar el trámite» (dos experiencias reales)

Que pueda decidir hacia dónde vamos

Los negocios cambian, las necesidades varían, nuevas normativas aparecen. Lo que era muy importante cuando se firmó el contrato podría no serlo meses después. El cliente puede decidir los nuevos objetivos, qué hacer en el nuevo Sprint y en qué debemos trabajar para la próxima entrega.

Divide y vencerás

Las tareas titánicas requieren de esfuerzos del mismo orden. Si debemos entregar solo una parte de esa tarea cada dos semanas la carga se nos hará más llevadera. Tareas más pequeñas y abordables harán que nos parezca menos difícil el trabajo y que con cada entrega tengamos la sensación de estar dando un nuevo paso hacia la meta final.

Menos sorpresas

Viendo crecer el producto poco a poco todos vamos a tener una idea de qué estamos haciendo con él y si nos va a ser útil o no. Además, con relativa exactitud sabremos a qué ritmo se están entregando cosas y cuánto tardaríamos en tenerlo acabado. ¿Es necesario tomar medidas para corregir el rumbo? Lo sabríamos en semanas.

Si te ha gustado este post, puedes encontrar más contenidos que expliquen Scrum de forma práctica y desde su base en mi libro en Amazon Curso práctico de Scrum: Algo más que teoría.

Libro en Amazon: Curso práctico de Scrum: Algo más que teoría
Libro en Amazon: Curso práctico de Scrum – Algo mas que teoría

Ponencia en las IV Jornadas de Sostenibilidad en Canarias

El pasado jueves tuve el honor de dar una ponencia sobre la Fase 2 del Sistema de Información de Residuos de Canarias (GUIRRE) en las IV Jornadas de Sostenibilidad en Canarias dentro de las actividades del Gobierno de Canarias por el Día Mundial del Medio Ambiente.

GUIRRE es un proyecto bastante especial para mí por varias razones. La primera de ellas porque fue la primera vez que ejecutamos un proyecto utilizando integración continua (Jenkins) y tests con Selenium IDE.

Al inicio del proyecto, antes de comenzar a programar, definimos una sección ‘Cómo probarlo’ para cada funcionalidad a desarrollar. Grabamos tests con Selenium, siguiendo lo indicado en esta sección, que servían para demostrar que la nueva característica funcionaba correctamente. Si encontrábamos un bug, grabábamos también un test que lo reprodujese. Cuando el test dejaba de marcarse en rojo, ya lo habíamos arreglado.

Cada dos semanas, grabábamos todos los test del Sprint en una ‘suite’ de Selenium. Cada noche, el servidor de integración continua, Jenkins, ejecutaba esta suite y las suites de todos los Sprints anteriores e informaba si había habido errores. Si la mañana anterior un programador había modificado código que afectaba a las funcionalidades desarrollada hace unos meses, Jenkins nos mostraba unos nubarrones muy oscuros.

La otra razón por la que GUIRRE es un proyecto muy querido para mí es porque se logró terminar por debajo de lo presupuestado (sí estos proyectos existen) a pesar de asumir totalmente el coste del aprendizaje con Jenkins y Selenium y de que el presupuesto era muy ajustado. Todo un reto.

Les dejo más abajo una fotos del acto y un enlace a la ponencia que presenté. Espero que les sea de su interés.

Boeing y los cirujanos

Atul Gawande, cirujano de un prestigioso hospital, estaba interesado en mejorar la cifra de incidencias y complicaciones que surgen habitualmente en las mesas de operaciones, así que se le ocurrió preguntar cómo lo hacían ellos a otro tipo de profesionales completamente diferente pero del que también dependen muchas vidas.

Durante una visita a Boeing, Gawande preguntó cómo conseguían que todo funcionara correctamente en su trabajo diario. La respuesta fue sencilla: Usaban checklists. Una y otra vez, los pilotos se apoyaban en checklists, no sólo para el despegue y el aterrizaje en condiciones normales sino también para las situaciones de crisis en condiciones de emergencia.

De vuelta a su hospital, Gawande preparó una lista de verificaciones que podía ser comprobada en 2 minutos y la implementó en las salas de operaciones de ocho hospitales. Se aseguraron de que la lista también incluía puntos básicos: Había suficiente sangre disponible o quedaban antibióticos en cantidad adecuada para la operación.

El resultado fue sorprendente, obtuvieron mejores resultados, mejores resultados de forma masiva. Se aseguraron de evitar errores básicos y de no cometer fallos estúpidos. Ahora, incluso la Organización Mundial de la Salud define listas de verificación para la seguridad de los pacientes.

Una simple hoja de papel o archivo MS Excel con una lista de puntos a revisar pueden evitar muchos errores y mejorar la calidad de lo que hacemos. Incluso SCRUM tiene una lista para que auto-comprobemos el nivel de su implementación en nuestra organización.

No existe solo una SCRUM Checklist, existen muchas. La que más me gusta es la SCRUM Checklist de Henrik Kniberg, el autor de SCRUM y XP desde las trincheras. Es muy útil la forma en la que separa lo fundamental y lo esencial de lo solo recomendado en la implementación.

Aún no puedo marcar todas las casillas de esa lista. Como indica Henrik, ¡tendré cuidado con la policía de SCRUM!

Al otro lado del charco

Estando tan cerca es increíble lo poco que sabemos de lo que se está haciendo justo aquí al lado, cruzando el charco.

Hace unas semanas que he descubierto los blogs de Carlos Ble y de Raúl Herranz. Mucho que leer ahí y todo muy bueno.

Les pongo algunos ejemplos: Open Agile Space en Tenerife, junio 2012-2013, Preparación de la certificación PMI-ACP y. como no, algo sobre el Triángulo de Hierro.

Disfruten de la lectura.