Este tutorial explica qué es un escenario de prueba junto con la importancia, implementación, ejemplos y plantillas de un escenario de prueba:
Cualquier funcionalidad/característica de software que pueda probarse se considera un escenario de prueba. La perspectiva del usuario final se tiene en cuenta al escribir cualquier escenario de prueba.
Este tutorial le ayudará a responder a las preguntas: por qué son necesarios los escenarios de prueba, cuándo se escriben los escenarios de prueba y cómo escribir los escenarios de prueba.
¿Qué es un escenario de prueba?
Consideremos una situación hipotética: El océano es inmenso y hay que atravesarlo de una orilla a otra. Por ejemplo, de Mumbai, costa de la India, a Colombo, costa de Srilanka.
Las modalidades de viaje por las que puede optar son:
(i) Vías aéreas: Tomar un vuelo a Colombo
(ii) Vías navegables: prefiera un barco para viajar a Colombo
(iii) Ferrocarril: coger un tren a Srilanka
Pasemos ahora a los escenarios de prueba: Viajar de la orilla del mar de Bombay a la de Colombo es una funcionalidad que hay que probar.
Los escenarios de prueba incluyen:
- Viajar en avión,
- Viajar por vías navegables o
- Viajar en tren.
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 en avión
Los casos de prueba pueden incluir escenarios como:
- El vuelo se realiza según el horario previsto.
- El vuelo no es según el horario previsto.
- Se ha producido una situación de emergencia (fuertes lluvias y tormenta).
Del mismo modo, se puede escribir un conjunto separado de casos de prueba para otros escenarios restantes.
Pasemos ahora a los escenarios de las pruebas tecnológicas.
Cualquier cosa que pueda probarse es un escenario de prueba. Por lo tanto, podemos afirmar que cualquier funcionalidad de software sometida a prueba puede dividirse en varias funcionalidades más pequeñas y denominarse "escenario de prueba".
Antes de entregar cualquier producto al cliente, hay que valorar y evaluar su calidad. El escenario de pruebas ayuda a evaluar la calidad funcional de una aplicación de software que se ajusta a sus requisitos empresariales.
Es un proceso en el que el probador prueba una aplicación informática desde la perspectiva del usuario final. El rendimiento y la calidad de la aplicación informática se evalúan a fondo antes de implantarla en el entorno de producción.
Importancia del escenario de pruebas
- Un Escenario de Prueba puede tener múltiples 'Casos de Prueba'. Se puede imaginar como una gran imagen panorámica y los casos de prueba son las pequeñas partes que son importantes para completar el panorama.
- Se trata de una declaración de una sola línea y los casos de prueba comprenden 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 del servicio de taxi contratado.
Esto tendrá múltiples casos de prueba como se indica a continuación:
(i) Forma de pago a utilizar: PayPal, Paytm, Tarjeta de crédito/débito.
(ii) El pago se ha realizado correctamente.
(iii) El pago realizado no ha tenido éxito.
(iv) El proceso de pago se interrumpió entre medias.
(v) No se puede acceder a los métodos de pago.
(vi) La aplicación se rompe entre medias.
- Los escenarios de prueba ayudan a evaluar la aplicación de software según las situaciones del mundo real.
- Los escenarios de prueba, una vez determinados, 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 informática.
- Las pruebas prioritarias de las funcionalidades contribuyen en gran medida al éxito de la aplicación informática.
- A medida que se priorizan los escenarios de prueba, las funcionalidades más importantes pueden identificarse fácilmente y probarse de forma prioritaria, lo que garantiza que la mayoría de las funcionalidades cruciales funcionan correctamente y que los defectos relacionados con ellas se capturan y rectifican debidamente.
- Los escenarios de prueba determinan el flujo del proceso de negocio del software y, por tanto, es posible probar la aplicación de principio a fin.
Diferencia entre escenario de prueba y caso de prueba
| Escenario de prueba | Casos de prueba |
|---|---|
| El escenario de pruebas 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 y las historias de usuario. | Los casos de prueba se derivan de los Escenarios de prueba . |
| El escenario de la prueba es "qué funcionalidad se va a probar". | Los Casos de Prueba son ' Cómo probar la funcionalidad '. |
| Los escenarios de prueba tienen múltiples casos de prueba. | El caso de prueba puede o no estar asociado a varios escenarios de prueba. |
| Los escenarios de pruebas individuales nunca son repetibles. | Un mismo caso de prueba puede utilizarse varias veces en distintos escenarios. |
| Breve documentación requerida. | Se requiere documentación detallada. |
| Se requieren sesiones de lluvia de ideas para finalizar un Escenario de Pruebas. | Se requieren conocimientos técnicos detallados de la aplicación informática |
| Ahorra tiempo, ya que no se necesitan detalles minuciosos. | Lleva mucho tiempo, ya que hay que cuidar hasta el más mínimo detalle. |
| El coste de mantenimiento es bajo, ya que los recursos necesarios son reducidos. | El coste de mantenimiento es elevado, ya que se necesitan muchos recursos |
¿Por qué son indispensables los escenarios de prueba?
Los escenarios de pruebas se derivan de los requisitos o las historias de usuario.
- Tomemos el ejemplo de un escenario de prueba para la reserva de un taxi.
- Los escenarios podrían ser opciones de reserva de taxi, métodos de pago, seguimiento por GPS, mapa de carreteras mostrado correctamente o no, detalles del taxi y del conductor mostrados correctamente o no, etc., todos están listados en la plantilla de escenarios de prueba.
- Supongamos ahora que el escenario de prueba consiste en comprobar si los servicios de localización están activados y, si no lo están, mostrar el mensaje "Activar servicios de localización". Este escenario se ha omitido y no figura en la plantilla de escenarios de prueba.
- El escenario "Servicio de localización" da lugar a otros escenarios de prueba relacionados con él.
Pueden ser:
- Servicio de localización en gris.
- El servicio de localización activado pero sin internet.
- Restricciones a los servicios in situ.
- Se muestra una ubicación incorrecta.
- Falta un solo escenario puede significar perderse muchas otras escenarios cruciales o casos de prueba Esto puede tener un gran impacto negativo al implantar la aplicación informática, lo que supone una gran pérdida de recursos (plazos).
- Los escenarios de prueba ayudan en gran medida a evitar pruebas exhaustivas Garantiza que todos los flujos de negocio cruciales y esperados se prueben, lo que ayuda aún más en las pruebas de extremo a extremo de la aplicación.
- Así se ahorra tiempo. Además, no es necesaria una descripción mucho más detallada de los casos de prueba, sino que se especifica una descripción de una sola línea sobre lo que hay que probar.
- Los escenarios de prueba se escriben después de sesiones de brainstorming De este modo, se reduce al mínimo la probabilidad de que se pierda alguna situación (crucial o menor), teniendo en cuenta tanto los aspectos técnicos como el flujo de negocio de la aplicación informática.
- Además, los escenarios de prueba pueden ser aprobados por un Analista de Negocio Cliente o por ambos que tengan un conocimiento explícito de la aplicación sometida a prueba.
Los escenarios de prueba son, por tanto, una parte indispensable del SDLC.
Realización de escenarios de prueba
Veamos la implementación de escenarios de prueba o cómo escribir escenarios de prueba:
- Se forman épicas/requisitos empresariales.
- Ejemplo de épica : Crea una cuenta de Gmail. Épica puede ser la característica principal de una aplicación o un requisito empresarial.
- Las epopeyas se dividen en historias de usuario más pequeñas a lo largo de los sprints.
- Las historias de usuario se derivan de las epopeyas, que tienen que ser definidas y aprobadas por las partes interesadas.
- Los escenarios de prueba se derivan de las historias de usuario o BRS (Business Requirement Document), SRS (System Requirement Specification Document), o FRS (Functional Requirement Document) que se finalizan y baselinizan.
- Los probadores escriben los escenarios de las pruebas.
- Estos escenarios de prueba son aprobados por el jefe de equipo, el analista de negocio o el jefe de proyecto, dependiendo de la organización.
- Cada escenario de prueba debe estar vinculado al menos a una historia de usuario.
- Deben identificarse escenarios de prueba tanto positivos como negativos.
- Las historias de usuario comprenden 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. Al redactar los criterios de aceptación se tienen en cuenta las expectativas del cliente y también los malentendidos.
- Estos son únicos para una historia de usuario y cada historia de usuario debe tener al menos un criterio de aceptación que debe poder probarse de forma independiente.
- Los criterios de aceptación ayudan a determinar qué características están dentro y cuáles fuera del alcance de un proyecto. Estos criterios deben incluir características funcionales y no funcionales.
- Los analistas de negocio redactan los criterios de aceptación y el propietario del producto los aprueba.
- O, en algunos casos, el propio propietario del producto puede redactar los criterios.
- Los escenarios de prueba pueden obtenerse a partir de los criterios de aceptación.
Ejemplos de escenarios de prueba
#1) Escenarios de prueba para Kindle App
Kindle es la aplicación que permite a los lectores electrónicos buscar libros electrónicos en Internet, descargarlos y comprarlos. Amazon Kindle ofrece al lector de libros electrónicos la experiencia real de tener un libro en la mano y leerlo. Incluso el paso de las páginas se simula perfectamente en la aplicación.
Anotemos ahora los escenarios de prueba. ( Nota: A continuación se enumeran escenarios limitados para tener una idea general para escribir el escenario de prueba. Puede haber múltiples casos de prueba derivados de él).
| Escenarios de prueba # | Escenarios de prueba |
|---|---|
| 1 | Compruebe si la aplicación Kindle se inicia correctamente. |
| 2 | Comprueba que la resolución de la pantalla se ajusta a los distintos dispositivos una vez iniciada la aplicación. |
| 3 | Compruebe que el texto mostrado es legible. |
| 4 | Compruebe que las opciones de acercar y alejar funcionan. |
| 5 | Comprueba que los archivos compatibles importados en la aplicación Kindle son legibles. |
| 6 | Verifica la capacidad de almacenamiento de Kindle App. |
| 7 | Compruebe que la función de descarga funciona correctamente. |
| 8 | Compruebe que la simulación del paso de página funciona correctamente |
| 9 | Comprueba la compatibilidad de los formatos de los libros electrónicos con la aplicación Kindle. |
| 10 | Comprueba las fuentes compatibles con la aplicación Kindle. |
| 11 | Comprueba la duración de la batería utilizada por la aplicación Kindle. |
| 12 | Verifica el rendimiento del Kindle en función de la conectividad de red (Wi-Fi, 3G o 4G). |
Se pueden derivar múltiples casos de prueba de cada escenario de prueba indicado anteriormente.
#2) Criterios de aceptación de Google Docs
Google Docs es una aplicación web que permite crear, editar y compartir documentos de texto, 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 pueden compartirse como página web o documento listo para imprimir. El usuario puede establecer restricciones sobre quién puede ver y editar los documentos. Un mismo documento puede ser compartido y trabajado en colaboración por diversas personas de distintas ubicaciones geográficas.
A continuación se mencionan escenarios de prueba limitados para una comprensión general. Los escenarios de pruebas en profundidad para Google Docs pueden ser un tema aparte.
| Criterios de aceptación | Criterios de aceptación |
|---|---|
| 1 | Word, Hojas o Formularios pueden abrirse correctamente 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, añadir texto, eliminar texto, insertar diapositiva). |
| 5 | Si la conexión a Internet no está disponible temporalmente, el archivo puede almacenarse localmente y cargarse cuando esté disponible la conexión a Internet. |
| 6 | Los cambios realizados por varios usuarios no se sobrescriben. |
| 7 | Varios usuarios pueden trabajar en un mismo documento. |
| 8 | El trabajo realizado se guarda si se pierde la conexión a Internet mientras se carga un archivo. |
| 9 | Las restricciones de uso compartido se aplican correctamente. |
| 10 | Los usuarios con restricciones de visualización no pueden editar los documentos. |
| 11 | Los documentos pueden publicarse en Internet para el público en general. |
| 12 | Las modificaciones realizadas en los documentos se guardan con sello de tiempo & sello; detalles del autor. |
El número de escenarios de prueba será múltiple y muy grande para Google Docs. En tales casos, por lo general, sólo los criterios de aceptación son establecidos y aprobados por las partes interesadas, 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 aplicaciones enormes.
Estos criterios de aceptación desempeñan un papel fundamental en la planificación del proceso iterativo y nunca deben pasarse por alto. Definirlos de antemano y por adelantado evita sorpresas o sobresaltos al final de los sprints o las versiones.
Dado una condición previa.
En para realizar una acción.
Entonces el resultado es el esperado.
Los formatos Dado, Cuándo y Entonces son útiles para especificar los criterios de aceptación.
Ejemplo de plantilla de escenario de prueba
| Utilice el número de identificación de la historia | Escenario de prueba ID # | Versión # | Escenarios de prueba | # Nº de casos de prueba | Importancia |
|---|---|---|---|---|---|
| USID12.1 | TSID12.1.1 | Kin12.4 | Compruebe si la aplicación Kindle se inicia correctamente. | 4 | Alta |
| USID12.1 | TSID12.1.2 | Kin12.4 | Verifica la capacidad de almacenamiento de Kindle App. | 3 | Medio |
Conclusión
En cualquier prueba de software, la comprensión del ciclo de vida y el establecimiento de los escenarios de prueba es un elemento muy importante. La calidad del software puede mejorar si se dispone de una buena base para los escenarios de prueba. Con frecuencia, el uso de casos de prueba y escenarios de prueba puede intercambiarse.
Sin embargo, la regla general es que el escenario de prueba se utiliza para escribir múltiples casos de prueba o podemos decir que los casos de prueba se derivan de los escenarios de prueba. Los escenarios de prueba bien definidos garantizan un software de buena calidad.