Calidad no es Testing, ni Procesos ni Certificaciones

Quienes intentamos construir software y dar servicios perceptibles como de calidad por el cliente, nos preguntamos continuamente si debemos efectuar más pruebas, buscar nuevos procesos y certificaciones. Si bien estos conceptos sí tienen relación a la calidad, por sí solos no son suficientes para determinarla.

Tomemos dos visiones típicas, y distintas, de la calidad:

Calidad es conformidad a requerimientos (parte de los postulados de P. Crosby)

Calidad es valor para alguna persona (G. Weinberg)

Ambas la definen, pero en forma diferente. La primera es la visión ingenieril, la segunda está relacionada con la experiencia del usuario.

Elaboremos un poco más sobre los conceptos de testing, procesos y certificaciones mencionados al comienzo.

• El testing nos permite validar si un producto cumple o no un requerimiento funcional y otros atributos de calidad definidos para él.
• Los procesos nos indican cuál es la forma recomendada para realizar una actividad o conjunto de ellas.
• Las certificaciones nos permiten demostrar el conocimiento y aplicación de mejores prácticas.

Todo lo mencionado concuerda bien con la visión ingenieril de la calidad. Sin embargo, de acuerdo a la segunda definición, para el cliente un producto o servicio se considerará de calidad, si cumple con sus expectativas. Y estará dispuesto a “pagar” por ello, en el sentido más amplio, si esto ocurre.

El cliente espera que nuestro producto/servicio cumpla con los requerimientos y lo haga en forma correcta, pero eso es sólo parte de sus expectativas y en general lo asume como lo mínimo necesario, asignando un valor relativo a dicho cumplimiento. Es como esperar que un reloj nos dé la hora correcta, parece obvio que lo hará. Cumplir las expectativas entonces implica mucho más que lograr conformidad con un requerimiento funcional o no funcional.

Ahora bien, ¿qué significa en la práctica traspasar el límite de lo estándar y tener un producto exitoso y de calidad superior? En principio, significa un trabajo conjunto de todo un equipo, incluyendo desde quién detecta la necesidad hasta quién materializa la solución.

La responsabilidad es compartida.

Si lo imagináramos como pasos secuenciales, realmente no lo son, se vería algo así:

1. Encontrar un problema del cliente no resuelto y de importancia.
2. Proponer distintas soluciones y obtener retroalimentación.
3. Volver a proponer, acercándonos más a lo esperado.
4. Realizar la especificación del producto/servicio.
5. Probar de acuerdo al modelo de trabajo seguido, en base a la especificación generada.

Los puntos 1 a 3 son experimentales, más que una validación formal contra requerimientos. Es inútil esperar requerimientos formalizados en esta etapa de descubrimiento.

Conclusión

Debemos seguir probando, definiendo procesos repetibles y capacitarnos u organizarnos en forma demostrable. Pero debemos estar conscientes de que no basta con esto; son condiciones deseables pero no suficientes para lograr la calidad. A todo ello debe sumársele el trabajo en equipo, la responsabilidad compartida, el espíritu investigativo, la visión del negocio y la curiosidad.

Los requerimientos implementados y operando correctamente, harán crecer nuestro producto hasta un punto; si logramos satisfacer expectativas del cliente y tenemos éxito, inevitablemente la competencia nos copiará y tendremos nuevamente un producto
estándar. Ser competitivos implica pasar ese punto y sobresalir entre los iguales, con lo cual el ciclo comienza nuevamente.

¿Cómo podemos hacerlo?, ¿qué nos ayudará a encontrar esas nuevas expectativas? Esto puede ser motivo de otra conversación.

Referencias
[1] J. McCall. Factors in software quality. NTIS, 1977.
[2] B. Kitchenham & S. Pfleeger. Software Quality: The elusive target. IEEE, 1996.
[3] D. Garvin. “What does Product Quality really mean?” http://swgu.ru/qs