Ya podéis descargaron el último número de la revista “testing experience”, titulado “Model-Based Testing”…o lo que es lo mismo, el testing basado en modelos. ¿Quién no ha trabajado alguna vez en empresas en las que no utilizan ningún tipo de modelo? Pues bien, si sois test managers o líderes de algún equipo y aún no tenéis ningún modelo implementado ya estáis tardando!!!!!!. Lo primero y más importante para llegar a un alto nivel de madurez es el instaurar o implementar un modelo de trabajo, una forma estandarizada de trabajar. Precisamente hay un artículo en la revista titulado “First model, then Test“, título del que estoy completamente de acuerdo…primero definimos nuestro modelo y luego testeamos.

Pero, ¿Por donde empezar si no lo tienes muy claro? Tienes varias opciones, pero primero debes de identificar el modelo de desarrollo de tu empresa ¿tradicional o “agile”? Hasta aquí muy sencillo. Tener en cuenta que un modelo nos ayudará, entre muchas otras cosas, a:

¿Cómo estandarizamos nuestros procesos de testing? Podemos usar algunos de los modelos ya existentes, como por ejemplo el TMAP e intentar implantarlo en vuestra empresa…o definir uno propio a medida de vuestras necesidades. Yo personalmente no soy un gran seguidor del TMAP, aunque he de reconocer que tengo el TMAP y el TMAP NEXT en mi biblioteca y que el TMAP tiene sus cosas buenas. Dicho esto, yo iría por la opción dos y definiría mi propio modelo basándome en las mejores prácticas. Cogería un poco de aquí y un poco de allí.

Lo primero es conceptualizar el modelo. Por ejemplo, cuatro pilares principales: Objetivos, roles, actividades de test y el ciclo de vida de pruebas. A estos cuatro pilares los podemos encapsular con la definición de procesos, herramientas y métricas (ya sabéis que no se puede medir aquello que no se puede controlar), ilustrándolo de la siguiente manera:

Imaginemos que ya tenemos nuestras ciclo de vida de pruebas, tenemos los procesos definidos, contamos con herramientas y además hemos definido algunas métricas que nos ayudarán a controlar todo nuestro modelo. ¿Cómo funcionaría esta conceptualización? veamos dos ejemplos:

Cualquier petición de negocio podría entrar en nuestro “Framework” y sería tratada de la misma manera, de forma estandarizada. Por supuesto tenéis que considerar que detrás de todo esto hay un esfuerzo importante de definición de todo el modelo que intentaré comentar en próximos artículos.

Novena entrega de la revista “Agile Record”, esta vez titulada “Testing challenges for distributed team“. Entre muchos otros he encontrado interesante el artículo de “Chetan Giridhar & Vishal Kanaujia” sobre “Understanding Test Driven Development with Python“, o lo que es lo mismo TDD. Lo encuentro interesante porque últimamente se está hablando mucho sobre esta técnica de testing, técnica empleada por los equipos de desarrollo y que muchas veces la gente la interpretar como: “hacemos TDD, así que no necesitamos a un tester en nuestro equipo”. Pues bien, este artículo no profundiza sobre si el TDD excluye cualquier otra actividad de testing, pero al menos encontraréis un ejemplo gráfico de como debería de hacerse TDD con Python. Por otro lado este artículo no tiene nada que ver con el tema principal de la revista, pero bueno, eso ya es otro tema.

No me he podido leer todos los artículos, pero me gustaría destacar dos artículos más, el primero para los amantes de las herramientas…escrito por Éva Takács & István Forgács, titulado “Continuous integration to test large distributed systems“(por fin un artículo que habla sobre equipos distribuidos) que habla sobre la herramienta open source “ETICS” (eInfrastructure for Testing, Integration and Configuration of Software).

