Difference between revisions of "Request Feature GXtest Designer"
(→Importar KB ajena) |
|||
| (15 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
| − | [[category: | + | {{Idiomas |
| + | |Request Feature GXtest Designer | ||
| + | | GXtest Designer - Request Feature | ||
| + | }} | ||
| + | [[category: Soporte]] | ||
| − | 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! | + | La idea de esta página es ir agregando las funcionalidades o modifciaciones que sería deseable hacerle a GXtest Designer. Anímate y escribí tu aporte! |
== Bug Autoejecutable == | == 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. | 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. | + | A partir del GXtest IERecorder se puede grabar un flujo en el SUT (system under test) 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 == | == Grabación desde otros Browsers == | ||
| Line 19: | Line 23: | ||
== Transcribir Scripts Selenium a Test Case en GXtest == | == 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. | 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. | ||
| − | |||
| − | |||
| − | |||
== Visualización de Resultados == | == 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) | Al hacer clic en un nodo del árbol de resultados, mostrar el nodo o arista correspondiente en el modelo de GXtest (grafo) | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
== Análisis de Impacto considerando cambios en la lógica == | == Análisis de Impacto considerando cambios en la lógica == | ||
| Line 41: | Line 33: | ||
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. | 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 == | == 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 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. | Sería bueno que para seleccionar un objeto o un control de la kb se puede tipear el mismo. | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
== Comandos Genéricos == | == 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. | 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== | + | Por ejemplo, definir sobre el atributo XX que cada vez que aparezca se ejecute la acción YY o la validación ZZ, sin que sea necesario que el tester la agregue en cada caso de prueba donde esto aparezca. |
| + | |||
| + | == 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 .... | 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 .... | ||
| Line 69: | Line 50: | ||
#(opcional) Mostar con un ícono diferente (estilo TestCase impactado) para diferenciar los TC que fueron impactados y aun no se arreglaron . | #(opcional) Mostar con un ícono diferente (estilo TestCase impactado) para diferenciar los TC que fueron impactados y aun no se arreglaron . | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
== Deshabilitar y Habilitar nodos de un Modelo (TestCase) == | == Deshabilitar y Habilitar nodos de un Modelo (TestCase) == | ||
| Line 87: | Line 61: | ||
== Documentación Integrada == | == 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. | 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. | ||
| + | |||
| + | == Ventana de Parametrización de Caso de prueba == | ||
| + | Sería deseable tener una funcionalidad en la cual dado un TC sin parametrizar (DataPools) se listen todos los lugares donde se utilizan valores fijos y se de la posibilidad de indicar de que DataPools se tomarán los mismos. | ||
| + | |||
| + | == Asociar las pantallas HTML a los Nodos para luego agregar comandos == | ||
| + | Al momento de grabar un caso de prueba se podría asociar a cada pantalla su HTML. Eso permitiría luego cuando se edita el modelo, pararse arriba de un nodo o una arista y en ese momento se visualizaría la pantalla asociada. Esto permite luego hacer click sobre el elemnto que se desee agregar un comando en dicha pantalla simplemente haciendo click arriba del elemento deseado. | ||
Latest revision as of 17:30, 15 August 2013
 |
 |
 link= {{{3}}} |
La idea de esta página es ir agregando las funcionalidades o modifciaciones que sería deseable hacerle a GXtest Designer. 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 (system under test) 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.
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)
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.
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.
Por ejemplo, definir sobre el atributo XX que cada vez que aparezca se ejecute la acción YY o la validación ZZ, sin que sea necesario que el tester la agregue en cada caso de prueba donde esto aparezca.
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 ....
- Al pasar los cambios de la nueva KB mostrar al lado los TC que se impactan
- luego de pasar todos los impactos de la nueva KB, guardar todos los impactos y mostrar un resumen de casos impactados al final
- (opcional) Mostar con un ícono diferente (estilo TestCase impactado) para diferenciar los TC que fueron impactados y aun no se arreglaron .
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.
Ventana de Parametrización de Caso de prueba
Sería deseable tener una funcionalidad en la cual dado un TC sin parametrizar (DataPools) se listen todos los lugares donde se utilizan valores fijos y se de la posibilidad de indicar de que DataPools se tomarán los mismos.
Asociar las pantallas HTML a los Nodos para luego agregar comandos
Al momento de grabar un caso de prueba se podría asociar a cada pantalla su HTML. Eso permitiría luego cuando se edita el modelo, pararse arriba de un nodo o una arista y en ese momento se visualizaría la pantalla asociada. Esto permite luego hacer click sobre el elemnto que se desee agregar un comando en dicha pantalla simplemente haciendo click arriba del elemento deseado.
