how review srs document
Este es el segundo tutorial de nuestro 'Capacitación gratuita en línea sobre pruebas de software en un proyecto en vivo' serie. Si es nuevo aquí, consulte el primer tutorial de introducción: Capacitación de prueba de software de extremo a extremo en un proyecto en vivo.
Pasemos ahora a un análisis detallado de cómo ocurre un recorrido de SRS, qué es lo que debemos identificar en este paso, qué pasos previos debemos tomar antes de comenzar, cuáles son los desafíos que podríamos enfrentar, etc. de manera detallada.
Fase de diseño de SDLC:
La siguiente fase del SDLC es 'Diseño': aquí es donde los requisitos funcionales se traducen en detalles técnicos. Los equipos de desarrollo, diseño, entorno y datos participan en este paso. El resultado de este paso suele ser un documento de diseño técnico (TDD).
La entrada es el documento SRS tanto para la creación del TDD como para que el equipo de QA comience a trabajar en el aspecto QA del proyecto, que es revisar el SRS e identificar el objetivo de la prueba.
Lo que vas a aprender:
- ¿Qué es una revisión de SRS?
- Pasos previos a la revisión de la especificación de requisitos de software
- ¿Se requiere plantilla para escenarios de prueba?
- Algunas observaciones importantes sobre la revisión de SRS
- Lectura recomendada
¿Qué es una revisión de SRS?
SRS es un documento creado por el equipo de desarrollo en colaboración con los analistas comerciales y los equipos de datos y entorno. Normalmente, este documento, una vez finalizado, se compartirá con el equipo de control de calidad a través de una reunión en la que se organiza un recorrido detallado.
para que se usa c ++
A veces, para una aplicación ya existente, es posible que no necesitemos una reunión formal y alguien que nos guíe a través de este documento. Podríamos tener la información necesaria para hacerlo por nosotros mismos.
La revisión de SRS no es más que revisar el documento de especificación de requisitos funcionales e intentar comprender cómo será la aplicación de destino.
El formato formal y una muestra se compartieron con todos ustedes en el artículo anterior. No significa necesariamente que todos los SRS se vayan a documentar de esa manera exactamente. Siempre, el la forma es secundaria al contenido .
Algunos equipos simplemente optarán por escribir una lista con viñetas, algunos equipos incluirán casos de uso, algunos equipos incluirán capturas de pantalla de muestra (como el documento que teníamos) y algunos simplemente describirán los detalles en párrafos.
Pasos previos a la revisión de la especificación de requisitos de software
Paso 1) Los documentos pasan por múltiples revisiones, así que asegúrese de tener la versión correcta del documento de referencia, el SRS.
Paso 2) Establezca pautas sobre lo que se espera al final de la revisión de cada miembro del equipo. En otras palabras, decida qué entregables se esperan de este paso; normalmente, el resultado de este paso es identificar los escenarios de prueba. Los escenarios de prueba no son más que indicadores de una línea de 'qué probar' para determinadas funciones.
Paso 3) También establezca pautas sobre cómo se presentará este entregable, es decir, la plantilla.
Paso 4) Decida si cada miembro del equipo trabajará en todo el documento o se dividirá entre ellos. Es muy recomendable que todos lean todo porque eso evitará la concentración de conocimientos con ciertos miembros del equipo.
Pero en el caso de un proyecto enorme, con los documentos SRS que se ejecutan cerca de 1000 páginas, el enfoque de dividir el módulo del documento y asignarlo a miembros individuales del equipo es más práctico.
Paso # 5) La revisión de SRS también ayuda a comprender mejor si existen requisitos previos específicos necesarios para la prueba del software.
Paso # 6) Como subproducto, se identifica una lista de consultas donde alguna funcionalidad es difícil de entender o si se necesita incorporar más información a los requisitos funcionales o si se cometen errores en SRS.
¿Qué necesitamos para empezar?
- La versión correcta del documento SRS
- Instrucciones claras sobre quién va a trabajar en qué y cuánto tiempo tienen.
- Una plantilla para crear escenarios de prueba.
- Otra información sobre a quién contactar en caso de una pregunta o a quién informar en caso de una inconsistencia en la documentación
¿Quién proporcionaría esta información?
Los líderes de equipo son generalmente responsables de proporcionar todos los elementos enumerados en la sección anterior. Sin embargo, las aportaciones de los miembros del equipo siempre son importantes para el éxito de todo este esfuerzo.
Los líderes de equipo a menudo preguntan: ¿Qué tipo de aportaciones? ¿No sería mejor asignar un determinado módulo a alguien interesado en él que a un miembro del equipo que no lo está? ¿No sería bueno decidir la fecha objetivo en función de la opinión del equipo que imponerles una decisión? Además, para el éxito de un proyecto, las plantillas son importantes.
Como regla general, las plantillas tienen una mayor tasa de eficiencia cuando se adaptan a la conveniencia y comodidad del equipo específico. Por lo tanto, debe tenerse en cuenta que los líderes de equipo son más que nada los miembros del equipo. Lograr que su equipo participe en las decisiones del día a día es crucial para el buen funcionamiento del proyecto.
¿Se requiere plantilla para escenarios de prueba?
¿Por qué una plantilla para escenarios de prueba? ¿No es suficiente si solo hacemos una lista?
Seguro que lo es. Sin embargo, los proyectos de software no son programas de 'un solo hombre'. Involucran trabajo en equipo .
Imagine un equipo de 4 si cada uno de ellos decide revisar un módulo de la especificación de requisitos de software cada uno. El miembro del equipo A ha hecho una lista en una hoja de papel. El miembro del equipo 2 usó una hoja de Excel. El miembro del equipo 3 usó un bloc de notas. El miembro del equipo 4 usó una palabra doc. ¿Cómo consolidamos todo el trabajo realizado para el proyecto al final del día?
Además, ¿cómo podemos decidir cuál es el estándar y cómo podemos decir qué es correcto y qué no si no creamos las reglas, para empezar?
Eso es lo que es la plantilla: Un conjunto de pautas y un formato acordado para la uniformidad y concurrencia de todo el equipo.
¿Cómo crear una plantilla para escenarios de prueba de control de calidad?
Plantillas no tiene que ser complicado o inflexible.
Todo lo que necesitan es un mecanismo eficiente para crear un artefacto de prueba útil. Algo sencillo como el que vemos a continuación:
El encabezado de esta plantilla contiene el espacio necesario para capturar información básica sobre el proyecto, el documento actual y el documento de referencia.
La siguiente tabla nos permitirá crear escenarios de prueba. Las columnas incluidas son:
Columna n. ° 1) ID de escenario de prueba
Cada entidad en nuestro proceso de prueba debe ser identificable de forma única. Por lo tanto, a cada escenario de prueba se le debe asignar una identificación. Se deben definir las reglas a seguir al asignar este ID.
Por el bien de este artículo, seguiremos la convención de nomenclatura como TS (prefijo que significa Escenario de prueba) seguido de '_', nombre del módulo MI (Módulo Mi información del proyecto Orange HRM) seguido de '_' y luego la subsección ( Por ejemplo, ME para el módulo Mi información, PAG para fotografía, etc.) seguido de un número de serie. Un ejemplo sería: “TS_MI_MIM_01”.
Columna # 2) Requisito
Ayuda que cuando creamos un escenario de prueba, podamos mapearlo de nuevo a la sección del documento SRS de donde lo elegimos. Si los requisitos tienen ID, podríamos usar eso. De lo contrario, los números de sección o incluso los números de página del documento SRS desde donde identificamos un requisito comprobable serán suficientes.
convertir char a cadena c ++
Columna # 3) Descripción del escenario de prueba
Un resumen que especifica 'qué probar'. También nos referiremos a él como el objetivo de la prueba.
Columna # 4) Importancia
Esto es para dar una idea de la importancia que tienen determinadas funciones para la AUT. Se pueden asignar valores como alto, medio y bajo a este campo. También puede elegir un sistema de puntos, como 1-5, siendo 5 el más importante y el 1 menos importante. Cualquiera que sea el valor que pueda tomar este campo, debe decidirse previamente.
Columna # 5) No. de casos de prueba
Una estimación aproximada de cuántos casos de prueba individuales podríamos terminar escribiendo ese escenario de prueba. Por ejemplo, Para probar el inicio de sesión, incluimos estas situaciones: Nombre de usuario y contraseña correctos. Corrija el nombre de usuario y la contraseña incorrecta. Corrija la contraseña y el nombre de usuario incorrecto. Por lo tanto, validar la funcionalidad de inicio de sesión dará como resultado 3 casos de prueba.
Nota: Puede expandir esta plantilla o eliminar los campos como mejor le parezca.
Por ejemplo , puede agregar 'Revisado por' en el encabezado o eliminar la fecha de creación, etc. También en la tabla, puede incluir un campo 'Creado por' para designar al evaluador responsable de un determinado escenario de prueba o eliminar el 'No. de casos de prueba ”. La decisión es tuya. Elija lo que funcione mejor para todo el equipo.
Revisemos ahora nuestro documento de SRS de Orange HRM y creemos los escenarios de prueba
Consejo profesional: Consulte la tabla de contenido en la muestra de SRS que proporcionamos en los primeros tutoriales para tener una buena idea de cómo va a fluir cualquier documento y cuánto trabajo podría implicar.Sección 1 es el propósito del documento. No hay requisitos comprobables allí.
Sección 2.1 : Descripción general del proyecto: audiencia: tampoco hay requisitos comprobables.
Sección 2.2 : Hardware y alojamiento: esta sección trata sobre cómo se alojará el sitio de Orange HRM. Ahora bien, ¿esta información es importante para nosotros, los evaluadores? La respuesta es Sí y No. Sí, porque cuando probamos necesitamos tener un entorno que sea similar al entorno de tiempo real.
Esto nos da una idea de cómo debe ser. No, porque no es un requisito comprobable, una especie de requisito previo para que se lleve a cabo la prueba.
Seccion 3: Aquí hay una pantalla de inicio de sesión y los detalles del tipo de cuenta que debemos tener para ingresar al sitio. Este es un requisito comprobable. Por lo tanto, debe ser parte de nuestros escenarios de prueba.
Consulte el documento de escenarios de prueba donde se han agregado escenarios de prueba para algunas secciones del SRS. Para practicar, agregue el resto de los escenarios de manera similar. Sin embargo, voy directamente a la sección 4 del documento.
Sección 4: Requisitos y pautas estéticos / HTML: esta sección explica mejor cómo algunos requisitos pueden no tener sentido para el equipo de prueba en el momento de la revisión del SRS, pero el equipo debe anotarlos como requisitos comprobables de todos modos.
Cómo probarlos y si necesitamos una configuración específica / la ayuda de algún equipo para validarlos son detalles que quizás no conozcamos en este momento. Pero convertirlos en parte de nuestro alcance de prueba es el primer paso para garantizar que no los pasemos por alto.
Ejemplos de escenarios de prueba para la aplicación OrangeHRM: (haga clic para ampliar la imagen)
=> Consulte y descargar el documento de escenarios de prueba para más información.
Algunas observaciones importantes sobre la revisión de SRS
#1) No se debe dejar al descubierto ninguna información.
#2) Realizar análisis de viabilidad sobre si un determinado requisito es correcto o no y también si se puede probar o no.
#3) A menos que exista un rendimiento / seguridad por separado o cualquier otra forma de equipos de prueba, es nuestro trabajo asegurarnos de que todos los requisitos no funcionales deben tenerse en cuenta.
#4) No toda la información está dirigida a los probadores, por lo que es importante comprender qué anotar y qué no.
#5) La importancia y el no. de los casos de prueba para un escenario de prueba no es necesario que sea precisa y se puede completar con un valor aproximado o se puede dejar en blanco.
En resumen, la revisión de SRS da como resultado:
- Lista de escenarios de prueba
- Resultados de la revisión: errores de documentación / requisitos encontrados al revisar / verificar estáticamente el documento SRS
- Una lista de preguntas para una mejor comprensión, en caso de
- La idea preliminar de cómo se supone que es el entorno de prueba
- Identificación del alcance de la prueba y una idea aproximada de cuántos casos de prueba podríamos tener, así que cuánto tiempo necesitamos para la documentación y, finalmente, la ejecución.
Puntos importantes a tener en cuenta:
#1) Los escenarios de prueba no son entregables externos (no se comparten con los analistas comerciales o los equipos de desarrollo), pero son importantes para el consumo de control de calidad interno. Son nuestro primer paso hacia un objetivo de cobertura de prueba del 100%. Una vez que los escenarios de prueba se completan, se someten a una revisión por pares y, una vez que se hace, se consolidan todos.
Para obtener más detalles sobre cómo se revisan los documentos de control de calidad, consulte el artículo: Cómo realizar revisiones de la documentación de prueba en 6 sencillos pasos.
#2) Podríamos utilizar una herramienta de gestión de pruebas como HP ALM o qTest para crear los escenarios de prueba. Sin embargo, la creación de escenarios de prueba en tiempo real es una actividad manual. En mi opinión, es más conveniente manualmente. Dado que es el paso 1, no es necesario que saquemos las armas grandes todavía. Las hojas de Excel simples son la mejor manera de hacerlo.
El siguiente paso de esta serie es que - Trabajaremos en la creación de casos de prueba y avanzaremos en la fase de diseño de pruebas. Antes de eso, también entraremos en - ¿Qué es la planificación de pruebas?¿Dónde encaja en todo el proyecto de control de calidad? Como siempre, trabaje con nosotros para obtener los mejores resultados.
Día 3 de capacitación de control de calidad: Cómo escribir un documento SRS desde cero.
Por favor, continúe recibiendo sus preguntas y comentarios. ¡Apreciamos mucho a sus lectores!
Lectura recomendada
- Programa del curso de pruebas de software: plan de formación detallado del curso en línea
- Curso de pruebas de software: ¿A qué instituto de pruebas de software debo unirme?
- Capacitación sobre pruebas de software: capacitación integral sobre un proyecto en vivo: capacitación gratuita en línea sobre control de calidad, parte 1
- Mejores herramientas de prueba de software 2021 [Herramientas de automatización de pruebas de control de calidad]
- Comentarios y revisiones del curso de pruebas de software
- Preguntas frecuentes sobre el curso de formación sobre control de calidad de pruebas de software
- Recursos y descargas de pruebas de software de control de calidad
- Guía de subcontratación de control de calidad: empresas de subcontratación de pruebas de software