Difference between revisions of "Advice for when to automate"
(→¿Por qué automatizar las pruebas?) |
|||
| Line 15: | Line 15: | ||
| − | == | + | == Why should I automate my tests? == |
| − | * | + | |
| − | * | + | * Through automation we manage to increase the coverage of our testing, thus, increasing the quality of our product |
| − | * | + | * Decrease the total amount of time to market, reducing the time employed in testing. |
| − | * | + | * Early errors detection provides the development team with the insight required to work upon its resolution. Additionally, it is much easier for a developer correcting a defect which has recently been introduced in the code, as opposed to troubleshooting something which was introduced several months ago. |
| − | * | + | * Costs reduction (through the automation of repetitive tests, thus, granting a bigger time frame for both the design and execution of tests) |
| − | * | + | * Encourage the team for testing more often, making use of their creativity, leaving repetitive and boring tasks to a robot. The QA team may employ more time to testing new features, whilst the automation tests are running verifying the health of the build. Besides, more time may also be employed for automating more tests, in order to increase the size of the regression suite. |
| + | * Having the possibility of testing simultaneously, unattended and across different platforms. More often than not, we come across with a situation which urges us for having automation, for instance, provided we want to run each and every test upon a crossed browser environment, with multiple generators (Java, .Net) and Databases (MSSQL, Oracle, etc.). | ||
== ¿Cuál es el diferencial de GXtest? == | == ¿Cuál es el diferencial de GXtest? == | ||
Revision as of 21:12, 26 March 2014
 |
 |
 link= {{{3}}} |
We are working to translate this page.
We suggest to read this edition of of this magazine Testing Experience - the magazine for professional testers, exclusively dedicated to test automation, its advantages and disadvantages.
Why should I automate my tests?
- Through automation we manage to increase the coverage of our testing, thus, increasing the quality of our product
- Decrease the total amount of time to market, reducing the time employed in testing.
- Early errors detection provides the development team with the insight required to work upon its resolution. Additionally, it is much easier for a developer correcting a defect which has recently been introduced in the code, as opposed to troubleshooting something which was introduced several months ago.
- Costs reduction (through the automation of repetitive tests, thus, granting a bigger time frame for both the design and execution of tests)
- Encourage the team for testing more often, making use of their creativity, leaving repetitive and boring tasks to a robot. The QA team may employ more time to testing new features, whilst the automation tests are running verifying the health of the build. Besides, more time may also be employed for automating more tests, in order to increase the size of the regression suite.
- Having the possibility of testing simultaneously, unattended and across different platforms. More often than not, we come across with a situation which urges us for having automation, for instance, provided we want to run each and every test upon a crossed browser environment, with multiple generators (Java, .Net) and Databases (MSSQL, Oracle, etc.).
¿Cuál es el diferencial de GXtest?
La principal ventaja de GXtest es que permite adaptar rápidamente los casos de prueba a los cambios realizados en la aplicación. Con el enfoque tradicional, si se automatizan grandes cantidades de casos de prueba (porque se visualiza el beneficio que tiene la automatización), con cada cambio de la aplicación se vuelve MUY costoso el mantenimiento, haciendo que el costo sea mayor que el beneficio. Con las herramientas tradicionales con el simple cambio de nombre de un control dejarán de funcionar las acciones automatizadas sobre este control, y la forma de "darse cuenta" de que ya no funciona es al momento de ejecutar las pruebas que lo utilizaban. Este mismo problema se da si se cambia de versión de GeneXus o de generador. Imagínense que se cambia un nombre de un atributo en una transacción muy utilizada o que se actualiza la versión de GeneXus y se rompen todos los casos de prueba. En ese caso se pierde la motivación por mantener las pruebas automatizadas por el costo de retrabajo que implica. Con GXtest puede mantener la trazabilidad entre la aplicación y las pruebas en forma simple. La principal ventaja de GXtest es la flexibilidad para adaptar los casos de prueba a los cambios. Técnicamente, la automatización está ligada a la KB y no al HTML generado. Si GeneXus me permite hacer cambios de manera sencilla y generar la aplicación, no sería adecuado que el testing este trabando posibles mejoras.
Con el enfoque tradicional, el esfuerzo construir un caso de prueba (aprender un lenguaje de scripting) y mantenerlos es muy grande, por lo cual muchas empresas deciden no automatizar. GXtest permite crear casos de prueba de manera sencilla (enfoque de record and playback), entenderlos mejor a través de un modelo abstracto, variar fácilmente los datos de entrada (con un enfoque de Data-driven testing) y mantenerlos al cambiar la KB. GXtest asocia los artefactos de prueba a elementos de la KB de GeneXus, y por esto no se pierden esas asociaciones, ya que es una herramienta específica para automatizar aplicaciones generadas con GeneXus.
GXtest, a diferencia de la mayoría de las herramientas, tiene un enfoque de Testing Basado en Modelos. Esto es como para acompañar la filosofía GeneXus en el sentido de la simplicidad en el desarrollo. Los modelos son más simples de entender y de mantener que el código. A partir de los modelos abstractos luego se pueden obtener casos de prueba concretos y ejecutables.
