¿Qué pueden los testers aprender de los editores de libros?

Tengo varios amigos que trabajan en el sector de los libros como editores. Durante los últimos 10 años, he conseguido echar un vistazo a su trabajo y ver cómo un manuscrito se transforma desde un primer borrador, hasta una novela completa.

No es ningún secreto que la mayoría de los autores agradecen ante todo a sus editores cuando el libro finalmente se publica. El libro en sí tiene el nombre del autor en la portada, pero por lo general, señalan que «no podrían haberlo hecho ellos mismos». Esto se debe a que el trabajo del editor de libros es hacer «brillar» al autor. Necesitan pulir el trabajo y ayudan a construir algo extraordinario en base a lo que ha creado el autor.

Un artículo de Beth Hill nos habla sobre las tareas del editor de libros:

«Un editor pule y perfecciona, dirige el foco de la historia o artículo o película junto a un curso en particular. Elimina lo que no encaja, lo que no es esencial para el propósito de la historia. Realza los puntos principales, llamando la atención en los puntos donde la audiencia debe centrarse. «

Ahora esta es la idea: el editor y el autor trabajan juntos para hacer algo brillante. Esto es algo que necesitamos adoptar también en la relación desarrollador / tester. No se puede automatizar completamente el trabajo del editor de libros porque el editor de libros hace algo más que arreglar los errores tipográficos. En realidad, la funcionalidad de autocorrección en los procesadores de texto es una especie de herramienta de automatización de prueba. Automatiza las partes del trabajo que se pueden automatizar. Hay mucho trabajo que no se puede automatizar.

Veamos esa cita de la parte del blog por partes.

«Un editor pule y perfecciona.«

Este es el testing con el que estamos más familiarizados. Pulimos el producto final e intentamos librarlo de los bugs. Creamos checklists según las especificaciones. Tratamos de hacer que el producto esté libre de errores. Sin embargo, no sólo debemos esforzarnos para que esté libre de errores, debemos esforzarnos para que sea perfecto.

 «Dirige el foco de la historia o artículo o película junto a un curso en particular.»

Esto suele ser el trabajo del propietario del producto o del product manager, para ver si el producto realmente tiene sentido. Sin embargo, el propietario del producto a menudo no está utilizando el software tanto como los testers, por lo que estos tienen una buena visión de la «idea» completa del producto. Es por eso que los testers no deben sucumbir solo a hacer las pruebas, deben analizar el producto en consecuencia. La pregunta clave debería ser:

“¿Usaría este software para ganarme la vida? ¿Por qué? ¿Por qué no?” 

“Él elimina lo que no encaja, lo que no es esencial para el propósito de la historia. Él realza los puntos principales, llamando la atención en los puntos donde la audiencia debe centrarse. «

Esta es una idea que no he visto con frecuencia: el tester que dice que una característica/funcionalidad  realmente no hace nada. Por lo general, estas características/funcionalidades se analizan posteriormente para ver qué características se utilizan realmente. ¿Tal vez también podrían ser controlados durante la fase de desarrollo?

En mi opinión, un tester siempre debe señalar también si algo en el sistema es innecesariamente complicado o difícil de usar.

A menudo estamos discutiendo el valor del tester, mostrando los riesgos y cuánto costaría no probar el software. Sin embargo, rara vez «socavamos» el valor de un editor de libros. En lugar de tratar de demostrar nuestro valor por encontrar bugs debemos demostrar nuestro valor mostrando que el software se vuelve mejor, más rígido, etc Esto también es algo en lo que pensar cuando se habla de reemplazar los testers con la automatización de pruebas. La automatización de pruebas es una herramienta vital para ayudar al trabajo del tester y les permite centrase en las cosas que no pueden ser automatizadas. La profesión de tester debería ser algo más que casos de prueba y la caza de bugs.

Estoy deseando que llegue el día en que el software se publique en vivo y los desarrolladores comenten que podría ser su código, pero ciertamente no podrían haberlo hecho ellos mismos.

Este artículo ha sido publicado previamente en SogetiLabs.

Tuomas Peurakoski has been Consultant for Sogeti Group since 2013. During this time he has been continuously trying to find new ways to think outside the box and connect the already defined processes into more logical and streamlined gestalt entities. He has worked during this time in several different roles: test automator, manual tester, test manager and training. He is also the Finnish representative of Sogeti Mobile Testing STS and works a lot with sales to find the best solution for customers’ mobile testing needs.