Tengo un formulario de solicitud en un sitio web para solicitar algo. Ha sido probado a fondo y pasa. Sin embargo, mi cliente descubrió que si ingresaba un emoji en uno de los campos que realiza una búsqueda de direcciones, el formulario se rompe.
Y mi respuesta es "bueno, sí". Es una acción irrazonable. Ningún usuario haría esto, y creo que es una tontería que el cliente venga a mí por esto. Quiero decir, ¿qué esperan si hacen cosas poco realistas en la forma que un usuario común no haría?
¿Cómo manejo/trato con esto? ¿Le digo al cliente que está siendo ridículo o le sigo la corriente y lo arreglo?
No es la primera vez que hacen esto. Encontrarán todo tipo de formas de romper el sitio web, como ingresar este valor, luego eliminar e ingresar este carácter no válido, luego ingresar un número, luego eliminar y repetir, separar el mar rojo y mover mi casa 6 pulgadas a la izquierda. y obtienes un error. Y tengo ganas de tirarme de los pelos. ¿Qué esperan?
¿Quién es el irrazonable aquí?
Desde un punto de vista de seguridad, nunca se debe confiar en la entrada. ¿Qué quiere decir que la próxima vez no se trate de un emoji, sino de algún tipo de hazaña textual como el ataque del billón de risas ?
Al final del día, si se trata de un sitio público, tendrá script kiddies apuntándole con sus herramientas que le enviarán todo tipo de datos. Si la página se rompe, es su ERROR, debe corregirse y podría implicar que existe un riesgo inherente (¿aceptará y ejecutará XSS como alert('hello') )?
La entrada debe validarse en el cliente Y en el servidor. Solo procesa los datos que esperas.
Consulte la muy útil guía Owasp Top 10 de Troy Hunt, que puede descargar de forma gratuita Guía para desarrolladores de Owasp Top 10
Puede ser un verdadero desafío diferenciar entre lo que es un error y lo que es un nuevo requisito.
Una forma de hacer esto más explícito es producir un informe de prueba que incluya tanto la prueba realizada como el alcance de la prueba. Si el cliente acepta el alcance, cualquier trabajo futuro fuera del alcance será facturable.
Por ejemplo, el informe de la prueba podría decir algo como esto:
El campo de dirección ha sido probado para la longitud del campo. No se realiza ninguna otra validación de texto.
Si esto es aprobado por el cliente y luego informan un problema con emoji rompiendo el campo, se consideraría una solicitud de cambio.
No mencionaste que esto era parte de un proceso de prueba beta del cliente, así que asumiré que no lo es.
En cambio, supongo que este problema surgió cuando un cliente real estaba usando la aplicación y mostró un comportamiento que el cliente no esperaba .
A mis ojos, eso es un error . ¡Sin embargo!
¿Le digo al cliente que está siendo ridículo o le sigo la corriente y lo arreglo?
Estás mostrando un pensamiento notablemente polarizado, ahí. ¡ Nunca le digas a un cliente que es ridículo! Incluso si desea despedir a un cliente, será mejor que lo haga de una manera que no le dé motivo para albergar una mala voluntad significativa hacia su empresa, lo que podría hacer que se desvíe de su camino para causarle daño (como publicar públicamente su maltrato hacia ellos).
E incluso si se trata de un error, no hay nada que diga que debe dejar todo y solucionarlo ahora . ¿Ha considerado responder con lo siguiente?
"¡Gracias por sus comentarios! Hemos recibido su informe de error y lo hemos ingresado en nuestro sistema. Una vez que se haya priorizado, comenzaremos a procesarlo".
Y luego asigne al error una prioridad adecuada (léase: baja) y solucione el problema cuando finalmente tenga tiempo (posiblemente nunca, pero revisar los informes de errores de bajo riesgo y baja recompensa me parece un uso válido de la holgura tiempo. Su millaje puede variar).
Asegúrate de agradecerles , porque te están haciendo un favor . Me encantaría tener clientes tan dedicados y serviciales como este. Está realizando pruebas exhaustivas de control de calidad de forma gratuita . Probablemente simplemente porque le gusta su producto y quiere que sea lo mejor posible (o posiblemente solo porque disfruta encontrando los problemas de otras personas, pero de cualquier manera, el resultado es el mismo).
El núcleo de su problema parece reducirse a esto:
Ha sido probado a fondo y pasa. Sin embargo, mi cliente descubrió que si ingresaba un emoji en uno de los campos que realiza una búsqueda de direcciones, el formulario se rompe.
Desde el punto de vista de la gestión de proyectos, uno puede extraer los siguientes puntos solo de las dos oraciones citadas anteriormente:
La Definición de Terminado del proyecto no se ha definido formalmente.
Si usted y el cliente tienen diferentes definiciones de "probado a fondo" que no se acordaron por adelantado, entonces tiene un problema. Puede ser un problema de comunicaciones, un problema de planificación o un problema contractual, pero en todos los casos es un problema a nivel de proyecto y debe tratarse constructivamente.
Dices que el formulario "se rompe", pero no defines el nivel de impacto.
Su cliente está realizando extensas pruebas de control de calidad (como debería hacerlo alguien en el proyecto) y está encontrando problemas. Sin embargo, "el formulario se rompe" es bastante inespecífico. Si coloca datos no desinfectados en una base de datos, hace que la aplicación finalice o hace algo además de generar un error recuperable, entonces es un error. Si su aplicación puede fallar cuando el gato de alguien camina por el teclado, es poco probable que sea adecuada para su propósito.
Sin embargo, nuevamente, el problema es definir un nivel de calidad. Lo ha definido como "el formulario funciona cuando los usuarios siguen el camino feliz". Es probable que el cliente lo haya definido como "el sistema es robusto frente a la entrada sin desinfectar". Sin embargo, el proyecto no ha adoptado un nivel de calidad acordado en el que tanto los desarrolladores como el cliente estén de acuerdo. ¡Arregla eso!
El proyecto no está integrando QA o pruebas de aceptación en el ciclo de desarrollo.
Parte de su frustración es que está recibiendo comentarios post facto sobre el incremento de trabajo. Sin embargo, si QA y UAT estuvieran verdaderamente integrados con el ciclo de desarrollo, no habría sorpresas para nadie. Tanto los desarrolladores como los probadores sabrían de antemano qué pruebas tenían que pasar y si cada incremento de trabajo cumplía o no con esos objetivos.
Pasar a una mentalidad de prueba primero es difícil, pero hacer cualquier otra cosa es preparar su proyecto para el fracaso. Aquí es donde la experiencia en gestión de proyectos, incluida la gestión de procesos y el liderazgo orientado a las comunicaciones, puede ser de gran ayuda.
Usted y el cliente no están colaborando entre sí.
Uno de los cuatro valores centrales del Manifiesto Ágil es la colaboración del cliente sobre la negociación de contratos . Incluso si no está siguiendo una metodología ágil (lo que sin duda explicaría parte de su dolor), el punto es que trabajar codo a codo con su cliente en lugar de depender de los traspasos y la retroalimentación de ida y vuelta es generalmente más efectivo. y evita exactamente el tipo de comunicaciones y desafíos de expectativas que está experimentando.
Trabaje en la creación de colaboración a través de una definición de hecho bien definida, la implementación del desarrollo basado en pruebas y la inclusión de probadores de clientes y especialistas de UAT dentro de cada ciclo de desarrollo. La colaboración casi siempre será más efectiva para resolver los desafíos que enfrenta, especialmente cuando se compara con disputas contractuales o abogados.
Bart van Ingen Schenau
Robert K Bell