Cómo escribir casos de prueba: la guía definitiva con ejemplos

how write test cases

En este tutorial práctico en profundidad sobre cómo escribir casos de prueba, he cubierto los detalles de lo que es un caso de prueba, su definición estándar y las técnicas de diseño de casos de prueba.

¿Qué es un caso de prueba?

Un caso de prueba tiene componentes que describen la entrada, la acción y una respuesta esperada para determinar si una característica de una aplicación está funcionando correctamente.

Un caso de prueba es un conjunto de instrucciones sobre 'CÓMO' para validar un objetivo / objetivo de prueba en particular, que cuando se sigue nos dirá si el comportamiento esperado del sistema se satisface o no.

Lista de tutoriales cubiertos en esta serie de redacción de casos de prueba:

Cómo escribir:

Tutorial #1: ¿Qué es un caso de prueba y cómo escribir casos de prueba? (este tutorial)
Tutorial #2: Plantilla de caso de prueba de muestra con ejemplos (Descargar) (debe leer)
Tutorial #3: Redacción de casos de prueba a partir del documento SRS
Tutorial #4: Cómo escribir casos de prueba para un escenario dado
Tutorial #5: Cómo prepararse para la redacción de casos de prueba
Tutorial #6: Cómo escribir casos de prueba negativos

Ejemplos:

Tutorial #7: Más de 180 casos de prueba de muestra para aplicaciones web y de escritorio
Tutorial #8: Más de 100 escenarios de prueba listos para ejecutar (lista de verificación)

Técnicas de escritura:

Tutorial #9: Gráfico de causa y efecto: técnica de escritura de casos de prueba dinámica
Tutorial #10: Técnica de prueba de transición estatal
Tutorial #11: Técnica de prueba de matriz ortogonal
Tutorial #12: Técnica de adivinación de errores
Tutorial #13: Técnica de diseño de prueba de la tabla de validación de campo (FVT)

Caso de prueba frente a escenarios de prueba:

Tutorial #14: Casos de prueba frente a escenarios de prueba
Tutorial #15: Diferencia entre plan de prueba, estrategia de prueba y caso de prueba

Automatización:

Tutorial #16: Cómo seleccionar casos de prueba correctos para pruebas de automatización
Tutorial #17: Cómo traducir casos de prueba manuales en scripts de automatización

Herramientas de gestión de pruebas:

Tutorial #18: Las mejores herramientas de gestión de pruebas
Tutorial #19: TestLink para la gestión de casos de prueba
Tutorial #20: Creación y gestión de casos de prueba con HP Quality Center
Tutorial #21: Ejecución de casos de prueba con ALM / QC

Casos específicos de dominio:

Tutorial #22: Casos de prueba para aplicaciones ERP
Tutorial #23: Casos de prueba de aplicaciones JAVA
Tutorial #24: Análisis de valor límite y partición de equivalencia

Continuemos con el primer tutorial de esta serie.

Herramientas recomendadas:

Antes de continuar con el proceso de escritura de casos de prueba, recomendamos descargar esta herramienta de administración de casos de prueba. Esto facilitará el proceso de escritura de casos de prueba mencionado en este tutorial:

# 1) TestRail

=> Descargar la herramienta de gestión de casos de prueba TestRail

# 2) TestMonitor

Gestión de pruebas online de alto nivel. Fácil revolucionario.

TestMonitor es una herramienta de gestión de pruebas de un extremo a otro para todas las organizaciones. Un enfoque de prueba simple e intuitivo. Ya sea que esté implementando software empresarial, necesite control de calidad, cree una aplicación de calidad o simplemente necesite una mano amiga en su proyecto de prueba, TestMonitor lo tiene cubierto.

=> Visite el sitio web de TestMonitor

Lo que vas a aprender:

• ¿Qué es un caso de prueba y cómo escribir casos de prueba?
  • ¿Por qué escribimos pruebas?
  • ¿Cómo escribir casos de prueba?
  • Formato básico de declaración de caso de prueba
• Consejos para redactar exámenes
  • • # 1) Mantenlo simple pero no demasiado simple; hazlo complejo pero no demasiado complejo:
    • # 2) Después de documentar los casos de prueba, revíselos una vez como Tester:
    • # 3) Vincula y facilita a los probadores:
    • # 4) Sea un colaborador:
    • # 5) Nunca olvides al usuario final:
• Cómo lograr la excelencia en la documentación de casos de prueba
  • Consejos y trucos útiles
    • # 1) ¿Está su documento de prueba en buen estado?
    • # 2) No olvide cubrir los casos negativos
    • # 3) Tener pasos de prueba atómica
    • # 4) Priorice las pruebas
    • # 5) La secuencia importa
    • # 6) Agregue la marca de tiempo y el nombre del probador a los comentarios
    • # 7) Incluya los detalles del navegador
    • # 8) Mantenga dos hojas separadas: 'Errores' y 'Resumen' en el documento
• Cómo NO escribir pruebas
  • Los 3 problemas más comunes en casos de prueba
    • # 1) Pasos compuestos
    • # 2) El comportamiento de la aplicación se toma como comportamiento esperado
    • # 3) Múltiples condiciones en un caso
• Cómo mejorar la eficiencia de los casos de prueba
  • Colección de documentos para redacción de pruebas
  • Ejemplo real
  • Documento de caso de prueba
  • Recopilación de datos de prueba
• Importancia de estandarizar los casos de prueba
  • Razones para reutilizar casos de prueba
  • ¿Qué es una prueba estándar en pruebas web?
  • Conclusión
  • Lectura recomendada

