Nuestro servicio EasyQA contiene las funcionalidades más sencillas pero más variadas que ayudarán a los usuarios a escribir casos de prueba de forma más fácil y rápida.
Enlace útil: Canal de YouTube de EasyQA
En nuestro artículo damos respuesta a las siguientes preguntas:
¿Caso de prueba? ¿Qué es?
No hay duda de que la redacción de los Casos de Prueba efectivos es la habilidad imprescindible para los especialistas en QA. Como cualquier otra habilidad, puede ser adquirida y mejorada. Los principales principios y consejos de la escritura efectiva de Casos de Prueba serán considerados en este artículo.
Antes de empezar, vamos a entender completamente lo que es el Caso de Prueba. Imagina que necesitas probar alguna funcionalidad de la aplicación. Debe iniciar paso a paso la situación en la que podría ser implementada.
Por decirlo de forma sencilla, el Caso de Prueba es un conjunto de esos pasos (acciones) bien diseñados y fáciles de entender que se ejecutan para verificar una característica o funcionalidad particular de su aplicación de software. Mantenga en su mente «bien diseñado» y «fácil de entender». Tiene un sentido importante como verás un poco más adelante.
Así que, ahora podemos empezar. Aquí vamos a dividir el Caso de Prueba a los componentes y tratar de analizar lo que se debe hacer, así como lo que no debe ser para escribirlo con alta eficiencia.
Las partes principales del Caso de Prueba
Identificación del Caso de Prueba
Es un número único de Caso de Prueba en el sistema de gestión de pruebas o en el documento. Por regla general, todos los sistemas modernos de gestión de pruebas como Jira, TestRail y Zephyr asignan automáticamente el ID al nuevo caso de prueba creado. Por lo tanto, no hay posibilidad de cometer un error con este componente.
Pero, hay que tener en cuenta, que en algunos proyectos todavía se utiliza Excel para las pruebas. Es por eso que usted siempre debe recordar la regla: «No hay casos de prueba con el mismo ID en su sistema de gestión de pruebas. Incluso estos son los casos de prueba de los proyectos terminados».
Título del caso de prueba
El título fuerte es el atributo obligatorio del caso de prueba efectivo. ¿Qué significa? Las características clave del Título fuerte son: fácil de entender y lacónico. Además, el Título del Caso de Prueba debe representar el nombre del módulo o el área funcional que se va a verificar.
Imaginemos que tenemos una tarea para comprobar lo que sucederá si introducimos símbolos inválidos como $,&, * en el campo «e-mail» del formulario de registro del Sistema de Gestión de Pruebas EasyQA. De acuerdo con los principios mencionados, el título del caso de prueba debería ser como: «Campo de correo electrónico no válido en el formulario de registro».
Consideremos el ejemplo de título no fuerte. «Campo de correo electrónico «$&*» símbolos de entrada en el formulario de registro de la «EasyQA». Aquí tenemos al menos dos errores.
- La excesiva longitud del título. No hay necesidad de mencionar «EasyQA», porque este caso de prueba es una parte del plan de pruebas para este sistema de gestión de pruebas. Por lo tanto, todos los casos de prueba se refieren a «EasyQA».
- Concreción de los símbolos especiales «$&*». Otros símbolos no válidos también podrían ser introducidos para ejecutar este tipo de caso de prueba. Por lo tanto, «símbolos no válidos» es una definición más adecuada para este título.
- Se necesita alguna configuración especial
- Dependencias de cualquier otro Caso de Prueba – ¿el Caso de Prueba necesita ser ejecutado antes/después de algún otro Caso de Prueba
- Dependencia de los datos del usuario – en qué página debe comenzar el viaje el usuario; el usuario debe estar conectado.
Algunos Sistemas de Gestión de Pruebas, incluyendo EasyQA, simplifican este proceso mediante la creación de un campo de módulo especial para cada Caso de Prueba.
El Plan de Pruebas se divide en módulos, que incluyen Casos de Prueba particulares. Por eso es más fácil crear un título fuerte para el caso de prueba.
Descripción del caso de prueba
Antes de empezar a probar, debes mencionar todos los detalles sobre lo que vas a probar. Estos son: Datos de Prueba a utilizar, Precondiciones (Presteps), Detalles del Entorno de Prueba, Herramientas de Prueba.
Si das los Datos de Prueba a utilizar siempre que sean aplicables para el Caso de Prueba dentro de la descripción del caso de prueba o con el paso específico del Caso de Prueba, no sólo te ayudarás a ti mismo, sino también a tus colegas-testers. Es un grave error escribir Casos de Prueba sólo para uno mismo.
Las Precondiciones (Presteps) describen diferentes tipos de dependencias de la Ejecución de la Prueba:
El Entorno de Pruebas es una configuración de software y hardware para que los equipos de pruebas ejecuten los casos de prueba. En otras palabras, soporta la ejecución de la prueba con el hardware, el software y la red configurada.
Cuando la gente menciona acerca de las herramientas de prueba, la prueba automatizada se sugiere a menudo. Por supuesto que se refieren previamente a este tipo de pruebas. Pero también hay herramientas sencillas para el Testing Manual. Herramientas de mapas mentales como Xmind, gestores de capturas de pantalla como Jing son fáciles de usar incluso para los recién llegados al área de QA. De todos modos, si alguna herramienta especial es obligatoria para las pruebas, debería mencionarla en la descripción del caso de prueba.
Por supuesto, si la misma herramienta se utiliza para la ejecución de algún grupo de casos de prueba, sería mejor describirla en el módulo/submódulo de prueba o incluso en el plan de prueba.
Hay algún tipo de error típico en el que debería centrarse. Algunos probadores con menos experiencia confunden los Pasos con los Presteps. Tenga en cuenta que los Presteps son la forma de llegar a la situación en la que se puede iniciar la ejecución del caso de prueba. Los Pasos son la forma más efectiva de obtener el Resultado Real de la Ejecución del Caso de Prueba.
Por ejemplo, si tenemos que probar las habilidades funcionales de un usuario registrado, sería un error crear pasos especiales de registro de usuario para cada Caso de Prueba en el módulo apropiado. La decisión correcta es mostrarlo en los Presteps para todos los módulos de Test Suites de registro de usuarios: el usuario debe estar registrado. El proceso de registro se verifica en el Test Suite particular.
Como se mencionó anteriormente, los Pasos son el camino hacia el Resultado Esperado. Otra cosa que se debe recordar Pasos en el caso de prueba eficaz están bien diseñados y fácil de entender. Estos dos puntos son los básicos para entender cómo planificar los pasos para sus casos de prueba.
Los principales atributos de los pasos bien diseñados:
- Cantidad óptima de pasos. No hay necesidad de escribir pasos adicionales, así como el paso «para comer». Las cosas que parecen obvias para ti, no pueden ser tan claras para tus compañeros.
- Un Caso de Prueba cubre sólo una funcionalidad independiente. Es un error verificar diferentes funcionalidades en un Caso de Prueba.
- Los Pasos son fáciles de ejecutar.
- Los Pasos no sólo deben cubrir el flujo funcional sino también cada punto de verificación que debe ser probado.
- Los Pasos son al grano. No debes escribir un ensayo para describir tus Pasos.
- Expresión clara. Debe evitar el uso de la ambigüedad en sus Pasos de Casos de Prueba.
- Entendible incluso para los principiantes. Sus colegas, que probablemente no son tan experimentados deben ser capaces de entender cómo ejecutar cada Paso.
- Título
- Módulo – para elegir el módulo al que se refiere nuestro Caso de Prueba. – Si se pulsa Añadir caso en el módulo, este campo se introducirá por defecto.
- Tipo – seleccionar un tipo de caso de prueba de la lista desplegable de acuerdo con la siguiente descripción:
Los principales atributos de los Pasos fáciles de entender:
El rendimiento de la aplicación después de ejecutar los pasos de prueba anteriores se muestra en el resultado Esperado. Por lo tanto, antes de escribir los Casos de Prueba, debe reconocer completamente qué página/pantalla espera que aparezca después de la prueba y, cualquier actualización que espera como resultado que se haga en los sistemas de back-end o en la base de datos.
Espero que recuerde que un Caso de Prueba cubre una funcionalidad independiente. Por eso, sería un error escribir un caso de prueba con más de un resultado esperado.
Los comentarios/las postcondiciones no son componentes obligatorios del caso de prueba, pero realmente aumentan la eficiencia de su caso de prueba. Aquí puede poner información adicional útil como capturas de pantalla y descripciones para proporcionar a los desarrolladores la información que necesitarán para corregir cualquier defecto encontrado.
Las Condiciones Posteriores también se utilizan para dar instrucciones de guía para restaurar el sistema a su estado original para que no interfiera con las pruebas posteriores. Por ejemplo, esto es bastante útil si se mencionan los cambios que hay que hacer a un Dato de Prueba para que se utilice para un Caso de Prueba posterior para la misma funcionalidad.
Los diferentes sistemas de Gestión de Pruebas ofrecen variantes de campo de Caso de Prueba. El caso de prueba en la herramienta EasyQA Test Management tiene los siguientes:
- Positivo es un caso de prueba que utiliza sólo datos correctos.
- Negativo es un caso de prueba que utiliza no sólo datos correctos.
- Límite es un caso de prueba que utiliza valores máximos y mínimos.
- Integración es un componente de las pruebas de integración.
- UI es la prueba de una interfaz gráfica de usuario.
- Localización es la prueba de ubicaciones, idiomas, etc.
- Prepasos
- Pasos
- Resultado esperado
- Existe un Sistema de Gestión de Pruebas «EasyQA» – https://geteasyqa.com/
- Tiene que verificar la capacidad del usuario registrado para crear un nuevo Plan de Pruebas para el proyecto llamado «Blogger» según la especificación.
- El correo electrónico del usuario es «[email protected]», la contraseña es «gEORGe52»
- Hay un sistema de gestión de pruebas «EasyQA» – https://geteasyqa.com/
- Se necesita probar el formulario de «Registro».
- La longitud mínima de la contraseña es de 6 símbolos. La longitud máxima es de 128 símbolos
- Sólo se pueden utilizar letras del alfabeto latino de la A a la Z y cifras en los campos «Login», «Password», «Confirm Password».
En esta imagen se puede ver el proceso de adición de casos de prueba con los campos rellenados.
Una vez añadidos los Casos de Prueba puedes elegirlos con las casillas correspondientes. Después de haber escogido uno o varios casos de prueba puedes moverlos donde necesites. Puedes editarlos o eliminarlos.
Ejemplo sencillo de Caso de Prueba
Ahora, cuando tengas algunos conocimientos teóricos sobre la escritura de Casos de Prueba, trata de utilizarlos para la siguiente decisión de tarea.
Datos de la tarea:
Consideremos cómo crear cada paso.
Por supuesto, el ID único será asignado automáticamente por el Sistema de Gestión de Pruebas que utilice.
En primer lugar, debe hacer es elegir el título apropiado, el módulo y el escenario de pruebas para el Caso de Prueba. Naturalmente, el módulo podría ser «Usuario registrado». Y otros Casos de Prueba que prueben la funcionalidad de los usuarios registrados se pondrán en este módulo. El título fuerte parece «Capacidad de creación de planes de prueba». El escenario de prueba es positivo.
Así como tiene que comprobar la funcionalidad de usuario registrado, necesita mostrar el camino al registro en los Pre Pasos. Estos Pre Pasos serán los mismos para todos los Casos de Prueba del módulo «Usuario registrado».
En el campo Pasos tiene que mostrar cómo conseguir el Resultado Esperado.
Determinemos el Resultado Esperado como «El usuario registrado tiene la capacidad de crear un Plan de Pruebas».
Podemos ver el resultado de nuestras acciones utilizando las herramientas de Gestión de Pruebas de EasyQA.
Casos de Prueba del formulario de inicio de sesión y contraseña: Positivo, Negativo, Límite
Consideremos algunos Casos de Prueba típicos basados en diferentes escenarios.
Los datos de la tarea son casi los mismos que los de la tarea anterior:
Aquí consideramos algunas especificaciones de este tipo Proceso de creación de casos de prueba.
El formulario «Sign Up» de EasyQA tiene los siguientes campos obligatorios: «Nombre», «Apellido», «Correo electrónico», «Contraseña» y «Confirmar contraseña». Además de eso, hay otros campos como «Empresa» y «País», que no son obligatorios, pero también tienen que ser probados. Por lo tanto, debe dividir su módulo «Sign Up» Test Suite en submódulos apropiados.
Intente analizar algunos escenarios típicos: positivo, negativo y límite.
Según el escenario positivo, el usuario no registrado introduce sólo datos válidos en todos los campos. Así que no tendrá problemas con la creación de este tipo de casos de prueba. Puede ver cómo podría verse en la imagen de abajo.
El resultado esperado para este caso de prueba es «La entrada de letras y cifras latinas es posible en el campo «Contraseña»».
Pero, ¿qué ocurrirá si el usuario introduce los símbolos no válidos en cualquiera de los campos mencionados anteriormente? Podemos comprobarlo ejecutando Casos de Prueba basados en el Escenario Negativo. De hecho, hay un montón de variantes de entrada no válida. Podrían ser consideradas en un artículo en particular. Aquí están sólo algunos de eso:
- «&%$» símbolos de entrada
- Espacios de entrada
- Campo vacío de entrada
- Combinaciones de símbolos inválidos y no válidos de entrada
- Otros casos de entrada de letras, etc.
En la imagen de abajo se representa un ejemplo de Casos de Prueba negativos.
El Resultado Esperado para este Caso de Prueba es «La entrada inválida es imposible en el campo «Contraseña»».
Preste atención a la condición – restricción de longitud de contraseña (6-128 símbolos). ¿Es posible registrarse con una contraseña de sólo 3 símbolos? ¿Y con una contraseña de 150 símbolos? Los Casos de Prueba escritos por la técnica de diseño Boundary Value Testing le dan respuestas a estas preguntas.
La idea básica en Boundary Value Testing es seleccionar los valores de las variables de entrada en su: mínimo, justo por encima del mínimo, justo por debajo del máximo, máximo. En nuestro ejemplo deberías escribir Casos de Prueba para situaciones con:
- 5 símbolos de entrada de contraseña
- 6 símbolos de entrada de contraseña
- 128 símbolos de entrada de contraseña
- 129 símbolos de entrada de contraseña.
Mira la imagen de abajo para ver cómo queda el Caso de Prueba escrito según esta técnica.
El resultado esperado para este caso de prueba es «Se muestra el mensaje informativo «La longitud mínima de la contraseña es de 6 símbolos»».
Casos de prueba para los criterios de filtrado
También es necesario probar diferentes funcionalidades como la búsqueda, la clasificación y la paginación. Estos Casos de Prueba también podrían ser escritos de acuerdo a los escenarios que consideramos antes. Verifican el funcionamiento normal de:
- Campos de búsqueda
- Botones de página
- Flechas
- Ranqueo por nombre (de la A a la Z, de la Z a la A)
- Ranqueo por precio (el más bajo primero, el más alto primero)
- Botones de menú del tablero y de la barra lateral, etc.
Vuelve al Sistema de Gestión de Pruebas de EasyQA y escribe un sencillo Caso de Prueba para comprobar la funcionalidad de filtrado del botón de «Problemas cerrados». Aquí está.
El Resultado Esperado para este Caso de Prueba es «Sólo se muestran las incidencias cerradas en el menú del tablero».
Las Pruebas de Seguridad suelen ser proporcionadas por herramientas especiales de Pruebas Automatizadas como Vega, Google Nogotofail, Wapiti etc. Pero usando sus habilidades de actividad mental puede escribir un simple caso de prueba para comprobar algunos parámetros de seguridad del sitio web. Vuelva de nuevo a EasyQA Test Management System. Puede ver un ejemplo de este caso de prueba a continuación.
Preste atención a los pasos. El resultado esperado para este caso de prueba es «El formulario de inicio de sesión de EasyQA se muestra después de copiar/pegar la URL de un navegador a otro». Por lo tanto, no hay acceso a la cuenta de usuario.
EasyQA Test Management System características útiles adicionales
Hay un montón de herramientas de gestión de pruebas para ayudar a los probadores en su trabajo. EasyQA le ofrece una amplia gama de características útiles adicionales:
- Exportar un plan de pruebas preparado en formato CSV pulsando un botón
- Importar un plan de pruebas preparado a nuestro sistema.
- Visualización de casos de prueba por varios criterios:
- Realización de informes de fallos
- Construcción de la distribución
- Sistema de seguimiento de errores
- Ejecución de pruebas
- Generación de informes
- Integración rápida y sencilla con sus herramientas existentes.
- Tenga en cuenta, que los Casos de Prueba son ejecutados también por sus colegas
- Use un Título fuerte
- Preste atención a los Pasos Previos y a las Precondiciones
- El Caso de Prueba cubre una funcionalidad y
- El Caso de Prueba tiene sólo un Resultado Esperado
- Escriba pasos biendiseñados y fáciles de entender
- No olvide poner toda la información útil en los Comentarios o las Condiciones Previas
- Utilice ilustraciones y herramientas de prueba sencillas si es necesario
- El Caso de Prueba debe ser reutilizable
- Comience a practicar
Por decirlo de forma sencilla, EasyQA es más que un sistema de gestión de pruebas. Es un entorno de trabajo agradable y eficiente.
10 consejos para escribir Casos de Prueba efectivos
¿Quiere escribir Casos de Prueba efectivos? Sólo tienes que empezar a hacerlo. Y será un placer ayudarte.
TY EASY QA