miércoles, 15 de abril de 2015

Arquitectura de la prueba automatizada



La automatización de la prueba de software es un tipo particular de sistema de software, a veces llamado framework de prueba o stack de prueba.
Como cualquier sistema de software, tiene una arquitectura que puede facilitar o no la extensión, reuso y modificación. 
Arquitectura del Sistema de pruebas automáticas

Una arquitectura compartida

Algunas familias de herramientas de prueba (como Mercury, Rational, Silk y TestComplete) están pensadas para resolver toda la problemática de la prueba y tienen la arquitectura definida por el fabricante.
En otros casos (como Selenium, FitNesse, Cucumber y RobotFramework) las herramientas resuelven sólo algunos de los aspectos de la prueba. Suelen usarse combinadas con otras herramientas.
Una discusión que dejo pendiente es la correlación entre los atributos de las arquitecturas (extensión, reuso y modificación) y el origen de las herramientas: propietarias o FLOSS.

Planteo entonces por mi cuenta una arquitectura que describe muchos de los stack de prueba que conozco. 
Esta arquitectura está en movimiento aún. Hace un año aproximadamente incorporé el componente Comparator por conversaciones con Nicolás Páez (él plantea un modelo ligeramente distinto parte 1/parte 2). En enero de este año, cuando estaba explicando la arquitectura, me surgió la necesidad de agregar el Editor.
Y aún tengo dudas sobre la utilidad de separar algunos componentes, como por ejemplo tener componentes separados para reflejar el mecanismo de extender el DSL, tanto del lado del Test Case como del Interpreter.

Para qué buscar una arquitectura compartida

Identificar una arquitectura común de las herramientas de prueba permitiría simplificar las interfaces y que cada producto tenga foco en su especialidad, sabiendo que otros productos se ocuparán de las restantes áreas. Esperaba que el programa de la Agile Alliance "Agile Alliance Functional Testing Tools" lograra este consenso. No encuentro que se haya publicado ese análisis, aunque hay otros temas interesantes (20082012).

Es también útil tener un lenguaje común para poder discutir stacks alternativos cuando se está diseñando una solución de prueba.  

Los componentes