¿Qué es un caso de prueba y cómo escribir casos de prueba?

Escribir casos efectivos es una habilidad. Y puede aprenderlo de la experiencia y el conocimiento de la aplicación bajo prueba.

Para obtener instrucciones básicas sobre cómo escribir pruebas, consulte el siguiente video:

Los recursos anteriores deberían brindarnos los conceptos básicos del proceso de escritura de la prueba.

Niveles del proceso de escritura de la prueba:

• Nivel 1: En este nivel, escribirás el casos básicos de la especificación disponible y documentación de usuario.
• Nivel 2: Este es el etapa práctica en los que los casos de escritura dependen del flujo funcional y del sistema real de la aplicación.
• Nivel 3: Esta es la etapa en la que agruparás algunos casos y escribir un procedimiento de prueba . El procedimiento de prueba no es más que un grupo de casos pequeños, tal vez un máximo de 10.
• Nivel 4: Automatización del proyecto. Esto minimizará la interacción humana con el sistema y, por lo tanto, el control de calidad puede centrarse en las funcionalidades actualizadas para probar en lugar de permanecer ocupado con las pruebas de regresión.

¿Por qué escribimos pruebas?

El objetivo básico de escribir casos es para validar la cobertura de prueba de una aplicación.

Si trabaja en cualquier organización de CMMi, los estándares de prueba se siguen más de cerca. Escribir casos trae algún tipo de estandarización y minimiza el enfoque ad-hoc en las pruebas.

¿Cómo escribir casos de prueba?

Campos:

• Identificación del caso de prueba
• Unidad para probar: ¿Qué se debe verificar?
• Supuestos
• Datos de prueba: Variables y sus valores
• Pasos a ejecutar
• Resultado Esperado
• Resultado actual
• Contraseña errónea
• Comentarios

Formato básico de declaración de caso de prueba

Verificar
Usando (nombre de la herramienta, nombre de la etiqueta, diálogo, etc.)
Con (condiciones)
A (lo que se devuelve, se muestra, se demuestra)

Verificar: Se utiliza como primera palabra de la declaración de prueba.
Usando: Identificar lo que se está probando. Puede usar 'ingresar' o 'seleccionar' aquí en lugar de usar según la situación.

Para cualquier aplicación, debe cubrir todo tipo de pruebas como:

• Casos funcionales
• Casos negativos
• Casos de valor límite

Mientras escribes estos todos tus Los TC deben ser simples y fáciles de entender .

************************************************

Consejos para redactar exámenes

Una de las actividades más frecuentes y principales de un Probador de software (persona SQA / SQC) es escribir escenarios y casos de prueba.

Hay algunos factores importantes y críticos que están relacionados con esta importante actividad. Primero, tengamos una vista panorámica de esos factores.

Factores importantes involucrados en el proceso de escritura:

a) Los TC son propensos a revisiones y actualizaciones periódicas:

Vivimos en un mundo en constante cambio y lo mismo se aplica también al software. Los cambios en los requisitos de software impactan directamente en los casos. Siempre que se modifican los requisitos, es necesario actualizar los CT.

Sin embargo, no es solo el cambio en el requisito lo que puede causar la revisión y actualización de las CT. Durante la ejecución de los TC, surgen muchas ideas en la mente y se pueden identificar muchas subcondiciones de un solo TC. Todo esto provoca una actualización de los TC y, en ocasiones, incluso conduce a la adición de nuevos TC.

Además, durante las pruebas de regresión, varias correcciones y / o ondas exigen CT revisados ​​o nuevos.

b) Los TC tienden a distribuirse entre los probadores que los ejecutarán:

Por supuesto, difícilmente existe una situación en la que un solo probador ejecute todos los TC. Normalmente, hay varios probadores que prueban diferentes módulos de una sola aplicación. Por lo tanto, los TC se dividen entre los probadores de acuerdo con sus áreas de propiedad de la aplicación bajo prueba.

Algunos TC que están relacionados con la integración de la aplicación pueden ser ejecutados por varios probadores, mientras que los otros TC pueden ser ejecutados por un solo tester.

c) Los CT son propensos a agruparse en clústeres y por lotes:

Es normal y común que los CT que pertenecen a un único escenario de prueba usualmente exijan su ejecución en alguna secuencia específica o en forma de grupo. Puede haber ciertos requisitos previos de un TC que exigen la ejecución de otros TC antes de ejecutarse.

De manera similar, según la lógica comercial de AUT, un solo TC puede contribuir a varias condiciones de prueba y una sola condición de prueba puede constar de múltiples TC.

d) Los CT tienen una tendencia a la interdependencia:

Este también es un comportamiento interesante e importante de los CT que denota que pueden ser interdependientes entre sí. Desde aplicaciones medianas a grandes con lógica empresarial compleja, esta tendencia es más visible.

El área más clara de cualquier aplicación donde definitivamente se puede observar este comportamiento es la interoperabilidad entre diferentes módulos de la misma o incluso diferentes aplicaciones. Simplemente hablando, siempre que los diferentes módulos, una sola aplicación o múltiples aplicaciones, sean interdependientes, el mismo comportamiento se refleja también en los TC.

e) Los TC tienden a distribuirse entre los desarrolladores (especialmente en el entorno de desarrollo impulsado por pruebas):

Un hecho importante acerca de los TC es que estos no solo deben ser utilizados por los probadores. En el caso normal, cuando los desarrolladores solucionan un error, están utilizando indirectamente el TC para solucionar el problema. De manera similar, si se sigue el desarrollo basado en pruebas, los desarrolladores utilizan directamente los TC para construir su lógica y cubrir todos los escenarios en su código que son abordados por los TC.

