Presentación: Hablemos de Deuda Técnica

Hablemos de Deuda Técnica from Jorge Hernán Abad Londoño

Equipos Scrum: El equipo es multifuncional, no los team members polivalentes

Hola a todos

Cuando alguien se aproxima a Scrum (desde el desarrollo de software), se encuentra con que los equipos son multifuncionales (1) y comienza a buscar en la literatura y en las experiencias de otros equipos, como rayos implementar esto.

Comprendemos que multifucional consiste en tener todos integrantes requeridos con las habilidades (skills) requeridas para lograr un incremento en la construcción del producto, es decir, ya no esta tester y desarrollo aparte, sino que trabajan juntos.

                  - ¿como así?,
                     ¿ya no nos podemos acusar mutuamente?

                  - pues si, ya no son ellos y nosotros,
                    ya somos un solo team (wow, tremendo cambio)

Activando un riesgo

En esa búsqueda de referentes en internet, se encuentra que equipos muy maduros no tienen personas con el rol de tester, sino que el equipo toma sobre sí la responsabilidad del producto, y por ende,  se puede caer en una interpretación riesgosa es: "no necesitamos personal de testing, la calidad del producto debe ser garantizada por el equipo de desarrollo", no digo que este enfoque esté del todo mal, pero perdemos de tajo las habilidades de alguien experto en calidad del producto y le delegamos esta responsabilidad al equipo de trabajo que deberá aprender:

• a verificar el producto,
• a aprender de estrategia de pruebas
• a buscar lo que no se ha perdido, 
• es decir, intentar casos de prueba extraños para identificar comportamiento del producto.
• adicional, los desarrolladores tienden a probar los caminos que saben que funciona, lo que deja huecos "funcionales" o "no funcionales".
• Solo un desarrollador con gran disciplina y orientado a pruebas (tdd - test driven development) cubriría muchos de estos escenarios sin garantizarlo - y la verdad de eso he visto poco en estos años -.
• a pensar como usuario
• entre otras fortalezas de un buen tester

Implicando que los team members sean polivalentes(2), esto se puede lograr con el tiempo - no lo dudo -, pero esta transición deberá pagarla alguien con plena seguridad:

• el equipo: pues le reclamarán tempranamente por habilidades que no tiene
• el cliente: recibirá un producto que no tendrá full "Done / Terminado / Completado"
• el scrum master: le dirán que por que no removió este impedimento oportunamente
• el product owner: pues confió en el equipo y este le entrego un producto que tiene alta probabilidad de incidencias
• la empresa proveedora: por el desagrado del cliente y el desgaste del equipo de trabajo.

Qué significa realmente un equipo multifuncional

La multifucionalidad significa que tenemos todos los roles y solo los roles requeridos para lograr el incremento del producto - ya lo había dicho -, por lo tanto, es muy probable que un buen Equipo de Desarrollo para software podría estar constituido por:

• Desarrolladores de software
• Tester
• Tester automatizador (depende del proyecto y producto)
• Base de datos (depende del proyecto y producto)
• Diseñador gráfico  (depende del proyecto y producto)

Pues lo que se quiere en "Agile" es romper los silos y permitir que quienes saben construir la solución interactúen de forma más efectiva y eficaz, sin tropiezos y barreras burocráticas.

No dudo - como me ha sucedido - que los miembros del equipo comiencen a compartir conocimiento y a enseñarle a otros para verse apoyados en momentos que el producto tiene un aumento de esfuerzo en un tipo de especialidad específica, me ha sucedido que:

•  los testers se apoyan en sus compañeros de desarrollo para probar, 
• o que desarrolladores enseñan a testers a programar,
• expertos de bases de datos y desarrolladores
• etc

 y así poco a poco lograr una "polivalencia" pero el equipo reconoce en que hay al interior expertos que lideran un campo de conocimiento y se apoyan en ellos para encontrar la mejor solución.

Hasta acá la reflexión del día de hoy, espero les haya servido, pues encontrar quienes hacen todo bien es más difícil que encontrar quienes hagan bien unas cuantas cosas.

Saludos ágiles

Jorge Abad.

Notas y Aclaraciones:

