Jag gillar testidéer, och då tänker jag på idéer om något att testa, sätt att utmana programmet för att undersöka vad som händer.
När jag är med och testar något så vill jag att det ska finnas så många testidéer att man måste välja ut de man tror är bäst.
Och de allra bästa testidéerna har man troligen i slutet av projektet när man vet mest, så man måste vara beredd att ändra testerna under resans gång.
Så hur ska man få till detta? Det är ju sällan man är en ensam testare med ett felfritt minne; och man har ju inte tid att skriva testfall för allting, speciellt inte om en del kommer slängas och ändras.
Ett gyllene verktyg är att dokumentera sina testidéer med en kortfattad mening. Då kan man dela med sig bland testarna, man kan ge och få tips av utvecklarna, och det finns till och med en rimlig chans att övriga intressenter läser och förstår mer om testningen.
Man kan anpassa granulariteten för att öka läsbarheten; för ett projekt kanske man skriver “försök med allehanda giltiga och ogiltiga inloggningar”, medan det en annan gång blir tjugo testidéer kring samma områden (normala bokstäver, Unicode, strängar som betyder annat, raderade konton, ändrade lösenord, felmeddelanden, säkerhet, gränssnitt o.s.v.) Testningen som utförs kanske blir samma ändå, eller bestäms mer av tillgänglig tid eller vad testaren tror är viktigast. Det beror också på om man skriver mer detaljerade testfall av de bästa testidéerna, eller om de används i scenarier eller som inspiration till ad hoc-testning, eller på ett annat, ännu bättre sätt.
En testidé kan vara essensen av ett eller flera testfall (försök installera programmet på en nätverksenhet), en ingång mot ett område (undersök beteendet vid många uppgraderingar och avinstallationer), en aktivitet (fråga utvecklarna vilka enhetstester de inte hann skriva), eller något helt annat (undvik musen under en arbetsdag); det viktiga är att testidéerna hjälper dig att ta fam den viktigaste informationen om produkten.
Jag hinner inte gå in på detaljer om hur man genererar alla testidéer, men jag tror att man använder sig av det svåröversatta “test idea triggers”, vilket innebär att man kastar loss sin erfarenhet, kunskap och kreativitet utifrån saker som specar, buggar, tester, prototyper, testtekniker, kunder, konkurrenter, kvalitetsattribut, modeller, heuristics, analogier, verktyg, samtal m.m.
Jag tror inte generella testidéer är speciellt lysande, däremot tror jag att man på ett företag kan ha återkommande “test idea triggers”, exempelvis är det på vårt företag alltid gångbart att tänka “delete”.
Jag skulle väldigt gärna höra från fler som använder liknande metoder; jag är säker på att det finns, RUP har ”test idea list” och ISTQB har ”test condition”, och nog går ni väl utanför de explicita kraven?
Som ett verktyg jag använder mig för att fundera på testideer och koppla samman dem etc är att använda ett s.k. mindmap verktyg. På det sättet är det enkelt att dela med sig av sina tankar och iaf enligt mig får jag en bättre bild av vad jag menade med en tanke en tid senare.
Programmet som jag använder heter freemind och är ett open-source verktyg.
Kanske ett litet tips för den som vill prova på något nytt satt att dokumentera och brainstorma runt ideer.
…och nog går ni väl utanför de explicita kraven?
Det känns som att det är viktigare att det blir en bra (helst långsiktig) lösning än att det explicita kravet har uppfyllts till 100%. Sen gäller det förstås att kunden och leverantören är överrens om detta och är någorlunda kommunikativa med varandra under resans gång.
Bengt; Freemind använder jag också ibland, det är ett bra verktyg.
Stefan; håller helt med om att det viktigaste är att det blir bra.
“att kunden och leverantören är överrens om detta” låter som en fråga som är allra mest aktuell inom konsultbranschen, där jag inte befinner mig (som tur är, höll jag på att skriva;)
Det kanske inte är så vanligt med enradingstester? Jag trodde det var “uppfunnet” på många håll.
Apropå Freemind så använder jag det också ibland. Ofta till kravhantering och i bland som en sorts testfalls administrativt verktyg, allt blir mycket visuellt tydligt. Min fråga till alla är nu, har någon idé på hur du på ett enkelt sätt verionshanterar i ett mindmapp verktyg. Finns det något mindmapp verktyg med inbyggt stöd för detta?
Rikard- bra inlägg
Även jag lite förvånad att inte fler kommenterat. Om det är så att det inte är så spritt så hade jag gissat att fler undrat vad du menar och hur du praktiserar det. Om det är så att många använder det så skulle det väl finnas massor att komplettera Rikards artikel med?
Själv så använder jag mig mycket av detta och har gjort en längre tid. Håller med om det du skrev men gillar även att dom ofta är ”open ended” vilket stimulerar till fler testideer samt att kostnaden för att ta dom från tanke till papper är väldigt liten så man behöver inte vara försiktigt och överväga om man ska skriva ner dom eller ej. Sen när man har dom så kan man enkelt och snabbt göra ett urval av vilka man anser mest värdefulla att faktiskt vill använda, men även detta urval kostar relativt lite att göra.
”Och de allra bästa testidéerna har man troligen i slutet av projektet när man vet mest”
Jag känner inte alltid så. Jag tycker att det ibland är väldigt svårt att komma på nya värdefulla testideer mot slutet av den anledningen att man vid det stadiet hunnit med att testa av det viktigaste och där de främsta riskerna finns. Så jag tycker att mot slutet kan det krävas ganska mycket energi och klurande att komma på värdefulla testideer och att inte falla in i ett slentrian beteende.
” ”att kunden och leverantören är överrens om detta” låter som en fråga som är allra mest aktuell inom konsultbranschen, där jag inte befinner mig (som tur är, höll jag på att skriva;)”
Men även du Rikard har väl en del kunder och intressenter (om än interna) till din testning som du behöver kommunicera med även om du jobbar internt på ett företag med produktutveckling. Så det Stefan skriver gäller väl oss alla, vi har alla kunder till det jobb vi utför annars är vi ju överflödiga och behöver vi ju inte göra det.
Tack Henrik, jag gillar också öppna testidéer, och den låga kostnaden (även för granskare) är nog den allra största förtjänsten.
Angående “de bästa testidéerna i slutet” så har du helt rätt; det var ett klumpigt försök till en klatschig formulering. Egentligen menar jag bara att ju mer man lär sig, desto bättre testidéer kan man skriva ner (fast om dom redan finns och är genomförda så är det ju inte så stor poäng.)
Och jo, vi har intressenter på vårt jobb, men jag vill inte se dem som kunder; och eftersom det är internt inom ett företag, så vill jag hellre se det som att vi gemensamt gör en bra produkt, inte som att vi uppfyller (informella) kontrakt.
Jag tror faktiskt att det är ganska ovanligt med dokumenterade testidéer (grattis till dig, Henrik!), och spekulerar i att:
* i en skriptad miljö finns det ingen anledning att skriva och granska enradingar, eftersom den gudomlige testdesignern ändå kommer att täcka allting
* i en utforskande miljö kommer den gudomlige testaren bara att begränsas av dokumentationen
Kombinationer av scripted (som metod!) och exploratory (som approach) är inte så välutvecklat (Kaner är nog på gång, http://www.kaner.com/pdfs/ValueOfChecklists.pdf, men det är inte ofta Bach och Bolton pratar gott om granskningar eller dokumentation)
Jag tror faktiskt att detta är vanligast i Sverige.
Få kommentarer kan bero på få läsare, men också på att det låter lite väl simpelt, som en grej som vem som helst kan komma på (vilket är helt sant!), man har bara själv inte haft något behov av det.
Det är nog först när man använt det ett tag, och fått ruljans på feedback som man inser det stora värdet av den lilla idén.