Application Performance Testing - A Simplified Universal Approach
Scott's tutorial var en god gennemgang af de ledelsesmæssige, organisatoriske og strategiske betragtnnger der skal gøres i forbindelse med performance test - uden at det bliver et teknisk indlæg.
Der var nogle gode key points som jeg gerne vil dele:
- Performancetest skal være en integreret del af hele projektets life-cycle
- Hele projektteamet skal have fokus på det - ikke kun de tekniske testere
- Forventningerne til performancetesten skal være afstemt, herunder klar rolle- & ansvarsfordeling
- Fokus skal være konstant og samarbejdende.
Paul's tutorial startede lidt akavet i min optik, men blev bedre. Først brugte han en del tid på den nye ISO/IEEE/IEC 29119 standard for softwaretest - som han ikke er den store fan af, lød det til - og derefter brugte han en del tid på sine - åbenbart store - idoler; Brdr. Bach. Nu skal jeg selvfølgelig passe på med ikke at lade mig påvirke af mine personlige holdninger til førnævnte ting, men var jeg primært kommet for at få en ind-i-kroppen-oplevelse af exploratory test.
Han havde en god efterfølgende god (og relevant) start omkring exploratory test - step 1: learn how to test og derefter et nyt step 1: do exploratory testing! - og derefter følgende 'To do ET well, begin by doing it poorly' - dette var en ganske forfriskende start.
Der blev også præsenteret nogle synspunkter på forskellen mellem 'checking' og 'testing', som selvfølgelig er interessante, men nok vil være et fokusområde jeg vil præsentere senere på bloggen.
Exploratory test (ET) er en tilgang til test, og kan anvendes i forbindelse med alle testteknikker og alle udviklingsmodeller - det er altså ikke begrænset til den agile verden. ET er en testtilgang, hvor læring, testdesign, testafviklng og evaluering af testresultater kører som samtidige parallelle aktiviteter.
Der blev talt en del om heuristikker (Ifølge Wikipedia er en heuristik: En heuristik eller heuristisk metode er en metode, som hjælper en til eller tillader en at udforske og lære ting på egen hånd, eller at løse et problem ved at evaluere de erfaringer, man har gjort sig, og derved prøve sig frem, til man har en løsning).
Paul præsenterede en heuristisk teststrategi model omfattende begreber som projektmiljø, kvalitetskarakteristik, produktelement og opnået kvalitet der samtidig dækkede over risiko, orakler, dækningselement og rapportering. Nogle spændende betragtninger.
ET er en struktureret proces - og altså ikke tilfældig, men systematisk - og denne struktur stammer fra flere kilder: føromtalte testdesign-heuristikker, testcharter, timeboks, produktrisiko, produktstrukturen, udviklingsaktiviteterne, projektbegrænsninger, ressourcer allokeret af projektet og så den overordnede tilgang og mål med testen.
Hele ideen med ET er denne samtidighed af læring, design, afvikling og logning af test, og det er under denne proces det kreative og sjove element indgår, herunder forgreningen af testideer - altså det forhold at man starter med en testide, og under arbejdet med at teste denne, får man en ny ide til test, der igen skaber en ny osv.
En vigtig del af ET - ifølge Paul - er testhistorien, som består af 3 dele (eller måske nærmere 4) - (1) historien om status på produktet, (2) historien om hvordan du har testet det, (3) historien om værdien af test, og så (måske) (4) historien om værdien af disse historier.
ET bør køre sessionsbaseret - altså med et givet formål m.m., og deraf skal der selvfølgelig også ske en rapportering af dette - jvf. ovenstående historier.
Alt-i-alt var det en god og interessant eftermiddag, men jeg er dog overbevist om, at dette ikke er den eneste 'historie' om exploratory test.
Jeg er meget enig i at ET er en struktureret proces. Jeg ser også mistolkning af "ET - tænd for skærmen og test" - uden nogen forberedelse.
SvarSletDet er en skam, at nogle personer mere eller mindre bevidst mistolker.
SvarSlet