introducción
En muchos proyectos con los que trabajé, las personas no personalizaron TestRail y se conformaron con la configuración estándar. Por lo tanto, en este artículo intentaré describir un ejemplo de configuraciones individuales que pueden ayudarlo a mejorar la eficiencia de su trabajo. Por ejemplo, tomemos un proyecto de desarrollo de aplicaciones móviles.
Un pequeño descargo de responsabilidad. Este artículo no contiene una descripción de la funcionalidad básica de TestRail (hay muchas guías sobre esto) ni expresiones de ventas que describan de manera colorida por qué necesita elegir este proveedor en particular para crear un repositorio con pruebas.
Plan de justificación (qué se implementará)
-
Requisitos generales
-
Absolutamente cualquiera debería poder pasar el caso.
-
Los casos deben seguir siendo relevantes durante el mayor tiempo posible
-
Los casos deben cubrir la funcionalidad de la aplicación móvil lo más detalladamente posible en la medida en que esto no contradiga los dos primeros puntos.
-
-
Dividir en TestCase y TestScenario
-
Generación rápida de TestRun de varios tipos.
-
Humo
-
regreso
-
Pruebas de impacto, etc.
-
-
Optimización del soporte de casos
-
Abandonar las capturas de pantalla codificadas "muertas" y cambiar a "datos móviles"
-
Requisitos
Para editar campos necesitará acceso de administrador
Seleccionar un tipo de proyecto
Hay tres tipos de proyectos para elegir:
Seleccionaremos el tipo predeterminado. Todos los casos estarán disponibles en él al mismo tiempo. Usaremos filtrado inteligente y gestionaremos dinámicamente todos los casos a la vez.
Agregar campos para ver una lista de casos de prueba
Agreguemos un campo para mostrar casos de prueba prioritarios:
También puedes agregar otros campos.
Configurar campos y etiquetas de casos de prueba
Abra el menú de configuración:
Necesitaremos los siguientes campos:
Campo "Resumen" (encabezado del caso de prueba)
Este campo ya existe, apenas estamos sistematizando su uso. Dividiremos los casos en TestCase y TestScenario. Para una mejor legibilidad de una lista grande de casos, es mejor acordar de antemano las reglas para redactar un resumen.
Escenario de prueba:
Ejemplo: TestScenario: escenario básico para usar una aplicación móvil
Caso de prueba:
Ejemplo: Pantalla Principal - Sección Autorización - Ingresar inicio de sesión
En total, vemos en el resumen del caso el entendimiento clásico: “qué, dónde, cuándo”. También separamos visualmente los scripts de prueba de alto nivel y los casos de prueba de bajo nivel en la forma más adecuada para la automatización.
Etiqueta "StartScreen" (la pantalla desde la que comienza TestScenario; además, muchos casos de prueba pueden tocar pantallas adyacentes)
Para lo que pueda ser necesario: eliminaremos del texto el texto de los pasos típicos de los casos que llevan al usuario a la pantalla del caso de prueba actual. (pasos típicos para crear una situación de prueba específica) Todos los pasos típicos para todos los casos de prueba se escribirán en un archivo. Escribiré sobre esto con más detalle por separado.
Crea un nuevo campo:
Complete los componentes del nuevo campo:
En este caso, estamos creando un campo de selección a partir de una lista de valores. Ingrese los valores de este campo:
Tenga en cuenta que los valores de identificación no comienzan con uno y no son consecutivos. ¿Por qué se hace esto? El punto es que si tenemos casos de prueba con la identificación ingresada registrada,
y después de eso necesitaremos crear una tercera pantalla entre las dos existentes,
luego tendremos que reescribir la identificación y, dado que las etiquetas de los casos de texto existentes ya están adjuntas, simplemente se eliminarán. Será muy desagradable.
Etiqueta “Pantalla” (nombre de la pantalla que afecta a TestCase)
Lo que podrías necesitar: uno de los anclajes para pruebas de impacto. Por ejemplo, los desarrolladores crearon una nueva característica interesante. Necesitamos probarlo, pero para ello necesitamos comprender qué podría afectar exactamente esta característica. Por defecto, podemos partir del paradigma de que diferentes pantallas (Actividades) de una aplicación tienen diferentes clases y por tanto constituyen diferentes componentes de la aplicación. Por supuesto, en este caso se necesita un enfoque individual.
Ejemplo: pantalla de inicio, MapScreen, PayScreen, etc.
Campo "MovableData" (enlace a una base de datos proxy con datos de prueba modificables)
A continuación, intentaremos resolver el problema de mantener la relevancia de los datos en casos de prueba:
-
Enlaces a diseños actuales (esto es mucho mejor que tomar capturas de pantalla muertas)
-
Pasos típicos para llegar a la pantalla con una situación de prueba
-
Consultas SQL
-
Enlaces a datos externos y otros datos
En lugar de escribir datos de prueba dentro de cada caso de prueba, crearemos un archivo externo y lo vincularemos en todos los casos de prueba. Al actualizar estos datos, no tendremos que revisar todos los casos de prueba y cambiarlos, pero será posible cambiar estos datos en un solo lugar. Si alguien que no está preparado abre un caso de prueba, verá en el cuerpo del caso de prueba un enlace a un archivo y una pista de que necesita acceder a él para obtener datos de prueba.
Empaquetaremos todos estos datos en un archivo externo, que estará disponible para todos los participantes del proyecto. Por ejemplo, puede utilizar Google Sheet o Excel y configurar una búsqueda dentro del archivo. ¿Por qué estos proveedores en particular? El hecho es que partimos del paradigma de que cualquier persona del equipo debería poder abrir y pasar un caso de prueba sin tener que instalar ninguna herramienta primero.
para Hoja de Google puedes utilizar consultas SQL. Ejemplo:
=query(DATA!A1:M1146;"
SELECT C,D
WHERE
C contains '"&SEARCH!A2&"'")para Excel Puede configurar cómodas macros de búsqueda instantánea. (filtrado) Ejemplo .
En realidad, la idea no es nueva y se describe en el libro del primer evaluador "Testing dot com". (autor Savin Roman) Simplemente estamos integrando los métodos propuestos por Roman Savin en TestRail. Para hacer esto, cree un campo con un enlace al archivo creado:
complete el valor predeterminado del enlace para que cada nuevo caso de prueba ya tenga un enlace:
Si la ubicación del archivo externo cambia (prevemos cualquier caso de fuerza mayor), puede cambiar cómodamente uno o más campos a la vez en todos los casos de prueba:
Campo “Descripciones” (descripción o idea de un caso de prueba, instrucciones estándar)
Lo que puede necesitar: En este campo de texto colocaremos una breve descripción del caso de prueba e instrucciones estándar.
Ejemplo: Todos los datos de prueba (diseños actuales, uso de herramientas y otros datos) de este caso de prueba se indican mediante enlaces {...} y se encuentran en el archivo MovableData. Enlace a MovableData en el campo correspondiente en la parte superior.
Etiqueta "Componente" (componente de aplicación móvil)
Para qué podría ser necesario: para pruebas de impacto. Si una aplicación móvil se puede dividir en componentes (que se afectan entre sí lo menos posible), entonces los cambios en un componente serán suficientes (con algunos riesgos) para ser verificados dentro del mismo componente, y habrá menos motivos para realizarlos. Regresiones generales de todo. Si hay información de que un componente puede afectar a otro, se elabora una matriz de pruebas de impacto.
Componentes de ejemplo: GooglePay, Pedido, Usuarios, Mapa, Autorización, etc.
Etiqueta "TAG" (Otras etiquetas para filtrar)
Etiquetar un caso de prueba con etiquetas para filtrado arbitrario.
Muy útil para:
-
compilar rápidamente TestRun para varias tareas típicas: humo, regresión, etc.
-
¿Las pruebas estarán automatizadas o ya estarán automatizadas?
-
cualquier otra etiqueta
Ejemplo: Humo, Automatizado, WhiteLabel, ForDelete, etc.
Configurar el orden de visualización de los campos en el caso de prueba
Hemos creado muchos campos nuevos, es hora de organizarlos en un orden conveniente:
Creando prueba de ejecución
Ahora crearemos una nueva ejecución de prueba con casos actuales para realizar pruebas de humo en tres clics:
Otros consejos
-
Si TestRail tiene varios proyectos, no olvide crear nuevos campos solo para su proyecto; de lo contrario, los colegas de los equipos vecinos se sorprenderán mucho con la aparición de nuevos campos inusuales. Es posible que se produzcan desmayos locales.
2. Los casos con una gran cantidad de campos son más fáciles de copiar de un tipo de grupo similar que crear otros nuevos:
3. Las cuentas se pueden compartir. Por ejemplo: un administrador, varios usuarios.
Conclusión
Los ejemplos descritos anteriormente se han implementado en varios proyectos y han demostrado su eficacia. Espero que le ayuden a mejorar su comprensión de esta herramienta y le ayuden a crear "almacenamiento de prueba" eficaces y convenientes. Le agradecería mucho que describiera su experiencia con el uso de TestRail y consejos útiles en los comentarios.
Enlaces:
Libro
¡Muchas gracias por su atención!
Fuente: habr.com