{"id":6736,"date":"2019-09-30T19:30:00","date_gmt":"2019-09-30T22:30:00","guid":{"rendered":"http:\/\/cl.abstracta.us\/blog\/?p=6736"},"modified":"2024-02-15T17:39:58","modified_gmt":"2024-02-15T20:39:58","slug":"shift-left-testing","status":"publish","type":"post","link":"https:\/\/es.abstracta.us\/blog\/shift-left-testing\/","title":{"rendered":"\u00bfQu\u00e9 es el enfoque shift left testing?"},"content":{"rendered":"\n

Conoce c\u00f3mo este enfoque permite mejorar la calidad del producto final y reducir los riesgos, al descubrir y solucionar potenciales problemas de manera anticipada.<\/strong><\/h3>\n\n\n\n

Se habla cada vez m\u00e1s de la idea de shift left testing, pero \u00bfqu\u00e9 es shift left testing? \u00bfA qu\u00e9 se refiere exactamente? En este post quiero contar un poco por qu\u00e9 nosotros en Abstracta tambi\u00e9n le estamos dando cada vez m\u00e1s peso en lo que hacemos d\u00eda a d\u00eda. Algunas ideas las tom\u00e9 de lo que public\u00f3 hace un tiempo Sof\u00eda Palamarchuk en este post<\/a>.<\/p>\n\n\n\n

\u00bfQu\u00e9 significa Shift Left Testing?<\/h2>\n\n\n
\n
\"\"<\/figure><\/div>\n\n\n

Primero que nada, no, no se refiere a probar la tecla SHIFT del lado izquierdo del teclado, nada que ver.<\/p>\n\n\n\n

Fuera de broma, y en pocas palabras, refiere a mover las actividades de testing m\u00e1s hacia la izquierda del proceso de desarrollo, viendo al mismo como una l\u00ednea temporal.<\/p>\n\n\n\n

Esto es m\u00e1s que nada porque el testing, especialmente en las metodolog\u00edas waterfall<\/em>, queda bien a la derecha, al final. La idea entonces, es anticipar, tener en cuenta al testing desde el principio.<\/p>\n\n\n\n

En la siguiente imagen se ve d\u00f3nde aparece el testing usualmente, luego de terminar de analizar los requerimientos, de dise\u00f1ar el sistema y luego de codificar. Reci\u00e9n ah\u00ed aparece la fase o la etapa de pruebas.<\/p>\n\n\n

\n
\"\"<\/figure><\/div>\n\n\n

La propuesta es mover el testing hacia la izquierda, y en realidad tambi\u00e9n 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.<\/p>\n\n\n\n

En parte, esto se ve motivado o impulsado por el movimiento de las metodolog\u00edas \u00e1giles, el TDD y BDD, o alguna de sus variantes, con el rol de DevOps, y con el Continuous Integration<\/strong>. Incluso, se est\u00e1 hablando de dejar de lado el rol de QA (quality assurance<\/em>, aseguramiento de la calidad) a QE<\/a> (quality engineering, ingenier\u00eda de la calidad).<\/p>\n\n\n\n

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\u00ed mejorarla.<\/p>\n\n\n\n

Es m\u00e1s, el testing no es una fase que la realiza un equipo especializado y nada m\u00e1s, hay muchas tareas relacionadas, algunas las har\u00e1 un desarrollador, otras un tester, otras alguien de operaciones, o alg\u00fan analista de negocios, y todos seguramente se retroalimenten y mejoren sus resultados trabajando juntos.<\/strong><\/p>\n\n\n\n

A continuaci\u00f3n detallo algunos ejemplos:<\/p>\n\n\n\n