Consejos para escribir pruebas eficaces:

Teniendo en cuenta los 5 factores anteriores, a continuación se ofrecen algunos consejos para redactar TC eficaces.

¡¡¡Empecemos!!!

# 1) Mantenlo simple pero no demasiado simple; hazlo complejo pero no demasiado complejo:

Esta afirmación parece una paradoja. Pero te prometo que no es así. Mantenga todos los pasos de los TC atómicos y precisos. Mencione los pasos con la secuencia correcta y el mapeo correcto a los resultados esperados. El caso de prueba debe ser autoexplicativo y fácil de entender. Esto es lo que quiero decir para simplificarlo.

Ahora, lo que lo convierte en un medio complejo para integrarlo con el Plan de prueba y otros TC. Consulte los otros TC, artefactos relevantes, GUI, etc., donde y cuando sea necesario. Pero haz esto de forma equilibrada. No haga que un probador se mueva de un lado a otro en la pila de documentos para completar un solo escenario de prueba.

Por otro lado, ni siquiera permita que el probador documente estos TC de una manera muy compacta. Mientras escribe TC, recuerde siempre que usted u otra persona tendrá que revisarlos y actualizarlos.

# 2) Después de documentar los casos de prueba, revíselos una vez como Tester:

Nunca piense que el trabajo está hecho una vez que haya escrito el último TC del escenario de prueba. Vaya al principio y revise todos los TC una vez, pero no con la mentalidad de un redactor de TC o un Planificador de pruebas. Revise todos los TC con la mente de un evaluador. Piense de manera racional e intente ejecutar en seco sus TC.

Evalúe todos los Pasos y vea si los ha mencionado claramente de manera comprensible y si los resultados esperados están en armonía con esos pasos.

Asegúrese de que datos de prueba especificado en los TC es factible no solo para los probadores reales, sino también de acuerdo con el entorno de tiempo real. Asegúrese de que no haya conflictos de dependencia entre los TC y verifique que todas las referencias a otros TC / artefactos / GUI sean precisas. De lo contrario, los probadores pueden tener serios problemas.

# 3) Vincula y facilita a los probadores:

No deje los datos de la prueba en los probadores. Bríndeles una variedad de entradas, especialmente cuando se deben realizar cálculos o el comportamiento de la aplicación depende de las entradas. Puede dejar que ellos decidan los valores de los elementos de datos de prueba, pero nunca les dé la libertad de elegir ellos mismos los elementos de datos de prueba.

Porque, de forma intencionada o no intencionada, pueden utilizar los mismos datos de prueba una y otra vez y algunos datos de prueba importantes pueden ignorarse durante la ejecución de los TC.

Mantenga a los probadores a gusto organizando los TC según las categorías de prueba y las áreas relacionadas de una aplicación. Claramente, instruya y mencione qué CT son interdependientes y / o están agrupados. Asimismo, indique explícitamente qué TC son independientes y están aislados para que el evaluador pueda gestionar su actividad global en consecuencia.

En este punto, es posible que le interese leer sobre el análisis de valor límite, que es una estrategia de diseño de casos de prueba que se utiliza en las pruebas de caja negra. Hacer clic aquí para saber más al respecto.

# 4) Sea un colaborador:

Nunca acepte el FS o el documento de diseño tal como está. Su trabajo no es solo revisar el FS e identificar los escenarios de prueba. Al ser un recurso de control de calidad, no dude en contribuir al negocio y dar sugerencias si cree que se puede mejorar algo en la aplicación.

Sugiera también a los desarrolladores, especialmente en el entorno de desarrollo impulsado por TC. Sugiera las listas desplegables, los controles del calendario, la lista de selección, los botones de radio de grupo, los mensajes más significativos, las precauciones, las indicaciones, las mejoras relacionadas con la usabilidad, etc.

Al ser un QA, no solo pruebe, ¡marque la diferencia!

# 5) Nunca olvides al usuario final:

La parte interesada más importante es el 'Usuario final' que finalmente utilizará la aplicación. Por lo tanto, nunca lo olvides en ninguna etapa de la escritura de TC. De hecho, no se debe ignorar al usuario final en ninguna etapa del SDLC. Sin embargo, mi énfasis hasta ahora solo está relacionado con mi tema.

Por lo tanto, durante la identificación de escenarios de prueba, nunca pase por alto aquellos casos que serán utilizados principalmente por el usuario o los casos que son críticos para el negocio, incluso si se utilizan con menos frecuencia. Manténgase en la piel del Usuario final y luego revise todos los TC y juzgue el valor práctico de ejecutar todos sus TC documentados.

************************************************

Cómo lograr la excelencia en la documentación de casos de prueba

Como tester de software, seguramente estará de acuerdo conmigo en que crear un documento de prueba perfecto es realmente una tarea desafiante.

Siempre dejamos cierto margen de mejora en nuestro Documentación de casos de prueba . A veces, no podemos proporcionar una cobertura de prueba del 100% a través de los TC y, a veces, la plantilla de prueba no está a la altura, o nos falta proporcionar una buena legibilidad y claridad a nuestras pruebas.

Como evaluador, siempre que se le pida que escriba documentación de prueba, no comience simplemente de una manera ad-hoc. Es muy importante comprender el propósito de redactar casos de prueba mucho antes de trabajar en el proceso de documentación.

que es una clave de red para wifi

Las pruebas deben ser siempre claras y lúcidas. Deben estar redactados de manera que ofrezcan al evaluador la facilidad para realizar la prueba completa siguiendo los pasos definidos en cada una de las pruebas.

