View source for ¿Como empezar con testing automatizado?

{{Idiomas| ¿Como empezar con testing automatizado?|  How to get started with automated testing | テストの自動化を開始する方法}}
[[Category: Testing]]

__NOTOC__


Muchas veces se visualizan los beneficios de automatizar parte de las pruebas pero no se sabe como comenzar, o se cuenta con una herramienta de testing automatizado pero no se está seguro acerca de su implantación. Por estos motivos en este artículo se discutirán los distintos aspectos importantes a tener en cuenta para comenzar con el testing automatizado, en particular utilizando GXtest sobre aplicaciones GeneXus, aunque varios de los conceptos y consejos que se mencionan aquí aplican a cualquier intento de automatización.

== Comenzar con un proyecto piloto ==
Al igual que la mayoría de las prácticas de ingeniería de software, es conveniente '''elegir''' un proyecto '''adecuado''' y utilizarlo como proyecto piloto para comenzar.

El hecho de utilizar un proyecto piloto tiene varias ventajas:
* poder definir una metodología inicial adecuada a la forma de trabajo de la empresa 
* adquirir experiencia en el uso de las herramientas de automatización
* medir los beneficios 
* evaluar las dificultades
* contar con un proyecto de alcance acotado en el cual focalizar los esfuerzos por mejorar la calidad

Es deseable que este proyecto piloto pueda mostrar en el menor plazo posible el ROI que se tiene al aplicar testing automatizado, por este motivo se deben seleccionar algunas métricas (de acuerdo a la realidad de la empresa y del proyecto) que lo visualicen.
Algunas métricas que se pueden utilizar para este fin son las siguientes:
* horas de testing / # de errores encontrados por el cliente
* # de errores encontrados por el cliente / Tamaño del sistema
* Tiempo de detección de los errores (entre que se introdujo el error y se detectó)
* etc

También se puede evaluar a través de un cuestionario algunos aspectos subjetivos como son la motivación del equipo de testing, la sensación de estabilidad o calidad del sistema por parte de los usuarios o la percepción de calidad en el testing de los desarrolladores.

Ahora bien, ¿cuales son las características deseadas que tiene que tener el proyecto piloto?. Algunas de estas características son:
* '''Tamaño del equipo''' pequeño: es preferible que el equipo de testing y el equipo de desarrollo sean pequeños. En equipos pequeños es más fácil introducir cambios y medir su impacto. Un factor muy importante es que el equipo vea el testing automatizado como una ayuda en su trabajo y no como una carga extra. 
* '''Skills''' de las personas involucradas: si se va a introducir un cambio es imprescindible contar con gente dispuesta a cambiar la forma de trabajo. Si esta gente es líder o referente en la empresa mucho mejor, ya que luego será más sencillo adoptar los cambios en el resto de los proyectos.
* Cantidad de '''ciclos de prueba''': las pruebas automatizadas tienen más valor cada vez que se corren, por este motivo aquellos proyectos que involucren varios ciclos de prueba son los que sacan más valor de este tipo de pruebas. Típicamente durante la etapa de mantenimientos de los sistemas se tienen algunas correcciones del mismo y luego se corren pruebas de regresión. Estos proyectos de mantenimiento suelen ser buenos candidatos para empezar con las pruebas automatizadas
* Relevancia de la '''calidad''' del sistema: si bien todos los sistemas que desarrollamos tienen que ser de calidad, hay ciertos proyectos en los cuales los clientes son más demandantes en cuanto a la calidad y valoran más los aspectos referentes a la calidad.
* '''Tecnología''' a utilizar: dependiendo de la tecnología que se utilice para desarrollar existen herramientas para automatizar de menor o mayor sofisitificación y de menor o mayor precio. Para el caso en que la aplicación se realice en GeneXus con GXtest se tendrán contemplados los distintos aspectos que necesita cubrir la herramienta, con otras tecnologías hay que evaluar otras alternativas.

== ¿Quién automatiza? ==

Una vez que se decidió del portfolio de proyectos, cual será el elegido para comenzar con la experiencia de testing automatizado se deberá asignar las personas que se involucrarán en el mismo. En particular se deberá elegir quienes serán los encargados de realizar el testing automatizado. La recomendación es que las personas encargadas de automatizar sean los mismos analistas que conocen de los requerimientos y de la realidad y que realizan el testing funcional tradicional. Es importante que sea el mismo grupo por varios motivos:
* que no se genere competencia entre las pruebas manuales y las pruebas automatizadas
* ayudar a asegurar la correcta elección de las pruebas que se realizarán de manera automatizado
* las herramientas de testing automatizado pueden servir no solo para automatizar casos de prueba sino que también para generar datos para los casos de prueba. Por este motivo conocer de la herramienta de automatización ayudará a también en las pruebas manuales

