Mis esperanzas para Testing en 2018…

¿Son las pruebas automatizadas el futuro de testing? La respuesta es no.

Advertisements

 

por Steve Watson

 

Es el uno de enero de 2018, y a las 3 pm la lluvia y las nubes grises empiezan a irse, el cielo azul y unos rayos de sol están apareciendo. Es un pequeño rayo de esperanza en un día gris que me ayuda a pensar en el futuro, y a imaginar donde estaremos como industria en un año.

¿Qué habremos aprendido? ¿Qué haremos diferente? ¿Qué nuevas habilidades y estrategias habremos adoptado? ¿Cómo habrán evolucionado nuestros trabajos?

 

¿Cuál es mi esperanza para la industria de testing este año? Después de considerarlo mucho, pude enfocar mi obsesión en un solo término, en un solo aspecto de las técnicas de testing: “automatización”.

Han habido muchos debates y creo honestamente que es momento de avanzar, es una distracción innecesaria que no nos permite enfocarnos en otros temas que deberíamos estar discutiendo.

Citaré a James Bach: “El problema con “Testing Automatizado” empieza con las mismas palabras. Testing es parte del trabajo creativo y crítico que sucede en la sala de juntas, pero “automatizar” alienta a la gente a creer en un modelo de línea de ensamblaje que se hace en una planta.”

 

Testing es un oficio. Es algo que requiere pensar. Requiere tener la habilidad para identificar que necesita ser probado y como será probado.

Automatizar sólo es “el cómo”, eso está bien, pero enfocándonos mucho en “el como”, parecemos obviar mucho la importancia de “el qué”.

Varios comentarios en LinkedIn, hechos por profesionistas en testing, han sugerido que esto demerita el oficio, y estoy de acuerdo. Cualquiera que no sea tester o no tenga experiencia en testing, tal vez un gerente que lleve control de presupuestos, podría ver las actividades de testing, y asumir que automatización es básicamente codificar algunas pruebas. Ésto no nos ayuda a mostrar los procesos de análisis por los que pasamos para identificar que necesita ser probado, como análisis basados en riesgos, pruebas exploratorias, recorridos de historias y nuestra propia experiencia para planear como romper algo que ni siquiera ha sido construido.

 

Pruebas automáticas se ve muy bien en el papel, ¿Quién no quiere ahorrar tiempo y deshacerse del aburrido trabajo repetitivo?. Es algo muy sencillo de vender, y en teoría, si podemos automatizar un montón de pruebas repetibles tendremos mucho tiempo para hacer cualquier otra cosa. Sin embargo, este no es siempre el caso. Y es que si sólo discutimos sobre automatizar las pruebas, los gerentes, o cualquier persona encargada de tomar decisiones, no podrá ver todas las otras pruebas que necesitan ser agregadas a la ecuación, sin mencionar que ese montón de pruebas automatizadas necesitarán mantenimiento cada que haya cambios o actualizaciones en el producto o aplicación que se esté desarrollando.

Vamos a suponer que estamos probando una página web. Los testers hacen unas pruebas manuales y luego empiezan a escribir unas pruebas automatizadas para cubrir los escenarios encontrados. A menos que otra cosa suceda, el equipo podría asumir que el trabajo está hecho, tenemos pruebas repetibles, así que vayamos a otra cosa. Pero esa automatización de la que tanto se habla sólo está cubriendo UNA PARTE de lo que necesita ser probado: “Regresión”.

Por ejemplo, ¿Qué hay de las pruebas de carga y desempeño? ¿Cuándo entrarían? Hace falta otra herramienta para crear pruebas de carga, pero también es necesario el pensamiento crítico para establecer si los puntos de referencia para el desempeño serán de un usuario, de diez, de cien, de mil, etc. Y luego tiene que venir el entendimiento de como se escalarán esas pruebas de carga, ¿se repetirán los mismos escenarios o trataremos de imitar el comportamiento del usuario? La ejecución es la última parte de un largo proceso de análisis.

 

Y ni siquiera he hablado de los beneficios de las pruebas exploratorias. Las pruebas automatizadas no pueden detenerse en un momento dado de la ejecución y hacer algo diferente(al momento por lo menos), a observar los detalles de la página, a leer el contenido, sin embargo, hoy por hoy, las pruebas automatizadas checan lo mismo una y otra vez.

 

DE ESO NO SE TRATA TESTING.

 

Lo volveré a repetir: “Testing se trata de análizar, investigar, en definir los riesgos, en planear que es lo que vamos a hacer, en buscar cosas que se le hayan escapado a quien haya hecho los requerimientos, algo que nunca haya considerado que pudiera pasar” Después de todo eso, viene “el cómo”, el definir como será la mejor manera de ejecutar esas pruebas, ya sea usando el teclado para navegar en una aplicación web o escribiendo pruebas automatizadas que realicen actividades repetibles por nosotros.

 

Mi deseo para 2018 es que dejemos de hacerle creer a los demás que testing sólo se trata de automatización. No lo es. Somos más que programadores de pruebas, hagamos que nuestro trabajo se trate de añadir valor real a nuestras organizaciones.

 

SOMOS PENSADORES CRÍTICOS, SINTAMONOS ORGULLOSOS DE ELLO.

 

¡Feliz año nuevo!

 

https://stevethedoc.wordpress.com/2018/01/01/my-hope-for-testing-in-2018/

Steve Watson, 01/01/2018

Author: RobotSQT

Soy el robot que mantiene el blog de SQT.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s