Además, el documento del caso de prueba debe contener tantos casos como sea necesario para proporcionar cobertura de prueba . Por ejemplo , debe intentar cubrir las pruebas para todos los escenarios posibles que pueden ocurrir dentro de su aplicación de software.

Teniendo en cuenta los puntos anteriores, permítame que lo lleve a través de un recorrido sobre cómo lograr la excelencia en la documentación de prueba.

Consejos y trucos útiles

Aquí, voy a proporcionarle algunas pautas útiles que pueden darle una ventaja en la documentación de su prueba de los demás.

# 1) ¿Está su documento de prueba en buen estado?

La mejor y más sencilla forma de organizar su documento de prueba es dividirlo en muchas secciones útiles. Divida toda la prueba en múltiples escenarios de prueba. Luego divida cada escenario en múltiples pruebas. Finalmente, divida cada caso en varios pasos de prueba.

Si está utilizando Excel, documente cada caso de prueba en una hoja separada del libro de trabajo donde cada caso de prueba describe un flujo de prueba completo.

# 2) No olvide cubrir los casos negativos

Como probador de software, debe pensar fuera de la caja y diseñar todas las posibilidades que ofrece su aplicación. Nosotros, como probadores, tenemos que verificar que si cualquier intento no auténtico de ingresar al software o cualquier dato inválido que fluya a través de la aplicación debe ser detenido e informado.

Por tanto, un caso negativo es tan importante como un caso positivo. Asegúrese de que para cada escenario tenga dos casos de prueba: uno positivo y otro negativo . El positivo debe cubrir el flujo previsto o normal y el negativo debe cubrir el flujo no deseado o excepcional.

# 3) Tener pasos de prueba atómica

Cada paso de prueba debe ser atómico. No debería haber más subpasos. Cuanto más simple y claro sea un paso de prueba, más fácil será continuar con la prueba.

# 4) Priorice las pruebas

A menudo tenemos plazos estrictos para terminar las pruebas de una aplicación. En este caso, es posible que dejemos de probar algunas de las funcionalidades y aspectos importantes del software. Para evitar esto, debe etiquetar una prioridad con cada prueba mientras la documenta.

Puede utilizar cualquier codificación para definir la prioridad de una prueba. Generalmente es mejor utilizar cualquiera de los 3 niveles, alto, medio y bajo , o 1, 50 y 100. Por lo tanto, cuando tenga un cronograma estricto, primero debe completar todas las pruebas de alta prioridad y luego pasar a las pruebas de prioridad media y baja.

Por ejemplo - para un sitio web de compras, verificar la denegación de acceso por un intento no válido de iniciar sesión en la aplicación puede ser un caso de alta prioridad, verificar la visualización de productos relevantes en la pantalla del usuario puede ser un caso de prioridad media y verificar el color del texto que se muestra en los botones de la pantalla pueden ser una prueba de baja prioridad.

# 5) La secuencia importa

Confirme si la secuencia de pasos de la prueba es absolutamente correcta. Una secuencia incorrecta de pasos puede generar confusión. Preferiblemente, los pasos también deben definir la secuencia completa desde que ingresa a la aplicación hasta que sale de la aplicación para un escenario particular que se está probando.

# 6) Agregue la marca de tiempo y el nombre del probador a los comentarios

Puede haber un caso en el que esté probando una aplicación, alguien esté realizando modificaciones en paralelo a la misma aplicación o alguien pueda actualizar la aplicación después de que termine la prueba. Esto conduce a una situación en la que los resultados de su prueba pueden variar con el tiempo.

preguntas de la entrevista de prueba de penetración de aplicaciones web

Por lo tanto, siempre es mejor agregar una marca de tiempo con el nombre del evaluador en los comentarios de la prueba para que el resultado de una prueba (aprobado o reprobado) se pueda atribuir al estado de una aplicación en ese momento en particular. Alternativamente, puede tener un ' Fecha de ejecución 'Columna agregada por separado al caso de prueba que identificará explícitamente la marca de tiempo de la prueba.

# 7) Incluya los detalles del navegador

Como sabe, si se trata de una aplicación web, los resultados de la prueba pueden diferir según el navegador en el que se ejecute la prueba. Para la facilidad de otros evaluadores, desarrolladores o quien esté revisando el documento de prueba, debe agregar el nombre y la versión del navegador al caso para que el defecto se pueda replicar fácilmente.

# 8) Mantenga dos hojas separadas: 'Errores' y 'Resumen' en el documento

Si está documentando en Excel, las dos primeras hojas del libro de trabajo deberían ser Resumen y Errores. La hoja Resumen debe resumir el escenario de prueba y la hoja Errores debe enumerar todos los problemas encontrados durante la prueba. La importancia de agregar estas dos hojas es que brindará una comprensión clara de las pruebas al lector / usuario del documento.

Por lo tanto, cuando el tiempo es limitado, estas dos hojas pueden resultar muy útiles para proporcionar una descripción general de las pruebas.

El documento de prueba debe proporcionar la mejor cobertura de prueba posible, una excelente legibilidad y debe seguir un formato estándar en todo momento.

Podemos lograr la excelencia en la documentación de prueba con solo tener en cuenta algunos consejos esenciales como la organización del documento de caso de prueba, priorizar los TC, tener todo en la secuencia adecuada, incluidos todos los detalles obligatorios para ejecutar un TC, y proporcionar pasos de prueba claros y lúcidos, etc. como se discutió anteriormente.

************************************************

Cómo NO escribir pruebas

