Difference between revisions of "Request Feature GXtest Designer"

Revision as of 21:59, 27 August 2009

La idea de esta página es ir agregando las funcionalidades o modifciaciones que sería deseable hacerle a GXtest. Anímate y escribí tu aporte!

Bug Autoejecutable

Es deseable poder empaquetar el caso de prueba (por ejemplo para mostrar un error) en un archivo para que pueda ser enviado a otra persona interesada y reproducido por esta. A partir del GXtest IERecorder se puede grabar un flujo en el SUT el cual puede ser ejecutado desde GXtest. La idea es generar un ejecutable que se pueda correr (sin GXtest instalado). La información a exportar deberá ser la mínima que permita ejecutar el caso de prueba. Esto es particularmente útil para un equipo de soporte.

Grabación desde otros Browsers

Sería deseable tener una extensión para que se pueda grabar en Google Chrome y en FireFox.

Opciones avanzadas de grabación

Si se graba Online (desde GXtest), se podría incluir un mecanismo para que el tester tenga el catálogo de datapools de GXtest al momento de grabar y dejar parametrizado un caso de prueba.

La toolbar debería tener una feature de "Usar variable" que se pueda elegir una variable desde un input. La toolbar debería completar el input con el valor q tenía asociado la variable, a la inversa de la funcionalidad existente.

Sería deseable poder incluir checkpoints a medida que se va grabando. O sea si es un caso de prueba largo y ya se hizo una parte bien y se quiere seguir grabando, que se permita guardar los cambios hasta el momento.

Transcribir Scripts Selenium a Test Case en GXtest

A partir de un set de scripts Selenium que estén funcionando sobre la aplicación, que se pueda generar automáticamente modelos en GXtest con los mismos casos de prueba.

Ejecutar pruebas Selenium (u otros) desde GXtest Server

Al armar una suite de ejecución que sea posible mandar a ejecutar pruebas Selenium o cualquier otro, pruebas externas, las cuales se integren con los resultados gestionados por GXtest.

Visualización de Resultados

Al hacer clic en un nodo del árbol de resultados, mostrar el nodo o arista correspondiente en el modelo de GXtest (grafo)

Mostrar todos los datos con los que se ejecutó un test case de forma centralizada

En los resultados las validaciones se muestran con X o V. Las condiciones deberían mostrarse con T o F

Visualización 360

Interesa tener una vista que desde el caso de prueba se vean los datapools que tiene asociados.

También una vista que dado un DataPool, muestre los casos de prueba que tiene relacionados.

Agregar una vista de relaciones de un caso de prueba, que contenga todo lo q tiene asociado. Las variables, datos (DP), etc.

Análisis de Impacto considerando cambios en la lógica

Hasta el momento el análisis de impacto sólo tiene en cuenta los cambios de los Objetos Genexus con los cuales GXtest interactúa (Controles, WebPanels, Transactions, etc.).

Sería interesante tener en cuenta los componentes de la lógica como para hacer un análisis de impacto tal, que al cambiar la KB se sugieran qué TC hay que ejecutar, basándose en los nuevos cambios sobre la aplicación.

KB GeneXus

Sería bueno que el tester le pueda asignar un nombre más familiar e intuitivo a cada control de la KB. Sería bueno que para seleccionar un objeto o un control de la kb se puede tipear el mismo.

Probar errores de cosmética automáticamente

Al traducir una aplicación a otro idioma (por ejemplo) se pueden generar errores de cosmética en el SUT. Estos errores pueden ser que no se muestran enteros los literales, que se muestran superpuestos, que no están alineados, etc. Este requerimiento lo que busca es poder detectar de manera automática la mayor cantidad posible de errores de este tipo.

Se debería poder definir reglas de correctitud visual, en las cuales se expresen las validaciones a realizar para verificar la cosmética. Estas serían del estilo como las que se nombran en el artículo “Automating the testing of the GUI for Multilanguage applications” de la revista Testing Experience volumen 4: Test truncation, Access key clashes, Overlapping of controls, Aligment of controls.

