Wednesday, February 8, 2012

Educando al tester.

Pocas veces he leído una presentación tan hilarante como la de James Bach en relación al fake testing (Testing fallido). Sarcástico desde la primera línea, no deja títere sin cabeza, desde los modelos de "madurez" hasta los casos de prueba super detallados. Algunos highlights de la presentación:
  • La "madurez" me permite que mis procesos sean lentos y caros, pues dichas cualidades son "virtudes".
  • (Para hacer como que prueba, diseñe) Casos de prueba detallados con puntos de verificación muy específicos que son ejecutados después de cada build por Testers inexpertos.
  • (Para hacer como que trabaja con sus pruebas, ) Ayuda el relocalizar al equipo de pruebas a miles de kilómetros de los programadores.
Y la cereza en el pastel: la Automatización,
  1. Compre licencias de una herramienta de automatización cara (véase Rational, Mercury, Compuware, etc)
  2. Defina un montón de pruebas manuales,
  3. Contrate un equipo de automatización y automatice cada uno de ellas,
  4. Desarrolle una cantidad enorme de código para sus librerías de pruebas y un framework,
  5. Arréglelo constantemente
Trish Khoo escribe en su blog que la mayoría de los testers "caen" a la profesión por casualidad,
y que hay una creencia muy arraigada de que el testing es una profesión de inexpertos y que
cualquiera puede ser buen tester (mmmh, donde he oido eso antes). Así que, cuando se contrata
personal para pruebas, con mucha frecuencia se contrata a cualquiera.

La solución, como en todo, reside en la educación. Educar no sólo al tester, sino a todos los
equipos de desarrollo, los project managers, y hasta los reclutadores que los contratan. Y
requiere mucha reconsideración del rol que jugamos los testers en un proyecto. Basta de

Monday, January 16, 2012

Testing, Mentiras y Verdades.

Estoy peleado con la visión simplista que cualquiera puede probar una aplicación, pues no le hace justicia a nuestra profesión tan llena de retos. Tampoco estoy de acuerdo con aquellos testers que se suben a un pedestal ( o se montan en su macho) y se creen dueños de la calidad de un producto, con super poderes para bloquear la salida a producción de un software que tiene baja calidad. Y mucho menos comulgo con aquellos que dicen requerir especificaciones/requerimientos exhaustivos para probar un software, so pena de negarse a empezar su trabajo.

A lo largo de mi carrera he oído con cierta frecuencia que "Cualquiera puede hacer testing (manual), al cabo es bien fácil, nomás sigues el caso de prueba", o "No es necesario probar la aplicación". Y aún, recientemente, se requirió la colaboración de 5 programadores para un proyecto de testing que ya iba atrasado: La cara que pusieron lo dijo todo, pero aún así, no se hicieron esperar sus peroratas de "que flojera, todavía fuera automatizado" y cosas por el estilo.

Lamento decirles, señores, pero ese es un sólo una técnica de testing manual: el basado en Casos de Prueba o scripts. Es muy 'cuadrado': requiere de mucho esfuerzo pero poca o nula creatividad. El tester rara vez necesita salirse del guión (aunque éste mismo lo haya escrito), y tiende a no percibir otras fallas obvias, ya que está enfocado a un resultado esperado a la vez. Es bastante miope.

Entre otras bellezas, (los testers) nos encargamos de maximizar el conteo de defectos, ayudamos a los Managers a tomar decisiones de cuando liberar o no un software a producción, a minimizar los costos de soporte técnico, evaluar si el producto está conforme a especificaciones y leyes regulatorias, a encontrar flujos de la aplicación libres de errores, evaluar la calidad y verificar si el producto está implementado correctamente. Para ello nos valemos de todo un catálogo de herramientas disponibles o desarrollamos las propias a la medida de las necesidades del Cliente. Si, leyó usted bien. Desarrollamos. No todos, mas al parecer la tendencia es que los testers programemos.

