![\"\"](\"https:\/\/cl.abstracta.us\/wp-content\/uploads\/2023\/03\/scrum-estrategia-enfoque-shift-left-testing-qa-1024x682.jpg\")
\u00bfEs posible lograr los cometidos del Shift Left Testing con metodolog\u00edas tradicionales en proyectos de ingenier\u00eda de software?<\/strong> Antes que nada, quiero detenerme por un momento en el concepto de Shift Left, para lograr una comprensi\u00f3n cabal de la tem\u00e1tica.<\/p>\n\n\n\n Tal como explic\u00f3 Mat\u00edas Fornara en este art\u00edculo<\/a>, Shift Left Testing es el enfoque de expandir las actividades de testing hacia la izquierda del proceso de desarrollo, entendiendo el mismo como una l\u00ednea temporal. La etimolog\u00eda de esta idea proviene de que en metodolog\u00edas m\u00e1s tradicionales como waterfall, las actividades de calidad quedan m\u00e1s \u201ca la derecha\u201d, es decir, al final.<\/p>\n\n\n\n \u201cLa idea del Shift Left Testing es incluir actividades de calidad desde el principio, incluso desde que se planifican las funcionalidades, con el fin de mitigar riesgos y tener un mejor an\u00e1lisis de calidad en cada una de las etapas de este proceso<\/strong>\u201d, puntualiz\u00f3 Mat\u00edas.<\/p>\n\n\n\n Entonces, \u00bfes viable concretar estos objetivos con metodolog\u00edas tradicionales? Cuando se utilizan procesos diferentes a los que proponen las metodolog\u00edas \u00e1giles de hoy d\u00eda, los proyectos pueden durar meses y a veces a\u00f1os.<\/strong><\/p>\n\n\n\n Imaginemos por un momento un proyecto de 12 meses, con etapas secuenciales y en cascada. Aqu\u00ed las iteraciones se hacen en funci\u00f3n de la construcci\u00f3n de software en fases, tales como: relevar requerimientos, analizar, dise\u00f1ar, desarrollar, testear y poner en producci\u00f3n. Como resultado de esta filosof\u00eda de trabajo, posiblemente, el testing se comience a realizar reci\u00e9n en la fase n\u00famero 8 o incluso m\u00e1s tarde.<\/strong><\/p>\n\n\n\n En ese marco, a veces se encuentran grandes errores en fases de desarrollo avanzadas, bugs que podr\u00edan haberse evitado f\u00e1cilmente en etapas m\u00e1s tempranas. El efecto de esto se puede visualizar sin ser un experto en el tema: incremento del tiempo necesario para la entrega del producto, con sus consecuentes perjuicios econ\u00f3micos, insatisfacci\u00f3n del cliente y tambi\u00e9n del equipo de testing y desarrollo dado el agotamiento que puede provocar esta situaci\u00f3n.<\/strong><\/p>\n\n\n\n Entonces, cuando un equipo de ingenier\u00eda software cambia esa forma tradicional de desarrollar tecnolog\u00eda por una \u00e1gil, se genera un cambio muy importante, radical. Implica la existencia de un Shift Left Testing de hecho<\/strong>. \u00bfPor qu\u00e9? La respuesta es directa: el agilismo, y particularmente Scrum, permite trabajar en detalle para lograr consecuentes entregas de incrementos de valor, y mitigar as\u00ed una importante cantidad de riesgos.<\/strong><\/p>\n\n\n\n Para figurarlo, un sprint, que es el nombre que tiene la iteraci\u00f3n en el marco de trabajo Scrum, debe durar menos de un mes. Usualmente, dura dos semanas, en las cuales el equipo debe entregar software \u00fatil, funcionando. Para ello, en ese lapso, el equipo necesita aplicar todas las fases de construcci\u00f3n de software, incluido el testing.<\/p>\n\n\n\n Scrum es un framework, y como tal no garantiza el resultado del trabajo. Destaco esto porque me defino hoy d\u00eda como Agile Enabler: una persona que promueve que los equipos y las empresas \u201csean \u00e1giles\u201d en vez de que \u201cusen m\u00e9todos \u00e1giles\u201d.<\/p>\n\n\n\n En mi experiencia, sigo viendo que hay una gran oportunidad de mejora en aquellos proyectos donde se usa el framework de Scrum, pero no se ponen en pr\u00e1ctica los principios \u00e1giles, la mentalidad adecuada. Fundamentar\u00e9 lo anterior con base en un ejemplo concreto.<\/p>\n\n\n\n Un equipo puede utilizar Scrum, pero quedarse en el m\u00e9todo, es decir en los eventos, artefactos y roles. \u00bfQu\u00e9 implica esto? Que cuando tiene que generar acuerdos de trabajo de forma autoorganizada y enfoc\u00e1ndose en agregar valor de negocio en cada sprint, trabaja de una forma en que los desarrolladores escriben c\u00f3digo durante la mayor parte del sprint, para reci\u00e9n m\u00e1s adelante, probablemente los \u00faltimos d\u00edas del sprint, pas\u00e1rselos a los testers, para que ellos se encarguen en encontrar errores.<\/p>\n\n\n\n Esta situaci\u00f3n, en definitiva, conlleva seguir aplicando lo desarrollado de modo secuencial y en cascada, pero en un periodo de tiempo m\u00e1s corto.<\/p>\n\n\n\n Entonces: \u00bfScrum no resuelve esto? No. Absolutamente que no lo resuelve. Se necesita generar un equipo. Scrum no reconoce etiquetas de ning\u00fan tipo en los integrantes de un equipo Scrum. Por ello, cada una de las personas que lo integran deben ser responsables de construir relaciones de confianza, para luego ser \u201caccountable\u201d<\/em> del delivery de su trabajo.<\/p>\n\n\n\n No hay f\u00f3rmulas m\u00e1gicas, se precisa madurez profesional, poner en pr\u00e1ctica los 12 principios que est\u00e1n de <\/strong>Manifiesto \u00c1gil<\/strong><\/a>, y los 5 valores de Scrum: respeto, compromiso, apertura, foco y coraje.<\/strong><\/p>\n\n\n\n \u201cScrum se vincula desde el an\u00e1lisis e inclusi\u00f3n de validaciones de calidad en cada etapa. <\/strong>Muchas veces, esto se traduce en utilizaci\u00f3n de historias de usuario con criterios de aceptaci\u00f3n claros que permitan entender c\u00f3mo tiene que funcionar una funcionalidad o incremento de software y, por ende, c\u00f3mo debemos probarlo\u201d, esboz\u00f3 Mat\u00edas Fornara<\/strong>. \u201cOtro artefacto de Scrum que ayuda que las pr\u00e1ctias de shift-left permeen es el Definition of Done (DoD), es decir, que tiene que cumplir una tarea para ser considerada lista por mi equipo\u201d, continu\u00f3.<\/p>\n\n\n\n S\u00e9 que muchos estar\u00e1n buscando recetas para lograr estos objetivos y, aunque no exista una forma \u00fanica de realizarlo, a veces pueden ayudar. Una receta que les puedo dar es la siguiente:<\/strong><\/p>\n\n\n\n Es el momento en el cual un equipo Scrum debe entender qu\u00e9 valor aportar\u00e1 en el Sprint (Sprint Goal), qu\u00e9 \u00edtems del Product Backlog est\u00e1n asociados a ese valor, y c\u00f3mo el equipo que construye el producto va a organizar su trabajo para lograr ese Sprint Goal.<\/p>\n\n\n\n Con esto en mente, el equipo debe aprender a dise\u00f1ar la estrategia constructiva de cada \u00edtem que, haciendo una analog\u00eda con la elaboraci\u00f3n de una torta o pastel, en vez de elaborarla por capas debe aprender a hacerlo por rodajas, tajadas (slice). Cada trozo precisa contener relleno: capa superior, inferior, etc. Con esto en el radar, el equipo va a generar su plan de trabajo, llamado Sprint Backlog.<\/p>\n\n\n\n Aqu\u00ed existe la oportunidad de identificar si est\u00e1n \u201cconstruyendo\u201d ese pastel como planificaron. Si no lo est\u00e1n, deben corregir el plan, y ser cr\u00edticos acerca de si est\u00e1n generando \u201cporciones de pastel\u201d que pueda ser deleitado por alg\u00fan paladar.<\/p>\n\n\n\n Algunos aspectos a\u00fan m\u00e1s t\u00e1cticos que pueden ayudar a los equipos a poner en pr\u00e1ctica esto es que comiencen a dise\u00f1ar la soluci\u00f3n t\u00e9cnica en pares: un desarrollador y un tester, cada uno aportando su conocimiento, Adem\u00e1s de poder emplear conceptos como Test Driven Development (TDD), una t\u00e9cnica de dise\u00f1o que implica comenzar a desarrollar escribiendo primero el test unitario.<\/p>\n\n\n\n Quiz\u00e1s estar\u00e1n pensando si eso es eficaz y eficiente. Puedo asegurar que s\u00ed, lo es, ya que permite generar relaciones entre cada integrante. Por eso es importante el trabajo en pares. Antes de pedirle eficiencia a un equipo, es necesario construir un equipo.<\/p>\n\n\n\n Otra actividad que promueve Scrum en pos de acercar el testing al comienzo de la construcci\u00f3n se llama Backlog Refinement. No es un evento como el Sprint Planning, el equipo Scrum organiza dicha actividad pensando en como particionar los \u00edtems del Product Backlog para que en el Sprint siguiente est\u00e9n listos para ser planificados y accionados.<\/p>\n\n\n\n En otras palabras, identifican algunas porciones de la torta que son muy grandes, y buscan estrategia para dejarlas en un tama\u00f1o que el paladar pueda disfrutar.<\/p>\n\n\n\n Por \u00faltimo, el equipo puede centrar el Sprint Retrospective en generar nuevas hip\u00f3tesis de trabajo, en consideraci\u00f3n de ir hacia el \u201cShift Left Testing\u201d o, lo que ser\u00eda mejor a\u00fan, \u201cShift Left Relationship\u201d entre los integrantes de un equipo de ingenier\u00eda, sea cual sea su experticia.<\/p>\n\n\n\n \u00bfQu\u00e9 opinas al respecto? \u00bfCoincides en que Scrum trae oportunidades de mejora continua<\/a> para las actividades de prueba y QA? \u00a1Cu\u00e9ntanos en los comentarios!<\/p>\n\n\n\n S\u00edguenos en LinkedIn<\/a>, Twitter<\/a>, Facebook<\/a>, Instagram<\/a> y Youtube<\/a> para ser parte de nuestra comunidad, y enterarte de m\u00e1s novedades respecto a las mejores pr\u00e1cticas de Scrum y shift left testing.<\/p>\n\n\n\n \u00bfC\u00f3mo ayuda Scrum en tiempos de incertidumbre?<\/a><\/p>\n\n\n\n Scrum, un cambio de paradigma para el Testing de Software<\/a><\/p>\n\n\n\nScrum: oportunidades de mejora continua<\/strong><\/h2>\n\n\n\n
Scrum no lo resuelve, pero es un gran apoyo en ese camino<\/strong><\/h2>\n\n\n\n
Sprint Planning<\/strong><\/h2>\n\n\n\n
Daily Scrum<\/strong><\/h2>\n\n\n\n
Backlog Refinement<\/strong><\/h2>\n\n\n\n
Sprint Retrospective<\/strong><\/h2>\n\n\n\n
\n\n\n\n
\n\n\n\nOtros contenidos relacionados<\/h3>\n\n\n\n