Se podría revisar todas las transacciones y webpanels y para cada uno acceder a la página Web por la URL dada, y verificar que todos los elementos en la página aparezcan correctamente según las reglas definidas.

Comandos Genéricos

Se podría tener una forma genérica de definir comandos, que se apliquen cada vez que aparece un Webpanel, sea en la página que sea. Esta idea se puede llevar incluso hasta el nivel de atributos.

Matriz de Impacto

Estaría bueno hacer una matriz que digas funcionalidad y objetos que esta toca, entonces que cuando se impacta una nueva kb se diga qué TC es recomendable ejecutar ....

1. Al pasar los cambios de la nueva KB mostrar al lado los TC que se impactan
2. luego de pasar todos los impactos de la nueva KB, guardar todos los impactos y mostrar un resumen de casos impactados al final
3. (opcional) Mostar con un ícono diferente (estilo TestCase impactado) para diferenciar los TC que fueron impactados y aun no se arreglaron .

Screenshots de ejecución

En algunos casos es útil documentar la ejecución de casos de prueba para mostrar que funciona correctamente (o no).

La idea es que, automáticamente, se pueda generar un documento que contenga:

• Entrada (Datos de entrada, sean datos harcoded o datos de Datapools)
• Ejecución (screenshots de validación)
• Salida (a definir, pero quizá otro screenshot)

Se puede generar un .doc que adentro tenga cada nombre de validación y cada screenshot de ejecución.

Deshabilitar y Habilitar nodos de un Modelo (TestCase)

Esto es similar a comentar líneas de código, y tiene las mismas ventajas, como por ejemplo, si cambia algo, uno lo puede deshabilitar sin perderlo, por si luego hay que volver a recuperarlo.

Generar casos de prueba a partir de Transactions, Entities, Patterns

Hay un conjunto de pruebas a un WorkWith que son básicas, y que podrían generarse automáticamente, alimentándose de los tipos de datos definidos en la transacción (o entidad si se usa K2Btools). Sería deseable que se puedan generar automáticamente casos de prueba básicos para probar cada transacción, etc.

Documentación Integrada

Así como en GX X se tiene algo así como una Wiki integrada a la KB, en donde se puede documentar en el mismo IDE y vincular la documentación a elementos de la KB, sería deseable en GXtest tener la posibilidad de editar documentos y vincular TestCases o Datapools directamente dentro de esa documentación. Esto permitiría organizar más las pruebas, dejándolas bien documentadas.

Busqueda de Comandos

Implementar una búsqueda tipo full text search, o sea que busque palabras en los comandos o parámetros (quiero ver dónde me quedó harcoded cierto valor que ingresé durante la grabación, así voy y lo parametrizo a mano).

Para este objetivo sería bueno también que al seleccionar varios nodos y aristas me liste en el command List los comandos asociados a todos, en el orden que corresponde. No es muy simple, pero tal vez se puede hacer algo similar.

Representar concurrencia en los modelos

Cómo hacer para que se puedan probar problemas dados ante la concurrencia? Es interesante ver qué pasa si dos usuarios actúan a la vez sobre el sistema bajo pruebas, planteando ciertas sincronizaciones en la prueba, tal como "acción A - usuario 1, acción B - usuario 2 (una vez que la del usuario 1 terminó)". Para esto simplemente se requerirían nuevos constructores en el modelo para representar estas acciones.

Sugerir variables en la toolbar

Estaría bueno tener un botón "insert variable value" que inserte el valor de una variable. O sea, la idea es que si yo grabo una variable y quiero usarla no tener que tipearla exactamente, tal vez me equivoco al tipear, o no me acuerdo. Sería más comodo si puedo seleccionar un input y decirle "poné el valor de tal variable" dándome para elegir todas las variables creadas hasta el momento.