Difference between revisions of "Request Feature GXtest Designer"

Revision as of 23:52, 22 April 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.

Validaciones

Completar las validaciones, agregar validaciones con Proc. GeneXus.

Modelado

Permitir copiar y pegar parcial o totalmente los objetos de un test case. También sería bueno poder copiar y pegar comandos desde un test case a otro.

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.

Importar KB ajena

No todos los equipos de desarrollo quieren/pueden pasar la KB (fuentes) de la aplicación a testear. Para esto existe la posibilidad de filtrar la misma pasando sólo los elementos que GXtest utiliza.

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.