Tropezando en software mal terminado

Alguna vez, James Bach decía que hoy no tenía sentido el testeo del software, porque no existía uno que se entregara con una revisión cuidada. Mejor en sus palabras, allá por marzo de 2009:

My impression is that up to about ten years ago most companies were still trying, in good faith, to put out a good product. But now many of them, especially the biggest ones, have completely given up. One sign of this is the outsourcing trend. Offshore companies, almost universally, are unwilling and unable to provide solid evidence of their expertise. But that doesn’t matter, because the managers offering them the work care for nothing but the hourly rate of the testers. The ability of the testers to test means nothing. In fact, bright inquisitive testers seem to be frowned upon as troublemakers.

(...) This is my Quality is Dead hypothesis: a pleasing level of quality for end users has become too hard to achieve while demand for it has simultaneously evaporated and penalties for not achieving it are weak. The entropy caused by mindboggling change and innovation in computing has reached a point where it is extremely expensive to use traditional development and testing methods to create reasonably good products and get a reasonable return on investment. Meanwhile, user expectations of quality have been beaten out of them. When I say quality is dead, I don’t mean that it’s dying, or that it’s under threat. What I mean is that we have collectively– and rationally– ceased to expect that software normally works well, even under normal conditions. Furthermore, there is very little any one user can do about it.

Esta incómoda afirmación de un especialista, se puede comprobar a diario, a cualquier nivel. Un incidente esta semana pasada me lo hizo recordar: migraba en Eclipse la versión de una librería que uso, a su último fix (esto sólo ya daría para hablar largo sobre políticas de entrega de producto). Ésto, mientras a la vez migraba de sistema operativo y máquina: demasiados frentes abiertos; Windows 7 a su último nivel crítico de actualizaciones, Visual Studio y Java instalados por primera vez en la máquina; en este último caso, a las instalaciones de JRE de Java 6 y Java 7, agregamos la instalación del JDK de JEE 6, tomando la última versión ofrecida por Oracle en su sitio de descargas para JEE 6: la que se instala con Java SE modificación 29.
Haciendo las primeras pruebas de funcionamiento de Eclipse con el proyecto en que trabajaba, encontré que la primera aplicación que probaba fallaba a poco de iniciarse. Después de algo de búsqueda, el problema quedó localizado en la primera llamada a Microsoft SQL Server, con la particularidad de que la llamada al driver sqljdbc4.jar recibía el control, y comenzaba la descarga de clases necesarias, hasta detenerse en una llamada en particular, sin provocar una excepción: simplemente la aplicación se colgaba sin aviso de ningún tipo, ni siquiera en el visor de eventos de Windows. La primera acción fue comparar la carga de clases en las dos máquinas involucaradas (la que estaba migrando, y la de destino, nueva), y tratar de asegurar que no se estuviera solicitando una clase que faltara en el jar cargado. Una búsqueda en todas las carpetas encontró no menos de seis copias del jar, pero ninguno de ellos podría haber entrado en conflicto, y la copia que debiera llamarse estaba en la ruta esperada. A pesar de que hubo que hacer algo de limpieza del número de copias y de sus rutas, este no era el problema. Por lo tanto, decidí comenzar una búsqueda de incidencias entre Java,  JEE, servlets, Microsoft SQL Server jdbc, y/o SQL en general. A poco de revisar, apareció una consulta en StackOverflow, que vinculaba la incidencia a la modificación 29 de Java SE. Siguiendo su discusión, llegué al caso en Oracle: JDK-7103725 : REGRESSION - 6u29 breaks ssl connectivity using TLS_DH_anon_WITH_AES_128_CBC_SHA. En la evaluación del impacto del fallo, se afirma: "The more obvious impact of this bug is to the MS JDBC Driver and MS SQL Server".
Tanto los comentarios en StackOverflow como la propia descripción del problema corregido coincidían en sus efectos con el que nos afectaba. De modo que, siguiendo las líneas recomendadas allí,  descargamos una versión posterior de Java SE,  la última disponible para Java 6, la modificación 45. Reemplazada la versión, no hubo más que arrancar Eclipse y la aplicación para encontrar todo trabajando normalmente...
Ahora, atemos nuestro percance con lo que James Bach dice más arriba: cuando instalábamos esta máquina, buscamos el paquete de JEE 6 en su sitio oficial, donde JEE 6 con el sdk de Java SE m29 es una de las opciones disponibles. Si bien la elección entre varias opciones fue nuestra, no existía ninguna advertencia de dificultades con JDBC (!) o SQL Server ni su documentación advierte que existe un problema, y que para resolverlo...se debe cambiar de versión. ¿Qué clase de entrega de un producto es una que no dice que fallará bajo ciertas circunstancias, para más, bastante comunes, cuando eso ya fue detectado? ¿Qué protocolo de comunicación existe entre quienes desarrollan el producto (JEE) y quienes lo mantienen (Java Community)?
Este es sólo un minúsculo ejemplo; sólo en el proceso de resolver este inconveniente podría hablar de varias imperfecciones de todo tipo, tan simples como insólitos resultados de la búsqueda de un objeto en el sistema de archivos (fallo en Windows 7), o la imposibilidad de usar las herramientas de desarrollador en Internet Explorer. O encontrar que un fix produce otro fallo que requiere otro fix al día siguiente...y otro más un día después.
En una época en que los métodos ágiles predominan, conjeturo que algo de responsabilidad les corresponde: reducir los tiempos de entrega, simplificar las metas de cada release, creo que también conducen a este estado de permanente falta de terminación.

