Testing con Selenium

Selenium es una herramienta para hacer testeo automático de aplicaciones web.

Con un servicio propio, que podemos arrancar en cualquier máquina, y nuestro lenguaje de programación favorito, podemos crear tantos casos de prueba como queramos una sola vez, y ejecutarlos todas las veces necesarias. La utilidad es obvia, ejecutar periódicamente pruebas de la aplicación, para asegurar la integridad del sistema, y todo, de manera automática.

La gran virtud de Selenium, es su extrema facilidad de uso, como ejemplo (en Java y Firefox) solo tienes que seguir estos cuatro pasos para hacerlo funcionar.

1. Descárgate el zip de Selenium y descomprímelo en una carpeta (p.ej. c:/selenium).

2. Arranca el servidor Selenium:
java -jar c:\selenium\selenium-remote-control-0.8.1\server\selenium-server.jar

3. Asegúrate que la JVM y el ejecutable del Firefox, están en el PATH del sistema.

4. Compila y ejecuta la siguiente clase Java.

package test;

import com.thoughtworks.selenium.DefaultSelenium;
import com.thoughtworks.selenium.Selenium;

public class Maintest {

private static Selenium sel;
public static void main(String[] args) {

sel = new DefaultSelenium("localhost",
4444, "*firefox", "http://www.google.com");
sel.start();

sel.open("http://www.google.com/webhp");
sel.type("q", "hello world");
sel.click("btnG");
sel.waitForPageToLoad("5000");
System.out.println(sel.getTitle());
}
}

Este ejemplo, lanza una búsqueda en google, y saca el título de la pagina de resultados.

Para más información sobre Selenium, te aconsejo que veas el tutorial del RC de Selenium, y que veas el Javadoc incluido en el zip que te descargaste.

Selenium también dispone de un IDE para Firefox que te permite grabar macros simplemente navegando por la web, y ejecutarlas de nuevo posteriormente.

servido por jarroyo 1 comentario compártelo

La mejor documentacion, un código limpio

Todos los programadores nos hemos quejado, y lo seguiremos haciendo, de la falta de documentación del código fuente que heredamos. Casi con toda seguridad, otro programador, se quejará exactamente de lo mismo si revisa nuestro código, y un tercero del del segundo, y otro y otro ...

Documentación puede haber mucha: del API, del diseño y arquitectura, comentarios en el propio fuente ... pero seamos sinceros, cuesta mucho trabajo programar y hacer la documentación a la vez. Alguien podría decir, "pues programa, y luego dedicas una fase a documentación". Es posible, pero aun pasando por alto la falta de tiempo habitual, la calidad de la documentacion puede bajar debido a que ha pasado cierto tiempo desde la codificación.

El último handicap de la documentación es, lo rápidamente que se queda desfasada ante cambios del programa, volviéndose inservible.

Desde mi pundo de vista, no hay mejor documentación que un código limpio. Él hablará por si solo de las funcionalidades que implementa, siempre estará actualizado, y requiere un esfuerzo adicional menor.

Para ayudar a este código limpio, y a facilitar la herencia de fuentes de programadores de la misma empresa, toda la organización debe adoptar unos estándares de desarrollo comunes, de manera que una misma cosa, la hagan igual en todas partes, para que a simple vista pueda identificarse lo que se ve, y cada cual sepa buscar lo que necesita en el lugar adecuado.

servido por jarroyo sin comentarios compártelo

La informática es así

Pero, ¿eso no se podía haber previsto?. Esta frase la he escuchado miles de veces cuando un software desarrollado se comporta de una manera inesperada. Las personas que no están involucradas en la construcción de la aplicación, se preguntan como es posible que tal o cual comportamiento no se haya pensado de antemano, y que por tanto ahora haya que dedicar un tiempo valioso a corregirlo.

Lo primero que hay que saber, es que la informática en general, y el desarrollo de software en particular, no es una ciencia exacta. No podemos ni debemos compararla con otras ingenierías, en las que todo puede calcularse y analizarse de antemano. Comparado con cualquier proyecto en el que se construya algo, no hay nada tan difuso, abstracto, impredecible y variable como una aplicación informática. En la mayoría de los casos, por no decir en todos, la persona que solicita el sw, no sabe lo que quiere, ni como lo quiere. Partiendo de esta base, ¿como se pretende que salga bien a la primera?.

Lo que quiero dejar claro es que esto no es un defecto, es solo una característica, y que por tanto debe ser asumida por todas las partes, desarrolladores y usuarios.

Los "fallos", aunque realmente esta palabra no es la más apropiada, deben gestionarse como un aspecto más del proyecto. Los usuarios, por su parte deben comprender que esto seguirá ocurriendo se pongan como se pongan, pero que su colaboración para detectarlos e informar al equipo de desarrollo es indispensable. Los programadores, por su parte, no deben ver dichos "fallos" como algo personal, es decir, como algo que han hecho mal profesionalmente, deben verlo simplemente como lo que es, un aspecto más de su trabajo.

