Asegurando la Calidad… estás seguro?

Hace un tiempo, mientras revisaba/corregía las observaciones que el equipo de control de calidad hacia, una de las personas del equipo “contrario” (por así decirlo) fue parte de uno de los diálogos mas interesantes por esos días.
Líneas abajo, un resumen:
– QA: Si, está bien, ahora está todo mas rápido.
– Yo: Y cómo lo determinas?
– QA: Bueno, es lo que parece, no?
– Yo: …
– Yo: Estás seguro?
– QA: (sonrisa) ya bueno, con mi reloj.

dialogo

Por esas fechas una de las observaciones mas importantes tenían que ver con la performance de la aplicación, a lo cual procedimos a ejecutar diversas pruebas, muchas de estas bajo automatización realizada con programas que habíamos construido, mientras que por otro lado, usábamos herramientas que en base a reportes, nos aseguraba, o al menos nos daba una idea del consumo de recursos, administración de memoria, tiempos de respuesta, etc.

Mientras transcurría el proyecto, se resolvían las observaciones y éramos testigos de como el producto comenzaba a integrarse con cada aplicación, por mi parte confirmaba (y lamentaba) una vez más la pobre percepción que tienen muchos profesionales sobre el Aseguramiento de Calidad.
El problema se hace mayor si es que nos damos cuenta de que esta falencia también está sentada en las empresas, no solo en algunos trabajadores, sino en los jefes! 

Lo que pasa es que muchos piensan, creen o aseguran, que asegurar la calidad se determina por la menor cantidad de errores que salgan al probar la aplicación luego de programar un módulo, funcionalidad o peor aun… al terminar de programar todo!

Error!

Asegurar la calidad tiene que ver con:
– Asegurar
– la
– Calidad.

Nada mas que eso!
(no, no estoy bromeando)

Y cómo logras algo tan simple?
Pues primero, tenemos que detenernos un momento y determinar cuales son nuestros estándares mínimos para definir un producto de calidad.
Tranquilidad ante esto, ya que muchas veces estos aspectos ya están definidos por las gerencias de alto nivel.
Lo que se debe hacerse es conversar con el equipo (una vez mas, la comunicación saliendo a flote) sobre estos aspectos ya definidos y ver/encontrar/definir/decidir de que manera se hará un trabajo acorde a esto.

Pero decidir una forma de trabajo que vaya de acuerdo a la idea de los estándares de calidad de la compañía es mucho menos del 50% de lo que tienes que hacer para asegurar la calidad de tus desarrollos.

Debemos en primera instancia mantener un respeto al trabajo de las demás personas, por eso:
– Si alguien usará la librería que estas creando, pues, simula su uso antes de entregarla. Ante esto, la primera palabra clave es: pruebas unitarias, aunque claro, hay mas conceptos, pero al menos ese, no?
– Si ya vas a entregar tu módulo/funcionalidad, realiza algunas pruebas en base a lo especificado funcionalmente y acordado con tu Analista de Pruebas.
– No puedes aducir que no tienes tiempo y que esa ya no es tu tarea, pues tu tarea en realidad es entregar algo que funciona, recuerda, es prácticamente el valor de tu palabra y del compromiso que tienes con el proyecto.
– El Analista de Pruebas tiene como una de sus actividades principales, confirmar las funcionalidades especificadas, no tanto así, como verificar si es que algo está correctamente compilado, desplegado, escrito, diseñado visualmente.
– Escrito: es decir, ortográfica y gramaticalmente hablando, es que acaso ser ingenieros informáticos nos da opción a no saber escribir?
– Diseño Visual: esto es dependiendo del caso, pero si vienes con la mentalidad del “ya luego vemos como le arreglamos el diseño” pues, créeme, estas comenzando mal.
– Lo mencionaré en otros términos, el trabajo del Analista de Pruebas, no es ver si lo que has publicado está listo para probar. Su trabajo es confirmar si está listo para ser publicado.

Si bien es cierto, hasta este momento muchas de estas anotaciones parecen obvias o difíciles de considerar por la naturaleza de nuestro mercado, pero la verdad es que aun no hemos terminado de hablar al respecto.

Pues, queda determinar algo bien claro:
Asegurar la calidad una aplicación no es probar la aplicación.

bug-feature
Cómo es eso?
Independientemente del modelo de trabajo que se esté siguiendo, debemos tener en mente y aceptar que el aseguramiento es constante, que si hablamos de fases, microfases, iteraciones, etc. pues lo que se debe considerar siempre es que todo artefacto debe pasar por un proceso de certificación realizado por un tercero ajeno de manera directa a lo liberado, que asegure que lo se va a liberado:
– Que funcione, si es un módulo.
– Se entienda, si es un documento, procedimiento, proceso
Sea claro, que no requiera explicación
– Responda a los flujos ideales y casos ideales.
– Soporte casos complejos, si es que ya es una versión superior.
Que tenga sustento, sea técnico, funcional o ambos, lo realizado debe tener sustento! no solo se trata de un “así me pareció” o “es que lo otro no me gusta”.

Como podrán notar asegurar la calidad de un producto, desde el punto de vista de construcción de software (tema del cual espero hablar en alguna oportunidad), no tiene mucho que ver con pensar en el producto como un todo, sino en un esquema integral en el cual, cada componente está completamente ligado con la siguiente versión del mismo y del producto en si. 

No podemos olvidarnos de las personas involucradas en la construcción, liberación y certificación de cada artefacto, teniendo muy en cuenta que cada uno no puedo ser juez y parte del trabajo que viene haciendo, que además de nuestro trabajo, está en juego nuestra palabra y el respeto a las demás personas que usarán lo que vayamos liberando (dentro y fuera del proyecto).

measurement-of-code-quality

Y lo mas importante, asegurar la calidad de un producto, no es probar el producto, y mucho menos a ultima hora!

Saludos
@Jersson

Leave a Reply

Your email address will not be published. Required fields are marked *