La mejor herramienta de pruebas con la que dispone todo equipo de desarrollo

Gracias a la interacción con los estudiantes del curso he recibido la misma pregunta una y otra vez, y al pensar en el articulo que quería publicar esta semana, llegaron a mi mente muchos posibles temas para publicar en el blog.

Aunque he querido retomar los temas de liderazgo, comunicación y creatividad me he dado cuenta de lo necesario de seguir conversando de la importancia del factor humano en las pruebas de software.

En una era obsesionada con resultados rápidos y el exceso de procesos automatizados todo el aporte humano queda relegado al análisis y prevision de la perspectiva de los desarrolladores. Muchos de ellos con análisis ya marcados sobre resolución de algunos problemas, siendo necesario la mediación de las personas que estamos en el medio de los desarrolladores y usuarios. Sin embargo en muchos equipos no se determina la importancia del aporte de esta perspectiva. 

¿Esto es algo bueno para la industria de software? 

Si bien quisiera responder con resultados concretos, debo responder con mi opinión, lo cual pudiera generar debates abiertos de miles y miles de opiniones, pero debo concluir que de ninguna manera esto es bueno.

Uno de los mayores resultados de cada ciclo de pruebas en el desarrollo de un pruebas, es un ingeniero mucho más listo y conocedor del producto y proyecto que en el que está trabajando.

Cuando estuve trabajando con un equipo de la India, me llamaba la atención la obsesión con entregar números y demostrar la cantidad de trabajo que se estaba haciendo desde el area de pruebas, muchas veces sin llegar al total entendimiento del negocio o lo que se buscaba alcanzar con el proyecto.

Si bien los reportes y los números son importantes, muchas veces solo a través del uso del producto es que puedes llegar al mayor valor que tu perspectiva de ingeniero puede proveer, y es la interacción humana dentro del equipo, y no la cantidad de pruebas que puedas escribir o la cantidad de ellas que logres reproducir.

Cuando ponemos todo el peso en esto, olvidamos un factor profundamente importante en la estrategia de pruebas, y es el ingeniero de pruebas en sí.

Los buenos ingenieros se mantienen en constante crecimiento y aprendizaje. Así mismo como el proyecto progresa y agrega nuevas funcionalidades y estructuras, de la misma manera el ingeniero de pruebas también lo hace, pues gana mayor conocimiento de producto internamente, y gradualmente mejora su análisis y sensibilidad en cada camino que importa en ese proyecto.

El ingeniero de pruebas busca más que errores en el sistema

Por eso mantengo que es erróneo pensar que el rol de un ingeniero de pruebas, QA o tester esta solo relacionado con encontrar errores en la aplicación, y quizás esta afirmación es una de las que mas ha contribuido en el pensamiento generalizado que las pruebas automáticas pueden ayudar a que el proyecto avance más rápido y la búsqueda incesante de ingenieros que conozcan las mejores herramientas.

Hasta el año 2020, según los reportes entregados por Ministry of Testing, la mayoría de las empresas de software estaban mas dispuestas a contratar a un ingeniero de pruebas, confiando más en sus habilidades de comunicación, muy por encima de las herramientas que maneja. Y tiene sentido, porque ¿sabes qué? Las herramientas las puedes aprender con un par de clics y búsquedas en internet, pero conocer un producto y trabajar en equipo, dependiendo de tu equipo, eso te tomara más tiempo y no hay un camino fácil para entenderlo, ni clics en internet que te provean del conocimiento interno de cada equipo.

¿Entonces? ¿Me estas diciendo que la mejor herramienta que puede tener un ingeniero de pruebas es su propia habilidad para conocer el producto y crear pruebas que potencialmente influyan en crear un producto con menos errores? Pues si, eso te estoy diciendo.

Un ingeniero experimentado que conozca el producto y que haya estado en cada lanzamiento y liberación de versiones, es capaz de probarlo con una gran efectividad, aun si recibir mayores instrucciones de los cambios anexados al proyecto.

Algunos consultores y escritores en el campo parecen creer que la ineficiencia de un ingeniero de pruebas se puede “arreglar” con el establecimiento de un procedimiento detallado de pruebas para cada ciclo de publicación de un producto.

En mi humilde opinion, esto es una mala practica, debido a que un buen ingeniero y un producto de mucha calidad implica un equipo comprometido, donde todos trabajen con el fin de entregar un producto que satisfaga las necesidades del usuario y con la menor cantidad de fallos posibles, y creer que esto solo se logra reportando errores, refleja la falta de entendimiento de las pruebas de software y lo que la gente de nuestro campo realmente hace.

Así, que finalmente quiero decirte que antes de evaluar cualquier procedimiento de pruebas, procedimiento o herramienta, comiences por echarle un vistazo a tu equipo de desarrolladores u de pruebas y te intereses por lo que hacen, la forma en la que entienden del proyecto y que piensan ellos al respecto y como influye esto en el producto final.

Solo el mismo equipo de desarrollo puede llegar a conclusiones magnificas sobre lo que hacen y cómo pueden llegar a mejorarlo.

Espero que este articulo te haya servido y que puedas recomendarlo a otros ingenieros que estén en el mundo de las pruebas de software. Y no te olvides de dejarme tu opinion uy tu experiencia en este campo.

También puedes acceder a mis cursos en los siguientes link:

También puedes suscribirte a mi canal de youtube, si aun no te has suscrito y ayudarme a seguir conectado contigo. Nos vemos en un próximo artículo.

Leave a Reply

Your email address will not be published. Required fields are marked *