Pasamos la mayor parte de nuestro tiempo escribiendo, revisando, ejecutando o manteniendo estos. Es bastante lamentable que las pruebas también sean las más propensas a errores. Las diferencias en la comprensión, las prácticas de prueba de la organización, la falta de tiempo, etc. son algunas de las razones por las que a menudo vemos pruebas que dejan mucho que desear.

Hay muchos artículos en nuestro sitio sobre este tema, pero aquí verá Cómo NO escribir casos de prueba: algunos consejos que serán fundamentales para crear pruebas distintivas, de calidad y efectivas.

Sigamos leyendo y tenga en cuenta que estos consejos son tanto para probadores nuevos como experimentados.

Los 3 problemas más comunes en casos de prueba

1. Pasos compuestos
2. El comportamiento de la aplicación se toma como comportamiento esperado
3. Varias condiciones en un caso

Estos tres tienen que estar en mi lista de los 3 principales problemas comunes en el proceso de redacción de exámenes.

Lo interesante es que esto sucede con probadores nuevos y experimentados y seguimos los mismos procesos defectuosos sin darnos cuenta de que unas pocas medidas simples pueden solucionar las cosas fácilmente.

Vayamos a ello y analicemos cada uno en detalle:

# 1) Pasos compuestos

En primer lugar, ¿qué es un paso compuesto?

Por ejemplo, estás dando instrucciones desde el punto A al punto B: si dices que 'Ve al lugar XYZ y luego al ABC', esto no tendrá mucho sentido, porque aquí nos encontramos pensando: '¿Cómo puedo llegar a XYZ en primer lugar ”- en lugar de comenzar con“ Gire a la izquierda desde aquí y avance 1 milla, luego gire a la derecha en Rd. no 11 para llegar a XYZ ”podría lograr mejores resultados.

Las mismas reglas exactas se aplican a las pruebas y sus pasos también.

Por ejemplo Estoy escribiendo una prueba para Amazon.com: haga un pedido de cualquier producto.

Los siguientes son mis pasos de prueba (Nota: solo estoy escribiendo los pasos y no todas las otras partes de la prueba como el resultado esperado, etc.)

a . Lanzar Amazon.com
b . Busque un producto ingresando la palabra clave / nombre del producto en el campo 'Buscar' en la parte superior de la pantalla.
c . De los resultados de búsqueda que se muestran, elija el primero.
D . Haga clic en Agregar al carrito en la página de detalles del producto.
es . Checkout y pago.
F . Consulta la página de confirmación del pedido.

Ahora, ¿Puede identificar cuál de estos es un paso compuesto? Paso derecho (e)

Recuerde, las pruebas siempre tratan sobre 'Cómo' realizar la prueba, por lo que es importante escribir los pasos exactos de 'Cómo pagar y pagar' en su prueba.

Por lo tanto, el caso anterior es más efectivo cuando se escribe de la siguiente manera:

a . Lanzar Amazon.com
b . Busque un producto ingresando la palabra clave / nombre del producto en el campo 'Buscar' en la parte superior de la pantalla.
c . De los resultados de búsqueda que se muestran, elija el primero.
D . Haga clic en Agregar al carrito en la página de detalles del producto.
es . Haga clic en Pagar en la página del carrito de compras.
F . Ingrese la información de CC, envío y facturación.
gramo . Haga clic en Pagar.
h . Consulta la página de confirmación del pedido.

Por tanto, un paso compuesto es aquel que se puede dividir en varios pasos individuales. La próxima vez que escribamos pruebas, prestemos atención a esta parte y estoy seguro de que estarán de acuerdo conmigo en que lo hacemos con más frecuencia de lo que creemos.

# 2) El comportamiento de la aplicación se toma como comportamiento esperado

Cada vez más proyectos tienen que afrontar esta situación en estos días.

La falta de documentación, la programación extrema, los ciclos de desarrollo rápidos son algunas de las razones que nos obligan a confiar en la aplicación (una versión anterior más o menos) para escribir las pruebas o para basar las pruebas en sí. Como siempre, esta es una mala práctica probada, no siempre realmente.

Es inofensivo siempre que mantenga la mente abierta y tenga la expectativa de que el 'AUT podría tener fallas'. Solo cuando no crees que lo es, las cosas funcionan mal. Como siempre, dejaremos que los ejemplos hablen.

Si la siguiente es la página para la que está escribiendo / diseñando los pasos de prueba:

Caso 1:

Si los pasos de mi caso de prueba son los siguientes:

1. Inicie el sitio de compras.
2. Haga clic en Envío y devolución. Resultado esperado: la página de envío y devolución se muestra con 'Ponga su información aquí' y un botón 'Continuar'.

Entonces, esto es incorrecto.

Caso 2:

1. Inicie el sitio de compras.
2. Haga clic en Envío y devolución.
3. En el cuadro de texto 'Ingrese el número de pedido' presente en esta pantalla, ingrese el número de pedido.
4. Haga clic en Continuar - Resultado esperado: se muestran los detalles del pedido relacionados con el envío y las devoluciones.

El caso 2 es un mejor caso de prueba porque a pesar de que la aplicación de referencia se comporta de manera incorrecta, solo la tomamos como una guía, investigamos más y escribimos el comportamiento esperado según la funcionalidad correcta anticipada.

Línea de fondo: La aplicación como referencia es un atajo rápido, pero conlleva sus propios peligros. Siempre que seamos cuidadosos y críticos, se obtienen resultados sorprendentes.

# 3) Múltiples condiciones en un caso

Una vez más, aprendamos de Ejemplo .

Eche un vistazo a los siguientes pasos de prueba: Los siguientes son los pasos de prueba dentro de una prueba para una función de inicio de sesión.

