DevOps en Startups

Recientemente participé en la transición de una startup, que está yendo más allá de las pruebas de conceptos y de los pilotos hacia un negocio autosustentable. Comparto lo que aprendimos.

¿DevOps es distinto en Startups?

El movimiento DevOps busca derribar las paredes entre las áreas de las empresas, para lograr que las soluciones se construyan incluyendo el aporte de todos los involucrados. Esto permite disminuir el tiempo que toma pasar de la idea al producto, lo que a su vez permite aprender y ajustar el rumbo con mayor velocidad.

En las Startups,  por el contexto riesgoso y desconocido, es necesario aprender y ajustar el rumbo con velocidad. ¡Bingo! El objetivo de DevOps y las necesidades de las Startups coinciden.

Por otro lado, el foco inicial de las Startups es descubrir el producto y el mercado. Hay relativamente pocos usuarios y el mayor riesgo es hacer el producto incorrecto. Al inicio se pone menos atención a la operación.

Como reflejo de esto, en muchas Startups no hay un área de Operaciones separada. Y si la hay, hubo mucho menos tiempo de levantar muros entre esta y el área de Desarrollo.

Entonces, ¿cuál es el desafío?

El desafío de DevOps en Startups

Inicialmente validamos con pocos usarios que el producto genera valor. Luego la prioridad pasa a ser hacerlo disponible para muchas personas. Buscamos incorporar los atributos necesarios para seguir creciendo (por ejemplo: escabilidad, confiabilidad, que sea operable y tenga soporte) afectando poco en la velocidad del equipo. Queremos mantener al equipo en el centro de la acción, incorpore los conocimientos y responsabilidad de Operaciones.

Algunos de los análisis sobre DevOps (como The Phoenix Project o el Continuous Delivery Maturity Model) asumen que la organización ya tiene un área de Operaciones funcionado.

El desafío es encontrar un camino de evolución para que el equipo incorpore responsabilidades y actividades de Operaciones sin desatender la mejora del producto.

Estos son algunos de los riesgos en ese camino:

• Que el esfuerzo de incorporar conocimientos y prácticas de operaciones le quite foco al equipo y no se pueda seguir con el ritmo de innovación.
• Que el equipo vea las actividades de operaciones o soporte como aburridas. Esto bajaría la motivación del equipo.
• Que no se incorporen buenas prácticas de operaciones. Esto bajaría la calidad de la experiencia del usuario.

¿Cómo lo hacemos?

¿Qué es Operación en IT?

Cuando hablamos de que el equipo incorpore responsabilidades y actividades de Operaciones, ¿lo tenemos que hacer como un todo o podemos dividirlo?

Intentaremos una posible división en roles, que nos permita incorporar el conocimiento incrementalmente al equipo o buscar soluciones alternativas:

• Soporte de Operaración: Mantener la aplicación funcionando, lo que incluye entre otras cosas estar al tanto de los consumos de recursos para realizar escalamiento (según políticas preestablecidas), responder a incidentes como por ejemplo servicios caídos, realizar provisioning de ambientes, instalar versiones, realizar copias de resguardo.
• Ingeniería de Operaciones: Anticiparse a los problemas relacionados con el software de base y infraestructura (red, almacenamiento, procesamiento), estando al tanto de las actualizaciones de seguridad, versiones de software que dejan de estar soportadas, manejo de licencias.
• Arquitectura: Colaborar con el equipo en el diseño de la aplicación, incluyendo consideraciones sobre la forma de despliegue, radar de tecnologías, buenas prácticas para lograr los atributos de calidad buscados (como seguridad, escalabilidad, confiabilidad, etc.).

Conviene recordar que sobre esto hay mucho análisis, reflejado en ITIL. Hay mucho para reutilizar si mantenemos la visión de simplicidad que tiene la agilidad. Por ejemplo, en muchas Startups, es necesario implementar manejo de Incidentes y Resolución de problemas. Estos procesos pueden implementarse siguiendo las buenas prácticas de ITIL.

Alternativas

Pensamos algunas alternativas de solución, cada una con sus pros y contras:

• Manejarlo con el equipo actual.
• Incorporar personas en el equipo (permanente o temporal) con experiencia en Operaciones.
• Aumentar temporalmente la capacidad del equipo.
• Tercerizar el servicio
• Delegar al usuario
• Automatizar las actividades de operaciones.

Para decidir deberíamos analizar el caso concreto, y experimentar distintas alternativas para resolver los problemas en orden de prioridad.

