how classify positive
Puedes hacer algo de la manera fácil o difícil; lo importante es que lo hagas. Hay pocas cosas sencillas de la vida cotidiana, pero sin confianza, algo sobre ellas no encaja del todo en nuestras mentes y el alcance del éxito es impredecible.
Tomemos un ejemplo simple hoy y busquemos atajos que no solo aclararán los conceptos, sino que también se asegurarán de que siempre lo haga bien.
Clasificación positiva o negativa de escenarios / casos de prueba
El proceso de diseño de la prueba es triple:
- Identificar requisitos
- Escribir escenarios de prueba (punteros de una línea de qué probar)
- Diseñar instrucciones detalladas sobre cómo realizar pruebas (casos de prueba)
Al escribir escenarios de prueba, los clasificamos en condiciones positivas y negativas. (Cuando lo piensas, ¿es realmente importante hacer esta clasificación? Si es así, ¿para qué sirve? Tenemos que probarlos todos de todos modos, ¿no es así?) También me supera, en su mayor parte. Pero creo que es un intento de establecer una cobertura adecuada y ayuda a establecer que estamos probando tanto el camino feliz como el alternativo que se supone que debe manejar el sistema. Comente a continuación, si conoce otras razones por las que se hace esto.
Ahora, veamos algunos requisitos, escribamos escenarios de prueba y realicemos la clasificación.
# 1) Iniciar sesión :Un usuario que ingresa las credenciales correctas ingresa al sistema. Si las credenciales son incorrectas, se deniega el acceso y se muestra un mensaje de error.
# 2) Ver productos: Supongamos que hay un catálogo en línea de todos los productos disponibles en el sistema y que los muestra todos en una lista cuando se hace clic en el vínculo 'Ver productos'.
# 3) Cerrar sesión: Cuando se hace clic en este enlace, el usuario se desconecta.
Voy a escribir algunos escenarios de prueba para estos requisitos.
Cuadro A:La direccion correcta
ID de escenario de prueba | Descripción del escenario de prueba | Positivo negativo |
---|---|---|
TS_login_01 | Validar si el usuario inicia sesión correctamente si las credenciales ingresadas son correctas | Positivo |
TS_login_02 | Validar si el usuario no tiene permitido el acceso cuando las credenciales ingresadas son incorrectas | Negativo |
TS_ViewProduct_01 | Valide si todos los elementos se enumeran cuando se hace clic en el enlace Ver productos | Positivo |
TS_logout_01 | Validar si el usuario que ya inició sesión se desconecta del sistema cuando se hace clic en cerrar sesión | Positivo |
Sin embargo, a veces veo el escenario de prueba escrito así.
Cuadro B: Entradas marcadasRedson escenarios de prueba no válidos.
ID de escenario de prueba | Descripción del escenario de prueba | Positivo negativo |
---|---|---|
TS_login_01 | Validar si el usuario inicia sesión correctamente si las credenciales ingresadas son correctas | Positivo |
TS_login_02 | Validar si el usuario no tiene permitido el acceso cuando las credenciales ingresadas son incorrectas | Negativo |
TS_ViewProduct_01 | Valide si todos los elementos se enumeran cuando se hace clic en el enlace Ver productos | Positivo |
TS_ViewProduct_02 | Valide si todos los elementos no aparecen en la lista cuando se hace clic en el enlace Ver productos | Negativo |
TS_logout_01 | Validar si el usuario que ya inició sesión se desconecta del sistema cuando se hace clic en cerrar sesión | Positivo |
TS_logout_02 | Validar si el usuario no cierra la sesión cuando se hace clic en el enlace de cierre de sesión | Negativo |
En el caso de que el inicio de sesión sea exitoso, existe un caso igual y opuesto cuando no será exitoso. No se supone que todos los requisitos sean así y para ellos, realmente no hay obligación de escribir un escenario negativo.
En pocas palabras: no todos los requisitos deben tener casos negativos.
En este punto, si estás pensando '¿Cómo lo sabré?' O 'Todavía no estoy seguro', aquí tienes una sencilla hoja de trucos que te ayudará.
software de copia de dvd para windows 10
Si hay una generalización que podemos hacer sobre las aplicaciones es que son dinámicas. La entrada (datos, clics, etc.) que proporcionemos hará que la aplicación sea de cierta manera y genere una determinada salida.
Una simple correlación entre las variables de entrada y salida hará que esto sea fácil de comprender.
Intentemos lo siguiente para iniciar sesión:
Aporte | Producción | Positivo negativo |
---|---|---|
Correcto (información de inicio de sesión correcta) | Correcto (usuario conectado) | Positivo |
Incorrecto (información de inicio de sesión incorrecta) | Correcto (un mensaje de error) | Negativo |
Correcto (información de inicio de sesión correcta) | Incorrecto: el inicio de sesión falla | Error / defecto |
Incorrecto (información de inicio de sesión incorrecta) | Incorrecto (el sistema los registra) - '¡Oh, el horror!' :) | Error / defecto |
Entonces, como puede ver en la tabla anterior, podemos decir que categorizamos el flujo primario como positivo y el flujo alternativo (también el comportamiento correcto de la aplicación) está marcado como negativo.
Los dos últimos casos en rojo son, de hecho, errores. Las pruebas se tratan de la validación de los requisitos y, cuando no funcionan como se esperaba, encontramos errores. Dado que no validamos por defectos, los dos últimos casos no son válidos.
Siguiendo la misma línea de pensamiento y aplicándola para cerrar sesión y ver productos, esto es lo que obtendrá.
Aporte | Producción | Positivo negativo |
---|---|---|
Cerrar sesión (clic) | Correcto: cierra sesión | Positivo |
Cerrar sesión (clic) | Incorrecto: permanece registrado | Error / defecto |
Ver productos (clic) | Correcto: muestra productos | Positivo |
Ver productos (clic) | Incorrecto (sin lista o visualización de lista incorrecta) | Error / defecto |
Como puede ver, para estos requisitos, no existe la posibilidad de proporcionar una entrada incorrecta. Por lo tanto, no es necesario que se escriban casos / escenarios de prueba negativos.
Pensamientos concluyentes:
El sistema podría estar sujeto a entradas positivas o negativas. De cualquier manera, el sistema debería generar una salida correcta. Los casos que suelen tratar con una entrada correcta son positivos. Los que son de entrada correcta pero negativa son negativos.
Algunas sugerencias:
#1) Cuando un casos de prueba de extremo a extremo están escritos para UAT o incluso para pruebas del sistema, siempre son los casos de prueba positivos los que entran en el flujo.
#2) A veces, la clasificación es subjetiva.Por ejemplo, si estoy eliminando algo en un sitio y recibo un mensaje de confirmación que me pregunta '¿Está seguro de que desea eliminar esta entrada?' con las opciones Aceptar y Cancelar; según yo, hacer clic en cancelar es un caso positivo. Pero algunos piensan que es negativo, ya que la intención principal de la opción 'Eliminar' es eliminar y no cancelar la operación. Entonces, el juicio de un evaluador también juega un papel en la clasificación.
#3) Para cada caso positivo, no siempre hay un caso negativo igual y opuesto.
El método anterior siempre garantiza una clasificación correcta. Pruébelo usted mismo y dígame, si no es así. :) “Un atajo es a menudo un corte incorrecto.” - ¡Pero entonces, puede que no sea en este caso!
Para obtener una explicación más formal de las pruebas negativas, marque => ¿Qué son las pruebas negativas y cómo escribir casos de prueba negativos?
Sobre el Autor: Este artículo fue escrito por Swati S., miembro del equipo de STH. Únase a su curso de capacitación en control de calidad en vivo aquí: ' ¡La mejor capacitación en pruebas de software que jamás obtendrá! “
Háganos saber si le ha gustado este artículo y desea ver algunos de estos conceptos básicos explicados fácilmente en los próximos artículos.
Sus comentarios, preguntas, comentarios y lectores son muy apreciados y valorados aquí en STH. ¡Feliz prueba!
Lectura recomendada
- Prueba positiva: significado y méritos explicados con escenarios de prueba reales
- Cómo escribir casos de prueba para una página de inicio de sesión (escenarios de muestra)
- ¿Qué son las pruebas negativas y cómo escribir casos de prueba negativos?
- Cómo escribir casos de prueba para cajeros automáticos (escenarios de muestra)
- Scripts eficientes de Selenium y escenarios de resolución de problemas: tutorial de Selenium n. ° 27
- Tipos de pruebas de migración: con escenarios de prueba para cada tipo
- Tutorial de QTP n. ° 24: uso de objetos virtuales y escenarios de recuperación en pruebas de QTP
- Prueba de aplicaciones sanitarias: consejos y escenarios de prueba importantes (parte 2)