Climens Codelog

El otro día llegué a un interesante post sobre qué preguntarle a nuestro futuro empleador en una entrevista. Después de leerlo me di cuenta de que si en una entrevista llego a preguntar todo eso y encima valoro las respuestas que me dan, no sé sin encontraría trabajo en el inframundo del desarrollo de software (si trabajas en un sitio que cumple, por ejemplo, 8 de los 12 puntos, por favor ¡contrátame!), por lo menos en España.

Lo importante en definitiva es que se basa en The Joel Test: 12 Steps to Better Code (versión en español). Son 12 sencillas preguntas que esconden toda una filosofía de buenas prácticas deseables en cualquier entorno de desarrollo. También googleando he encontrado un excelente artículo sobre estas 12 preguntas aplicadas al desarrollo web. Estas son:

1. ¿Usas control de versiones?
2. ¿Puedes tener listo el producto en un solo paso?
3. ¿Compilas el producto a diario?
4. ¿Tienes una base de datos de errores?
5. ¿Solucionas los errores antes de escribir nuevo código?
6. ¿Tienes una planificación actualizada?
7. ¿Tienes unas especificaciones?
8. ¿Tienen los programadores un entorno de trabajo tranquilo?
9. ¿Tienes las mejores herramientas que puedes comprar?
10. ¿Tienes testers?
11. ¿Escriben código los candidatos durante su entrevista?
12. ¿Haces pruebas de usabilidad de "vestibulo"? (O sea, a cualquiera que pase por allí y esté dispuesto)

Aunque en realidad se podrían hacer muchas más, si se realizan la mayoría de ellas probablemente se esté trabajando de forma decente. Si no, la cosa se puede poner complicada: posiblemente vives diariamente en un infierno incomprensible.

Ahora toca la parte complicada. ¿Qué nota sacamos en mi empleo actual? Vamos a ver

1. Sí, desde hace un tiempo y por supuesto para nuevos desarrollos. Subversion que no es ni el mejor ni el peor pero tiene herramientas chulas como TortoiseSVN y VisualSVN. Además está bastante extendido y se encuentra fácilmente soporte y ayuda.
2. No, de momento. Es algo necesario y está planificado. Supuestamente con MsBuild o Nant lo podemos conseguir.
3. Sí. Para el producto actual usamos TeamCity con cierto éxito, gratuita para pequeños grupos. Eso sí, faltan aun los scripts completos del paso 2.
4. Sí, usamos Redmine y una herramienta interna (bastante inservible, la verdad), aunque no se si el Redmine me acaba de gustar del todo. En fin, mientras tengamos todos los errores registrados bueno es.
5. Más o menos. A veces el tiempo apremia, pero se debería hacer. La compilación del paso 3 comprueba los tests unitarios, lo que no significa que encuentre todos los bugs, obviamente.
6. Sí, lo intentamos, aunque a veces vamos dando palos de ciego sin saber muy bien el rumbo.
7. Eso creo. El flujo de generación de especificaciones es bastante malo, por lo que muchas veces no son lo suficientemente rigurosas ni explícitas.
8. Depende de la oficina. En la que yo estoy es excelente.
9. No. Siempre hay pegas para adquirir herramientas pero estamos mejorando.
10. No oficialmente. Se prueban las cosas bastante mal y sin rigor.
11. No, lo que me atañe y voy a ver qué puedo hacer al respecto. De momento me leere la Guerrilla Guide to Interviewing a ver qué saco de interesante.
12. No. Parece que ahora quieren contratar a unos expertos en usabilidad para guiarnos, aun así dudo que se realicen pruebas de este tipo

Así que mi JoelScore(tm) es de unos 6/12. Aprobado raspadillo y por los puntos 1, 3 y 4, lo cual no es por tirarme flores, pero creo que he contribuido bastante a instaurar estas herramientas y procesos. A ver si el año que viene llegamos a 8 o 9/12, lo que estaría bastante bien.

En resumen, aconsejo a todo el mundo que trabaja en este mundillo que lea las preguntas, que lea lo que significan las preguntas y se autoanalice para ver en qué estado está y qué puede hacer por mejorarlo.

Con esta última sesión concluyen las JTS2008, con un balance creo que positivo. Como en todo, hay cosas que mejorar pero hemos seguido viendo cosas interesantes.

De esta jornada destacaría la ponencia de Lee Copeland sobre los cómo saber cuándo terminar de testear. Conseguir testear todo es imposible por lo que hay que sopesar si vale la pena seguir o es mejor dar el producto como suficientemente probado y listo. Cierto es que a veces los deadlines o decisiones de los estamentos superiores son quien deciden cuándo debe publicarse algo, pero aun así, las distintas métricas nos sirven para conocer el estado real del producto.

