BLOG
INNOVATION

Blog: Challenge Based Learning

Kan vi lære af Challenge Based Learning?

[18. oktober 2016] I dag skal du være lidt tålmodig med mig, det bliver et af de lange indlæg :) men jeg håber det kan give dig lidt inspiration.

Min nabo Margit er lærer i en lokal skole. For et stykke tid siden mødtes vi over hækken og talte om at komme i gang efter sommerferien. Hun fortalte mig, at hun var ved at blive introduceret til begrebet ”Challenge Based Learning”. Nysgerrig som jeg er, var jeg nødt til at søge efter det på nettet bagefter for at finde ud af mere.

Challenge Based Learning

Som beskrevet på http://cbl.digitalpromise.org/about/ giver "Challenge Based Learning (CBL) en effektiv ramme for læring, mens man løser udfordringer fra den virkelige verden. Rammerne er samarbejdsorienterede og hands-on. Dette får alle deltagere (elever, lærere, familier, og community medlemmer) til at identificere store ideer, stille gode spørgsmål, identificere og løse udfordringer, få dyb viden om domænet, udvikle færdigheder der giver værdi i det 21. århundrede, og dele deres erfaringer med verden. "

Rammerne er opdelt i tre faser:

  • Engage; identificer den store idé og begynd at generere en lang liste af relevante spørgsmål, der afspejler interesser og behov i samfundet. På baggrund af spørgsmålene defineres ​​en udfordring, som danner grundlaget for det efterfølgende forløb.
  • Investigate: baseret på den udfordring man har defineret, gennemføres indholds- og kontekstbaseret research for at skabe et fundament for en løsning. Researchen begynder med at vi identificerer en række vejledende spørgsmål i forbindelse med udfordringen, ting vi skal lære for at finde den rigtige løsning til den definerede udfordring. Spørgsmålene bruges til at identificere aktiviteter og ressourcer, der er nødvendige for at besvare dem. Dette kan eksempelvis være anden nødvendig research, simulationer, spil, spørgeskemaer etc. Som en del af ”investigate” justerer vi spørgsmål og aktiviteter i forhold til eventuelle givne standarder – f.eks. standarder indenfor sundhed, medicin, IT sikkerhed etc. Til sidst, når alle spørgsmål er blevet besvaret, og alle aktiviteter er blevet udført, analyserer vi data og identificerer temaer – og udvikler en klar konklusion som et fundament for løsningen.
  • Act: her udvikles og implementeres løsningen, og resultatet af implementeringen evalueres. "Act" er delt i to forskellige dele; udvikling af løsningen, hvor grundlaget fra undersøgelsesfasen bruges til at udvikle en løsning i en iterativ cyklus ved hjælp af prototyper, forsøg og undersøgelser. Efter udvikling implementeres løsningen og vi evaluerer resultatet - reflekterer over hvad der virkede og hvad der ikke gjorde. Når implementeringen er gennemført, kan vi iterere på løsningen eller oprette en afsluttende rapport hvor vi deler arbejdet med resten af ​​verden.

Kan det bruges til test?

Som kontekstdrevet tester lader jeg mig gerne inspirere af alt muligt andet end det der lige præcist handler om test - der er meget læring at hente mange steder fra, uanset om det er IT, social videnskab, matematik eller noget helt fjerde.
Hvis vi dykker ned i det sidste tanke - kunne vi måske forestille os en situation, hvor teamet bruger Challenge based learning som en metode til at identificere og planlægge test for teamet, samt udføre de exploratory charters og indsamle den viden der opsamles til at kunne kommunikere omkring systemets kvalitet under test?

Lad os tage et kig på de trin, der er beskrevet og forsøge at sætte ord på, hvad det ville betyde i en test sammenhæng.

Engage:

Big ideas. Når du starter et projekt har du behov for at definere formålet med systemet som skal bygges. Hvilken værdi skal det give til kunden? Dette er efter min mening helt fundamental viden uanset om du er tester, testmanager eller en del af et agilt team, du har brug for at forstå hvorfor vi skal bygge systemet.