Caso Ejemplo

El caso es una startup que tuvo éxito con un piloto y va a empezar a vender el servicio, lo que implica mantener un SLA (Service Level Agreement o Acuerdo de Nivel de Servicio) en cuanto a disponibilidad, resguardo de datos y escalabilidad ante la incorporación de nuevos clientes.

Con personas sumadas en forma temporal al equipo, se evaluó y decidió modificar la arquitectura de despliegue, para pasar de máquinas virtuales a servicios en la nube (Amazon Web Services). El estado del ejemplo al momento de este reporte, solo una foto dentro de la evolución:

• Parte de la Soporte de Operación se mantuvo dentro del equipo, con herramientas de monitoreo provistas por la plataforma. Se mantuvo y extendió la automatización de la instalación.
• Parte de los actividades de Soporte de Operación e Ingeniería de Operaciones fueron delegadas a la plataforma: Actualización de versiones y seguridad, parte de los mecanismos de alta disponibilidad y escalamiento.
• Arquitectura: Se detectó una oportunidad de mejora, que se realizaría conjuntamente entre miembros del equipo y las personas sumadas al equipo en forma temporal.

Conclusión

En las empresas establecidas, el conocimiento sobre cómo Operar existe, pero está en áreas separadas. El desafío en la transición hacia DevOps es derribar las barreras internas entre áreas y compartir ese conocimiento. Además, las formas de desarrollo deben adaptarse, como por ejemplo automatizar builds y pruebas.

En las Startups la dificultad está en incorporar la Operación de manera incremental, profesional y sostenible a la empresa y al equipo (en una Startup son prácticamente lo mismo).

Cápsulas de Testing - Qué son y Próximas fechas

Próximas cápsulas

Webinar (¡Inscríbete!):

• Viernes 12 de mayo - 13:15 a 14:00 hs GMT-3 - Arquitectura de la prueba automática
• Viernes 19 de mayo - 13:15 a 14:00 hs GMT-3 - Page Object

En TestingUy: Lunes 15 de mayo - 11:30 - 13:30 hs

(bajate el draft del libro en pdf)

Cápsulas de Testing - Estrategias de Datos v2

En los equipos que desarrollan ágilmente se busca que todos los miembros del equipo tenga un conocimiento mínimo de las actividades de testing. También que los testers profundicen su conocimiento.

¿Cómo podemos distribuir ese conocimiento?

Las cápsulas de información de testing son una manera incremental de incorporar conceptos a partir de ejemplos del equipo o externos. Pueden servir como guía para realizar círculos de aprendizaje en el equipo de desarrollo o para profundizar conocimientos en comunidades de práctica.

Algunas cápsulas de conocimiento: Arquitectura de la prueba Automática, Modelo del Oráculo y Pruebas Diagnósticas.

En este caso, nos encontraremos 45 min el 21 de abril de 2017 (¡mañana!) para hablar sobre las estrategias de preparación de datos para pruebas automatizadas, de 13:15 a 14:00hs Bs As.

Agenda

• Presentar el concepto (10 min).
• Trabajar en grupos para analizar el ejemplo, o un caso particular (20 min).
• Presentar los resultados (10 min).
• Cierre (5 min).

Anotate

(Próximo encuentro, viernes 28 de abril, votá los temas)

Cápsula de Pruebas - Datos de Prueba

¿Cómo generar los datos de prueba? ¿Cómo lograr que los datos estén en disponibles en el momento de la prueba?

¿Cómo lo he hecho?

Para ejecutar las pruebas automáticas, necesitamos que la aplicación o SUT (System Under Test) esté en un estado conocido. Ese estado incluye los datos necesarios para la prueba.

Toma una prueba que estés realizando en este momento o que realizaste hace poco, piensa y anota:

• ¿Cómo obtuviste o generaste los datos de prueba?
• ¿Cómo lograste que esos casos de prueba estén cargados o disponibles para el SUT?

Generación de datos

Por Diseño: Se inventan datos que ejercitan la funcionalidad a desarrollar. Los ejemplos pueden estar basados en la experiencia en el negocio o en las hipótesis de uso futuro. Por ejemplo, generar datos que corresponden a situaciones límites y de error, hayan ocurrido o no.

Datos Reales: Tomar un conjunto de datos de la aplicación actual o del problema a resolver. Por ejemplo, tomar los conceptos facturados  en el último mes, o los clientes y movimientos de una sucursal durante el año pasado.