Brian W. Kernighan y Rob Pike sobre depuración

Leído en Apache, a de propósito Log4j,   en la introducción:
[Tomado de Brian W. Kernighan y Rob Pike de su libro "The Practice of Programming"]

As personal choice, we tend not to use debuggers beyond getting a stack trace or the value of a variable or two. One reason is that it is easy to get lost in details of complicated data structures and control flow; we find stepping through a program less productive than thinking harder and adding output statements and self-checking code at critical places. Clicking over statements takes longer than scanning the output of judiciously-placed displays. It takes less time to decide where to put print statements than to single-step to the critical section of code, even assuming we know where that is. More important, debugging statements stay with the program; debugging sessions are transient.

Testeando Plex

John Rhodes publicó hace pocos días una presentación sobre un producto promovido por ADC Austin para testear aplicaciones de Plex y 2E (Certify). Más allá de su aspecto comercial, de especial utilidad para quienes utilizan Plex (o 2E), dada la dispersión de soluciones asumidas en este terreno.
Pueden encontrarse otras similares en Slideshare. Una referencia a la empresa creadora de Certify (Worksoft), en su sitio.

Calidad y modelo de negocios

El 4 de marzo, James Bach escribe que "La calidad está muerta" en la creación de software. Pero el desarrollo de su nota apunta más bien a un modelo de negocios, antes que a una posición general sobre el desarrollo de software siguiendo patrones de calidad.
Ciertamente apunta a un problema su indicación de que la cesión del desarrollo y actividade de control a terceros a través del outsourcing disminuye la calidadad del producto. Al menos, es frecuente la crítica de desconexión entre solicitante y encargado de los trabajos, así como la desconfianza en la real capacidad de empresas (abundantes referencias a India), y la devaluación de algunas certificaciones de calidad.
También es cierto que la media probablemente maneja criterios mucho más laxos que los recomendables tanto en la construción como en el control, y no alcanzarían varias páginas para dar ejemplos.
Lo importante de su observación es que, si las empresas que desarrollan software, y aquí habla de aquellas cuyo negocio es esto mismo, si estas empresas son empujadas por el mantenimiento de un retorno elevado de utilidades, entran en un ciclo de renovación de productos que termina degradando la calidad de aquello que entregan. Bach habla reiteradamente de quien probablemente sea el mayor impulsor de este modelo, Microsoft, señalando en las sucesivas entregas de versiones de Windows un grado de inmadurez que ha terminado minando la confianza en sus productos.
Estamos ante una crisis que parece que marcha a ser mayor que la de 1930. ¿Se generalizarán las malas prácticas en pro del abaratamiento del producto final, o se mantendrá un modelo más conservador? Estas son épocas de crudo darwinismo. Quizá el más fuerte no sea el mejor.

