¡El código es un desastre! ¿qué hago?

Vives, respiras y resuelves incidencias mas de 8 horas, cinco o incluso más días por la semana. El código es ya tan difícil de cambiar que un simple cambio hecho un Viernes por la tarde genera consecuencias impredecibles que podrian arruinarte inesperadamente  esa parrillada que planeaste con tus amigos del colegio un sábado.

Te encuentras con código heredado (legacy code):

  • Cuando ignoras la excelencia técnica y el buen diseño y te encuentras con “patrones de diseño” inexistentes que mas bien parecen “patrones del mal”.
  • Cuando no hay cultura de simplicidad. Esta palabra ni siquiera es parte del léxico de tu equipo, el código parece la ciudad de un municipio dejado por un alcalde que no salió reelegido (lleno de basura)
  • Cuando las arquitecturas, requisitos y diseños emergen de:
    1. sistemas de trabajo que se apoyan en esfuerzos individuales sometidos a presión
    2. equipos que no siguieron estándares de desarrollo consistentes
    3. individuos que no tuvieron  idea de lo que estaban haciendo (falta de experiencia o conocimiento)

Te encuentras con código que parece la mesa de una fiestita infantil a las 6 de la tarde. Quieres mejorar los módulos mas críticos pero con la seguridad que no vas a romper la lógica que sabes que mientras se siga apagando incendios funcionará y sostendrá a duras penas porque piensas que tu equipo es “lo que hay” y Dios es grande y tu seguirás alli mientras no tengas otra opción.

¿Que podemos hacer al respecto? Has escuchado de la automatización de pruebas y pruebas ágiles que soportan el desarrollo pero no tienes idea cómo utilizar estos conceptos, total dices QA no es mi chamba. Dependiendo del proyecto, riesgos,  metas del cliente y recursos disponibles se decidirá en los tipos de pruebas. Pero vayamos por partes, Brian Marick hace cuatro clasificaciones generales para pruebas de la siguiente manera:

1) Las prueba con orientación al negocio: emergen de manera natural en una conversación entre una persona del negocio y un miembro del equipo, ejemplo: “si no pagas tu recibo de teléfono en dos días te enviamos una notificación como recordatorio”

2) Las pruebas orientadas a la tecnologia: salen directamente del contexto de los programadores y podría ser “probar que el código JavaScript del módulo de pago funcione en todos los Browsers”

3) Las pruebas que soportan al desarrollo: se refiere a a pruebas que se usan como parte inherente de la programación a medida que se va desarrollando el producto.

Como indica Lisa Crispin y Janet Gregory en su libro “Agile Testing” este concepto de pruebas para ayudar a los programadores a desarrollar el producto es nuevo para muchos testers y establece la gran diferencia entre QA en un proyecto tradicional y un proyecto ágil.

Estas pruebas se automatizan y corren cada vez que se hace un check-in del código dándole al equipo un feedback constante e inmediato de la calidad de su código.

Se relacionan a la especificación de los requerimientos y soporte para el diseño del producto en lugar de lo que típicamente conocemos como “pruebas”. Estas pruebas son el fundamento de un equipo ágil, que una vez automatizadas proveen una defensa para cuando se hace refactoring y se introduce nuevo código que pueda romper la logica.

4) Las pruebas que critican el producto: implica revisar la aplicación de manera constructiva con el objetivo de aprender cómo podríamos mejorarla, a medida que aprendemos podremos sugerir requerimientos, pruebas o ejemplos de vuelta al proceso que soporta al equipo y guia el proceso de desarrollo.

Veamos los cuadrantes de testing:

 

Lean Testing

Lean Testing

 

Q1
– Definen calidad interna del código
– Este cuadrante representa “Test Driven Development” (pruebas antes de escribir código) o Unit Testing automatizado (pruebas despúes de escribir código) que verifican funcionalidad de pequeñas secciones funcionales del sistema como objetos y métodos
– Pruebas de componentes/integración: Verifican el comportamiento de secciones mas grandes en el sistema tales como un grupo de clases que provee algun tipo de servicio.

Q2
– Soprtan al equipo de desarrollo un nivel mas alto.
– Definen calidad externa o el comportamiento esperado del sistema (validan conformidad con requerimientos)
– Escritas en el lenguaje del negocio
– Especificaciones guiadas por ejemplos (ejecutables)

Q3
– Un nivel de pruebas adicional que valida que se está entregando lo que el cliente necesita
– Emula escenarios complejos a traves del testing exploratorio validando situaciones humanas
– Guiado por intuición y alineado a experiencia de usuario para verificar el valor entregado
– Los bugs mas serios se encuentran con este tipo de testing

Q4
– Este tipo de testing puede hacerse a nivel de historias de usuario como parte de requerimientos no funcionales o un conjunto de funcionalidad de valor
– Se critican características como performance, robustes y seguridad
– Requiere uso de herramientas especializadas y expertise adicional
– Podrian ser cruciales para el éxito/fracaso de la aplicación

Las pruebas podrian iniciarse por ejemplo a partir del cuadrantre Q2 escribiendo historias de usuario como pruebas ejecutables, pero al fin de cuentas la idea es probar y experimentar en los diferentes cuadrantes. Lo mejor es utilizar los cuadrantes para asegurar que las pruebas necesarias se hacen en el momento correcto proveyendo suficiente cobertura.

Lo recomendable para trabajar con código heredado es planear cuidadosamente y construir un arnés de pruebas automatizadas de caja negra (Q1) que nos generen un balance entre cobertura y confianza para comenzar a refactorizar el código de a pequeños pasos.