El otro artículo que quería destacar es el escrito por mi amigo “Toni Robres” sobre como ha cambiado el role del tester con las metodologías ágiles, pasando de ser un role destructivo en las metodologías Waterfall o con el modelo en V a pasar a ser un role contructivo en equipos con metodologías ágiles. Afirmación de la que estoy totalmente en desacuerdo. Un tester que trabaja con el modelo en V puede ser igualmente constructivo que uno que trabaje con SCRUM. Un Tester/SQA puede aportar valor en todas y cada una de las fases del ciclo de vida de desarrollo, desde la fase de elicitación hasta que se hace el roll-out. Puede aportar valor en la demanda, en la toma de requisito, instaurando herramientas de gestión de la configuración, haciendo seguimiento de las pruebas unitarias(cobertura) o haciendo revisiones de código…puede automatizar las regresiones, hacer pruebas de rendimiento o de seguridad, continuous quality improvements, etc, etc, etc…en fin, mil y una actividades totalmente constructivas. Ni las metodologías ágiles son la solución a todos los problemas del desarrollo de software ni el modelo Waterfall o en V son lo peor. Cada uno tiene sus cosas buenas y malas, todo depende de la tipología del proyecto y del sector, pero ambas pueden ser perfectamente constructivas.

Envía ya tu artículo a la revista Testing Experience. Tienes hasta el 20 de enero para envíar tu propuesta. En esta ocasión el próximo número de la revista será sobre “Model Based Testing”.

Como en otras ocasiones tenéis que enviar vuestra propuesta a editorial@testingexperience.com. Algunas fechas que tenéis que considerar, 20 de Enero envio de propuestas, 1 de Febrero fecha límite para enviar artículos y el 1 de Marzo será publicado.

Debemos de tener en consideración:

• Artículo y biografía corta (max. 1700 caracteres) en formato word.
• Gráfico usados en el artículo (e.g. JPEG o vector)
• Fotografía del autor 5.5 x 7 cm (300 dpi)

Referencia:
http://www.testingexperience.com/

¿Quieres escribir un artículo en la próximo número de la revista “Testing Experience” sobre “The Future of Testing”? Si quieres escribir en el próximo número simplemente tienes que enviar una propuesta a editorial@testingexperience.com con un pequeño resumen del artículo.

El artículo debe incluir una biografía de un max. de 1700 caracteres (utilizar template proporcionado por la revista). Usa imágines en alta resolución en formato jpeg o vectorial y envía una foto del autor de 5.5 x 7 cm (300 dpi)

Algunas fechas:

• Deadline Propuesta: 20 de Octubre.
• Deadline Artículo: 1 de Noviembre.
• Publicación: 1 de Diciembre.

Ya está disponible la decimocuarta entrega de la revista Testing Experience titulada “Improving the test Process”, en esta ocasión os encontraréis una revista de 172 página y casi 50 artículos. Aún no he tenido tiempo de leerme todos los artículos, pero he estado ojeando la revista y la verdad que podréis encontrar artículos muy interesantes….desde el TPI Next, pasando por la certificación Expert del ISTQB, como mejoras en automatización, mejoras de procesos o el TMMi.

Lo que está claro es que “Testing Experience” es a día de hoy la revista referencia del mercado…descargaros este número o subscribiros, merece la pena.

Acaba de salir el “Call for papers” para el número 7 de la revista Agile Records, revista especializada en “Agile Development” y “Agile Testing”. Os comento la información por si alguno está interesado en escribir algún artículo. Estás son las fechas límites:

• Propueta: 20 de Mayo
• Versión final: 10 de Junio

Si quieres publicar un artículo, envía tu propuesta a editorial@agilerecord.com.

El artículo debe contener una pequeña biografía una foto.

Más información en Agilerecord.com

Ya está disponible la decimotercera entrega de la revista Testing Experience, titulada: “Testing @ Domains”. ¿Cómo hace testing el sector médico, bancario, el de telecomunicaciones…? Todo lo que siempre has querido saber lo podrás encontrar en este número.

Bájatelo de forma gratuita de la web de www.testingexperience.com” o subscríbete a la edición impresa por tan solo 32€.

Por otro lado, ya podéis enviar vuestros artículos para el siguiente número de la revista…que se titulará “Improving the test process“. Envía tus propuestas antes del 20 de Abril.

Ya podéis comprar la versión impresa de “Testing Planet”. Pero, ¿que es Testing Planet? Es una publicación sobre Software Testing que hace el “Software Testing Club”. El coste son unos 25€ si el envío es a Europa y 30€ si es al resto del mundo.

En caso de no queráis subscribiros, siempre podéis obtener la versión digital gratis en “www.thetestingplanet.com“