test scenario vs test case
Diferencia entre el escenario de prueba y el caso de prueba.
Hace 6 años , mientras trabajaba con una multinacional de tamaño mediano, cuando sugerí documentar los escenarios de prueba en lugar de perder el tiempo en preparar el documento de prueba completo llamado casos de prueba, todas las cabezas se volvieron hacia mí molestas.
La expresión de los rostros transmitía claramente que cometí un gran error al sugerirlo. Aunque nadie negó la idea, nadie la aceptó. Todos sintieron que seguir la tradición, es decir, escribir documentos de casos de prueba, sería más seguro. No pude discutir.
Después de 4 años , la empresa recibió un proyecto de prueba, donde la única limitación era el tiempo y la única expectativa era la prueba completa pruebas.
Estábamos en la reunión nuevamente y estábamos discutiendo ideas para cumplir con el plazo crítico. La aplicación consistía principalmente en buscar y generar diferentes informes a través de diferentes elementos del menú. Se suponía que documentar los casos de prueba nos arrebataría la mayor parte del tiempo y no estábamos seguros de cuánto iba a utilizar el documento para el cliente.
Sugerí documentar los escenarios de prueba y, de alguna manera, con algunas dudas, todos estuvieron de acuerdo. No es necesario mencionar que podríamos ahorrar un tiempo precioso de documentación y podríamos utilizarlo para realizar pruebas.
Lo que vas a aprender:
- ¿Se están reemplazando rápidamente los casos de prueba con escenarios de prueba?
- ¿Cuándo es importante la documentación de casos de prueba?
- Diferencias entre el escenario de prueba y el caso de prueba en formato tabular
- Conclusión
- Lectura recomendada
¿Se están reemplazando rápidamente los casos de prueba con escenarios de prueba?
Con el tiempo, como todo está cambiando, la industria del software y los procesos también han cambiado mucho.
java agregando elementos a una matriz
Tradicional Cascada y Modelos V están siendo reemplazados por modelos ágiles e iterativos. La documentación es necesaria pero para cumplir con los plazos y hacer que el proceso sea fácil y transparente, se puede cambiar la forma de documentación.
¿Cuándo es importante la documentación de casos de prueba?
- El cliente ha solicitado lo mismo como parte del proyecto.
- No hay límite de tiempo (no creo que sea posible).
- Los probadores son más recientes o desconocidos para el producto.
- Política de la empresa (creo firmemente que se puede cambiar).
Déjame compartir contigo una experiencia:
Mi equipo y yo participamos en la prueba de un proyecto de una empresa Fortune 500 con plazos flexibles. Documentamos casos de prueba con la mejor plantilla disponible y obtuvimos la aprobación del cliente.
Una vez que la compilación comenzó a entregarse al equipo de control de calidad, durante la mayor parte del día, nuestro deber fue seguir mecánicamente 100 casos de prueba por día, actualizar el documento con el resultado de aprobado / reprobado y enviárselo al cliente al final del día. La mayoría de los miembros del equipo comenzaron a quejarse trabajo monótono pero la empresa estaba generando ingresos.
Luego hubo un descanso de un día en el medio sin una nueva construcción para probar. Nos sentamos juntos al comienzo del día y estábamos discutiendo lo que íbamos a hacer ese día. Cuando propuse generar más ideas para mejorar el documento del caso de prueba, todos los miembros del equipo negaron haber realizado esfuerzos.
Según ellos, no había nada más en qué pensar ya que habíamos cubierto todos los escenarios. Y convencerlos de piensa fuera de una caja y genera más ideas fue realmente duro.
La mayoría de las veces, cuando documentamos casos de prueba y eso también una vez aprobado por el cliente, esa mente humana piensa que hemos hecho nuestro trabajo y nuestra mente deja de considerar automáticamente cualquier esfuerzo para pensar en otras formas de probar el producto.
Y créame, cuando se prepara el documento de casos de prueba, solo queremos seguirlo mecánicamente. Dígame cuántas veces en su carrera ha experimentado que usted o su compañero de equipo ofrecieron casos de prueba adicionales al documento de casos de prueba aprobado.
Una experiencia más:
Durante la actividad de desafío del equipo semanal, anunciamos la aplicación y les pedimos a los miembros del equipo que vieran los escenarios de prueba.
cómo dividir cadena por carácter python
Todos los miembros del equipo, incluidos los que respondieron tarde o los que no respondieron, aportaron ideas. ¿Por qué? No había documentación formal en la que tuvieran que completar el resultado esperado para cada secuencia de funcionalidad y condición previa para cada caso de prueba. Recopilamos 40 escenarios de prueba en un día y fue una gran experiencia.
Para favorecer mi experiencia, Me gustaría presentar un ejemplo.
Tome una aplicación de muestra, diga página de inicio de sesión con nombre de usuario, contraseña, inicio de sesión y botones de cancelación. Si se nos pide que escribamos casos de prueba para el mismo, terminaremos escribiendo más de 50 casos de prueba combinando diferentes opciones y detalles.
Pero si se escriben escenarios de prueba, será cuestión de 10 líneas como se muestra a continuación:
Escenario de alto nivel: Funcionalidad de inicio de sesión
Escenarios de bajo nivel :
1. Para comprobar que la aplicación se está iniciando
2. Para comprobar el contenido del texto en la página de inicio de sesión
3. Para comprobar el campo Nombre de usuario
4. Para comprobar el campo Contraseña
5. Para comprobar el botón Iniciar sesión y cancelar la funcionalidad del botón
Ver también=> Más de 180 escenarios de prueba de muestra para probar aplicaciones web y de escritorio.
Como todos tenemos poco tiempo, los escenarios de prueba funcionan como un aerosol analgésico en lugar del IODEX antiguo. Y aún así, el efecto es el mismo.
Diferencias entre el escenario de prueba y el caso de prueba en formato tabular
Finalmente, me gustaría resumir la diferencia entre el escenario de prueba y el caso de prueba:
| Casos de prueba | Escenarios de prueba | |
|---|---|---|
| Que es => | Un concepto que proporciona información detallada sobre qué probar, los pasos a seguir y el resultado esperado de la misma. | Un concepto que proporciona información de una línea sobre qué probar. |
| Se trata de => | Se trata más de documentar detalles. | Se trata más de pensar y discutir los detalles. |
| Importancia => | Es importante cuando las pruebas se realizan en el extranjero y el desarrollo en el sitio. Escribir casos de prueba con detalles ayudará tanto al desarrollador como al equipo de control de calidad a sincronizarse. | Es importante cuando el tiempo es menos y la mayoría de los miembros del equipo pueden estar de acuerdo / comprender los detalles del escenario de una sola línea. |
| Ventaja => | La documentación única de todos los casos de prueba es beneficiosa para rastrear miles de rondas de pruebas de regresión en el futuro. La mayoría de las veces, es útil para informar de errores. El evaluador solo necesita dar una referencia de la identificación del caso de prueba y no requiere mencionar todos y cada uno de los detalles. | Una actividad que ahorra tiempo y genera ideas, preferida por la comunidad de pruebas de software de nueva generación. La modificación y la adición son simples y no específicas de una persona. Para un proyecto enorme, donde un grupo de personas solo conoce módulos específicos, esta actividad les da la oportunidad a todos de mirar otros módulos, hacer una lluvia de ideas y discutir |
| Beneficioso para => | Un documento de caso de prueba de prueba completa es una línea de vida para el nuevo probador. | Se puede lograr una buena cobertura de prueba dividiendo la aplicación en escenarios de prueba y reduce la repetibilidad y complejidad del producto |
| Desventaja => | Consume tiempo y dinero, ya que requiere más recursos para detallar todo sobre qué probar y cómo probar | Si lo crea una persona específica, es posible que el revisor o el otro usuario no sincronice la idea exacta detrás de él. Necesita más discusiones y esfuerzos en equipo. |
Conclusión
Los casos de prueba son la parte más importante del ciclo de vida del desarrollo de software y sin uno, es difícil rastrear, comprender, seguir y razonar algo. Pero en la era de Agile, los casos de prueba se están reemplazando rápidamente con escenarios de prueba.
Una común lista de verificación de prueba para cada tipo de prueba (prueba de base de datos, prueba de GUI, prueba de funcionalidad, etc.) junto con escenarios de prueba es la artillería moderna para probadores de software. Las discusiones, la capacitación, las preguntas y la práctica definitivamente pueden cambiar el gráfico final de tu productividad así como una matriz de informe de errores.
Como de costumbre, agradecemos sus pensamientos y consultas. Sintonice por favor.
PREV Tutorial | SIGUIENTE Tutorial
Lectura recomendada
- Diferencia entre plan de prueba, estrategia de prueba, caso de prueba, guión de prueba, escenario de prueba y condición de prueba
- Tipos de pruebas de software: diferentes tipos de pruebas con detalles
- Cómo escribir casos de prueba: la guía definitiva con ejemplos
- Cómo revisar el documento SRS y crear escenarios de prueba - Capacitación en pruebas de software en un proyecto en vivo - Día 2
- Cómo clasificar escenarios de prueba positivos y negativos: una hoja de trucos para el evaluador
- Pruebas de rendimiento frente a pruebas de carga frente a pruebas de estrés (diferencia)
- Pruebas estáticas y pruebas dinámicas: diferencia entre estas dos importantes técnicas de prueba
- 101 diferencias entre los conceptos básicos de las pruebas de software