¿Qué es SHIFT LEFT TESTING?

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 le pone foco a las ventajas que tiene moverlo a la izquierda, de hacer el 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.

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 en base a 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é hay que tomar la decisión de 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 antes por lo tanto se pueden resolver antes. 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 a Continuous Integration, 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 tranqulidad 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 temprano, 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 revisar 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.

Pensando en esto es que junto a BIOS armamos un curso de tester técnico, que está pensado en formar los profesionales que hoy la industria necesita para las tareas de calidad. De todos modos, hay cientos de cursos online en distintas academias, como nuestro curso de performance, así como cursos de todo precio y sabor (incluso gratis) en plataformas como Udemy o Coursera.

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 (al contrario de lo que suelen pensar muchos, de que el testing es aburrido).

El testing es aburrido si lo hacés de forma aburrida, tal como programar, diseñar, pintar, etc, pueden llegar a ser actividades aburridas. Todo depende de la forma en la que se haga.

Cerrando

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, y que estamos intentando ponerle foco dado que creemos en los resultados positivos que trae para el producto y para el equipo.

Vos, ¿qué pensás?