Las actividades de testing, fundamentales para encontrar el equilibrio entre coste y satisfacción del cliente
Queremos lo mejor. Como usuarios queremos que todos los productos y servicios que adquirimos funcionen perfectamente, que tengan la mejor configuración, la mayor cantidad de servicios y opciones, que sean lo más rápidos posible y a un precio razonable (por no decir baratos).
En el mundo de las apps y las webs esto supone que los equipos involucrados tienen que ser rápidos y precisos, en muchas ocasiones en proyectos complejos y deficiente documentados, al dar prioridad a la entrega de nuevas funcionalidades (delivery) frente al mantenimiento y soporte.
Pero, ¿cómo se asegura la calidad? ¿Qué calidad es la exigible? Si contéstanos que “0 fallos” y “disponibilidad absoluta”, seguramente no somos conscientes del altísimo coste que supone si se lo tenemos que exigir a todos los eslabones de la cadena.
En general, los sistemas tienen pocos fallos y solo los sistemas y servicios más críticos requieren SLAs excepcionalmente altos por los que hay que estar dispuesto a pagar su sobrecoste.
Pero, por otro lado, como fabricantes o creadores nos obligamos a construir buenos productos y servicios para nuestros clientes, porque es lo que nos compran o son los canales y servicios que les facilitamos para relacionarnos con ellos, es la “Customer Experience” (CX) que tenemos que cuidar y mejorar para la ansiada fidelización.
Pero, ¿Cómo podemos balancear ambas realidades?
Las pruebas integradas pueden ser la solución, disponer de pruebas manuales o automáticas, integradas en el código o externas, unitarias, integradas, de regresión, de humo, de carga, … Hay muchas opciones, tenemos mucho que probar.
En el momento de diseñar nuevas funcionalidades tenemos que pensar ya en qué test validará esa funcionalidad, y conforme la vamos desarrollando se va probando.
Si integramos este test en el ciclo de vida de la aplicación, será capaz de ejecutarse no sólo una vez al final del desarrollo, sino cada vez que preparamos la aplicación para publicarla en los markets, y por tanto aseguramos ya una serie de funcionalidades que son correctas, que lo han sido y lo siguen siendo con el resto del código desarrollado.
Podemos hacer toda una batería de tests a nuestras aplicaciones, en distintos dispositivos y configuraciones para anticiparnos a cualquier problema, para poder solucionarlas antes de que le surja al cliente y le provoque insatisfacción.
Es imposible anticiparse a todas las situaciones y sería muy caro hacerlo, pero tenemos que optimizar nuestros recursos para que estas actividades de testing nos aporten el mayor valor para nuestros clientes en los productos y servicios que realizamos.
Social Links: