El blog de Diego Lucio D'Onofrio

Viendo fisiogramas antes que estén hechos.

2011-11-12T13:53:00.000-08:00

Hace unas semanas, un amigo me comentó sobre la existencia de los "Fisiogramas". Para el que no lo sepa, como yo hace menos de un mes, un fisiograma es el registro fotográfico de la trayectoria de una o varias fuentes de luz. Además me mostró una galería de estas imágenes realmente impresionante.

Comencé a dudar respecto a ser el creador de mi técnica de fotografía artística a la que llamé Coloreado con laser (painted with laser), ya que esto se parece mucho a lo que publiqué en su momento. Para el que no lo recuerde aquí tengo un link al post original: Pintado con láser publicado por primera vez el 4 de octubre de 2010, también os dejo dos fotografías bastante más recientes y dónde uso mi técnica con un láser verde:

No obstante, luego de ver varios ejemplos, creo que los fisiogramas y mi técnica no son lo mismo aunque sí algo similar.

Volviendo al los fisiogamas, luego de esta pequeña introducción y de la reivindicación de mi parte de seguir siendo el primero en publicar imágenes de este tipo, a continuación os cuento mi primera aproximación a la técnica y os paso el primer ejemplo. Prometo en una entrada futura añadir imágenes más elaboradas.

El desafío

El primer desafío con el que me encontré, fue no poder ver lo que estaba haciendo al tratar de dibujar usando luz o láser y una cámara con el obturador abierto. Es muy difícil dibujar cualquier cosa, incluso un garabato como el que muestro más adelante, sin poder ver como está quedando.

El visor de fisiogramas

Para facilitar la idea, se me ocurrió desarrollar un pequeño programa al que decidí llamar "visor de fisiogramas". Básicamente es una aplicación que, mediante una web cam capturando vídeo, es capaz de mostrar solo los registros lumínicos que están por arriba de la intensidad de color ya registrado para cada píxel.

Para hacerlo me apoyé en un software libre llamado "Qt Opencv webcam viewer" publicado en qt-apps.org y desarrollado por Windel Bouwman, a quien estoy muy agradecido ya que hizo la parte difícil del asunto: Mostrar una imagen capturada desde una webcam.
Tomando este programa como base y cambiando unas pocas líneas, conseguí desarrollar un nuevo software que vale perfectamente para visualizar en tiempo real como están quedando los fisiogramas.

El programa está hecho en Qt con C++, por lo que es bastante portable a todos los OS's/plataformas y se puede descargar desde: http://code.google.com/p/fisiogram-viewer/

Mi primer fisiograma

Ante todo quiero dejar en claro que no considero que esta imagen que subo sea una obra de arte, simplemente lo he añadido como ejemplo de mi primera creación usando el visor. Como bien pone el título de esta entrada, mi idea es mostrar el programa y no unos fisiogramas decentes, los cuales prometo en una entrada próxima.

La imagen la hice con una pequeña linterna que emitía luz blanca ocultándola en mi mano, se ve roja por la sangre de mis dedos que se volvían translúcidos a la exposición de la luz.

Imagen capturada por mi cámara

Captura de pantalla de mi netbook ejecutando Fisiogram Viewer

(De fondo se ve el editor de código, el programa todavía estaba en el horno)

Conclusión

Los fisiogramas y mi técnica de pintado con láser no son lo mismo, sin dudas desarrollar un fisiograma bonito requiere de mucho más esfuerzo y habilidad que colorear objetos con un rayo láser, aunque los resultados de ambas técnicas pueden ser equivalentes en calidad.

Un -1 gigante para Computer Hoy.

2011-09-08T13:21:00.000-07:00

Desde hace algunos años, me compro la edición española de la revista Computer Hoy, la cual es muy profesional y tiene muy buenos e interesantes contenidos.

Desafortunadamente, hoy tengo que ponerle un -1 (no me gusta) gigante, debido a un artículo publicado en su edición Nº335 y por supuesto a su falta de respuesta a mis correos enviados hace más de un mes.

A continuación os cuento porque:

El viernes 5 del pasado mes, como habitualmente suelo hacer cada dos semanas, al regresar del trabajo, pasé por la gasolinera que está camino a casa dónde reposté combustible y me compré la mencionada edición. Mientras caminaba hacia mi coche por la explanada de la estación de servicio, repasé ligeramente las notas de tapa hasta que mi mirada se clavó en el titular que rezaba "La revolución Open Source".

Me entusiasmó mucho el título de esta nota, si bien soy un fanático del software libre, me interesaba mucho leer un poco, más allá de la wikipedia, sobre el Open Source, el trabajo de Eric Raymond y la OSI. Como Computer Hoy es una revista con una calidad excelente de material, esperaba encontrarme con un artículo a la altura del resto de sus publicaciones.

Tristemente, debo admitir, que a medida que leía la nota no dejaba de asombrarme por la evidente falta de conocimientos del autor sobre el tema. Y lo que es peor, no dejaba de mesclar conceptos como software gratuito, software libre, código abierto que, junto a algunas sandeces adicionales, convierten a esta publicación en algo muy atípico.

Una verdadera pena, porque estoy convencido que si antes de escribir este artículo contactaban con la OSI o incluso la FSF, lo más probable es que les hubiesen ayudado gustosos, añadiéndole un gran valor, e incluso evitándome escribir esta corrección.

Unos días después, luego de repasar varias veces el artículo, decidí escribirles un correo dónde exponía de manera genérica los errores que la nota posee, el mal que le hace al software libre y una solución propuesta. A lo largo del mes, y en varias oportunidades, reenvié el correo solicitando al menos una confirmación de recepción, para todos esos correos no recibí ninguna respuesta.

Sin más preámbulos, y con el único ánimo de proporcionar al público de mi blog conocimientos correctos sobre el tema en cuestión, por supuesto que mi blog no tiene la cantidad de lectores que posee la revista, no obstante, si puedo llegar a unos pocos, habré cumplido con mi meta.

¿Programas gratis? ¿A que se refiere?

En la página 64, dónde comienza la nota, encontramos el copete "¿Programas gratis?" Seguido de una breve explicación completamente incorrecta: "Existen aplicaciones comerciales para todos los usos. Pero ¿es necesario pagar por todo? Bajo el término Open Source, hay infinidad de programas gratuitos en Internet. ¿Te gustaría saber qué hay realmente detrás del código abierto?".

En primer lugar, para que un programa sea Open Source, no tiene por que dejar de ser comercial ni ser gratuito. El decálogo del movimiento se puede encontrar en wikipedia en este link, y como se puede apreciar, en ningún lado se habla de costes o temas monetarios.
Contradiciendo a lo que expresa el copete de la nota, un programa Open Source, al igual que el software libre, puede ser comercial.

Pero no soy yo el único que contradice la publicación, también lo hace el propio autor, tan solo unas líneas después, escribe el siguiente texto, el cual, además de ser mentira, desdice lo dicho: "El primer proyecto Open Source se basó en el navegador favorito de los años 90, Netscape Navigator".

Señores, para el que no lo sepa, el Netscape Navigator fue el primer programa comercial de la empresa Netscape Communications. El cual fue liberado bajo licencia GPL (software libre, no Open Source) a finales de los 90.

Además, creo que nadie sabe cual fue el primer programa Open Source ya que el movimiento parte de un cisma del software libre, a principios de los 90's. Por otra parte, y como lo indico, Netscape nunca fue Open Source, sí pasó a ser software libre, y por ende su código fue liberado.

Código privativo

Bajo el título de "¿Que es código fuente?" el autor explica muy bien y de manera compacta el significado para que cualquier mortal pueda entenderlo, cosa que entona con el resto de las publicaciones de esta revista, no obstante, en un momento se refiere al código privativo con una línea bastante desafortunada, en pocas palabras dice que los programas privativos solo pueden ser mejorados y limpiados de errores por el "fabricante".

Por un lado, creo que le ha faltado indicar que también los autores de software privativo pueden, y de hecho lo hacen, incluir funcionalidades malévolas, invisibles y no deseadas por el usuario.

Por otra parte, la palabra "fabricante" no es la más adecuada, ya que el software no se fabrica, no es algo tangible y relacionarlo aunque sea implícitamente, como es este le caso, con objetos materiales, impide que podamos pensar en reglas distintas para su uso y comercialización.

Tal vez creáis que me esté poniendo un poco purista, pero es importante, sobre todo con temas relacionados a licencias de software, utilizar términos correctos, ya que la complejidad e importancia del asunto no es para nada trivial.

El nombre del sistema operativo es GNU-Linux

Avanzando un poco en la nota y tratando de contestar a la pregunta "¿Qué programas Open Source existen?", hay un párrafo en el que el autor no ha acertado en ninguna de sus afirmaciones, el cual pone literalmente: "Los hay para todos los sistemas operativos. Por ejemplo, el software Open Source como VLC Player o Firefox, existe para Windows, Mac OS X y Linux. Actualmente hay más de 250.000 programas Open Source en casi todas las categorías:"

En principio, los dos ejemplos que pone de Open Source, son una vez más Software Libre. Por otra parte, el nombre correcto del sistema operativo es GNU, o también se lo puede llamar GNU-Linux, ya que Linux es solo el núcleo, el cual se utiliza también en otros sistemas operativos, como por ejemplo Android.

Respecto al dato estadístico del cuarto de millón de programas, no se de dónde el autor sacó esta cifra, aunque a esta altura estoy convencido que no habla de programas Open Source.

Repito: El nombre del sistema operativo es GNU-Linux

Las afirmaciones de su siguiente párrafo tampoco han sido muy precisas, el mismo pone "Sistemas Operativos: Los más conocidos son Ubuntu, Debian, Red Hat u Open Suse, basados en Linux. Pero también el conocido sistema operativo Android de Google, para móviles y tablets, es Open Source".

No se que corregir primero, así que vamos por orden. Ubuntu, Debian, Red Hat y Open Suse son distribuciones del mismo sistema operativo, llamado GNU y no están basados en Linux, Linux es el núcleo, el cual constituye solo una parte del sistema operativo.

El sistema operativo Android es software privativo, el cual viola más de un punto de las licencias libres, incluso el decálogo de Open Source, así que tenerlo en cuenta, si bien Android utiliza el núcleo Linux, es software privativo, ya que sus fuentes no están disponibles. Algo similar ocurre con el Max OS, que tiene un núcleo Open Source y el sistema operativo es privativo y comercial.

He pasado por alto el detalle de la "u" entre Red Hat y Open Suse, ya que creo que el autor ha cometido un error tipográfico y lo que en realidad quería decir era "y". Además, los que escribimos sabemos que estos errores se cometen y la rigidez de escribir para una publicación en papel impide futuras correcciones.

Finalmente, Android no es solo para móviles y tablets, en un artículo de ediciones anteriores de la misma revista se puede leer que Android ya viene instalado en algunos portátiles.

Para que un software sea libre, necesita ser Open Source, no sucede lo mismo al revés.

Un poco más adentrado en la misma sección de la nota, pone al "freeciv" como un programa Open Source, el mismo está licenciado bajo la versión 2 de la licencia GNU-GPL, por lo que es Software Libre. Este programa también es Open Source, pero no lo pondría como ejemplo ya que lo único que lograría es confundir aún más al lector.

Entonces Open Source ¿Es de pago?

Dentro de las ventajas que el autor expone para recomendar el uso del Open Source, como era de esperarse, en primer lugar expone "Prácticamente todos los programas Open Source los puedes descargar de forma gratuita", seguido de una explicación que demuestra una mala interpretación de la "artistic licence" de OSI: "Según las normas de OSI, no puede ser superior al coste de su fabricación, manipulación y envío de un DVD."

Hasta este párrafo, el autor había dejado entrever la ecuación "Open Source = Gratis", para contradecirlo en este punto, no obstante, OSI no habla de costes o proporciones de los mismos en ninguna de sus licencias, por lo que un programa Open Source puede ser gratis o valer miles de millones de €, lo sí que dice la licencia es que no se cobrarán portes por el licenciamiento y pone como ejemplo lo que el autor atribuye a una norma del modelo OSI.

¿Defectos de usar Open Source o de escribir un artículo así?

Además de lo expuesto hasta ahora, el autor ha demostrado tener una gran inventiva, imaginando desventajas inexistentes que no soportan el menor análisis. Además, no ha tenido mejor idea que ponerlas bajo la pregunta "¿Cuales son los defectos de Open Source?" dónde se explaya ocupando prácticamente toda una página y por supuesto, no explica las desventajas de usar software privativo.

Como primer punto negativo, el autor escribe "Software Anticuado" y explica que el Open Source suele ser anticuado por falta de recursos. Esto es completamente incierto, normalmente los proyectos Open Source, al igual que Software Libre suelen tener varios cientos de desarrolladores, cosa que la mayoría de las empresas que crean software privativo no se pueden permitir.

Al segundo punto lo llamó "Confusión", no voy a decir nada al respecto ya que no soy capaz de entender a que se refiere, simplemente voy a copiar la descripción del mismo: "El gran número de programas, versiones y partes de la aplicación dificulta el control. En Internet puedes encontrar muchas páginas que te orientan acerca de cual elegir"

Como tercer punto negativo expone "Compatibilidad" y escribe: "Por ejemplo, los ficheros de Word y Excel también se pueden abrir y editar con programas como Open Office. Pero si las tablas creadas con Excel contienen fórmulas muy complejas, es posible que Open Office no las pueda procesar correctamente."

Simplemente voy a añadir que si hablamos de compatibilidad, podemos decir que no hay software privativo que abra los ficheros nativos de Open Office, por el contrario, Open Office abre los ficheros de los programas privativos más usados de ofimática. Entonces ¿Cual es el defecto de compatibilidad de usar software libre?

Al siguiente punto lo titula "No para todas las áreas", y su ampliación del tema no destaca del resto de la nota "Aunque el software Open Source se aplica a muchas categorías, aún no existen demasiados programas profesionales. Este es el motivo por el que las empresas, al pasar a Open Source, no equipen todos los ordenadores con el software gratuito".

¿En que quedamos? ¿El Open Source es o no gratuito? Está claro que el autor no se pone de acuerdo ni siquiera dentro de la propia nota.

Respecto al resto de este párrafo, el decir que no existen demasiados programas profesionales Open Source pone en tela de juicio la interpretación de la palabra "profesional" del autor, como así también su propio nivel profesional.

El punto titulado "Hardware" es posiblemente el que más daño gratuito hace al Open Source y también al Software libre. Alegremente y una vez más sin fundamentos, en una sola línea el autor desaconseja instalar el OS GNU, ya que dice que el hardware puede dejar de funcionar.

Flujo de trabajo del desarrollo Open Source

Una vez más, el autor hace uso de su creatividad para describir un flujo de procesos que, según él, son los que dirigen el desarrollo de todo programa Open Source.

Si pensamos por un momento la cantidad de empresas que desarrollan Open Source en el mundo, entre las cuales figuran IBM y Oracle, no es posible pensar que todas utilizan el mismo flujo de trabajo, los mismos métodos o procesos.

Desarrolladores de Open Source

Bajo la pregunta "¿Que motiva a los programadores?", el autor comienza escribiendo: "El programador busca, ante todo, el reconocimiento de otros desarrolladores".

No lo he dicho antes, pero son varios los puntos en la nota dónde trata de dejarnos a los desarrolladores de Open Source como una panda de frikis. No entiendo muy bien el motivo, pero como desarrollador de varios proyectos Open Source y Software Libre, os puedo asegurar que nuestras motivaciones y preocupaciones son exactamente las mismas que las del resto del mundo. No somos especiales ni raros y tampoco sufrimos de baja autoestima, al menos no más que la media de las personas.

Los desarrolladores de Open Source utilizamos el Notepad de Windows.

Vamos, que a este punto la mitad de mi indignación se me había escapado a carcajadas. El desopilante autor, quien por cierto no firma el artículo, afirma: "Además el desarrollador necesitará un software para modificar los programas existentes y crear nuevos. Para proyectos pequeños suele ser suficiente el bloc de notas de Windows. Pero para el desarrollo de grandes proyectos, se utiliza normalmente Eclipse (gratuito) o Visual Studio 2010 (En torno a 500 euros)"

Posiblemente muchos de los que lean esta entrada no terminen de entender por que me causa tanta risa esta falsedad. Pero estoy convencido que a los desarrolladores que lo lean también les surgirá cuando menos una sonrisa. El motivo es que los desarrolladores Open Source o Software Libre solemos usar programas libres para desarrollar, entre ellos el emacs que casualmente fue programado por el presidente y fundador de la Free Software Foundation Richard M. Stallman a principios de los 80 y que se sigue ampliando al punto que prácticamente no hace falta salir de este programa para realizar todas las actividades relacionadas al desarrollo o no.

Cygwin el mejor compilador.

El último párrafo del artículo es claro y conciso, dice literalmente "Al final se utiliza un programa compilador, como Cygwin, que traduce el código para el sistema operativo correspondiente".

Salvo por el detalle que Cygwin no es un compilador, y de hecho su funcionalidad no tiene nada que ver con la de un compilador, el resto del párrafo es razonablemente correcto.

Por último y no menos importante, el autor confunde el trabajo de Linus Torvalds con el de Richard Stallman, describiendo a este último como un "Hacker activista" y obviando el pequeño detalle que es el padre del software libre.

En resumen, el artículo posee 4 páginas las cuales no echaría de menos si nunca hubieran sido escritas. A pesar de esto, y de que mis correos hayan ido al /dev/null de la editorial, voy a continuar recomendando y comprando la revista, ya que, dejando de lado este puntual incidente, reboza de calidad la cual refleja el trabajo duro de grandes profesionales.

NDA: Los textos escritos en cursiva son transcripciones literales de la revista.

Palabras que no debemos usar, o debemos usarlas con cuidado.

2011-08-10T08:47:00.000-07:00

Hace mucho tiempo que tengo ganas de escribir esta entrada en mi blog, precisamente poco después que Richard Stallman me entregara en mano una copia de uno de los libros que más disfruto leyendo "Software libre para una sociedad libre". En él aparecen descritos varios términos con los que perfectamente se podría escribir un glosario, eso pensé en ese momento y casualmente hoy, navegando por la página de la Free Software Foundation, me he encontrado justamente con un artículo que lleva el mismo título que esta entrada de mi blog "Palabras que no debemos usar, o debemos usarlas con cuidado".

Basándome en esa lectura, que podría decirse me ganó de mano con la idea, he confeccionado una lista con los términos y definiciones que más suelo corregir, a diferencia de la entrada original de la FSF, lleva comentarios míos y la he ordenado un poco en función de los más frecuentes. Espero que os guste:

PC

Elegí esta sigla, como primera palabra, no porque sea la que más suela corregir, sino porque la veo con mucha frecuencia mal usada. En muchos sitios de descargas, encuentro que determinado software se encuentra disponible para Mac, GNU-Linux y PC, como si PC se refiriera a un ordenador con Microsoft Windows.
PC son las siglas, en inglés, de Ordenador Personal, no tiene nada que ver con su sistema operativo. De hecho, en mis PC's, utilizo el sistema operativo GNU con Linux.
Por otra parte, para llamar a los ordenadores personales que tienen Microsoft Windows, la FSF ha propuesto unas siglas que resultan mucho más apropiadas: WC. Creo que lo describen mucho mejor, así que, si desarrolláis software que ejecute en PC's con GNU y núcleo Linux, Mac OS y Microsoft Windows podéis decir que vuestro software es para: GNU, Mac y WC.

Linux

Realmente me canso de corregir el mal uso de esta palabra, Linux es un núcleo que comenzó a desarrollar Linus Torvalds en el año 1991, por aquel entonces, Richard Matthew Stallman ya tenía un sistema operativo libre, basado en Unix, llamado GNU, al cual le faltaba un núcleo. La licencia original de Linux no era libre, pero cuando Stallman contactó a Torvalds lo convenció de adoptar la mejor licencia del mundo, GPL.
Como Linus había desarrollado una versión muy preliminar de un núcleo que podía completar el SO de GNU, y finalmente la licencia lo hacía libre, la FSF adoptó este núcleo para su sistema operativo GNU.
Con este breve resumen de la historia, quiero aclarar que el verdadero nombre del sistema operativo es GNU, que puede ser llamado como GNU-Linux, o GNU con núcleo Linux.
Aprovecho este párrafo para citar una de las frases que más me gustan de Richard Stallman: "GNU es el único sistema operativo y Linux es solo uno de sus núcleos".

Gratis

La creencia de que el software libre (free software) es gratis, es otro punto que a menudo debo explicar. El software libre no necesariamente es gratis, de hecho su fundamento es algo ético que no tiene que ver con el dinero. Software libre se refiere a software que respeta las libertades de los usuarios y la solidaridad de su comunidad. Os recomiendo que invirtáis 6 minutos de vuestras vidas en ver este video dónde RMS explica perfectamente que es Software Libre.
En resumen, todo el software debe ser libre y no necesariamente gratis.

Piratería

Con diferencia, este es el término que menos me agrada cuando se usa mal, no porque sea malsonante o especialmente incorrecto, sino porque su uso fue acuñado con el único fin de combatir uno de los pilares fundamentales de toda sociedad: la solidaridad.
Piratas son aquellos que matan gente y atacan naves en alta mar, lo cual es algo malo, por el contrario, compartir es probablemente el acto solidario más importante de cualquier comunidad, lo que lo convierte en algo muy bueno.
Llamar piratas a los que comparten software o música es implícitamente estar en contra de un bien social, y los medios de comunicación han promulgado el mal uso de este término, al punto que lo encuentro mal usado muy a menudo.
Sin ir más lejos, la real academia española describe la palabra Piratería como "Ejercicio de pirata", así que por favor, no llaméis Piratería a algo tan bueno como es la solidaridad.

Hacker

El término hacker, no tiene traducción al español, pero originalmente describía a alguien a quien le gustaba jugar con inteligencia y no necesariamente estaba relacionado con la informática. Tal y como lo conocemos hoy en día, fue acuñado por los desarroladores del MIT en los años 60's. Ellos mismos se hacían llamar "Hackers" lo cual tiene sentido con la descripción correcta del término anglo.
Lamentablemente, durante los años 80, periodistas que descubrieron la comunidad de Hackers, lo asociaron con la acción de romper la seguridad de los sistemas informáticos. Esto sumado a Hollywood, quien nos muestra a un "hacker" rompiendo la seguridad del pentágono mientras es apuntado con un arma y distraído por las actividades de una bella mujer en cuclillas, consiguió que la mayoría de la gente piense que un hacker es necesariamente alguien que irrumpe de forma ilegal en sistemas remotos y sin autorización.
Yo mismo me considero un hacker por la pasión que le pongo a mis actividades de desarrolador de software. Así mismo, cuando se le pide un autógrafo a Richard Stallman, suele firmar escribiendo Happy Hacking, y os aseguro que no se refiere a que seamos felices mientras cometemos actos ilegales. Por el contrario, significa que disfrutemos de la investigación.

Código Abierto (Open Source)

A menudo escucho a gente preguntar ¿Este software es open source? o ¿Es software abierto? cuando en realidad lo que quieren saber es si es gratis o libre. Open Source no necesariamente tiene que ver con ser libre o gratis, simplemente significa que poseemos el código fuente del programa, con lo cual podríamos llegar a ser capaces de modificar su funcionamiento aunque esto puede no estar permitido por su licencia.
El software libre, necesariamente tiene que ser abierto, poseer el código fuente y todos los componentes para poder crear ejecutables de ese software, es uno de los puntos fundamentales de la licencia GPL, aunque el software debe cumplir con otros requisitos para llegar a ser libre.
Respecto al tema económico, el software de código abierto no tiene por que ser gratis.

Freeware

Freeware, es otro término que normalmente se confunde con Software Libre, lo cual no puede estar más alejado de la realidad. Un Freeware significa que es un software gratuito, es un tema puramente económico. Como expliqué anteriormente el Software Libre o Free software no tiene nada que ver con el coste de un programa. De hecho Richard Stallman, durante una época vendía software libre con el fin de recolectar dinero para la FSF, así mismo personalmente compro software libre en algunas oportunidades.

Software Comercial

Escucho muy a menudo, el llamar "Software Comercial" al software no libre. Esto es una equivocación, ya que como comenté antes, el software libre no tiene por que ser gratis. Por otra parte, Software Comercial se refiere a aquel desarrollado como una actividad de negocio, y hoy en día existen muchas empresas que realizan software comercial libre. Como contraejemplo está el caso del software privativo gratuito o no comercial.

Consumo/Consumidor

Otro término, menos usado pero no menos incorrecto, es hablar de consumidores o consumo de software, refiriéndose a aquellos quienes compran un programa.
Este termino no es apropiado, ya que a diferencia de lo que sucede con los elementos físicos, se pueden hacer copias exactas de un software sin coste y sin consumirlo, por lo que hablar de consumo, consumible y consumidores refiriéndose a software carece de sentido.

Hasta aquí llega mi lista de términos por hoy, no descarto la posibilidad de extenderla en el futuro, en una segunda parte de esta entrada. Espero que os haya gustado, como así también leer vuestros comentarios.

Fuentes:

¿Está correctamente dimensionado nuestro departamento de SQA?

2011-04-24T01:44:00.000-07:00

¿Está correctamente dimensionado nuestro departamento de Aseguramiento de Calidad del Software?

Esta cuestión que se formula en menos de diez segundos, es con seguridad, una de las más complicadas de contestar fehacientemente. Esto se debe a que conjuga una suerte de retos, difícilmente abordables, que a la vez implícitamente requieren la correcta implementación de procedimientos que, en papel no resultan complicados, aunque a la práctica lo son.

En esta entrada de mi blog, voy a intentar desmenuzar estos desafíos, a los que añadiré mi experiencia personal en la resolución de los mismos.

Me es difícil encontrar otras preguntas que encierren tantas cuestiones como lo hace esta. Un modo de resolver un problema mayor, es dividirlo en cuestiones menores, tantas veces como sea necesario, hasta que sea humanamente abordable. Esta es exactamente la forma en que acometí este asunto y de esta manera lo describiré a continuación.

La primera pregunta tácita que debemos ser capaces de contestar es ¿cual es el nivel de calidad que necesita mi software?
Para contestarla, es necesario contar con métricas multidimensionales que permitan, con relativa exactitud, medir los resultados de la calidad y estimar sus fluctuaciones en función de variaciones en la inversión. Este punto representa la piedra angular de la problemática planteada.

Una de las maneras de obtener una respuesta a esa pregunta es mediante el calculo y estimación del retorno de inversión (ROI en SQA). En lo personal, por cuestiones inherentes a mi empresa, elegí esta forma de atacar el problema, aunque no descarto que se puedan utilizar otros procesos más directos y consecuentemente menos costosos.

Calculando el Retorno de Inversión (ROI)

El calculo del ROI es algo relativamente trillado, especialmente en aquellas áreas dónde las fuentes de datos y su trazabilidad están disponibles. Puntualmente en SQA calcular el ROI es complejo y, al día de hoy, no hay demasiada documentación al respecto.

En ROI es un valor porcentual que, aplicado en un momento determinado, nos dice que porcentaje de la inversión hemos recuperado, así mismo, un ROI negativo siempre significa pérdida, un ROI positivo significa ganancia y un ROI de cero significa que hemos ingresado exactamente el capital invertido.
El cálculo del ROI siempre debe estar asociado a un segmento de tiempo, que es el que necesitamos medir, lógicamente si variamos este momento el ROI varía. Podemos afirmar que el ROI es una comparación entre la utilidad obtenida y la inversión realizada para un momento.

Con el fin de eclipsar las dificultades comprendidas en esta tarea, personalmente realizo el cálculo del ROI por proyectos. De esta forma además de obtener un ROI general, poseemos cierta granularidad que permite obtener rápidamente cálculos de ROI por producto, versión, cliente, etc.

Con todo lo anterior, continuamos aplicando la regla "divide y vencerás", partiendo esta tarea en el cálculo de la inversión de una dupla proyecto/momento y su correspondiente cálculo de beneficio.