Por cada componente, describo brevemente el alcance del mismo y algunos ejemplos de su instanciación en herramientas existentes.
  • Editor: cómo creo y edito mis casos de prueba. En ocasiones una herramienta ad hoc, en otros casos una herramienta genérica.
    Selenium: Selenium IDE, permite grabar acciones desde la aplicación o editar los TC.
    WebDriver: editor/IDE del lenguaje de programación usado. 

    RobotFramework: RIDE, permite editar TC en forma 'inteligente', o editores de HTML. 
    FIT: Word, Excel y editores de HTML. 
    FitNesse: wiki. 
    Cucumber: cualquier editor de texto.
  • Test Case (TC): Repositorio de mis casos de prueba, con o sin estructura y con un lenguaje con el que escribo mis casos de prueba. Puede incorporar la posibilidad de definir términos nuevos que abstraigan complejidad.
    Selenium IDE: Los casos de prueba se escriben con Selenese, básicamente un HTML con una tabla de tres columnas. La estructura de casos está dada por las suite, que es una tabla HTML con los casos.
    WebDriver: No tiene forma nativa de representar los casos de prueba o la estructura. Debe usarse un Runner de otra herramienta y sintaxis de lenguaje de programación usado. Extensión usando el lenguaje de programación.
    RobotFramework: HTML (tablas), TSV, reST. Permiten extender el DSL de prueba con user keywords.

    FitNesse: wiki markup languaje (tablas). Permiten extender el DSL de prueba con Scenario.
    Cucumber: Gherkin y permiten extender el DSL de prueba con Scenario Outlines.
  • Interpreter: interprete del lenguaje de TC, incluyendo mecanismos para definir o extender un DSL.
    Selenium: plugin de Firefox, y se extiende con plugins adicionales.
    WebDriver: la parte correspondiente a WebDriver es interpretada o compilada por el lenguaje en el que se escribieron los TC (Java, Ruby, Python, etc), y resuelto con la API provista por la biblioteca de Selenium.
    RobotFramework: interprete del lenguaje propio (test data syntax), se extiende con  
    library keywords.
    FitNesse: interprete de HTML (modo compatibilidad con FIT) a través de una conversión interna entre wiki text y HTML, o directamente wiki text en el caso de SLIM. Extensión usando Fixture.
    Cucumber: interprete de Gherkin más los steps creados.
  • Adapter: cero, uno o más capas de adaptación entre los TC interpretados y el sistema bajo prueba (System Under Test o SUT). La forma de conexión depende del tipo de prueba que se quiere hacer, por ejemplo conexión con: interfaz usuario, API REST, u objetos de la aplicación.
    SUT Web: un ejemplo sería WebDriver usado para automatizar la aplicación a través de la interfaz web, más PhantonJs para simular un browser.
    SUT Desktop: un ejempo es Abbot para pruebas de Java Swing o White para pruebas GUI sobre Windows usando UIAutomation.
  • Comparator: el mecanismo de comparación entre resultados esperados y los resultados reales. El comparador puede tener conocimiento semántico y sintáctico sobre el resultado (Output) del SUT, para poder hacer comparaciones más significativas y concisas. En este sentido puede estar ligado a los adapters. En otras casos está implementado en el Interpreter. Y también puede ser extendido.
    Cucumber: la base de los comparadores corresponde a las expectations de RSpec, pero se enriquecer, por ejemplo con los Capybara Matchers.
    Fitnesse: una de las diferencias entre el Interprete FIT y SLIM es los comparadores adicionales (rangos, aproximados, mayor o menor). Adicionalmente, en SLIM se pueden enriquecer con Custom Comparators.
  • Runner: permite correr los TC. Pueden permitir ejecutar TC secuencialmente o en paralelo; todos los TC, o algún subconjunto (los que tienen cierta marca o tag, los que han fallado, etc), o uno solo TC; indicar dependencias entre TC.
    Los Runner también tiene mecanismos para indicar cuando un TC ejecutado ha sido exitoso o no y  mecanismos de preparación y limpieza de las pruebas. Invocan a la generación de reportes.
    Cucumber: se invoca por linea de comando y puede usarse el runner de JUnit (con cucumber-JVM)
    FitNesse: se puede ejecutar las pruebas desde la wiki, por linea de comandos, por servicios REST y puede usarse el runner de JUnit.
  • Reporter: crea los reportes de seguimiento de los resultados de la prueba. Distintos usuarios del sistema de pruebas requieren distintos reportes: resumen al momento, evolución temporal, detalle de casos ejecutados, etc. Es este área el formato XML de JUnit es el standard de facto. Aunque varias herramientas tienen alternativas: sólo texto o HMTL. Además, se incorporan a otras herramientas para brindar visibilidad, como Jenkins o SonarQube.

Conclusiones

Los equipos de desarrollo de software pueden diseñar su sistema de pruebas automáticas en forma iterativa e incremental, de igual manera a como se desarrolla el producto. Se empieza por la forma más sencilla y se mejora cuando es necesario.

Espero que este modelo te ayude a evaluar alternativas y decidir que cambiar en cada ciclo de mejora.

lunes, 12 de enero de 2015

Fitnesse con Python (waferslim)

En estos días tuve la necesidad, por primera vez, de usar Fitnesse para probar un sistema escrito con Python.
Gracias a SLiM es fácil, comparado con la implementación con FIT, relacionar Fitnesse con varios lenguajes.
Me llevó, de todas formas, más de un par de horas hacerlo funcionar. Espero que a otros les sirva.
Nota: Mis pruebas fueron con Ubuntu 14.04 y 11.04

Los pasos para ponerlo en marcha son:
  1. Instalar WaferSLiM, el servidor SLiM para Python.
  2. Instalar Fitnesse
  3. Configurar las pruebas para usar WaferSLiM y la versión correcta de protocolo

WaferSLiM

