agosto 2013 ~ Tengo una idea

El post anterior sobre este tema hizo bastante ruido. Recibí muchos comentarios/opiniones al respecto y me pareció interesante dar "otra vuelta". En realidad, esta vez es para dividir en un par de tracks los comentarios que recibí y "generar más conocimiento":

1. Testing Agile: hace un tiempo escribí sobre los principios propuestos en este libro, y efectivamente, de alguna manera, la idea expuesta en el post tiene implícitos estos principios.

2. Cualquiera puede hacer Testing: sinceramente, me cuesta creer en esto. He trabajado con gente que no es del palo y han tenido un excelente desempeño. Sin embargo, hay cuestiones técnicas, de análisis, gestión, etc. en las cuales hay una clara ventaja del informático. Seguramente en testing funcional es más factible, pero si queremos ir en esta dirección deberíamos apuntar a gente informática, sin dudas. En otro momento, retomaré el tema.

3. El Testing no puede automatizarse completamente: No puedo estar más de acuerdo con esta afirmación. No hay dudas. Lo que sí surge aquí es, ¿qué automatizar y qué no?, ¿qué herramientas son las adecuadas?

4. Un fail como puerta de entrada hacia más conocimiento: Un bug permite a los developers explorar escenarios, situaciones, y código aún no explorado y con un fuerte impacto (potencial) en la funcionalidad de software. La forma operativa de capturar conocimiento en testing es a través de un bug.

Para terminar, no deja de sorprenderme la cantidad de comentarios y de gente que tiene las mismas inquietudes. Los lectores son como los testers que ayudan a generar más conocimiento en este blog!

Les dejo unos links a los comentarios que recibí -> 1, 2, 3, 4

Hace unos días, en mi trabajo, estuve presenciando una charla interesante sobre NoSQL. El orador era Cristobal Pedregal Martín. Sinceramente, no conocía mucho sobre el tema y, por lo tanto, no voy a entran mucho en detalle sobre el concepto en este post. Más allá del tema en cuestión (del cuál podemos tener una vaga idea o no saber nada al respecto), estas exposiciones son oportunidades para abrirse a nuevos conocimientos y relacionarlos con otros ya existentes. Personalmente, en estas charlas me fijo mucho en cómo está estructura la presentación, qué ejemplos se usan para explicar los conceptos y cómo el orador se dirige a la audiencia. Cómo hacer una buena presentación no es un tema que esté en condiciones de abordar profundamente, sin embargo, creo que hay que entrenarse al respecto para saber hablar delante de una audiencia.

Volviendo a la charla, y a lo que motivó esta entrada, quería mencionar lo que Pedragal Martín nombró como Talent Pool. La traducción es simple. Sin embargo, me interesó el contexto en el cuál lo comentó. Promediando la presentación, Martín repasaba algunos riesgos asociados a implementar un sistema NoSQL. Decía que es necesario tener en cuenta el costo capital (Capex), el costo operativo (Opex), si el sistema es propietario o si es Open Source y, por último, si existe gente capacitada en esta tecnología o si es necesario atraer a jóvenes promesas para capacitarlas. Inmediatamente, relacioné esto último a un tema actual, complejo y crítico, y que tiene que ver con la poca gente especializada que existe en el ámbito de la Informática. Lo digo en relación a la necesidad actual de profesionales informáticos y cómo de ellos depende el desarrollo de una "identidad tecnológica" como país. Claramente, esto no es algo nuevo y en estos enlaces hay algunas muestras de ello:

Estudiar Computación,
Las posiciones de trabajo más dificiles de cubrir,
La escasez de profesionales, y
Hay que estudiar informática

Como conclusión, está claro que para desarrollar nuevas tecnologías e innovar, es necesario tener este talent pool impulsado por la "profesionalización" de la Informática como disciplina y por la necesidad de definir esta "identidad tecnológica". Es también nuestra responsabilidad promover esta especialización.

Imagen: http://www.insightfororganisations.co.uk/talent-management/