Simulados: Utilizar un algoritmo para generar datos. Por ejemplo, todas las combinaciones posibles de los variables de entrada, o valores aleatorios.

Object Mother: Cada entidad de la aplicación tiene un mecanismo para generar objetos de prueba. Normalmente con datos default y las entidades adicionales las genera recursivamente. Por ejemplo, una prueba que necesita un cliente, la prueba le pide a la entidad Cliente una instancia de prueba. Cliente genera un cliente que tiene un nombre y apellido default (Juan Perez). Para completar el país de nacimiento,  Cliente le pide a la entidad Pais una instancia de prueba.

Estado conocido

Cargar cada vez: Cargar los datos para cada prueba. Esto puede hacerse a diferentes niveles: desde el repositorio de los datos (base de datos, archivos), desde una capa de servicios o componentes, a través de la funcionalidad disponible para el usuario final. Puede cargarse a partir de un estado inicial vacío, o como incremento. Puede ser necesario modificar datos (fechas, números de referencias cruzadas).

No cambiar: Se llega al estado conocido y se lo proteje. Por ejemplo backup y restore de bases de datos, se utilizan transacciones de base de datos, se realizan operaciones que no modifiquen datos o se realizan operaciones que revierten la operación realizada en la prueba.

Existentes: Asumiendo que tenemos un volumen alto y variado de datos, realizamos una búsqueda que nos traiga un dato con las características que necesitamos.

Mock (o dobles): Reemplazamos un componente del sistema, que no nos interesa probar, por un mecanismo que devuelva datos conocidos. Pueden ser siempre los mismos datos o puede ser más inteligente.

Actividades

Analiza el siguiente ejemplo y proponer la estrategia para los datos de prueba:

Tenemos una aplicación monolítica que resuelve una parte central del negocio de nuestra organización. Siguiendo las buenas prácticas actuales, se busca migrar hacia una arquitectura de microservicios. La migración será incremental, y en cada micro servicio se va a realizar en dos fases: duplicar funcionalidad mínima de la aplicación actual, y luego agregar funcionalidad nueva, valiosa para el negocio.

La aplicación actual tiene algunas pruebas automatizadas a través de la UI.

Queremos que puedan trabajar en paralelo los equipos que modifican el sistema monolítico remanente y los que desarrollan cada nuevo micro servicio.

¿Qué alternativas tenemos para generar los datos de prueba?

¿Cuáles son los pros y contras de cada una de las alternativas?

Capsulas de Testing - Estrategias de Datos

En los equipos que desarrollan ágilmente se busca que todos los miembros del equipo tenga un conocimiento mínimo de las actividades de testing. También que los testers profundicen su conocimiento.

¿Cómo podemos distribuir ese conocimiento?

Las cápsulas de información de testing son una manera incremental de incorporar conceptos a partir de ejemplos del equipo o externos. Pueden servir como guía para realizar círculos de aprendizaje en el equipo de desarrollo o para profundizar conocimientos en comunidades de práctica.

Algunas cápsulas de conocimiento: Arquitectura de la prueba Automática, Modelo del Oráculo y Pruebas Diagnósticas.

En este caso, nos encontraremos 30 min el 31 de marzo de 2017 (¡mañana!) para hablar sobre las estrategias de preparación de datos para pruebas automatizadas.

Anotate

TestComplete y Git

En un grupo están trabajando con TestComplete, una herramienta que permite automatizar aplicaciones de escritorio (y muchas más cosas).
Estaban manteniendo las pruebas con versionado por directorios y decidimos moverlos a git.

La solución es sencilla, ya que TestComplete tiene integración con git.

Agregar en la raíz un archivo .gitignore con contenido

Log/

Luego se pueden seguir los pasos normales para subir un proyecto existente a un repo. Por ejemplo en GitHub.

¿Y que pasa si te olvidás del paso del .gitignore?

En ese caso, la subida de los logs puede tardar mucho tiempo, incluso dar timeout. En nuestro caso, contenido completo de la carpeta del proyecto con sus logs pesaba 500Mb!

¿Cómo borrar completamente algo de Git?

Quitar de la versión

En este caso, para borrar todos los directorios Log

find . -name Log -print

Tomar de la salida todos los directorios resultantes y armar lineas como la que está a continuación, que quitan los directorios del repo local, pero lo dejan fisicamente.


git rm -r --cached <directorio>/Log

Luego podés validar que estén borrados en Git.

Ahora si, agregá el .gitignore (como está indicado arriba).



Y comitear y subir al repo. 

git status

git commit -m ‘borrar logs’
git push