Obtener waferslim desde https://pypi.python.org/pypi/waferslim
wget https://pypi.python.org/packages/source/w/waferslim/waferslim-1.0.2-py2.6.zip#md5=acacf783444802677358b8b301ab23f9  --no-check-certificate
unzip waferslim-1.0.2-py2.6.zip

Instalar waferslim por https://bugs.launchpad.net/ubuntu/+source/distribute/+bug/958550

sudo easy_install ez_setup
cd waferslim-1.0.2
sudo python setup.py install

Para probar que todo anda bien (reemplazar el syspath donde lo hayas instalado)

python -m waferslim.server --syspath /home/kleer/waferslim-1.0.2 8002

Fitnesse

Obtener Fitnesse de http://www.fitnesse.org/FitNesseDownload el release 20140901
fitnesse-standalone.jar (*)

Para probar, ejecutar
java -jar fitnesse.jar -p 8000

Abrir en un browser localhost:8000

Configuración

Crear una página de Test y poner este texto, reemplazando el path por el correcto en tu caso (*)

!define TEST_SYSTEM {slim}
!define SLIM_VERSION {0.1}
!path /home/kleer/waferslim-1.0.2
!define COMMAND_PATTERN {python -m waferslim.server -v --syspath %p }

Luego poner el test, tomado del docstring de algunos de los ejemplos que se encuentran en la distribución de WaferSlim. Por ejemplo

|import|
|waferslim.examples.decision_table|

|should I buy milk|
|cash in wallet|credit card|pints of milk remaining|go to store?|
|      0       |    no     |      0                |    no      |
|      10      |    no     |      0                |    yes     |
|      0       |    yes    |      0                |    yes     |
|      10      |    yes    |      0                |    yes     |
|      0       |    no     |      1                |    no      |
|      10      |    no     |      1                |    no      |
|      0       |    yes    |      1                |    no      |
|      10      |    yes    |      1                |    nope    |

|should I buy milk alternative implementation|
|cash in wallet|credit card|pints of milk remaining|go to store?|
|      0       |    no     |      0                |    no      |
|      10      |    no     |      0                |    yes     |
|      0       |    yes    |      0                |    yes     |
|      10      |    yes    |      0                |    yes     |
|      0       |    no     |      1                |    no      |
|      10      |    no     |      1                |    no      |
|      0       |    yes    |      1                |    no      |
|      10      |    yes    |      1                |    nope    |


Apretar el botón de test y ¡listo!

(*) Versión del protocolo

La versión de WaferSlim que se encuentra en pypi fue probada con el fitnesse.jar release 20100103.
Si se usa esa versión de Fitnesse, no es necesario configurar SLIM_VERSION {0.1}

martes, 15 de abril de 2014

Reporte de defectos (bugs) en Scrum

Una pregunta muy frecuente en los equipos que están implementando Scrum es si tienen que seguir usando una herramienta de seguimiento de defectos, y si lo uso que deberían registrar en la misma.

Veamos primero la respuesta revolucionaria y después una respuesta evolutiva. 
Y luego el análisis en cuanto al momento en que se detecta.

Nota: en todos los casos que comentamos, la importancia o prioridad de los bugs se debe acordar en el Scrum Team (Dev Team + Product Owner + Scrum Master), teniendo la última palabra el PO basado en el impacto en el negocio.

Revolución: Hay una sola lista de pendientes

El backlog contiene todo lo que hay que construir. No hacemos diferencia entre bug y funcionalidad nueva.
Un bug que provoca que las pruebas automáticas estén en rojo (falla alguna de las pruebas) debe corregirse en el momento o esa funcionalidad debe quitarse (o desactivarse).
Si encontramos un bug durante la prueba exploratoria que es crítico, agregamos una prueba automática que lo evidencie. 
Todo otro bug se considera un cambio a una funcionalidad existente y se prioriza junto con otras funcionalidades.

Evolución (orgánico): Lista de bugs

El Product Owner dispone de varias fuentes: pedidos de los clientes, ideas propias de nueva funcionalidad, y un lista de los bugs que persisten en el producto. Cuando se planifica el sprint, se consideran los bugs más complejos como nuevos requerimientos, y los chicos se agrupan en paquetes de corrección. En ocasiones se define un tiempo fijo que se dedicará a corrección de todos los bugs que se puedan.

