Pon un tester en tus proyectos

A menudo recibo la pregunta: ¿Qué puedo hacer para mejorar la calidad del software que desarrollamos? Y mi respuesta siempre es la misma: Pon un tester en tu proyecto.

Pero la reacción a mi respuesta es siempre reticente. Las cuestiones que se plantean suelen ser del estilo:

¿Cómo se los voy a justificar a mis superiores? o ¿Cómo voy a poner alguien solo a probar, con todo lo que tenemos que desarrollar?
No existen tester en el mercado.
Los desarrolladores ya prueban.
Las pruebas las hace el usuario.

…y algunas variantes de las anteriores.

Iré abordando estas cuestiones a lo largo de este post, aprovechándolas como una perfecta excusa para hablar sobre algunas de las ideas erróneas que se tienen sobre la calidad en el software. De todos modos antes de seguir leyendo te recomiendo que leas un post anterior: En el software, la calidad, no es opcional.

Primero de todo voy a dar varios motivos por los que la figura de un tester es valiosa para un proyecto:

Es muy útil contar con alguien cuyo trabajo sea única y exclusivamente vigilar la calidad del software para asegurar que la calidad se ve como una autentica prioridad. Se nos puede llenar la boca de lo importante que es la calidad del software para nosotros y nuestra empresa, podemos llenar el pasillo de carteles tipo "la calidad nuestra razón de ser", pero nada deja más claro la importancia que le damos a la calidad que poner un tester en nuestro proyecto. Todo el equipo de desarrolla sabrá a ciencia cierta que alguien va a estar vigilante sobre la calidad del software que se desarrolla, y por tanto será mucho más cuidadoso. A nadie le gusta que le saquen los colores

Un tester impulsa el desarrollo, por que ayuda a que los errores se descubran rápido y por lo tanto con mucho menor impacto sobre las tareas cotidianas del equipo de desarrollo. Además, el tester mantiene la infraestructura necesaria para probar el sistema, de manera que siempre contamos con un entorno de pruebas en buen estado. Otro factor por el que un tester impulsa el desarrollo es porque tiene que tener algo que testear, lo que 'obliga' al equipo de desarrollo a mantener cierta velocidad en el desarrollo para 'alimentar' al tester.

Un tester impulsa el uso de buenas prácticas porque para que alguien pueda probar nuestro software este tiene que ser construido a menudo, lo que obliga a tener algún sistema de construcción automática. Otra buena práctica relacionada con que haya un teste en nuestro equipo de desarrollo es la necesidad de actuar pronto sobre los bugs. Ningún tester soporta encontrarse con el mismo bug más de dos veces. Además si tenemos un tester en nuestro proyecto, con total seguridad tendremos un sistema de bug tracking, o el se asegurará de ponerlo en marcha, por su salud mental. Otro efecto beneficioso, es que si tienes un tester en tu equipo, no caerás en el error habitual de dejar la calidad para el final.

Bueno ahora que ya os he convencido de que necesitáis un tester en vuestro proyecto voy a entrar en las reticencias para no tenerlo que comentaba al principio:

¿Cómo se los voy a justificar a mis superiores?: No lo hagas, no lo necesitas, no tienes porque explicar que necesitas un tester, si tu equipo aun no lo tiene muy probablemente tus superiores no entienden esa necesidad. Si tu equipo de desarrollo se componen de n desarrolladores, convierte a uno o varios en testers. Si estas formando un nuevo equipo, aun es más fácil, pon n-m desarrolladores y contrata m testers (m no puede ser cero!!!). Ahora pensarás, si tengo menos desarrolladores, voy a correr menos!!!. Pero esto es falso, la manera más rápida de desarrollar software es hacerlo con calidad. El proceso de desarrollar un proyecto de software es algo iterativo, construyes software sobre software existente, iteración sobre iteración, si no logras tener una base de código estable, es muy difícil que la siguiente iteración añada código de calidad. En una frase, sobre cimientos de basura solo se sostiene más basura.

No existen tester en el mercado: Falso, lo que no existe es demanda de testers desgraciadamente, pero hay mucha gente dispuesta e interesada en trabajar mejorando la calidad del software que otros prueban. Es un trabajo interesante, en el que se usan herramientas avanzadas y que para ser realmente efectivo exige escribir código, automatizar pruebas, crear scripts de limpieza de la red pruebas, utilizar herramientas avanzadas de pruebas como Team System Tester Edition. El problema es que debido a la ignorancia de la importancia de esta figura esta devaluada. Probar en este país, es un trabajo de becarios, que dada su inexperiencia no obtienen grandes resultados, lo que se traduce en que los testers no esten valorados. En Microsoft por ejemplo, solo programadores senior pueden testear el trabajo de otros, el que más sabe es el encargado de asegurar que otros hacen un trabajo correcto, ¿podría ser de otro modo?. Adeás incluso hay certificaciones para testers.