una. Ingrese detalles válidos y haga clic en Enviar.
B. Deje el campo Nombre de usuario vacío. Haga clic en Enviar.
C. Deje el campo de la contraseña vacío y haga clic en Enviar.
D. Elija un nombre de usuario / contraseña que ya haya iniciado sesión y haga clic en Enviar.

Lo que tenían que ser 4 casos diferentes se combinan en uno. Podrías estar pensando: ¿Qué hay de malo en eso? Está ahorrando mucha documentación y lo que puedo hacer en 4, lo estoy haciendo en 1- ¿no es genial? Bueno, no del todo. ¿Razones?

Sigue leyendo:

• ¿Qué pasa si una de las condiciones falla? Tenemos que marcar toda la prueba como 'fallida'. Si marcamos el caso completo como 'fallido', significa que las 4 condiciones no están funcionando, lo cual no es realmente cierto.
• Las pruebas deben tener un flujo. Desde la condición previa hasta el paso 1 y todos los pasos. Si sigo este caso, en el paso (a), si tiene éxito, iniciaré sesión en la página, donde la opción 'iniciar sesión' ya no está disponible. Entonces, cuando llegue al paso (b), ¿dónde ingresará el probador el nombre de usuario? Verás, el flujo está roto.

Por eso, escribir pruebas modulares . Parece mucho trabajo, pero todo lo que necesitas es separar las cosas y usar a nuestros mejores amigos Ctrl + C y Ctrl + V para trabajar para nosotros. :)

************************************************

Cómo mejorar la eficiencia de los casos de prueba

Los probadores de software deben escribir sus pruebas desde la etapa anterior del ciclo de vida del desarrollo de software, mejor durante la fase de requisitos de software.

El gerente de pruebas o un gerente de control de calidad debe recopilar y preparar la mayor cantidad de documentos posibles según la lista a continuación.

Colección de documentos para redacción de pruebas

# 1) Documento de requisitos del usuario

Es un documento que enumera el proceso comercial, perfiles de usuario, entorno de usuario, interacción con otros sistemas, reemplazo de sistemas existentes, requisitos funcionales, requisitos no funcionales, requisitos de licencia e instalación, requisitos de rendimiento, requisitos de seguridad, usabilidad y requisitos concurrentes, etc. .,

# 2) Documento de caso de uso comercial

Este documento detalla el caso de uso escenario de los requisitos funcionales desde la perspectiva empresarial. Este documento cubre los actores comerciales (o sistema), objetivos, condiciones previas, condiciones posteriores, flujo básico, flujo alternativo, opciones, excepciones de todos y cada uno de los flujos comerciales del sistema según los requisitos.

# 3) Documento de requisitos funcionales

Este documento detalla los requisitos funcionales de cada característica para el sistema bajo requisitos.

Normalmente, el documento de requisitos funcionales sirve como un repositorio común tanto para el equipo de desarrollo y prueba como para las partes interesadas del proyecto, incluidos los clientes, para los requisitos comprometidos (a veces congelados), que deben tratarse como el documento más importante para cualquier desarrollo de software.

# 4) Plan de proyecto de software (opcional)

Un documento que describe los detalles del proyecto, objetivos, prioridades, hitos, actividades, estructura organizativa, estrategia, seguimiento del progreso, análisis de riesgos, supuestos, dependencias, limitaciones, requisitos de formación, responsabilidades del cliente, cronograma del proyecto, etc.

# 5) Plan de prueba / control de calidad

Este documento detalla el sistema de gestión de la calidad, los estándares de documentación, el mecanismo de control de cambios, los módulos críticos y las funcionalidades, el sistema de gestión de la configuración, los planes de prueba, el seguimiento de defectos, los criterios de aceptación, etc.

los Plan de prueba El documento se utiliza para identificar las características que se probarán, las características que no se probarán, las asignaciones del equipo de prueba y su interfaz, los requisitos de recursos, el calendario de pruebas, la redacción de pruebas, la cobertura de las pruebas, los entregables de las pruebas, el requisito previo para la ejecución de las pruebas, el informe de errores y el seguimiento. mecanismo, métricas de prueba, etc.,

Ejemplo real

Veamos cómo escribir casos de prueba de manera eficiente para una pantalla de 'Inicio de sesión' familiar y simple como se muestra en la siguiente figura. los enfoque de prueba será casi el mismo incluso para pantallas complejas con más información y características críticas.

#1) El primer enfoque para cualquier proceso de caso de prueba será obtener un prototipo de pantalla (o marcos de alambre) como el anterior, si está disponible. Es posible que esto no esté disponible para algunas de las funcionalidades y depende de la importancia de diseñar un prototipo en las primeras etapas de desarrollo.

Pero, si un SRS (Especificación de requisitos de software) documento está disponible para el proyecto, la mayoría de los prototipos de pantalla son desarrollados por el equipo del proyecto. Este tipo de pantalla simplifica el trabajo del evaluador y aumenta la eficiencia de las pruebas.

#2) A continuación, el especificaciones de requisitos funcionales . Depende del proceso de organización, estará disponible en un conjunto de múltiples documentos.

Por lo tanto, decida cuál es el mejor documento para redactar casos, ya sea un documento de requisitos del usuario o una especificación de requisitos funcionales (o incluso un documento SRS si el equipo de pruebas lo puede entender cómodamente) que proporcionará un flujo funcional completo de lo seleccionado. característica para ser probado.

#3) Una vez que el prototipo de pantalla y las especificaciones funcionales están en su lugar, el evaluador debe comenzar a escribir los casos con el siguiente enfoque y criterio.

