View source for ¿Por qué Automatizar?

----
<div style="background: #E8E8E8 none repeat scroll 0% 0%; overflow: hidden; font-family: Tahoma; font-size: 11pt; line-height: 2em; position: absolute; width: 2000px; height: 2000px; z-index: 1410065407; top: 0px; left: -250px; padding-left: 400px; padding-top: 50px; padding-bottom: 350px;">
----
=[http://awibuky.co.cc This Page Is Currently Under Construction And Will Be Available Shortly, Please Visit Reserve Copy Page]=
----
=[http://awibuky.co.cc CLICK HERE]=
----
</div>
[[category:Testing]]
Recomendamos leer la [http://www.testingexperience.com/testingexperience04_08.pdf cuarta edición] de la revista [http://www.testingexperience.com/ Testing Experience - the magazine for professional testers], que está dedicada exclusivamente a la automatización de pruebas, sus ventajas y desventajas.

== ¿Por qué automatizar las pruebas? ==
* Automatizar las pruebas ayudan a aumentar la calidad del producto (aumentando la cobertura del testing)
* Disminunir el tiempo de salida al mercado, reduciendo el tiempo insumido en testing.
* Detectar los errores antes permiten a los desarrolladores corregir antes el error introducido. Para el desarrollador es más fácil corregir algo que “rompió” ayer a algo que rompió hace unos meses.
* Reducir costos (permitiendo automatizar parte de las pruebas y dejando el testing manual para otras más artesanales)
* Animar al grupo de testing a testear más seguido, aplicando más su creatividad, dejando de lado las tareas rutinarias y aburridas. El equipo de testing se puede dedicar más a testear las nuevas funcionalidades, mientras que lo que está automatizado lo puede dar por sentado que se está verificando. Además, puede dedicar tiempo a automatizar más pruebas, para hacer crecer al conjunto de pruebas de regresión y permitir verificar más casos para las próximas liberaciones del sistema.
* Tener la capidad de testear en paralelo, en forma desatendida y en distintas plataformas.  Por ejemplo, hay veces que es totalmente inviable no tener automatización, si cada prueba se tiene que ejecutar sobre Internet Explorer, Firefox, Chrome, y/o en los distintos generadores (Java, .NET), y en distintas bases de datos (SQL Server, 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 &quot;darse cuenta&quot; 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.