what is test scenario
Este tutorial explica qué es el escenario de prueba junto con la importancia, la implementación, los ejemplos y las plantillas del escenario de prueba:
Cualquier funcionalidad / característica de software que pueda probarse se considera un escenario de prueba. La perspectiva del usuario final se considera al escribir los escenarios de prueba.
Este tutorial le ayudará a responder las preguntas: por qué se requieren escenarios de prueba, cuándo se escriben los escenarios de prueba y cómo escribir los escenarios de prueba.
Lo que vas a aprender:
¿Qué es un escenario de prueba?
Considere una situación hipotética: Hay un vasto océano. Tienes que viajar a través del océano de una orilla a otra. Por ejemplo, desde Mumbai, India Seashore hasta Colombo, Srilanka seashore.
El modo de viaje que puede optar es:
(i) Vías aéreas: Tome un vuelo a Colombo

(ii) Vías fluviales:Prefiere un barco para viajar a Colombo

(iii) Ferrocarriles:Tome un tren a Srilanka

Ahora para los escenarios de prueba: Viajar desde la costa de Mumbai hasta la costa de Colombo es una funcionalidad que debe probarse.
Los escenarios de prueba incluyen:
- Viajando por Airways,
- Viajando por vías fluviales o
- Viajar por ferrocarril.
Estos escenarios de prueba tendrán casos de prueba.
Los casos de prueba que se pueden escribir para los escenarios de prueba anteriores incluyen:
Escenario de prueba: Viajar por vía aérea
Los casos de prueba pueden incluir escenarios como:
- El vuelo es según el horario programado.
- El vuelo no se ajusta a la hora prevista.
- Se ha producido una situación de emergencia (fuertes lluvias y tormentas).
De la misma manera, se puede escribir un conjunto separado de casos de prueba para otros escenarios restantes.
Ahora vayamos a los escenarios de prueba tecnológica.
Todo lo que pueda probarse es un escenario de prueba. Por lo tanto, podemos afirmar que cualquier funcionalidad de software que se esté probando y se puede dividir en múltiples funcionalidades más pequeñas y se puede denominar 'Escenario de prueba'.
Antes de entregar cualquier producto al cliente, se debe evaluar y evaluar la calidad del producto. El escenario de prueba ayuda a evaluar la calidad funcional de una aplicación de software que cumple con sus requisitos comerciales.
El escenario del probador es un proceso en el que el probador prueba la aplicación de software desde la perspectiva del usuario final. El rendimiento y la calidad de la aplicación de software se evalúan minuciosamente antes de su implementación en el entorno de producción.
Importancia del escenario de prueba
- Un escenario de prueba puede tener varios 'casos de prueba'. Puede figurar como una gran imagen panorámica y los casos de prueba son las partes pequeñas que son importantes para completar el panorama.
- Es una declaración de una sola línea y los casos de prueba forman parte de una descripción paso a paso para completar el propósito de la declaración del escenario de prueba.
- Ejemplo:
Escenario de prueba: Realice el pago por el servicio de taxi disponible.
Esto tendrá varios casos de prueba como se indica a continuación:
(yo) Forma de pago a utilizar: PayPal, Paytm, Tarjeta de crédito / débito.
(ii) El pagohecho es exitoso.
(iii) El pago realizado no se realizó correctamente.
(iv) El pagoproceso abortado en el medio.
(v) No se puede acceder a los métodos de pago.
(nosotros) La aplicaciónse rompe en el medio.
- Los escenarios de prueba ayudan a evaluar la aplicación de software según las situaciones del mundo real.
- Los escenarios de prueba, cuando se determinan, ayudan a bifurcar el alcance de las pruebas.
- Esta bifurcación se denomina priorización que ayuda a determinar las funcionalidades importantes de la aplicación de software.
- Las pruebas priorizadas de las funcionalidades ayudan en gran medida a la implementación exitosa de la aplicación de software.
- A medida que se priorizan los escenarios de prueba, las funcionalidades más importantes pueden identificarse fácilmente y probarse con prioridad. Esto asegura que la mayoría de las funcionalidades cruciales estén funcionando bien y que los defectos relacionados con ellas se capturen y rectifiquen debidamente.
- Los escenarios de prueba determinan el flujo del proceso empresarial del software y, por lo tanto, es posible realizar pruebas de un extremo a otro de la aplicación.
Diferencia entre el escenario de prueba y el caso de prueba