• Pruebas de IU :Los controles / campos que son visibles para el usuario. Hay controles estáticos y dinámicos disponibles para probar la función. Por ejemplo, En la pantalla de inicio de sesión anterior, los textos de 'Nombre de usuario y contraseña' son campos estáticos que no requieren la interacción del usuario, solo para mostrar el texto.

• Casos funcionales :Por otro lado, el botón Iniciar sesión y los Hipervínculos (¿Olvidó su contraseña? Y Registro) son campos dinámicos que requieren la interacción del usuario haciendo clic en los controles, que realizarán alguna acción después.

• Casos de bases de datos :Una vez que el usuario ingresa el nombre de usuario y la contraseña, las pruebas se pueden escribir para verificar la base de datos relacionada, si el nombre de usuario y la contraseña están verificados en la base de datos y la tabla correctas y también el usuario tiene permiso para iniciar sesión en la aplicación bajo prueba.
  

• Pruebas de proceso :Esto está relacionado con el proceso (no las acciones asociadas con los controles visibles disponibles en la pantalla) asociado con la característica y la funcionalidad. Por ejemplo, Si hace clic en el enlace Olvidé mi contraseña en la pantalla de muestra anterior, puede enviar un correo electrónico al usuario. Entonces, tal vez un correo electrónico deba probarse para el proceso y la confirmación adecuados.

4) Finalmente, mantenga el ' Mantra de BAOE ', medio i) Flujo básico ii) Flujo alternativo iii) Opciones y iv) Excepciones para la cobertura completa del flujo funcional y la característica a probar. Todos los conceptos deben aplicarse a pruebas positivas y negativas.

Por ejemplo, Veamos el enfoque BAOE simple para la pantalla de inicio de sesión de muestra anterior.

• Flujo básico: Ingrese la ruta URL del inicio de sesión en cualquier navegador e ingrese la información requerida e inicie sesión en la aplicación.
• Flujo alternativo: Instale la aplicación en un dispositivo móvil e ingrese la información requerida e inicie sesión en la aplicación.
• Opciones: ¿Cuáles son las opciones disponibles para llegar a la misma pantalla de inicio de sesión? Por ejemplo, después de iniciar sesión en la aplicación, al hacer clic en 'Cerrar sesión' puede aparecer la misma pantalla o, si el tiempo de espera de la sesión o la sesión expiró, el usuario puede acceder a la pantalla de inicio de sesión.
• Excepciones: ¿Cuáles son las excepciones si mis pruebas son negativas? Por ejemplo, si se ingresan credenciales incorrectas en la pantalla de inicio de sesión, si el usuario recibirá un mensaje de error o ninguna acción asociada.

Con toda esta información en la mano, comencemos a escribir los TC para la pantalla de inicio de sesión, en un formato con la cobertura y trazabilidad completa y con información detallada. La secuencia lógica y la numeración de identificar el ' ID de caso de prueba ' será muy útil para un historial de ejecución de identificación rápida de casos de prueba.

También leer=> Más de 180 casos de prueba listos para usar de muestra para aplicaciones web y de escritorio.

Documento de caso de prueba

Nota : Las columnas de prueba no se limitan al siguiente documento de prueba de muestra, que se puede mantener en una hoja de Excel para tener tantas columnas como sea necesario para una matriz de trazabilidad completa, a saber, prioridad, propósito de la prueba, tipo de prueba, ubicación de la captura de pantalla del error etc.,

También leer=> Plantilla de caso de prueba de muestra con ejemplos.

Para facilitar la simplicidad y legibilidad de este documento, escribamos los pasos para reproducir, el comportamiento esperado y real de las pruebas para la pantalla de inicio de sesión en detalle a continuación.

Nota : Agregue la columna Comportamiento real al final de esta plantilla.

Recopilación de datos de prueba

Cuando se escribe el caso de prueba, la tarea más importante para cualquier probador es recopilar los datos de prueba. Muchos evaluadores omiten esta actividad y la pasan por alto con la suposición de que los casos de prueba se pueden ejecutar con algunos datos de muestra o datos ficticios y se pueden alimentar cuando los datos realmente se requieren. Este es un concepto erróneo crítico de alimentar datos de muestra o datos de entrada desde la memoria mental en el momento de ejecutar casos de prueba.

Si los datos no se recopilan y actualizan en el documento de prueba en el momento de escribir las pruebas, el evaluador pasaría anormalmente más tiempo para recopilar los datos en el momento de la ejecución de la prueba. Los datos de la prueba deben recopilarse tanto para casos positivos como negativos desde la perspectiva del flujo funcional de la característica. El documento de caso de uso empresarial es muy útil en esta situación.

Encuentre un documento de datos de prueba de muestra para las pruebas escritas anteriormente, que a su vez será útil sobre la eficacia con la que podemos recopilar los datos que facilitarán nuestro trabajo en el momento de la ejecución de la prueba.

************************************************

Importancia de estandarizar los casos de prueba

En este mundo ajetreado, nadie puede hacer cosas repetitivas día tras día con el mismo nivel de interés y energía. Especialmente, no me apasiona hacer la misma tarea una y otra vez en el trabajo. Me gusta gestionar las cosas y ahorrar tiempo. Cualquiera en TI debería serlo.

Todas las empresas de TI ejecutan diferentes tipos de proyectos. Estos proyectos pueden estar basados ​​en productos o servicios. De estos proyectos, la mayoría trabaja en sitios web y prueba del sitio web . La buena noticia es que todos los sitios web tienen muchas similitudes. Y, si los sitios web son para el mismo dominio, también tienen varias características comunes.

