Menú

Cómo lidiar con los malos requisitos como evaluador

how deal with bad requirements

Pruebe Nuestro Instrumento Para Eliminar Los Problemas

La silenciosa sala de conferencias era sofocante y todos dentro estaban confundidos. ¿Cómo podríamos perderlo? , fue la pregunta reflejada en el rostro de todos.

Después de todo, no aparecer con ningún error relevante cuando el usuario intenta duplicar el registro existente y permitirle hacerlo no fue un pequeño error. Eso también para una compañía de seguros.

Después de decidir concretar el problema, todos se dispersaron. Y mientras investigaba, se observó que el cliente nunca mencionó nada sobre la duplicidad de registros en el documento de requisitos y, por lo tanto, nadie hizo preguntas relevantes ni pensó en ello.

malos requisitos

Este fue solo un ejemplo.

En una carrera de más de 10 años , He observado muchos casos en los que los proyectos sufrieron debido a requisitos deficientes o deficientes.

Pero como dicen, nada es perfecto en este mundo y tendrás que lidiar con eso y lidiar con proyectos que no tienen requisitos o requisitos deficientes es una especie de pesadilla.

Dejame explicar -

Lo que vas a aprender:

Qué tan malos, deficientes y conflictivos crean problemas los requisitos:

# 1) Sin requisitos - Ningún requisito implica suposiciones y conjeturas y, por lo tanto, no hay confianza. Es muy difícil probar un producto / aplicación sin una línea de base. Y esto da como resultado más trabajo, más errores del cliente y más sufrimiento para el proyecto.

  • Como harias Reportar un problema sobre la caída del sistema cuando no hay una definición de cómo se debe manejar el comportamiento.
  • ¿Cómo transmitiría que el tiempo de carga de 100 segundos para la página de inicio es inaceptable cuando no hay un requisito relevante para el rendimiento?

Puede encontrar más información sobre Sin requisitos y cómo manejar la situación durante las pruebas en un artículo publicado anteriormente: ¿Cómo probar una aplicación sin requisitos?

# 2) Requisitos deficientes - La frase, Saber algo incompleto es peligroso que no saberlo en absoluto , es muy cierto cuando se trata de lidiar con un requisito deficiente.

Interpretar un requisito deficiente e implementarlo es un gran riesgo.

  • ¿Cómo confirmaría que la ventana emergente que muestra los resultados de la búsqueda es válida o no cuando el único requisito mencionado es que los resultados de la búsqueda deben ser correctos y no está seguro de qué criterios deben considerarse durante la búsqueda?
  • ¿Cómo interpretaría usted esto? Se debe implementar la contraseña olvidada para facilitar al usuario la regeneración / restablecimiento de la contraseña olvidada. Desconocido sobre qué flujo de trabajo quiere el cliente para la contraseña olvidada, el desarrollador implementa lo que cree que es mejor y comienzan los conflictos.

# 3) Requisitos en conflicto - Pedirle a alguien que haga dos cosas diferentes al mismo tiempo es confundirlo y el sistema tampoco es una excepción.

  • ¿Cómo probaría una aplicación con los requisitos mencionados a continuación?
    • La aplicación siempre debe abrirse en la página de inicio.
    • Se espera que los usuarios inicien sesión para acceder a la aplicación.
  • ¿Cuál decidiría la prioridad cuando el documento de requisitos es el siguiente:
    • La aplicación de juegos debe promover al usuario al siguiente nivel si el usuario obtiene una puntuación de 1000.
    • El usuario debe ser redirigido a la página de suscripción gratuita una vez que obtenga 1000 puntos.

Y así es como los requisitos malos, deficientes y conflictivos crean problemas.

Al estar en la industria del software, debería ser parte del proyecto, ya que a veces incluso el cliente no está seguro de qué es exactamente lo que quiere y cómo expresarlo.

Desde la perspectiva de las pruebas, aunque es difícil manejar esos requisitos ambiguos o vagos, no es completamente imposible.

Veamos las posibles soluciones:

Malos requisitos y cómo manejarlos como evaluador:

Método 1)Explore y aprenda:

Explorar otras aplicaciones, aprender sobre el comportamiento general esperado, comprender el flujo de trabajo, pensar en la conveniencia del usuario y aplicar la lógica es una forma de lidiar con la situación. También, confiando en pruebas exploratorias Sería útil en este tipo de situaciones donde los requisitos no están claros.

La mayoría de las veces, es una buena apuesta priorizar la experiencia y la comodidad del usuario cuando los requisitos no están claros.

Método # 2)Utilice la experiencia:

Utilizar la experiencia

Experiencia de dominio , la experiencia general en las pruebas, los problemas enfrentados en el pasado y los conocimientos personales pueden ayudar a abordar situaciones y requisitos confusos.

Método # 3)Consulte los wireframes:

Los wireframes son una especie de requisito visual en el que puede encontrar pequeños detalles y esos detalles pueden ser muy útiles para crear la imagen esperada del producto o la aplicación y ayudan a cubrir los aspectos de prueba de una mejor manera.

Leer más => Wireframes: ¿deberían realmente probarse? Y si es así, ¿cómo?

Método # 4)Discusión entre pares:

cómo escribir scripts de prueba de automatización

Discusión entre pares

No importa cuál sea la confusión, si se discute con el grupo adecuado de personas, las cosas se aclaran. Todo el mundo tiene diferentes experiencias, expectativas, ojo del usuario y punto de vista de análisis, y discutir esos requisitos deficientes con los compañeros servirá como beneficio para cristalizar la comprensión y aumentar la confianza en uno mismo.

Método # 5)Aclaración del cliente:

El cliente es el propietario del producto / aplicación y siempre es aconsejable acercarse a él cuando se trata de claridad de requisitos. Pero recuerde, no es recomendable atacar al cliente con cientos de preguntas. Antes de hacerlo, se requiere algo de tarea.

Trate de descubrir las mejores prácticas disponibles, comprenda los beneficios de la implementación y luego comuníquese con el cliente con preguntas y posibles soluciones.

Conclusión

Por último, los requisitos vagamente definidos o indefinidos son parte de la vida del evaluador y debemos aceptarlos, pero tratemos de ser optimistas y determinar soluciones. Después de todo, somos probadores, ayudamos a mantener las aplicaciones encaminadas y protegemos de que no se desinflen. YAY para nosotros :)

Sobre el Autor: Esta publicación inspiradora está escrita por Bhumika M., miembro del equipo de STH. Ella es líder de proyecto y tiene más de 10 años de experiencia en pruebas de software.

Feliz prueba, como siempre… .. esperando tus puntos de vista, comentarios y opiniones.

Lectura recomendada

^