¿Por fin has instalado Tricentis Tosca Commander y estás listo para automatizar tus casos de prueba? Intenta evitar los siguientes cinco errores comunes que suelen cometer los principiantes en Tosca. Esto te permitirá mantener bajos los costos de mantenimiento a largo plazo.
¡Empecemos ya mismo!
1. Creación de casos de prueba sin una estructura
Si bien puedes comenzar a escanear módulos rápidamente y luego arrastrarlos y soltarlos en tu nuevo caso de prueba, intenta mantener una estructura que facilite la lectura del mismo. Es probable que no seas la única persona encargada de mantenerlo.
La mejor práctica consiste en definir al menos tres carpetas dentro del caso de prueba: Precondiciones, Proceso y Postcondiciones.
Las precondiciones deben incluir los pasos preparatorios para la prueba, como la carga de datos o la inicialización de búferes. La carpeta Proceso debe contener únicamente el flujo de trabajo que se va a probar. La poscondición puede incluir los pasos necesarios para la limpieza posterior a la finalización del flujo de trabajo o para actualizar el estado de los datos de prueba.
2. Creación de módulos grandes
En Tosca, el módulo representa técnicamente un conjunto de controles de una pantalla. Al escanear el sistema bajo prueba (SUT), se añaden controles al módulo como atributos. Sin embargo, un sitio web o un formulario puede contener muchos controles. Si se añaden todos al módulo, puede resultar difícil encontrar el control correcto posteriormente.
Intenta encontrar una separación lógica de los controles existentes en secciones de la pantalla. Por ejemplo, puedes mantener una fila de menú superior separada en un módulo.
En la mayoría de los casos, es posible que reutilice módulos con elementos de menú para varias pantallas; mantenerlos en un módulo central facilita el mantenimiento.
3. No tratar los pasos de tu prueba como mantenibles
Crear pasos de prueba es muy sencillo: basta con arrastrar y soltar módulos en el caso de prueba. Luego, se rellenan los valores de los pasos y listo, ¿verdad? No del todo. Es muy útil renombrar los pasos de prueba creados con un nombre descriptivo, como «Haga clic en el botón xy». Esto facilitará la lectura del caso de prueba y, a largo plazo, su mantenimiento.
Consejo adicional: Si bien puedes asignar varias acciones en un mismo paso de prueba, puede ser útil crear pasos de prueba independientes para cada acción. De esta manera, el caso de prueba resulta más legible en general, y tener acciones por paso de prueba ofrece mayor flexibilidad para futuros cambios en el flujo de trabajo.
4. Creación de casos de prueba sin verificación
Así que has completado todo el flujo de trabajo del caso de prueba y todo funciona correctamente. Todo parece estar bien, ya que solo querías que el flujo de trabajo se ejecutara correctamente. Por lo tanto, no necesitas ninguna verificación adicional, ¿verdad?
Bueno, no, aunque tu flujo de trabajo funcione correctamente, normalmente está orientado a un objetivo específico. Supongamos que tienes una tienda online y quieres probar el proceso de pago. Si bien el proceso de selección y adición de artículos al carrito puede estar cubierto y funcionando, ¿cómo puedes estar seguro de que el objetivo final, añadir artículos al carrito, se realizó correctamente? Tendrás que verificar qué hay finalmente dentro del carrito.
Todos los casos de prueba deben tener un objetivo, y este objetivo debe verificarse. Por lo tanto, implemente pasos de verificación en sus casos de prueba.
5. Verificar en exceso las cosas en un caso de prueba
Esto es lo contrario del error anterior. Normalmente, se requiere verificar muchos aspectos dentro de la aplicación. Tomemos como ejemplo el flujo de pago de nuestra tienda en línea. Se debe verificar que todos los artículos seleccionados estén en el carrito de compras. Además, la suma de los artículos debe ser correcta y ciertos descuentos deben verificarse y calcularse correctamente en el carrito.
Si bien verificar todo en un solo caso de prueba puede ser conveniente y ahorrar tiempo, interpretar los resultados después de una ejecución de regresión resultará complicado. Una verificación fallida solo indicaría que algo no funciona correctamente. Sin embargo, dado que el caso de prueba abarca muchos puntos de verificación, no es posible identificar el problema con precisión. Por ejemplo: ¿Qué significa que algunas verificaciones fallen y otras pasen? ¿Se puede confiar en las verificaciones que pasaron? ¿Qué información proporciona esto sobre la cobertura de pruebas de la aplicación?
Crear un caso de prueba centrado en una verificación específica le permitirá identificar directamente el fallo sin necesidad de analizar en detalle la ejecución de la prueba. Esto se puede gestionar mediante el diseño de casos de prueba en Tosca.
Sin embargo, esta es solo una regla general. Crear más casos de prueba afecta la velocidad de ejecución, lo cual puede ser un factor importante. Como siempre, es posible que deba encontrar un punto intermedio.
Conclusión
En este artículo hemos tratado la importancia de la estructura y la nomenclatura en su caso de prueba, hemos analizado la creación de módulos y qué debe incluirse en un caso de prueba
Los 5 errores que suelen cometer los principiantes en Tosca, descritos aquí, se pueden evitar fácilmente y le permitirán crear casos de prueba mucho más fáciles de mantener.
Deja un comentario si estás de acuerdo o en desacuerdo. ¿Quizás tengas algún consejo que quieras compartir?
¿Necesitas más personal para crear tu conjunto de pruebas de regresión? Entonces no dudes en contactarnos o contactarme directamente. ¿O necesitas más capacitación? Entonces consulta nuestra oferta de la Academia.
