El plan de prueba tiene como propósito comunicar a todos los involucrados del proyecto los entregables, las características a ser o no probadas, los aspectos de criterios de aprobación y fallo, criterios de suspensión y reanudación, las necesidades ambientales, las capacitaciones requeridas para los integrantes del equipo de pruebas, los riesgos y el laboratorio de usabilidad.
(Nos dice cómo debemos de llevar a cabo la estrategia.)
Para elaborar un plan de pruebas de software lo primero que debes hacer es entender los requerimientos de usuario que componen la iteración o proyecto, que son el sujeto de la verificación de calidad que se va a realizar.
Deberás analizar toda la información de la ingeniería de requisitos, incluyendo la matriz de trazabilidad, especificaciones y diseño funcional, requisitos no funcionales, casos de uso, historias de usuario (si estás trabajando con metodologías ágiles), entre otra documentación.
También es muy importante realizar entrevistas con el equipo encargado de la ingeniería de requisitos para aclarar dudas y ampliar la información que sea necesaria.
Además de las preguntas específicas de cada requisito, es importante hacer preguntas del alcance general, por ejemplo:
¿Es un sistema nuevo o existente?¿Cuáles funcionalidades existentes están siendo modificadas?¿Cuáles son los requisitos no funcionales? Entre otras.
Para elaborar un plan de pruebas de software lo primero que debes hacer es entender los requerimientos de usuario que componen la iteración o proyecto, que son el sujeto de la verificación de calidad que se va a realizar.
Deberás analizar toda la información de la ingeniería de requisitos, incluyendo la matriz de trazabilidad, especificaciones y diseño funcional, requisitos no funcionales, casos de uso, historias de usuario (si estás trabajando con metodologías ágiles), entre otra documentación.
También es muy importante realizar entrevistas con el equipo encargado de la ingeniería de requisitos para aclarar dudas y ampliar la información que sea necesaria.
Además de las preguntas específicas de cada requisito, es importante hacer preguntas del alcance general, por ejemplo:
¿Es un sistema nuevo o existente?
¿Cuáles funcionalidades existentes están siendo modificadas?
¿Cuáles son los requisitos no funcionales? Entre otras.
No hay comentarios.:
Publicar un comentario