Si estamos utlizando un método como Kanban por ejemplo lo recomendable será ir incluyendo las estrategias de pruebas como políticas en cada fase del proceso de desarrollo de manera evolutiva a media que el equipo va a adquiriendo habilidades y competencias. Lo mismo podríamos hacer con Scrum como parte de las definición de políticas de terminado a nivel de historia de usuario, sprint o incluso release.

Finalemente QA no es solamente el trabajo de las personas encargadas de aseguramiento de calidad, bajo este enfoque QA es responsabilidad de todo el equipo utilizando las estrategias adecuadas de testing y soporte automatizado dependiendo de las circunstancias.

Comparte...Tweet about this on TwitterShare on LinkedInShare on FacebookShare on Google+
Manuel Mazán

Manuel Mazán

Fundador de Agiland en el 2010 y Consultor internacional en Metodologías Ágiles e innovación. 20 años de experiencia internacional trabajando en Perú, España, Irlanda y UK. Pionero aplicando el método Lean Kanban en Perú. Manuel ha llevado a cabo transformaciones ágiles exitosas a nivel de equipo y a escala. En el 2015 lideró la transformación ágil de la banca digital en BBVA Continental. Ingeniero de Sistemas (Cum Laude) Universidad de Lima. MBA Ulster University (UK). Certified Scrum Master (CSM), Certified Scrum Professional (CSP), Scaled Agile Framework (SAFe) Program Consultant, Facilitador Management 3.0 y PNL Practitioner. Expositor internacional Lean Kanban Southern Europe 2012 España, Ágiles 2012 Argentina, Ágiles 2013 Perú,Ágiles 2014 Colombia y ScrumDay Perú.
Manuel Mazán
Tagged with: , , ,
Posted in Blog
  • fredy yasuda

    Muy interesante!

Enviamos a tu inbox noticias y te mantenemos al tanto con lo mejor de nuestro
BLOG

¡Al suscribirte te daremos acceso inmediato a un caso de estudio tipo "White Paper" y un cupón GRATIS a un curso online!

Leénos en FB !

Algunos testimonios de nuestros cursos

Manuel, tiene la facilidad de simplificar los conceptos y pone en práctica lo enseñado de una manera ágil y amena. El entrenamiento logrado ha sido excelente para poder aplicar las metodologías ágiles en los proyectos de desarrollo de software
Carlos PeraltaGestión de Proyectos Lean-Agile
Uno de los mejores cursos de metodologías ágiles que he llevado a lo largo de mi carrera profesional, la metodología didáctica y el conocimiento profundo de la materia hace de este curso sea uno de los mas recomendables en su linea.
César Garrido LeccaTaller de Incepción al Framework Ágil Scrum
Aprendizaje con casos y dinámicas, perfecto! Usa la experiencia para asimilar conceptos
Jose Luis SánchezTaller de Incepción al Framework Ágil Scrum
Este curso me ayudo a entender los diversos conceptos relacionados con el mundo LEAN y me ayudó a darme cuenta que en el proceso actual de desarrollo de software de mi empresa se estaban cometiendo muchas ineficiencias que no generaban valor al producto final. Definitivamente este curso es 100% recomendable.        
Marco CarranzaGestión de Proyectos exitosa con Lean Software Development
Curso muy Dinámico. El instructor sabe llegar a los alumnos. Casos prácticos que ayudan a entender los conceptos
Kristel NuñezTaller de Incepción al Framework Ágil Scrum
Curso que explica de manera clara las bases fundamentales para llevar acabo un proyecto de software de manera exitosa, ideal para aquellos que nos encontramos inmersos dentro de la gerencia de proyectos. Este curso toca temas y problemas reales con los que uno tropieza al liderar proyectos de este tipo. Buen curso.        
Christian DelgadoPrincipios para entender y aplicar Agile, Scrum, XP y Kanban
El contenido del curso y la exposición de los temas es muy bueno, cumple con las expectativas del mismo y aporta valiosa información al respecto del tema principal del mismo. Adecuado para aplicar en casos del día a día. Recomendado!        
Hernando RondónPrincipios para entender y aplicar Agile, Scrum, XP y Kanban
Este es un curso sencillo, claro de entender y muy preciso. Mis expectativas fueron cubiertas en un 100%. Lo recomiendo ampliamente para aquellos que (como yo) se encuentran en proceso de implementar este tipo de metodologías para mejorar su trabajo día con día.        
Jesús V.Principios para entender y aplicar Agile, Scrum, XP y Kanban
Un curso obligado para comenzar a entender estos conceptos. Muy bien explicado. Me resulta difícil dar una reseña completa del curso porque se presentan varios conceptos nuevos para mi y además se emparejan con conceptos de manufactura, en definitiva debo leer el libro que recomienda al final del curso. La valoración tan alta la doy porque el instructor tiene una excelente fluidez al explicar los puntos tratados y un dominio en los temas que mantiene toda mi atención y crea mayor interés p…
Felipe De Jesús Piña Gestión de Proyectos exitosa con Lean Software Development
Manuel se caracteriza por tener buenos conocimientos en temas de Lean – Agile, los cuales fueron de mucha ayuda para el buen desenvolvimiento del curso, y para ampliar lo ya aprendido, provee buenas dinámicas para poner en practica lo aprendido, comparte conocimientos y consejos, ampliamente recomendado        
Enmanuel MestanzaGestión de Proyectos Lean-Agile