Om de kontekst-drevne principper

Jeg har vidst siden 2008 at jeg var en kontekst-drevet tester. Det var første gang jeg tog til CAST – den konference der er kendt som hjemstedet for kontekst-drevet test. Det blev en af de begivenheder jeg altid vil se tilbage på med glæde og vished om, at her blev mit liv ændret.

Her mødte jeg en flok testere, der alle tog sit fag meget alvorligt. Der blev diskuteret lystigt og inderligt, og CAST’s brug af K-cards til facilitering (grønne, gule og røde kort med numre, der angiver nyt spørgsmål, opfølgende spørgsmål eller jeg må ubetinget tale nu), der sidste år også blev benyttet med stor succes på EuroSTAR og er fast inventar på LetsTest-konferencerne og en række peer-workshops, gjorde at alle kunne være med. Det var fantastisk at mindst en trediedel af hver session, inklusiv keynotes, var sat af til diskussioner.

Men det var først bagefter, da jeg satte tingene i sammenhæng, at det gik op for mig hvor meget de kontekst-drevne principper betyder for mig.

De syv principper er (her i deres originale, engelske formulering):

1. The value of any practice depends on its context.
2. There are good practices in context, but there are no best practices.
3. People, working together, are the most important part of any project’s context.
4. Projects unfold over time in ways that are often not predictable.
5. The product is a solution. If the problem isn’t solved, the product doesn’t work.
6. Good software testing is a challenging intellectual process.
7. Only through judgment and skill, exercised cooperatively throughout the entire project, are we able to do the right things at the right times to effectively test our products.

Umiddelbart ser de jo meget tilforladelige ud. De to første handler om vores metoder eller vores proces, og slår fast, at metoden/processen ikke nødvendigvis i sig selv er effektiv – for de skal ses i relation til den givne kontekst – den situation de anvendes i. Med andre ord: det man gør i ét projekt, vil ikke have samme værdi i et andet projekt. Man bliver dermed nødt til at se først på projektets kontekst, derefter vælge den bedste proces/metode.

Princip nummer to slår yderligere fast, at der altså ikke findes en universel løsning på alle problemer. Det fortærskede ‘best practice’-begreb må dø (ganske ofte dækker det jo også blot over at være den eneste practice der er forsøgt). Det er selvfølgelig dårligt nyt for ‘proces-politiet’, der typisk gemmer sig i metodeafdelingen, men de må altså finde ny (og efter min mening hårdt tiltrængt) inspiration i at være behjælpelig med at målrette og tilsnitte processer, fremfor at fokusere på ensartethed og konformitet.

Princip nummer tre bevæger sig ind på et kerneområde for kontekst-drevet arbejde: det handler primært om de mennesker, der arbejder på projektet, og deres evner og muligheder for at arbejde sammen. Dét, slår princippet fast, er det væsentligste i hele konteksten, og dermed forstås, i sammenhæng med princip nummer ét, at vi ikke kan have en værdifuld proces, hvis den er en hindring for, at disse mennesker arbejder sammen.

Princip nummer fire er fantastisk, en af mine favoritter, fordi den så enkelt udtrykker, at vi ikke kan forudse hvad der sker. Med andre ord: liniær ekstrapolering er muligvis godt for et hurtigt estimat, men ikke for andet end det. Og vi kan ikke engang beskylde nogen for at være årsag til den bristede illusion: det uforudsete er ganske enkelt uforudsigeligt. Selvom vi alle gør vores bedste, så kan vi stadig ende et sted vi ikke havde regnet med.
Det er derfor vigtigt, at vi fra begyndelsen accepterer dette og forbereder os på, at det bliver nødvendigt at lave ting og beslutninger om. Frygten for at tage fejl kan ikke bruges til noget: vi tager alle fejl fra tid til anden. Lad os istedet leve med det og ikke mindst lære af det.

Princip nummer fem anser jeg for at være “super-oraklet”, der holder os fast på selve formålet med det vi arbejder med: en løsning på et problem, som nogen har. Jeg ved ikke med dig, men jeg har ofte siddet i et projekt og tænkt, at det hele virker som om, at projektet er det vigtigste af alt. Men når projektet er overstået og lukket ned, så er der jo et produkt, som faktisk er årsagen til at projektet blev sat igang. Projektafviklingen må ikke konkurrere med produktet. Og dermed har vi også fået placeret test som en aktivitet vi foretager af hensyn til produktet, ikke pga. at processen foreskriver at test skal finde sted. Næh, det er en naturlig del af, at vi er ved at bygge noget og at vi dermed holder øje med, om det vi bygger er godt, solidt og ikke mindst brugbart i brugssituationen.

Princip seks og syv hænger ligesom ét og to sammen: her kigges på test for første gang – test er slet ikke nævnt før nu (udover implicit i overskriften)! Vi kan læse at test kræver færdigheder, dygtighed, omhu på rette tid og rette sted, og at det er udfordrende for vores intellekt. Dét kan jeg skrive under på. Efter en dag med intensiv test er jeg træt som et alderdomshjem. Det er udmarvende, men også en god følelse. Men der ligger mere i principperne end det: at vi som testere skal besidde de nødvendige færdigheder og evne at bruge dem. Det er slut med at udpege tilfældige mennesker til at teste (fordi ‘det kan alle jo finde ud af’). Det duer bare ikke at skulle forlade sig på at andre skal tænke og forstå for en. Heller ikke selvom det er komplekst og indviklet. Hvad testerne ikke kan, må de tilegne sig.

Tilsammen fortæller disse syv principper en historie om, at det at teste software er individuelt, fra projekt til projekt. At det er udfordrende, svært og til dels uforudsigeligt. Men at tager vi udgangspunkt i situationen før noget andet, og mest af alt i de mennesker der arbejder i projektet (som jo også er forskellige), og bruger vores dygtighed, viden og erfaring godt, så kan vi lykkes med vores forehavende: at vide hvorvidt vi bygger et brugbart og solidt produkt.