Como contrapartida a esta imprevisibilidad, el software es infinitamente más fácil de modificar que cualquier construcción de las otras ingenierías con las que pretendía compararse, así que simplemente, aceptemos las caracterísiticas desfavorables y explotemos las favorables.

servido por jarroyo sin comentarios compártelo

¿Que cuesta mejorar el rendimiento?

Cuando pregunto qué cuesta mejorar el rendimiento de una aplicación, no me refiero a cuanto tiempo o cuanto dinero, sino a qué otro tipo de puntos debemos sacrificar. Cada cual que los ponga en la balanza y decida.

Al tiempo de estar en funcionamiento una aplicación, van detectándose puntos en los que se requiere mejorar la velocidad de ejecución, bien porque sean muy utilizados, o bien porque el crecimiento de carga o datos, haya empeorado lo que antes era aceptable. Lo primero a comentar es que no se debe pretender mejorar el rendimiento general del software, se deben atacar de manera individual cada uno de estos puntos conflictivos detectados. ¿Que puede constarnos mejorar su rendimiento?

- Pérdida de genericidad. Que algo vaya rápido y sirva para cualquier circunstancia de la aplicación se me antoja difícil. Por ejemplo, en muchas ocasiones, que una consulta a base de datos vaya lenta, depende exclusivamente de los datos que se buscan, y de como se buscan, por tanto debemos centrarnos exclusivamente en como mejorar estos casos concretos.

- Aumentar redundancia y por tanto consumo de espacio en disco. Tener la informacion replicada en distintos sitios, cuando podríamos acceder siempre a una única ubicación, nos puede ahorrar tiempo. La normalización de las bases de datos, no nos lo aconsejan, y yo, en la mayoría de los casos tampoco, pero hay situaciones desesperadas que requieren soluciones desesperadas.

- Incorrección arquitectónica. Hay veces en las que una programación no totalmente correcta desde el punto de vista de la arquitectura, mejora la velocidad, es el momento de dejar tus escrúpulos a un lado y hacerlo. Nuevamente remarco que esto solo en cosas muy puntuales.

Algunos teóricos podrían echarse las manos a la cabeza con todos estos sacrilegios, pero seguro que tras unos meses en el mundo real, lo verían de otra forma.

servido por jarroyo sin comentarios compártelo

Desarrollo con prototipo Vs enfoque clásico

Antes, que trabajaba en una empresa de servicios, era un firme defensor del desarrollo de software mediante el enfoque clásico.

En este enfoque es imprescindible tener el proyecto lo mejor definido posible en el análisis de requerimientos, realizar las fases de análisis funcional y técnico, y finalmente abordar el desarrollo y las pruebas de calidad.
Los análisis de requerimientos, y funcional, debían ser revisados y validados por el cliente, y eso era la biblia para la implementación. Cualquier cambio que surgiera posteriormente, debía ser estudiado, y ver si implicaba un coste adicional o podía asumirse dentro del proyecto.

Ahora que trabajo en una "empresa final", es decir, que desarrollamos para nosotros mismos, las cosas cambian. Puedes realizar igualmente el análisis de requerimientos, y funcional, pero es difícil que las personas no técnicas de tu propia empresa se tomen el tiempo requerido para revisarlo detalladamente y validarlo. ¿Por qué? ... pues porque los cambios que se realicen posteriormente no les cuestan dinero, solamente tiempo. Puedes decir que el tiempo es dinero, y tienes razón, pero mientras no haya una correspondencia directa entre modificación y euros, eso se diluye.

Estos son los casos en los que estoy comprobando, que es valioso el desarrollo con prototipo. Hacer los análisis más ligeros (no quiero decir que desaparezcan), y comenzar a desarrollar antes, para tener pronto algo básico sobre lo que discutir. A esto que los "no técnicos" pueden "palpar", si que le prestarán atención, propondrán y validarán funcionalidades ... vamos, que el prototipo podrá evolucionar hasta alcanzar el producto deseado.

Con todo esto que quiero decir, ¿es mejor el enfoque clasico o el prototipado?. Pues como te habrás imaginado tu mismo, depende del marco del proyecto. Si tuviera que volver a desarrollar para un cliente, dificilmente optaría por el prototipo, porque el factor tiempo, es muy dificil de estimar.

Otros artículos relacionados:
Artículos de gestión
Artículos de desarrollo

servido por jarroyo sin comentarios compártelo

¿Calidad del software? ¿Y eso que es?

Si el concepto de calidad ya es difícil de establecer para cualquier producto, para el software, y como ya ocurre en comparación con otros ámbitos profesionales, es mucho más difuso, y en la mayoría de los casos, los parámetros son totalmente subjetivos y de cuantificación complicada.

