Me pareció que esta pregunta lanzada en diferentes grupos de discusión relacionados con el testing, además del mio, iba a ser muy útil y aprovechado por muchos.
Además quería tener un estado de situación general para compararlo con todo lo que surgiera durante el transcurso del curso de Automatización que dimos con Emilio, ayer y hoy.
En estos momentos estoy regresando a casa, un poco cansado pero satisfecho en que este segundo ciclo (y el último del año) ha sido todo un éxito.
Mañana me dedicaré a escribir la Bitácora de los dos dias, pero a modo de adelanto debo decir que todos los comentarios que leerán a continuación y que fueron extraídos de distintos grupos de discusión de Linkedin, se fueron dando a modo de debate durante las jornadas de estos dos dias, sirviendo como disparadores de otros.
Comentario 1:
No tenemos una manera estructurada para automatizar, pero avanzamos.
Automatizamos partes ya probadas y mas o menos estables (hay que recordar que las herramientas para automatizar no ven, solo miran aquello que les pedimos mirar).
Vamos automatizando una por una las zonas que nos queremos quitar de encima y así evitamos errores de regresión.
Si se necesita un perfil técnico? Pues sí, En general venden los sistemas que permiten automatizar como una herramienta en la que cualquiera puede automatizar, pero en cuanto se complica todo un poco hay que programar y entonces vienen las risas. Porque hay muchos QA’s que no saben programar y por lo general en ese momento donde el proyecto comienza a demorarse y hasta incluso, se abandona.
Comentario 2:
Los programadores hacen TDD, así que esa parte la tenemos cubierta.
Yo como tester, mantengo las suites de humo y las de integración.
Automatizo todo lo que me permite testeo exploratorio de una forma mas eficiente.
Libro recomendado, de Alan Page, «The A word».
Comentario 3:
Los primeros pasos son sencillos, tareas simples y repetitivas. Empecé hace 6 años con Mercury, ahora HP ALM y de ahí vas pasando por varias herramientas (Selenium, RFT, otras)
Al final, es como programación, si tienes en la mente como programar, solo es aprender el lenguaje y sus APIs.
A mi parecer, QTP y RFT, son muy similares conceptualmente hablando.
La elección de la herramienta, muchas veces viene por parte del cliente.
En mi caso, ha sido más cómodo y útil, aplicar automatización sobre pruebas de regresión.
Yo llegué a perder 1 semana por despliegue con pruebas de regresión, y lo reduje a casi 1 día con automatización, ganando 4 días para investigar o formarme mejor.
Creo que para tener un buen equipo automatizador, tiene que haber un perfil de desarrollo, ya que al final para sacarle provecho a estas herramientas, hay que bajar a nivel de código, para explotar la posibilidad de integrarlo en scripts.
Y tiene que haber también, un perfil tester, que indique el qué, el cuándo, el cómo y con qué condiciones probar y desarrollar los scripts.
La mayor dificultad con la que me encontré, fue la escasa documentación y formación sobre estos temas.
Comentario 4:
Nosotros usamos una herramienta de pago: Ranorex, similar al TestComplete, ya que el frontend de nuestra app esta hecha en flash,
Nuestro principal problema es el tiempo y no contar con un «automatizador» con un 100% de disponibilidad. Sin embargo, vamos automatizando lo que creemos conveniente añadir en las regresiones. Respecto al backend, estamos analizando que implementar.
Lo cierto es que, un buen QA necesita conocimiento de programación,
Comentario 5:
Nosotros automatizamos con QTP ALM 11 en entorno SAP. Ahora mismo estoy evaluando la posibilidad de usar SAP TAO para ver si podemos acelerar la creacion y mantenimiento de scripts utilizando las famosas T-BONEs para obtener el análisis de impacto. En nuestro caso al ser SAP, la participación de los Super Usuarios y Analistas Funcionales es clave. Todos los scripts que queremos automatizar, son creados por ellos, ya que para automatizar SAP se requiere un alto conocimiento del negocio, que el equipo de automatización no tiene. Ahora mismo enfocarmos nuestra automatización en proceso End to End de regresión. Nos ayuda mucho a quitarles carga de trabajo a los Super Usuarios cuando estamos en la fase de UAT. Nuestra mayor dificultad es obtener unos buenos scripts de negocio que sean automatizables. Tenemos muchos problemas de datos ya que se quedan obsoletos muy rápidamente.
… To be continue
Nosotros venimos automatizando con QTP pero estamos trabajando para empezar a utilizar BDD con Cucumber + Webdriver. No va a ser fácil, sobre todo porque tenemos una suite de +600 tests, pero ya estamos escribiendo Gherkin en cada ticket que se pueda, cosa de facilitar la migración o de, al menos, aprender a hacerlo.
Sería interesante que pudieras compartir algo de la información que estas manejando, a nivel del resultado de estas prácticas, como ser:
1. si te basaste en algún modelo de éxito bajado de internet o de alguien que te lo facilitó;
2. cómo preparaste y armaste tu entorno de prueba;
3. primeras dificultades que se te presentaron y forma de resolverlas;
4. si tuviste una formación previa o fue todo, autoaprendizaje;
5. con qué tipo de tecnología te estarás enfrentando: Java, .NET, PHP, otro;
Gracias