La ponencia de Peta Heck sobre "Crear y validar requerimientos de usuario", aunque no centrada en el testeo nos recuerda que un buen testeo no se puede realizar si no hay una buena captura de requerimientos, sin ambigüedades ni lagunas, que permita conocer exactamente como debe funcionar un producto y por lo tanto permite realizar un testeo adecuado.

El resto de presentaciones han aportado más pinceladas y ideas sobre cómo implantar el testeo a todos los niveles, haciendo siempre hincapié en unos buenos requerimientos y en la necesidad de la implicación de todos los elementos que participan en el ciclo de desarrollo, no solamente de los equipos de test.

Por la tarde, un par de ejemplos de casos reales de implantación y uso de equipos de testado en Zurich y Metro de Madrid así como otros sobre el uso de algunas herramientas para gestionar el ciclo de desarrollo y testeo: desde la captura de requisitos hasta el testeo de aceptación. Ha quedado patente la importancia de la trazabilidad para conocer qué se implementa, cómo, cuando y quién; para ello, Telelogic presenta DOORS, un software comercial muy completo y también se habla de TestLink (también tienen un blog), un ejemplo de software libre apto para este tipo de tareas. Por supuesto, menos completo que el comercial pero aun así muy válido para PYMEs que no pueden costearse grandes soluciones.

He echado en falta el testeo de seguridad informática, especialmente en entorno web, ya que por ejemplo es el que en realidad ha preocupado más en mi entorno de trabajo dadas las posibles implicaciones que pueden tener los agujeros de seguridad, quizás no tan visibles como un fallo detectado por usuarios finales pero cuyas consecuencias pueden ser desastrosas y comprometer nuestros sistemas. A ver si un día me animo y hago una presentación sobre el tema.

También me gustaría haber visto algún caso de éxito más cercano de empresas locales (o a nivel estatal) de mediano tamaño que hayan visto mejorados sus productos gracias a la introducción de técnicas más o menos formales de especificación y testeo.

En cuanto a lo que me ha sobrado... en general no me gustan las grandes consultoras ni los mercaderes y por norma las soluciones que proponen desde luego no son escalables ni asumibles por la gran cantidad de PYMEs españolas que necesitan un punto de partida para mejorar sus procesos de calidad del software, además de que suelen hablar de conceptos vagos sin aportar realmente valor a la audiencia. Pero supongo que tiene que haber de todo.

Nos vemos el año que viene.

Link | JTS2008: segunda jornada, 4 abril, mañana

Hoy han empezado de verdad las Jornadas y en general diría que la calidad de las presentaciones no ha estado mal pero he de reconocer que en algunas no me he enterado ni de lo que pretendían explicar.

La que más me ha gustado, quizás por mi prefil de desarrollador al que Google le parece aun cool, la explicación del "Testeo de software en Google" conducida por Julian Harty de Google UK. Siempre es interesante conocer como trabaja esta gente porque es sorprendente lo distintos que pueden parecer en sus formas y métodos. Pero al final, usan las herramientas que usa todo el mundo: Selenium, WebDriver, scripts en Python y seguro que muchas pequeñas herramientas hechas por ellos para simplificar tareas. Finalmente ha dejado un enlace interesante al Google Testing Blog (interesante la idea de Testing on the Toilet :))

Las dos ponencias de Lee Copeland han estado también interesantes, más que nada porque es una persona con experiencia sobre los escenarios y es ameno de escuchar. La de "Todo lo que hay que saber sobre testeo de software se aprende en el jardín de infancia" ha tenido momentos bastante divertidos, aunque quizás el contenido era un poco más superfluo.

La tarde la verdad es que me ha aburrido un poco. Algunos ponentes han reciclado y recortado presentaciones multiusos que no dicen mucho. Me quedaría con la de Tanja Vos, "Testeo en mi empresa, ¿cómo empiezo?", donde ha presentado un retrato impecable de muchas de las PYMES del sector donde hay auténticos empastres: sin orden, sin documentos, sin tests... Propone un trato: que todo el mundo haga testeo unitario y poner una persona exclusivamente dedicada a probar cosas durante seis meses. En ese tiempo se darán todos cuenta de todo el trabajo que hay por delante y la necesidad de realizarlo para mejorar la calidad del software. Una apuesta arriesgada pero interesante.

También se ha hablado del SSTQB (Comité español de Testing) que certifica Testers a nivel mundial a través del ISQTB (International Testing Board) y el INTECO ha presentado sus estudios sobre el estado del testeo en el tejido empresarial español (algunos aun no están publicados).

Para más información, nada como el blog oficial del SQUAC o seguirles por su Twitter.

Link | JTS2008: primera jornada, 3 de abril, mañana
Link | JTS2008: primera jornada, 3 de abril, tarde