La primera parte, que consiste en el cálculo de la inversión, es relativamente sencilla. En lo particular utilizo openproj para gestionar, entre otras cosas, el esfuerzo aplicado a un proyecto. Con cualquier herramienta que usemos de gestión de proyectos podemos obtener, de manera rápida, los recursos asignados y si a esto le sumamos los costes de infraestructura, que tampoco son muy difíciles de medir, y los ajustes pertinentes por costes ocultos habremos calculado la inversión.

Implementar un proceso que permita calcular la utilidad obtenida es el quid de esta cuestión. La punta del ovillo la encontré en el último expo:QA, evento dónde tuvo a lugar una interesante charla de Francisco Sáez precisamente sobre este tema. En resumen, calcular el ROI en SQA consiste en monetizar las incidencias, calculando los costes de resolución de las mismas según su origen de detección, para luego elaborar una simulación dónde la detección de las incidencias se efectúa al final de nuestra línea de producción, normalmente en el cliente. La diferencia entre ambos cálculos nos arroja el ROI.

Podemos partir esta tarea en dos restos menores, por un lado identificar el origen de las incidencias y por otra parte crear un proceso que nos permita agruparlas según su coste de resolución en etapas posteriores a la validación.

Voy a hacer un pequeño paréntesis para subrayar que, este último proceso está íntimamente ligado a las singularidades de cada empresa, por lo tanto en mi experiencia ha requerido la aplicación de ingeniería de procesos en varias faces y posteriores ajustes a través de los ciclos.

Retomando el tema de la identificación del origen de las incidencias, la manera más directa de hacerlo es apoyarse en la versatilidad de los bugtrackers modernos, los cuales permiten añadir campos personalizados. Para obtener esta información añadí en mi bugtracker (bugzilla), un campo obligatorio que indica dónde se ha hallado la incidencia. Esto se puede hacer con tanto detalle como definición queramos tener.

Por último, para calcular el coste de resolución en etapas posteriores a la validación, añadí también algunos campos a las incidencias que, además de ser manualmente informados, se les aplica una fórmula mediante un proceso batch nocturno.

Con esta información recogida en las incidencias, creamos una tabla dónde las columnas representan las distintas etapas en las se detectan, y sus filas son los costes de incidencias agrupados.

A continuación he creado un ejemplo de esta tabla, como se puede ver un mayor número de columnas añade nitidez que puede servirnos para otras métricas:

Origen / Grupo de coste	I+D		SQA			Cliente
Origen / Grupo de coste	Unitest	Revisión de pares	Verificación	Análisis	Validación	Preproducción	Producción
Grupo A	1	2	0	2	10	0	1
Grupo B	3	5	1	6	25	0	2
Grupo C	6	3	0	12	30	2	3
Grupo D	17	7	5	15	56	10	10

He pintado de color gris las columnas previas a SQA, debido a que no deben ser tomadas en cuenta para calcular el ROI de dicho departamento.

Con esta tabla y teniendo implementado el proceso que define el cálculo de costes de resolución de incidencias para cada par grupo/fase, obtenemos el primer valor que necesitamos para calcular el ROI. Con esto estamos en condiciones de realizar la siguiente simulación que, de manera directa, despejará el dato que falta para calcular el beneficio.

Dicha simulación consta de mover todas las incidencias detectadas en SQA (Verdes) directamente hacia la columna del cliente (amarillas), calculando así el coste emulado de resolución de las mismas detectadas posteriormente a la validación. Con un afinado proceso adicional, se podría determinar incluso cuantas de estas incidencias caen en la columna de pre-producción y cuales en la de producción, aunque dependiendo de las necesidades de cada empresa, es posible que sea necesario tener una mayor cantidad de columnas o bien tener solo una.

Con esto estamos en condiciones de calcular el beneficio, el mismo es la diferencia entre el valor obtenido de los datos reales y el arrojado por la simulación, al que no debemos olvidar restarle aquellas que realmente fueron detectadas en el cliente.

Obtendremos el ROI de un proyecto si conocemos la inversión y el beneficio tras aplicar la siguiente fórmula:

Pudiendo calcular el ROI para cada proyecto, es posible definir estadísticas que arrojen la tendencia del mismo, de esta manera no solo tendremos el ROI calculado sino que, además seremos capaces de estimarlo.

Siendo capaces de calcular el ROI, para conocer si es correcto el dimensionamiento de un departamento de SQA, el siguiente paso natural es calcular el índice de producción de los recursos.

Calculando el índice de producción de los recursos

Hoy en día prácticamente cualquier departamento moderno de aseguramiento de calidad del software, posee mecanismos que permiten obtener el índice de producción por recurso.
Así mismo, las herramientas de gestión de pruebas, en mi caso utilizo Testopia, ofrecen características que, de manera más o menos directa, brindan cuando menos la recolección de estos datos. Testopia puntualmente, posee unos controles con los cuales el ingeniero de pruebas registra el momento en que comienza, pausa y termina de ejecutar un caso de pruebas. Herramientas más completas, además de esto, permiten extraer esta información.
Personalmente es una necesidad que he satisfecho hace tiempo, contando con la recolección de datos a nivel de caso de prueba ejecutado (tiempo de ejecución de un test case/test run) y añadiendo algunas dimensiones adicionales, como ser entorno, versión, etc, he logrado mediante un proceso tener este dato más que ajustado.

En relación al resto de las actividades, fuera de la ejecución manual de casos de prueba, como ser análisis, diseño, automatización, mantenimiento de bancos de prueba, etc. es necesario contar también con algún procedimiento que permita medirlas, ya que sus costes y beneficios no son residuales.

Si tenemos trazabilidad, en tantas dimensiones como necesitemos, sobre la producción de los recursos, el calcular variaciones en función de la inversión es un proceso relativamente sencillo.

Conclusión

Es factible, de hecho lo he logrado, poder conocer el beneficio y el coste de un departamento de aseguramiento de calidad del software en funcionamiento, también es posible estimar el beneficio que obtendremos variando la inversión. Una vez implementados los procedimientos que arrojan estos datos, seremos capaces de contestar, con determinada exactitud, a la pregunta ¿Está correctamente dimensionado nuestro departamento de SQA?

Soy consiente que estas pocas líneas en mi blog no representan una guía lo suficientemente completa como para poder implementar cualquiera de los procesos que nombro, aunque tampoco lo intenta ya que la documentación interna que he escrito dónde se recogen tiene las dimensiones de una novela. Mi objetivo con esta entrada es principalmente dar a conocer la factibilidad mediante el relato de mi experiencia. Así también contribuir con datos que hubieran sido de gran utilidad para mi cuando comencé a diseñar estos procesos.

Para terminar y por si no ha quedado claro, este conjunto de procedimientos se aleja mucho de ser económico o rápido de implementar y su coste varía en función de muchos factores, entre los que más destacan la madurez de los procesos en funcionamiento y el tamaño del departamento.

De Radares y velocidades mínimas.

2011-04-24T00:16:00.000-07:00

Esto es solo una situación hipotética completamente ficticia, cualquier parecido con la realidad es mera coincidencia.

En una transitada autopista madrileña, se decide colocar un radar para controlar el límite de velocidad de los automóviles. El radar se instala, junto a su sistema de software que lo opera. Este mide la velocidad en que circulan los coches y toma fotografías a aquellos que exceden los 120 Km/h. A su vez, el software encargado de la gestión de multas, recibe las fotografías y la información pertinente a la infracción: fecha, hora, velocidad, matrícula, etc. busca en la base de datos el propietario del automóvil y le envía la comunicación de la misma vía correo postal.
La intervención humana es mínima, por lo que el sistema es altamente rentable.

Dado la belleza del paisaje, en varias oportunidades, la guardia civil ha advertido a varios turistas por circular por debajo de la velocidad mínima (60 Km/h). Esto dio como resultado que se pusiera en el radar un control extra, además de multar a quienes superen la velocidad máxima, este generará multas para aquellos que circulen por debajo de los 60 Km/h.

Se genera un requerimiento a la empresa que fabrica y mantiene los radares, el cual dice: Por la presente, solicitamos que, los radares operativos en la autopista AP-n sean adaptados para multar a todos aquellos que circulen por debajo de la velocidad mínima. A diferencia con las velocidades máximas, la multa será única para todo el rango de 0 a 59 Km/h, siendo la de más baja categoría y no se quitarán puntos por esta infracción.

El responsable de tomar los requerimientos de la empresa de radares lee estas líneas y entiende que tiene todo lo necesario, por lo que pasa la información recibida directamente al responsable de investigación y desarrollo. Éste, lee la definición del cambio y entiende que no es necesario cambiar nada en el hardware y que bastará con introducir unas pocas líneas de código para añadir la nueva funcionalidad solicitada, por lo que entrega esta definición a uno de los analistas de software para que desarrolle la documentación técnica.
El analista responsable del cambio en el software, genera la documentación técnica como un anexo a las especificaciones del resto de software que controla estos dispositivos, una vez hecho esto envía la notificación respecto a la disponibilidad de una nueva versión del documento técnico SGR50054-3-Anexo-Mínimos-AP-n.
Unos días antes del comienzo del desarrollo, se le asigna la tarea de verificar los requerimientos y ampliar los casos de prueba a un ingeniero de SQA quien recibe las especificaciones escritas por el cliente. Las compara con el documento técnico dónde no encuentra ninguna diferencia a reseñar. Una vez terminado este proceso, las especificaciones quedan verificadas.
Luego de esto, examina las clases de equivalencia y valores límite que ya existen para la validación del software actual, decide lo siguiente:
* Se elimina la validación <= 120Km/h ya que se vuelve redundante con las nuevas situaciones de prueba. * Se añade una nueva situación de prueba dónde <= 120 y >= 60 Km/h no se aplican multas.
* Se añade una nueva situación de prueba dónde = 60 no se aplica multa.
* Se añade una nueva situación de prueba dónde < 60 se aplica la multa de categoría 1. Finalmente, por su sencillez e importancia del caso, decide validar la frontera de esta nueva decisión con 3 valores: 59 - Aplica multa. 60 - No aplica multa. 61 - No aplica multa. Y con estas modificaciones, se dan por terminadas la modificación en los casos de prueba. El día planificado, da comienzo el desarrollo. El ingeniero encargado del cambio examina el código y añade las siguientes líneas, cometiendo un error no intencionado, por el cual introduce un defecto en el código:

Como se puede apreciar, en la nueva comparación de la velocidad, el desarrollado ha introducido un defecto. Este código multaría a aquellos que van a 60Km/h y los que van por debajo de esta velocidad. Es muy común encontrar que muchos fallos de software se encuentran debidos a defectos causados por errores tan simples como este, pero esto no debe engañarnos, este tipo de errores se han cometido y se seguirán cometiendo siempre. No es algo que se pueda evitar prestando más atención ni son un síntoma de incompetencia.

Una vez terminado el código y liberado el software, comienza el ciclo de pruebas dónde el ingeniero de pruebas utiliza un Driver para emular el hardware del radar y un Stub que cumple la función de emular el sistema de generación de multas. Al ejecutar las pruebas de frontera se produce un fallo, el error es reportado y, tras un nuevo release de código, se genera una nueva versión que es validada tras la repetición de la prueba funcional y las de regresión por el departamento de SQA.

Se realizan las validaciones de integración pertinentes, el software es instalado en producción y los radares comienzan a operar con su nueva funcionalidad.

Poco más de un mes después de estar funcionando perfectamente, en un solo día y durante el período de unas pocas horas, el radar en cuestión ordena emitir 1478 multas por conducción por debajo de la velocidad mínima permitida, velocidad a la que conducían todos los coches que circulaban por la carretera, debido a un atasco ocasionado por un automóvil averiado en la entrada de un túnel cercano.

Y hasta aquí llega la situación hipotética, que retomaré en un futuro post, dónde hablaré del Cálculo del ROI en SQA.

Ahora, analicemos algunos conceptos que suelen prestar a confusión:

Como primera pregunta, me gustaría saber si ¿ha habido una incidencia?
La respuesta es fácil:
Sí, no solo ha habido una incidencia, han sido 1478 incidencias. Si esto hubiera sucedido en la vida real, multitudes enardecidas aporrearían las puertas de la DGT desde antes que abriesen por la mañana. ¿Cómo no va a ser eso una incidencia?

¿La incidencia han sido producidas por un fallo de software?
¡¡¡Por supuesto que si!!! ¿A caso estaba mal la cámara fotográfica del radar? ¿A caso fue la antena lo que falló? No, nada de eso. El único origen de esta incidencia es el software que ordenó se fotografiaran los 1478 vehículos enviando al sistema de gestión de multas las órdenes para sancionar conductores incorrectamente.
Este software tiene un defecto que se ha manifestado en 1478 fallos.
Y una vez más, para los que estáis sacudiendo la cabeza de lado a lado:
¡¡¡ Afirmativo!!! ¡Es un fallo, producido por un defecto de software!

¿Es el cliente el responsable de este fallo?
No y nunca lo es. Es verdad que la solicitud no estaba completa, pero el cliente no tiene porqué conocer que otros datos podrían ser necesarios para el desarrollo del software, el cliente no desarrolla los radares, no conoce como funcionan internamente, que variables tienen en cuenta y que información vital podría estar omitiendo.
De hecho, muchas de las asunciones que llevan a los clientes de factorías de software a omitir información, son producidas por las experiencias de éxito casuales previas dónde tampoco especificaron más datos que los que consideraron importantes. Retomando el ejemplo hipotético, cuando se solicitó la primera funcionalidad de multar a los coches que circulen por arriba de los 120Km/h, no se dieron más datos y el radar lo hizo bien. Cuando se añadieron los rangos de multas por velocidad, también lo hizo bien.
¿Por que entonces ahora el cliente debería dar más información?
Decir que la responsabilidad de este fallo de software es de quien lo compra es completamente erróneo. Las empresas que desarrollan software, normalmente pagan un sueldo a uno o más profesionales para que tomen los requisitos. La toma de requisitos no es, como en la película "Office Space", llevar un fax hasta dónde están los desarrolladores de software. Por el contrario es un trabajo tan importante como el desarrollo o el control y aseguramiento de la calidad.

¿El desarrollador hizo bien su trabajo?
Si, generó un software que hacía lo que debía.

¿La verificación realizada por el ingeniero de calidad, fue correcta?
Si, comprobó que las especificaciones funcionales eran coherentes con la solicitud del cliente.

¿Se podría haber detectado este fallo en el departamento de aseguramiento de la calidad del software?
Si, tanto como se podía haber detectado durante el desarrollo, o el diseño funcional, o como lo podría haber detectado el encargado de I+D, o incluso el profesional que realizó las pruebas de integración. Este tipo de fallos podría haber sido detectado por todos aquellos que leyeron las especificaciones funcionales y/o la solicitud del cliente. Y los ojos y experiencia de los profesionales de SQA estuvieron ahí.

Para concluir: es erróneo es pensar que un software que se encuentra un tiempo en producción sin generar incidencias se encuentra libre de defectos. En mi caso hipotético el radar estuvo funcionando un mes sin que se genere ningún fallo, y eso no significa que no tuviera defectos de software.

Los fallos son la manifestación de los defectos de software, y un defecto de software, sin lugar a dudas, permanecerá oculto hasta que se den las condiciones necesarias, lo cual muchas veces no está relacionado con el tiempo y es impredecible.

Estimación del esfuerzo de las pruebas.

2011-03-14T12:33:00.000-07:00

Hoy voy a escribir sobre un tema tan necesario como trillado, la estimación de esfuerzo como actividad del aseguramiento de la calidad del software.

Cuando hablo de estimación no me refiero a levantar un dedo mojado al aire para saber en que dirección va el viento, ya que esto en el mejor de los casos, me dirá en que dirección sopla el viento, no a que velocidad, ni mucho menos, cuanto tardaré en probar un objeto de pruebas.

Decir que algo se puede probar en uno o dos días porque no es muy extenso ni complejo no es más que un dedo al aire.

Asumir que algo que se ha probado en el pasado utilizando n man/days, necesitará un esfuerzo similar también es un dedo al aire, un poco más preciso que el ejemplo anterior, pero no mucho más exacto ya que la métrica utilizada no es precisa y se están omitiendo factores significativos que podrían alterar el resultado.

Toda estimación formal requiere métricas correctamente realizadas y apoyadas en un procedimiento que las sustente. En mi experiencia y puntualmente en lo que a métricas de esfuerzo respecta, este procedimiento debe ser revisado y corregido tantas veces como se necesite hasta que funcione con la precisión deseada.

Son varias de las actividades de aseguramiento de la calidad del software, dónde normalmente es requerido estimar el esfuerzo, entre ellas está el análisis de requisitos, la generación de planes de prueba, la verificación de documentos y la validación de software, siendo esta última, la que tal vez, tenga mayor complejidad debido a la presencia de actores y componentes externos que, impactan de manera significativa en el esfuerzo. Sobre esta última voy a escribir a continuación, contando un poco mis experiencias y como las he resuelto.

Estimación del esfuerzo del testeo de software.

Las métricas globales habitualmente necesarias para realizar una correcta estimación, tanto para pruebas funcionales como no funcionales y automatizadas como manuales son:

Tiempo de preparación de las pruebas.
Generación de datos, preparación de testbeds, población de tablas, puesta a punto de herramientas, etc.
Tiempo de ejecución discriminada por caso de prueba.
Ya sea manual o automática, cada prueba debe estar medida de manera pura, sin incluir tiempos indirectos como ser el reporte de incidencias.
Tiempo medio en reporte de incidencias.
Progresión de incidencias para el proyecto.
Discriminando las nuevas incidencias de las regresiones y reaperturas.
Evolución del software.
Releases de objetos de prueba durante el ciclo de pruebas.
Tiempos de gestión de la prueba.
Escalabilidad de las actividades de prueba.

Es imprescindible contar con esta información a la hora de realizar una métrica correcta. La parte buena es que hoy en día existen herramientas que nos facilitan la tarea, haciendo posible afrontar los costes de la misma incluso en áreas de SQA reducidas.

A continuación os cuento la manera que conozco de afrontar este desafío:

Estimación del tiempo de preparación de las pruebas.

Es sin dudas la parte más fácil, ya que durante el diseño, a la hora de definir los testbeds se puede estimar este esfuerzo y normalmente es muy parecido entre el segundo y posteriores ciclos. Lo importante es tenerlo documentado y trazable de tal forma que, al seleccionar un conjunto de casos de prueba que vayan a ser ejecutados, se pueda conocer rápidamente el tiempo de preparación.
En muchos casos, esto será trivial ya que no será requerido nada especial, pero hay actividades de SQA que poseen complejas configuraciones, el uso de drivers, mocks y/o stubs dónde dependiendo las pruebas a ejecutar este tiempo puede variar.
Para trazarlo lo que suelo hacer es identificar y versionar los testbed e incluir el par ID/Versión en la documentación del plan. Es importante que la herramienta de gestión nos permita tener esta información a mano.

Tiempo de ejecución discriminada por caso de prueba.

Como siempre digo, gracias a Dios, los tiempos dónde los casos de prueba se guardaban en una hoja de cálculo han quedado en el pasado. Hoy en día existe una amplia gama de herramientas libres, como el famoso Testopia de Mozilla, que, además de guardar una excelente relación entre ejecuciones, casos de prueba, planes de prueba, productos, etc. permiten guardar el tiempo de ejecución individual de cada caso, para ello, posee una serie de botones que nos permiten indicar cuando comenzamos a ejecutar una prueba, cuando la pausamos, para ir a comer o reportar una incidencia, cuando continuamos con la ejecución y cuando la finalizamos, además de aportar un histórico de ejecución de cada caso.
En el caso de ejecuciones automatizadas, es necesario que la herramienta de ejecución se integre con nuestra herramienta de gestión a fines de registrar estos valores, como así también los resultados de las pruebas.
Respecto a la herramienta de recolección de datos, lamentablemente Testopia, al menos hasta su versión 2.3 no posee un apartado que lo permita, por lo que hay que implementar un script que calcule a la hora de generar nuevos test runs, el tiempo estimado de ejecución. La parte buena es que al ser datos muy bien estructurados que se albergan en una DB, el script es trivial. Así mismo, hay herramientas de pago que generan este tipo de informes.
Como parte del proceso, es importante concienciar a los usuarios de poner en play (comienzo), pausa (detener temporalmente) y finalizar cada caso que se ejecuta.
Además, el procedimiento debe contemplar que, al refactorizar casos de prueba, los nuevos deben tener un ID diferente para no ensuciar las estimaciones.
Otro punto importante a tener en cuenta en el promedio de tiempos de ejecución en los cálculos. Discriminando ejecuciones manuales de automáticas (esto último lo suelo realizar mediante el usuario de ejecución).

Tiempo medio en reporte de incidencias.

Este punto es posiblemente uno de los más difíciles de estimar con precisión, por lo que en mi experiencia, lo que más se acerca a la realidad es hacer una clasificación de las incidencias reportadas en función de factores que tengan implicación directa. Por ejemplo, si para reportar una incidencia de tipo X es necesario hacer capturas de pantalla e indicar como llegar a tal o cual menú, se le da un tiempo asociado a estas actividades, en cambio, si para reportar una incidencia del tipo Y, es requerido el entregar un snapshoot de la máquina virtual conteniendo un testbed configurado el tiempo asociado a esta acción es diferente.
La mejor manera de guardar esta información para tenerla trazable es añadir a nuestro bugtracker un campo obligatorio con los n tipos de incidencia que difieran significativamente en su tiempo de reporte.
Luego, al momento de estimar un nuevo ciclo, se suma al esfuerzo la proyección de las incidencias a reportar según el progreso de las mismas en cada ciclo.

Evolución del software.

Este punto también está muy emparentado con el formato del proyecto, en un mundo ideal no existe liberación de software durante un proceso de certificación, en la realidad esto no siempre se cumple en mayor o menor medida. El recibir nuevo software en la mitad de una certificación es sin dudas, la acción que más caos aporta a los valores de una estimación. Primero porque dependiendo de la magnitud de los cambios puede ser necesario re-ejecutar una parte importante de las pruebas, lo cual obliga a diseñar pruebas de regresión al vuelo que no estaban dentro de la estimación, así mismo el nuevo release fuerza a probar incidencias que no se encontraban resueltas al comienzo de la prueba, por lo que estaban fuera del alcance de las mismas.
De cualquier manera, si esto es una realidad que con cierta frecuencia se hace presente, no tenerla en cuenta a la hora de estimar es un error.
Por ello, tener un histórico de los releases que se producen durante un ciclo de pruebas, como así también de la magnitud de los mismos, nos ofrece un dato importante a la hora de contemplar factores para una estimación.

Tiempos de gestión de la prueba.

Toda actividad procedimental y formal de aseguramiento de la calidad del software requiere una gestión, esta parte del diseño de la ejecución/regresión y termina con el informe, pasando por varias actividades intermedias que varían según la empresa, el proyecto o el momento.
Es verdad que esta gestión varía de forma abismal entre empresas pero normalmente es muy similar dentro de un mismo proyecto, por lo tanto, el tener una casilla reservada para guardar este esfuerzo suele ser suficiente. Tal vez suene un poco obvio, pero he visto en más de una oportunidad olvidar este detalle y tener que consumir tiempos de pruebas para la gestión de las mismas.

Escalabilidad

Esta palabra que se ha vuelto popular desde que Fred Brooks escribió "The Mythical Man-Month", un libro que recomiendo ampliamente, también tiene su efecto a la hora de realizar estimaciones.
Si bien lo ideal es realizar las estimaciones en unidades horas/hombre, normalmente lo que nuestros clientes esperan son fechas, estoy convencido que sería millonario si me dieran un céntimo por cada vez que me preguntan ¿cuando estará esto validado?
Por ello es parte de nuestra tarea el convertir esas horas/hombre + prioridades en fechas. Esto parece simple, a bote pronto y en la teoría, la fecha fin de una validación sería la fecha de inicio + el cociente de las horas/hombre y recursos asignados, aunque a la práctica esto no suele ser cierto. Hay pruebas que no escalan por diferentes razones, que seguramente estáis recordando. De todas formas la escalabilidad es un dato que se puede registrar y tazar. En lo personal prefiero hacerlo a nivel plan de pruebas, y utilizando categorías que denomino "niveles de escalabilidad".

Conclusión

En resumen, como podéis apreciar, realizar una correcta estimación del testeo tiene requisitos indispensables pero no inalcanzables, incluso con un poco de ingenio es posible cumplirlos con muy poco esfuerzo.
De más no está recordar que el realizar estimaciones correctas, además de incrementar la confianza permite utilizar de manera más óptima los recursos.

Espero que os sea de utilidad, todo lo que aquí os cuento está basado en mi experiencia y conocimientos por lo que a mi me ha servido.
Lamentablemente no dispongo de todo el tiempo que necesitaría para documentar más en detalle algunos puntos pero como ya sabéis, podéis enviarme vuestros comentarios los que siempre estaré dispuesto a contestar.

Nueva ley contra las descargas ilegales.

2011-01-25T01:27:00.000-08:00

Ayer salió publicado en Larazon.es una noticia que hoy aparece en los noticieros matutinos, su título pone textualmente "Luz verde a la nueva Ley Antipiratería". Hace unos momentos, acabo de ver en la uno a Duran I Lleida hablando sobre el tema post-denegación de la ley sinde.

En principio quiero aclarar que hay un error de concepto, indudablemente inducido por quienes están a favor de este tipo de leyes y potenciado por los medios. Me refiero a llamar "Piratas" a quienes comparten.
Como ha dicho en incontables oportunidades Richard Stallman, un pirata no es quien comparte, un pirata es quien saquea ciudades y asalta naves en altamar.
El compartir es un deber social, compartir de hecho es un principio muy bueno y necesario de toda sociedad y no debería ser comparado con la acción de atacar naves, saquear o matar gente.

Los que están a favor de esta nueva ley tratan de engañarnos llamando "piratas" a quienes comparten, utilizando incorrectamente la palabra piratería, la cual en el diccionario aparece como actividades que realizan los piratas:
f. Asalto de barcos o de lugares costeros realizado por los piratas.

Os recomiendo ampliamente que echéis in ojo a este blog dónde aparece un vídeo de una entrevista hecha a Richar Stallman dónde expone el tema.

Dicho esto, si nos situamos en los objetivos de esta ley, que no van más allá de un motivo puramente económico por el cual un puñado de gente quiere hacerse de un negocio millonario que ahora mismo se les escapa, entendemos los motivos por los cuales quieren que se conozca como "Piratas" a quienes comparten.
En lo personal, creo que es muy importante, si no estamos de acuerdo con la ley, no apoyarla ni siquiera llamando Piratería a la acción de compartir.

Increíblemente, el efecto viral que tiene este mensaje es tan potente que muchos sitios serios utilizan íconos como calaveras con huesos cruzados, parches en un ojo, etc. para definir a quienes comparten e incluso a quienes se benefician de este bien social.

En lo personal creo que un buen ícono de la acción de compartir música, vídeos o programas por la red podría ser este:

(Foto: www.fondosgratis.com.mx)

Para terminar, os dejo esta reflexión personal: La nueva ley, a diferencia de la ley Sinde, ataca a quienes comparten pero no a quienes se benefician, decía hoy Duran I Lleida en el noticiero: "La ley es tan equilibrada que no están de acuerdo ninguna de las partes". Mi pregunta es: ¿Es esto algo equilibrado?

Estadísticas mentirosas

2011-01-19T00:51:00.000-08:00

A decir verdad, llevo tiempo viendo lo que ahora voy a contaros, en principio no era más que una presunción y por eso no he querido escribir esta entrada hasta tener datos fehacientes.

El motor de esta investigación ha sido, en gran parte, el ver en que datos en los cuales se fijan las empresas de software para seleccionar las plataformas que soportarán sus sistemas. Obviamente esta importante decisión la toman basándose en estadísticas, pero... ¿Que tan fiables son esas estadísticas?

En las pruebas que he hecho, he detectado información claramente falsa y contradictoria, pero las que más me molestan por ser descaradas son: las estadísticas de uso de navegadores y OSs.

Así mismo, el que esta información no sea fiel a la realidad, también produce un mal mayor: Mucha gente publica noticias a partir de estos datos, con lo cual, estas mentiras tienen un importante efecto viral.

