¿Qué haces cuando las especificaciones están incompletas durante las pruebas de software?

Lo que describe es la situación habitual 🙂 y es extraño o algo más profundo cuando alguien dice que las especificaciones están completas.

Cuando en el escenario de “especificaciones incompletas” hay un par de opciones para completar los elementos que aparentemente faltan, por lo que puedo decir:

  • Descúbrelos, haciendo preguntas, tal vez los elementos que faltan no se escriben, se consideran conocimiento tácito;
  • Mire más profundamente o vuelva a enmarcar su punto de vista, ya que es posible que no falten especificaciones y sus expectativas sean incorrectas. Hay casos en que los evaluadores dicen que faltan especificaciones solo porque las cosas no coinciden con el modelo que han construido en sus mentes;
  • Escriba las especificaciones que faltan y asígneles algunos valores, y estos generalmente se denominan supuestos. El siguiente paso es probar los supuestos, validarlos o falsificarlos, y si probarlos no es una opción, hágales saber a cualquiera para que sepan cuál es el contexto operativo. Para esta opción, todas las cosas deben registrarse de alguna manera, para que uno sepa más tarde qué suposiciones se hicieron o qué suposiciones se confirmaron o falsificaron.

En orden secuencial, también clasificados en términos de prioridad:

  1. Anunciar la situación . Comuníquele al resto del equipo (desarrolladores, gerentes de proyecto) que las especificaciones funcionales están incompletas y brinde ejemplos para demostrar el punto.
  2. Aclarar las reglas . Haga que todos comprendan y acepten que los defectos que no se detectaron con éxito debido a requisitos incompletos no deben atribuirse únicamente a la falta de pruebas.
  3. Recopilar información a través de otros medios . Solicite más reuniones orientadas a la demostración.
  4. Haga suposiciones, verifique las suposiciones . Solicite comentarios (del analista de negocios o de cualquier persona que represente a los usuarios finales) con frecuencia. Solicite información a los desarrolladores también, pero tómela con un poco de sal (alguna información es mejor que nada).
  5. Realizar pruebas exploratorias . Realice pruebas basadas en su perspectiva como probador manual y en base a las pautas generales de experiencia del usuario.
  6. Documente tanto como sea posible , para ayudar a otros a consolidar los requisitos y reducir el riesgo de ser culpado de algo.
  7. Enumere sugerencias de mejora para disminuir las posibilidades de encontrar la misma situación en el futuro.