Caso bug detectado en una historia que se está desarrollando

  • Primera opción, corregirlo dentro del sprint como parte del desarrollo de la historia
  • ¿Y qué pasa si no llegamos con todo lo comprometido? 
    • Recortar la funcionalidad para que ese bug no sea relevante y agregar una historia con esa funcionalidad recortada. 
    • Si es muy grave, quitar la funcionalidad correspondiente y la historia queda sin hacer. Quizás pueda resolverse e el próximo sprint.
    • El bug es poco importante como para hacer alguna de las anteriores: si no es importante ahora, ¿cuándo lo será? Podemos registrarlo en una herramienta o tiralo a la basura, si aparece alguien a quien le importe, lo pedirá. Esta última es la forma más realista en el largo plazo. Las listas interminables acumuladas de bugs son un consumo de tiempo y esfuerzo de todo el equipo.

Caso bug detectado luego de liberada una historia

Hay varias alternativas:
  • Se maneja como una historia de usuario (si es grande)
  • Se agrega a las lista de ideas a revisar en el refinamiento de backlog, tanto para estimar como para evaluar la prioridad. Luego del análisis, se carga en el backlog / lista de bug si se quiere corregir en los próximos sprints, o se descarta.
  • Se corrige a medida que aparecen. El equipo debe manejar el impacto en cuanto a cambio de alcance. Por ejemplo: tener un tiempo fijo dedicado en el sprint para corrección de bugs. O poner un límite de bugs abiertos (por ejemplo 10) y se debe detener el desarrollo de nueva funcionalidad hasta tanto se corrijan los bugs que hay en exceso. 

¡Espero este breve recorrido te ayude!

miércoles, 5 de marzo de 2014

Reunión Agile Peru en Lima el 27 de Febrero

Aprovechando mi estadía en Lima, el jueves pasado fui a la reunión mensual de Agile Perú. Nos reunimos en Avantica, que prestaron la sala y proporcionaron bebida.

Se presentaron temas y luego se votó, en un estilo Open Space. Iniciamos unas 15 personas y hubo unas 25 personas en total. Había un par de personas nuevas en agilidad, y personas con mucha experiencia. Se planteó hacer dos tracks, uno introductorio, pero finalmente se unificó en una sola ronda


Hubo tiempo para 4 temas, y podes ver todas las fotos en el album. Además, facilité gráficamente las charlas.

Mejores prácticas de Estimación

¡Sería mejor hablar de buenas prácticas, no de mejores!
Se partió de la pregunta frecuente del tipo: "como hago para estimar agile mejor que como lo hago ahora". Esto lleva a entender que si hacemos lo mismo que antes no podemos mejorar la estimación, y de ahí pasamos a entrega incremental, formatos alternativos de contratos, confianza, negociación win-win,  y alternativas para estimar al inicio de un proyecto con un equipo nuevo.
   

¿Cómo manejar proyectos llave en mano?

Casualmente (o no tanto :D) la conversación derivó naturalmente en el siguiente tema. ¿Cómo manejamos proyectos llave en mano?
A su vez, la pregunta fue cambiando a "cómo convencemos a nuestros clientes que entrega incremental y colaboración es mejor él? 

¡El rol de Product Owner es una gran mentira!

Esta fue una sesión propuesta por mí. Plantee una discusión, en cuanto a la utilidad y aplicabilidad del rol de Product Owner, usando 3 casos en los que creo que no aplica (Organización de conferencias, Pproducto masivo, Open source), y tres hipótesis que no siempre son ciertas (Product Owner como priorizador de necesidades, Capacidad fija del equipo, Software funcionando como medida del éxito).


Técnicas Retrospectivas (Motivar participación)

Un par de personas expusieron la situación del proyecto en el que estaban (distribuido, largo) y nos dieron una excelente oportunidad para hablar sobre las características de las retrospectivas efectivas, como identificarlas y fomentarlas.



