miércoles, 28 de enero de 2015

¿Qué hacer con las pruebas cuando no tenemos tiempo para ejecutarlas?

 

A la hora de probar una aplicación nos gustaría, aunque suene un poco ambicioso, abarcar todos los casos de prueba posibles logrando un 100% de cobertura. Sabemos que las pruebas exhaustivas no son posibles. Limitaciones como el tiempo y los recursos nos lo impiden. En este artículo nos vamos a centrar en la primera de las limitaciones.

A continuación dejamos una serie de consideraciones para ejecutar los casos de prueba cuando disponemos de poco tiempo: 

- Realizar una prueba de humo sencilla: en otro artículo, ya hemos hablado sobre en qué consisten este tipo de pruebas.

- Ejecutar primero los casos de prueba más relevantes, prioritarios y que signifiquen un riesgo técnico para el negocio.

- Si es posible, evitar los casos de prueba rebuscados o que tomen demasiado tiempo para crear datos de prueba, entorno, configuración a la base de datos, etc.

- Tener los datos de prueba a mano y realizar consultas rápidas a los funcionales para que nos indiquen cuales son los datos a probar más fáciles de obtener en ese momento.

- Hacer listas: es decir, además de analizar cuáles son los casos de prueba más relevantes para ejecutar, diseñar un checklist rápido que se pueda aplicar para cualquier tipo de proyecto en esta situación específica. Esto ayudará a que en un futuro podamos guiarnos con dicho checklist para realizar pruebas básicas.

- Reutilizar casos de prueba.

- Documentar sólo lo necesario.

- Automatizar: este punto es muy particular, ya que no todas las empresas cuentan con el conocimiento y/o las herramientas para realizarlo. Sin embargo, podría ser provechoso para estas situaciones, ya que garantiza una prueba de regresión rápida y efectiva, más allá de otras pruebas manuales que el tester vaya a ejecutar. 

- Consensuar y avisar con tiempo que la totalidad de las pruebas planificadas no llegarán a ejecutarse.

 

¡Gracias Cecilia Soledad Marsili por tu contribución!

miércoles, 14 de enero de 2015

Montaña Rusa del amor con Angular JS 1.3 (y 2.0)

 

Cuando vi que escribía en un textbox y eso se reproducía inmediatamente en la página me encantó, así que empecé a interiorizarme sobre el funcionamiento de Angular JS. En mi opinión, el two-way binding, o sea, tener la posibilidad de modificar una "variable" desde el modelo y que se refleje en la pantalla y viceversa, modificar algo en pantalla y que en el mismo momento el modelo ya cuente con la modificación, realmente me parece muy interesante.

Para que se entienda aquí va un ejemplo en plunker (http://plnkr.co/edit/fY2rN5anm3AkbZksiPNN?p=preview) donde con menos de 70 líneas tenemos un formulario con validaciones.

clip_image001

http://www.kapilkaushik.com/wp-content/uploads/2014/04/angular.gif

Lo siguiente que me intereso fue la posibilidad de darle semántica al código html de la aplicación. Por ejemplo, tener un div con la class "menú" es bastante claro a qué se refiere, pero dentro del div seguramente tendremos una buena cantidad de otros tags para resolver como se visualiza lo que deseamos mostrar.

Angular introduce el concepto de las directivas, que cuando interpreta el código de la página les otorga el funcionamiento que se definió. Por ejemplo, en caso que queramos mostrar una grilla de productos, lo único que ponemos en la página es la directiva <grilla-productos></grilla-productos> y con esto angular lo reemplazará con el html (template) y el funcionamiento (controller) que nosotros hayamos definido. Por lo tanto en la página, lo único que nos queda son los tags que se refieren al contexto de la aplicación y no a la estructura del documento html como pueden ser tags del estilo H3, UL, TABLE, DIV, etc.

Otro key feature de Angular es que simplifica la creación de SPA's (Simple Pages Applications) que hoy en día resuenan tanto en la Web. En cambio, en una aplicación empresarial, que seguramente tenga que ser mantenida por distintos equipos (con sus distintos skills y expertices), más el paso del tiempo (que hace que nos olvidemos de por qué tomamos ciertas decisiones) y sumado por último, que provengo del mundo .Net (donde la aplicación de MVC hoy es un estándar), se me hace complicado ver que llevar todo a una única página ofrezca un gran beneficio.

Bajo el capot

En la charla del Google DevFest explicaron cómo funciona Angular. Lo primero que hace es poner en una lista todas los componentes que va a observar, el valor que tienen actualmente y una función a llamar en caso que cambien. Después, por cada evento que se realiza, tanto en la página como en los servicios, recorre la lista y se fija si cambió algún valor y ejecuta la función asociada. Si se dio el caso que algún valor fue modificado, vuelve a recorrer toda la lista (obviamente, con un límite de ejecuciones para evitar un ciclo infinito).

Como se ve, esto tiene un pequeño problema de performance a medida que incrementamos los objetos observables, por lo tanto, se dice que hasta 2000 es una cantidad aceptable. Aunque parece un número grande, hay que tener en cuenta que cada directiva ng-repeat genera un objeto por cada fila y columna y, además, agrega uno por el contexto en general, por lo tanto,  si tenemos una grilla que muestra 10 columnas por 15 registros, más las cabeceras, más el pie, etc. estamos entre 160 y 200 objetos. Simplemente hay que tener en cuenta la cantidad de cosas que estamos Anguleando.

Otro dato que me pareció interesante, es que uno de los representantes de Google comentó que en Angular (1.x) están trabajando cerca de 50 ingenieros, pero en Polymer hay alrededor de 2000. No me quedó en claro si es porque ya se considera estable, o porque están apostando a Polymer.

clip_image002

Angular JS 2.0

Con la futura llegada de la versión 2.0 de Angular todo lo que sabemos desaparece. ¡Durísimo!. Bueno, no tanto. Los muchachos de la gran G publicaron los documentos de diseño de arquitectura a la comunidad y recibieron montones de contribuciones de cómo modificarla. Se creó un intercambio de ideas que sigue creciendo día a día.

De todas formas confirman que se seguirá evolucionando las versiones 1.x en paralelo con la 2.x.

Esta es la imagen con la que se presentaron en la conferencia de ng-europe:

clip_image003

Con lo cual, a pesar de que pueda faltar tiempo antes de que aparezca una versión estable de v2.0, no recomendaría arrancar una nueva con la versión 1.x ya que, aunque la curva de aprendizaje es bastante corta, no se va a poder reaprovechar en algún tiempo.

Más información

https://angularjs.org/ - Dónde se debería comenzar

http://campus.codeschool.com/courses/shaping-up-with-angular-js/intro  - El más simple de los tutoriales

https://www.ng-book.com/ - El libro

http://ng-learn.org/2014/03/AngularJS-2-Status-Preview/ - Que pasa con la versión 2.0

https://www.youtube.com/watch?v=gNmWybAyBHI - Conferencia en ng-europe

https://www.polymer-project.org/ – Polymer

 

¡Gracias Marcelo Mosquera por tu contribución!