Sin más preámbulos, comencemos a analizar un poco los datos que se encuentran en Internet, cuyas fuentes son utilizadas para tomar decisiones tan importantes como si un nuevo software soportará o no una plataforma o incluso que un periódico publique cual es el cliente de correo o el navegador más usado no siendo este un dato cierto.

Estadísticas de sitios más visitados:

Hoy en día, uno de los referentes a nivel mundial de las empresas, para determinar cual es la popularidad de los sitios web es Alexa: una empresa que se dedica exclusivamente a las estadísticas web.
Esto a simple vista tiene bastante sentido, tomar las estadísticas de sitios de una fuente cuya principal actividad es recolectar información y generar estadísticas.
Pero si prestamos atención a sus fuentes de datos, veremos que estas estadísticas están considerablemente alejadas de la realidad.
Alexa toma sus datos única y exclusivamente de su barra de navegación, la cual ofrece como un componente de IE y recientemente de Firefox.
En principio, las barras de navegación de los navegadores son componentes tan populares que cada sitio importante nos ofrece la suya. Como todo producto tiene un público específico y no todos queremos instalar una barra de navegación. Así mismo, si ya tenemos una instalada difícilmente nos atrevamos a instalar otra.
Además, si bien Alexa es una fuente importante para las empresas, no es muy popular, y si a esto le sumamos que, hasta hace muy poco tiempo, esta barra estaba solo disponible para Internet Explorer y siendo software privativo, hay mucha gente que por principios no la instalaría jamás, la conclusión es que las estadísticas que ofrece Alexa, se encuentran extremadamente cribadas y no me extraña que muestren que el sitio web de Microsoft tenga muchas más visitas que la Free Software Foundation.
Conclusión: Aun suponiendo que Alexa realice bien la contabilidad de visitas, la fuente de datos no se parece en nada a la realidad y no debería ser considerada como muestreo/fuente fiable a la hora de tomar decisiones.
La duda que me queda es ¿Cuantas empresas realizan el análisis que acabo de hacer antes de confiar en esta información?

Estadísticas sobre el uso de OSs:

Este sin dudas es un dato muy importante, ya que como dije al principio, tiene un papel fundamental al decidir el soporte y el rumbo de muchos productos en muchas empresas. El principal proveedor de estos datos es el famoso W3Counter. El punto es que también colocan al OS de Microsoft excesivamente arriba del resto de lo OSs. Esto despertó mis dudas y decidí hacer mis propias pruebas:

He colocado un contador de W3Counter junto al de Google para el mismo sitio: Mi Blog, el resultado ha sido el esperado por mi: para un mismo período de tiempo, Google y W3Counter muestran datos estratégicamente diferentes.

Según el W3Counter, en el último mes, mi blog ha sido visto por 310 visitantes únicos, los cuales utilizaron los siguientes OSs:

Asumiendo que cuando dicen Linux en realidad se refieren al sistema operativo GNU con Linux, las estadísticas son las siguientes:

OS	%
GNU-Linux	39%
Windows XP	30%
Windows 7	16%
Windows Vista	5%
Unknown	4%
Mac OS X	3%
BlackBerry	1%
iPhone OSX	<1%

En principio es normal que GNU-Linux ocupe con diferencia el primer lugar, ya que mi blog tiene un público específico. La parte buena es que nadie va a tomar estas estadísticas para tomar decisiones.

Ahora veamos que dice Google para el mísmo período de tiempo:

OS	%
Windows	56,00%
Other Unix	39,00%
Macintosh	2,00%
BlackBerry	<1%
iPad	<1%

Según el W3Counter GNU con Linux ocupa el 39%, casualmente lo mismo que dice Google que ocupa "Other Unix", GNU-Linux no es Unix, de hecho y para los que no lo saben, GNU es el acrónimo redundante en inglés de GNU no es Unix. Entonces ¿Por que Google no pone GNU o Linux como hace la W3Counter?
Google usa el núcleo Linux para muchos de sus productos, como por ejemplo el Android, por lo tanto no creo que el desconocimiento sea lo que haga que llame Unix a GNU.

Otro dato curioso es que si sumamos los valores de XP, Vista y 7 de las estadísticas de W3Counter nos da un 51%, mientras que Google agrupa todo en la categoría Windows, pero para sumar el 56% que Google marca como Windows, es necesario añadir la categoría que la W3Counter entiende como Unknown (desconocido). ¿Será que Google asume que si no sabe que OS es, entonces es Windows?

Siguiendo con el análisis, Mac OSX difieren en un 1% sobre el ínfimo total de 300 visitas, esta diferencia es inadmisible ya que si la extrapolamos, puede que queden fuera del Top10 OSs que realmente tengan participación. Pero ¿quien está errado? Personalmente no le creo a ninguno de los dos. Es increíble que con la misma fuente de datos, muestren información diferente.

Estadísticas sobre uso de Navegadores Web

Haciendo la misma prueba que con los OSs, con los navegadores las diferencias son bastante más descaradas, con el fin de no hacer un mega-post, voy a comentaros los datos que encuentro más representativos:

Ambos dicen que Firefox es el navegador más usado, sumando el desglose que W3Counter realiza por cada versión de Firefox, nos da que el 60% de las visitas han sido hechas con alguna versión de Firefox, por otra parte Google dice que el 45% ha sido Firefox y que el 15% Ubuntu. Curiosamente sumando ambos nos da el total de 60% que la W3Counter totaliza para Firefox, lo que me llama la atención es que Ubuntu es una distribución de GNU, no un navegador, entonces ¿Con que objetivo Google los divide?

Otro punto a tener en cuenta es que Google suma un 18% en su estadística de uso de Chrome (su propio navegador Web) mientras que W3Counter le da 14%. Comparando el resto de datos, el 4% faltante sale de Mozilla 1.4 ¿Será que Google contabiliza las navegación hecha con Mozilla como propias?

Estadísticas sobre clientes de correo electrónico:

Como muchos ya sabéis, me dedico al aseguramiento de la calidad de software de seguridad informática, por lo tanto gran parte de mi trabajo consiste en administrar testbeds que deben ser lo más parecidos a la realidad.
Realizando esta actividad, hace un par de meses, me encontraba extendiendo un emulador de clientes de correo propio, cuya misión es emular el dialogo POP3, SMTP e IMAP que tienen los clientes más utilizados. Fue así que he dado con las estadísticas de uso de Litmus.

Si echamos un ojo a la siguiente tabla (fuente: http://litmus.com/resources/email-client-stats) veremos que Outlook posee el 43% del mercado mientras que GMail solo el 5%, también veremos que Thunderbird posee solo el 2.5.

Email client		Market share
	Outlook Outlook 2003 and earlier Outlook 2007	43% 34% 9%
	Hotmail	17%
	Yahoo! Mail	13%
	Gmail	5%
	Apple Mail	4%
	iPhone	4%
	Thunderbird	2.4%
	Windows Live Mail (Desktop)	2%
	AOL Mail	1.2%
	Lotus Notes	0.4%
	Others	8%

Si bien estos datos, a simple vista, a muchos nos resultan falsos (Ya que si realmente Outlook fuera usado diez veces lo que GMail, Microsoft solo se dedicaría a ese producto), no tengo la certeza de que en el muestreo que Litmus ha realizado, estos datos no hayan salido así.
Tampoco es público el mecanismo que han utilizado para realizar la medición, por lo que perfectamente podría ser que son los mails que recibe info@microsoft.com, cosa que explicaría por que Outlook tiene 10 veces más mercado que GMail.
Conclusión: No puedo decir que esta estadística sea falsa, pero al no estar pública la forma en la que se realiza, desde mi punto de vista los datos no son fiables.

Conclusiones

Como conclusión general del post, quiero decir que en general la información estadística de uso que hoy en día encontramos o bien se encuentra cribada por lo que no es del todo real o se encuentra manipulada por intereses económicos de grandes empresas que tienen el poder que asociaciones de software libre no tienen. De cualquier forma, la manipulación de la información siempre es mala y el utilizarla implica el dejarnos manipular. Lamentablemente hoy en día las empresas que se dejan manipular por estos datos constituyen la gran mayoría.

Mis primeros pasos con OpenGL

2011-01-16T00:09:00.000-08:00

Siendo esta mi primera entrada del año, ante todo quiero desearos un: Muy Feliz Año.

Respecto al título de la entrada: así es, he llegado un poco tarde a esta tecnología que prácticamente es del 92'. Aunque lo bueno de llegar 10 años tarde a algo es que ya hay mucho hecho.

A decir verdad, hace aproximadamente unos seis meses, cree mis primeros esbozos de lo que sería una pantalla de un juego, mientras aprendía con el famoso NeHe. Durante estos meses, he dedicado tiempo a investigar las direcciones de los múltiples caminos que pude visualizar como necesarios para alcanzar mi objetivo: realizar un motor y editor para juegos 2.5D similares al popular Double Dragon.

Durante mi recorrido por estos sinuosos caminos, me he ido encontrando con dificultades que, en mayor o menor medida, hasta el día de hoy he logrado superar. No obstante, muchas de ellas me han sorprendido, por ser situaciones por las que todo aquel que se haya embarcado en una empresa como la mía tuvo que sortear y, para mi gusto, se encuentran muy poco o nada documentadas.

Así como me gusta pensar que una entrada en un blog debe aportar algo, también cuando tengo algo para aportar me gusta crear una nueva entrada. Esta entrada va justamente, de mis primeros tropezones en el camino de la programación con la Open Graphics Library.

Seleccionando una interfaz adecuada

Al igual que aquél día que relegué a Debian exclusivamente a ser el OS de mis servidores, poniendo Ubuntu como único sistema operativo de mi PC de escritorio y portátiles, o el día que comencé a utilizar PlayOnLinux, ya que era un dolor de cabeza hacer funcionar cada uno de mis juegos con distintas versiones de wine, cuando persigo un objetivo claro, quiero alcanzarlo cuanto antes, y el aprendizaje que pueda realizar es residual o innecesario, prefiero hacerlo mediante las herramientas disponibles que puedan ofrecerme atajos para conceguirlo.
Mis primeros pasos en la programación con OpenGL no han escapado a este principio, por lo que seleccioné la librería SDL como una capa de abstracción que me simplificaría la vida a la hora de tratar con los gráficos, sonido e interfaces de entrada: teclado y ratón.

La librería la encontré porque me la recomendaron y la elegí al ver que todos los ejemplos del NeHe tienen un juego de fuentes hechos con la SDL y que soportaba múltiples plataformas: GNU con Linux, Google Android, OpenVMS, Syllable, WebOS, Mac OS X, OS 9, PSP, AmigaOS, Haiku/BeOS, MorphOS y otros.

De esta manera además de ser más simple mi trabajo, será portable en el caso que quiera distribuirlo para otras plataformas.

Cargando PNGs como texturas.

Cuando comencé a hacer mis primeras animaciones, siguiendo los ejemplos del NeHe, el formato que usaba para leer las imágenes de una textura era el BMP. La SDL trae una función-macro para hacerlo SDL_LoadBMP(), la cual carga una imagen con esta finalidad.

En el momento en que decidí comenzar a perseguir mi objetivo, me decidí por PNG como formato gráfico libre, por soportar imágenes de 32 bits en RGBA y tener compresión sin pérdida (lossless).

No daba crédito a lo que veía: la SDL no trae un método para cargar PNGs. Googleé un poco y encontré que había una exención de la misma biblioteca que lo hacía: SDL_image. El tema es que no iba fino, tenía algunas complicaciones y ante mis preguntas en foros la respuesta que obtuve en general fue: "La SDL soporta BMP's, usa ese formato".

Sorprendido y negándome a cambiar de rumbo, busqué un poco más y encontré la biblioteca SOIL Simple OpenGL Image Library, que tenía justamente métodos para la carga de PNGs. El tema fue que tampoco funcionaban y al buscar encontré en foros que otros tenían los mismos problemas que yo y no estaban solucionados.

Tropezón no es caída, y pese a haber invertido un considerable tiempo en dos intentos fallidos, decidí comentar mi problema con unos colegas que se encuentran desarrollando juegos. Para mi sorpresa, ellos me dijeron lo mismo que yo estaba suponiendo: Cada uno había implementado la lectura de imágenes a partir de código propio y no conocían la existencia de una librería estándar que funcionase bien a la hora de cargar un PNG.

Como la licencia del juego que uno de mis colegas estaba haciendo era igual que la de mi proyecto: GPL3+, le pedí que me compartiera su clase de lectura de imágenes PNG, lo que hizo amablemente.

Fue así como resolví este increíblemente común problema, y este fue el motor de esta entrada en mi blog. A continuación os dejo un link al proyecto que he creado con el único fin de compartir las soluciones que hasta ahora he dado a los desafíos con los que me he topado: http://code.google.com/p/dde/source/checkout

Administrando Sprites.

Este es un tema de los que más vueltas le he dado, sobre todo porque, si bien es un asunto normal y corriente de diseño, que ha sido abordado cada desarrollador de videojuegos, he encontrado mucha diversidad en las soluciones.

Voy a comentaros aquí como lo estoy encarando hasta el momento, lo que tengo hecho y lo que pienso hacer, aunque no descarto la posibilidad que, en una posterior entrada dónde hable de OpenGl, haya cambiado el rumbo.

Para mi un Sprite es una entidad que, debe manejar sus propias imágenes (a los que he llamado frames), debe ser capaz de animarse coherentemente, debe manejar su movimiento, debe conocer su posición en el mapa, debe disparar los eventos relacionados a él, como ser sonido y activación de etapas del juego, debe contener sus propiedades de daño, vidas, energía, movimientos posibles, etc.

Hago este preámbulo porque he visto algunos diseños dónde el Sprite se considera solo la representación gráfica de una entidad que puede ser un enemigo, un NPC, o telón (decorado).

Dicho esto, una de las cosas que el Sprite maneja son sus movimientos: Un Sprite es capaz de moverse en diferentes direcciones y requiere ir cambiando imágenes (frames) que lo animen. Esto lo resolví con una lista de listas circulares.
Cada una de las imágenes de una animación del Sprite, por ejemplo cuando camina hacia la derecha, son guardadas en una lista circular con un enlace simple, entonces, cada vez que surge el evento de avanzar a la siguiente imagen de la animación, actualizo el puntero que apunta a la lista por el siguiente. Este truquillo lo puedo hacer gracias a que las imágenes de las animaciones de los sprites suelen ser cíclicas.

A su vez, solo genero texturas del Sprite moviéndose a la derecha, como las de la izquierda normalmente son iguales a las de la derecha, si no las cargo, automáticamente se toma el movimiento opuesto e invierte los valores de las coordenadas de las texturas para que se pinten al revés. De esta manera, cuando el Sprite "camina" hacia la izquierda, utiliza las mismas imágenes que al hacerlo hacia la derecha.

Por ahora no he avanzado mucho más con los Sprites, aunque me encuentro trabajando en ello.

Administrando Mapas (Carga).

Como la idea es hacer un game engine (motor de juegos), una de las premisas es: evitar el hardcode, es más, me arriesgo a afirmar que la premisa más importante es la parametrización. De esta forma, desde los comienzos he tenido en mente cargar (y grabar) los mapas desde ficheros.

Supongo que podríais estaros preguntando ahora mismo... ¿Que es lo que entiende como un mapa?

Para mi un mapa es la representación de un segmento de juego, este contiene todos los objetos que se encuentran en dicho segmento, como así también sus posiciones iniciales. Los Sprites también son parte de un mapa.

Para cargar mapas, mis colegas que me llevan buena ventaja en estos menesteres, me aconsejaron que en principio utilice ficheros de texto, ya que se pueden leer sin necesidad de un programa, lo cual ayuda a desarrollar y detectar fallos relacionados a la carga más rápidamente.

Con esta premisa escogí XML como formato de mis mapas, apoyándome en la biblioteca de Apache: xerces, actualmente cargo los Sprites desde un XML y pronto, Dios mediante, tendré la carga de mapas lista.
(Podéis ver el ejemplo en mi código en el fichero: filemanager.cpp)

Hasta aquí os he contado un poco mis primeros pasos en OpenGL, no pienso detenerme aquí, así que es probable que en unos meses estéis leyendo la continuación de esta entrada.

Espero que os haya gustado, que os sea de utilidad y como siempre estaré encantado de leer vuestros comentarios.

Modelos de desarrollo de software: Cascada vs V.

2010-12-25T05:31:00.000-08:00

Suele entenderse al modelo de desarrollo en V como la evolución del modelo en cascada. Si bien no estoy completamente en desacuerdo con esta afirmación, creo que no es del todo afortunada, ya que insinúa que en todos los escenarios, el modelo en V será mejor.

Desde su aparición a nivel mundial, hace más de veinte años, se han escrito mares de tinta respecto al modelo en V, en esta entrada no voy a describirlo en mayor detalle, ya que lo que intento es aportar ideas y conocimientos basados en experiencias. Toda entrada en un blog debería intentar hacer lo mismo ¿no es así?
Bueno, al menos yo lo intento y espero que mi aporte os sea útil aunque recomiendo para ello tener una base de conocimiento sobre ambos modelos.

Para ilustrar mi experiencia con el modelo de desarrollo en V, necesito antes comentar algunos puntos sobre su predecesor, el modelo en cascada.

El modelo de desarrollo en cascada o Waterfall.

Al igual que muchas otras definiciones, el modelo de desarrollo en cascada, también comúnmente llamado por su nombre en inglés "waterfall model", no es más que el nombre que se le dio al proceso de desarrollo que normalmente se utilizaba desde mucho antes de aparecer el término.

Su nombre mantiene una doble analogía, ya que al igual que cae el agua en una cascada, avanzar en un desarrollo a través de los escalones que representan las etapas del modelo es fácil y muy rápido, por el contrario, cuando hay que corregir algo, es muy costoso ascender contra de la corriente.

Es un modelo natural, que lejos de ser inventado por alguien como un estándar a seguir, surgió de forma intuitiva, espontánea y paralela en todo el mundo.

Normalmente suele ser dibujado con solo cuatro etapas: Análisis, Diseño, Codificación y Testing, no obstante, la esencia del modelo no está limitada por la cantidad de etapas o faces que se utilicen. En realidad su enfoque define una sola limitación: "La dependencia estricta entre las faces del ciclo de vida del software".

A diferencia de otros, el modelo en cascada no requiere una cantidad de actores determinada, por lo que distintas faces pueden ser llevadas a cabo por el mismo profesional, permitiendo así ser utilizado en pequeños equipos de desarrollo dónde el análisis, el diseño y la codificación podrían ser ser realizadas por la misma persona.

Los modelos más avanzados como el modelo en V o el modelo en W, utilizan al modelo en cascada, ya que las rectas que dibujan esas letras, no son más que la implementación de un model en cascada. En estos, a diferencia del modelo en cascada, existen ángulos dónde se permite "girar", para ascender en la cascada.
Desde mi punto de vista, el modelo en V no es más que dos cascadas unidas por un ángulo.

Los que hemos tenido la suerte de presenciar la formación de un equipo de desarrollo de software, entendiendo por desarrollo no solo a la codificación, sino a todas las etapas del ciclo de vida del software, vimos como al embonar los procesos de cada etapa, naturalmente surgía un modelo en cascada.

Hoy en día este modelo se encuentra fuertemente criticado, a pesar que su uso sigue muy extendido en todo el mundo. Personalmente no creo que sea criticable y el usarlo no es algo de lo que avergonzarse.

Por otra parte, si existen en un equipo de desarrollo los procesos y recursos para utilizar un modelo más avanzado, como el V, y se sigue utilizando el modelo en cascada, es importante realizar los ajustes necesarios a los procesos para minimizar costes con poco esfuerzo.

El modelo de desarrollo en V.

Una vez más, recuerdo un poco lo que he comentado el el preámbulo de esta entrada, mi intención no es describir este modelo, por el contrario intento dar mi visión y aportar conocimientos que he adquirido en la experiencia trabajando con el mismo. Si lo que buscas es la descripción del mismo, te recomiendo que vayas a otra página, por ejemplo la wikipedia, dónde es perfectamente explicado.

Desde mi particular visión y sabiendo que es posible sea criticado por dar esta definición: El modelo en V es una representación de dos cascadas enfrentadas y relacionadas, con su vértice en la codificación como punto en común.

Este modelo que sí fue diseñado como tal, propone una cascada a la izquierda, con las actividades relacionadas al desarrollo propiamente dicho, y una a la derecha con las actividades del aseguramiento de la calidad del software.

El indiscutible punto a favor respecto al cascada, aunque no a otros como el W, Espiral, Incremental, Helicoidal, etc. es que las actividades de ambas cascadas de la V se realizan en paralelo y en el mismo ciclo, subdividiendo así la V en varios ciclos, normalmente cuatro.

Es por ello que, a pesar de no representar otra cosa que dos cascadas enfrentadas, su representación gráfica es la V, ya que durante las verificaciones y/o validaciones que se apliquen en cada ciclo se permite reajustar y reiniciar el ciclo, eclipsando las posibilidades que un defecto inherente a un ciclo llegue al siguiente.

Como modelo de desarrollo es más óptimo que utilizar una cascada pura, pero requiere ciertos actores y procesos que no siempre se encuentran disponibles. Luego de una ponencia que realicé hace unos días en mi empresa sobre este modelo, hicimos un pequeño y entretenido ejercicio de identificación de diferencias entre nuestro modelo y el modelo en V tal y como TMAP lo describe. El resultado fue que si bien nos acercamos bastante, carecemos de alguna etapa que simplificamos en otra, de esta manera, no generamos cierta documentación necesaria para la interacción con la otra cascada en un ciclo determinado.
Una vez que quedó esto plasmado en la pizarra, creo que todos coincidimos en varios puntos:
* El modelo de desarrollo está muy relacionado con la cultura de la empresa.
* El no poseer un modelo en V completo con todas sus etapas, ciclos y relaciones no es algo malo.
* El tratar de ajustar el modelo de una empresa, a uno predefinido, cuando esto implica la modificación/creación de procesos que solo cumplirán la función ad-hoc de respetar el modelo, indudablemente generará un coste que no será retribuido.
* El identificar las diferencias entre un modelo estándar y el existente en una empresa es algo muy bueno. Puede permitirnos identificar pequeños ajustes que derivarán en beneficios de bajo coste.

Creo que estos últimos puntos redondean un poco lo que quería expresar, solo voy a añadir como punto final que no creo que haya modelos malos, solo hay mejores y peores y saber identificar el momento más apropiado de un proyecto para dar el salto a un modelo mejor es una tarea compleja, que requiere experiencia, muy necesaria y que debe ser realizada con cierta periodicidad.

Como supongo este será el último post del año, os deseo a todos muy felices fiestas y un prospero año nuevo.

Contradicciones de los conceptos en SQA

2010-12-12T04:16:00.000-08:00

Según el diccionario de la lengua española, una contradicción es una afirmación y negación que se oponen una a otra y recíprocamente se destruyen.
Los conceptos, terminología, glosarios e incluso muchos métodos del aseguramiento de la calidad del software se encuentran contradichos en distintos estándares, metodologías o procesos generados a partir de conjuntos de metodologías. Incluso la definición de Testing suele variar entre autores de bibliografía.
Desde sus comienzos, se han escrito mares de tinta respecto a conceptos y definiciones de la calidad del software.
Al día de hoy, es bastante fácil encontrar contradicciones en estos conceptos, no solo en libros, sino también en ponencias, cursos, e incluso en conversaciones o entrevistas. Sin ir más lejos, en una de las últimas conferencias de las que he participado, he escuchado más de un concepto contradictorio respecto a los que se dijeron en la misma conferencia, ese ha sido el motor que me ha impulsado a escribir esta entrada.

Muchas de estas contradicciones suelen ser semánticas, simplemente llamar a algo de una forma distinta, si bien estas son las menos importantes, el hablar un mismo idioma es fundamental a la hora de comunicar y entender objetivos. Es por ello que personalmente las pongo a todas en el mismo nivel.

Podría aquí exponer las contradicciones que recuerdo, que me molestan y que más discrepan entre sí, pero eso no aportaría nada nuevo. Por el contrario voy a comentar las definiciones que según yo, son más exactas, las que más me gustan y lo haré ilustrando el caso según crea necesario.

Soy consciente que esta tarea no es minúscula ni trivial y que seguramente esta entrada quedará chica, pero por algún lado hay que empezar y me gusta dejar cosas en el tintero que den a lugar a futuras entradas que continúen este texto.

A continuación, la reducida lista de conceptos y términos que, ahora mismo recuerdo y se suelen contradecir:

Error, Defecto (defect) y Fallo (failure)

Voy a comenzar hablando de tres palabras que muchas veces se encuentran mezcladas, incluso en un mismo párrafo he escuchado utilizarlas como si fueran sinónimos por importantes profesionales del aseguramiento de la calidad del software.

Desde el punto de vista de SQA, lejos de ser sinónimos, cada una de estas palabras significan cosas distintas y, como todo componente de la comunicación, es importante saber utilizarlas e interpretarlas.

Error: Es un concepto puramente humano, los ordenadores y el software no se equivocan, hacen exactamente lo que su configuración, condiciones y codificación dictan y nunca comenten errores. Por el contrario, los seres humanos tenemos la capacidad de cometer errores, cuando un desarrollador comete un error básicamente escribe código que funciona diferente a lo que él espera. Los errores cometidos durante el desarrollo de cualquier programa no trivial son inevitables.

Defecto: Un defecto de software es el resultado de un error durante algún proceso de la generación del software. Los defectos pueden ser evidentes o permanecer ocultos por siempre. Todo software no trivial posee defectos incluso luego de sus etapas de aseguramiento de la calidad.

Fallo: Un fallo es la manifestación de un defecto introducido en el código, los fallos solo se manifiestan al ejecutar el código que posee defectos.

Una oración que me gusta e ilustra el correcto uso de estas tres palabras es: Los desarrolladores de software, al ser humanos inevitablemente cometen errores, introduciendo defectos en el software que se manifiestan como fallos al ejecutarlo.

Incidencia (issue)

Esta palabra es la más apropiada para identificar y documentar un defecto de software. Debido a que un fallo en el sistema no siempre se debe a un defecto del software, se llamará Incidencia cualquier tarea que describa un comportamiento no esperado, incluso cuando esta se encuentre confirmada como un defecto.

Una contradicción común es llamar al software de gestión de incidencias "Bug tracker", las herramientas más modernas que cumplen estas funciones, por utilizar una palabra conocida, continúan usando el termino "Bug tracker" o "Sistema de seguimiento de defectos" en lugar de "Issue Tracker" o "Sistema de seguimiento de incidencias".

Los dos siguientes términos, además de encontrarlos contradichos, muchas veces los he escuchado utilizar indistintamente, como si se tratase de sinónimos:

Validación (validation)

Confirmación mediante pruebas y el suministro de evidencia objetiva de las mismas, que demuestren que los requisitos para un uso específico previsto de aplicación se han cumplido.

Verificación (verification)

Confirmación mediante análisis y el suministro de evidencia objetiva de que los requisitos especificados se han cumplido.

Los tres siguientes terminos van encadenados, los pongo juntos para poder llegar al enfoque de la prueba, haciendo que este sea comprensible:

Nivel de prueba (test level/test stage)

Grupo de actividades de testing que se organizan y administran juntos. A nivel de testing, está vinculada a las responsabilidades de un proyecto. Por ejemplo: las pruebas de aceptación, integración y sistema son niveles de prueba.

Estrategia de prueba (test strategy)

Una descripción de alto nivel de los niveles de prueba a realizar.

Enfoque de la prueba (test approach)

La aplicación de la estrategia de prueba para un proyecto específico.

Entorno de prueba (test bed/test environment)

Un entorno controlado, documentado y reproducible que contiene el hardware, la instrumentación, simuladores, herramientas de software y otros elementos de apoyo necesarios para llevar a cabo una prueba. En España comunmente se les suele llamar también "Maqueta de pruebas", término que particularmente me agrada ya que una maqueta no deja de ser un modelo en tamaño reducido de una construcción.

Respecto a los siguientes términos, más que una contradicción, suelo encontrar que "Driver" casi no se usa y "Stub" se usa como sinónimo del primero. También he escuchado muchísimas formas de referirse indistintamente a ellos, incluso algunas muy graciosas como "Tapón", "Emulador", "Simulator", "Respuesta escrita en piedra", ect. La diferencia es tan clara como pensar que "Driver" y "Stub" son lo mismo, solo que el "Driver" realiza llamadas a un componente que queremos probar o desarrollar y los "Stubs" son aquellos llamado por un componente existente. A continuación las definiciones que más me gustan para ambos (Según el IEEE 610):

Drivers (no encuentro una traducción al español que me guste)

Un componente de software o una herramienta de pruebas que reemplaza a un componente que se encarga del control y/o la llamada de un componente o sistema

Stub (Debido a su extendido uso, creo que no es bueno traducir este término)

Una implementación "equeleto" o de propósito especial de un componente de software, utilizada para desarrollar o probar un componente que la llama.

SQA o Software Quality Assurance

Esta sigla, comúnmente utilizada como "testing", "pruebas de software", o incluso en uno de sus variantes más acertadas, para nombrar al departamento o área que se ocupa del aseguramiento de la calidad, tiene un significado muy distinto: "Aseguramiento de la calidad del Software". Pero... ¿Que es el aseguramiento de la calidad del software?

SQA es un conjunto de actividades sistemáticas que aseguran que el proceso del software y productos conformados por requerimientos, estándares, y procedimientos cumplen con las especificaciones. Y su principal objetivo es asegurar la calidad del software.

De todas las definiciones de SQA, y os aseguro que hay muchas, esa es la que más me agrada. En una versión más reducida, se puede decir que SQA es la actividad por la cual se comprueba que un software cumple con las especificaciones.

Respecto a su objetivo, hay también una definición por autor, hay quienes dicen que sirve para conocer la calidad de un componente de software. Este concepto no está mal pero es incompleto. Un proceso de aseguramiento de la calidad no termina cuando conocemos el estado de la misma. Un correcto proceso de SQA debe terminar cuando se ha asegurado que la calidad del software cumple los mínimos establecidos. Entonces, proceso de SQA sirve para conocer la calidad, también sirve para dar confianza y para muchas otras cosas pero su principal objetivo es asegurar la calidad del software.

Calidad Total

Este concepto, también es muy entretenido, ya que lo que representa simplemente no existe. Calidad Total en SQA significa que un software se encuentra libre de defectos en todas las situaciones posibles en las que se ejecute. Esto solo puede ser aplicable a programas realmente triviales, un "Hola mundo" podría tener calidad total, un programa más complejo que eso, definitivamente no la tendrá por más recursos que se inviertan en el aseguramiento de la misma.

Para ilustrar un poco lo dicho hasta ahora, a continuación planteo una situación hipotética, donde podremos entender muchos de estos conceptos.

* De Radares y velocidades mínimas.

Para concluir y retomando el tema central del post, otro concepto erróneo es pensar que un software que se encuentra un tiempo en producción sin generar incidencias se encuentra libre de defectos. En mi caso hipotético el radar estuvo funcionando un mes sin que se genere ningún fallo, y eso no significa que no tuviera defectos de software.

Los fallos son la manifestación de los defectos de software, y un defecto de software, sin lugar a dudas, permanecerá oculto hasta que se den las condiciones necesarias, lo cual muchas veces no está relacionado con el tiempo.

Google AI Challenge (Sep-Dic 2010)

2010-12-02T15:19:00.000-08:00

Hoy os voy a contar sobre esta competición, que recientemente me he enterado que existía y con la que disfruté muchísimo participando.

Me refiero al Google AI Challenge, que comenzó este año el 1 de Septiembre, para finalizar ayer, 1 de Diciembre.

Para los que no la conocéis, de hecho creo que no es muy popular, Google AI Challenge es un concurso de inteligencia artificial organizado por el club de ciencias computacionales de la universidad de Waterloo, y patrocinado nada menos que por Google.

A pesar de estos representantes no ha tenido demasiada adición, en la etapa final del concurso solamente éramos 4617 concursantes. Aunque sí ha sido ampliamente aceptado en todo el mundo con 112 países participantes.

Con esto, un poco la idea de esta entrada en mi blog es divulgar en concurso a fines de ser muchos más para el próximo.

Si bien me enteré de la existencia de este desafío durante esta competición, esta no es la primera, y me he quedado con ganas de participar en la anterior, dónde el juego en cuestión era el famoso "Snake" o "Tron" como lo han llamado debido a la famosa película.

El Juego

Creo que no podían estar más acertados con el juego elegido, en esta oportunidad ha sido el famoso Galcon, el cual se puede jugar gratuitamente on-line desde este link. El organizador decidió rebautizarlo "Planet Wars".

La idea es la misma que en la competición anterior, programar un "Bot" que compita contra los bots creados por otros concursantes y les gane a todos jugando el juego.

Cuando digo que no podía estar más acertado, es porque, si bien la complejidad del mismo es muy alta, permitía un amplio gradiente de estrategias que íbamos aprendiendo a medida que el juego avanzaba. Así mismo, cuando algún participante subía una versión de su "Bot" más avanzada y comenzaba a tener éxito, su nueva técnica no tardaba en ser copiada, de esta manera descubrí que enviar las naves al frente era mucho mejor que tenerlas detrás.

Complejo y abordable a la vez, el "Planet Wars" sin dudas, ha sido una excelente elección que nos ha dado mucha diversión a cambio de unas cuantas horas de quebraderos de cabeza.

El desarrollo

Había para elegir varios lenguajes por lo que cada uno podía seleccionar el lenguaje con el que se sienta más cómodo a la hora de hacer el bot. Particularmente preferí el C++, que es el que uso a diario desde ya hace unos cuantos años y sin dudas, con el que me siento más cómodo.

La parte buena, es que los organizadores han hecho tan, pero tan bien la competición, que solo había que preocuparse por el problema en sí. En el "starter package" de C++ por ejemplo, había una función llamada DoTurn, que recibía por parámetro una referencia a un objeto de la clase PlanetWars, la cual tenía todos los métodos necesarios para poder conocer el estado del juego y realizar los movimientos necesarios para ganar la partida, además de algunos cálculos útiles, como ser el método Distance que entregaba la distancia en turnos entre dos planetas.

Lo único que había que hacer era escribir el mejor bot posible y ganar el concurso. :o)

