En faktor som påverkar tiden för test fundamentalt är ett systems testbarhet.
Bygger man in i systemet (helst från början) egenskaper och funktioner som underlättar testarbetetet så har man stor chans att hålla tidsåtgången för test på en hyfsad nivå över tiden.
Här är en lista på saker som i mitt tycke ökar testbarheten för komplexa och stora system åtminstone:
1. Testmiljöer
Tillgång till en kontrollerad, helst produktionslik testmiljö är vanligtvis ett av fundamenten i ett testprojekt. Men räcker det med en? Inte sällan vill man ha flera testmiljöer för att det inte ska uppstå flaskhalsar och så att olika tester inte stör varandra. Att ha extra testmiljöer med äldre versioner är ofta inte helt fel heller…
1.1 Det ska vara lätt att skapa nya testmiljöer godtyckligt, publika som lokala.
2. Testdata
Utan bra testdata, inga bra tester…
2.1 Det ska finnas möjlighet att använda/skapa produktionslikt testdata i godtycklig mängd med en minimal insats.
2.2 Testdata ska kunna flyttas mellan (test)miljöer
2.3 Testdata ska kunnat sparas i ett visst läge (snapshot)
3. Systemtid
I komplexa system händer det ofta massa spännade saker över tiden. Har vi tid att vänta i realtid på att någon viktig händelse ska triggas? Nix.
3.1 Datum och klockslag i en testmiljö ska kunna ändras godtyckligt (åtminstone framåt i tiden).
4. Systemfel
Ohanterade systemfel kan ju förekomma och bör ofta åtgärdas ASAP. Men vilken kodrad? Vilket data?
4.1 Systemfel ska loggas automatiskt innehållande relevant information som stack-trace och parametervärden
5. Loggfunktionalitet
Loggar innehåller ofta viktiga pusselbitar i vårt dagliga testarbete.
5.1 Omfattande loggfunktionalitet ska finnas och vara konfigurerbar utfrån behov
6. Testverktyg
Måste man använda dyra externa testverktyg? Nix, bygg in skräddarsydd funktionalitet för tidskrävande obligatoriska (test)aktiviteter i systemet istället.
6.1 Via lämpligt gränssnitt ska inbyggda testverktyg vara tillgängliga som kan användas vid testarbete (konfigurerbart)
7. Automatisering
Automatisera regressionstester eller ej? Om ja så…
7.1 Systemets alla gränssnitt ska vara förutsägbara och varje enskilt objekt ska ha ett sammanghangsunikt id-begrepp om möjligt
8. Versionshantering
Vilken version testar vi mot?
8.1 Systemets versionsidentitet ska finnas tillgängligt via gränssnitt.
Hur är det systemens testbarhet där ute?
Hej Stefan,
En riktigt bra checklista att gå igenom när börjar fundera på designen av produkten.
En del av dom punkterna känner jag själv att jag har tänkt på för sent och när man sen begär dom så är designen redan gjord och det är för kostsamt att ändra, så man blir utan istället.
En liten fundering man kanske ska ha med sig är om de ingrepp man vill göra på designen för testbarhet påverkar systemet på något negativt sätt, tex prestandamässigt? Tänker mest så att man vet vilka ”trade off” man gör.
Checklistor är fantastiska verktyg och denna gillar jag skarpt. Jag skulle kunna tänka mig att lägga till (åtminstone för agila projekt) möjligheten att som testare kunna ha tillgång till kod direkt från CI-miljön och kunna göra egna byggen. Detta påverkar kanske inte testbarheten direkt, men indirekt upplever jag det som kraftfullt för “flödet” i arbetet att kunna komma in snabbt efter en incheckning av ny kod och kunna börja testa, snarare än att behöva be någon göra ett bygge åt test.
Tack för kommentarerna!
@Henrik
En del av dom punkterna känner jag själv att jag har tänkt på för sent och när man sen begär dom så är designen redan gjord och det är för kostsamt att ändra, så man blir utan istället.
Absolut, jag är övertygad om att det kan vara intressant att räkna på även för många befintliga system om man har en bra prognos på systemets förväntade livslängd, befintlig testinsats per release/projekt etc. Om inte annat för att få ytterligare ett underlag för beslut hurvida man ska byta system eller ej.
En liten fundering man kanske ska ha med sig är om de ingrepp man vill göra på designen för testbarhet påverkar systemet på något negativt sätt, tex prestandamässigt? Tänker mest så att man vet vilka ”trade off” man gör.
Det ställer krav på konfigurerbarhet för exempelvis loggning (som oftast tar prestanda även om det görs asynkront) samt att man har en bra versionshantering då testfunktioner inte får påverka “riktig” funktionalitet negativt.
Man bör förmodligen även göra vissa tester “the hard way” i någon fas men testfunktionalitet kommer förmodligen hjälpa till att hitta allvarliga problem tidigare än annars. Som testare bör man behålla sitt kritiska tänkande och fastställa värdet/risken av användandet av testhjälpmedel vid varje givet tillfälle.
@Jonas
Jag skulle kunna tänka mig att lägga till (åtminstone för agila projekt) möjligheten att som testare kunna ha tillgång till kod direkt från CI-miljön och kunna göra egna byggen.
En variant är att testaren har en egen utvecklingsmiljö.
Införandet av testbarhet underlättas av ett nära samarbete med utveckling vilket också är en framgångsfaktor i många andra sammanhang också.
Flera av dessa fina punkter behöver troligen implementeras av utvecklarna “i” produkten.
Så det är viktigt att också peka på att utvecklarna kan tjäna väldigt mycket tid på att lättare testa själva, samt felsöka underligheter som upptäcks.
@Rikard
Flera av dessa fina punkter behöver troligen implementeras av utvecklarna ”i” produkten.
Så det är viktigt att också peka på att utvecklarna kan tjäna väldigt mycket tid på att lättare testa själva, samt felsöka underligheter som upptäcks.
En viktig poäng. En stor fördel med att ha dessa funktioner inbyggda är att det kan utnyttjas i alla led utom Prod (därav konfugurerbart) samt att minimera deployment-problematik . Förmodligen kanske den största tidsbesparingen blir just att bättre utförda utvecklartester möjliggör tid för djupare tester av testteamet.