• (1) Guía oficial de Scrum (clic aquí)
• (2) Polivalente: que vale para muchas cosas (clic aquí: http://dle.rae.es/?w=polivalente), en la industria de la manufactura, significa que puede realizar correctamente muchas labores

Acomodando o Forzando Scrum para Equipos de Testing

Hola a todos (hace tiempo no escribía, discúlpen lo perdido que he estado)

Hoy hablare un poco de como he visto que se hacen proyectos de testing bajo el marco de Scrum o al menos ser ayudados por el marco. Comencemos.

------

PROLOGO

La tradicional forma de ver el software en cascada entre empresas,  en donde:

La empresa “X” construye el software (entregándolo probado),

y la empresa “Y” lo prueba y certifica

Va seguir viva en nuestro entorno por un tiempo más y la causa raíz de esto es sin duda la desconfianza, pues ya sea por procedimiento, requerimientos corporativos de seguridad ponemos a un tercero a que pruebe, generando la calidad de la calidad.*

NUDO

Recordemos, “en Ágil la idea es hacer la menor cantidad de software con calidad que genere el mayor valor de negocio**”, pero muchas veces, debido a estos  esquemas de desconfianza “CASCADIZAMOS ÁGIL” y se cae en que:

• un equipo hace desarrollo ágil cumpliendo su DEFINITION OF DONE
•  y otro prueba el DONE del anterior, cayendo en la calidad de la calidad, el proceso y reproceso, y por ende el desperdicio

Bajo esta premisa el equipo adicional de testing – de la empresa “Y” –

dice: “yo voy a probar usando Scrum”

¡ ¡ ¡OMG!!!

Seamos claros, ese equipo usará del framework de Scrum para realizar la gestión del proyecto realizando:

• Planeación
• Ejecución
• Revisión
• y Retrospectiva

Pero bajo este esquema “LOS EQUIPOS DE TESTING QUE EMPLEAN EL PROCESO DE SCRUM PARA PROBAR, REALMENTE NO HACEN SCRUM” pues Scrum sirve para construir productos, y bajo este esquema solo lo estamos probando.

Pero a pesar de lo anterior, procedamos a homologar lenguaje que equivaldría en este esquema:

• El Product Backlog es todo lo que hay que probar
• Casos de uso
• Historias de usuario
• Requisitos no funcionales
• El sprint backlog
• Es lo que se selecciona a probar durante el ciclo
• El team es un equipo de testing
•  Product Owner y Scrum Master conservan sus definiciones.

Entonces cual es la DEFINITION OF DONE de un equipo de testing bajo estas características

• Todos los casos de prueba de la HU o del CU diseñados
• Las evidencias asociadas a casos fallidos o exitosos registradas en el repositorio
• Reporte de incidencias encontradas actualizado.

Y la DEFINITION OF READY:

• Casos de uso o historias de usuario desarrollados y congelados en un ambiente para testing
• Documentación asociada congelada.

No dudo que este esquema sea efectivo, lo he visto:

• Potencializa más el trabajo en equipo, pero no se nota la fortaleza e interacción de un equipo multidisciplinario que construye software.
• Se mejora la predictibilidad de diseño y ejecución de casos de pruebas

Conclusión

En la medida que hagamos mejor ágil, un mejor DONE (procesos y practicas técnicas que aseguren los productos) estos esquemas comenzarán a desaparecer, al igual que los testers evolucionarán a testers que no solo hacen pruebas funcionales, sino que automatizan, realizan pruebas no funcionales y hacen parte crucial del equipo de desarrollo.

Notas

*si vamos a ser sensatos esto tiene todo el sentido en proyectos donde a la empresa “X” construía el software haciendo cascada, generando grandes cantidades de software, que  talvez entregado a la fuerza y en consecuencia, obligando al cliente a contratar a un tercero que le certifique que lo que le entregaron muchos meses después si sirve.

**y saliendo a producción lo antes posible, para generar el mayor RETORNO DE INVERSION (ROI)

Testing Agile Manifesto

Creo que necesitábamos algo así.

No son dos equipos (desarrollo y pruebas), son un equipo enfocado en generar las mejores soluciones posibles para el cliente

Saludos ágiles

Jorge Abad

Leído y Recomendado: Caso de estudio: Cómo hace Google sus planes de pruebas (y los hace en menos de 10 minutos)

Este es el link: http://www.javiergarzas.com/2012/12/google-pruebas.html


Saludos ágiles

Jorge Abad

Leído y Recomendado: “Vamos a automatizar pruebas”. ¿Qué significa esto? ¿Realmente por dónde deberíamos empezar a automatizar?

Tomado de: http://www.javiergarzas.com/2015/01/automatizacion-pruebas.html

Excelente post de la página de Javier Garzas

Lo copio, pues lo considero de colección

--------

Hoy en día muchas empresas software, por su negocio quieren ser ágiles. Quieren sacar productos más rápido al mercado y adelantarse a la competencia, mejorando para ello la calidad de su proceso, producto y equipos software.

Una de las claves para agilizar ese proceso, detectar errores antes, en puntos del desarrollo en los que nos cueste menos solucionarlos y así desarrollar con más seguridad, es la optimización y automatización de ciertos procesos y pruebas (muy relacionado con Integración Continua).

Sé que no es un cambio sencillo y que automatizar pruebas tiene un coste (lo vivo en el día a día, ya que Integración Continua, testing ágil, automatización de pruebas, son campos en los que trabajo en dentro 233 Grados de TI.).

No obstante, creo que con recursos limitados, sin automatizar ciertas pruebas es complicado llegar al testing ágil.

Dentro de este día a día, me da cada vez más la impresión, de que al igual que ocurre con la calidad de software en general, en ciertas ocasiones no se tiene muy claro qué implica la automatización de pruebas. Ni qué implica el testing ágil.

De ahí que escuche cosas como:

– “Para el mes que viene estará todo automatizado, ¿no?”

– ¡Ah, genial! Si automatizamos las pruebas…¡Nos ahorraremos a los testers manuales!

– ¡Sí, automaticemos pruebas! Tú enséñanos a automatizar pruebas con eso de Selenium, que le das al botoncito, tocas cuatro cosas y vas grabando lo que haces.

Pero la automatización de pruebas implica más que eso. Ahora verás por qué.

¿Automatizaremos todo? ¡Así nos ahorraremos el testing manual! ¿No?

Como comenté en ¿Cómo enfoco el testing de forma ágil?, el objetivo de la automatización de pruebas no es eliminar por completo el testing manual, ni suplantar a los testers manuales.

Lo que automatizamos son chequeos, comprobaciones que los testers manuales previamente han detectado antes: ciertas pruebas de regresión, smoke test etc.

En este enfoque de testing, durante la evolución de un sistema, un caso de prueba comienza siendo manual, para luego ser automatizado.

Así los testers manuales pueden dedicarse a buscar otros bugs más complejos o testear nuevas funcionalidades.

Incluso puede haber ocasiones en las que automatizar alguna prueba o generar las condiciones necesarias para ello sea tan costoso, que sea más rentable mantenerla manual.

¿Y por dónde empezamos a automatizar?

Por otra parte, la calidad del software tiene muchos ámbitos (Calidad del software es mucho más que el testing).

Y dentro de lo que es el testing, existen distintos tipos de pruebas, cada una orientada a detectar y prevenir ciertos tipos de errores en el software.

Probablemente lo que primero suele venirnos a la cabeza cuando oímos hablar de automatización de pruebas son automaciones de “record & play”, por ejemplo con herramientas tipo Selenium IDE, que te permiten simular y grabar tus interacciones con la interfaz de la plataforma, con el navegador web etc.

Depende de qué plataforma, a primera vista pueden resultar las más sencillas de automatizar.

Es cierto que son automatizaciones necesarias, pero no son las que más retorno de inversión aportan, ni las que deberían automatizarse en mayor cantidad.

Principalmente, porque la interfaz de usuario es la parte más propensa a cambios de toda la aplicación, y para automatizar pruebas y tener fiabilidad sobre lo que estamos ejecutando necesitamos cierta estabilidad: un cambio en la interfaz podría hacer fallar la prueba automática, y en ese caso, tendríamos que readaptarla para que volviera a funcionar.

Por eso este tipo de pruebas suelen tener un coste de mantenimiento mayor que el resto.

Sí que tenemos que automatizar las pruebas de interfaz, pero mi consejo es que lo hagas después de haber automatizado otras partes más estables de la aplicación, el núcleo en sí, que aporta más retorno de inversión.

Por ejemplo, un buen primer paso es automatizar los test de API (funciones, elementos que ofrecemos desde nuestro software para que otro software, u otras partes del nuestro, puedan interactuar con él).

Hay varios niveles a la hora de automatizar pruebas. El secreto está en automatizar en el grado adecuado y en los niveles adecuados para nuestra aplicación.

Pirámide de Cohn.

La pirámide de pruebas de Mike Cohn, descrita en su libro Succeeding with Agile, ha sido un referente en este campo durante mucho tiempo.

En ella Cohn establece que hay varios niveles de pruebas, y señala el grado en el que deberíamos automatizarlas. Lo ideal sería:

– Muchos tests unitarios automáticos, porque un primer punto primordial para detectar fallos es a nivel de desarrollador. Si una funcionalidad en este punto falla, podrían fallar pruebas de los siguientes niveles: integración, API etc.

– Bastantes tests a nivel de API, integración de componentes, servicios, que son los más estables y candidatos a automatizar.

– Menos tests de interfaz gráfica automatizados. Ya que estos tests son variables, lentos en su ejecución y con muchas dependencias con otros componentes.

Aún así, en este punto, no suelo utilizar esas herramientas de record & play para automatizar pruebas de interfaz de usuario, ya que el código autogenerado por algunas de ellas no es muy mantenible (existen alternativas como Selenium WebDriver, que hace lo mismo pero programando tu el código).

– Un nivel estable de pruebas automáticas, que vayan detectando los testers manuales y se vayan automatizando paulatinamente, para que llegue un momento en el que invirtiendo los mismos recursos logremos cada vez una cobertura mayor de pruebas.

Mala estrategia de automatización: el patrón del “cono de helado”

En la automatización de pruebas hay que tener cuidado, ya que en ciertas ocasiones se tiende a perder el foco y a invertir en automatización en el nivel y grado no adecuado.

Una mala estrategia en estos casos, es lo que llamamos el patrón “del cono de helado”.

Como ves es lo contrario a la pirámide de Cohn: centramos el foco en muchas pruebas manuales y en automatizar pruebas de interfaz de usuario, y nada de pruebas unitarias. Con todos los problemas que acarrea no detectar errores en los otros niveles y dejarlo todo para la parte más visible de la aplicación.

Además ten en cuenta, que una buena estrategia de automatización de pruebas conlleva más cosas que solo automatizar las pruebas en sí: crear un buen framework de automatización, parametrizar los tests, las ejecuciones para los distintos entornos, lanzar los test con distintos datos de prueba y gestionar dichos datos, sistemas de logs, buenos reportes con información que sirvan para obtener conclusiones, montar una buena infraestructura contra la que lanzar esos tests, paralelizarlos etc.

Leído y Recomendado: Transitioning from a Traditional Tester to an Agile Tester

http://www.techwell.com/2015/01/transitioning-traditional-tester-agile-tester


lo copiaré por acá por miedo a que se pierda..

excelente post ( de colección)


_________

Transitioning from a Traditional Tester to an Agile Tester

January 7, 2015 by Michael Sowers

One of the most challenging changes any organization can make is moving from a traditional lifecycle development approach to an agile one. As such, there are many books, articles, blogs, and consulting firms that aim to assist with this transition.

One question I'm often asked is "What's the difference between a tester's role in a traditional lifecycle model versus in an agile methodology?” The answer is not an easy one. There are many factors to consider, and any individual tester's or test team's experience will vary based on the organizational environment, culture, and the technology being tested.

There is a spectrum of differences, ranging from redefining the testing role and responsibilities completely to making only minor changes in context and accountability. Some individual testers and test teams will find this transition easy because it's very close to the way they are already working; other individuals and teams will find the transition much more difficult, to the extent that they may need to reinvent themselves.

At the risk of oversimplifying, here are a few key differences in the context, responsibilities, behaviors, and expectations of an agile tester versus a traditional tester.

As an Agile Tester	As a Traditional Tester
Testing is conducted immediately and continually as soon as possible, with the smallest feature(s) available. Test-driven development is employed.	Testers usually wait on a specific build or release and then begin testing once most features are implemented.
Testing is planned as part of the sprint and the release. Developers automate unit tests. Functional and nonfunctional testing is conducted iteratively within the team and in collaboration with the product owner.	One phase of testing usually builds on the next—unit, then integration, then system, then acceptance.
Bug identification and repair is in hours rather than days or weeks.	There is significant wait time between bugs being identified and bugs getting fixed.
Developers and testers operate as one team and interact continuously and collaboratively. The testing voice is equally represented.	Testers are less a part of the development team. Testers may be more distant in interaction and communication with developers and may have less of a voice.
Testers and developers are part of a homogeneous team accountable for quality delivery of the system under test.	Testers are accountable for testing. Developers are accountable for developing.
Testing is continuous and all quality steps are planned and executed iteratively by the agile team.	While the goal is always to have quality built in at every step in the lifecycle, in practice, much of the checking (quality steps) occurs during the backend testing cycle.
Automation is a must have, particularly for unit tests, as it supports continuous integration.	Automation is not a necessity because most testing of new development is done manually.

What are other key differences between the traditional testing role and the role of a tester in an agile environment?