Además el "starter pack" traía un pack de 100 mapas perfectamente balanceados y una representación gráfica del juego hecha en Java, que nos permitía jugarlo en local para probarlo antes de subirlo a la competición.

El calendario

El 1 de Septiembre fueron liberados los materiales de desarrollo para que pudiéramos comenzar a trabajar en el bot.
El 10 de ese mismo mes, fue el comienzo oficial, dónde ya podíamos crear una cuenta y subir nuestro bot, como así también ver el ranking mundial.
El 27 de Noviembre fue el último día en que se aceptó código con nuevos Bots, luego de lo cual, todos los rankings se pusieron a cero y comenzó de nuevo la competición con los últimos bot subidos de cada uno.
Entre ese día a las 11:59 PM y el 1 de diciembre, todos los bots compitieron entre sí, de una manera similar a la que se hace en un torneo de ajedrez. Finalmente ayer, 1 de diciembre terminó el concurso felicitando al ganador y agradeciéndonos al resto por participar.

Como curiosidad os dejo aquí la última partida que jugó (y ganó) mi bot llamado therealnuke: mark.tms vs therealnuke.

También ofrezco al que quiera (y me pida por email) una copia de mi bot, aunque supongo que será mucho más interesante tener el del ganador del concurso. :o)

expo:QA 2010 - El mejor evento del año

2010-11-19T02:28:00.000-08:00

Como todos los años, los profesionales del aseguramiento de la calidad del software nos encontrábamos ansiosos esperando el mayor evento del sector: expo:QA 2010.

A diferencia de años anteriores, en esta oportunidad me prometí a mi mismo ir con un ojo más crítico, y no es que anteriormente no lo haya tenido, el tema está en que las veces anteriores me encontré sorprendido y podría decirse que incluso hasta abrumado por las novedades, la calidad de las presentaciones, el material, la comida, etcétera, cosas que sin dudas nublaron un poco mi ojo más crítico.

Así y todo, puedo afirmar que la gente de Nexo QA, se supera por mucho cada año, y lo hace a una velocidad mayor que mis expectativas, es por eso que afirmo sin lugar a dudas que expo:QA 2010 ha sido con diferencia, el mejor evento del año.

A continuación os cuento algunas cosas de este impresionante evento. Lamentablemente no puedo bajar al nivel de detalle que me gustaría, ya que han sido dos días muy intensos, repletos de novedades y de dónde me he traído muchísima información. Trataré de ahondar más en aquellos temas que me impactaron más y que resultan más interesantes.

Sin más preámbulos, vamos a adentrarnos en el evento:

El lugar

En esta oportunidad, el mayor evento internacional de la calidad del software expo:QA 2010, ha tenido lugar en nada más y nada menos que el ala norte del centro ferial de Madrid, la foto a continuación muestra la recepción de la entrada norte, con el cartel luminoso anunciando: 17-18 (noviembre) EXPOQA - International Conference on Software Testing & Quality Assurance

(Has click en cualquiera de las fotos para verlas más grande)

Para los que no lo tenéis la oportunidad de conocerlo, os confirmo que efectivamente el evento ha tenido lugar en el mismo predio que el GameFest 2010.

En un nublado y frío 17 de Octubre madrileño, en pleno corazón de la capital española, a exactamente las 08:30 un taxi nos dejaba en la entrada norte del magnificente centro de exposiciones. Luego de atravesar el primer control y pasar los maletines por los rayos X, nos dirigimos a la recepción, dónde a pesar de haber sido puntuales, ya había algunos ansiosos madrugadores que se nos habían adelantado.

Nos acercamos a los mostradores de expo:QA a fines de registrarnos y obtener nuestras entradas. Las mismas se adquieren por internet y en preciso llevar los comprobantes impresos para cambiarlos en la recepción por los pases.

El proceso de registro, muy ordenado y rápido por cierto, presentaba distintos lugares ordenados por letras (de la A a la G, de la H a la N, etc) dónde las colas, que no tardaron en formarse, se ordenaban por el apellido de los asistentes. Así mismo, los expositores tenían una fila propia.

Además de los 4 salones de conferencias dónde las casi 40 ponencias tuvieron lugar, había una importante cantidad de stands dónde los patrocinadores exponían sus productos y servicios relacionados con SQA y Software testing.

A continuación se ven algunos de los stands que más abajo comentaré con un poco más de detalle:

Abajo, los magníficos auditorios, completamente equipados dónde las conferencias se realizaban en español o en inglés, con traducción simultánea Inglés-Español / Español-Inglés.

En resumen, el lugar estaba más que bien, completamente acondicionado, las salas dónde tenían a lugar las ponencias estaban equipadas con un excelente audio, los proyectores perfectamente ajustados, las butacas muy confortables, la temperatura ideal todo el tiempo, había un área de stress free, dónde se ofrecían masajes de forma gratuita, en una palabra, no desentonaba para nada con el resto del evento.

Por cierto y pecando por adelantarme un poco a los sucesos, os cuento que me he ganado la siguiente taza en el stan de Steria jugando al minigolf:

El material entregado

Como se muestra en las siguientes fotografías, nos entregaros una cómoda bolsa que aprovechamos para guardar los trípticos, premios que ganábamos, publicidad, e información de contactos interesantes que recaudábamos a lo largo de los paseos por los stands.

En la foto de abajo se muestra de izquierda a derecha: Un colega que nos autorizó expresamente a poner su foto sosteniendo la bolsa entregada. Una foto del programa, impreso en papel satinado de excelente calidad, el cual consta de 34 páginas en español y la misma cantidad en inglés, detallando el calendario del evento y, como no podía faltar y nexo:QA ya nos ha acostumbrado año tras año, un fino gafete, que por broche presenta nada menos que un pendrive USB que contiene la totalidad de las transparencias expuestas en todas las ponencias.

Como un punto a favor, el programa se podía descargar libremente desde la página oficial del evento expo:QA 2010 varios días antes del comienzo del mismo, lo cual fue de gran ayuda al seleccionar las ponencias a las que queríamos asistir.

El ambiente

Al igual que en los años anteriores, expo:QA 2010 se ha convertido una vez más, en el lugar de reunión de los representantes de SQA y software testing de las más grandes empresas de la península, junto a importantes profesionales de nivel internacional, entre las cuales recuerdo a Alan Brown, Arnold Aumasson, Derk-Jan de Grood, Dorothy Graham, Ewout Van Driel, Geoff Thompson, Graham Moran, Ken Brennock, Niels Malotaux, Peter Farrell-Vinay, Rick Hower y otros.

No solo he tenido la oportunidad de estrechar sus manos en un saludo luego de cada ponencia, sino que además, he podido conversar y cruzar ideas con ellos, debatir asuntos relacionados al aseguramiento de la calidad del software, métricas y software testing y disipar dudas que llevaban conmigo un largo tiempo. Sin ir más lejos, luego de su excelente ponencia "Mejorar los resultados económicos de las empresas a través de actividades de calidad del software que contribuyan al ahorro", Francisco Sáez me ha sabido explicar de manera clara y concisa un asunto relacionado al cálculo del ROI en SQA. De hecho, hubo partes en su explicación que me resultaron tan esclarecedoras que las recuerdo palabra a palabra.

Pido disculpas una vez más por adelantarme en la historia de los acontecimientos, lo que me sucede es que he vivido con mucha pasión el evento y me cuesta mantener el orden, aunque supongo que esto es algo que ya habéis deducido dada la calidez de mi texto.

Fuera de los profesionales tan renombrados, también estábamos todos, y cuando digo todos, me refiero a todos los profesionales de calidad del software de la península, me he encontrado con gente que he conocido durante cursos en Barcelona, en Madrid y en otras ciudades. He estrechado mi mano con importantes asesores, jefes de proyecto, profesionales independientes, en fin, gente que cuando menos sumaría un milenio de experiencia en termas relacionados al aseguramiento de la calidad del software y el software testing.

Un ambiente sin dudas muy recomendable para hacer contactos, negocios, adquirir servicios y productos o como ha sido mi caso, enriquecer los conocimientos y disipar dudas.

La comida

Estaréis pensando que soy un glotón por hacer una sección dentro de esta entrada solo para hablar de la comida. Pues sí, lo soy, pero también soy un gran admirador del buen gusto y eso es exactamente lo que describe al catering que coronaba el evento. Los que pudimos disfrutar de ella sabemos que la calidad de la misma estaba a la altura del acontecimiento, personalmente me enamoré de las brochetas de tomates cherry con anchoas, tomates cherry y queso de cabra, la infalible tortilla española, el queso curado con uvas pasas, la cerveza, el buen vino, los distintos zumos naturales que se ofrecían y los platos principales.

A continuación os dejo para deleitar la vista una paellera de fideua que estaba escoltada por unos panecillos que me hacen agua la boca al solo recordarlos:

Las ponencias

Finalmente llegamos al plato fuerte del evento, y ahora no estoy hablando de comida, me refiero a las casi 40 ponencias que conformaron la parte más interesante de este evento.

Continuando con el relato, luego del registro, nos dirigimos con tiempo al Trak 1, sala más grade del evento dónde tuvo a lugar la apertura del mismo.
En esta sala, Raynald Korchia nos dio la bienvenida, explicó a grandes rasgos el evento y comentó las normas de "Vota y Gana" un concurso que, de todas maneras venía explicado en la página 33 del programa, y por el cual todos podíamos participar de un sorteo de un iPad. Básicamente la idea era puntuar las ponencias con 5 valores que se aplicaban desde la utilidad del contenido aplicado al trabajo que realizamos, la calidad de la presentación, la capacidad del ponente, el interés de la misma y una nota general. El concurso contaba con una aplicación on-line dónde se podían ver en el stand de Nexo QA los resultados parciales del mismo. Se podía votar por email o por SMS.

Con esta información permanecimos en esa misma sala a presenciar la ponencia inaugural, expuesta por Arnold Aumasson, "INVITADO: Mercado de servicios de testing a escala mundial para el período 2010-2014: oportunidades clave de crecimiento y tendencias del sector", seguida por un keynote, que fue una de mis favoritas: "Lo que los gerentes creen conocer sobre la automatización de pruebas pero en realidad ignoran", muy recomendable, personalmente me encantó por hablar de cosas que yo mismo he vivido. La misma enumeraba varios conceptos erróneos comunes con los que no podía estar más de acuerdo:

* Es fácil solo grabar los casos de prueba ya escritos.
* El automatizar casos de prueba es tarea de los testers.
* Se puede reducir el número de testers una vez que se tenga la herramienta.
* Somos ágiles ya que los desarrolladores harán las pruebas.
* La automatización es un problema técnico, por lo que no necesitamos involucrarnos.

Y las explicaciones de cada uno no podían ser mejor, la que más me gustó es la tercera, dónde exponía el concepto erróneo "Se puede reducir el número de testers una vez que se tenga la herramienta" y contestaba algo como: "¿Que clase de testers tienes? ¿Estúpidos descerebrados? ¿O inteligentes investigadores? Y explicaba la obvia brecha de inteligencia entre un script y un ser humano.

Muy buena ponencia, aprovecho este espacio para felicitar a Dorothy Graham por exponer de manera tan clara este tema.

Terminado el Keynote de Dorothy, llego la primer etapa de conferencias en paralelo, esto no me ha gustado nunca porque hay que elegir que ponencias ver, en años anteriores lo he comentado con los organizadores pero sus argumentos fueron irrefutables: Hay mucha gente que paga hospedaje ya que vienen de otros países para asistir al evento y ya sea por ese o por otros diversos motivos, no se pueden dar el lujo de asistir 4 o 5 días al mismo para asistir a todas las ponencias, además, las mismas se encuentran armoniosamente intercaladas de tal forma que el que estén en paralelo permite a los participantes elegir que tema le interesa más ver. Por supuesto que siempre está la opción de asistir en grupo y no perderse de ninguna.

En mi caso y como era de esperarse, semanas antes del evento ya me había leído detenidamente el programa, cuyas conferencias vienen etiquetadas con los siguientes temas: "Técnicas de prueba", "Gestión de las pruebas", "Procesos y metodologías", "Negocio e industrialización", "Agile Testing", "Medición de la calidad" y "Automatización y herramientas". Así que ya sabía bien a cual ir.

Al salir de la sala tocaba el coffee break patrocinado por HP, croissants, finas masas y buen café nos esperaban para agasajarnos en un ambiente ameno, dónde aprovechamos para comentar el track de Dorothy.

De manera puntual y siguiendo a rajatabla el programa, a las 11:35 sonó nuevamente la campanilla que indicaba el comienzo de nuevos tracks. Personalmente había decidido asistir al track 1, dónde Derk-Jan de Grood expuso claramente durante 40 minutos el tema "Como seleccionar las técnicas de diseño de testing más efectivas".
A continuación me decanté por la ponencia de Salvador Folgado: "Expectativas y percepciones de la calidad de Software ¿Una misión imposible?
Ambas me gustaron mucho, utilicé parte del tiempo de preguntas para disparar algunas y luego, durante el almuerzo patrocinado por MTP, aproveché para hablar con ambos sobre dudas que me habían surgido durante las ponencias y no las veía tan objetivas como para preguntarlo en frente de todos.

Durante ese almuerzo comprendí lo bien que estaba confeccionado el horario de ponencias y descansos y lo asequibles que eran los oradores, quienes además de grandes profesionales, se mostraron cálidos e interesados al responder a mis dudas.

Puntualmente 14:45 todos entramos en la sala mayor para presenciar la excelente ponencia de Alan Brown: "Mejores prácticas en la entrega de soluciones de calidad en un entorno distribuido y ágil".

Al terminar y por llevar 5 años dedicándome al testing en el ramo de la seguridad, no pude hacer otra cosa que no fuera quedarme en la sala y presenciar la excelente ponencia de Miriam Serna, responsable del departamento de calidad de Panda Security y Ewout Van Driel, consultor de Sogeti para ese proyecto. Ambos expusieron como estaba aplicado TMAP en Panda bajo el título "Gestión de pruebas orientada al negocio en Panda Security". Me agradó mucho estar ahí, primero porque en mi empresa también elegimos a TMAP como conjunto de metodologías y herramientas y segundo porque me he sentido orgulloso una vez más, al confirmar por enésima vez que nuestro departamento de calidad del software, a pesar de tener aun mucho camino por delante, se encuentra muy avanzado, con procesos comparables a los de las más grandes multinacionales. Afortunadamente en eso he tenido mucho que ver, aunque el mérito es de todo mi equipo.

Inmediatamente nos fuimos al coffee break de las 16:30, dónde aproveché para entablar una amena conversación con Miriam, quien a pesar de estar algo atareada, contestó a mis preguntas sin dudarlo.

Me dirigí al track 3, dónde Francisco Sáez de Steria explicó claramente como calcular el ROI en actividades de aseguramiento de la calidad del software. Esta fue la última ponencia a la que asistí el día 17 y curiosamente ha sido la primera vez en la que me encontré en un dilema respecto a cual asistir. Afortunadamente al terminar la ponencia no me quedaron dudas que perdérmela hubiera sido algo imperdonable. Francisco utilizó palabras muy simples para explicar cosas que parecían difíciles, no voy a plasmar aquí los 40 minutos de su ponencia, aunque os voy a comentar algunos detalles que me gustaron mucho:

Primero explicó la formula para el ROI en SQA:
Beneficio - (Costes de calidad) / (Costes de calidad)
Y comentó algunos puntos que me aclararon muchas dudas, como por ejemplo que el ROI es un tanto por ciento, que un ROI positivo significa que la inversión ha sido buena, que un ROI de cero significa que no se ha perdido ni se ha ganado, y todo esto con ejemplos claros y realistas.

Luego dijo algunas palabras claves que me gustaron mucho, por ejemplo: "¿Cual es el coste de la calidad?" El coste de la calidad es lo que queramos invertir en calidad. Entonces... ¿Cual es el coste de la no-calidad? El coste de la no-calidad es, según las famosas tablas de costes de detección de incidencias en etapas tempranas vs costes en producción, para estimar el coste de no-calidad de un proyecto simplemente llevó la totalidad de incidencias detectadas durante todas las etapas de aseguramiento de calidad hasta el cliente. Entonces el coste de la no calidad es el valor que daba esa suma de incidencias menos el coste de desarrollo para solucionarlas.

La verdad es que dicho así y sin dibujos me doy cuenta que está poco claro, el tema es tan interesante que amerita una entrada nueva, si alguno de vosotros estáis interesados, estoy abierto a que me escribáis y gustoso escribiré esa entrada para clarificarlo.

Al salir del predio, una larga fila de taxis nos esperaban, por lo que no hubo que esperar para pillar uno que nos devolviera a nuestras casas.

El día siguiente, Jueves 18 de noviembre, se presentó un poco más frío y lluvioso que su predecesor. Esto sumado a una serie de eventos desafortunados, entre los que puedo destacar que salí de casa un poco tarde, un importante atasco en la autovía por viajar en la hora pico, dónde todos los madrileños se encontraban yendo a trabajar y un accidente de coche que nos demoró más de 30 minutos hicieron que me perdiera la primer ponencia, la cual tenía fichada desde hacía semanas y prometía muchísimo. Mientras iba en el taxi me di cuenta lo adictivo que era el evento y el síndrome de abstinencia que estaba sintiendo. Una cosa es no conocer el evento, no haber asistido nunca, pero una vez que vas, no puedes dejar de asistir.

A continuación pego el resumen de la ponencia que dieron nada más y nada menos que Nathalie Rooseboom de Capgemini Holanda y Ewout Van Driel de Sogeti España:

Su título ponía: EL debate ético sobre el testing de software, por Nathalie, Ewout y un INVITADO SORPRESA.

IMPORTANTE: El siguiente contenido, en su totalidad con letra itálica es copiado de la página de Nexo QA, no es de mi autoría y su licenciamiento debe ser consultado a sus propietarios:
Fecha: 18/11/2010 El debate ético sobre el testing de software Un debate al estilo "House of Commons" sobre el tema "La ética en la profesión del testing". En esta sesión de sesenta minutos, se parte de unas afirmaciones estimulantes para garantizar un debate intenso que servirá para elevar la moral de los testers a lo más alto. Este debate al estilo "House of Commons" se inspira en un programa de la televisión holandesa en que el objetivo es trasladar los temas cotidianos al salón de su casa de manera informativa y entretenida al mismo tiempo. Los organizadores se encargan de plantear las afirmaciones. Un organizador estará a favor de la afirmación y el otro en contra. El público tendrá la oportunidad de reaccionar ante las distintas alegaciones. Los organizadores animarán al público a que se pongan de su lado y argumentarán el punto de vista escogido. A continuación se enumeran unos cuantos ejemplos sobre las afirmaciones que pueden plantearse: * Se puede infringir la ley para conseguir los objetivos de las pruebas * Siempre se debe decir la verdad * Siempre se debe ser capaz de utilizar los datos sensibles de privacidad para realizar pruebas * Como tester, no se debe tener un código de conducta profesional, ya que esto dificulta llevar a cabo un buen testing * El testing y la ética son temas aparte ¿Será capaz de relajar sus principios y considerar qué podría pasar cuando uno actúa de manera no tan correcta? ¿Realmente son algunas de las afirmaciones tan opuestas? ¿Qué matices se deben aplicar? Comparta su opinión y quizás alcancemos un consenso sobre cuál es el "Código de conducta del tester". Calificada como "Excelente" en la EuroSTAR 2009 (puntuación 9 en una escala del 1 al 10).

Continuando con mi experiencia personal, ayer llegué al evento sobre las 10:30, hora en que entré en el trak 3, donde José Manuel Muñoz se encontraba exponiendo "No basta con construir el sistema correctamente, debemos construir el sistema correcto: Requisitos y pruebas en IRQA".

Luego del excelente coffee Break patrocinado por Steria, el cual aproveché para mantener una charla con José Carlos Padrino, me acomodé en el track 4. Una de las cuatro paredes de esta sala era un gran ventanal de vidrio por el cual se apreciaba una larga hilera de mástiles de dónde flameaban a toda velocidad banderas de todos los países. El ver caer la lluvia y el cielo color plomo hacían el lugar mucho más cálido y confortable, y una vez más caí en la cuenta de lo agradable que era todo en el evento. El saludo de la presentadora por los altavoces me quitó de mi trance y me hizo prestar atención a Miguel Castaño Cerezo, de GFI Informática quien dio una interesante charla sobre Automatización de pruebas.
Aproveché también el momento de preguntas para quitarme alguna duda y recuerdo que más tarde, durante el almuerzo, tuvimos una larga y entretenida charla dónde contamos anécdotas y tuve la suerte de conocer al cálido y experimentado profesional que es Miguel.

Inmediatamente después, me dirigí al track 2, dónde Neils Malotaux dio una entretenidísima charla titulada ¡Socorro! ¡Tenemos un problema de QA!
Niels es muy buen orador, todo un showman diría yo. La ponencia trató de una historia real dónde una empresa de Dubling lo llamó y le dijo: ¡Socorro! ¡Tenemos un problema de QA! Luego de lo cual, el asistió a la misma y solucionó el problema. Interesante y curioso a la vez, esta ponencia de gestión me ha gustado mucho.

Luego del almuerzo patrocinado por IBM, Isabel Evans dio para todos un Keynote: "Cultivar el testing", seguida de la cual me dirigí al track 3 para ver "Testing basado en modelos", de Pilar Blanco. Una ponencia muy útil, sobre todo para aquellos que utilizamos TMAP.

Finalmente vino la Entrega de Premios. Y digo finalmente porque efectivamente ha sido el punto final del evento. Se entregaron distintos premios, que iban desde un smartbox a un iPad, tanto a ponentes como a asistentes. Ha estado muy bien y sin dudas fue un bonito broche de oro.

A continuación una foto del cierre del evento dónde aparece un chiste que me resultó entretenido:

Haciendo click en la siguiente imagen, se puede ver el chiste más grande para que pueda ser leído:

Los stands

