¿Qué es el enfoque shift left testing?

Conoce cómo este enfoque permite mejorar la calidad del producto final y reducir los riesgos, al descubrir y solucionar potenciales problemas de manera anticipada.

Se habla cada vez más de la idea de shift left testing, pero ¿qué es shift left testing? ¿A qué se refiere exactamente? En este post quiero contar un poco por qué nosotros en Abstracta también le estamos dando cada vez más peso en lo que hacemos día a día. Algunas ideas las tomé de lo que publicó hace un tiempo Sofía Palamarchuk en este post.

¿Qué significa Shift Left Testing?

Primero que nada, no, no se refiere a probar la tecla SHIFT del lado izquierdo del teclado, nada que ver.

Fuera de broma, y en pocas palabras, refiere a mover las actividades de testing más hacia la izquierda del proceso de desarrollo, viendo al mismo como una línea temporal.

Esto es más que nada porque el testing, especialmente en las metodologías waterfall, queda bien a la derecha, al final. La idea entonces, es anticipar, tener en cuenta al testing desde el principio.

En la siguiente imagen se ve dónde aparece el testing usualmente, luego de terminar de analizar los requerimientos, de diseñar el sistema y luego de codificar. Recién ahí aparece la fase o la etapa de pruebas.

La propuesta es mover el testing hacia la izquierda, y en realidad también hacia la derecha, incluyendo actividades de calidad en todo el proceso, pero en particular se pone foco en las ventajas que tiene moverlo hacia la izquierda, de hacer shift left testing.

En parte, esto se ve motivado o impulsado por el movimiento de las metodologías ágiles, el TDD y BDD, o alguna de sus variantes, con el rol de DevOps, y con el Continuous Integration. Incluso, se está hablando de dejar de lado el rol de QA (quality assurance, aseguramiento de la calidad) a QE (quality engineering, ingeniería de la calidad).

Este cambio de mentalidad realmente me gusta, ya que el equipo de testing no es una empresa de seguros, sino que realiza distintas actividades relacionadas a la calidad, claramente, con la finalidad de conocerla y así mejorarla.

Es más, el testing no es una fase que la realiza un equipo especializado y nada más, hay muchas tareas relacionadas, algunas las hará un desarrollador, otras un tester, otras alguien de operaciones, o algún analista de negocios, y todos seguramente se retroalimenten y mejoren sus resultados trabajando juntos.

A continuación detallo algunos ejemplos:

El desarrollador haciendo pruebas unitarias, y el tester colaborando haciendo revisiones de las mismas y aportando con ideas para mejorar la cobertura.
Automatizar pruebas en distintos niveles (recomiendo ver el post sobre la Pirámide de Cohn).
Considerar las distintas actividades de testing al momento de realizar el plan y estimación de esfuerzo. Pensar oportunamente cuáles son los atributos de calidad que son importantes para el producto que se está desarrollando (performance, robustez, seguridad, etc., —ver la relación entre los distintos factores de calidad y sus pruebas— y con base en eso planificar las actividades de pruebas necesarias para trabajarlos.
Realizar pruebas de performance de los componentes que se van realizando, no esperar a tener el sistema terminado para esto.
Lo mismo con las pruebas de seguridad, usabilidad, etc.

¿Por qué optar por un enfoque Shift Left Testing?

Se habla de varias ventajas bien claras: primero es que se apunta a reducir costos, ya que las pruebas se hacen antes, el feedback se obtiene antes, los potenciales problemas se descubren previamente, por lo tanto, se pueden resolver con antelación. Esto al final de cuentas hace que se mejore la calidad del producto final y que se reduzcan los riesgos.

Hay varios aspectos técnicos, todos los relacionados con integración continua, es decir, tener pequeñas pruebas y chequeos de distintos tipos, que se ejecutan en cada build. Estos chequeos hechos en distintos niveles hacen que se detecten las incidencias más temprano, y que en cierta forma se pueda trabajar con más tranquilidad que al menos lo que se está chequeando en forma automática no se está rompiendo.

Algo también interesante, es que poniéndole foco al testing anticipadamente, seguramente apoye a que se desarrollen componentes testeables, o sea, más fáciles de probar y de automatizar los distintos tipos de chequeos. Esto es de gran valor, a corto y largo plazo, y también contribuye a mejorar la calidad y reducir los costos.

Pero, por otra parte, hay varias ventajas respecto a la forma de funcionar del equipo. El testing independiente tiene sus ventajas, pero muchas veces se cae en algunas malas prácticas, o malas dinámicas entre equipos que no se sienten parte del mismo propósito. Entonces, he visto que sucede que se desarrolla con menos cuidado, ya que total, lo va a revisar el equipo de testing. En cambio, si se comparten las tareas, si se fomenta la colaboración y se distribuye la responsabilidad, hay más chance de éxito. Claro que esto implica un cambio cultural, que tiene sus desafíos.

Soy tester, ¿cómo me afecta este enfoque?

Soy de los que dice que pueden existir testers muy buenos sin que tengan que tener conocimientos de programación. Con este enfoque de shift left testing, creo que toma más importancia que el tester se involucre en actividades como el desarrollo, para poder verificar una prueba unitaria y aportar valor, para poder automatizar un chequeo sobre una API REST, o analizar el resultado de una prueba de performance, correlacionando datos de la monitorización de los servidores.

Otro aspecto a resaltar, es que todo esto nos hace a los testers más partícipes en distintas etapas del proyecto, variando más aún lo que hacemos, teniendo que aprender más cosas, haciendo que nuestra tarea sea más entretenida aún.

Shift left testing no es solo un lindo slogan para una camiseta

Es un enfoque que si bien no es nuevo, es algo que no siempre se tiene en cuenta.

Estamos intentando ponerle foco, dado que creemos en los resultados positivos que trae para el producto y para el equipo.

¡Síguenos en Linkedin, Twitter, Instagram y Facebook para ser parte de nuestra comunidad y estar al tanto de otras buenas prácticas de desarrollo de software!