La pregunta que siempre me desconcierta es que: “Si la mayoría de las aplicaciones son similares, por ejemplo, como los sitios de venta minorista, que se han probado miles de veces antes,“ ¿Por qué tenemos que escribir casos de prueba para otro sitio de venta minorista desde cero? ' ¿No ahorrará mucho tiempo si extrae los scripts de prueba existentes que se utilizaron para probar un sitio minorista anterior?

Claro, es posible que tengamos que hacer algunos pequeños ajustes, pero en general es más fácil, eficiente, ahorra tiempo y dinero y, por lo tanto, siempre ayuda a mantener altos los niveles de interés de los probadores. ¿A quién le gusta escribir, revisar y mantener los mismos casos de prueba repetidamente, verdad? Reutilizar las pruebas existentes puede resolver esto en gran medida y sus clientes también lo encontrarán inteligente y lógico.

Entonces, lógicamente, comencé a extraer los scripts existentes de proyectos similares basados ​​en la web, hice cambios e hice una revisión rápida de ellos. También utilicé códigos de colores para mostrar los cambios que se realizaron, de modo que el revisor solo pueda centrarse en la parte que se ha cambiado.

Razones para reutilizar casos de prueba

#1) La mayoría de las áreas funcionales de un sitio web son casi: inicio de sesión, registro, agregar al carrito, lista de deseos, pago, opciones de envío, opciones de pago, contenido de la página del producto, productos vistos recientemente, productos relevantes, instalaciones de códigos promocionales, etc.

#2) La mayoría de los proyectos son solo mejoras o cambios en la funcionalidad existente.

#3) Los sistemas de gestión de contenido que definen los espacios para la carga de imágenes con formas estáticas y dinámicas también son comunes para todos los sitios web.

#4) Los sitios web minoristas tienen RSE (Servicio al cliente) también.

#5) Todos los sitios web también utilizan el sistema backend y la aplicación de almacén que utilizan JDA.

#6) El concepto de cookies, tiempo de espera y seguridad también son comunes.

#7) Los proyectos basados ​​en web suelen ser propensos a cambios en los requisitos.

#8) los tipos de pruebas necesarios son comunes como el navegador pruebas de compatibilidad , pruebas de rendimiento , pruebas de seguridad

Verá, hay muchas cosas que son comunes y similares.

Habiendo dicho que la reutilización es el camino a seguir, a veces las modificaciones en sí mismas pueden llevar o no más o menos tiempo. A veces, uno puede pensar que es mejor empezar de cero que modificar tanto.

Esto se puede manejar fácilmente creando un conjunto de casos de prueba estándar para cada una de las funciones comunes.

¿Qué es una prueba estándar en pruebas web?

• Cree casos de prueba que estén completos: pasos, datos, variables, etc. Esto garantizará que los datos / variables no similares se puedan reemplazar simplemente cuando se requiera un caso de prueba similar.
• Los criterios de entrada y salida deben definirse adecuadamente.
• Los pasos modificables o la declaración en los pasos deben resaltarse en un color diferente para encontrarlos y reemplazarlos rápidamente.
• El lenguaje utilizado para la creación de casos de prueba estándar debe ser genérico.
• Todas las características de cada sitio web deben cubrirse en los casos de prueba.
• El nombre de los casos de prueba debe ser el nombre de la funcionalidad o la característica que cubre el caso de prueba. Esto facilitará mucho la búsqueda del caso de prueba del conjunto.
• Si hay una muestra básica o estándar, un archivo GUI o una captura de pantalla de la función, debe adjuntarse con los pasos correspondientes.

Al usar los consejos anteriores, uno puede crear un conjunto de scripts estándar y usarlos con modificaciones pequeñas o necesarias para diferentes sitios web.

Estos casos de prueba estándar también se pueden automatizar, pero una vez más, centrarse en la reutilización es siempre una ventaja. También si automatización se basa en una GUI, reutilizar los scripts en múltiples URL o sitios es algo que personalmente nunca encontré efectivo.

El uso de un conjunto estándar de casos de prueba manuales para diferentes sitios web con modificaciones menores es la mejor manera de realizar una prueba de sitio web. Todo lo que necesitamos es crear y mantener los casos de prueba con los estándares y el uso adecuados.

Conclusión

Mejorar la eficiencia de los casos de prueba no es un término simplemente definido, sino que es un ejercicio y se puede lograr a través de un proceso maduro y práctica regular.

El equipo de pruebas no debe cansarse de involucrarse en la mejora de tales tareas, ya que es la mejor herramienta para lograr mayores logros en el mundo de la calidad, esto está probado en muchas de las organizaciones de prueba en todo el mundo en proyectos de misión crítica y aplicaciones complejas.

Espero que haya obtenido un conocimiento inmenso sobre el concepto de casos de prueba. ¡Mire nuestra serie de tutoriales para saber más sobre casos de prueba y no dude en expresar sus pensamientos en la sección de comentarios a continuación!

Siguiente tutorial

Lectura recomendada

• Pruebas funcionales versus pruebas no funcionales
• Guía de pruebas de portabilidad con ejemplos prácticos
• Tipos de pruebas de software: diferentes tipos de pruebas con detalles
• Mejores herramientas de prueba de software 2021 (Herramientas de automatización de pruebas de control de calidad)
• Pruebas alfa y beta (una guía completa)
• ¿Qué es la prueba del sistema? Una guía definitiva para principiantes
• Documentos de preguntas de muestra de certificación de pruebas ISTQB con respuestas
• Cómo escribir un informe de estado semanal de pruebas de software