Black Box Software Testing

En estos días de poca actividad en mi proyecto me encontré con varios recursos bien interesantes de pruebas. El primero, un curso de black box software testing, de Cem Kaner y James Bach, con colaboraciones de Michael Bolton (el ingeniero de software, no el cantante) y demás pesos pesados. Apenas llevo el de Foundations y empezando con el de Bug Advocacy. Otros temas incluyen Test Design, Domain Testing, Scenario Testing, Spec-Based Testing, Risk-Based Testing y Exploratory Testing. Muy recomendables todos, sobre todo para gente como yo que le gusta estar un poco contra la corriente y es anti-certificaciones como CSTE o ISTQB o modelos engorrosos como el CMMi. Para citar el artículo de Kaner, "The ongoing revolution in software testing"

Algunos libros dicen que si nuestros proyectos no están controlados "apropiadamente", si nuestras especificaciones no están escritas, siempre completas y siempre actualizadas, si nuestro código no está organizado de acuerdo a cualquier metodología en boga, entonces, bueno, deberían estarlo. Dichos libros hablan de hacer pruebas cuando todo mundo juega de acuerdo a "las reglas."

Este libro es sobre hacer pruebas cuando tus colegas no siguen, no quieren o no tienen que seguir las reglas. Con frecuencia, los proyectos de software se caracterizan por un presupuesto que es demasiado pequeño, un personal muy reducido, fechas de entrega muy prontas y que no se pueden posponer nunca, y por una visión y compromiso compartidos por los programadores. La calidad de un gran producto va de las manos con un grupo de individuos que lo diseñan, programan, prueban y documentan. El esfuerzo de cada cual cuenta. Los estándares, especificaciones comités y controles de cambios no aseguran la calidad... Es el compromiso de los individuos para con la excelencia, su dominio de las herramientas de su oficio, y su habilidad para trabajar juntos lo que hace un producto grande, no las reglas.

Del otro recurso les platico cuando lo termine de leer...

Certificaciones, Weekend testing y otras actividades interesantes.

En estos días en el trabajo estamos armando un plan de certificaciones para la raza. No estoy particularmente de acuerdo con las certificaciones, debido a que en mis siete años de estar en este negocio no he necesitado ninguna para ejercer, ni para obtener mejores puestos de trabajo, pero parece ser el objetivo de varias personas en la organización, desde los jefes a algunos compañeros que quieren ponerlo en su CV.

La hoja de control de certificaciones que armamos contiene entradas como las que siguen,

• Quality Center (de HP Mercury, actualmente ALM)
• QuickTest Professional (de HP Mercury también)
• ISTQB (International Software Testing Qualifications Board, certificación en el ramo de pruebas)
• CSTE (Certified Software Tester)
• LoadRunner (de HP Mercury).

Se puede ver la tendencia de certificaciones de herramientas muy comerciales como las de HP Mercury. Espero que haya un poco mas de variedad en años por venir.

Yo en lo particular prefiero una serie de talleres prácticos con temas de testing como context-driven testing, rapid software testing, agile testing, y demás approaches de black box. Y si acaso después, rematar con una certificación, debido a que soy de la opinión que la certificación como tal difícilmente te deja conocimiento aparte de memorizar conceptos. Hay que ponerlos en práctica.

Recientemente me topé con el sitio de weekend testing, en el cual testers de diferentes partes del mundo (predominantemente de la India), se juntan para probar algún programa de código abierto (sourceforge suele ser la fuente de dichos programas). Después, utilizando herramientas como typewith.me para crear documentación, se generan entregables como misión y estrategias de prueba.

Me parece una idea interesante ya que aquellos que contamos con algo de tiempo libre en el trabajo, y tenemos un poco de proactividad podemos aprovechar para adquirir habilidades nuevas. Hace nuestro CV más atractivo sin tener que mentir tanto en la entrevista al incorporar técnicas de pruebas que por lo regular no tenemos chance de usar debido a que el cliente ya tiene un proceso ya establecido. Sirve también para rolar roles (vaya expresión). En un ejercicio A puede ser líder de B, C y D, mientras que en un futuro ejercicio B es quien liderea. Pero sobre todo, en las palabras del equipo de weekend testing, "... es una ... plataforma para dejar que los ingenieros de prueba salgan de al rutina diaria ... y practicar testing en un ambiente seguro sin preocuparse de nada..."

Salarios de Testing...

Y, en estos días, uno de tantos temas recurrentes ha sido el de los salarios. Verán, sin hablar de cifras, un amigo fan de las estadísticas y yo hablábamos de las prestaciones y beneficios laborales a los que aspiramos dentro de las diferentes empresas. Y concluimos en que en ese renglón, los de TI que hablamos un inglés medianamente pasable vivimos en un mundo aparte, de fantasía.

Mi opinión es que esto se está convirtiendo en una burbuja no muy diferente a las vividas en las épocas del dotcom y la inmobiliaria. Y a pesar de las diferencias de opinión entre nosotros dos , estoy de acuerdo en que la alta demanda y escasez de personal de TI ocasionan que los salarios de ciertos consultores del área estén por las nubes. Anteriormente, en tiempos de IBM aquí en Guadalajara, los salarios eran más bien aterrizados a la realidad nacional. Con la llegada de TCS, el salario de un fresher subió, según las cifras que he reunido entre mis amigos, de un 25 a un 35%. Agreguen la llegada de Bank of America, Oracle (entre otros), y si los rumores son ciertos Accenture e Infosys, y verán que esto va apenas comenzando.

