En enfoque del aprendizaje basado en retos

Mi vecina Marga es profesora en una escuela local. Hace un par de días nos vimos en el jardín y estuvimos hablando de la vuelta después de las vacaciones de verano. Ella me dijo que se estaba introduciendo al concepto de aprendizaje basado en retos/desafíos. No pude aguantar mi curiosidad y tuve que buscar este concepto en Internet para averiguar algo más de su significado.

Como describe la página www.digitalpromise.org, el aprendizaje basado en retos/desafíos ofrece un esquema eficiente y efectivo para aprender mientras resuelves retos de la vida real. Este esquema es colaborativo y práctico, pidiendo a todos los participantes (estudiantes, profesores, familias y miembros de la comunidad) que identifiquen grandes ideas, hagan buenas preguntas, identifiquen y resuelvan retos, obtengan un profundo conocimiento en la materia, desarrollen habilidades del siglo XXI y compartan su experiencia con el mundo.

El esquema está dividido en tres fases o etapas:

• Engage: Identificar la idea principal y comenzar a generar una gran variedad de cuestiones esenciales que reflejen los intereses y necesidades de la comunidad. Finalmente, terminar con la definición de un desafío, sobre la base de una de las cuestiones esenciales.
• Investigar: En base al desafío, el alumno lleva a cabo investigaciones con base en el contexto y el contenido para crear una base para una solución. Este comienzo con la identificación de una serie de preguntas guía relacionados con el desafío – cosas que tenemos que aprender con el fin de encontrar la solución adecuada para el reto. Utilizar las preguntas para identificar las actividades y los recursos necesarios para responder a estas. Esto puede ser necesario para la investigación, simulaciones, juegos, cuestionarios, etc. Como parte de la investigación , también alineamos preguntas y actividades a cualquier estándar – en términos escolares, esto podría estar conectado con áreas como ciencias, matemáticas, artes, etc. . Al final, cuando todas las preguntas han sido contestadas y se han llevado a cabo todas las actividades, se analizan los datos y se identifican temas, desarrollando una conclusión clara como base para la solución.
• Actuar: Aquí la solución basada en la evidencia se desarrolla e implementa y se evalúa el resultado de la aplicación. Esta fase se divide en dos partes bien diferenciadas. Por un lado, el desarrollo de la solución donde se usa la base de la fase de investigación para desarrollar una solución en un ciclo iterativo utilizando prototipos, experimentos y pruebas. Después del desarrollo, ponemos en práctica y evaluamos el resultado – reflexionando sobre lo que funcionó y lo que no lo hicimos. Cuando la implementación se ha completado, podemos ya sea reiteramos la solución, o crear un informe de finalización compartiendo el trabajo con el resto del mundo.

Leyendo sobre este modelo tenía dos pensamientos: » Esto suena como una especie de modelo de desarrollo iterativo sacado del contexto de TI “, y «¿tal vez podríamos conseguir la inspiración de este para planificar y ejecutar las pruebas en un entorno ágil? » Si nos sumergimos en este último pensamiento – tal vez, podríamos imaginar una situación en la que el equipo utiliza el concepto de aprendizaje basado retos como una manera de identificar y probar el plan para el equipo. Vamos a echar un vistazo a los pasos descritos por el esquema y tratar de poner en palabras lo que esto significaría en un contexto de pruebas.

Engage:

Grandes ideas: Cuando empiezas un proyecto, necesitas comenzar definiendo el propósito del sistema que el equipo va a construir. Qué valor le debería dar al cliente, creo que es algo crucial que tenemos que saber con independencia de si eres un tester o un test manager – tú necesitas entender por qué estamos construyendo este sistema.

Cuestiones esenciales. Para mí, esto puede ser dos actividades diferentes en dos niveles distintos. Podría ser el equivalente al análisis de riesgo del producto – en cualquiera de las formas que elijas para hacerlo. Hacer brainstorming en el equipo para llegar a un entendimiento común. Pero también podría ser utilizado en un nivel de historia  -hacer un brainstorming para la historia para conseguir una mejor comprensión y criterios de aceptación claros.

Retos. Aquí es donde se define el proyecto de testing, aunando información de la PRA, preguntas, etc y definir el alcance de la prueba, los trabajos de test. El cómo es el documento depende de su contexto.

Investigar:

En este punto, pude verlo en dos niveles –  la planificación de la prueba y también la preparación de una sesión de prueba exploratoria. Voy a tratar de describir ambas.

