how test software requirements specification
Eres consciente de que 'La mayoría de Loco en el software se deben a requisitos funcionales incompletos o inexactos? ' Por muy bien que esté escrito, el código del software no importa y no se puede hacer nada si existen ambigüedades en los requisitos.
Este artículo sobre la Especificación de requisitos de software (SRS) establece que los requisitos deben ser claros, específicos, medibles y completos sin contradicciones.
Es mejor detectar las ambigüedades de los requisitos y corregirlas en el ciclo de vida del desarrollo inicial.
El costo de corregir el error después de completar el desarrollo o el lanzamiento del producto es demasiado alto. Por lo tanto, es importante tener un análisis de requisitos y detectar estos requisitos incorrectos antes de las especificaciones de diseño y las fases de implementación del proyecto de SDLC.
Lo que vas a aprender:
¿Cómo medir los documentos SRS funcionales?
Bueno, necesitamos definir algunas pruebas estándar para medir los requisitos. Una vez que cada requisito ha pasado por estas pruebas, puede evaluar y congelar los requisitos funcionales.
Tomemos un ejemplo, está trabajando en una aplicación basada en web. El requisito es el siguiente: 'La aplicación web debe poder atender las consultas de los usuarios lo antes posible'.
¿Cómo congelará el requisito en este caso?
¿Cuáles serán sus criterios de satisfacción de requisitos? Para obtener la respuesta, haga esta pregunta a las partes interesadas: ¿Cuánto tiempo de respuesta está bien para usted? Si dicen, aceptaremos la respuesta si es dentro de 2 segundos, entonces esta es su medida de requisito. Congele este requisito y siga el mismo procedimiento para el siguiente requisito también.
preguntas y respuestas de entrevistas de pruebas de automatización para experimentados
Acabamos de aprender a medir los requisitos y congelarlos en las fases de Diseño, Implementación y Pruebas.
Ahora tomemos otro ejemplo: Estaba trabajando en un proyecto basado en web. El cliente (partes interesadas) especificó los requisitos del proyecto en la fase inicial del desarrollo del proyecto. Mi gerente hizo circular todos los requisitos en el equipo para su revisión. Cuando comenzamos la discusión sobre estos requisitos, ¡nos sorprendimos!
Todos tenían su propia concepción sobre los requisitos. Encontramos muchas ambigüedades en los 'términos' especificados en los documentos de requisitos, que luego se enviaron al cliente para su revisión / aclaración.
El cliente usó muchos términos ambiguos, que tenían muchos significados diferentes, lo que nos dificultaba analizar el significado exacto. La siguiente versión del documento de requisitos del cliente fue lo suficientemente clara como para congelarse durante la fase de diseño.
De este ejemplo, aprendimos que 'los requisitos deben ser claros y coherentes'
El siguiente criterio para probar la especificación de requisitos es 'Descubrir los requisitos que faltan', echémosle un vistazo.
Descubra los requisitos faltantes
Muchas veces los diseñadores de proyectos no tienen una idea clara sobre cada módulo específico y simplemente asumen algunos requisitos en la fase de diseño. Ningún requisito debe basarse en suposiciones. Los requisitos deben ser completos, cubriendo todos y cada uno de los aspectos del sistema en desarrollo.
Las especificaciones deben indicar ambos tipos de requisitos, es decir, qué sistema debe hacer y qué no.
Generalmente, utilizo mi propio método para descubrir los requisitos no especificados. Cuando leo el Documento de especificación de requisitos de software (SRS) , Anoto mi propio entendimiento de los requisitos que se especifican, además de otros requisitos que se supone que debe cubrir el documento SRS.
Esto me ayuda a hacer las preguntas sobre los requisitos no especificados, haciéndolo más claro.
Para verificar la integridad de los requisitos, divida los requisitos en tres secciones, requisitos 'Debe implementar', requisitos que no se especifican pero que se 'asumen' y el tercer tipo es el tipo de requisitos de 'imaginación'. Compruebe si se abordan todos los tipos de requisitos antes de la fase de diseño del software.
Compruebe si los requisitos están relacionados con el objetivo del proyecto
A veces, las partes interesadas tienen su propia experiencia, que esperan que venga en el sistema en desarrollo. Ni siquiera piensan si ese requisito sería relevante para el proyecto en cuestión. Asegúrese de identificar dichos requisitos. Intente evitar todos los requisitos irrelevantes durante la primera fase del ciclo de desarrollo del proyecto.
Si no es posible, haga las preguntas a las partes interesadas como por qué desea implementar este requisito específico. Esto describirá el requisito particular en detalle, lo que facilitará el diseño del sistema considerando el alcance futuro.
Pero, ¿cómo decidir si los requisitos son relevantes o no?
Respuesta simple: establezca el objetivo del proyecto y haga esta pregunta: ¿Si no implementar este requisito, causará algún problema para lograr nuestro objetivo especificado? De lo contrario, este es un requisito irrelevante. Pregunte a las partes interesadas si realmente quieren implementar este tipo de requisitos.
preguntas y respuestas de la entrevista de administrador de salesforce para
En resumen, el documento de Especificación de requisitos (SRS) debe abordar lo siguiente:
- Funcionalidad del proyecto (qué se debe hacer y qué no se debe hacer).
- Software, interfaces de hardware e interfaz de usuario.
- Criterios de corrección, seguridad y rendimiento del sistema.
- Problemas de implementación (riesgos) si los hay.
Conclusión
He cubierto casi todos los aspectos de la medición de requisitos. Para ser específico sobre los requisitos, resumiré las pruebas de requisitos en una oración:
'Los requisitos deben ser claros y específicos sin incertidumbre, los requisitos deben ser medibles en términos de valores específicos, los requisitos deben ser comprobables con algunos criterios de evaluación para cada requisito, y los requisitos deben ser completos, sin contradicciones'
Las pruebas deben comenzar en la fase de requisitos para evitar más errores relacionados con los requisitos. Comunicar cada vez más con sus partes interesadas para aclarar todos los requisitos antes de comenzar el diseño e implementación del proyecto.
¿Tiene alguna experiencia en pruebas de requisitos de software?
No dude en compartirlos en los comentarios a continuación.
Lectura recomendada
- Mejores herramientas de prueba de software 2021 (Herramientas de automatización de pruebas de control de calidad)
- Trabajo de asistente de control de calidad de pruebas de software
- Tutorial de pruebas destructivas y no destructivas
- Mapas mentales en las pruebas de software: ¡formas de hacer que las pruebas sean más divertidas!
- ¿Cómo probar una aplicación sin requisitos?
- Curso de pruebas de software: ¿A qué instituto de pruebas de software debo unirme?
- Elegir las pruebas de software como carrera
- Prueba de software Escritor de contenido técnico Trabajo autónomo