menu_superior

El testing como trabajo desagradecido

He leído un post de José Manuel Sampayo titulado “¿Es el testing un trabajo desagradecido?” y me he animado a escribir este post, un poco por contestarle y un poco por poner en orden mis ideas con este tema. Bueno, también por cortesía por que le iba a escribir un comentario monstruosamente grande y prefiero hacerlo en mi blog y ocupar mi propio espacio 😉

Por situar un poco, aunque lo mejor es leer el post de José Manuel completo, la tésis del post es que el testing es un trabajo desagradecido y aporta 3 acusaciones que se suelen hacer para certificarlo: la responsabilidad del equipo de QA por los errores no encontrados, el retraso que introducen en la entrega y la responsabilidad por la baja calidad de los productos entregados aunque no sea algo sobre lo que el equipo de calidad haya intervenido.

Posiblemente es cierto todo lo que describe el artículo  ( y el original de Mike Brown), posiblemente faltan algunas cosas más que también nos achacan a los testers :-(, pero… No creeis que en muchos casos nosotros somos mismos los que hacemos posible que estas cosas pasen?

Estoy muy de acuerdo con los alegatos para defender la profesion que se exponen en el artículo (la calidad es una misión compartida por todos, inicio temprano de las pruebas, gestión de las expectativas…) lo que suele suceder es que los equipos de testing nos vemos a nosotros mismos como los salvadores, los heroes que van a convertir un código patatero en un ejemplo digno de mostrarse en las escuelas de informática. Esto es un error. Es un error gordo ya que facilita que te carguen con responsabilidades que no son tuyas y deben recaer inequivicamente en los equipos de desarrollo. Hay que evitar escuchar esto de “esto ya lo harán en/los de pruebas”… Además de las responsabilidades ficticias se crean unas expectativas sobre el poder del testing que no son reales y que claramente defraudaremos por que están muy por encima de las posibilidades.

Mi aproximación para cambiar esta mala imagen incluye el respeto estos valores:

.- La calidad es cosa de todos. Nosotros somos los en último término eliminamos defectos pero el compromiso tiene que ser de toda la organización. Ni auditamos ni juzgamos el trabajo de otros. Nuestra misión debe ser proporcionar información al resto de los grupos para que puedan mejorar el proceso de construcción y el producto construido.

.- Test often, test early. Probar con frecuencia y probar desde las fases más tempranas. No solo prueban los testers, no solo se prueba al final…

.- Nunca se tiene la total seguridad de haber eliminado todos los defectos. Siempre puede haber algún caso no contemplado, un defecto inducido por un sistema externo, cambios en componentes no notificados, etc.

Hay más valores que podríamos enumerar, tampoco quería ser exhaustivo. La idea es evitar el victimismo (no lo digo ni por tí, José Manuel, ni por nadie en particular) y ser un poco autocrítico. Seguramente tenemos que empezar por asumir nuestro papel: somos unos técnicos especialistas que incrementamos el nivel de calidad del producto dentro de unos margenes relativamente estrechos y que aportamos valor por que ayudamos a los equipos de desarrollo a mejorar su trabajo mostrándoles dónde están sus puntos débiles y qué cosas han dado o pueden dar problemas para que las eliminen en el futuro. A larga nuestra intervención mejorará no solo el producto también el proceso.

, , , , , , ,

  • http://www.qatesting.es/ Jose Manuel Sampayo

    Totalmente de acuerdo Pedro. Lo del victivismo es precisamente lo único que no me gusta demasiado del artículo de Mike Brown y por eso escribía en mi comentario final que debemos ser autocríticos y ante todo los mejores profesionales del sector 😉 Muchas gracias por enlazar mi artículo.

    Un abrazo,

    Jose

  • http://twitter.com/jherabe Jesús Hernández

    Muy buen artículo, Pedro, como de costumbre. La gestión de expectativas me parece fundamental para no generar frustraciones ni en el cliente ni en el propio equipo de pruebas. Todo el mundo debe ser consiente de hasta dónde se puede llegar y qué se puede exigir con los plazos y recursos disponibles.

    Como bien dices, no se puede probar todo (pruebas exhaustivas) sino que hay que elegir qué probar, con qué cobertura y hasta alcanzar qué objetivo de una forma meridianamente clara, conociendo y asumiendo el riesgo de cada decisión tomada junto con el cliente.

    Para evitar que el testing sea “esa actividad que retrasa el despliegue del software en producción” o la última tarea en el camino crítico del desarrollo de software, hay que intentar adelantar todo el trabajo que no requiera disponer del código fuente (test early): evaluaciones, inspecciones, estrategia de pruebas, criterios de entrada/salida, selección de técnicas de prueba, situaciones de prueba, datos de prueba, etc. para tenerlo todo listo para ejecutar en el momento en el que el código esté disponible.

    En general se puede decir que la planificación (una buena planificación) es el punto de partida para evitar los problemas citados. El compromiso del cliente por la calidad de software y la buena disposición de todo el equipo para conseguir un buen producto software podría ser un buen segundo paso :)

    • pedrosebblog

      Muchas gracias por vuestros comentarios, Jesús y José Manuel. Me alegra que os haya gustado, la verdad es que de vez en cuando apetece salirse de los temas más técnicos y pisar estos “terrenos”.

      Saludos