Discusión aparte de si la reforma laboral nos hará más competitivos o no, de si el outsourcing tiburonesco llegó para quedarse o no, se ve una clara tendencia en el ramo de, empresa que se instala, empresa que ofrece prestaciones superiores a las de ley: Vacaciones de 10 a 15 días el primer año (contra seis que marca la LFT), Aguinaldos de 30 días (contra 15 por ley), Vales de despensa y fondos de ahorro topados ó sin topar, Seguros de gastos médicos a cada integrante de la familia del trabajador. Atractivo no? Todo un modelo de "Land Grab" en un contexto donde ya existen fuertes competidores, pero en el cual la adquisición de talento es vital para el nuevo de la cuadra.

De nuevo, Cuándo reventará la burbuja? Espero que no pronto.

Test is dead, o eso dicen.

El dia de hoy leí un post cuyo titulo leia "Test is dead" en el blog de googletesting. Eso me recuerda una conferencia de la agilista Elizabeth Hendrickson de la compañia TestObsessed quien narra que, despues de una conferencia de Agile, el ponente declaro que el trabajo de los testers era "irrelevante". Y a decir por la cultura mexicana del software para muchas pequeñas y medianas empresas, el desarrollo es necesario pero las pruebas no.

Fuera de si mal interpreté el post de google, la verdad es que todavía hoy, habiendo tanto tester, y que somos una gran parte de la facturación de las compañías de servicio, se nos considera un mal necesario. Mala onda, no? Y aquí algunas de mis experiencias en el área de testing:

• En una empresa de servicios donde trabajé recientemente, varios desarrolladores trabajaron en un proyecto interno de un sistema administrativo. El manager que les encargó dicha tarea les indicó que no era necesario probarla. Estamos hablando de una empresa que factura bastantes millones de dólares al año y que tiene un departamento de Pruebas. Huelga decir que, para cuando empezamos a probar la aplicación, tronó peor que Windows 95 y su blue screen of death.

• Hace un par de años compartí depa con un desarrollador .NET que tuvo a su cargo un programa de inventarios para una compañía bloquera. Se tardaron más de un año en programarla, y, después de un fallido deployment en varias ciudades, los usuarios finales encontraron la herramienta, inusable.
• Recientemente evalué una herramienta de telefonía para una startup (trabajo gratis, de compas). El entrepreneur estaba más preocupado por los costos del testing que por contratar un desarrollador novato, quien aumentaría el riesgo de que su aplicación tronara como chinampina. Y parece no ser sólo el pequeño empresario a quien le duele el codo pagar por pruebas. Por el ejemplo anterior, tambien los medianos, grandes empresarios.

Hay muchas razones equivocadas para no contratar testers, y Joel Spolsky nos cuenta cinco de las más socorridas. Y como hay mucho que decir sobre el tema, creo que esta será una serie de posts. Veamos lo que ustedes tienen que decir sobre el tema.

Por eso tu, desarrollador, si quieres saber si tu entregable funciona como deberia, y lo que es mejor, si quieres disminuir el riesgo de que tu programa no truene a las primeras de cambio con tu cliente, haz contratar un tester.

Tu, empresario, que has invertido en un software que será ventaja competitiva para tu negocio, no dejes que se transforme en pérdida. Necesitas alguien pruebas externo a desarrollo que te de una medida de la calidad del producto. Y si tienes un consultor que supervise a la empresa que te provee de equipo de testing, mejor. Alguien debe auditar al auditor. Por otro lado, y en la medida de lo posible, contrata freelancers. Hay muchas opciones y siempre obtendrás precios más asequibles.

Mi nombre es Omar Navarro, y soy un tester.

Me inicié en el mundo del testing hace como siete años, parcialmente inspirado por un maestro de programación que solía serlo (Gracias de nuevo, Ken Bauer). Él es una leyenda en el campus famoso por su prueba del teclado (Básicamente, simula input aleatorio volteando un teclado y luego esperando la respuesta del programa).

Así que, tres años despues de haber tomado su clase de compu II, y haber tomado clases evaluación de interfases de usuario, decidí que ya estaba listo para el mundo laboral y solicité empleo en la IBM de México. Año y medio después , de testing manual, entrenamiento en procesos y automatizaciónconsideré que ya estaba listo para nuevos retos (y más salario :) ) y tomé un empleo con Softtek en Monterrey. Seis meses después ( muy poco tiempo, pero llegaré a eso luego) como desarrollador Java en un proyecto de automatización de pruebas con Symbian. Y así sucesivamente hasta hoy, siete años de experiencia después, y haber hecho testing manual, automatizado, desarrollo de frameworks, liderazgo de equipos y varios viajes al extranjero estoy a punto de convertirme en el Delivery Manager Nearshore de testing para una compañía India.

Así que, 7 años y 7 trabajos después, me parece que he estado haciendo un poquito de todo en el área de pruebas, y es precisamente lo que quiero compartir con la comunidad IT de habla hispana. Es gratificante ver las inmensas oportunidades que hay en el área de la ingeniería de pruebas o testing como se le conoce más comúnmente, más allá del simple monkey-testing con el que se estereotipa a la profesión. El tester es mucho más que un capturista de datos, o creador de escenarios. Como todo tiene su chiste. Tiene tanta codificación como cualquier proyecto de desarrollo y te enfrenta a retos bastante interesantes. Es cuestión de actitud e ingenio.