Hay por otro lado, los testers que se creen la última línea de defensa. Son lo que Lis Hendrickson llamó "guardianes" de la calidad, quienes alegan ser a los únicos que les importa. Esa actitud resulta en dos efectos negativos, a saber: logra excluir los esfuerzos del resto del equipo, frustrando a todos aquellos que se esfuerzan por lograr un producto de mayor calidad; es también una lamentable excusa para aquellos miembros del equipo que se creen muy ocupados para pensar en la calidad, al fin los testers ya tomaron la estafeta, enemistándose con medio mundo en el proceso. Aún más, al asumir el poder de veto sobre un producto, terminan tomándose atribuciones que no le van, porque debería ser el project manager quien sopesa riesgos y conflictos. Nadie más.

En ausencia de una especificación clara, o dada con antelación, es que utilizamos nuestras habilidades investigativas, en combinación de técnicas como pruebas exploratorias. Sobre todo en contextos de desarrollo ágil, donde el grupo de desarrollo prefiere no tener una especificación detallada, ni siquiera documentar de manera excesiva potenciales cambios. Esto implica el reto de crear pruebas basadas en cualquier información que llegue a nuestras manos, empapándonos del dominio de la aplicación. Como proveedores de un proyecto, no podemos rehusarnos a trabajar. Si acaso a pedir más aclaraciones; a utilizar técnicas de prueba en ambientes dinámicos; a estar en más comunicación con el cliente y con desarrollo, dándoles retroalimentación sobre el software en desarrollo.

Estas tres o cuatro mentiras sobre el rol del tester son las más frecuentes en mi práctica profesional, y las que más me causan comezón cada vez que las escucho. Estamos tan acostumbrados a proyectos con CMMi y sus mejores prácticas que cuando nos cae un proyecto poco documentado a la bandeja, tendemos a sentirnos desamparados. Es mi sincera opinión que debemos empezar a basar nuestras pruebas en cualquier dato podamos obtener.

Wednesday, January 11, 2012

Test is dead, o eso dicen, parte II.

Al fin supe por qué dice el Alberto Savoia que el testing está muerto.

Resulta que en el estudio hecho por Elizabeth Hendrickson sobre trabajos de QA, salió a colación el tema. Dicho estudio, intitulado "¿Tienen que programar los testers? ("Do Testers Have to Write Code"), lleva dos años realizándose y es resultado de examinar vacantes de testing en Estados Unidos. La abrumadora conclusión es que el 80% ( y 85% este año) de los empleos requiere alguna habilidad de programación. Queda pendiente un estudio similar para México, pero me aventuro a pronosticar que ni siquiera el 50% de los trabajos de testing requiere programación.

Finalmente, el artículo hace mención de la plática del Beto. Vestido de calaca, afirma que .el reto más grande no es desarrollar la aplicación correctamente, sino la aplicación correcta. Así que lanzan una versión mínima del producto para obtener retro de usuarios finales y clientes de manera rápida. Otro googlero, James Whittaker, en su plática llamada "Todo ese testing es estorboso para un trabajo de calidad (All That Testing is Getting in the Way of Quality)". Jaime explica, al igual que Beto, que Google utiliza a sus usuarios para hacer la mayoría de sus pruebas exploratorias, ya que "(Los) Usuarios juegan mejor el rol de usuarios que los testers, por definición."

Según Joel Spolsky, entre las cinco malas razones para no tener testers, destacan la ii)Mi software está en internet ( y puedo arreglar los bugs en un segundo) y iii) Mis usuarios harán las pruebas por mi. En realidad, google si tiene Ingenieros de Prueba, quienes pasan entre el 20 y 80% del tiempo escribiendo código, según Jaime. Probablemente son las pruebas de caja negra como las conocemos están moribundas. Ergo, El testing está vivito y coleando (pero no tanto).

Por el estudio mencionado arriba, los requerimientos de empleo parecen indicar que, por lo pronto, la mayoría de los testers escriben algo de código. De nuevo, estamos hablando de Estados Unidos, pero, al final del día, ¿No hacemos mucho outsourcing de esas pruebas aquí en México? Tengo la impresión de que el testing en México está en pañales, por experiencias previas con empresas mexicanas, pero eso es tema de un estudio más extenso.

Thursday, November 10, 2011

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...

Tuesday, September 20, 2011

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..."

Saturday, July 2, 2011

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.


Saturday, June 18, 2011

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.