Cierre
Por lo que comentaban, fue una buena reunión. La comunidad limeña viene de un año en el que las reuniones giraban en torno a organización de eventos (sobre todo Ágiles 2014, que exigió mucho trabajo). Y ahora disfrutan de las reuniones de intercambio de ideas y experiencias. La organización es super liviana: El lugar y las bebidas ofrecidos por una empresa, las charlas se definen en el momento. 

Les dejo el link al albúm de fotos

lunes, 27 de enero de 2014

Evaluación y autoevaluación docente: ¡Analízame!

Desde el inicio de Kleer, siempre hubo foco en la mejora y la innovación en los productos y servicios que brindamos. 
En particular, la forma en que facilitamos cursos, talleres y otras instancias de proceso enseñanza- aprendizaje está siempre cambiando, exploramos y compartimos entre nosotros tanto lo que funcionó como lo que no.
A lo largo de los últimos 3 años esto a incluido, entre otras cosas:

  • Salirnos del centro del proceso educativo, dando más lugar a la intaracción entre los asistentes 
  • Facilitar y documentar gráficamente
  • Incorporar música
  • Repensar el componente visual (no usar proyector salvo para ver videos, fotos o software que los asistentes usarán en el curso)
  • Incorporar actividades lúdicas
Aunque no tenemos "la manera correcta" de facilitar el aprendizaje, necesitamos continuo feedback. Una fuente de feedback son los alumnos. Otra son otros compañeros docentes, y nosotros mismos.

 Para estos últimos dos casos, escribimos una lista de lo que no gustaría saber sobre cómo hacemos nuestro trabajo. 
La copio más abajo en su versión actual. La mantendremos actualizada en el libro Educación Participativa, que estamos escribiendo con Pablo Tortorella sobre todos estos temas. 


Sugerencia: en cada punto del cuestionario podés usar Perfection Game (ver capitulo 15 de Software for Your Head ).
NO ES: un checklist sobre la experiencia completa del curso, que implica como el asistente se entera,
el material de difusión, la experiencia de registración, facturación y cobro, la logística organización
del lugar, la calidad o cantidad de comida y bebida, etc.

Cuestionario
Previa / precalentamiento
• ¿Tenés claros lo objetivos del training, lo mínimo que tiene que lograr los asistentes? ¿Cómo
esperas que cambien su comportamiento por lo que aprendieron?
• ¿Enviaste información relevante del curso con suficiente anticipación, distinguiendo las
preparaciones necesarias de las adicionales? ¿Tienen para material variado para elegir (leer,
videos, hacer, hablar con otros, investigar)?
• Lo pedido en el precalentamiento, ¿se usó durante el curso?
Bienvenida
• La primera impresión: música, elementos ordenados con atención en lo visual, actividad para
conectarse desde el primer momento.
• Ambiente seguro y cómodo: bebida / comida / lugar de baños / agenda de la actividad /
temperatura / espacio / luz
Durante
• ¿Cuánto tiempo sos el centro de atención (debe ser menos del 25%)?
• ¿Creaste el ámbito para que se enseñen entre ellos?
• Manejaste bien la participación: participaron todos y ninguno acaparó el tiempo, separaste
bien los temas que eran relevantes para este entrenamiento y los que quedan para charla de
break o para información adicional.
• Actividades Grupales:
– ¿Hubo actividades individuales, de a pares o tríos y grupales?
– ¿Variaron los grupos?
– ¿Variaste los medios? Ej.: presentación con proyector, video, storytelling, facilitación
gráfica, lectura, escritura, movimiento corporal, actuar una situación.
• Actividades:
– ¿Las consignas resultaron claras, ayudaste durante las actividades para amplificar las
oportunidades de aprendizaje y para rescatar temas a comentar en la puesta en común?
– ¿Hubo tiempo para la puesta en común?
– ¿Música en actividades de introspección?
• Material de Soporte:
– ¿El material de soporte (Conceptos y workbooks) fueron usados?
– ¿Fueron útiles?
– ¿Los alumnos se los llevaron luego del curso?
• Material Adicional:
– Referiste durante el curso a material adicional para profundizar?
– ¿Lo dejaste registrado en algún lado para enviarlo en el cierre virtual?
• ¿Referiste durante el curso a experiencias propias y de otros? ¿Comentaste cómo esto se
relaciona con actividades comunitarias y de terceros?
• ¿Documentaste (fotos, videos, material adicional) para el cierre?
Breaks y Almuerzos
• ¿Es claro y cumplible el tiempo dedicado al break? En cursos largos, das tiempo para que los
asistentes revisen rápidamente sus mensajes / mails / llamados?
• ¿Estás presente para consultas y socialización?
Cierre y despedida en el lugar
• ¿Tomaron los alumnos compromisos de acción?. Foto grupal. Feedback del curso.
Cierre y despedida virtual
• Resumen fotográfico, referencias y lecturas adicionales, datos contacto o actividades comu-
nitarias, tus próximas actividades. Todo enviado dentro de las 24 horas posteriores al curso.
Contactos luego del curso.