Essential Questioning.  For mig kunne dette være to forskellige aktiviteter på to forskellige ”niveauer”. Det kunne være gennemførelse af en produktrisikoanalyse – i hvad form du end vælger at lave den. Brainstorm i teamet for at få en fælles forståelse. Men det kunne også være på Epic eller Story niveau at du bruger dette – brainstorm over spørgssmål til epic/story for at få en bedre forståelse og veldefinerede acceptkriterier.

Challenges. Det er her du definerer dit ”testprojekt” – samler information fra PRA, spørgsmål og så videre og definerer scope for og tilgang til testen, din testopgave. Hvordan du dokumenterer det er op til din kontekst, om det er visualiseret i en tegning, skrevet i en WIKI eller i et IEEE829 formateret dokument.

Investigate:

Når det kommer til ”Investigate”-delen af modellen ser jeg umiddelbart, at der er to forskellige fokusområder - planlægning af test og forberedelse af en exploratory test session. Jeg vil forsøge at beskrive begge i det følgende.

Guiding questions. Fra et planlægningsperspektiv kan de vejledende spørgsmål bruges som et værktøj til testmanager; jeg stiller en række spørgsmål for at afklare omfang, risiko og testtilgang til projektet. Alle spørgsmål er nødvendige for at lære om projektet og identificere den mest effektive test. På den anden side, fra en testers perspektiv kan jeg bruge de vejledende spørgsmål som en metode til at identificere alt det, jeg har brug for at vide og forstå for at teste en funktion eller et område bedst muligt.

Guiding activities and resources
. Hvis vi igen ser dette fra to forskellige perspektiver, så vil denne aktivitet blive anvendt af såvel testmanager som team for at undersøge mulighederne for teststrategien; rammerne for automatisering, virtualisering af testmiljøet etc. Og ikke nødvendigvis dokumenteret i henhold til IEEE829 eller TMAP®, men en visualisering af hvad strategi og plan for at teste systemet er. Skab en fælles forståelse af de testudfordringer teamet står overfor. Fra testerens perspektiv vil dette være tidspunktet hvor jeg starter med identificere potentielle temaer eller områder af interesse - hvor bør vi fokusere, hvordan skal vi adressere test for denne funktion?

Curriculum and standard alignment. Er der krav til opfyldelse af specifikke standarder? FDA regulativer? Militære standarder etc? Hvis der er, så vi er nødt til at sikre, at vi kontrollerer for overholdelse i overensstemmelse med kravene. Dette er mere at kontrollere end teste som sådan, men det er en nødvendig aktivitet.

Analysis. Baseret på de gennemførte aktiviteter og spørgsmål kan vi nu specificere teststrategien, og som tidligere nævnt bør dette være på en måde, der passer til din kontekst; tegning, wiki, dokument osv. Testeren er nu klar til at identificere de charters og sessioner, han ved han skal gennemføre for at opfylde testudfordringen - strategien for projektet. På baggrund af den indsamlede viden og identificerede udfordringer kan han bryde udfordringen ned i separate sessioner. For store systemer kan der være et behov for at gøre dette i teamet sammen, måske faciliteret af testmanageren.

Act:

Når det kommer til ”Act” så ser jeg en god mapning til sessionsbaseret, exploratory test.

The solution development. Det er her prototyper bliver skabt, eksperimenter udføres og en iterativ design cyklus køres. Når testere gennemfører exploratory sessions, vil det så være den cyklus af samtidig læring, test design og test udførelse som defineret af James Bach. Det er her, den viden, vi opnåede ved at stille spørgsmål og udfordre, giver værdi - i den forstand, at vi finder fejl, lærer om systemet og stiller spørgsmål om løsningen.
Fra et testmanagement perspektiv, er det her vi følger op, mindsker risici, støtter holdet. Der kan være aktiviteter for at forbedre miljøet, indføre nye værktøjer baseret på eksperimenter mv.

