Como probador de software/control de calidad, ¿cómo manejar cuando las partes interesadas (por ejemplo, el administrador del proyecto y el desarrollador) tienen una comprensión diferente de los requisitos del proyecto? Entiendo que esta falla en la comunicación afecta el cronograma de publicación y control de calidad del proyecto.
¿Alguien puede sugerir cuál sería el siguiente paso del probador/control de calidad aquí?
Agradezco su amable sugerencia. ¡Gracias!
Esta es una gran pregunta. Hace varios años, analicé los errores informados en un equipo y descubrí que más de la mitad de ellos surgieron como resultado de una falta de comprensión de los requisitos.
Algunas cosas que pueden ayudar a reducir este problema incluyen:
Si hay dos partes interesadas que tienen diferentes interpretaciones del requisito, entonces puede haber más. ¿Qué pasa con la forma en que interpreta el requisito, desde la perspectiva de un probador? ¿O qué tal el cliente? ¿O incluso los usuarios finales del producto? Si el requisito es ambiguo hasta el punto de que dos personas que (al menos en teoría) trabajan juntas para entregar el producto tienen interpretaciones diferentes, consideraría probable que haya otras interpretaciones.
Espero que el equipo de control de calidad esté atento a esto al participar en cada paso del proceso. Considerar el aseguramiento de la calidad como una prueba posterior al desarrollo es insuficiente para entregar un producto de calidad. Mirar los requisitos como otro par de ojos para encontrar ambigüedad o hacer preguntas sobre cómo probar el requisito al principio del proceso de desarrollo es importante para preparar al equipo para el éxito a largo plazo.
Si ya llegó al punto en que el trabajo está listo para la integración y las pruebas, pero hay desacuerdos sobre el requisito, el primer paso sería averiguar cuál es realmente el requisito. Alguien tiene que tomar la decisión final. Una opción sería que alguien se ponga en contacto con el cliente o un usuario final y obtenga una aclaración sobre cuál es realmente la necesidad. En algunos casos, el gerente del proyecto o propietario del producto puede estar facultado para tomar la decisión y brindar la voz del cliente, en cuyo caso su palabra es el verdadero requisito. Una vez que tiene el verdadero requisito, se construyen las pruebas para ejercitar el sistema dentro de los límites del requisito y demostrar que cumple con la necesidad.
Dependiendo de cuál sea el verdadero requisito y qué tan lejos esté el diseño y la implementación de ese requisito, se determinarán los siguientes pasos.
¡Bienvenido a PMSE!
Es muy normal que las personas tengan diferentes interpretaciones de un requisito, pero lo interesante es que no ha mencionado a la persona cuya opinión es más importante: el cliente. La forma de lidiar con su situación es colaborar de manera cercana y frecuente con su cliente (patrocinador/propietario del producto/usuarios finales), entregar resultados con regularidad y frecuencia, buscar la retroalimentación del cliente y actuar en consecuencia.
El control de calidad siempre debe ejecutarse desde el comienzo de un trabajo hasta su final. Es contraproducente tratar de incluir el control de calidad en un marco de tiempo limitado. Lo que importa es la rapidez con la que el equipo en su conjunto (análisis, desarrollo, control de calidad y cliente) puede entregar cada incremento del producto.
Voy a responder a esta pregunta de manera más genérica porque resolver los problemas de las partes interesadas no debería requerir métodos diferentes en función de quiénes son las partes interesadas o cuáles son las tareas. Se dan diferentes opiniones, interpretaciones y percepciones en cualquier proyecto complejo, por lo que el equipo debe tener un proceso mediante el cual estos problemas se escalan, examinan, analizan y sobre el cual el equipo acuerda una solución. Si dos o más partes interesadas no pueden resolver un problema en un nivel más bajo e informal, entonces una o más partes interesadas lo escalarán formalmente a través de este proceso, lo que permitirá que el equipo en general lo maneje en consecuencia.
Este proceso debe permitir que ambas partes interesadas opuestas expresen su punto de vista, discutiendo los méritos y brindando su solución. El equipo de escalada escucharía ambos argumentos y luego elegiría una solución utilizando el método predeterminado, ya sea un individuo con la autoridad adecuada, el voto de la mayoría u otra forma de consenso.
En términos de control de calidad, cuando se congela un requisito, prepare sus casos de prueba y preséntelos al equipo. Todos verán lo que construirán y / o recibirán y formularán preguntas y solicitudes de cambio antes de comenzar la prueba.
A todos los que tengan una comprensión aparentemente diferente de los requisitos del proyecto se les debe recordar tanto la redacción original y específica como la interpretación habitual en las costumbres y prácticas estándar de la industria.
Si hay personas que no pueden o no quieren aceptar eso, o necesitan asistir a algún tipo de seminario de pensamiento grupal para entender bien, o tienen razón y el resumen del proyecto necesita ser reescrito.
nick012000