Buscando la calidad de software en el camino y no en la meta (I)

Cada vez que terminamos, o que creemos que hemos terminado un desarrollo, sabemos que aun cuando e proceso de construcción ha sido duro, aún falta lo más duro. Pasar por QA. Todos los esfuerzos de esta área o persona calificada para desempañar este rol están dedicados a buscar “destruir” el software. Lo cual es un objetivo valido considerando que no importa cuántas veces se caiga el sistema,siempre y cuando sea antes de salir a producción. Pero, ¿realmente no importa cuántas veces? Dependiendo de la empresa, existen procedimientos e indicadores que deben cumplirse para buscar la menor cantidad de errores en esta etapa.

Para esto, en la etapa de construcción cada programador realiza sus pruebas unitarias, las cuales deben ser exhaustivas para poder conseguir el menor índice de error en el proceso del aseguramiento de calidad (QA).  En resumen, cuando tenemos un área de QA, el desarrollo tiene estas fases:

Ciclo de desarrollo tradicional
Ciclo de desarrollo tradicional

 

Como las pruebas unitarias son realizadas por el mismo desarrollador, siempre se sigue un ciclo (no tan ordenado, a decir verdad) entre el desarrollo y estas pruebas. La idea, es conseguir la menor cantidad de errores antes de integrar los entregables de cada desarrollador para luego pasar a QA. Lo que casi siempre pasa es que nos devuelven el software (duro pero cierto). Y tenemos que empezar a parchar el software o en el peor de los casos a empezar de nuevo. Pero ¿Cómo llegamos a esa situación? Las causas van desde requerimientos funcionales mal entendidos (o mal redactados), poca comunicación con el usuario o cliente para aclarar lógica de negocio, aportes personales (o suposiciones), mejoras no “documentadas” o “informadas”, hasta entorno de pruebas difiere del ambiente de desarrollo, etc.

Entonces, la pregunta cae por su propio peso, ¿Cómo evitamos el circulo vicioso de desarrolla, probar y volver a desarrollar que se repite una y otra vez? Para empezar, hay ciertos caminos que nos ayudaran a aplicar el mejor método de aseguramiento de calidad tanto en a nivel de líneas de código como de funcionalidad o expectativas del cliente.

Extreme Programing (XP): Creando el ambiente propicio para Test Driven development (TDD)

Tenemos los requerimientos, los cuales los podemos “romper” en historias de usuario (para XP las historias son el punto de partida). Estas historias bien redactadas permiten al programador tener una mejor idea de lo que se debe hacer y para el usuario es su mejor arma para poder probar el software. Los criterios de aceptación que van en las historias son los casos de prueba. No se necesita más.

Considerando los principios de XP, tenemos una pirámide de principios la cual tiene su base en la simplicidad. Simplicidad para tener el mínimo producto viable siempre, código redundante es el mal que aqueja a todos los sistemas. Con XP buscamos refactorizar en todo momento. La simplicidad también se necesitará para los siguientes componentes de la pirámide. Tener una comunicación clara, fluida y simple para poder entender las historias es vital para codificar lo estrictamente necesario y lo que genere valor.

Un principio que quizás no se entienda muy bien pero que considero muy importante para todo desarrollador es el del coraje o valentía. Esto significa que estar siempre dispuesto a: verificar el código, notificar si hay alguna mejora posible, y más aún para realizar el cambio que implique aumentar o quitar código (muchas veces nos cuesta desechar código). No muchos desarrolladores desean meterse en problemas (código) de otros. Atreverse a esto es parte del principio de coraje que necesita todo equipo para lograr un mejor software.

Después, tenemos que la retroalimentación llegará gracias a la comunicación fluida con el cliente, conseguiremos siempre la palabra del cliente guiándonos en el camino. Y, finalmente, en la cumbre de esta pirámide está el respeto. El cual nos permitirá al equipo, tener un sentido de consideración con los otros miembros. Muchos desarrolladores trabajan por su cuenta y agregan o quitan código sin verificarlo en equipo. El respeto es algo que conseguiremos con mucha comunicación en el equipo y mucha empatía.

 

Pirámide de Principios de XP
Pirámide de Principios de XP

Asimismo, es necesario aplicar ciertas prácticas que permitan facilitar el camino del desarrollo desde el planning hasta la entrega. Son 12 prácticas, pero aquí me enfocaré en 4 que considero las más importantes.

Propiedad colectiva: básicamente consiste en compartir el código entre todos los miembros del equipo. De tal forma que cualquier pueda tocar el código, de ser necesario. Obviamente bajo conocimiento de todo el equipo sin trasfredir el trabajo de otros.

Integración continua: consiste en no esperar a terminar todo el desarrollo para integrar los entregables y probarlos. Integrar continuamente permitirá reducir el tiempo de la fase de integración y más aún las pruebas ya que cada iteración integrada significa código completo y no partido.

Pair Programming: esto ayuda a la propiedad colectiva, ya que además de tener el código disponible para todos. Los cambios, las adiciones y las correcciones que puedan realizarse se hacen en parejas, mientras uno codifica, la visión del acompañante permite identificar errores imperceptibles y lógica mejorada.  Rotar e intercambiar parejas ayuda a que todo el equipo conozca de todo y reduce la dependencia de “héroes”.

Entregas pequeñas: con esto evitamos programar demasiado para rehacer el 50% o 60% en el peor de los casos. Necesitamos e feedback cada cierto tiempo para poder tener siempre la curva de cumplimiento lo más derecha posible.

Bueno, este post ha resultado muy extenso, por lo que continuaré en un siguiente post en el que entraremos ya con TDD y ATDD y como ayudan a la calidad de software.

Please follow and like us:
0

Leave a comment

Hey, so you decided to leave a comment! That's great. Just fill in the required fields and hit submit. Note that your comment will need to be reviewed before its published.