Los desarrolladores ya prueban: Falso, los desarrolladores están entrenados y se centran en que las cosas funcionen, no en tratar de romper las cosas. Un programador puede desarrollar un pantalla de login y nunca hacer login usando el ratón, solo el teclado, miles de veces. Un tester entrenado y metódico probará la pantalla de login con el afán claro de romperla, detectando que no se puede hacer login usando el ratón al poco rato. Otro enfoque que a menudo veo es que los analistas sean los que prueban, pero no estén entrenados para ello. Es más a menudo no tienen el tiempo para ello, y son 'analistas' algo mucho más reconocido que ser tester, no quieren dedicar su tiempo a probar, sino a analizar. Además los analistas cuenta con una visión propia del sistema, no en vano ellos son los autores del análisis, pero nada asegura que esta visión sea la correcta. La consecuencia es que la calidad de tu software caerá. Otro factor a tener en cuenta es que el software cada vez es más complejo, y las pruebas que necesita tambien, e incluso las herramientas que existen para realizar esas pruebas (hechadle un vistazo a VSTS for Testers Edition) por lo tanto es imprescindible un alto grado de especialización.

Las pruebas las hace el usuario: Sin duda a parte de los problemas que se derivan para tu imagen como empresa o tu imagen como profesional, el problema más grave es otro. Cuanto más tarde te enteras de un error, más te cuesta en términos económicos. Si los errores te los cuenta el usuario, te estas enterando lo más tarde posible y por tanto lo vas a pagar caro. Ver el gráfico adjunto.

Este post va dedicado a Hector, de Panda Software, el tester con más dedicación y entusiasmo con el que he tenido el placer de trabajar. Sin su excelente labor, 'parir' AdminSecure hubiese sido mucho más doloroso.