Implementation and evaluation. Dette svarer så til debriefing af sessionerne. Det er her, vi reflekterer over netop afsluttede sesioner; evaluerer resultatet (PROOF huskeregel – Past, Results, Obstacles, Outlook, Feelings - Se http://www.satisfice.com/sbtm/index.shtml for detaljer) og vurderer eventuelle behov for at supplere med nye charters osv Det er også her testmanageren forbereder den rapportering, han skal lave for projektet som helhed - så igen to forskellige perspektiver. Når det kommer til den reflekterende del, kan testmanageren genbesøge tidligere stillede spørgsmål fra ”Engage” og ”Investigate” for at verificere om svarene er blevet fundet og opgaven løst.

Hvad jeg lærte?

Hvad fik jeg så ud af ovenstående gymnastik? Faktisk først og fremmest fokus på spørgsmål. Bevidst brug af spørgsmål og på en struktureret måde for at lære og skaffe information som et grundlag for testplanlægning og testspecifikation/afvikling. Jeg ser jævnligt testmanagere sidde i deres elfenbenstårn når de laver deres teststrategi, de involverer kun andre i et meget begrænset omfang. Og ofte må vi basere vores teststrategi på en begrænset mængde af dokumentation, men mangler en god tilgang til at indsamle den information vi mangler – måske kunne dette være en metode? Med flere og flere projekter der går den agile vej, så kunne Challenge Based Learning konceptet måske bruges som en samarbejdsmetode for at skabe en teststrategi ejet af teamet?

Challenge based learning metoden opererer med en tre-spørgsmåls tilgang; kunne det måske give værdi for testmanageren i hans planlægning og kontrol af test i projektet? Måske kunne det bruges som følger:

  1. Første niveau af spørgsmål for at forstå hvad det er for en opgave, vi står overfor (engage – essential questioning)
  2. Andet niveau af spørgsmål for at forstå hvilken tilgang, der er nødvendig for at supportere opgavens løsning (investigate – guiding questions)
  3. Tredje niveau af spørgsmål for at evaluere: fik vi rent faktisk opfyldt vores formål (Act – evaluation).

Kunne der måske endda være grupper af spørgsmål vi kunne genbruge som et fundament for inspiration – i hvert fald for de to første niveauer af spørgsmål? Man kunne måske se dem som heuristikker for testplanlægning, eller måske endda question patterns, eller q-patterns som de oprindeligt blev beskrevet af Vipul Kocher (f.eks på EUROSTAR i 2008: http://www.slideshare.net/EuroSTARConference/vipul-kocher-software-testing-a-framework-based-approach).

Et sæt af relaterede spørgsmål grupperet sammen for:

-        Relatere til specifikke aspekter af bruger eller software krav

-        Identificere forskellige alternativer for at kunne nå frem til en løsning.

Der er spørgsmål som vi gentager hver gang vi starter et nyt projekt, hvorfor ikke samle disse og få et forspring når vi starter på et nyt projekt og skal undersøge udfordringen vi står overfor? Selvfølgelig vil konteksten diktere en række ting, der er forskellige fra gang til gang, men andre spørgsmål vil altid være relevante.

Konklusion

Det er jo meget fint, men hvad ændrede det at jeg forsøgte at lave denne mapning mellem challenge based learning og agil test? Jeg revolutionerede ikke testverdenen, det er helt sikkert... men jeg tænker der måske kunne være en lille evolution i den forstand, at det kunne være et oplæg til en struktureret men fleksibel og kontekstdreven tilgang til testplanlægning og afvikling. Og bare processen at stoppe op, se på andre modeller, se hvordan min verden passer ind i den model giver værdi – kontinuerlig læring og forbedring af min egen testverden.

Gitte Ottosen
Gitte Ottosen
Management Consultant & Agile Evangelist
+45 39778711
todo todo