martes, 12 de noviembre de 2013

Testers, el Sombrero Negro y los riesgos

Varias veces en mi carrera he tomado el rol de tester, ya sea como miembro de equipo o como consultor, y con ese rol me ha tocado participar en reuniones en las que se analizaban las estrategias de pruebas y la relación con los riesgos.

En algunas de las reuniones en las que participé sentí que mis preguntas y comentarios generaban incomodidad, incredulidad o incluso enojo. De alguna manera, la forma en que estaba planteada la reunión o la forma en la que yo participaba de la misma, no facilitaban la exploración de ideas o caminos alternativos.

Origen de la incomodidad

En mi última retrospectiva personal (hansei) estuve pensando en el origen de esta situación, y que podría hacer para cambiarla la próxima vez que estuviera en esa situación.

Posibles fuentes de incomodidad

  • Mezclar en la reunión diferentes momento del proceso creativo que lleva a un plan de prueba:
    • La instancia de identificación y exploración de los riesgos 
    • La evaluación del impacto y probabilidad de los riesgos
    • La ideación de mitigaciones
    • La evaluación de riesgos secundarios.
  • Percepción de que alguna persona en la reunión está evaluando el trabajo pasado en vez de estar trabajando en los próximos pasos.
  • Falta de práctica de los asistentes con técnicas de innovación. Por ejemplo criticando las ideas desde el mismo momento en que se plantean, y no aplicar resonancia (utilizar si... pero, en vez de si... y además).

Mi lista de accionables


  • Validar al inicio de la reunión el objetivo, dinámica y agenda. Marcar a lo largo de la reunión donde estamos, y si nos apartamos reevaluar si volvemos a la agenda original o la modificamos.
  • Siendo que últimamente participo como consultor, explicitar que tengo poco contexto, y que por favor tomen mis intervenciones como disparadores de ideas.
  • Facilitar gráficamente la charla, para ayudar a que todos estemos en la misma página.
  • Ser el primero en seguir las recomendaciones: no juzgar las ideas cuando las generamos, construir sobre las ideas de los demás (resonancia), manter en foco en las seleccionadas.

Riesgos secundarios

No todas las reuniones tienen las estructura "generar ideas y luego converger a solución". 
En algunas grupos o reuniones se espera que el experto diga "cómo deben hacer las cosas" y por más que yo crea que sea mejor construir entre todos, debo escuchar lo que se espera de mí, y al menos explicitar la tensión. Muy ligado a Cynefin, sólo sirve buscar "la mejor forma" de hacer las cosas cuando estamos en un contexto Simple (algo de eso en mi post sobre La mejor forma de Probar).
En otros grupos, "no hay tiempo" para analizar las alternativas, debemos pasar directamente a definir la acción. Lo mejor es detectar esto antes de la reunión, hablando con los participantes para entender las expectativas y, como último momento responsable, se puede aclarar en el inicio de la reunión, cuando se plantea la agenda.

jueves, 7 de noviembre de 2013

¿Automatizamos las pruebas de regresión?