En los stands estaban las principales empresas de SQA y software testing, recuerdo a IBM, Steria, HP, Bull, Sogeti, etc. Casi todos tenían las mismas dimensiones excepto alguno como IBM que eran un poco más grandes.

En algunos de ellos se podía jugar, en otros se podía consultar información on-line, y por supuesto, el excelente stand de Stress Free dónde se podía tomar un magnífico masaje.

Los mismos fueron inteligentemente situados en la parte central del evento, por lo tanto, al salir de las conferencias, podíamos recorrerlos.

Perlas Blancas

En esta parte, quiero homenajear a quienes por distintas razones, se han ganado mi admiración y respeto:

Los que hemos organizado eventos, sabemos la tensión constante que supone el mismo, desde sus preparativos, la incertidumbre de la adición al mismo, el insomnio de la noche anterior al no saber si todo saldrá según lo previsto, y sobre todo, los pequeños apaños y correcciones que es necesario realizar ante los imprevistos que surgen cuando el evento está en marcha. Por todo eso quiero dar una perla blanca a Raynald Korchia quien hoy, a un día después del evento, se ha convertido en un profesional de mi admiración y mis más sinceros respetos. ¡¡¡ Enhorabuena Raynald!!!

Otra perla blanca es para todo el equipo y colaboradores de Nexo QA, esa gente que, como se dijo en el cierre del evento, trabaja desde las sombras haciendo posible lo que pocos podemos ver, la puntualidad de las ponencias, las traducciones, el material, la comida, etc. Son cosas que estaban ahí, cosas de las que todos disfrutamos, cosas que rara vez nos detenemos a pensar que si no fuera porque alguien se ocupó de la logística, las contrataciones, las alianzas, la publicidad, nunca hubieran sido concebidas. Mi segunda perla blanca es sin lugar a dudas para todo el equipo de Nexo QA. Por favor, continuad haciendo un trabajo tan maravilloso como siempre.

Perlas Negras

En esta sección de mi entrada voy a criticar las partes negativas del evento.

Aquí, a diferencia que en la sección anterior, necesito enfriar un poco el tema, trataré de entregar las perlas negras con la cabeza y no con el corazón.

Mi primera perla negra en es para el equipo de clasificación de ponencias, y no es porque piense que las ponencias no estaban bien, todo lo contrario, todas tenían un nivel increíble, el punto es que han rechazado nuestra ponencia de automatización, para la cual varios profesionales trabajaron durante un tiempo considerable y, desde mi punto de vista, merecía sin dudas estar entre las seleccionadas. Con el respeto que el asunto merece, entrego una perla negra para ellos.

Mi segunda perla negra es para el equipo de catering, quienes durante el coffee break de las 11:05 del miércoles han servido el café de una de las jarras, relativamente frío y no fue el mío el único reclamo al respecto, esta perla en realidad, la entrego gris (casi blanca), ya que cuando reclamamos nos cambiaron las tasas por café caliente y de muy buena calidad, como nos tenían acostumbrados. Perla gris para ellos por no haber prevenido el enfriamiento repentino de una de sus jarras de café.

En resumen

expo:QA 2010 es sin dudas un evento único, imperdible para los que estamos interesados en el aseguramiento de la calidad del software y/o software testing. Una vez más, ha sido el lugar de reunión de los representantes de SQA y software testing de las más grandes empresas de la península, junto a importantes profesionales de nivel internacional. Personalmente estoy muy contento de haber podido asistir ya que me ha permitido conversar con grandes figuras internacionales de la calidad del software, y como comento más arriba, ha sido lejos, el mejor evento del año.

Hardware que respeta la libertad de los usuarios

2010-10-14T12:58:00.000-07:00

La Free Software Foundation (FSF) anunció hoy que ha publicado un conjunto inicial de criterios para aprobar los ordenadores y otros dispositivos de hardware, los cuales llevarán el logo "Respeta su libertad". Esta publicación tiene dos objetivos claros, por un lado obtener feedback respecto a estos criterios publicados, y por el otro aumentar el interés en el programa entre los fabricantes de hardware.

Se está planeando recompensar mediante la promoción y recomendación a aquellos fabricantes cuyo hardware cumpla con los requisitos "Respeta su libertad".

Segun las palabras pronunciadas hoy por Peter Brown, actual director ejecutivo de la FSF:
-El objetivo es que los usuarios de ordenadores y otros dispositivos puedan tener un control total sobre él, para saber que no están siendo espiados o analizados sus patrones de uso, para ejecutar cualquier software que quiera sin pedir permiso, y para compartir con amigos sin preocuparse del DRM. Estos son los deseos de millones de personas que se preocupan por el futuro de la tecnología y nuestra sociedad. Desafortunadamente, los fabricantes de hardware hasta ahora han tenido una estrecha cooperación con las empresas de software propietario que exigía el control de sus usuarios. Como ciudadanos y sus clientes, tenemos que promover nuestros deseos de una nueva clase de equipos de hardware que cualquier persona puede usar, ya que respeta su libertad.

El criterio de la FSF es tratar de cubrir todos los aspectos de la interacción del usuario con y el control de un dispositivo: El equipo debe ejecutar software libre en todas las capas que sean actualizables por el usuario, se debe permitir al usuario a modificar ese software, debe tener soporte de formatos de datos libre, ser plenamente utilizable con herramientas libres, etc.

Según textuales palabras del ingeniero de recopilación de licencias de la FSF, Brett Smith: Todos los componentes de software necesarios para producir hardware actualizable ya están disponibles. Tenemos varias distribuciones de GNU con Linux que sólo incluyen software libre y son completamente funcionales en el hardware adecuado, tenemos el núcleo LinuxLibre que no incluye microcódigo no libre, también tenemos plataformas móviles de última generación como Android y Meego que se basan en software libre. Con nuestra marca de aprobación "respeta su libertad" y los nuevos criterios criterios, tenemos la intención de cerrar esa brecha y demostrar a los fabricantes que pueden ganar mucho haciendo hardware que respeta la libertad de las personas en lugar de reducir la misma.

Me ha gustado tanto esta novedad que no he podido dejar de escribir una entrada en mi blog al respecto. Los desarrolladores nos encontramos muchas veces con hardware que, lejos de ser libre, tiene componentes de software no libres, no entregan especificaciones y es un trabajo colosal realizar la ingeniería inversa necesaria, que además está prohibida muchas veces, para poder utilizar este hardware como queramos o con el software que elijamos.

En lo personal me limito a comprar hardware que, no tenga software privativo preinstalado y que indiquen de manera explícita que soportan ser utilizados con software libre, lo cual me limita bastante a la hora de adquirir dispositivos. Espero que este movimiento logre liberar a la los usuarios al devolverle el derecho de controlar sus dispositivos, sabiendo que no están siendo espiados, analizada su conducta mediante analizadores de tráfico, escuchadas sus conversaciones, etc. y nos permita a los desarrolladores elegir entre más opciones.

Gamefest 2010

2010-10-10T09:53:00.000-07:00

Como muchos ya sabéis, el 8, 9 y 10 de Octubre de 2010 se ha celebrado la feria de vídeo juegos Gamefest, en el predio ferial de Madrid. La misma ha tenido tanto éxito que una semana antes del evento, solo se conseguían entradas para el último día.

Por supuesto, un aficionado a los vídeo juegos como yo, no podía faltar. He aquí un pequeño resumen de lo que encontramos en este entretenido y maravilloso acontecimiento.

La historia

A pesar de ser España la cuarta consumidora europea de vídeo juegos, es la primera vez que esta feria tiene un lugar en este país. Japón, lleva años realizando la mundialmente conocida Tokyo Game Show (TGS), la convención de vídeo juegos más grande del mundo. En los Estados Unidos de América, desde 1995 existe la famosa Electronic Entertainment Expo (E3). Tal vez un poco tarde para mi gusto, pero finalmente a España ha llegado Gamefest, y lo ha hecho con una participación y novedades que no están muy lejos de la altura de las anteriores.

Los participantes

Obviamente estaban presentes los más importantes fabricantes de vídeo juegos del mundo. Pegado a la entrada estaba el magnificente stand de Game, custodiado por el de Sega a la derecha, de no mucho menor envergadura y por el de PlayStation a la izquierda. Microsoft también estuvo presente con un stand central y algunos aledaños. Además de estos y entre otros estaban Konami, presentando el PES2010, Sony y Nintendo con más de un stand, Ubisoft, EA y THQ. También estuvieron presentes la aDeSe (Asociación Española de Distribuidores y Editores de Entretenimiento) y la gente de GameLab, estos últimos han dado una conferencia invitando a distintos tecnólogos de la industria del vídeo juego.

El ambiente

En una palabra: Impresionante. Muy bien creado, tanto por el decorado en general, por la música de los vídeo juegos flotando en el aire y por los distintos personajes que, como si hubieran saltado de la pantalla, se paseaban por los pasillos.

Cerca del stand de Wii nos encontramos con Mario y Luigi que pululaban por ahí, dispuestos a tomarse fotografías con la gente*.

Junto al stand de Play Station nos encontramos con el verdadero Kratos.

La unidad de operaciones especiales del UNSC, liderada por el Comandante Carter-259 y su segunda la Teniente Comandante Kat-320, apoyados por el francotirador Subteniente Jun-266, el experto en combate cuerpo a cuerpo Subteniente Emile-239 y el especialista en armas pesadas Jorge-052, se han escapado del Halo Reach para estar entre nosotros en la expo:

Mis favoritos han sido lejos, una chica convertida en Zombie y Chuck Greene que la perseguía con un palo ensangrentado y lleno de clavos, luego de escapar del espeluznante Dead Rising 2.

Por supuesto, se podía jugar a todo lo que estaba expuesto, lamentablemente y a pesar de la vasta cantidad de consolas y debido a que estas eran superadas en número por los deseosos jugadores de probarlas, muchas veces el acceder a un juego suponía hacer una larga cola.

Estos son algunos de los lugares, dónde con un poco de paciencia, se podía jugar:

El stand de Nintendo DS, presentando sus versiones DS, DS-Max y DSi:

Play Station Move, el sistema de Juego de Play Station 3 que compite de manera frontal con la Wii de Nintendo, también nos ofrecía la opción de probar algunos de sus maravillosos juegos:

De la mano de EA, los Sims también se podían probar desde un cómodo stand lleno de pufs, la gente podía sentarse e incluso recostarse para crear los personajes y disfrutar del último título de este clásico durante horas:

El impresionante Gran Turismo de Polyphony se podía disfrutar en unas máquinas que Sony ha puesto con una Play Station 3 camuflada a modo de motor, realmente muy bueno:

En el stand de Nintendo Wii, se podía jugar a numerosos juegos en pantallas que iban desde estas normales que se ven en primer plano, hasta gigantescas como la que se puede apreciar en el fondo de esta imagen:

El Pro Evolution Soccer 2011 también se podía jugar en numerosas consolas:

En fin, como bien os estaréis imaginando, el pabellón se encontraba plagado de juegos y gente jugando, personajes de la ficción caminando entre la gente y la colorida escenografía hacían del lugar un sitio mágico y agradable.

Novedades

Una de las tónicas del evento han sido los juegos sin mando, como se puede ver en la siguiente fotografía, el famoso Sonic y su compañero Tails andando en skate, manejado por estos dos jugadores que debían balancearse para girar, saltar, agacharse e impulsarse con los pies para ganar velocidad.

Ya había escuchado sobre esta nueva tendencia, incluso había visto algunos vídeos en YouTube, y no me parecía una gran idea, tenía mis dudas respecto a la jugabilidad y diversión que este innovador sistema pudiera ofrecer, no obstante, al verlo en vivo y en directo, debo admitir que es una gran idea, que sin dudas, Sega ha sabido implementar a la perfección.

Como era de esperar, Microsoft también estaba presentando sus juegos sin mando, me ha llamado un poco la atención, que las consolas de Microsoft que estaban disponibles para probar este sistema de control, se encontraban con el Development Kit y las promotoras que las manejaban, seleccionaban opciones desde un menú, dónde se veían ficheros .exe y demás. ¿Será que MS todavía no tiene muy depurado esto en sus juegos? No me hubiera sorprendido el ver en algún monitor una pantalla azúl, con el útil volcado de registros, aunque esto no ha ocurrido.

A continuación se ven algunos de los concurridos stands de MS con sus juegos para XBox 360 basados en su nueva tecnología Kinect. Por cierto, su curioso slogan es "Tu eres el mando".

Otra de las novedades que se impusieron fue el anuncio con imágenes del "Assassin's Creed: La Hermandad", había varias gigantografías, monitores mostrando vídeos y partes del juego.

Una inmensa pantalla de Ubisoft nos tentaba con avances de lo que podremos disfrutar a partir del 18 de este mismo mes, fecha en la que será liberado esta maravillosa tercera parte de uno de los mejores juegos.

Miscelánea

Como curiosidades se podía fotografiar en el lugar un precioso Lamborghini Diablo, vestido de su amarillo rabioso que tanto nos agrada ver.

Otra cosa que me llamó la atención fue el están de Wii dónde podías tomarte una foto posando con un fondo neutro y luego la compaginaban en alguna escena de Mario Bros.

También había una zona Retro, dónde se podían ver expuestas numerosas consolas y vídeo juegos,
Se podían usar varios ordenadores de los años 80, que se encontraban operativos y a disposición del público.

Aunque en las vidrieras expositoras, llegué a ver alguna reliquia de los 70. Algunos de los sistemas que he visto son: Sega Megadrive II, Amstrad GX4000 (1990), Nintendo 64 (1996), Nes Famicom (1983), Game Boy Advance (2001) y Game Boy micro (2005), Super Nintendo (1990), Philips CDi (1991), Bandai Playdia (1994) , una Coleco Telstar Alpha que no ponía el año aunque sé que son de los 80, y una Atari 2600 (1977).

Bueno, espero que con lo que os he contado os hagáis una idea de lo que ha sido esta expo, realmente la he pasado muy bien y el escribir esta entrada en mi blog me ha hecho recordarlo. Ojalá que a vosotros os haga la misma ilusión al leerlo. Como siempre, espero gustoso recibir vuestros comentarios.

(*) Las personas cuyos rostros aparecen en las fotografías han aceptado explícitamente por escrito el aparecer en la publicación de esta entrada en el blog.

Mi solución personal de firewall perimetral

2010-10-08T22:48:00.000-07:00

Antes que nada, quiero advertir que en esta entrada de mi blog, solo estoy explicando la forma en que he montado parte de la seguridad para la red, tanto cableada como inalámbrica de mi casa. Soy consiente que es completamente excesivo para un hogar y que las medidas de seguridad deben ser tomadas acorde a lo que se intente proteger. Digo esto por dos razones de peso: primero que mis pocos visitantes y seguidores han sido exigentes con mis publicaciones y estoy seguro que sin este pequeño preámbulo, me hubieran llegado unos cuantos comentarios. Por otra parte, no quiero crear paranoia en nadie, al hacerlo pensar que si no tiene algo similar su red hogareña es insegura.

En pocas palabras, nunca es necesario matar moscas a cañonazos, excepto en aquellas ocasiones en las que se quiera probar un lanza misiles, y eso es exactamente a lo que dedico gran parte de mi tiempo.

Las redes cableadas

La seguridad en una red cableada, a diferencia de su alternativa inalámbrica, es bastante mayor ya que requiere un medio físico, que en un hogar normalmente está lejos del alcance de manos indeseadas. No conozco ningún caso, en el que algún demente haya hecho un boquete en la pared de su vecino con el único fin de conectar un cable al módem para hacer uso de su conexión de banda ancha.
Por otra parte, en las empresas el asunto es diferente, lo que se trata de defender no es que alguien robe ancho de banda para bajar la última película de Danny Trejo, por el contrario suele haber datos sensibles viajando por la red y se reciben visitas de clientes, proveedores, gente que trae portátiles a la que normalmente no se le restringe el acceso a una boca de red. Proteger una red cableada puede ir desde algo tan sencillo como realizar la conmutación de los equipos sensibles mediante switches que se protejan del Arp Spoofing, hasta implementar IEEE 802.11i o VPNs para cifrar los datos que viajan por ella.

En la implementación de seguridad informática de mi hogar, los datos viajan "en claro" por la red cableada, aunque esta está protegida en varias capas contra fallos y ataques, con alarmas para su pronta detección y algunas acciones se ejecutan de manera desatendida para la prevención de daños, como la eliminación de rootkits, código malicioso y detección de intrusos. Estas políticas se aplican a todo lo proveniente de las DMZs (internet y wifi no cifrada).

Las redes inalámbricas