Cuestiones guía. Desde una perspectiva de planificación, las preguntas de guía podrían ser utilizadas como una herramienta para el test manager; formulando una serie de preguntas para aclarar el alcance, riesgo y enfoque de la prueba para el proyecto. Todas las preguntas necesarias para aprender sobre el proyecto y hacer las pruebas más eficientes. Por otro lado, desde una perspectiva del tester, me gustaría utilizar las preguntas de guía como una forma de identificar todo lo que necesito saber y entender con el fin de probar una característica de la mejor manera posible.

Actividades guía y recursos. Si volvemos a ver esto desde dos perspectivas diferentes, entonces esta actividad sería utilizada por el test manager y el equipo para investigar opciones para la estrategia de prueba; marco de automatización, virtualización del entorno de pruebas, etc. Y no necesariamente quiero decir documentado IAW IEEE829 o TMap, pero sí una visualización de lo qué es la estrategia y el plan para probar este sistema. Crear un entendimiento común del desafío de testing. Desde la perspectiva de los testers, este sería el caso donde empezar a identificar posibles temas o áreas de interés – ¿hacia dónde tenemos que centrarnos?, ¿cómo debemos hacer frente al testing para esta función ?

Alineación estándar. ¿Qué necesitamos para cumplir con todas las normas? ¿regulaciones de la FDA?, etc.  Si es así, necesitamos asegurar que verificamos el cumplimiento de conformidad con los requisitos. Esto es más en el sentido de la comprobación que de la prueba como tal, pero es una actividad necesaria también.

Análisis. Sobre la base de las actividades y preguntas, ahora podemos especificar la estrategia de pruebas, y como se ha mencionado antes esto podría ser en cualquier forma que se ajuste a su contexto; dibujo, wiki , etc. El tester ya está listo para identificar las sesiones que él sabe que tiene que hacer con el fin de cumplir con el reto de pruebas – la estrategia para el proyecto. Sobre la base de los conocimientos y retos recogidos puede descomponer el desafío en sesiones separadas. Para grandes sistemas puede haber una necesidad de hacer esto con todo el equipo, facilitado por el test manager.

Actuar:

El desarrollo de la solución es cuando los testers están llevando a cabo las sesiones, aquí es donde se crean prototipos, se llevan a cabo experimentos y se está ejecutando un ciclo de diseño iterativo. Ese ciclo sería entonces el ciclo de aprendizaje simultáneo, diseño y ejecución de pruebas como se define por James Bach. Desde una perspectiva de gestión de pruebas, aquí es donde hacemos el seguimiento, mitigamos los riesgos, apoyamos al equipo.  Es posible que haya actividades para, por ejemplo, introducir nuevas herramientas basadas en la experimentación, etc.

La implementación y la evaluación. Aquí es donde se reflexiona sobre la sesión que se acaba de completar; se evalúa el resultado y las necesidades. Esto es también donde el test manager prepara cualquier informe que tiene que hacer para el proyecto en su conjunto.

¿Qué es lo que he aprendido?

¿Qué es lo que me gusta de lo anterior? En realidad la mayoría de todas las preguntas; el cuestionar deliberadamente y de manera estructurada para aprender y obtener información como base para la planificación de test y especificación y ejecución de pruebas. A menudo veo test managers «sentados en una torre de marfil» al configurar su estrategia de test, solamente involucrando a otros en una escala muy limitada. Y, a menudo, tenemos que basar nuestra estrategia de prueba en una cantidad limitada de documentación, pero falta un buen enfoque para recoger la información necesaria – tal vez ¿esto podría ser una manera ? Con más y más proyectos que son ágiles, ¿tal vez este concepto de aprendizaje basado en desafíos podría ser utilizado como una forma de colaboración para crear una estrategia de test que es propiedad de un equipo?

A modo conclusión … Es cierto que no revolucionaré el mundo de testing … pero creo que es una pequeña evolución en el sentido de un enfoque flexible para la planificacion y la ejecución de pruebas. Y sólo el hecho de parar , mirar a los otros modelos es un paso para  el aprendizaje continuo y la mejora de mi propio mundo del testing.

(Fuente www.digitalpromise.org)

Este artículo ha sido publicado previamente en SogetiLabs.

Gitte Ottosen has 19 years of experience in test engineering and test management, is a certified ScrumMaster, TMap Test engineer, CAT trainer and holds an ISEB Practitioner Certificate in software testing.