¿Qué es lo que más te gusta de Ghost Inspector?
- Mensajes detallados de fallos y video de lo que ocurrió durante las pruebas; fue fácil averiguar por qué falló una prueba en particular sin volver a ejecutarla.
- Integración de API; pudimos conectar nuestros conjuntos de pruebas en nuestras canalizaciones de CI sin mucho esfuerzo adicional (usando el complemento de Azure DevOps e integración con Pager Duty para fallos).
- Conducción de datos - utilizamos esta función para capturar y ejecutar pruebas en diferentes entornos con diferentes datos maestros (una sola prueba, múltiples ejecuciones) lo que redujo el costo de propiedad.
- Capacidad para construir pruebas componentizadas que se construyeron a partir de componentes de script reutilizables; redujo masivamente el costo de propiedad al eliminar la duplicación entre pruebas.
- Los costos son relativamente bajos para toda nuestra organización en comparación con otras herramientas comerciales (HP, Ranorex, Tosca).
- Grabar rápidamente la migración de datos u otros trabajos de automatización ad-hoc es muy sencillo, acelerando la configuración de datos y otros trabajos. Reseña recopilada por y alojada en G2.com.
¿Qué es lo que no te gusta de Ghost Inspector?
Como usuario intensivo a largo plazo de GI, los siguientes se enumeran como desagrados, pero con suerte las sugerencias serían consideradas por el equipo :)
- Nuestra aplicación depende en gran medida de llamadas API exitosas para sincronizar la prueba con la aplicación, GI no proporciona un mecanismo para esperar el resultado de una llamada API específica antes de continuar con la ejecución. Esto resultó en pruebas inestables que a veces funcionaban y a veces fallaban dependiendo de la rapidez con que respondía la API.
- Sin cuidado, las pruebas terminaban siendo una larga lista de instrucciones del navegador (clic, verificar, navegar, etc.) y se perdía el sentido de la prueba. Sería genial ver una forma de agrupar / organizar pasos dentro de una prueba que pudieran ser etiquetados con la intención de la prueba (las etiquetas por paso son un término medio, pero requieren que los autores de las pruebas las usen...)
- Las variables globales / de prueba son muy útiles, y sería aún mejor si se sugirieran automáticamente al escribir pasos (autocompletar / sugerir).
- Los localizadores de elementos generados automáticamente basados en el marcado ARIA (rol, etiqueta, para, etc.) serían mejores que el enfoque actual basado en la estructura del DOM (td > div > etc).
- Control de versiones; no hay ninguno - aunque puedes extraer y controlar versiones de pruebas individualmente, una vez que comienzas a importar / llamar a otros scripts todo se complica. Un historial de auditoría para las pruebas (quién editó qué / cuándo) sería de gran ayuda para solucionar este problema. Mantener diferentes versiones de la prueba para diferentes conjuntos de características (interruptores de características) era inmanejable.
- Integración de API - detener una ejecución de prueba no está actualmente incluido en la integración de Azure Devops, por lo que las ejecuciones canceladas deben detenerse manualmente en GI para evitar consumir minutos.
- Solo puedes esperar hasta un minuto por un elemento y esto es global para toda la prueba, por lo que si tienes un paso o un proceso que toma más tiempo que esto, tienes que usar una espera estática que introduce inestabilidad en tus pruebas. Sería genial si hubiera un método que te permitiera esperar a que un elemento se muestre (o se oculte) con un tiempo de espera que sea más largo de 60s. Reseña recopilada por y alojada en G2.com.
