En el testing como en la medicina

Asistiendo a un debate sobre calidad del software, oí decir que el testing no es sexy. Ciertamente, no hay batas blancas como en la medicina o luces de neón como en las discotecas. Pero la conclusión acaba siendo que, al igual que con los médicos, casi nadie puede librarse de tener una relación continua con los ingenieros de pruebas. La excepción a la necesidad son aquellas típicas frases que intentan evitar dicha necesidad: “mejor no me miro, porque siempre me encuentran algo” o “prefiero vivir en la ignorancia y si me viene algo, ya me daré cuenta” (quizás demasiado tarde).

He aquí la palabra clave: riesgos. En la medicina, como en el testing, chequear la calidad de forma continua y fomentando la detección precoz no es un trámite, ni una opcionalidad, sino una necesidad para evitar riesgos graves, con posibles consecuencias irremediables.

No me imagino un debate cuestionándonos la necesidad de la medicina. Quizás porque el ser humano, desde sus orígenes, ha tratado de explicarse el porqué de sus males y cómo hacerles frente para estar mejor y evitarse problemas. Primero, con un marcado carácter “mágico” o religioso (muy propio también de la informática), pero después con un enfoque pragmático, más resolutivo y científico, basado en las pruebas y la exploración para el análisis, la diagnosis y las medidas correctivas o paliativas. El organismo humano lleva tiempo de ventaja a los sistemas de información, pero ambos requieren un proceso de análisis, diagnosis y corrección continua para estar mejor. ¿Uno puede quedarse tranquilo sin ir al médico mientras siente que podría hacer algo más para evitar males mayores o inesperados? Esta es la misma sensación que deberíamos tener cuando valoremos la necesidad de realizar pruebas de software.

La necesidad de invertir en actividades de testing y tener perfiles especializados en calidad del software es una inversión. La misma inversión que uno realiza cuando contrata un seguro médico, cuando invierte tiempo en visitarse o realizarse pruebas… No lo hacemos por gusto normalmente. Pero sienta bien tener la evidencia de que estamos bien, si lo estamos. Y es imprescindible contar con un acompañamiento médico si tenemos la evidencia de que algo va mal para corregirlo a tiempo.

¿Cuáles deben ser pues, los principios del testing que justifican su necesidad en los proyectos de software?

• Chequeos continuos: Cada vez es más importante concebir el testing como una actividad continua, no como una simple validación final (seria como esperar a viejo para ir a hacerse un chequeo). El testing continuo ha adquirido especial importancia en un contexto de evoluciones continuadas de las aplicaciones y desarrollo de múltiples aplicaciones, que requieren “quality gates” (puntos de validación) frecuentes.
• Agilidad en el diagnóstico y detección precoz: La reducción del time-to-market implica la necesidad de mecanismos cada vez más ágiles para el testing. De hecho, se trata de tener pruebas rápidas (como los despachos de filtraje de urgencias) y otros niveles de prueba más intensivos. Asimismo, es necesario aprovechar al máximo el conocimiento ya existente por parte de otros roles (especificado, por ejemplo, en historias de usuario) para un diseño más eficiente (o incluso automático) de los casos de prueba.
• Metodología y recetas: La metodología usada en un proyecto condiciona la calidad y facilita o complica los procesos de pruebas y aseguramiento de la calidad. Por ello es importante definir bien la estrategia organizativa y la metodología de soporte. Existen metodologías con componentes diversos, pero es necesario que se seleccionen los componentes adecuados y en la medida adecuada (receta) para cada proyecto.
• Colaboración: En contextos cada vez más ágiles, es necesario romper los tradicionales silos para adoptar aproximaciones DevOps. Igual que en la medicina, es imprescindible la colaboración entre profesionales y entre estos y los pacientes/clientes. Por ejemplo, de nada sirve investigar las causas de un desmayo sin la colaboración entre almenos un neurólogo y un cardiólogo que se crucen información y unan esfuerzos, y tampoco sirve de mucho sin la colaboración del propio paciente. En el software, pasa lo mismo entre distintos roles (negocio, desarrollo, testing, operaciones, etc.) y por esto es necesario definir (y también explicitar) los procesos, las responsabilidades y los mecanismos de seguimiento y comunicación. Una estrategia de gestión de la documentación es necesaria para dar soporte a una colaboración efectiva.
• Automatización: Las tareas repetitivas (como por ejemplo las pruebas de regresión) deben poder ser automatizadas, evaluando siempre el coste de mantenimiento de la automatización.
• Seguridad y datos: La disponibilidad de datos, su tratamiento seguro y la legalidad entorno a su gestión son aspectos esenciales tanto para la ejecución de los casos de prueba como para la gestión de su información asociada.
• Especialización: Dado que existen distintos tipos de prueba (funcionales, seguridad, performance, etc.) y que se requiere una estrategia de pruebas (no se puede probar todo por fuerza bruta), una definición de las mismas, unos criterios de cobertura,… es necesario disponer de perfiles especializados.
• Reacción: Ante los defectos y mejoras encontradas es importante que se activen cadenas correctivas que mejoren la calidad. En caso de que esto no suceda, el testing pasaría a ser un trámite para el cual no hay reacción, como cuando en el ámbito médico se obvian los informes, los resultados de las pruebas y las prescripciones médicas. Los resultados si sucede esto nos los podemos imaginar, a menos que haya suerte…

En definitiva: en el testing….como en la medicina.

Si necesitas información sobre los servicios en Testing y Calidad de Software de SOGETI, puedes consultar nuestra página web.