=== ¿Cómo formar a las personas que van a automatizar? ===

El proceso que siga cada una de las personas que vaya a automatizar puede variar según su grado de conocimiento en testing automatizado y en herramientas de automatización.
Es aconsejable que de manera paralela puedan comenzar con la capacitación en la herramienta que se vaya a utilizar (con GXtest se puede empezar por ejemplo con [[Tutorial de GXtest Designer]]) así como también leyendo material acerca de metodología y experiencias de pruebas automatizadas en general. Una lectura recomendada es la [http://www.testingexperience.com/testingexperience04_08.pdf 4º Edición] de la revista Testing Experience dedicada al testing automatizado.

== Selección de los casos de prueba a automatizar  == 
Una vez que se tiene elegido el proyecto y la gente que participará en el mismo el punto crítico en la automatización de las pruebas es '''decidir''' cuales casos de prueba se automatizarán. 
El error más común en los intentos de automatización es intentar automatizar todo, así que la recomendación aquí es '''NO INTENTE AUTOMATIZAR TODOS LOS CASOS DE PRUEBA'''.
Teniendo una visión del negocio y también de la estructura interna del sistema (para lo cual se necesita involucrar a los desarrolladores) se debe decidir cuales casos de prueba que se automatizarán. 
Algunas de los factores a tener en cuenta son:
* ¿cuales casos de prueba se necesitarán correr más veces durante el proyecto? Típicamente aquellos casos de prueba asociados al núcleo de la aplicación se pueden construir al principio del proyecto y luego sirven (adaptándolos cuando sea necesario) para el resto de la vida del sistema.
* ¿cuáles casos de prueba conllevan mucha dedicación humana y son repetitivos? Hay veces que un caso de prueba requiere de un trabajo tedioso para configurar el ambiente de prueba y luego ejecutar el caso de prueba. Estos casos de prueba es bueno automatizarlos para liberar el recurso humano y que pueda dedicarse a otros casos más desafiantes.
* ¿que funcionalidades son críticas para el cliente/usuario? Aquellas funcionalidades que tienen que andar si o si en cada entrega generalmente es interesante incluirlas en los casos automatizados.
* ¿que costo tienen asociado la automatización del caso de prueba? Hay casos de prueba que son muy difíciles de automatizar, ya sea porque hay que realizar validaciones visuales complejas o por otras razones. Por este motivo si el costo de su automatización es grande hay veces que es mejor dejarlo para ser ejecutado manualmente.

Teniendo en cuenta estas características se puede ponderar cada caso de prueba en base a cada una de ellas para luego hacer un ranking o priorizar los casos de prueba a automatizar.

En el caso de que se vaya a automatizar en un proyecto de mantenimiento en el cual ya se están corriendo pruebas manuales, muchas veces la fuente de información más importante que tenemos para elegir los casos de prueba a automatizar es el historial de incidentes. Con este instrumento más las consideraciones vistas previamente se puede tener una idea clara de cuales son aquellos casos de prueba o funcionalidades a automatizar.

== Cómo Comenzar ==
Luego de seleccionar un proyecto para un piloto, y seleccionar ciertos casos de prueba para automatizar, lo que recomendamos es comenzar por un subconjunto acotado de casos de prueba (no más de 10) y ponerlos a funcionar. Esto es: diseñarlos (en papel, planillas, etc.), automatizarlos (con GXtest Designer y Recorder), preparar ambiente y datos para poder probarlos, preparar la ejecución programada de estos casos (con GXtest Manager, haciendo que ejecuten todas las noches por ejemplo) y definiendo las metodologías para trabajar. Una vez que preparemos esto comenzaremos a ver los beneficios y a alimentar la máquina de pruebas automatizadas, haciéndola crecer cada vez más, obteniendo cada vez más beneficios.

== Ver también ==
* [http://searchsoftwarequality.techtarget.com/expert/KnowledgebaseAnswer/0,289625,sid92_gci1251861,00.html How to design test cases]
* [http://www.testingexperience.com/testingexperience04_08.pdf 4ta Edición de la revista "Testing Experience"]