16 comentarios sobre “Pon un tester en tus proyectos”

  1. Solo un comentario, aunque es obvio (pero como bien mencionas en realidad no lo es tanto) que el implementar un proceso formal de pruebas ejecutado como tal por un profesionista es un requisito imprescindible para obtener calidad en un producto, esto es solo un lado de la historia, ya que aunque efectivamente la funcionalidad es un aspecto escencial para decir que un software tiene la calidad adecuada (es decir, si un software no hace lo que tiene que hacer, pues estamos en el hoyo), esto cumple dependiendo de la complejidad del software, un porcentaje de la calidad. El resto de la calidad proviene de atributos que no están asociados al funcionamiento del software. Es decir, aspectos como usabilidad, desempeño, portabilidad etc. Aspectos que algunos autores identifican como Factores de Calidad, Requerimientos Operacionales, Requerimientos No Funcionales, etc.
    Y en ese escenario, aunque el Tester también tiene un papel (es quien se encarga de verificar que los atributos se satisfagan), quien defina la calidad del mismo es precisamente el Rol del Arquitecto de Sotware.
    Para quien este interesado, chequen el blog del buen Sergio: http://community.crosshorizons.us/blogs/softwarearquitecto/default.aspx

  2. Rodrigo, estoy totalmente de acuerdo contigo en todos los puntos comentados acerca de la necesidad de un tester y las razones a esgrimir ante la dirección de la empresa. Creo que es fundamental para la supervivencia de cualquier empresa de software.
    No obstante, antes de contratar un tester en una empesa, yo haría la siguiente pregunta ¿ Está la empresa preparada para que un tester desarrolle su trabajo eficientemente ?
    Y la respuesta podría depender de otras cuestiones como: ¿ Está el software suficientemente documentado para que una persona ajena al desarrollo sepa lo que tiene que probar ? ¿ Existen base de datos de pruebas perfectamente establecidas para que las pruebas sean efectivas ? ¿ Se tienen herramientas para controlar y documenatar cada una de las incidencias encontradas y reportarlas a programación ? ….
    Con ello quiero decir que no resulta tan sencillo tomar la decisión de contratar a un tester y que
    se ponga a trabajar. Antes de eso es necesario un trabajo de análisis de la situación actual de la empresa, ya sea interno o externo, y seguramente a partir de ahí trabajo duro hasta tener los cimientos necesarios para contratar un tester.

  3. Hola Aderojas!!!

    Siento decirte que no creo que que sea condición indispensable, aunque sin duda ayuda, que las pruebas estén documentadas para que un tester pueda realizar su trabajo. No es necesaria ninguna documentación que te diga que el software no tiene que ‘cascar’ o que su operación tiene que ser simple, o que su rendimiento tiene que ser aceptable. Un tester medianamente experimentado podrá hacer mucho por el software aunque no exista mucha documentación. Es más, un buen enfoque a la hora de diseñar software es hacer que cualquiera lo pueda utilizar sin tener que leer el manual, lo que implica que un tester lo pueda probar sin tener que leer mil casos de prueba.

    Si comparto tu opinión de que herramientas para documentar, gestionar (que no controlar) e informar sobre los problemas encontrados son imprescindibles, pero de nuevo, un tester medianamente experimientado ni se planteará hacer su trabajo sin un bug tracking, probablemente si no hay uno en la empresa, lo instalará (hay muchos gratuitos) y hará evangelismo sobre su uso. En conclusión, lo importante es tener el tester, que impulsará, como ya comento en el post el uso de buenas prácticas, solo para poder mantener su salud mental.

    Tampoco estoy de acuerdo en que el tester sea ‘alguien ajeno al desarrollo’. Esto es parte del error de como se gestiona la calidad. El tester es alguien del equipo de desarrollo!!! Una pieza central y vital, tanto como cualquier desarrollador. Entrenada para asegurar la calidad de software desarrollado desde el primer momento del desarrollo. El pensar en testers ajenos al desarrollo es pensar, implicitamente, en ‘dejar la calidad para el final’. No digo que no sea interesante que departamentos o empresas ajenas al desarrollo certifiquen la calidad del producto, pero esto es una segunda derivada.

    Vamos que en mi opinión contratando un buen testes ya estás haciendo mucho por la calidad, igual que contratando cualquier otro tipo de desarrollador. Nadie se plantea hacer un proyecto sin jefe de proyecto, analistas o arquitectos de software (o al menos así debería ser), pero a menudo se plantean hacer proyectos sin testers empresas a la que luego se les llena la boca de ‘calidad’!!!!!

  4. Rodrigo, estoy de acuerdo contigo en que tener un tester en el grupo de desarrollo ayuda mucho, pero tb creo importante tener en cuenta que los propios desarrolladores tienen que intentar dar la mayor calidad posible, haciendo las pruebas para verificar que sus desarrollos cumplen con lo que se les ha pedido. Si el programador entrega «software basura» al tester apaga y vamonos!! No puede ser que por tener un tester en el equipo yo me olvide de la calidad porque ya me lo va a probar otro.

    Lo que intento decir es que un tester sí que ayuda mucho a mejorar la calidad, siempre que el tester realmente sea eso y no una persona que se dedica a dar doble-click sobre la aplicación, pero que antes hay que cumplir con otros pasos anteriores; Una buena documentación, revisiones de código, pruebas por parte del desarrollador..y no caer en que con tener un tester ya me vale.

  5. Encuentro que uno de los principales obstáculos para plantearse tener un equipo de testers, (suficiente con que cumpla la formula m+1 testers donde m<>0, según Rodrigo) es la motivación o la ausencia de experiencia positiva en este campo.
    Ya no digo iniciar los pasos, simplemente que por nuestra cabeza pase la idea, de que se tiempo esta bien invertido.
    Ian Sommerville, decia algo asi como:
    «Las pruebas sirven para determinar que un sistema tiene fallos, pero no pueden demostrar la ausencia de estos»

    Así… ¿Quién quiere probar un sistema? ¿Cómo podemos asegurarnos fehacientemente de que un sistema es bueno? Quizás ahí encontraremos la motivación que buscamos.

    Gracias por vuestro tiempo.

  6. El post buenisimo como siempre, pero encontrar una joya en los comentarios como

    Ian Sommerville, decia algo asi como:

    «Las pruebas sirven para determinar que un sistema tiene fallos, pero no pueden demostrar la ausencia de estos»

    me pone 😀 😀 😀

    Thanks to everyone

    Saludos

  7. Hola:
    Soy Tester y me da mucha felicidad encontrar este tipo de comentarios en la red. Desde que me inicié en este rol (que nunca pensé que existiera) me he tenido que enfrentar a una serie de menosprecios, confrontaciones, demostraciones, experiencias, etc todas con el afán «no de defender mi trabajo» sino de hacer ver a los equipos de desarrollo con los que trabajo, la importancia de documentar, asignar tiempo para pruebas y trabajar ordenadamente para aminorar la falta de cumplimiento de requerimientos del cliente que lleva a la ruina a muchos proyectos.
    Gracias a mi trabajo, al menos con la gente que he trabajado ha terminado por entender la importancia de tener un tester durante sus proyectos, cosa que me da mucho gusto porque tambien me abre muchas fuentes de empleo. Es un camino por recorrer pero confío en que poco a poco se logrará esta conciencia en todos los equipos de Desarrollo de Software.

  8. Sólo un pequeño comentario. Si algún día tomáis la decisión de poner un «Software Quality Engineers»(o más de uno) en vuestros proyectos…no podréis vivir sin ellos. Como bien dice Rodrigo «impulsan el desarrollo y las buenas practicas».
    Por otro lado…existe mucha gente en España que se dedica al «Quality Assurance»…yo en Barcelona conozco por lo menos a unas 30 personas…existir, existen!!!!

  9. Por alusiones, se agradecen las flores Rodrigo….
    Buceando por ahí me he encontrado esto…
    Muy importante lo que comentas y lo que apuntilla el sr Landa 🙂 si el desarrollador entrega software basura al tester apaga y vamonos!!!

    Ainsss que tiempos aquellos de Admin!!

    La masa el ladrillo la bota el bocadillo vamossss
    😉

Responder a anonymous Cancelar respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *