El bug presentado en nuestro post anterior atrajo a un gran número de comentarios muy interesantes

Así que, primero, un gran agradecimiento a todos los que expresaron sus puntos de vista, ya que fue precisamente el objetivo de esta publicación.

Mi experiencia en consultoría es más bien orientada a las ‘mejores prácticas’ en términos de ciclo de vida del proyecto. No soy un experto en control de calidad.

Pero trabajo regularmente con buenos profesionales de QA y yo tenía mucha curiosidad acerca de las opiniones de personas más expertas que yo en esta área … antes de hacer algunas suposiciones en este segundo post.

En primer lugar, un resumen del error que hemos encontrado.

Un sitio web ofrece a la venta todos los días diferentes productos de diferentes marcas, cada una en una tienda virtual donde se puede navegar y añadir lo que nos interesa a una cesta (virtual). Una vez las compras validadas y el pago realizado, puedes seleccionar una marca diferente y hacer nuevas adquisiciones. Entonces, el sitio permite agrupar las nuevas compras con las anteriores en una sola entrega. Esta es la operación por defecto.

En mi caso, he comprado dos artículos diferentes de la misma marca, pero cuando traté de hacer el pago, un mensaje me informó que estos dos objetos requieren dos entregas diferentes. Tuve que hacer dos compras y dos pagos separados. La operación por defecto no es aplicable.

Pues volví a la tienda para hacer una compra inicial (2 sillas de jardín), y luego una segunda compra (una hamaca) y cuando traté de validar … el sitio web me ofrecio agrupar las diferentes compras en una entrega única. Es decir, se me propone el proceso por defecto que no debe aplicarse. Debo confesar que yo podía adivinar el defecto, y la curiosidad me llevó a aceptar, para encontrarme con:

• Una página de error genérica muy imprecisa, de absolutamente ninguna ayuda.
• Una sesión ‘web’ completamente inestable, sin la posibilidad de reinitializar mi carrito y volver a un proceso normal que me hubiera permitido finalizar mi compra.

Quitar el sitio para volver de nuevo no hubo ningún efecto. Tuve que cerrar mi navegador y volver a iniciar una nueva sesión con el fin de hacer mis compras. Espero que encontraré ellas a la altura de las dificultades para adquirirlas.

Si trato de pensar con un punto de vista desde el proyecto: el proceso de entrega habitual no se aplica, y el desarrollador ha implementado correctamente un proceso «por excepción». Sin embargo, la integración de esta nueva funcionalidad con el proceso «por defecto» existente conduce a un error grave. Traté de imaginar lo que podría ser la causa, y fue entonces cuando decidí realizar un primer post y pedir su opinión a la comunidad de los profesionales de QA.

Cherchez l’erreur.

Vuestros comentarios (en resumen):

• No es un defecto de testing: es ‘no testing’.
• No es un defecto de testing: es un problema de diseño.
• Un buen tester debe ser capaz de abandonar la lógica de QA y pasar al otro lado: la de la lógica de usuario.
• Esta es una situación clásica, donde la presión del time-to-market y la falta de recursos conducen a una falta de pruebas.

El objetivo principal de cualquier prueba es asegurar que un producto responde correctamente a lo que se espera en términos de función y calidad. La QA es una profesión, una especialidad en sí misma, que requiere habilidades y experiencia. En nuestro ejemplo, podemos considerar que esta funcionalidad no ha sido probada, o que las pruebas no se realizaron correctamente.

El hecho de que el sitio se refiere a una sola página para todos los posibles problemas me dejó pensar que el presupuesto de desarrollo / QA no es a nivel del crecimiento del sitio web. Veo esto como un signo de pereza o de falta de recursos. Una admisión de impotencia. La gestión de errores no es claramente una prioridad.

¿Cómo? No puedo hacer una compra, y esto no es una prioridad? Este sitio web no quiere mi dinero?

Yo quería saber más y llamé a un amigo, un consultor independiente como yo, con un buen conocimiento de este tipo de sitios comerciales y de las dificultades que enfrentan. Así que hemos hablado acerca de prioridades. Esto es lo que aprendí:

• Este sitio gestiona más de 100.000 visitas por día, con un tiempo de respuesta óptimo y sin ninguna interrupción. En 2011, 1.500 marcas vendieron sus productos
• Desarrollo y control de calidad se gestionan internamente, con cerca de sesenta personas. No hay outsourcing.
• Este departamento se encarga de sus propias aplicaciones y también utiliza diferentes sistemas ERP. Metodologías en V (Waterfall) y Scrum.
• La compañía ha abierto oficinas en diferentes países. Existe un rumor sobre un posible proyecto para entrar en el Cloud con unas infraestructura SaaS para clientes que quieren su propia tienda online.

Una anécdota proporcionada por mi amigo. Un cliente puede solicitar un reembolso si la compra, una vez recibida, no cumple con sus deseos: producto defectuoso, tamaño equivocado, o simplemente, no lo quiere más. En este caso, se devuelva el producto y se puede solicitar un reembolso. Hace unos años, sucedió que todos los pagos se suspendieron durante varias semanas debido a un bug. El management había dejado los pagos durante el tiempo necesario para volver a escribir la aplicación o implementar un sistema ERP con la misma función. ¿Puedes imaginar la furia de los usuarios y la mala imagen para el sitio web?

No hacer una prioridad de los usuarios no es la elección de un único programador o de un tester: es una opción del management. Y conozco una sola prioridad más importante que el usuario: el presupuesto.
Este no es el caso aquí. Este sitio web es una empresa pionera y líder del mercado en las ventas privadas, con un crecimiento impresionante. Estoy hablando de una nueva empresa en marcha para la conquista del mundo, no una empresa centenaria en un mercado en declive.

Creo que se trata de un equipo TI cuya prioridad es satisfacer el crecimiento del negocio, estar listo para la apertura de cada nueva filial, para gestionar la logística de los distintos proveedores y decenas de miles de clientes, para evitar cualquier interrupción o malo rendimiento … lo que significa una acumulación de capas tecnologicas a lo largo del tiempo, aplicaciones desarrolladas internamente a una velocidad significativa, la duplicación / especialización en sistemas de acuerdo con las regulaciones de cada nuevo país, la integración de ERP diferentes, etc .

Llega un momento en que la acumulación de la deuda técnica es tal que:

• Un módulo entero – como el del reembolso – puede cesar de funcionar: que no se paga durante varias semanas, sin siquiera tratar de encontrar una solución, durante el tiempo necesario para implementar un nuevo software.
• El número de errores encontrados es demasiado importante como para manejar cada uno de forma independiente: se implementa una página de error genérica y el usuario tiene que hacer lo que puede con esto.
• Y ya que el usuario no es una prioridad, si todos los errores posibles están cobiertos, ¿por qué perder el tiempo en pruebas?

Llega un momento en que hay tantas fugas que ya no se trata de arreglar cada uno de ellas: colocar un barril grande y una cuchara.

Como consultor de calidad, mis recomendaciones serían:

• Un análisis sistemático de la calidad del código de todas las aplicaciones.
• Identificar los sistemas demasiado pesados, que ya no pueden permitir ningún flexibilidad en time-to-market, experimentando retrasos en el desarrollo y importantes esfuerzos de QA.
• Cruzar estos datos de proyectos con los de la calidad del código para decidir qué partes del portafolio de aplicaciones necesitan refactoring.

También ver si la metodología utilizada puede explicar algunos malos resultados en términos de proyecto. Si la QA descubre demasiados errores demasiado tarde en el ciclo de vida del proyecto, llega un punto en el que el esfuerzo de pruebas es demasiado importante para permitir correcciones antes de la fecha límite.

Si el rumor es cierto que implica proponer el sitio como Software-as-a-Service, la refactorización no sólo se justifica sino es mandatoria. No se trata simplemente de poner al usuario en el centro de la estrategia TI, esto es impredicible para seguir el crecimiento.

Ya he encontrado este tipo de situación en empresas de telecomunicaciones. Tuvieron que enfrentarse a un crecimiento muy fuerte y sus departamentos de TI experimentaron esos mismos problemas, y ahora deben gestionar sistemas de mala calidad, errores incontables, … salvo que estas empresas ya no son en un mercado en crecimiento y que los presupuestos de TI se están reduciendo y no se pueden pagar una refactorización ahora.

Y eso es cuando el management decide poner al usuario en el centro de su estrategia porque, cuando no hay crecimiento, cuando ya no es posible obtener nuevos clientes, es cuando evitar la pérdida de los clientes se convierte en la prioridad.

Cherchez l’erreur… antes de que sea demasiado tarde.