| Escenario de prueba | Casos de prueba |
|---|---|
| Se requiere documentación breve. | Se requiere documentación detallada. |
| El escenario de prueba es un concepto. | Los casos de prueba son las soluciones para verificar ese concepto. |
| El escenario de prueba es una funcionalidad de alto nivel. | Los casos de prueba son procedimientos detallados para probar la funcionalidad de alto nivel. |
| Los escenarios de prueba se derivan de los requisitos / historias de usuarios. | Los casos de prueba se derivan de escenarios de prueba. |
| El escenario de prueba es 'Qué funcionalidad se va a probar' | Los casos de prueba son 'Cómo probar la funcionalidad'. |
| Los escenarios de prueba tienen varios casos de prueba. | El caso de prueba puede estar asociado o no a múltiples escenarios de prueba. |
| Los escenarios de prueba únicos nunca son repetibles. | El caso de prueba único se puede utilizar varias veces en diferentes escenarios. |
| Se requieren sesiones de lluvia de ideas para finalizar un escenario de prueba. | Se requieren conocimientos técnicos detallados de la aplicación de software |
| Ahorro de tiempo ya que no se requieren detalles minuciosos. | Consume mucho tiempo, ya que hay que cuidar cada detalle. |
| El costo de mantenimiento es bajo ya que los recursos necesarios son bajos. | El costo de mantenimiento es alto ya que los recursos necesarios son altos |
¿Por qué son indispensables los escenarios de prueba?
Los escenarios de prueba se derivan de requisitos o historias de usuarios.
- Tomemos el ejemplo de un escenario de prueba para la reserva de taxis.
- Los escenarios pueden ser como opciones de reserva de taxis, métodos de pago, rastreo por GPS, mapa de carreteras mostrado correctamente o no, detalles de la cabina y del conductor mostrados correctamente o no, etc. Todos se enumeran en la plantilla de escenario de prueba.
- Ahora suponga que el escenario de prueba es para verificar si los servicios de ubicación están activados, si no están activados, se muestra el mensaje 'Activar servicios de ubicación'. Este escenario no se incluye y no se incluye en la plantilla de escenarios de prueba.
- El escenario 'Servicio de ubicación' da lugar a otros escenarios de prueba relacionados con él. Estos pueden ser:
- El servicio de ubicación está atenuado.
- El servicio de ubicación está encendido pero no hay Internet.
- Restricciones para los servicios de ubicación.
- Se muestra la ubicación incorrecta.
- Falta un solo escenario puede significar perderse muchos otros escenarios cruciales o casos de prueba . Esto puede tener un gran impacto negativo mientras implementa la aplicación de software. Esto da lugar a una gran pérdida de recursos (plazos).
- Los escenarios de prueba ayudan en gran medida a evitando pruebas exhaustivas . Garantiza que se prueben todos los flujos comerciales cruciales y esperados, lo que ayuda aún más en las pruebas de un extremo a otro de la aplicación.
- Estos son ahorradores de tiempo. Además, no se requiere una descripción mucho más detallada según los casos de prueba. Se especifica una descripción de una sola línea sobre qué probar.
- Los escenarios de prueba se escriben después sesiones de lluvia de ideas de los miembros del equipo. Por lo tanto, la probabilidad de perder cualquier escenario (crucial o menor) es mínima. Esto se hace teniendo en cuenta los aspectos técnicos y también el flujo comercial de la aplicación de software.
- Además, los escenarios de prueba pueden ser aprobados por Business Analyst o Client o ambos que tengan el conocimiento explícito de la aplicación bajo prueba.
Los escenarios de prueba son, por tanto, una parte indispensable de SDLC.
Preguntas y respuestas de la entrevista del servidor SQL por 5 años de experiencia
Implementación de escenarios de prueba
Veamos la implementación de escenarios de prueba o cómo escribir escenarios de prueba-
- Se forman Epics / Business Requirements.
- Ejemplo de épica : Crea una cuenta de Gmail. Epic puede ser la característica principal de una aplicación o un requisito comercial.
- Las epopeyas se dividen en historias de usuarios más pequeñas a través de sprints.
- Las historias de usuario se derivan de Epics. Estas historias de usuarios deben tener una base de referencia y ser aprobadas por las partes interesadas.