Trabajo en una aplicación en la que cada vez que mis usuarios piden un cambio, el costo de hacer el cambio es mucho menor que el costo de probar. La aplicación no tiene automatizada la prueba y no es modular.

Esta situación la he escuchado y vivido muchas veces en mi carrera. Ante esa situación, hay varias acciones posibles:

  1. Tenemos que hacer de nuevo el sistema, y esta vez lo haremos bien.
  2. Redefinamos el sistema para que sea más fácil probar.
  3. Automaticemos la prueba.
  4. Contratemos más testers.
  5. Sigamos sin cambiar durante algún tiempo.

No puedo en este post analizar todas las alternativas, pero voy a seguir una linea de razonamiento posible, asumiendo algunas creencias, básicamente que las prácticas de desarrollo ágil me pueden ayudar en este caso (Más información sobre estrategias en Working Effectively with Legacy Code). 

Entonces, la secuencia de pensamientos sería:
  • Me gustaría hacerlo bien, pero no puedo tirarlo y empezar de nuevo, el negocio debe seguir operando y la aplicación se debe seguir adaptando. Entonces, trabajaremos en hacerlo bien, pero en forma incremental
  • Para redefinir el sistema sin romperlo, y dado que trabajaremos incrementalmente (muchos pequeños cambios) necesitamos pruebas automatizadas, al menos de nivel funcional. Esto permitirá que probemos a bajo costo cada versión del sistema con un nivel aceptable de calidad. No reemplazamos las pruebas manuales, pero al menos distribuimos las pruebas entre dos ciclos: uno automatizado, rápido y frecuente, otro manual, costoso y que corremos antes de liberar versiones.
  • Hacer bien la aplicación implica modularizar, tener pruebas automatizadas unitarias y calidad interna. Estas importantes ideas y prácticas no las estoy tratando en este post, pero suelen tener como precondición las pruebas funcionales automatizadas a las que me refierno en este post.
Vemos muchas equipos y empresas que siguen esta linea de pensamiento. Entonces el problema se puede reeplantear.

Quiero automatizar las pruebas de regresión, ¿cómo lo hago?

Quiero automatizar las pruebas de regresión, ¿cómo lo hago? ¿Qué herramientas uso? ¿lo hago con personas del equipo o contrato fuera? ¿cómo cambian los roles, que tenemos que aprender? ¿qué y cuánto tengo que probar para lograr confianza?

La respuesta a estas preguntas: Depende. 
Bien, pero ¿de qué depende?

El equipo ¿tiene cultura de calidad?

Algunos miembros del equipo se ocupan de la calidad, dedican tiempo a pensar como probar y manejar los riesgos. Ya se hacen pruebas, y el problema es como automatizarlas.

¿Cómo es la estructura y cuales son los conocimiento del equipo?

La prueba manual la realiza un grupo externo, o los testers del equipo (hay personas cuyo puesto o posición es Tester), o las pruebas las realizan varias personas que cubren el rol de tester, pero también otros roles (analistas, programadores, diseñadores gráficos).
Los que cumplen rol de tester, ¿tienen conocimientos sobre programación o les interesa adquirirlos?
Funciona el equipo como un Whole Team en el que todos toman responsabilidad sobre el resultado conjunto y no sobre un subconjunto ("yo pruebo, no programo" o viceversa)

¿Cómo es la tecnológicamente la aplicación?

Para disminuir la curva de aprendizaje y mejorar la aceptación de las nuevas herramientas, es conveniente que la tecnología de la prueba automática sea cercana a la utilizada para la aplicación. ¿El equipo trabaja con .Net, Java, Ruby, Python?

Nuestra respuesta

Cada equipo debe explorar qué organización, herramientas y conocimientos les servirán para su caso.
Lo que encontramos desde Kleer (en este caso Nicolás Páez, Juan Gabardini, Carlos Peix), es que solemos repetir, al inicio de las consultoría de estos temas, una mínima nivelación de conocimientos y del abanico de posibilidades en cuanto a prácticas y herramientas, para facilitar a los equipos tomar decisiones. Pensamos que sería útil extraer esto en una serie de talleres cortos (medio día cada uno):