Una red wifi es por naturaleza extremadamente insegura. Esto se da primero por su medio, el cual sería el equivalente a que cualquiera pueda acceder a un puerto del conmutador central configurado para hacer mirroring de todas las comunicaciones en una red. Luego por la cantidad de software y "HOW TOs" que se pueden encontrar en Internet para "hackearlas" (como normalmente se denomina al obtener las credenciales necesarias para poder conectarse.

Existen diferentes tipos de cifrados que ofrecen los enrutadores que nos "regalan" los ISPs aunque ninguno de ellos es infranqueable. Es posible que para una casa, utilizando WPA o WPA2 sea más que suficiente para que nadie nos robe ancho de banda impunemente, el problema es que estos sistemas de cifrado no están soportados por todos los dispositivos. A continuación he confeccionado una tabla dónde se puede ver esto un poco mejor explicado:

Encripción	Seguridad aportada	Dispositivos posibles	Usos
Ninguna (abierta)	Es requerido utilizar seguridad en alguna otra capa, como ser VPN, portal cautivo, etc.	Todos los dispositivos WiFi	Restringido solo para expertos o alguna prueba puntual.
WEP	Mínima, lo único que nos asegura es que no se puedan conectar de manera instantánea los que estén al alcance de la señal, se puede obtener la clave en cuestión de minutos.	Algunos dispositivos, como consolas portátiles (NDS/PSP) y teléfonos móviles no lo implementan correctamente.	No recomendado, debe usarse solo si no hay otra mejor opción.
WPA	Bastante más segura, se lo pone difícil a los que se descargan la última de Wifislax y están buscando redes para ahorrar el pagar por banda ancha. Esto también hace que desestimen el ataque a la red, decantándose por aquellos que tengan WEP.	Solo los ordenadores y las nuevas consolas implementan correctamente la encripción WPA.	La mejor opción para hogares, no recomendable en instituciones con datos sensibles que puedan viajar por esta red.
WPA2	Si bien, ya existen aplicaciones (que utilizan la GPU) para romper esta encripción relativamente rápido, podemos estar tranquilos que ningún aficionado accederá a nuestra red.	Solo ordenadores.	En un hogar, esta encripción se puede entender como segura. En una empresa va relacionada a las probabilidades de ataque y riesgo.

Como se puede ver, hay un compromiso entre el tipo de seguridad a implementar y los dispositivos que los soportan, además, algunas no son soportadas por hardware por lo que el cifrado de todos los paquetes se hace por software, consumiendo CPU por el solo hecho de transferir ficheros por la red. Como explico en la tabla anterior, para una casa de familia WPA es la mejor opción.

En mi caso, como tengo dispositivos de apoyo, he dejado la red WiFi abierta, considerándola una DMZ más como es Internet, de ahí que poseo 2 DMZs.

Mi firewall perimetral

Problemática

Al tener Internet por un lado y una WiFi abierta por el otro, poseo dos redes DMZ (Desmilitarizadas) de dónde pueden provenir ataques o intrusos a mi red. Pueden venir ataque de todo el mundo desde Internet e intentos de uso y abuso de mi ancho de banda desde mis vecinos, transeúntes que pasen cerca de mi casa y clientes de la cafetería que tengo justo frente a la parte trasera de mi casa dónde la señal llega perfectamente.

Solución

Lo primero que hice fue desarmar mi Livebox I (El router que me fue provisto por mi ISP) y extirparle la tarjeta WiFi mini-pci que trae. El router en sí no está mal, solo que se me queda pequeño para instalar todos los componentes de seguridad que necesito en ese punto.
Al abrirlo me encontré con la sorpresa que trae una tarjeta WiFi con un chip Broadcom BCM4318, a continuación una fotografía que le tomé a la tarjeta luego de retirarla del router:

Con esto me quité el problema de que el WiFi del router se active accidentalmente, por ejemplo al restablecer los valores de fábrica. Y gané una mini-pci que me vino de perlas para utilizarla como lo cuento más abajo.

En segundo lugar, he aprovechado un poco de hardware que ya tenía, puntualmente una tarjeta Alix.

La tarjeta Alix que poseo es un verdadero PC basados en un uP Geode x86 de 500Mhz que no requiere refrigeración ni disipador. Trae 265 Mb de ram (más que suficiente), dos tarjetas de red, puerto serie y 2 slots mini-pci y alguna cosa más que se me escapa, lo mejor de todo es que solo mide 15cm por 15cm. He aquí un link a la página del fabricante, del modelo que compré:
http://www.pcengines.ch/alix2d2.htm
Yo lo tengo con una tarjeta Compact flash de 4Gb que juega el papel de HD.

Al ser un dispositivo que no tiene monitor ni teclado, aunque posee un puerto serie q no suelo tenerlo conectado todo el tiempo, he desarrollado un pequeño wrapper para las luces que funciona de manera muy sencilla:
Como solo tiene 3 luces frontales, les he sacado provecho dándoles 4 opciones a cada una: apagada, fija, parpadeando lento (1 seg), parpadeando rápido (1/4 seg). Y combinadas me hice una tabla que ahora mismo tiene 30 combinaciones pero soportaría hasta 12 bits (2048 combinaciones posibles). El wrapper funciona de manera sencilla, todos los scripts generan la salida a un fichero, una vez por segundo el wrapper lee el fichero y busca expresiones regulares, estas mueven estados en las distintas máquinas de estado que posee, generando así un código, luego al ver parpadear las luces, busco en la tabla impresa el código y se en que estado está el firewall.

El siguiente paso fue insertar la tarjeta moduladora WiFi extraída del router al Alix, a continuación una foto que tomé una vez realizada dicha labor:

La tarjeta tiene dos conectores para antena, pero el gabinete que compré trae un solo agujero para tal fin, además solo poseía una antena WiFi, por lo que tuve que hacer algunos malabares:

Luego de observar el mother, hice un agujero en el costado del gabinete, en un lugar dónde había vigilado previamente que el conector de la antena no tocaría con ningún componente. En este instalé la antena que tenía:

Luego, sabiendo que la longitud de onda de la banda de 2.4 GHz es de 12.5 centímetros, me construí con un alambre un dipolo de onda completa, aproveché una pata de PVC que tenía para usarla de base y el agujero que trae en la parte posterior el gabinete para sacar el cable, el soporte para la segunda antena me ha quedado así:

He aquí una foto de todo montado:

Luego conecté el router del ISP (ya no es router wifi) al dispositivo Alix, y la otra salida del dispositivo al conmutador central.

El WiFi no lo sirvo directamente desde le Alix porque el alcance sería mucho menor, en su lugar utilizo un dispositivo Cisco Aironet 1200 que me regaló un amigo, el cual ofrece la administración por una boca de red y cumple solo la función de access point.

Admito que vendría bien un diagrama hecho en Dia, pero lo tengo pendiente. Voy a tratar de explicar esmeradamente en que consiste la solución de seguridad:

El accesspoint está conectado a otro dispositivo Alix que hace de terminador de VPN, como la wifi está abierta, debo asegurarme que solo puedan conectarse a la red cableada mediante el uso de credenciales no negociadas.

A su vez, el Alix se conecta al wifi ofreciendo DHCP, DNSs y un DG, el cual tiene un iptables Layer 7, control de ancho de banda, filtro web con Dansguardian, AV con ClamAV y por supuesto un Snort.

De esta manera, si estoy trabajando con un ordenador conectado a la red cableada, me conecto a Internet directamente a través del Alix, sus políticas de control de ancho de banda benefician a las conexiones que van por la interfaz ethernet sobre las de la WiFi.

Si me conecto con un ordenador a la red WiFi, utilizo la VPN, con lo que accedo directamente a la red cableada, tengo accesos a todos los servicios y no tengo restricciones, salvo la protección del FW, filtrado de contenido, cache, antivirus, etc.

Si utilizo la WiFi abierta sin VPN, el Alix que está conectado a esta red me da IP por DHCP y la única salida que tengo a Internet es mediante esa conexión.

El layer7 determina que típo de tráfico es, permitiendo solo navegación web. El tráfico DNS está enrutado con un DNAT a un DNS local, por lo que el puerto 53 no está abierto. El tráfico WEB está redirigido a un SQUID como proxy transparente que se conecta con el analizador. Además el BWM (control de ancho de banda) le permite tanto ancho de banda como excedente haya.

La detección de uso de P2P, escaneo de puertos, ARP gratuitos y otros similares mediante la red WiFi genera un baneo automático a la MAC de origen.

Por cierto, en el Alix tengo un Debian Lenny con un repositorio extra llamado Voyage.

Espero que os haya sido de interés la entrada, os dejo algunos links sobre temas que he comentado:

PC Engines ALIX system board
Voyage Linux | { x86 Embedded Linux = Green computing }
Layer 7 Kernel HOWTO
SQUID: Optimising Web Delivery
Dansguardian
ClamAV
Snort

De más no está decir que no me hago responsable por los daños que podáis causar a vuestros equipos imitando lo que he comentado aquí. He escrito esta entrada para compartir la solución que le he dado a determinada problemática con vosotros y estar receptivo a ideas y mejoras.

Pintado con láser.

2010-10-04T20:58:00.000-07:00

Pintado con láser (painted with laser), es una técnica de fotografía digital que inventé(*) hace unos cuatro años. La misma consiste en la toma de una fotografía con exposición en un cuarto obscuro mientras con un puntero láser se pinta el objeto a fotografiar. El truco está en aplicar trazas que queden bien, lo cual se obtiene con unos segundos de inspiración y varias horas de intentos fallidos.

Así es, hoy no voy a hablar de SQA, ni seguridad, ni internet. Como dice en el copete de mi blog, aquí expondré los temas que me resulten de interés, y cualquiera que me conozca más o menos sabe de mi afición por la fotografía.

La historia

La primera cámara digital que tuve fue por el año 2006, es verdad que fue un poco tarde, pero no me la pude permitir antes.

Además de estar fascinado por tomar fotografías y ver como quedaban al momento, me sentía muy atraído por las posibilidades "extra" que esta ofrecía, como ser fotos a alta velocidad, como esta que tomé en el jardín delantero de mi casa, dónde se pude ver el agua de lluvia quieta como hielo sobe una flor:

Comencé a hacer mis primeros experimentos con la opción manual (M) que trae mi cámara, dónde se puede configurar desde la definición y enfoque, hasta la sensibilidad (ISO) y la velocidad de obturación (tiempo de exposición). Me apasioné con la opción de microfoco que me permitía tomar fotografías como el rocío de la mañana sobre esta fruta:

Y por supuesto, también he jugado bastante con la velocidad de obturación combinada con la obscuridad, lo que me permitió magnificar cosas tan simples de la vida, como el encender un mechero:

Jugando un poco con estas técnicas, un buen día tuve la idea de dejar el lente abierto, y comenzar a escribir cosas con fuego, con leds, etc... Estos experimentos, que no quedaban tan bien como me los imaginaba, decantaron en la idea de coger un puntero láser y dibujar algo en la pared, lo cual me mostró lo bien que este imprimía cada imperfección de la misma, decantándome así por la idea de pintar cosas con láser.

Láser como pintura

La verdad es que no es fácil ni rápida, un modelo toma aproximadamente 20 minutos, entre intentos fallidos y detalles, he aquí un poco de hielo pintado con láser:

Lo primero es conseguir un lugar completamente obscuro, tomar algunas fotos a modo de prueba y ajustar los parámetros de la cámara, principalmente el tiempo de exposición, el foco y la sensibilidad. Una vez que tenemos estos parámetros afinados, comienzan los ensayos con la pintura, las cosas transparentes son más fáciles de pintar, ya que no dejan demasiado rastro del trazo. En la foto anterior, al terminar las pasadas que dieron color al hielo, he sacado el puntero fuera de la imagen, hacia la izquierda, para que se pueda apreciar como queda un trazo sobre algo sólido.
Esta fotografía, de 30 segundos de exposición, tiene complicaciones extras, como ser que el hielo se derrite y se desliza, lo que la transforma en un verdadero reto para la imaginación y la paciencia. Deberíais haber visto la cara que se me quedó cuando traté de pintar el primer hielo y no lo encontraba con el puntero, entonces di la luz y lo vi incrustado contra la lente de la cámara. En este caso, he arrojado un poco de sal de frutas sobre la superficie dónde iba a tomar la foto, lo que logró una adherente efervescencia que, como podéis apreciar, no se nota en la imagen.

Otro desafío interesante es el pintar superficies planas como este billete:

O este calendario Azteca:

Como se puede apreciar, el láser es capaz de copiar hasta el último detalle, de las texturas, apagando por completo los colores y brillando excesivamente ante la sobre exposición, lo cual es muy fácil que suceda en una superficie plana. En ambas fotografías lo que he hecho, luego de muchos intentos fallidos, es poner el láser de forma perpendicular a la superficie, de esta manera realicé un solo barrido evitando, dentro de lo posible, quemar o dejar partes obscuras.

El siguiente ejemplo es un poco de fruta, se me ha quemado un poco lo cual me dio una idea que he plasmado una fotografía más abajo:

Como venía diciendo, al ver la fruta algo "quemada" por la sobre exposición, se me ocurrió la idea de quemar intencionalmente algo, y que mejor que un peluche, la siguiente imagen fue realmente complicada de tomar, primero porque para "quemar" con estilo una imagen, es imperiosamente necesario tener buen pulso y segundo, porque los ajustes de sensibilidad y foco necesarios han recaído en más de treinta intentos. En pocas palabras, que me he tirado más de 2 horas para hacer esta foto, la cual, al igual que todas las que aquí expongo como "pintadas con láser" no tienen ningún tipo de edición:

Y siguiendo un poco con los peluches, he pintado este perro, dónde he dejado intencionalmente, grotescos trazos por el suelo. Como podéis observar en las anteriores fotografías estos trazos casi no se aprecian y ocultarlos es mucho más difícil que hacerlos evidentes como en esta imagen:

Un detalle que me resulta interesante, es remarcar los bordes de las superficies brillantes, ya que estos, reflectan el láser hacia el suelo, dando una sensación de iluminación al rededor de la figura:

Como os imaginaréis, tengo una amplia colección de "pintados con láser", pero creo que lo bueno, si es breve, es dos veces bueno y esta entrada está a punto de dejar de ser breve. Espero que os haya gustado mi post, como siempre, estaré encantado de recibir vuestras preguntas, dudas, aportaciones, etc.

Por cierto: Poseo todas las imágenes aquí exhibidas en 5 y 8 Megapixeles, las he transformado a 640x480 y 800x600 con el único objetivo de no hacer tan pesada esta página, si alguien gusta algún ejemplar en tamaño mayor, que me lo pida y gustoso se lo enviaré. (Recordad que este material está licenciado bajo Cc-by-nc-sa-3.0).

*Respecto a la técnica (pintado con láser): He buscado razonablemente temas relacionados a esta técnica y hasta el día de hoy estoy no he encontrado nada similar, por favor, si alguien conoce algún dato que indique lo contrario que me lo deje saber y haré la corrección pertinente en este blog. Por lo pronto entiendo que existen otras técnicas de sobre-exposición pero no he visto ninguna en la que se utilice un puntero láser (y el pulso del artista) para generar las fotografías literalmente "pintadas con láser".

Seleccionando un profesional de SQA

2010-09-19T04:29:00.000-07:00

Hoy me contactó un viejo amigo, que actualmente se encuentra realizando una ardua tarea por la que he pasado en más de una oportunidad: el crear un departamento de aseguramiento de calidad de software que embone perfectamente en una infraestructura que lleva algunos años creada y funcionando.

La charla fue larga y amena, me contó de algunas decisiones que me recordaron a las mías y también confirmó mi teoría respecto a que cada empresa es un mundo con sus propios desafíos y retos y que no hay una única solución a cada situación ya que las variables de ajuste son tantas, que es imposible aplicar una misma solución a iguales circunstancias en distintas empresas. Me arriesgo a afirmar que, incluso no existe una solución a un mismo problema dentro de la misma empresa en distintas etapas de madurez de la misma.

Esto no significa que no haya patrones o metodologías estándares que se puedan aplicar con éxito, y que sean mucho más valiosas que las que un líder de calidad sea capaz de crear, a lo que me refiero es que se requiere una basta experiencia para saber seleccionar con claridad las herramientas que cumplan las funciones adecuadas para cada circunstancia.

El motivo puntual de su llamado fue una pregunta que, alguna vez también me hicieron en un evento internacional de calidad del software: ¿Cómo seleccionar adecuadamente a un profesional de aseguramiento de calidad del software?

La tarea de realizar una correcta selección de un profesional de SQA tiene ciertas complicaciones añadidas a las de elegir cualquier profesional de otras actividades de desarrollo del software.

Por un lado está la intrusión, que se ha visto incrementada en los últimos años debido a la crisis. Muchos desarrolladores de software, que han perdido su empleo debido a recortes de nóminas de empresas, han visto una posibilidad laboral en el área de SQA, realizando un trabajo que no les agrada demasiado, pero que les permite tener un ingreso mientras consiguen reincorporarse a la actividad de la programación, muchas veces en otras empresas, generando perdidas en la inversión que supone la adquisición de un nuevo recurso.

Por otra parte están los perfiles, un departamento moderno de calidad de software posee varios perfiles que son significativamente diferentes. Líderes, managers, analistas, testers, responsables de automatización, desarrolladores de herramientas y pruebas automatizadas, administradores de sistemas, testbeds y virtualización, etc. requieren distintos conocimientos y es muy común encontrar profesionales que se postulan a cualquier oferta relacionada con la calidad del software solo porque tienen alguna experiencia relacionada con un departamento de SQA.

Otro punto a tener en cuenta son los recursos y tiempos disponibles para la contratación.
Siempre ha sido muy difícil establecer el punto de corte en una evaluación-filtro. Un examen normalmente es algo injusto, nos pone a prueba en un día y hora fijados y no suele tener en cuenta si esa noche no descansamos bien, si hemos tenido la oportunidad de prepararnos adecuadamente o si hemos recibido alguna noticia que nos impide estar al 100% de nuestras capacidades. Por otra parte si el examen es demasiado permisivo, no cumple su función y no solo hace perder el tiempo al candidato y al seleccionador sino que puede convertirse en un desperdicio de recursos. De cualquier forma es muy difícil determinar durante una entrevista si el profesional que tenemos en frente es el más adecuado para cumplir con las responsabilidades que la vacante requiere.
Si los recursos del proyecto lo permiten, siempre es mejor completar la fase de selección con un "período de prueba" como se suele llamar a la evaluación del profesional durante un tiempo más prolongado, dónde se pueden evaluar todos los aspectos necesarios mientras realiza la tarea para la que se está postulando. Lógicamente, para llegar a esta segunda etapa de selección, se deben haber preseleccionado los postulantes cuyas aptitudes coincidan de manera mayoritaria con las requeridas por el perfil.

Un punto importante, que sin dudas marcará una diferencia significativa en la reducción de costes de la selección es, el contar con un departamento de RRHH que posea evaluaciones para el diagnostico de competencias profesionales, discriminando las fortalezas y debilidades por cada competencia y peso de la misma. Existen hoy en día herramientas que facilitan el trabajo permitiendo comparar los resultados obtenidos de cada profesional con el nivel requerido de todas las competencias evaluadas, simplificando de manera significativa la predicción del desempeño del profesional en el área designada dentro del departamento.

Como dije al principio, no soy de la idea que haya una receta mágica o patrón incuestionable que se aplique a todas las situaciones en cualquier fase que una empresa se encuentre. Dicho esto voy a comentar los procesos de selección que suelo aplicar y que me han dado resultado, lo cual no significa que, en otras circunstancias sean aplicables u obtengan el mismo éxito.

El punto de corte es una de las variables más solidarias al proyecto, hay metodologías para establecer dónde situarlo y así o bien permitir la incorporación de la mayor cantidad de recursos que cumplan con el perfil, a riesgo de que se "cuele" alguno que no lo cumpla, o solo aquellos que realmente encajan perfectamente dejando a fuera postulantes que pudieran ser muy útiles. Esta decisión solo puede ser tomada en conjunto a las necesidades establecidas en el momento en que se crea una vacante.

Lo primero es la publicación de la oferta de empleo

He visto algunas ofertas de trabajo, que indicaban algo así como: -Se solicita profesional de SQA con experiencia, dinámico y capaz de llevar adelante un grupo de trabajo. Por favor enviar CV con pretensiones a ...
No hace falta ser un erudito para darse cuenta que clase de profesionales se postularán a un aviso así. Prácticamente todos ellos que estén buscando empleo y sepan que significa SQA. Incluso puede que alguno más que ni siquiera sepa el significado de esta sigla nos envíe su CV.

La publicación de la oferta debe ser clara en cuanto al perfil solicitado, detallando cuando menos las competencias mínimas y deseadas y el nivel requerido para cada una de ellas, las responsabilidades a asumir y una breve descripción de la posición.

Por el lado bueno esto generará un filtro para aquellos verdaderos profesionales quienes encuentren su perfil diferente al solicitado. La parte mala es que a la vez que ayudará a otros sin escrúpulos a magnificar sus C.V. en los aspectos requeridos publicados. De cualquier manera, desde el punto de vista estadístico, tendremos menos y más precisos C.V. que analizar si el puesto está bien especificado en relación a una publicación más genérica.

Evaluación de los C.V.

Cualquier departamento de S.Q.A. que se jacte de serlo, es un departamento orientado a la documentación, las principales actividades suelen estar documentadas y normalmente se maneja con documentos maestros que generan instancias (planes, casos, informes, etc.).

Todos los perfiles del departamento suelen invertir una buena parte de su tiempo documentando y efectuando análisis y síntesis de lo que se documenta, sin ir más lejos, el reportar una incidencia de manera apropiada es también una tarea de documentación que requiere cierta agilidad y conocimiento.

Estas tareas cotidianas de redacción, síntesis y análisis son bastante más complejas que la confección de un currículo, al menos a mí me llama mucho la atención si un postulante no estructura correctamente su experiencia y conocimientos dentro de su C.V.

Otro punto que evalúo de manera temprana, es la compatibilidad entre los conocimientos y su relación con la experiencia. Si un postulante presenta en sus antecedentes laborales, haber trabajado para Capgemini y luego para IBM, no me resulta para nada extraño encontrar que sus conocimientos de metodologías abarcan TMAP y CMMI. Por otra parte, si en otro C.V. encuentro que conoce todas las metodologías modernas de aseguramiento de la calidad y su experiencia laboral ha sido desarrollando software, me llama más la atención. De cualquier forma es probable que este último no esté mintiendo, solo que exagere o piense conocer una metodología es algo que se adquiere simplemente trabajando en una empresa que la utilice.

La revisión de los C.V. recibidos es el primer filtro que aplico, si bien suelo ser muy estricto con algunos aspectos como los que he mencionado anteriormente, suelo centrarme en evaluar la compatibilidad del postulante con el perfil solicitado, para ello realizo una pequeña tabla de puntos que luego aplico a cada C.V. al estilo examen, luego fijo un mínimo en función del punto de corte establecido y descarto los que no lo superen.

La entrevista telefónica

Este relativamente moderno proceso, no muy común en algunos países en los que he trabajado, puede eclipsar la perdida de tiempo y algunas veces económica que significa concertar una cita con el postulante, sobre todo cuando este no vive en la misma ciudad y es necesario costear traslados para su evaluación.

Independientemente del candidato, suelo utilizarla para informar al postulante de detalles de la empresa, proyecto y posición dónde se encuentra la vacante, como así también enumerar las tareas y responsabilidades más significativas que llevará a cabo. En algunas oportunidades, esta práctica ha ayudado al profesional postulante a concluir en que no es lo que estaba buscando.

El formato de esta entrevista es muy compacto, normalmente suelo concertar una cita de tal forma que el postulante pueda elegir el día y momento en que se sienta más cómodo, el tiempo de la misma suelen ser 20 minutos y solo permito que se extienda si el candidato está a gusto narrando sus experiencias o considero que la situación lo requiere. En pocas palabras, suelo permitir que el profesional se vaya por las ramas una vez que he obtenido la información necesaria para tomar la decisión y creo que es un posible candidato a la siguiente fase de selección.

No suelo dar feedback en este punto a menos que esté convencido que el candidato no cumple con el perfil.

Por último, si bien las tecnologías de hoy lo permiten, prefiero no utilizar la conferencia telefónica para entrevistar a un candidato de manera remota, un proceso de selección es en sí una situación tensa para el candidato y trato de hacerla lo más amena posible. Si necesito que más de un examinador tenga la entrevista con el mismo postulante, siempre prefiero que sea en llamadas independientes y razonablemente espaciadas en el tiempo.

El examen

El siguiente punto es el examen, y este trae complicaciones inherentes a la problemática a abordar. Son pocas las reglas que he podido aplicar siempre en este punto. Con la tecnología de hoy en día suelo preferir los exámenes remotos, aunque no todas las empresas poseen la herramienta adecuada para examinar remotamente a un profesional evaluando todos los aspectos necesarios. Como he comentado más arriba, la interacción con el departamento de RRHH es muy importante ya que pueden ser nuestros mejores aliados en cuanto al formato y herramientas.

La entrevista cara a cara

Si el examen ha sido en el lugar, no soy de la idea de forzar a asistir una vez más al candidato a la empresa con el fin de entrevistarlo, normalmente se encuentra trabajando y no puede estar pidiendo permiso todos los días para asistir a entrevistas. Si es este el caso, suelo leer rápidamente el examen, identificar los puntos a comentar y comenzar la entrevista con el final de la evaluación de las competencias.

En este punto y si todo salió bien, debería tener toda la información necesaria para poder cotejar la evaluación contra el perfil maestro y determinar que candidatos se ajustan más a la vacante. Aprovecho el final de la entrevista para enterarme respecto a las necesidades de motivación del candidato, como así también a determinados estilos relacionados a las tareas. Suelo utilizar el C.V. impreso para hacer estas anotaciones, normalmente lo imprimen a cara simple, lo que me deja un buen espacio para apuntar datos que serán tenido en cuenta a la hora de realizar la selección.

La decisión final

Una vez analizado el perfil de cada candidato, tomar la decisión final es sin dudas la tarea más fácil. Solo hay que comparar las fortalezas y debilidades de cada competencia del candidato con las esperadas y el que más se acerque es el más adecuado. La parte difícil es la etapa anterior a la publicación de la oferta, la definición del perfil mediante la selección de competencias y la calibración de los pesos de las mismas es una tarea que a menos que se tenga experiencia, no sale bien a la primera.

En resumen, no conozco formulas mágicas que nos digan con certeza que profesional desempeñará un mejor trabajo en el departamento de SQA, pero si existen procesos definidos, herramientas y metodologías que pueden ayudarnos mucho. La experiencia también suele ser una buena herramienta.

Me dejo algunos detalles en el tintero, así que adelante con vuestras preguntas, estaré encantado de contestaros.

Ubuntu Lucid Lynx vuelve a Google después de intentarlo con Yahoo.

2010-05-03T08:57:00.000-07:00

Ubuntu seguirá utilizando Google como el buscador por defecto de Firefox en su 10,04 "Lucid Lynx" puesta en libertad, poniendo fin a una breve fase de prueba con Yahoo!

A principios de este año Canonical anunció que estaba dejando de Google en favor de Yahoo! Como el motor de búsqueda por defecto es la distribución de Firefox.

Sin embargo, ningún lanzamiento oficial se realizó con Yahoo! Solo aquellos usuarios que bajamos el Beta somos los únicos que hemos visto el cambio que finalmente solo fue usado en las versiones preliminares de Lucid.

En un anuncio a la lista de correo de desarrolladores de Ubuntu de la noche a la mañana, el gerente de ingeniería de Canonical, Rick Spencer, ha pedido al equipo de escritorio de Ubuntu para cambiar el valor por defecto a Google tan pronto como sea "razonablemente posible".

A principios del ciclo de 10,04 Spencer anunció que Ubuntu cambiaría el motor de búsqueda predeterminado por Yahoo!, Y el cambio que se implementó para varias versiones pre-lanzamiento.

Sin embargo, en la versión final, vemos relucir a Google al abrir por primera vez el Firefox.

"Al elegir el proveedor predeterminado de busqueda, consideramos factores como la experiencia de usuario, preferencias de los usuarios, costos y beneficios para Ubuntu.", según Spencer.

Ubuntu Lucid Lynx cambia Google por Yahoo en la página de inicio de Firefox.

2010-04-04T04:12:00.000-07:00

Hoy me he instalado la Beta 1 de la última versión de Ubuntu, 10.4 Lucid Lynx. Para los que no lo saben, Ubuntu históricamente ha sacado una nueva versión, del que para muchos es el mejor sistema operativo de hoy en día, cada seis meses, cada versión es tiene un nombre (codename) y un número de versión que corresponde al año y mes. El nombre de la versión es un animal y un adjetivo que llevan la misma letra, la 6.06 (Junio de 2006) se llamó Dapper Drake
(Pato Elegante), la siguiente, 6.10 (Octubre de 2006) se llamó Edgy Eft
(Salamandra Nerviosa) y así sucesivamente.

Históricamente Ubuntu ha introducido cambios en el navegador web Firefox que viene distribuido, como así también en muchos de los paquetes. Estos cambios son buenos y se encuentran en distintos ordenes, por ejemplo, para garantizar la estabilidad del sistema, a algunos programas se les quita la opción de actualizarse y la responsabilidad de la actualización queda asumida por el distribuidor. Así también otros cambios son simplemente mejoras estéticas.

En esta última versión se ha cambiado la página de inicio de Firefox, según ha explicado Rick Spencer en la solicitud del cambio, Canonical, la empresa que desarrolla Ubuntu, ha hecho un acuerdo con Yahoo con el fin compartir ganancias de publicidad.

Este cambio, al igual que todos los que realiza Ubuntu, es solo una elección para el usuario, ya que la página de inicio del navegador se puede configurar fácilmente y si los usuarios desean usar Google o cualquier otro navegador, solo deberían cambiarla y listo. Por otra parte, que Ubuntu distribuya programas no significa que el usuario no pueda optar por descargarlos desde los sitios web oficiales y tener las versiones originales de estos.

Lo que encuentro interesante de este cambio y a su vez lo que me ha llevado a realizar esta entrada en mi blog es mi experiencia personal con Yahoo.

A decir verdad, hacia tiempo que no usaba Yahoo, por comodidad, por costumbre, simplemente porque un día Google pasó a gustarme más o porque ya venía como página de inicio en mi navegador favorito. El tema es que hacía mucho que no realizaba una búsqueda en Yahoo.

Cuando abrí el navegador y encontré que había cambiado la página de inicio, me inquietaba la idea de conocer el motivo, fue ahí que di con la carta de Rick y pensé: Si esto va a ayudar a la empresa que desarrolla y distribuye gratuitamente mi sistema operativo preferido pues, bienvenido sea. No obstante pensé: ¿Que gana Yahoo con esto? El usuario va a cambiar la configuración de la página de inicio en un momento.

La respuesta apareció frente a mis ojos al realizar la primera búsqueda. Yahoo ha cambiado mucho desde la última vez que lo utilicé y estoy convencido que habrá mucha gente como yo que por diferentes razones no se ha planteado probarlo. No solo lo que vi me gustó mucho, sino que por el momento he decidido dejarlo como página de inicio en mi navegador Firefox. Está claro que, la parte beneficiosa para Yahoo en su trato con Canonical es justamente darnos la oportunidad a los usuarios de probar una vez más a Yahoo como motor de búsquedas.

No voy a detallar las virtudes que he encontrado en Yahoo en este post, en lo personal, pienso que merece la pena probarlo.

Como siempre me gustaría leer vuestros comentarios sobre este tema.

Fuentes:
http://www.guia-ubuntu.org/index.php?title=Versiones_de_Ubuntu
https://lists.ubuntu.com/archives/ubuntu-devel/2010-January/030065.html

Imagen del post descargada de:
http://mowmotheme.it/

La filosofía Zen de SQA.

2010-03-06T17:49:00.000-08:00

Según Wikipedia, Zen (禅) es el nombre en japonés de una tradición del budismo Mahāyāna, cuya práctica se inicia en China bajo el nombre de Chán (禪). Esto no tiene nada que ver con SQA. No obstante, hace ya varios años se puso un poco de moda el usar la frase “La filosofía Zen de...” para destacar cosas que, a pesar de ser obvias, no son tenidas muy en cuenta.

La primera que vi relacionada al desarrollo del software fue una escrita en alguna página de Visual Basic, dónde alguien escribía una lista de obviedades que, separadas nadie podía negar y juntas quedaban bonitas bajo el nombre de “La filosofía Zen del Visual Basic”. Otro ejemplo es el huevo de pascuas que trae el lenguaje de programación Python, al recibir la orden “import this”.

Sin dudas, en el aseguramiento de la calidad del software, también tenemos muchas obviedades que destacar, que a su vez, por más obvias que parezcan, muchas veces es necesario recordar. Por eso he escrito lo que yo llamo “Mis diez puntos de la filosofía Zen de SQA”.

Con esto no quiere decir que sea un gran sabio que se ha sentado a meditar por horas junto a la luz de cientos de velas como en la serie Kung Fu. Lejos de eso, la filosofía Zen de SQA que presento aquí no es más que la recopilación de diez obviedades que en mi experiencia he tenido que recalcar, repetir y destacar para que se comprendan.

Obviamente al estar todas juntas y tener un nombre tan especial queda más bonitas, y si no hubiera hecho esta pequeña introducción, con ese título, alguno hasta podría imaginar a un hombre de largas barbas blancas, sentado en medio de un templo redactando lo siguiente...

SQA is not testing (SQA no es probar).
Sin dudas, este es uno de los puntos obvios que más he tenido que recalcar a lo largo de mi carrera. Podemos encontrar las definiciones y diferencias de SQA y testing en cientos de libros, manuales, sitios de internet, etc. No obstante, hay mucha gente que lo confunde. Este error no solo se produce a nivel semántico, en muchas oportunidades he tenido que esmerarme para transmitir lo que considero como procesos modelo para comprobar que un software cumpla con las especificaciones, ante un público que hasta ese momento no imaginaba que sin especificaciones no puede haber SQA.

Test execution is not just testing (La ejecución de pruebas no es solo probar).
Las épocas de escribir los casos de prueba en una hoja de cálculo, para luego utilizar esas mismas hojas como parte de la ejecución e incluso el informe de las pruebas gracias a Dios han quedado atrás. Con el software que hoy existe nadie trabaja así, por lo que la ejecución de un caso de prueba no solo nos entrega información referente a la prueba, sino también al tiempo que ha costado ejecutarlo, al resultado de todas las ejecuciones anteriores e incluso en software más moderno, a la evolución versionada del caso para adaptarse a las nuevas funcionalidades del software. Existen muchas herramientas libres que nos entregan toda esta información, que sin dudas, es vital para generar métricas y realizar planificación.

The analysis outweighs the test execution (El análisis pesa más que la ejecución de pruebas).
Dentro de las actividades de SQA, una de las más importantes es el análisis. Un error en la ejecución de un caso de prueba, probablemente sea detectado en la siguiente ejecución, mientras que un error en el diseño de un caso de prueba, posiblemente sea detectado durante la investigación de Calidad de la Calidad al buscar como pudo llegar el fallo de software a producción.

Quality of Quality counts (La calidad de la calidad cuenta).
Por más pequeño que sea un departamento de calidad, y me refiero con esto a 3 o 4 profesionales, es importante contar con mínimos controles de la calidad. Gracias al software que existe hoy en día, es posible obtener métricas de la calidad que se ajusten a nuestras necesidades a bajo coste.

Automation is the key (La automatización es la clave).
Hoy en día existe mucho software que podemos adaptar a nuestras necesidades para conseguir un sistema de automatización de pruebas de bajo coste, que quede como un guante en nuestros procesos de calidad. Una vez más, no importa el número de recursos de un departamento de software, automatizar la ejecución de casos de prueba debe ser una meta a perseguir.

Existing terminology should be enough (La terminología existente debería ser suficiente).
Otra obviedad que he tenido que recalcar en muchas oportunidades y en varios departamentos de calidad, es la necesidad de utilizar la terminología existente de manera apropiada. Como todo protocolo, el lenguaje técnico se ha creado para derribar barreras en la comunicación, me resulta difícil de entender la resistencia natural a su buen uso.

Likewise existing methodologies should be enough (Así mismo, las metodologías existentes deberían ser suficientes).
Siendo que la ingeniería del software es muy joven aún, el aseguramiento de la calidad del software está literalmente en pañales. No obstante, existen muchas metodologías probadas y funcionando desde hace años, metodologías diseñadas por profesionales que han dedicado tiempo y experiencia afrontando retos en todas las áreas y escalas. En muchos casos suele resultar más efectivo implementar y adaptar una metodología que tratar de crear la propia, sin mencionar los costos directos e indirectos que acarrea la colosal tarea. Desde mi punto de vista, crear una metodología debe ser la solución a una necesidad no cubierta y en ningún caso debe ser tomado a la ligera.

Not everyone can be a tester (No cualquiera puede ser un tester).
Sin dudas, esta es una de las obviedades que más he tenido que recalcar. Si mal no recuerdo, Glenford J. Myers en 1979 escribió que la tarea del tester es una tarea orientada al fracaso, ya que su objetivo es encontrar errores y su tarea termina cuando no hay más errores que reportar. El autor de esta afirmación desde entonces, trataba de identificar el perfil que un tester debía tener. Hoy en día poseemos métodos y procesos más complejos que en aquel entonces, y si bien algunos aspectos del perfil de tester no han cambiado, como ser la atención al detalle y la preferencia por el trabajo orientado a la documentación, el tester sigue siendo un perfil tan diferente al desarrollador, como a cualquier otro perfil que podamos encontrar en una empresa. Con esto no quiero decir que un desarrollador no sea capaz de ejecutar un caso de prueba, repitiendo 20 pasos durante 40 escenarios. Lo que se debe tener en mente es la incapacidad de muchas personas para realizar este trabajo con la misma atención durante ocho horas diarias.

Not everyone can be a analyst (No cualquiera puede ser un analista).
En menor proporción, recuerdo que también he tenido que explicar en alguna oportunidad esta obviedad. El ejemplo que suelo poner es como diseñaría un analista un caso de prueba utilizando partición de equivalencia y el análisis de valores límite comparándolo con la forma en que un desarrollador lo diseñaría utilizando el sentido común. Para mi suerte, las veces que he tenido que explicar porqué se necesita un perfil tan específico para la que posiblemente sea la tarea clave en todo proceso de aseguramiento de calidad, lo he tenido que hacer a desarrolladores, de forma que caían fácilmente en la trampa que les ponía.

Testers are on the same side as the developer (Los testers están en el mismo bando que el desarrollador.)
Hay una tendencia, cada vez menor pero continúa existiendo, a pensar que el trabajo del tester es opuesto al del desarrollador. Hay incluso quienes pintan al departamento de calidad del software como la policía que controla el trabajo de los demás y señala con el dedo a quien se equivoca, incluso, he llegado a ver una empresa que ofrece servicios de SQA de manera externa y su lema (impreso en la tarjeta) reza: “your devil's advocate” (Su abogado del diablo).
Nada de esto es correcto y muchas de estas afirmaciones se basan en la ignorancia. En primer lugar un fallo detectado en un programa es el resultado de uno o más errores introducidos en el código. Estos errores son inevitables y no son un acto de incompetencia, no son algo que se pueda arreglar prestando un poco más de atención o realizando más pruebas de escritorio. Los humanos fallamos y cometemos errores de todo tipo, y cuando se desarrolla software es inevitable introducir errores involuntarios en el código, a menos que el programa sea realmente trivial.
Aquí es dónde entra la labor del departamento de calidad del software, es el responsable de trazar una red dónde los fallos queden atrapados, de proporcionar al desarrollador la información necesaria para la identificación del origen del fallo, es el responsable de ayudar al desarrollador en su tarea. Los testers y los desarrolladores tienen una tarea en común, hacer que el software salga con la menor cantidad de fallos posibles y está visto que cuanto mejor trato y colaboración exista entre ellos, se generará una sinergia que de manera natural elevará la calidad de cada componente.

Os invito a extender estos diez puntos, publicando comentarios con vuestras propias experiencias. Es probable que más tarde me acuerde de alguna más, de ser así, yo también publicaré las nuevas en comentarios.

Automatización total de pruebas para el aseguramiento de la calidad - Primera parte.

2010-01-06T03:30:00.000-08:00

Luego de la introducción a este tema, la cual redacté hace unos meses y publiqué el 23 de agosto de 2009 en este blog, me he hecho un rato para escribir un primer capítulo.

Por un lado agradezco el no haber tenido tiempo, ya que en estos meses he logrado realizar algunos ajustes en la metodología que, a continuación quedan plasmados en esta nueva publicación. Casualmente, el tema principal de la misma es uno de ellos.

Salida de ejecución de un caso automatizado de prueba.

A lo largo de mi experiencia con la automatización de pruebas, me topé con muchos asuntos que si bien, a simple vista parecían tener una solución idéntica a la ejecución manual, al ponerlos en práctica descubríamos que, en el mejor de los casos no era la solución más óptima y en otros se volvía sencillamente impracticable.

También he tenido la oportunidad de detectar otras situaciones dónde, la mejor solución era efectivamente hacerlo como se hacía en la ejecución manual, no obstante, a la hora de implementar esa solución, ya sea software, un proceso o documentación, tal vez por adaptarnos a la plataforma de automatización, realizamos pequeños cambios que terminaron teniendo un impacto directo en la calidad. La evaluación de la salida de la ejecución de un caso automatizado de prueba es un buen ejemplo de estos cambios.

En un principio y basándonos en lo que conocíamos, entendimos que una ejecución de un caso automatizado debía devolver una salida binaria, ejecutó correctamente o no ejecutó correctamente. Sobre esta suposición se construyeron el resto de los procesos que contemplaron la evaluación de esas salidas y las posibles excepciones a realizar. También se comenzó a diseñar software para soportar el proceso.
Cuando comencé a documentar los procesos, aprovechando nuestro modelo de documentación estructurada, tome el procedimiento que había redactado de ejecución manual para reusarlo. Fue recién ahí cuando me pregunté por primera vez: ¿por que lo estamos haciendo distinto?
La ejecución manual de un caso de pruebas, tiene una salida ternaria: Los resultados obtenidos equivalen a los resultados esperados, durante la prueba se detectaron fallos en el software o el caso no se puede ejecutar.

En el brainstorming inicial y posteriores reuniones durante el comienzo del diseño del modelo de automatización, se discutieron las similitudes y diferencias más significativas respecto a la ejecución manual vs ejecución automática. Tal vez la más obvia fue, que mientras un humano es capaz de asegurar que hay un fallo en el software, una ejecución automática, que se haya desarrollado dentro de costes aceptables, solo podrá decirnos si el caso ejecutó correctamente o no ejecutó correctamente. A su vez, correctamente es relativo a lo contemplado por el tester que lo automatizó.
En este tipo de diferencias fue donde pusimos esfuerzo en eclipsar el impacto. Fue una gran labor, que Dios mediante iré publicando a medida que mis obligaciones me lo permitan.

Creíamos tener bien identificada la complejidad y limitación de la evaluación de la salida de un caso automatizado y nos pusimos a trabajar sobre ello. Fue en ese momento cuando, casi por casualidad, detecté otra situación dónde pensábamos que la mejor solución era realizar un equivalente a la ejecución manual y sin embargo, nos encontrábamos obviando un punto crucial: Existen situaciones en las que un caso de prueba no se puede ejecutar, y darlo por malo incurre en un incremento directo en el coste del aseguramiento de la calidad.

Antes de citar a los involucrados a otra reunión, preferí evaluar detenidamente si contemplar esta diferencia merecía la pena, por lo tanto me remití a enviar correo electrónico informando el descubrimiento y que estaría estudiándolo detenidamente. Debo admitir que esa noche dormí muy poco, me desvelé proyectando las implicaciones del cambio y la madrugada me encontró escribiendo un primer borrador del proceso con salida ternaria.

Al principio me sentí desconcertado por no haber visto lo evidente, no obstante, el motivo de la omisión es entendible: hasta ese momento, nunca habíamos escuchado hablar de salida ternaria de un caso automatizado, lo más parecido a ello era salida binaria con n motivos por salida, no obstante estos motivos solían desencadenar dos acciones.

Por otra parte, nuestra salida no era binaria pura, ya que en el afán de evitar reportes de fallos inexistentes, decidimos darle una tercera dimensión a la evaluación de resultados binarios, teniendo así en cuenta la salida histórica del la ejecución del caso al momento de decidir el resultado de la prueba. En nuestro caso, el algoritmo que aplicamos para la evaluación de una salida de prueba y su línea media histórica se encuentra íntimamente emparentado con la naturaliza de nuestro objeto de pruebas, no creo que os resulte de utilidad conocerlo, no obstante, puedo daros algunas ideas generales si lo necesitáis.

Lo primero que hice fue poner en una balanza los pro y contra del cambio:

Pro:
El incremento en la fiabilidad del resultado: al tratar en procesos independientes los casos no ejecutados de los fallidos, matemáticamente la cuenta de casos fallidos disminuye, lo cual directamente incrementa los aciertos en la estadística general de la ejecución.

Contra:
La salida por defecto del flujo en el análisis de los casos no ejecutados es la des-automatización del caso, proceso que explico más abajo, lo cual decrementa el número total de casos de prueba automatizados, cosa que desencadena en un nuevo incremento de la efectividad de la ejecución, aunque esto último puede entenderse como un tanto engañoso.

Pro:
Reducción de costes por re-prueba (re-test) manual: Dado que una sola ejecución de un caso automatizado no es capaz de determinar un fallo, este no puede enviar un informe del mismo. Un humano debe revisar las trazas de ejecución y determinar la necesidad de una re-ejecución manual o cambio de la implementación en caso de detectar un fallo en la automatización.

Contra:
El diseño de un proceso de análisis de fallo para una salida binaria no es compatible con el de una ternaria y mientras que para el primero existen muchas fuentes de documentación y modelos a instanciar, para el segundo es preciso crearlos y adaptarlos a nuestras necesidades, dejando lugar a fallos y costes extras por el procedimiento empírico de prueba y error.

Pro:
El histórico de ejecución estaría libre de errores producidos por una mala configuración: Al separar los casos no ejecutados de los fallidos, tenemos una línea media más recta como entrada del algoritmo histórico, con lo cual el porcentaje de efectividad de los fallos reportados subiría.

Contra:
Es importante contemplar que el número de puntos que trazan los históricos de resultados puede variar. También es necesario añadir lógica a la evaluación del resultado ya que, dependiendo de nuestro procesamiento de casos no ejecutados, podemos tener varias ejecuciones de un mismo caso en el mismo ciclo, con lo cual si nuestro algoritmo de análisis no es lo suficientemente inteligente, podríamos tener más de un punto en el mismo eje de tiempo.

Pro:
Se simplifica la distribución de tareas entre recursos: normalmente los casos fallidos se atenderán por perfiles diferentes a los no ejecutados. De esta manera, tareas para distintos perfiles se encuentran separadas desde sus inicios.

Pro:
Se obtiene un mayor detalle a golpe de vista: es muy distinto ver que durante la ejecución hubo un 92% de casos correctamente ejecutados y un 8% de casos fallidos, a leer que el 92% de los casos ejecutaron correctamente, el 6% quedó sin ejecutar y el 2% no superó la prueba.

Pro:
Pasado cierto umbral de efectividad, ciertos casos de prueba podrían enviar automáticamente el informe del fallo, esto lógicamente es impensable con una salida binaria.

En este momento no recuerdo si había evaluado alguna implicación más, pero si recuerdo que la balanza se encontraba inclinada de manera favorable a tomar esta decisión y que la noche planeaba alargarse.

Decidido por el resultado, comencé a crear un croquis del proceso para generar y tratar la tercera salida: La no ejecución del caso.

Para una ejecución manual había definido los siguientes estados posibles de un caso de prueba: "No ejecutado", "Fallo", "Ok", "Bloqueado", "En ejecución", "En pausa", "Descartado" y "Pendiente de revisión", y como salida todos los estados anteriormente comentados con excepción de "No ejecutado", no obstante, esta salida se sustentaban en tres patas que claramente se podían ver como:

Ok: Cuando el humano determina que, durante la ejecución del la prueba, el objeto de la misma se comporta según los resultados establecidos y no ha detectado fallos adyacentes directamente relacionados al caso de prueba.

Fallo: Cuando el humano determina que el objeto de prueba no cumple con las especificaciones descritas en el caso de pruebas, o se produce un fallo adyacente que está directamente relacionado con la ejecución del caso de prueba.

No ejecutado: Los casos que no habían sido ejecutados por cualquiera de los motivos que conforman un estado del caso, como ser: Bloqueado por un fallo producido en otro caso, o que se detecta claramente que el caso está mal y debe ser revisado.

Es decir que a pesar de los n estados del caso, la salida en sí es ternaria, y es atendida por tres procesos que definen pasos para los n motivos de cada salida.

Lo que me decidió a llamar a esta tercera salida automatizada "caso no ejecutado" no fue más que su analogía con la ejecución manual y la naturalidad con la que que encaja en nuestra estructura de pensamiento: "Ok/Not Ok".
Cuando un tester ejecuta un caso de prueba, puede suceder que se encuentre con que el entorno no está preparado, no tiene las herramientas necesarias, el caso se encuentre bloqueado por otro caso, etc. Básicamente una serie de situaciones que, si las advierte, no actualizará el estado del caso a fallido, nuestra herramienta de automatización de pruebas también debe ser capaz de advertir al menos alguna de estas situaciones.

Dependiendo de la madurez de los procesos que envuelven nuestro proceso de automatización y del presupuesto asignado, podemos tener mayor o menor capacidad de detección de situaciones que discriminan un caso fallido de uno no ejecutado, por ejemplo: Si tenemos un proceso de documentación de requerimientos versionado y una de las características de nuestros casos de prueba es la dependencia de estas versiones, al cambiar una especificación los casos de prueba afectados podrían ser establecidos como "No ejecutado" con motivo "Pendiente de actualización" de manera automática y durante el tiempo de ejecución. Por otra parte, no es muy difícil establecer ciertos controles para los fallos más comunes de configuración previo a la ejecución de un caso de prueba.

Como antes comentaba, mi primer croquis se centraba en la parte del proceso que atiende tanto la generación de la tercera salida, como el tratamiento de la misma, las posibilidades con esta tarea son infinitas e imaginarlas no es tan difícil, sobre todo si lo hacemos ad-hoc a nuestro objeto de pruebas, la tarea más ardua consiste en evaluar de manera precisa si el coste de la implementación de la detección de un motivo de "caso no ejecutado" está justificado. Por un lado, porque hay que hacer estimaciones de uso de diversos recursos para desarrollar software y documentación, por otra parte, es imprescindible contar con una estadística que nos asegure que el implementar un análisis de salida mitigará una situación que si no es atendida generará un coste superior.

Algo que encontré necesario añadir fueron tres nuevos atributos al caso de prueba:
Cantidad de resultados consecutivos OK antes de una revisión manual: Si un caso de pruebas da, a lo largo de ciclos de ejecución siempre OK es sospechoso de poseer algún error. Esta regla no se puede aplicar de manera uniforme a todos los casos de prueba automáticos, de forma que debe ser una característica a configurar en cada uno de los casos de prueba.
Cantidad de falsos Fallos detectados: Para lograr una acertada evaluación de los fallos que me permita que ciertos casos de prueba generen de forma automática los reportes de fallos, me fue imprescindible contar con la posibilidad de registrar en cada caso de prueba que haya sido establecido como fallido de manera incorrecta durante la ejecución automatizada.
Generación de informe automático: Esta bandera indica al sistema de automatización que, si este caso falla se debe generar un informe automático.

Estos atributos se basan en la madurez de los procesos relacionados con la automatización. Realizar un informe de un fallo de manera automática es una tarea que puede ser desde muy fácil hasta casi imposible, dependiendo de nuestro modelo de caso de prueba automático.

Para realizar las estadísticas tomamos como dato computable todo aquel que sea obtenido con un objeto de prueba y una configuración determinada, al cambiar cualquiera de estos se considera un nuevo ciclo, si un caso es ejecutado varias veces dentro de un ciclo, el estado será el de la última ejecución. De esta manera podemos tener a lo largo de varios ciclos casos que no se han ejecutado, no obstante, los valores que funcionan de disparadores son los de la línea media, de forma que el hecho de no ejecutar durante uno o más ciclos un caso de prueba, solo quita granularidad pero el resultado no se ve afectado.

Una ejecución de prueba solo puede tener 3 posibles salidas: Ok, Fallo o "No ejecutado".
Para la primera se contempla el histórico de ejecución vs "Cantidad de resultados consecutivos OK antes de una revisión manual", si este número se alcanza, el estado de la ejecución queda en Ok y el caso de prueba pasa a "Pendiente de revisar" Es decir que, el próximo ciclo no se ejecutará de manera automática a menos que se restablezca el contador.
Cuando es Fallo, se determina si la bandera de "Emitir informe" está activa, si es así, se comprueba si el último informe emitido está cerrado, si esto se cumple, se traza la media de efectividad y si esta supera el umbral de emitir informe, este es emitido.
Los casos fallidos que hayan emitido informe de manera automática, tendrán una visualización diferente para el perfil responsable de la verificación y generación de informes.
Finalmente, para los casos "No ejecutados" se determinará la acción dependiendo de los motivos, como antes comentaba, estos casos son bastante específicos de cada proyecto y no veo que pueda resultar interesante salvo por la Des-automatización de un caso de prueba.
Algún caso genérico podría ser el de la re-ejecución lanzada de manera automática: Suponiendo que la ejecución del caso dependa de algún componente externo, se valide como pre-condición el correcto funcionamiento de este componente. Si este falla, el caso podría quedar como "No ejecutado", con un sub-estado que indique su ejecución automática en cuanto el componente vuelva a estar disponible.
De cualquier manera siempre estaré dispuesto a contestar las dudas que me plantees mediante comentarios en este blog o correo electrónico.
Se debe tener en cuenta que, cada uno de los contadores son incrementados/decrementados mediante ciclos y no ejecuciones, es decir, las n ejecuciones posteriores a la primera sobre el mismo ciclo (configuración+objeto de pruebas) no alterarán estos contadores.

Des-automatización de un caso de prueba automatizado.

La Des-automatización de un caso de prueba automatizado es un proceso que hemos creado como respuesta a la problemática de la fidelidad de los resultados.
Es fundamental que confiemos en nuestro proceso de automatización, de otra manera, incurriremos en costos ocultos como revisiones, ejecuciones redundantes y repruebas manuales (manual re-test) que no aportarán mayor beneficio que la confianza que debió brindar la primera ejecución.
Para poder confiar en nuestro proceso de pruebas automatizadas, este debe entregar resultados reales y esta tal vez sea una de las tareas más difíciles de diseñar. Personalmente suelo tirar del hilo del procedimiento empírico para lograr afinar estos procesos.
Volviendo al tema, cuando un caso de prueba no establece un patrón claro, es decir, que la línea media de ejecución está formada por picos entre la mínima y la máxima, este debe ser des-automatizado. Este proceso se puede hacer manual o automáticamente. La des-automatición no es más que establecer un estado al caso que no permita su ejecución automática e informe de esta petición. Históricamente, he hallado un patrón que afecta a la mayoría de los casos des-automatizados: El caso tenía más responsabilidad de la que debía, lo cual normalmente termina en una división del caso en más casos de prueba.

Espero que os resulte interesante esta primera entrega, es cierto que me he demorado en publicarla, pero también es cierto que quería contar con el tiempo de hacerlo bien. Como siempre, quedo atento a los comentarios que me queráis dejar. A todos os deseo ¡¡¡Muy Felices Reyes!!!

SQA: Temas tónica

2009-12-10T14:58:00.001-08:00

Hace un par de semanas, asistí al curso de certificación del ISTQB, seguido de su correspondiente examen, el cual por cierto aprobé y ya soy un ISTQB Certificado :)