- Los escenarios de prueba se derivan de historias de usuario o BRS (Documento de requisitos comerciales), SRS (Documento de especificación de requisitos del sistema) o FRS (Documento de requisitos funcionales) que está finalizado y establecido como base.
- Los probadores escriben los escenarios de prueba.
- Estos escenarios de prueba son aprobados por Team Lead, Business Analyst o Project Manager, según la organización.
- Cada escenario de prueba debe estar vinculado al menos a una historia de usuario.
- Deben identificarse escenarios de prueba positivos y negativos.
- Las historias de usuario forman parte de Criterios de aceptación como :
- Los criterios de aceptación son una lista de condiciones o el estado de intención de los requisitos del cliente. Las expectativas del cliente y también los malentendidos se consideran al escribir los criterios de aceptación.
- Estos son únicos para una historia de usuario y cada historia de usuario debe tener al menos un criterio de aceptación que debe ser comprobable de forma independiente.
- Los criterios de aceptación ayudan a determinar qué características están dentro del alcance y cuáles están fuera del alcance de un proyecto. Estos criterios deben incluir características funcionales y no funcionales.
- Los analistas comerciales escriben los criterios de aceptación y el propietario del producto los aprueba.
- O en algunos casos, el propietario del producto puede escribir los criterios él mismo.
- Los escenarios de prueba se pueden obtener a partir de los criterios de aceptación.
Ejemplos de escenarios de prueba
# 1) Escenarios de prueba para la aplicación Kindle
Kindle es la aplicación que permite a sus lectores electrónicos buscar libros electrónicos en línea, descargarlos y comprarlos. Amazon Kindle ofrece al lector de libros electrónicos la experiencia de la vida real de sostener un libro en la mano y leerlo. Incluso el paso de páginas se simula muy bien en la aplicación.
Ahora anotemos los escenarios de prueba. ( Nota: A continuación se enumeran escenarios limitados para tener una idea general de cómo escribir el escenario de prueba. Puede haber varios casos de prueba derivados de él).
| Escenarios de prueba # | Escenarios de prueba |
|---|---|
| 7 | Verifique que la funcionalidad de descarga funcione correctamente. |
| 1 | Verifique si la aplicación Kindle se inicia correctamente. |
| 2 | Verifique que la resolución de la pantalla se ajuste según los diferentes dispositivos, después del lanzamiento de la aplicación |
| 3 | Verifique que el texto mostrado sea legible. |
| 4 | Verifique que las opciones de acercar y alejar funcionen. |
| 5 | Verifique que los archivos compatibles importados en la aplicación Kindle sean legibles. |
| 6 | Verifique la capacidad de almacenamiento de la aplicación Kindle. |
| 8 | Verifique que la simulación de cambio de página funcione correctamente |
| 9 | Verifique la compatibilidad de los formatos de libros electrónicos con la aplicación Kindle. |
| 10 | Verifique las fuentes compatibles con la aplicación Kindle. |
| 11 | Verifique la duración de la batería utilizada por la aplicación Kindle. |
| 12 | Verifique el rendimiento del Kindle según la conectividad de la red (Wi-Fi, 3G o 4G). |
Se pueden derivar varios casos de prueba de cada escenario de prueba indicado anteriormente.
# 2) Criterios de aceptación para Google Docs
'Google docs' es una aplicación basada en web para crear, editar y compartir documentos de Word, hojas de cálculo, diapositivas y formularios. Se puede acceder a todos los archivos en línea mediante un navegador web con conexión a Internet.
Los documentos creados se pueden compartir como una página web o un documento listo para imprimir. El usuario puede establecer restricciones sobre quién puede ver y editar los documentos. Un solo documento puede ser compartido y trabajado en colaboración por diversas personas de diferentes ubicaciones geográficas.
Los escenarios de prueba limitados se mencionan a continuación para una comprensión general. Los escenarios de prueba en profundidad para los documentos de Google pueden ser un tema completamente separado.
| Criterios de aceptación # | Criterios de aceptación |
|---|---|
| 7 | Varios usuarios pueden trabajar en un solo documento. |
| 1 | Word, Sheets o Forms se pueden abrir con éxito sin errores. |
| 2 | Hay plantillas disponibles para documentos, hojas y diapositivas. |
| 3 | Las plantillas disponibles son accesibles para los usuarios. |
| 4 | La plantilla utilizada es editable (por ejemplo: fuentes, tamaño de fuente, agregar texto, eliminar texto, insertar diapositiva). |
| 5 | Si la conexión a Internet no está disponible temporalmente, el archivo puede almacenarse localmente y cargarse según la disponibilidad de conexión a Internet. |
| 6 | Los cambios realizados por varios usuarios no se sobrescriben. |
| 8 | El trabajo realizado se almacena si se pierde la conexión a Internet mientras se carga un archivo. |
| 9 | Las restricciones para compartir se aplican correctamente. |
| 10 | Los usuarios con restricción de vista no pueden editar los documentos. |
| 11 | Los documentos se pueden publicar en Internet para el público en general. |
| 12 | Las alteraciones realizadas en los documentos se guardan con la marca de tiempo y los detalles del autor. |
La cantidad de escenarios de prueba será múltiple y muy grande para Google Docs. En tales casos, por lo general, las partes interesadas solo establecen y aprueban los criterios de aceptación, y los miembros del equipo trabajan en estos criterios de aceptación. Escribir casos de prueba o más bien escenarios de prueba puede ser una tarea exhaustiva para grandes aplicaciones.
Estos criterios de aceptación juegan un papel importante en la planificación de procesos iterativos y nunca deben pasarse por alto. Definirlos de antemano y por adelantado evita sorpresas o choques al final de los sprints o lanzamientos.
Dado una condición previa.
Cuando hacer una acción.
Entonces el resultado esperado.
Los formatos de Dado, Cuándo y Entonces son útiles para especificar los criterios de aceptación.
Ejemplo de plantilla de escenario de prueba
| Usar número de ID de historia | ID de escenario de prueba # | Versión # | Escenarios de prueba | # No de casos de prueba | Importancia |
|---|---|---|---|---|---|
| USID12.1 | TSID12.1.1 | Kin12.4 | Verifique si la aplicación Kindle se inicia correctamente. | 4 | Alto |
| USID12.1 | TSID12.1.2 | Kin12.4 | Verifique la capacidad de almacenamiento de la aplicación Kindle. | 3 | Medio |
Conclusión
En cualquier ciclo de vida de prueba de software, comprender y establecer los escenarios de prueba es un elemento muy importante. La calidad del software se puede mejorar si se tiene una buena base para escenarios de prueba. Con frecuencia, el uso de casos de prueba y escenarios de prueba puede intercambiarse.
Sin embargo, la regla del pulgar es que el escenario de prueba se usa para escribir múltiples casos de prueba o podemos decir que los casos de prueba se derivan de escenarios de prueba. Los escenarios de prueba bien definidos garantizan un software de buena calidad.
Lectura recomendada
- Plantilla de plan de prueba de software de muestra con formato y contenido
- Plantilla de caso de prueba de muestra con ejemplos de casos de prueba (Descargar)
- Plantilla de muestra para el informe de prueba de aceptación con ejemplos
- Plantillas en C ++ con ejemplos
- Tutorial de Python DateTime con ejemplos
- Cortar comando en Unix con ejemplos
- Escenario de prueba versus caso de prueba: ¿Cuál es la diferencia entre estos?
- Plugin de Blazemeter y plantilla de Jmeter