Integración contínua (Continuous Integration)

Aplicado a Plex, un artículo en curso de elaboración en la wiki toma uno de los puntos de particular interés no sólo en este caso, sino en general en las distintas variantes de generación de código a partir de modelos o directivas de alto nivel. El artículo parte del papel escrito por Martin Fowler sobre Integración Contínua, y examina lo que Plex cubre, y lo que le falta para lograr el objetivo: un equipo de trabajo desarrollando cada uno su parte, e integrándola a un repositorio común, con un proceso definido de resolución de conflictos, compilación, testeo, implementación (Any individual developer's work is only a few hours away from a shared project state and can be integrated back into that state in minutes. Any integration errors are found rapidly and can be fixed rapidly.This contrast isn't the result of an expensive and complex tool. The essence of it lies in the simple practice of everyone on the team integrating frequently, usually daily, against a controlled source code repository).
Las observaciones del autor del artículo (John Bell) apuntan a la necesidad de extender la integración del proceso de construcción de tal forma que sea posible tener control sobre todos los elementos participantes del proceso, y de todos los estados hasta su implementación. Difiero con Bell en cuanto a que es posible tomar más control del proceso partiendo de los recursos que hoy se disponen. Estoy de acuerdo en que este mayor control no está incluído en el producto mismo.
Estos aspectos son los que, en términos generales, hacen interesantes las ideas de Jack Greenfield sobre su Software Factory, más allá de su final concreción. Creo que existen más ideas estimulantes en la descripción genérica de su idea, que en cómo se la ha implementado.
Estaremos esperando el desarrollo ulterior del artículo en la wiki...

Una guía para el testeo de paneles

Limpiando notas antiguas, encuentro mucha información de interés que pasaré aquí para no perder (y a del.icio.us). En Methods & Tools, destaco un artículo sobre testeo de GUI's(1) , (2) y (3)(año 2000), así como el autor, Barry Dorgan, que deja disponibles otros artículos en su página. Dorgan integra el grupo Software.Testing (1) y (2).
Lateralmente, de la información de Software.Testing, dos o tres sitios vinculados a testeo de software para agendar, especialmente TestingFaqs, y Software Configuration Management FAQ de Dave Eaton.

Material sobre Testeo, y más

Finalmente, con un poco de tiempo disponible, hice dos o tres cambios a los enlaces, agregando varios que tenía interés en compartir, aunque quedan otros futuros candidatos, que agregaré basado en la frecuencia de su utilidad. Tres incluídos son sobre Testeo: Testing reflections, Cem Kaner y James Bach. Kaner, especialmente, extiende su interés como analista de testing desde un punto de vista más amplio (a propósito, en algún momento habrá que tomar sus comentarios sobre el SWEBOK 1 y 2). Dos candidatos en el área de testing que seguramente incluiré son Pavankumar Pothuraju y Pradeep Soundararajan, que muestran a India en su estado actual, y su potencia futura.

Scott Sehlhorst sobre UML

Agregaré en los próximos días a dos o tres blogs en la lista del margen derecho, quizá abriendo alguna nueva categoría. Uno de los que debe estar, para ser seguido, es Scott Sehlhorst , si su interés es el diseño o modelado. Desarrolla buenos ejemplos de uso de artefactos de modelado, particularmente sobre casos de uso. Pero también sobre testeo, y sobre mejora de procesos, por puntualizar algunos especialmente.

Cem Kaner: un poco de teoría sobre Testing

Encontré a Cem Kaner a través de otro comentario de James Bach, otro especialista en testing. Su blog aporta una serie de notas consistentes sobre Testeo de Software. Lo agendé en del.icio.us, y en unos días trataré de registrarlo separando los conceptos que desarrolla. Por ahora, sólo para no perder su nombre.