Validar que en repo remoto no esten los Logs.

Quitar de toda la historia

No es común querer modificar la historia de Git. Y la forma estandard brindada por git es lenta.

Usamos una herramienta llamada BFG.

git clone --mirror https://github.com/<user>/<repo> <repo>_mirror

cp -a <repo>_mirror/ <repo>_backup/

cd <repo>_mirror
java -jar ~/Downloads/bfg-1.12.14.jar --delete-folders Log

git reflog expire --expire=now --all && git gc --prune=now --aggressive

git push

En nuestro caso, pasamos de un repositorio de más de 1Gb a uno de 380Mb.

Ya no estamos en testing Kansas

Nota: El título hace referencia a "We're not in Kansas anymore", del Mago de OZ.

¿Dónde estamos?

La agilidad surgió como una revolución de una clase oprimida; la de los programadores que lucharon para liberarse de los Project Managers.

Han pasado 15 años desde el Agile Manifesto. La revolución ha cumplido su objetivo. Los programadores lograron ser reconocidos como miembros igual de importantes dentro de los equipos de desarrollo. Pero, ¿Qué pasó con los testers?

En el primer proyecto ágil en el que participó uno de los autores, el grupo estaba cambiando su forma tradicional de desarrollo de software a una dinámica ágil. Era inicialmente un grupo compuesto por tres equipos de programación y uno de testing.

Durante el cambio, algunas personas del equipo de testing se sumaron a los programadores para formar equipos de desarrollo que incorporen la calidad desde el inicio. Pero el cambio no fue completo, los testers se ocuparon en acercarse a los programadores automatizando pruebas. Pero en los últimos dos días de cada sprint, cuando se corrían las pruebas finales (automáticas y manuales) antes de liberar el producto, algunos miembros del equipo no tenían respiro (los testers), mientras otros miembros del equipo se dedicaban a jugar al Counter Strike. Eso sí, con auriculares para no molestar. En este contexto, donde la calidad esperaríamos que fuera interés de todos, las tareas de testing no las toman los programadores.

La historia que contamos muestra una implementación incompleta del enfoque Whole Team o equipo completo. Pero ¿qué pasa si logramos una buena implementación? Si todos los miembros del equipo se ocupan de la calidad, entonces ¿el tester desaparece?

El rol de tester en un equipo ágil

Si definimos lo que somos por lo que hacemos (testeo, por lo tanto soy tester) no sólo nos auto-limitamos en nuestro crecimiento personal sino que además limitamos la capacidad de nuestro equipo para encarar desafíos.  

El equipo debe tener los conocimientos y capacidad para testear, los cuales no necesariamente deben estar centralizados en una persona, sino que pueden ser parte de un rol y ese rol puede estar distribuido en varios miembros del equipo. De esta manera todo el equipo es responsable de la calidad.

El rol de testing ágil tiene algunas diferencias con el testing tradicional. En lugar de una persona exclusivamente preocupada por el detalle, el rol de testing ágil ajusta el nivel de detalle según el análisis que se esté realizando. En lugar de enfocarse en probar el producto, se ocupa en que el producto se construya con calidad.

En el testing ágil además de ser importante probar que hicimos lo que nos pidieron, resulta central considerar las razones y el contexto en el que nos lo pidieron. De esta manera, puede detectarse si estamos logrando el objetivo original, si tenemos la oportunidad de lograr un producto que exceda las expectativas y en general, sí mantenemos la mirada en la visión y los pies en la tierra. Luego, podemos distinguir el grado de importancia de los distintos temas identificados y tomar decisiones considerando esa guía: ¿Qué nos acerca a la visión? ¿Qué nos dificulta avanzar?

En resumen, consideramos que las siguientes características resultan centrales para el rol de testing ágil:

• Comprender la visión de negocio: ¿Que proceso de negocio es el prioritario? ¿Cuáles son los objetivos y sus métricas relevantes que cierta funcionalidad intenta mejorar?
  