Por temas éticos no voy a hablar del examen. Tampoco hablaré del ISTQB® porque lo que podría opinar ya lo dice es su sitio web.

Respecto al curso, voy a comentar que lo organizó nexoQA (Tambien organizador de expo:QA, nuestra conferencia nacional sobre QA y Testing). Duró tres días, aunque esto me pareció poco. Estuvo bien impartido, Gustavo, el profesor, supo hacerlo llevadero y cumplir la apretada agenda moviendo los temas polémicos a la hora del café o comidas. Y ya que la nombro, quiero contaros que la comida estuvo increíble.

El material entregado en general está bien, en pocas palabras, ha cumplido muy bien con mis expectativas y también lo ha hecho con su objetivo (ya que he pasado el examen).

En realidad, esta entrada en mi blog tampoco la hago para hablar del curso, seguramente estaréis pensando: Si no va a hablar del examen de certificación, tampoco del ISTQB ni del curso ¿Para que lo trae? Pues, la respuesta es muy simple: lo que quiero compartir con vosotros son algunos temas polémicos que surgieron durante el curso y de los que anteriormente también he sido testigo en otros cursos, seminarios, exposiciones y demás referentes a SQA y Testing, en fin, dónde sea que se reúnan profesionales con experiencia en calidad del software.

Uno de estos temas tónica lo llamaré "Intrusión"

Este tema es tónica, no solo en la rama de aseguramiento de la calidad del software, sino en toda la profesión. Como asistente del curso estaba un profesor de Ingeniería del software quien, no pudo quedarse callado cuando alguien sugirió que “la ingeniería del software no es en realidad una ingeniería”.

Las bases de esta idea también las había oído con anterioridad y se resumen a que no es preciso contar con ningún título o certificación para poder trabajar en casi cualquier empresa del mundo en cualquier punto del desarrollo del software.

En realidad no creo que sea así. Mi abuelo me contó que dónde el vivía, era el barbero quien se encargaba de quitar los dientes cuando estos se ponían feos. Supongo que en aquel entonces la ortodoncia no era considerada medicina, no obstante si lo era, simplemente era muy joven para requerir estudios y certificaciones precisas que acrediten al profesional a realizar su trabajo.

Algo muy similar sucede con la ingeniería hoy en día y esto permite intrusión en nuestra carrera profesional.

Aquí en España, por ejemplo, la mayor intrusión la sufrimos por parte de los egresados de la carrera de telecomunicaciones, quienes salen bastante preparados para cubrir el trabajo de varios puntos en el ciclo de desarrollo del software.

El problema dentro de la calidad del software se agrava un poco más, ya que recibimos intrusión de profesionales de nuestra propia carrera que no están emparentados con la calidad, normas y metodologías y que creen que no hace falta mucho más que ser programador, para cubrir un puesto de Analista o Tester.

A su vez, también tenemos la intrusión de la intrusión, es decir, gente de otras carreras que, ve una solicitud de tester y se presenta porque entiende que puede probar software.

Esto que resumo no es más que un pequeño debate que surgió durante el curso. Personalmente, he tenido la oportunidad de entrevistar profesionales en tres continentes distintos y efectivamente corroboro que es completamente cierto.

Hoy por hoy, exigir una certificación como puede ser el ISTQB, sería un filtro, a mi parecer, demasiado fuerte que dejaría fuera muchos y muy buenos profesionales de la calidad del software con años de experiencia. No porque no sean capaces de aprobar el examen, sino porque a lo largo de su carrera no han tenido la necesidad de hacerlo.

Aunque cada vez se aproxima más el día en que un informático no podrá ejercer sin sin una titulación correspondiente, hoy por hoy, exigirla sería poner un acceso muy limitado, además que una certificación o titulación no asegura que el profesional sea bueno. Solamente dice que ha tenido los medios para estar frente al examen y pasarlo. Por otra parte, creo que con mucho menos se puede conocer que clase de experiencia y conocimientos tiene un profesional. En lo particular lo que hago es tomar un examen que me permita tener una definición bastante precisa de en que rangos está el profesional y, como seguro, introduzco 4 o 5 preguntas que si o si deba conocer. No puedo contratar a un analista que no sepa definir en una línea el objetivo del testeo de software.

Otro tema tónica lo llamaré "Un libro de una idea"

Esto lo he escuchado y visto con mis propios ojos y en más de una oportunidad focalizado en temas de SQA, QC y Testing. Se trata de gente que tiene una idea y escribe todo un libro de ella.

Alguien durante el curso lo expresó muy bien: “Hoy en día, cualquiera que tiene una idea escribe un libro. Con un post en un blog valdría”. Y creo que tiene toda la razón. Particularmente en SQA, si eres adicto a la bibliografía es muy difícil que no tengas uno de estos libros que describen algo que se podría perfectamente resumir en una página o en un blog.

La verdad es que no entiendo muy bien los motivos de este fenómeno, si realmente esa gente gana dinero ni tampoco el por que se acentúa más en SQA. Invito a los lectores de mi blog a contestar estas incógnitas.

Lo que si sé, es que escribir un libro no es una tarea corta, ni mucho menos económica, además hay que lograr convencer a una editorial que lo publique, no obstante esta gente que escribe libros de una sola idea lo logran y han encontrado una veta en SQA para hacerlo.

Otro tema tónica es la Virtualización de entornos de prueba.

De esto puedo y quiero hablar bastante, en la empresa tenemos montado algo que creo que es bastante novedoso al respecto, desde hace ya unos cuantos meses que me veo tentado en escribir en este blog sobre eso, pero hacerlo bien requiere mucho tiempo (hay gente que escribe libros de una idea y yo no soy capaz de escribir un artículo sobre la virtualización).

En mi caso además, necesito tener ciertas autorizaciones para que el artículo pueda publicarse con un nivel de detalle interesante, os prometo hacerlo relativamente pronto.

Otra tónica fue la automatización de pruebas.

Hace unos meses escribí un pequeño resumen en este mismo blog de un tema referente a la automatización. Estoy con ganas de hacer una segunda parte. Las charlas de café y comidas del curso me han dado mucho ánimo y he comenzado a escribir un pequeño boceto que espero que pronto vea la luz, aunque prefiero antes publicar el de virtualización. En ambos casos, invito a los lectores a poner un comentario respecto a cual les resultará más interesante.

Un tema que también surgió fue los métodos de testeo basados en la experiencia.

El año pasado a esta altura estaba en Barcelona tomando un curso de Rapid Software Testing, impartido por Michael Bolton, el mismo duró una semana y fueron casi ocho horas diarias de exposiciones referentes a métodos de pruebas rápidos, dinámicos, basados en la experiencia. En aquel entonces me quedó bastante claro que, estas metodologías no están nada mal para comenzar un departamento de calidad del software en una empresa pequeña o para un proyecto personal de escasas dimensiones. Casualmente durante el curso, se sentó a mi lado uno de los autores de TMap Next, y el comentario en las horas de café fue “no se puede confiar toda la calidad de un producto en la experiencia, intuición o conocimientos de un solo tester”.

Un año después, durante el curso del ISTQB, otra vez surgió el mismo tema. Personalmente creo que esto, al igual que los métodos ágiles de desarrollo, son para lugares dónde sean apropiados. Pequeños equipos, áreas o departamentos nuevos. No me imagino una compañía multinacional basando la calidad de sus productos en el conocimiento de una sola persona.

Quiero dejar en claro que para nada estoy menospreciando el curso de RST, el cual me ha enseñado muchas cosas muy interesantes, ni el papel de Michael Bolton, quien además de ser uno de los mejores oradores que he conocido en mi vida, es un verdadero showman. Recomiendo ampliamente, si tenéis la posibilidad de asistir a algunas de sus presentaciones, que lo hagáis, sin duda os lo vais a pasar muy bien. Un detalle: Lamentáblemente Michael solo habla Inglés, por lo que es requerido dominar el idioma para asistir.

Por supuesto no puedo dejar de hablar de las herramientas.

Las herramientas de SQA son una tónica siempre, en los eventos, seminarios y cursos que he asistido no ha habido una sola vez en que alguien no me pregunte ¿y tu que herramientas usas? O ¿Con cual herramienta cubres tal necesidad?

Hay una buena cantidad de ellas y sorprendentemente en general son buenas. Hay suites completas como el IBM Rational o el Quality Center de HP. Aunque estas son para empresas con un presupuesto millonario dedicado a la calidad del software. Por otra parte existen herramientas individuales y de software libre que, debidamente integradas, pueden proveernos toda la funcionalidad de los monstruos anteriormente mencionados.

Este fue el tema que surgió en el curso, durante la última parte de la capacitación vimos herramientas. Y muchos estábamos de acuerdo que, con un poco de astucia y conocimiento se puede montar con pocos recursos una buena suite de SQA y testing que cubran nuestras necesidades y calcen como un guante en nuestra empresa. Hay muchas herramientas que se integran solas entre si, y hay otras que permiten una increíble flexibilidad a la hora de ajustarse a nuestra necesidad.

Por ejemplo Testlink es una herramienta de control de pruebas muy flexible, que además se integra con distintos administradores de fallos, como ser Bugzilla o Mantis. Este último, que su nombre y logotipo lo obtienen de la ironía “que se come los bugs” es sin dudas, un bugtraquer super flexible, permite al administrador añadir índices, campos, tipos, etc. Y si a alguien no le basta lo que ofrece, está muy bien escrito en PHP utilizando templates, por lo que su modificación a nivel de código fuente es realimente trivial. Bugzilla también ofrece flexibilidad, por ejemplo, existe un módulo que permite integrarlo con Sourceforge. También existe un plugin para tener integrado el controlador de cambios Maven. si bien su código fuente también está disponible, está escrito en Perl, lo que para algunos hace que no sea tan trivial su modificación. Por otra parte se integra naturalmente con su administrador de pruebas Testopia, formando así una suite bastante completa. Existen además de los mal comunmente llamados “bugtrackers” y administradores de pruebas un sinfín de herramientas con otros fines como ser, automatización, pruebas de rendimiento, de estrés, de volumen, en fin, podría continuar escribiendo de herramientas durante días y sería poco. Estoy pensando que también me apuntaré el escribir un post exclusivamente sobre las herramientas con las que tengo experiencia. Espero por lo menos en este breve resumen dejar en claro una idea: “No es necesario invertir una cantidad millonaria en una súper herramienta, aunque disponer de ese recurso puede hacernos la vida más fácil, se puede lograr perfectamente lo mismo con un poco de idea, eligiendo e integrando las herramientas libres (y muchas veces gratuitas) que existen a disposición de todos”.

Se que me dejo cosas en el tintero, iré colocando algunos comentarios a medida que me vaya acordando, por lo pronto, espero que os haya gustado, lamento haberme tomado un tiempo considerable desde mi último post pero no he tenido oportunidad de escribir.

Referencias y sitios nombrados:

istqb.org

testlink.org

bugzilla.org

sf.net

Automatización total de pruebas para el aseguramiento de la calidad.

2009-08-23T15:41:00.000-07:00

En esta oportunidad voy a compartir con el lector algunas de mis definiciones de “Automatización total”.

En el año 2003, no recuerdo exactamente cuando, pero si algunos sucesos que relaciono con ese año, algunos entendidos de SQA, QC y Software Testing comenzaban a hablar de la virtualización de entornos y automatización de pruebas.

Hablaban sobre estos dos aspectos como “claves” para el futuro, incluso en algún momento llegué a escuchar que, la empresa que no invirtiera en el impulsar estos métodos se vería privada de ciertos niveles de calidad.

En aquel entonces, no comprendía estos mensajes, pensaba que se relacionaban a la automatizar pruebas unitarias o pruebas informales del desarrollador. Tampoco conocía de virtualización más allá de lo que a un microprocesador o equipo se refiere. Y por más que hoy en día resulta obvio, en aquellos momentos no aposté por ninguno de los dos.

