Introducción
En muchos proyectos con los que he trabajado, las personas no configuraban TestRail a su medida y se quedaban con la configuración estándar. Por lo tanto, en este artículo intentaré describir un ejemplo de configuraciones personalizadas que pueden ayudarle a aumentar la eficiencia de su trabajo. Tomaremos como ejemplo un proyecto de desarrollo de una aplicación móvil.
Un pequeño descargo de responsabilidad. Este artículo no describe la funcionalidad básica de TestRail (hay muchas guías para eso) ni utiliza expresiones comerciales que describan llamativamente por qué debería elegir a este proveedor para crear un repositorio de pruebas.
Plan de justificación (lo que se implementará)
Requisitos generales
El caso debe poder ser completado por cualquier persona
Los casos deben mantener su relevancia el mayor tiempo posible
Los casos deben cubrir exhaustivamente la funcionalidad de la aplicación móvil en la medida en que no contradiga los dos primeros puntos
División en TestCase y TestScenario
Generación rápida de TestRun de varios tipos
Smoke
Regress
Pruebas de impacto, etc.
Optimización del soporte de casos
Abandonar las capturas de pantalla "muertas" y pasar a "datos móviles"
Requisitos
Para editar los campos, necesitará acceso de administrador
Selección del tipo de proyecto
Se pueden seleccionar tres tipos de proyectos:
Elegiremos el tipo predeterminado. En él estarán disponibles todos los casos al mismo tiempo. Utilizaremos filtrado inteligente y gestionaremos dinámicamente todos los casos a la vez.
Agregar campos para ver la lista de casos de prueba
Agregaremos un campo para mostrar la prioridad de los casos de prueba:
También se pueden agregar otros campos.
Configuración de campos y etiquetas de caso de prueba
Abrimos el menú de configuración:
Necesitaremos los siguientes campos:
Campo "Resumen" (encabezado del caso de prueba)
Este campo ya existe, solo sistematizaremos su uso. Dividiremos los casos en TestCase y TestScenario. Para mejorar la legibilidad de una gran lista de casos, es mejor acordar por adelantado las reglas para escribir el resumen.
TestScenario:
Ejemplo: TestScenario — Escenario principal de uso de la aplicación móvil
TestCase:
Ejemplo: MainScreen — Sección de autorización — Introducción del nombre de usuario
En resumen, vemos en el resumen del caso una comprensión clásica: “qué, dónde, cuándo”. También visualmente separamos los escenarios de prueba de alto nivel y los casos de prueba de bajo nivel en la forma más adecuada para la automatización.
La etiqueta «StartScreen» (pantalla desde la que comienza el TestScenario; muchos casos de prueba pueden tocar pantallas adyacentes)
¿Para qué puede ser útil? Vamos a eliminar del texto los pasos típicos 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. Sobre este hablaré más detalladamente por separado.
Creamos un nuevo campo:
Rellenamos los componentes del nuevo campo:
En este caso, estamos creando un campo de selección de una lista de valores. Introducimos los valores de este campo:
Tenga en cuenta que los id de los valores no comienzan en uno y no son secuenciales. ¿Por qué es así? La razón es que si tenemos escritos casos de prueba con un id atribuido,
y después necesitamos crear una tercera pantalla entre dos existentes,
tendremos que reescribir los id, y dado que estos ya están vinculados a las etiquetas de los casos de prueba existentes, simplemente se eliminarán. Esto será muy desagradable.
La etiqueta «Screen» (nombre de la pantalla que afecta al TestCase)
¿Para qué puede ser útil? Uno de los anclajes para pruebas de impacto. Por ejemplo, los desarrolladores han creado una nueva y genial función. Necesitamos probarla, pero para ello debemos entender qué es exactamente lo que esta función pudo haber afectado. Por defecto, podemos partir de la parábola de que diferentes pantallas (Activity) de la aplicación tienen diferentes clases y, por lo tanto, componen diferentes componentes de la aplicación. Por supuesto, en este caso, se necesita un enfoque individual.
Ejemplo: home_screen, MapScreen, PayScreen, etc.
Campo «MovableData» (enlace a la base de datos proxy con datos de prueba cambiantes)
A continuación, intentaremos resolver el problema de mantener la actualidad de los datos en los casos de prueba:
Enlaces a maquetas actuales (esto es mucho mejor que hacer capturas de pantalla muertas)
Pasos típicos hasta la pantalla con la situación de prueba
Consultas SQL
Enlaces a datos externos y otros datos
En lugar de escribir los datos de prueba dentro de cada caso de prueba, crearemos un solo archivo externo y haremos referencia a él en todos los casos de prueba. Al actualizar estos datos, no tendremos que revisar todos los casos de prueba y modificarlos, sino que podremos cambiar estos datos en un solo lugar. Si alguien no preparado abre un caso de prueba, verá en el cuerpo del caso de prueba un enlace al archivo y una sugerencia de que debe ir allí para obtener los datos de prueba.
Todos estos datos los empaquetaremos en un solo archivo externo, que estará disponible para todos los interesados en el proyecto. Por ejemplo, se puede usar Google Sheet o Excel y configurar dentro del archivo una búsqueda. ¿Por qué estos proveedores? La razón es que partimos de la premisa de que cualquier persona en el equipo debe poder abrir y seguir un caso de prueba sin necesidad de instalar previamente alguna herramienta.
Para Google Sheet se pueden usar consultas SQL. Ejemplo:
=query(DATA!A1:M1146;"
SELECT C,D
WHERE
C contains '"&SEARCH!A2&"'")Para Excel se pueden configurar macros cómodas para la búsqueda instantánea. (filtrado) Ejemplo .
La idea en sí no es nueva y se describe en el primer libro del probador “Testing dot com”. (autor Roman Savin) Solo estamos integrando las metodologías propuestas por Roman Savin en TestRail. Para ello, crearemos un campo con un enlace al archivo creado:
llenamos el valor por defecto del enlace, para que en cada nuevo caso de prueba ya haya un enlace:
Si la ubicación del archivo externo cambia (prevenimos cualquier imprevisto), se puede cambiar cómodamente uno o varios campos en todos los casos de prueba a la vez:
Campo “Descriptions” (descripción o idea del caso de prueba, instrucciones estándar)
Para qué puede ser necesario: En este campo de texto colocaremos una breve descripción del caso de prueba y las instrucciones estándar.
Ejemplo: Todos los datos de prueba (maquetas actuales, uso de herramientas y otros datos) de este caso de prueba están designados por enlaces {…} y se encuentran en el archivo MovableData. El enlace a MovableData está en el campo correspondiente en la parte superior.
Etiqueta «Component» (componente de la aplicación móvil)
Para qué puede ser útil: para pruebas de impacto. Si una aplicación móvil se puede dividir en componentes (que interfieren lo menos posible entre sí), entonces será suficiente (con algunos riesgos) comprobar los cambios en un componente dentro de ese mismo componente, lo que reduce la necesidad de realizar regresiones generales de todo. Si hay información de que un componente puede afectar a otro, se elabora una matriz de pruebas de impacto.
Ejemplo de componentes: GooglePay, Orden, Usuarios, Mapa, Autorización, etc.
Etiqueta «TAG» (Otras etiquetas para filtrado)
Etiquetado de casos de prueba con etiquetas para filtrado arbitrario.
Muy útil para:
la rápida creación de TestRun para diversas tareas estándar: smoke, regresión, etc.
si las pruebas serán automatizadas o ya están automatizadas
cualquier otra etiqueta
Ejemplo: Smoke, Automatizado, WhiteLabel, ParaEliminar, etc.
Configuramos 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:
Creación de TestRun
Ahora crearemos un nuevo test run con casos de prueba actualizados para realizar pruebas smoke en tres clics:
Otros consejos útiles
Si hay varios proyectos en TestRail, no olvides crear nuevos campos solo para tu proyecto; de lo contrario, tus colegas de equipos vecinos se sorprenderán mucho al ver nuevos campos inusuales. Pueden ocurrir desmayos locales.
2. Los casos con un gran número de campos son más fáciles de copiar de un grupo similar que de crear nuevos:
3. Se pueden usar cuentas en conjunto. Por ejemplo: una administrativa, varias de usuario.
Conclusión
Los ejemplos descritos anteriormente se han implementado en varios proyectos y han demostrado su efectividad. Espero que ayuden a mejorar tu comprensión de esta herramienta y a crear ‘almacenamientos de pruebas’ eficientes y convenientes. Agradecería mucho si pudieras compartir tu experiencia utilizando TestRail y consejos útiles en los comentarios.
Enlaces:
Libro:
¡Muchas gracias por su atención!
Fuente: habr.com