• Conocer el proceso de desarrollo: Dentro del rol de testing ágil está trabajar continuamente para que la calidad esté incorporada al proceso de desarrollo. Si detectamos un problema en el ambiente de aceptación, tratemos de agregar un test para que la próxima vez se detecte en el ambiente de desarrollo. Optimizar el proceso muchas veces implica automatizar la prueba de regresión. Y avanzando por este camino, vemos que la calidad desde temprano nos permite más velocidad, como puede verse en Continuous delivery.
• Saber cómo diseñar experimentos: Esto nos sirve para validar hipótesis del negocio (Lean Startup), para probar que estamos haciendo el producto correcto y bueno para nuestros clientes, como para mejorar nuestro proceso de desarrollo. También tenemos hipótesis sobre aspectos que afectan la calidad y hacemos experimentos probando el producto.
• Conocer sobre testing en sí mismo: Es más fácil conseguir capacitación sobre programación o gestión de proyectos que sobre testing. Hay poca bibliografía y poco tiempo dedicado a la mejora del testing (katas, dojos, craftsmanship). Sin embargo hay mucho para aprender: evaluar las dimensiones de variación del sistema, identificar dimensiones válidas para probar, definir si es posible probarlas de forma independiente, etc. También resulta necesario conocer las diferentes heurísticas de prueba, los problemas comunes que dependen de la tecnología usada e identificar el conjunto que es posible probar en cada momento del desarrollo.
• Riesgos: ¿Cuál es nuestra peor pesadilla? ¿Cuáles son las formas en que se puede romper el producto?¿Qué podemos perder, vidas, dinero, clientes? Las respuestas a estas preguntas nos orientan tanto en la definición de alcance de las pruebas como para su priorización. Conociendo los riesgos podemos elegimos cómo manejarlos. Tomar riesgos en forma controlada nos permite ir más lejos más rápido y ser más innovadores, que si quisiéramos evitar todos los riesgos. Ver mi post anterior sobre el tema.

¡Cómo que en la lista no está ...!

Algunas dudas surgen de esta enumeración: ¿qué pasa con la automatización de la prueba, la usabilidad, la seguridad?

En un equipo de desarrollo ágil es bueno que todos se ocupen en aprender sobre programación, testing, usabilidad, seguridad y probablemente otras cosas también. 
Automatizar, automatizar, automatizar: Es el mantra de todos los miembros del equipo. Es parte de lo que llamamos Conocer el proceso de desarrollo. Para ello es útil que todas las personas de equipo puedan escribir scripts al respecto, pero no necesariamente ser todos expertos en herramientas. Como testers, podemos trabajar de a pares con los expertos.
Pero no todos tienen que ser expertos en todo. Nos parece útil, por lo tanto, dejar esos temas en otros roles. Cada persona desarrolla su especialidad, profundizando y participando de comunidades de práctica. Además, aprende de sus compañeros de equipo sobre otras áreas. Entonces una persona que cubre principalmente el rol de testing, puede además conocer sobre programación lo suficiente como para automatizar situaciones normales y pedir ayuda ante problemas técnicos complejos.

¿Pero es tan distinto el testing en ambientes ágiles del testing tradicional?
Una pregunta que naturalmente surge es: ¿Cuáles de estas características no están en el rol tradicional?¿Son exclusivas del rol del testing en un ámbito ágil?

Consideramos que ninguna de las actividades es demasiado novedosa, por lo que podríamos identificar actividades equivalentes en el marco del testing tradicional. Y encontramos dos diferencias: 

No hay en el equipo una persona cuya única tarea sea probar y que concentre toda la prueba necesaria. Sí se encuentra definido un rol, que cubierto por diferentes personas, con distinto grado de involucramiento. Así es posible compartir más tiempo con otros y esto da lugar a más oportunidades de aprender, crear e innovar.

¿Y ahora qué?
Considerando la diversidad de conocimientos necesarios para cubrir de manera completa el rol del testing, es posible identificar quienes son los miembros del equipo más adecuados para cubrir esas necesidades y que ellos se interesen, no sólo por profundizar el conocimiento sobre esos temas, sino además compartirlos con los compañeros de equipo.

Una forma es a través de lecturas. Mi lista personal de libros: Agile Testing, More Agile Testing, Explore It!, How Google Tests Software, The Domain Testing Workbook, Continuous Delivery.

Además, junto con Natty y Ángel realizamos cursos on line de Agile Testing.

Origen del post y agradecimientos

Este post es uno más, dentro de mi búsqueda sobre el testing (ver lo que opinaba en 2009). Entre 2014 y 2015 presenté algunas de estas idea en JAIIO 43, Ágiles 2014 (en Open Space con Juan Diego Vasco Moncada), CAS2014 (ver la presentación más abajo) y Agile 2015.

Gracias a Natty Davidovich (@nattydavidovich), Ángel Nuñez Salazar (@Snahider) y Nico Paez (@inicopaez) por las discusiones, revisiones y aportes a este post y a mi comprensión del testing.

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 (2008, 2012).

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.