Tan solo cuatro años más tarde, me encontraba desarrollando entornos virtualizados y pruebas automatizadas. En el año 2007 ya existían potentes herramientas libres para la automatización y virtualización de pruebas que, las grandes empresas de software llevaban bastante tiempo usando. Era común escuchar que tal o cual empresa poseía n pruebas automatizadas que se ejecutaban en su software antes de hacerlo público.

Solo en aquel momento pude comprender de que hablaban aquellos expertos, la virtualización y automatización fueron un futuro que no se hizo esperar. Para más, el software que yo usaba en el año 2007 se comenzó a distribuir en el año 2005, confirmando de esta manera la poca visión que tuve aquel entonces.

Hoy la evolución natural de estos métodos son la integración continua y automatización total, a diferencia del pasado, en esta ocasión me encuentro definiendo métodos de la automatización total de pruebas. Aprovecho este espacio para compartir con vosotros algunas de estas definiciones.

Automatización total de pruebas
La automatización total, a diferencia de lo que su nombre indica, no es la automatización de todos los casos de prueba. Se refiere a la automatización de todos los casos cuyo coste de automatización se encuentre por debajo del coste de seis meses de ejecución manual. Esta regla se ajusta muy bien a diferentes entornos, duración de ciclos y objetos de prueba. Y en la mayoría de los casos es muy fácil de determinar. Por otra parte, asegura estadísticamente la amortización del trabajo de automatización.

Ampliación de escenarios soportado en automatización
Existen situaciones dónde una clase de equivalencia no nos ofrece condiciones de carrera del mundo real. Por otra parte, la ejecución de estos casos se vuelve excesivamente cara e impracticable.
Esto normalmente se tiene en cuenta durante la etapa de diseño y se apunta como riesgos de instalación, excepciones en las fronteras del test, o ejecuciones no realizadas. La potencia que ofrece la automatización de pruebas, permite crear estos escenarios que, supondrían una tarea colosal. Es requerido tener esto en cuenta a la hora de crear o revisar el caso para la automatización.

Revisión de casos de prueba desde el punto de vista de la automatización
Para lograr una correcta automatización total es imprescindible revisar cada caso desde el punto de vista de la automatización. Lo que voy a describir a continuación, no aplica para aquellos casos dónde la herramienta integra diseño de casos y automatización, o bien se diseñan directamente para ejecución automática: Una vez que el caso de prueba se encuentra diseñado y listo para automatizar, es necesario revisarlo desde el punto de vista de la automatización, esta revisión tratará de buscar variaciones que, sin variar la cobertura funcional, permitan realizar una automatización más natural o simplificada. Este proceso incrementa significativamente la automatización total, no obstante es importante tener en cuenta que, si se realizan variaciones involuntarias que impacten en la cobertura del caso de prueba, se crearán agujeros que degradaran la calidad del plan de pruebas. La ampliación de escenarios de pruebas basados en la automatización no se considera una variación en el caso, por el contrario es una versión diferente del mismo.

Escoger la correcta herramienta de automatización
Aunque parezca trivial y obvio, es sin dudas el punto más importante de la automatización total, siendo esta la piedra angular del método. Es imposible acometer una automatización total sin contar con una herramienta que permita automatizar de manera rentable cada caso. El coste de automatización se relaciona íntimamente con la calidad de la herramienta y la cantidad de casos “automatizables” dependen directamente del costo de la automatización. Es probable que la herramienta que haga posible la automatización total no se encuentre en el mercado, modificar una existente o incluso crear una desde cero es completamente válido, de cualquier forma es fundamental realizar el correcto análisis antes de comenzar la automatización total.

Juegos de datos como estructuras
En varias metodologías de aseguramiento de la calidad del software, el caso de prueba se representa con una estructura rígida que ofrece las precondiciones, acciones y resultados y los datos como una estructura flexible e indexada. En la automatización total esto debe respetarse. Es fácil ver el caso de prueba como un todo y caer en la creación de casos con datos escritos en piedra. Los datos indexados, también conocidos como “escenarios de prueba” permiten al servidor de integración continua realizar una ejecución más precisa. Demás está decir que el respetar esta regla aporta una cuota de reusabilidad y mantenibilidad a cada caso de prueba automatizado.

Perfiles necesarios para acometer la automatización total
El perfil requerido para acometer la automatización total es sin dudas un perfil de analista de calidad del software con capacidades para manejar la herramienta de automatización. Afortunadamente, hoy en día, en la mayoría de los países, es fácil encontrar estos perfiles, incluso con experiencia en alguna herramienta de automatización de pruebas.

Integración continua
Habitualmente, se considera la integración continua una metodología que sirve únicamente al desarrollo ágil, esto se debe a sus orígenes pero no lo considero del todo cierto. Se puede implementar automatización total + integración continua sin importar el peso de los métodos del proyecto. La automatización total debe apoyarse en la integración continua, de forma que el tener un servidor de compilación que preste este servicio, brinde la posibilidad de encontrar los fallos cuanto antes.

Como siempre os digo, quedo a la espera de vuestros comentarios, estaré encantado de responder dudas o cualquier otro comentario que queráis escribir.

A continuación algunos sitios que recomiendo visitar:
http://www.opensourcetesting.org
http://ant.apache.org/index.html
http://continuum.apache.org/
https://hudson.dev.java.net/

Revisión por pares como etapa del desarrollo del software.

2009-08-05T11:16:00.000-07:00

Este artículo trata de difundir un caso de éxito donde la implementación de este método de bajo coste ha dado resultados positivos.

Siempre me ha gustado pensar que no está todo inventado y he sido reacio a aceptar el funcionamiento de las tecnologías sin más, esta mezcla de “incredibilidad” e inquietud fue motor de muchos proyectos personales que he sabido mantener paralelamente a mi ocupación primaria.

Muchos de de estos proyectos no han llegado lejos y otros se encuentran inconclusos, pero en esta ocasión hablaré de uno que, desde mi punto de vista, ha llegado a buen puerto gracias a los métodos y las buenas prácticas.

Me agrada la difusión e intercambio de experiencias profesionales, por lo que agradeceré mucho las notas que el lector se atreva a dejar. De la misma manera estaré dispuesto a responder aquellas dudas que pudiera crear con la falta de detalle.

El proyecto

Estaba compuesto por un puñado de desarrolladores de software, algunos expertos y otros con poca experiencia. Un objetivo importante que teníamos en mente : Mantener las buenas prácticas de codificación y la documentación actualizada.

Los métodos eran más de bazar que de catedral[1], la mejora era constante de cara al incremento de la productividad y el dinamismo aseguraba en todos una gran aceptación al cambio. Teníamos nuestras particularidades, una de las que más me gustaba era que tratábamos de usar siglas siempre que sea práctico y todas nuestras siglas se escribían igual en inglés que en castellano.

Al principio no había muchos procedimientos por lo que los íbamos incorporando a medida que veíamos las necesidades. Tampoco había fechas apretadas que cumplir, por lo que tratábamos de llevar adelante la empresa dando a las cosas el tiempo que considerábamos necesario para que maduren. Utilizábamos el plan del proyecto como una herramienta de medición de desviación en las estimaciones y también como un buen medidor del optimismo de los desarrolladores.

Durante este período cometimos algunos errores, uno de los más desafortunados fue el desarrollar herramientas que no tenían que ver con el núcleo del proyecto y que podían haberse obviado utilizando otras existentes no hechas por nosotros. Esto generó una gran demora en algunas entregas y distrajo nuestra atención del objetivo principal.

Todo iba relativamente bien hasta adentrarnos en una etapa más avanzada dónde llegaron los sprints[2], incluso algunos duraron un par de semanas, básicamente se generaban por cumplir hitos de interacción con factores externos como ser hardware rentado o servicios prestados por terceros y por el bajísimo presupuesto disponible.

El café, las pizzas a domicilio, las caras ojerosas y las mentes agotadas vinieron de la mano de la desorganización: Mal que hasta entonces no conocíamos en la empresa y no sabíamos como tratar.

Los intentos de poner orden generaban nuevos cambios en los procedimientos que se ramificaban en distintas implicaciones, algunas positivas, otras negativas y algunas tan desastrosas que podría escribir un artículo sobre cada una de ellas (y posiblemente lo haga). Por lo pronto hoy me centraré en una decisión que fue sin duda exitosa:

La incorporación del peer review[3] como etapa del desarrollo de software.

El método

Por definición la revisión por pares como etapa del desarrollo del software consiste la revisión de un trabajo por profesionales del mismo rango que el autor. Hasta ahí bien, solo que había que definir al menos en que sectores del desarrollo se implementaría este control, lo que había que revisar y como dividir las distintas etapas, quienes iban a ser los revisores, etc.

El procedimiento

La idea primero tuvo que madurar en nuestras mentes, conversábamos sobre la revisión en el café o al final del día durante varios días. Finalmente una tarde decidimos comenzar a escribir el procedimiento para la implementación del método.

Del original a la última versión del procedimiento se realizaron muchos cambios, comentaré algunos de ellos en pro de dejar claro algunas decisiones que, si bien al principio resultaban una buena idea, finalmente hubo que cambiar.

La primer pregunta que nos hicimos fue ¿Que debemos revisar?

Para conocer lo que debía ser revisado definimos algo llamado LPR (del español “Lista de Puntos de Revisión” o del inglés “List of Peer Review”), un LPR se creaba con la asignación de la tarea al desarrollador y contenía un detalle de los puntos que, el revisor debía constatar y el desarrollador debía estar preparado para mostrar ya sea en el código o en la ejecución del programa. Los LPRs estaban numerados y versionados asimismo sus resultados deberían formar parte de la documentación del proyecto.

¿dónde colocar este control? Fue lo siguiente escrito en el procedimiento.

El sector de control de la calidad fue el primer objetivo de todas las miradas, en el proyecto hacíamos pruebas de caja blanca y ese parecía ser el dónde para el nuevo procedimiento. Unos segundos después de soltar la idea, alguien replicó justamente que, si bien los desarrolladores y testers podrían ser iguales en rango, sus perfiles son muy diferentes y definitivamente no podrían ser pares. Ninguno de los dos podía hacer el trabajo del otro por lo que tampoco podría realizar la revisión desde el punto de vista de un par. Fue entonces que decidimos que el control se hiciera dónde se escribía el código: en el sector de desarrollo.

¿Quien debía hacer de revisor?

Recuerdo que en la versión 1.0 del procedimiento había escrito que a cada desarrollador le corresponderá un revisor asignado, y me había apuntado la tarea de añadir a nuestro tablón de anuncios una tabla con los nombres de los revisores para cada desarrollador, no obstante, cuando se hicieron las primeras revisiones, nos encontramos con un efecto colateral positivo que, en ciertas revisiones, la tabla de asignación directa eclipsaría.
Al parecer la implementación del método de revisión de pares comenzaba a ser positivo antes de ejecutarse, simplemente por una condición humana de los desarrolladores, el saber que su trabajo iba a ser revisado por alguien más del equipo, generaba cierta atención extra al detalle y esto no funcionaba en todas las combinaciones revisor/autor.
Durante versiones intermedias del documento del procedimiento, llevamos a cabo varias formas de combinar los revisores con los trabajos, dos círculos concéntricos fue una de ellas, pero lamentablemente el equipo del mismo circulo no interactuaba; aleatorio sin reposición fue otra idea descartada ya que el desarrollador sabía al menos que su trabajo no volvería a ser revisado por la misma persona hasta que pase el resto del equipo; completamente aleatorio parecía la definitiva, pero luego de un tiempo notábamos que ciertas combinaciones funcionaban mejor que otras, entonces se definió más o menos así:
En el comienzo de cada segmento de desarrollo a revisar, el líder del proyecto informará los nombres de los pares y el LPR (Lista de puntos de revisión).
De esta manera, internamente manejábamos de manera aleatoria la asignación de pares con ciertas excepciones dónde realizaba ajustes según cierto criterio.

¿Cuanto? Tal vez una de las preguntas más importantes por el bajo coste del proyecto.

En un principio definimos que una revisión nunca debía tomar más de 15 minutos y debería participar solo el autor y el revisor asignado. Esa fue una de las pocas cosas que, aun luego de muchas revisiones, quedaron intactas hasta el final del proyecto.

¿Cuando? Era otra pregunta que había que responder.

Definimos algo que llamamos SCR que eran las siglas de “Segmento de Código a Revisar” o bien “Segment of Code to be Reviewed” en inglés. En un principio, un SCR comenzaba en un commit[4] al repositorio estable y terminaba en otro. Sin dudas esto fue lo primero que se cambió en el procedimiento, algunos trabajos eran demasiado cortos para ser revisados, si un desarrollador olvidaba algo trivial, por procedimiento había que asignar un revisor y realizar la revisión del SCR del nuevo commit, esto era muy costoso y una clara pérdida de tiempo. Por otro lado, había casos dónde los 15 minutos no eran suficientes para revisar un cambio colosal, que, como tal, estaba acompañada por una lista de revisión colosal.
Al principio hicimos algunas excepciones para poder comprobar el funcionamiento del resto del procedimiento y finalmente lo ajustamos diciendo que: Cuando comenzara un SCR (Segmento de Código a Revisar) el desarrollador recibiría el LPR (Lista de puntos de revisión), si en algún punto del trabajo consideraba que en 15 minutos no iba a poder ser revisado, debía solicitar una revisión inmediata, dónde el líder confeccionaría una nueva LPR en función del trabajo hecho y se ejecutaba la revisión entre colegas cerrando así ese SCR. Por el contrario, si el revisor encontraba el cambio a realizar demasiado minúsculo para una revisión, esta se realizaba con otros cambios, creando así un SCR que podía englobar más de un desarrollo.

¿Cómo? Fue sin dudas la pregunta del millón.

El cómo englobaba varios puntos: ¿Cómo poner en marcha el procedimiento? ¿Cómo definir un LPR? ¿Cómo evaluar las revisiones? Etc...

Con el líder de desarrollo escribimos las listas de puntos de revisión para los desarrollos que se encontraban pendientes de realizar. Había puntos que tenían que ver con las buenas prácticas de programación: Uso de nomenclatura, código documentado, cabeceras de ficheros apropiadas, estos puntos de control se agregaron debido a las jornadas largas e intensas, durante estos tiempos se perdían un poco en pro de llegar al hito, lamentablemente luego de correr no era fácil volver a caminar y ya no se reescribía o corregía el código escrito maratonicamente.
Otros puntos estaban más apuntados a verificar que el desarrollador no olvidara nada. Hay un ejercicio muy bueno que consta en contar a alguien un problema aunque esta persona no sea capás de conocer la solución, el solo hecho de contarlo, de pronunciar detalladamente el problema ayuda al análisis y solución del mismo. Estos puntos obligaban al desarrollador a contar como solucionó ciertas partes del desarrollo. Finalmente algún punto de integración dónde se pedía ver una salida final de ejecución del programa antes de enviarlo al departamento de calidad.

Con el procedimiento y los primeros LPRs escritos enviamos un mail al equipo de desarrollo con el hiperenlace a la documentación y tuvimos una corta reunión dónde se comentaron algunos aspectos a fines de evitar malos entendidos por el tema de que alguien iba a revisar el trabajo.

Fue así que comenzó el primer desarrollo posterior a la reunión de kickoff y se le entregaró al desarrollador y al revisor asignado el LPR, al término del SCR se realizó la revisión dentro de los tiempos esperados y los resultados indicaban que el desarrollador debía corregir algunos detalles antes de enviar el código al departamento de calidad. Nos sentíamos bastante satisfechos con el resultado incluso antes de saber que con las revisiones el procedimiento se iría ajustando y sus resultados serían mejores.

Conclusión

El costo de la creación del procedimiento y del uso del método ha sido relativamente bajo respecto a sus beneficios, el tiempo de implementación fue realmente corto y no fue invasivo siendo este uno de los aspectos que más nos decidió por adoptarlo en una etapa avanzada del proyecto.

Personalmente me agrada mucho, he quedado con un buen sabor de boca y lo recomiendo seguido, al punto que hoy llevo tres horas escribiendo para difundirlo.

--- Notas al pie.
[1] Eric S. Raymond en su libro “The Cathedral and the Bazaar” dice que el desarrollo del software libre “No se trataba de ninguna forma reverente de construir la catedral. Al contrario, la comunidad se asemejaba más a un bullicioso bazar de Babel”. Llamando de alguna manera “programación Bazar” a ciertas prácticas y métodos ágiles.
[2] Esfuerzo de aceleración en el proyecto dónde se requirió un alto incremento de las jornadas laborales.
[3] Revisión por pares (en inglés, ya que es el nombre original del método).
[4] (acción de cometer) se refiere a la idea de hacer que un conjunto de cambios en el código "tentativos, o no permanentes" se conviertan en permanentes.

Sistema operativo GNU ¿Por qué no?

2009-07-19T12:12:00.001-07:00

Según mi propia definición, un sistema operativo es: Un conjunto de programas que administran de manera transparente un equipo, proveyendo al usuario una interfaz para el uso de sus aplicaciones. El sistema operativo realiza correctamente su trabajo cuando el usuario con o sin conocimientos en informática está conforme con la manera en que responde su sistema.
Este artículo no es una comparativa más entre el sistema operativo GNU y otros sistemas operativos.

Hace unos días conversando con un amigo y compañero de trabajo, quien es un usuario de GNU-Linux y un experto desarrollador profesional, me decidí a escribir este artículo que, sin dudas, con vuestros comentarios resultará esclarecedor (al menos para mi). La anécdota, lejos de ser un caso aislado fue una más, aunque probablemente la que más me ha llamado la atención.

Trataré de no hacerlo muy extenso, ya que creo firmemente que los comentarios en el mismo serán más ricos que el artículo en si, además, no tengo mucho que decir, solo contar lo sucedido, mis conclusiones y esperar que los lectores se animen a dar su punto de vista.

Los hechos:

Un conocido nos solicitó, a mi amigo y a mi, que le echáramos una mano con su ordenador que no funcionaba correctamente, iba muy lento, se “colgaba”, etc.

El primer consejo que me salió dar fue instalar un sistema operativo muy fácil de usar, con una interfaz intuitiva y personalizable, muy seguro, no susceptible a virus ni a la mayoría de las amenazas, rápido, de hecho el más rápido de todos, robusto, que no se estropee al apagarlo mal tres veces, estable, que no presente periódicamente una pantalla azul perdiendo todo el trabajo, el de mayor soporte, que cuente con la comunidad más grande de usuarios dispuestos a ayudar, el más compatible, que permita ejecutar miles de aplicaciones incluyendo las de otros sistemas operativos,
libre, que no se inflija la ley al usarlo como uno quiera, al compartirlo, al modificarlo o al distribuir versiones modificadas del mismo. Como ya os habéis imaginado le recomendé que utilice el sistema operativo GNU con el núcleo Linux, más precisamente, la distribución Ubuntu en su edición para equipos de escritorio.

Para mi sorpresa, mi amigo desaprobó instalarle este sistema operativo ya que su máquina era vieja y, según él dijo cuando tuviera algún problema solo yo podría ayudarle.

Lo que me impactó fue ver a un usuario del sistema operativo GNU desaconsejar su uso basándose en dos de sus fortalezas respecto al sistema operativo que proponía. El sistema operativo GNU tiene muchas distribuciones de “bajo peso” pensadas para equipos viejos dónde funciona muy bien y el soporte es mucho más amplio que el del resto de sistemas operativos.

Mis conclusiones:

No voy a hacer de este artículo una comparativa más entre el sistema operativo GNU y otros sistemas operativos, tampoco pienso aconsejar o desaconsejar el uso de ninguno ya que, ni las empresas que hacen posible GNU*, ni Microsoft, ni Macintosh me pagan por escribir. El único fin de este artículo es ayudarme a comprender los motivos de una preferencia por otro sistema operativo que no sea el de GNU muchas veces basada en mitos o cosas que alguna vez fueron pero que ya hace tiempo se encuentran muy bien resueltas.

Cuando dije que anécdota no fue única, me refería a que he encontrado mucha gente oponiéndose a usar el sistema operativo GNU por motivos tan contradictorios como los que dio mi amigo.

Yo particularmente uso GNU tanto en la oficina como en casa y cubre todas mis necesidades. Puedo entender que si el objetivo principal de tu ordenador es jugar, eres un gamer (videojugador en su significado en inglés) exquisito que tiene lo último y no tienes ganas de investigar dado que aún muchos juegos no salen para GNU y la compatibilidad con ellos algunas veces es limitada, te decidas por tener ambos, el sistema operativo para juegos y el de GNU para todo lo demás.
Por el contrario, para una persona que sabe poco y nada de ordenadores, lo mejor es utilizar GNU que por fortuna, últimamente lo están preinstalando en muchos equipos.
Desde mi punto de vista, son muy pocos los casos que ameriten tener otro sistema operativo y son muchas las ventajas que ofrece GNU, no obstante, las estadísticas muestran que se usa mucho más otro sistema operativo y de ahí mi pregunta: GNU ¿Por qué no?

No dejes de publicar tu comentario. ¡¡¡Muchas gracias!!!

*La lista de empresas que apoyan y hacen que el sistema operativo GNU sea posible es muy extensa, por nombrar algunas, a continuación pongo en orden alfabético las que ahora recuerdo:
Canonical, Free Software Fundation, Google, HP, IBM, Macromedia, Sun Microsystems, The Linux Fundation, y cientos de empresas más.
Obviamente todas estas marcas se encuentran registradas y son propiedad de sus respectivos propietarios.

Referencias:
http://www.gnu.org/home.es.html

Los niños e Internet

2009-07-15T02:18:00.000-07:00

Internet sigue siendo un lugar donde no debería haber niños o adolescentes sin supervisión de un adulto. Lamentablemente mucha gente no toma conciencia del peligro que significa dejar a un niño solo frente a un ordenador conectado a la red. Ninguna herramienta por más eficaz que sea ofrece el 100% de la protección.

En 1969 se creó la primera red de ordenadores llamada ARPANET. Conectaba cuatro universidades en los Estados Unidos de América y fue el origen de Internet. Podría decirse que durante los primeros 20 años la red fue de uso exclusivo de estudiantes y profesionales especializados, su uso se limitaba a la investigación y distribución de información y no era fácil encontrar, fuera de una universidad o una gran empresa con tecnología de punta, un ordenador con la capacidad de conectarse.

Comparo Internet de antes de los 90's con las calles de un gran polígono tecnológico, donde se podía conocer gente con respuestas a preguntas técnicas, nuevas y diferentes ideas o cooperar en investigaciones a distancia. Sin lugar para el ocio, niños o ambiente familiar.

Hoy en día es común encontrar un ordenador con conexión de banda ancha en cualquier casa de familia. Los diferentes servicios que Internet ofrece han atraído a gente de todas las edades y clases sociales a tener un ordenador en casa. En este momento hay al rededor de 1600 millones de personas en la red.

Sin lugar a dudas, esas calles de color ámbar o verde se han convertido en coloridas súper-autovías donde vídeo conferencias, música, noticias de último momento, llamadas telefónicas y cientos de otros servicios se propagan a altas velocidades hacia ordenadores, móviles, portátiles, netbooks, tablet Pcs, consolas de videojuegos, en pocas palabras, un sin fin de dispositivos al alcance de las personas comunes.

Esta transformación ha sido tanto tecnológica como social, se ha requerido nuevas tecnologías y leyes para que este gran cambio se produzca, pero hay cosas que aún no cambian: “Internet sigue siendo un lugar donde no debería haber niños o adolescentes sin supervisión de un adulto”.

Muchos creen que el ordenador para un niño representa una consola de videojuegos con la posibilidad añadida de usarlo con fines educativos. Esto deja de ser cierto si tenemos en cuenta que, una conexión a Internet es una ventana a un mundo que permite ver y ser visto y muchas veces sus contenidos no se encuentran adaptados a su público.

Nadie en su sano juicio dejaría que su hijo de 6 años haga zapping en un televisor con canales de contenido violeto y para adultos entreverados con canales infantiles. O que una niña de 8 años hable con completos desconocidos aunque sea por teléfono. “Lamentablemente mucha gente no toma conciencia del peligro que significa dejar a un niño solo frente a un ordenador conectado a Internet”.

Existe un mundo de peligros en la red que amenaza a todos sus públicos: Virus que atacan los ordenadores y roban los datos privados. Hoaxes y Phishing que engañan a personas adultas obteniendo acceso a las cuentas bancarias o dinero mediante una transferencia desde la víctima. Spam que en el mejor de los casos ofrece medicinas sin receta, drogas ilegales o servicios fraudulentos. Banners que bombardean con publicidad, muchas veces ofensiva, entre otras con imágenes de sexo explícito, los sitios web a los que accedemos como resultado de nuestra búsqueda por algún contenido de interés. Pedófilos que utilizan la red para llegar a niños y distribuir pornografía infantil. La lista es interminable y se renueva constantemente, cada vez que se desarrolla un mecanismo para contrarrestar estos males, variantes son creadas para engañar a estos mecanismos.

Hoy en día contamos con varias herramientas, gratuitas y de bajo coste que, con el adecuado mantenimiento y atención, ofrecen una seguridad relativamente buena en lo que se refiere a la mayoría de los ataques, pero de algo podemos estar seguros: “Ninguna herramienta por más eficaz que sea ofrece el 100% de la protección”. El resto es nuestra responsabilidad.

Desde el desarrollo de la lectoescritura cualquier niño se va a sentir atraído por el abanico de opciones que ofrece Internet. Desde navegar por el portal de su programa favorito de televisión hasta chatear con sus amigos del colegio. Así como es responsabilidad implícita de sus tutores el regular el tiempo que permanece frente al televisor y los programas que ve, debe existir una responsabilidad igual o mayor respecto al uso de la red.

Desde mi punto de vista esta responsabilidad debe ser:

Muy estricta en edades tempranas, para lo que se puede utilizar algún software de control parental por listas blancas (programa que impide la navegación por la red excepto en aquellos sitios que fueron habilitados por el administrador). Este software solo hace parte del trabajo ya que el tutor debe habilitar los sitios en los que pueda navegar el niño y estar con él a la hora de buscar nuevas páginas para expandir la lista. Durante esta etapa el uso de mensajería instantánea y correo electrónico debe ser supervisado directamente por un adulto que lea los mensajes en ambas direcciones, es decir que solo se permita cuando el adulto esté presente. Las páginas donde otros usuarios pueden añadir contenidos (foros, o publicación de mensajes, etc) deben estar bloqueadas y solo ser visitadas cuando el tutor esté con el niño.
Menos estricta al acercarse a la adolescencia. A medida que el niño crece estas restricciones deben ser retiradas paulatinamente mientras se acompaña con la educación adecuada. Existen también herramientas que nos pueden ayudar en esta etapa donde el sistema de listas blancas va quedando chico. Se requiere algún analizador de contenidos inteligente que evite los sitios inadecuados para el menor sin ser tan restrictivo. El bloqueo y control de mensajería poco a poco debe ser reemplazado por educación y normas para su uso.
Pasada la adolescencia también es necesario contar con programas que nos ayuden a navegar de forma segura. En este caso no con el fin de impedir el acceso a un sitio que queremos visitar sino apartándonos de contenidos indeseables. Algunas herramientas están al alcance de la mano, los buscadores de páginas web más serios, por ejemplo, traen una opción para hacer “búsquedas seguras” o libres de pornografía. Como es una opción que el usuario puede manipular solo sirve si la persona está realizando un uso responsable y adulto de la red.

En definitiva, la mejor de las herramientas para que los niños hagan buen uso de Internet es una buena educación acompañada del control respectivo en cada etapa. Podemos valernos de software que nos hará el trabajo más llevadero, permitiéndonos dar cierta “libertad” al niño y no estando sobre él cada vez que se conecte a la red, pero nunca debemos pensar que un programa puede hacer el trabajo de un padre.

Autor: Diego Lucio D'Onofrio

Fuentes:
http://es.wikipedia.org/wiki/Internet
http://www.internetworldstats.com/stats.htm
http://es.wikipedia.org/wiki/Bulo
http://www.anti-phishing.org
http://www.protegeles.com