Para un usuario final, un producto de calidad debería cumplir las siguientes condiciones:

- Que haga lo que tiene que hacer. Es decir, que no falle y que no se comporte de manera inesperada dependiendo de si la Luna está alineada con Saturno o con Júpiter.

- Usable. Incontables son el número de programas realmente buenos, y que se han quedado en desuso porque para utilizarlo hay que ser ingeniero de la Nasa.

- Rápido. Hoy en día el tiempo es oro, y los usuarios no están dispuestos a perder su preciado tiempo esperando al programa. Un tiempo excesivo, seguro que le cuesta al software un buen número de "adjetivos peyorativos" por parte del usuario.

- Atractivo. El interface de un programa es lo único que el usuario va a ver, y muy posiblemente, dicho usuario pase por alto un buen diseño del interface, pero un mal diseño, de nuevo provocará críticas y percepción de baja calidad.

Dado el gran número de utilidades que hay compitiendo en el mercado, si los parámetros de calidad no convencen a un usuario, no dudará en abandonar su uso, y buscar otro que le complazca más.

Para el desarrollador, que tiene que vérselas con las tripas del programa, los criterios cambian, y los que creo que más se valoran, son los siguientes:

- Mantenible. No empezaré a analizar el porqué, pero está claro que el software tiene errores que deben corregirse, y cambios funcionales que deben realizarse (por mucho esfuerzo que hayas puesto en definirlos completamente). Poder realizar estas pequeñas modificaciones rápidamente, sin tener que descifrar cada línea de código, ahorrará muchas horas de trabajo y dolores de cabeza al programador.
Yo definiría un posible parámetro mesurable respecto a la mantenibilidad: "El localizator", que sería el tiempo que le cuesta al programador localizar las líneas de código que implementan lo que se está buscando. A menor "localizator", más mantenible es el software.

- Escalable. Con un poco de suerte, el software se utilizará y querrá ampliarse funcionalmente. Llegados a este punto, es vital, que no haya que recompilar el kernel y escrincar el flujo de procesos para poder hacerlo, ya que si es así, posiblemente sea la última modificación que nos pidan.

- Documentado. Sueeeeeeeña .... aquel que tenga bien documentado todo su código, que arroje la primera piedra.

Bienvenidos son los nuevos parámetros de calidad que quieras aportar.

servido por jarroyo 2 comentarios compártelo

Ganar pequeñas batallas

Está demostrado, que los proyectos de desarrollo de software (DS), son un caso a parte, y totalmente distinto de otras ingenierías.

También está demostrado, que respetar las fases del desarrollo (análisis, diseño, implementación, pruebas ...) es más que beneficioso para el éxito del proyecto.

Y por último, también está demostrado, que la mayoría de profesionales no relacionados directamente (y algunos muy relacionados) con el DS*, se lo pasan por el forro, y les parece una pérdida de tiempo.

¿Que podemos hacer nosotros, desde nuestro proyecto y cliente particular, para arreglar esto? La respuesta es ganar pequeñas batallas.

No es necesario estar en una gran empresa de DS* para intentar educar a nuestros clientes, y enseñarles los beneficios de analizar lo que se quieres hacer, respetar los tiempos necesarios para cada tarea, hacer todas las pruebas necesarias antes de instalar ... y un largo etcétera que no es mi intención detallar en este post. Desde nuestra programación de andar por casa, podemos aportar nuestro granito de arena, e ir ganando pequeñas batallas, de manera que le demostremos a nuestros clientes, que es mejor hacer bien las cosas. De esta forma, en el futuro, estos profesionales serán más receptivos, y estarán más dispuestos a aplicar metodología donde sea necesario.

No importa quien sea tu cliente: si te contratan proyectos externos, si desarrollas de manera interna en una empresa ... o si tu eres tu propio cliente, los beneficios de aplicar metodología en el DS son altísimos, y puedes aprovechar cualquier ocasión para aportar tu granito de arena educando a tu cliente, de manera que la ingeniería de software, alcance el respeto que se merece del resto de profesionales.

*DS=Desarrollo de software

servido por jarroyo sin comentarios compártelo

Siempre somos los más listos

Cuando hay un proyecto en el que participan varias empresas, resulta curioso comprobar, que estés en el lado que estés, el trabajo perfecto siempre lo hace tu equipo, y el resto:
- Son un poco pardillos.
- Hay que andar contínuamente detrás de ellos.
- No "se enteran" demasiado.
- Hay que explicárselo todo muy muy clarito.
- etc, etc.

Está muy bien que nos valoremos, y que tengamos la autoestima alta, pero seguro que, ni las otras partes implicadas son tan torpes como nos parece, ni posiblemente nosotros seamos tan máquinas como creemos.

Depende, ¿de que depende?. De según quién lo mire todo depende.

Otros artículos relacionados:
Los hay muy listos

servido por jarroyo sin comentarios compártelo