Boken Advanced Software Testing -- Per Erik Strandberg

Jag läser Advanced Software Testing Vol. 2 - Guide to the ISTQB Advanced Certification as an Advanced Test Manager från Rockynook Computing av gurun Rex Black. ISBN: 9781933952369. Du hittar den just nu för 311 kr på Adlibris - [1] - eller 42$ på Amazon - [2] .

Den är väl organiserad och följer i stort ISTQBs kurslayout som finns på svenska från SSTB: [3] (välj Dokument -> Certifierad testare, kursplan avancerad nivå). Den landar på cirka 550 sidor.

Boken är en av tre som avhandlar examinering för ISTQBs Advanced Level - men de tre delarna är överlappande och på många sätt oberoende av varandra.

Huvudfokus ligger på testledning och kapitelupplägget är:

Test Basics, 32 sidor
Testing Process, 28 sidor
Test Management, 230 sidor
- Introduction
- Risk-Based Testing and Failure Mode and Effects Analysis
- Test Management Documentation adn Test Plan Documentation Templates
- Test Estimation
- Scheduling Test Planning
- Test Progress Monitoring and Control
- Business Value of Testing
- Distributed, Outsourced, and Insourced Testing
- Test Management Issues
- Nonfunctional Testing Issues
- Sample Exam Questions
Test Techniques, 4 sidor
Tests of Software Characteristics, 4 sidor
Reviews, 34 sidor
Incident Management, 24 sidor
Standards and Test Process Improvement, 48 sidor
Test Tools and Automation, 34 sidor
People Skills and Team Composition, 44 sidor
Preparing for the Exam, 12 sidor

Utöver ett föredömligt index finns tre Appendix (en bibliografi, ett exempel på en kravdokument för ett system och svar på övningsuppgifter).

Den något schizofrena kapitelindelningen med ett kapitel på 230 sidor och ett annat på 4 sidor beror på att författaren i möjligaste mån försöker följa ISTQBs indelning i kapitel. Som ni säkert vet är det samma kursmaterial för alla de olika examinationerna på Advanced Level (Test Manager, Test Analyst eller Technical Test Analyst). För de olika inriktningarna är olika områden olika viktiga och det är av denna anledning kapitlen är så olika stora. Vill man veta "allt" kan man helt sonika läsa hela kursmaterialet från SSTB - något jag tänkte försöka orka igenom. Men jag kommer satsa på att fördjupa mig inom testledning. Framtiden får visa om jag satsar på att certifiera mig som testledare - gör jag det blir det nog tidigast hösten nästa år.

Kapitlet om testledning talar mycket om Riskbaserad Testning - ett område jag tycker om att fördjupa mig i.

Kapitel 9: Test Tools and Automation, Anteckningar och Kommentarer

Rex Black täcker i detta ganska korta kapitel väldigt mycket som är relevant vid testautomatisering. Jag har jobbat med testautomatisering i ett par år så jag känner igen mycket, men det är skönt att få ordning på mina ogrundade och spretiga tankar. Och så är det mycket man kanske inte kunde, om sanningen ska fram.

De två avdelningarna täcker:

Koncept för Test-automatisering: Kostnader, Risker, Fördelar, Strategier, fall-studie för test-automatiserings-strategi, test-verktygs-integration och skriptning, fall-studie för integrerade testverktyg och hur man kan klassificera testverktyg.
Kategorier av test-verktyg: verktyg för testledning, testexekvering, nyckelords-driven automatiserad testexekvering, fall-studie för testexekvering, debuggning och felsökning, statisk analys, dynamisk analys, prestanda/performance, web-verktyg, simulatorer och emulatorer och en fall-studie för ett egenutvecklat testverktyg

Test Tool Concepts

Denna avdelning hade 3 kunskapsmål på nivå K2. Rex Black höjer verkligen ett varningens finger för testautomatisering och ger flera exempel på hur lätt man kan misslyckas. Att ha strategier och att mäta är nyckeln till ROI. Man vill inte hamna i "zero-ROI hell".

För att ha ett business case behöver vi undersöka kostnader, risker och
möjligheter. Först kostnader:

Initiala Kostnader
- Val och utvärdering av verktyg
- Inköp
- Inlärning
- Integration med andra verktyg och med personal
Återkommande kostnader:
- Underhåll
- Licenskostnader?
- Supportkostnader?
- Utbildning, bland annat för ny personal?
- Porta till nya plattformer
- Utöka test-täckning (skriva nya testfall)
- Ständiga förbättringar

Risker med automatiserad testning. Listan har fyllts från från Foundation:

Orealistiska förväntningar.
Underskatta kostnad och arbetsinsats för att introducera verktyget.
Underskatta arbetsinsats för att uppnå vettig ROI.
Underskatta arbetsinsats för att underhålla tester. Här ger författaren ett bra exempel på att man genom att initialt fuska med design av sitt testramverk får dyr underhållskostnad.
Övertro på verktyget.
Att automatisera felaktiga testfall resulterar bara i att man fortsätter göra fel, fast bara fortare. Man behöver se till att man har en vettig grund för sin automatisering.
Testerna och ramverket behöver utvecklas i takt med att produkten man testar utvecklas. Här finns stor risk att man bara underhåller sitt system och inte allt lyckas automatisera fler och fler testfall.
Misslyckas man att inse att sitt testautomatiseringsförsök bara har kostnader.
Med övertron till testsystemet kanske man glömmer mänsklig kreativitet och minskar manuella tester så att man släpper igenom fler defekter.

Möjligheter då? Vad anses positivt?

Automatiseras tester som körs ofta tjänar man snabbare in investerad tid.
En bra idé är att automatisera tester i rätt ordning - och inte ha som mål att automatisera allt.
Väl på plats krävs liten insats och hög effektivitet på automatiserad testning.
I vissa fall kan tid för att testa vara stor i förhållande till tid för att reparera buggar - i så fall kan hela releasecykeln kanske snabbas upp. Om man har tur.
Vissa saker kan inte testar manuellt på ett meningsfullt sätt (lasttester och så vidare).
Det är kul och utmanande att jobba med automatisering - så folk brukar gilla det.
Vissa utvecklingsmodeller - typiskt agila - kan ha en snabbt växande lista med regressionstester som det kan bli orealistiskt att testa manuellt på ett tillfredsställande sätt.

Man behöver en strategi för att automatisera - som Rex skriver så räcker det inte med att köpa en motorsåg för att utplåna en skog. Jag spinner vidare på den tanken och vill även varna för okontrollerad teknisk flora. Det kanske är bra att köpa eller bygga en motorsåg, men det är antagligen inte så bra om man har ett helt batteri motorsågar från olika tillverkare med olika reservdelar. Jag tror det är samma sak med mjukvara - kanske speciellt fri mjukvara som är "gratis". Det kan bli dyrt att underhålla kunskap om olika verktyg hos en skock testare och utvecklare.

Författaren ger ett exempel på hur han hjälpte ett testautomatiseringsprojekt på fötter i ett par steg:

Definiera KPI (key performance indicator), ROI (return on investment), affärsnytta.
Definiera beslutsmodell/processmodell, hur verktyg ska utvärderas
Identifiera kandidatverktyg
Utvärdera och välj verktyg
Implementera process, använd metriken och gör en plan
Lär er verktygen, sätt upp testmiljöer, ...
Låt den revitaliserade test automatiseringen börja!

I ett avsnitt nämner författaren att "..it would be nice to integrate all the test results into our test management tool and add traceability from our tests to the requirements or risks..."". Han nämner att man med skriptade verktyg lättare kan koppla in sig i ett API, kanske att fråga en server eller databas frågor direkt istället för att gå via en webb-sida.

I en fallstudie visar författaren en testsystemsarkitektur och ger exemplet att en dataprob kan vara bra för att läsa vilka ändringar som skett i till exempel en databas så att man inte bara tror det grafiska användarinterfacet som säger "allt gick bra".

Det finns många sätt att kategorisera testverktyg

Vilka aktiviteter stödjer verktyget?
Vilka test-nivåer stödjer det (modultester, integrationstester, ...?)
Vilka typer av defekter kan vi hitta?
Vilka testtekniker används?
Vad är syftet medverktyget?
I vilka domäner verkar verktyget?
Hur använder vi dem?
Vilka användare?

Den indelningen fick mig att tänka på Agila Testkvadranter från Boken Agile Testing - kanske inte helt relaterat men tankesättet att olika aspekter av testningen kräver olika testverktyg.

Test Tool Categories

I detta ganska korta avsnitt beskriver författaren olika typer av verktyg. Jag listar här de verktyg som författaren tar upp och lägger till några andra. Citaten kommer från ISTQB's/SSTB's ordlista som du bland annat kan hitta på [4] - jag kan varmt rekommendera att ladda ner denna lista och kika i då och då. ISTQB och SSTB har verktligen gjort en underbart jobb i att sammanfatta denna ordlista och att hitta översättningar från Engelska till Svenska.

Test Management Tool, eller Testledningsverktyg: "Verktyg som stödjer testledningen. Exempel på funktioner i testledningsverktyg är: stöd för oberoende versionshantering, gränssnitt för testexekveringsverktyg, stöd för spårbarhet av test, loggning av testresultat osv."
Test Execution Tool, eller testexekveringsverktyg: "En typ av testverktyg som utför exekvering av annan programvara genom automatiserade testskript, till exempel in- och uppspelningsverktyg" (capture/playback). Här tänker jag bland annat på Microsoft Test Manager och att spela in klick i Visual Studio (som jag beskriver lite i Testing In Visual Studio Part 2), men också hur Selenium kan fungera (se Selenium Plus Android). Jag har även jobbat med ett testramverk som via en typ av serieportar skickat kommandon till en "dut" (device under test). Ramverket triggade händelser och startade program i dut'en.
Keyword driven testing, eller Nyckelordsdriven testning: "En testteknik där man väljer testfall baserat på vissa nyckelord, ofta affärsdrivet och kopplat till den funktionella och logiska användningen av systemet. Se även datadriven testning." Här associerar jag till ett system vi försöker införa nu där vissa nyckelord till testramverket ska flagga upp vissa tester som extra viktiga. Ponera att vi uppdaterat en drivrutin i en gps-mottagare, då vill vi med nyckelordet gps välja ut, eller prioritera upp tester som är relaterade till gps.
Data Driven Testing, eller Datadriven testning: "En testteknik där testdata, dvs. invärden till testning, separeras från testfall. Ett vanligt tillvägagångssätt är att lägga de separerade invärdena i en tabell eller ett kalkylblad, och sedan låta mer generellt skrivna testfall läsa och använda dem. Datadriven testning används ofta för att stödja användning av testexekveringsverktyg t.ex. in- och uppspelningsverktyg. Se även nyckelordsdriven testning." Den här principen att skilja på testdata och testscript tror jag kan vara väldigt viktig för att möjliggöra för personer i projektet som inte är programmerare eller testutvecklare att utöka ett test. Kanske listar man gps-positioner i en kolumn i ett kalkylblad och vilken typ av beslut som ska fattas i nästa kolumn. När testetskrevs kanske två fall var kända, men insatta personer från marknadsavdelningen kanske kan utöka till ett par hundra. Då vore det ju vettigt att inte hårdkoda in de två fallen man först tänkte på i test-koden.
Debugging Tool, eller Avlusningsverktyg/Debuggningsverktyg: "Ett verktyg som används av programmerare för att återskapa felsymptom och undersöka program i syfte att hitta var det finns fel som orsakar felsymptom. Dessa verktyg gör det möjligt för utvecklare att undersöka program rad för rad, att stanna på en viss kodrad i programmet och att undersöka programvariabler." Som SSTB skriver är debuggningsverktyg typiskt för utveckling och inte för test. Det beror på att test inte är debuggning, och debuggning inte är test. Rent historiskt var test tidigare i princip debuggning - men så är det inte nu. Syftet med test är att hitta problem i mjukvara, syftet med avlusning är att reparera (eller lokalisera) fel.
Fault Seeding, eller felplantering (tidigare felinjektion): "Processen att till dem fel som redan finns i en komponent eller ett program avsiktligt addera ytterligare fel, i syfte att utvärdera hur många fel som hittas och tas bort, och för att uppskatta hur många fel som finns kvar." Detta görs med ett fault seeding tool, eller felinjektionsverktyg: "Verktyg för att injicera fel i en komponent eller ett system." Jag har själv aldrig testat felinjektion, men det är frestande att tänka att det måste vara effektivt. Ponera att du injecerar 100 fel i din kod, men testerna hittar bara 80 av dem. Då kan man dra slutsatsen att de 20 som är kvar kanske inte har tillräckligt bra testfall.
Static Analysis, eller Statisk Analys: "Analys av programvaruartefakter, till exempel krav eller programvarukod, utan att dessa artefakter exekveras. Vanligtvis utförs statisk analys med hjälp av verktyg." Static Code Analysis, eller Statisk Kodanalys definieras som "Analys av källkod utförd utan att programvaran exekveras." Typiska verktyg som jag stödd på är Visual Studio och Pylint (som jag skrvier om i Testing In Visual Studio Part 1 och One Does Not Simply Document Code). Verktyg för statisk kodanalys är i regel riktigt billigt med tanke på hur mycket och hur snabbt man hittar problem. Nackdelen kan vara en stor grad falska negativer.
Dynamic Analysis och Dynamic Analysis Tool, eller Dynamisk Analys och Dynamiskt Analysverktyg: "Processen att utvärdera ett system eller en komponent baserat på dess beteende under exekvering" respektive "Ett verktyg som tillhandahåller realtidsinformation om tillståndet för programvaran. Dessa verktyg används oftast för att identifiera ej tilldelade pekare, visa minnesallokering och flagga för minnesläckor." Här tänker jag på det ganska populära Valgrind som jag hört mycket gott om men aldrig använt själv. Se Wikipedia: [5]
Performance Testing och Performance Testing Tool, eller Prestandatestning och Verktyg för Prestandatestning: "Testning vars syfte är att utvärdera prestanda hos ett system, en systemdel eller en komponent. Testningen avser att demonstrera att testobjektet uppfyller specifika prestandakrav. Prestandatester omfattar både last- och stresstester" respektive "Ett verktyg som som stödjer prestandatestning som vanligtvis har två huvudfaciliteter, lastgenerering och mätning av testtransaktioner. Lastgenerering kan simulera antingen fleranvändare eller stora volymer av indata. Svarstider kan mätas och loggas från utvalda transaktioner under testexekvering. Dessa verktyg kan normalt tillhandahålla rapporter som baseras på testloggar och diagram som visar last jämfört med svarstider." Jag tänkte berätta om två erfarenhet jag har av prestandatester. Det ena handlar om att mäta omkopplingstider i nätverk. I princip skickade vi trafik från A till B via C eller D. När vi stänger av C eller D vill vi se att inte för mycket paket försvinner. Detta gjorde vi med hping3 som fick skicka ett paket per millisekund från A. I B mätte vi sedan hur stora glapp vi kunde uppmäta. Här hade vi problem att få upplösning bättre än millisekunder eftersom att vanliga datorer och nätverkskort kanske inte har tillräckligt bra prestanda. Den andra erfarenheten består i att mycket noggrannt mäta hur mycket paket man kan skicka genom ett device under test utan att man tappar paket. Här använde vi en extern "dator" vars enda syfte är att skicka massor med paket i en extrem hastighet med en extrem noggrannhet. Med olika script kunde vi ställa in vilka tester vi ville köra och genom vilka portar. Läs mer om hping3 på Wikipedia (se [6]), eller kika på verktygen Mausezahn eller Netsniff-NG (se [7] respektive [8]).
Simulator: "Utrustning, program eller system som används vid testning och beter sig likadant som ett givet system eller en komponent, då det ges en mängd av kontrollerade invärden. [...] Notera att egenskaper som tidsberoende faktorer oftast inte går att testa med denna metod"
Emulator: "Utrustning, program eller system som accepterar samma indata och producerar samma utdata som ett bestämt system."

Kapitel 10: People Skills and Team Composition, Anteckningar och Kommentarer

People Skills and Team Composition är för mig ett otroligt nyttigt kapitel. Har man kanske en bakgrund som projektledare kanske det är välbekant.

Individual Skills - här ligger fokus på att kartlägga kompetensen i sitt team. Författaren delar in färdigheter i tre områden: testfärdigheter, färdigheter i teknik och mjukvara samt domänkunskap. Vi får även bra tips på en typ av kompetensmatris. Rex Black talar även om att världen håler på att mogna för testning som karriärval. Attityder som "vem som helst kan testa" eller "ge mig bara en mall så gör jag en teststrategi" finns kvar och är inte ovanliga - men håller på att försvinna. Universitet och Högskolor har mängder med utbildning inom olika typer av utveckling, men test ligger ett par decennier efter - men det finns undantag. Här i Västerås forskas det till exempel inom test.

Två begrepp som ofta återkommer är team of specialists och team of generalists. Skillnaden är att specialistteam har individer som är bra på färre saker men har större erfarenhet inom dem. Generalister är bra på fler saker men har inte lika djupa kunskaper inom dem.

Rex Black och ISTQB i allmänhet är ganska förtjusta i att mäta saker. Jag börjar gilla det mer och mer - men är ibland lite skeptisk till att mäta saker för mätandets skull. Ett för mig nytt mätetal som jag gillar, och som jag stött på i projektledningssammanhand är en uppiffad kompetensmatris:

Vi listar delområden inom test, teknik och domän i rader (för test till exempel: granskning, performancetester och manuell testning).
I kolumner listar vi våra medlemmar i teamet.
Underst får vi ett slags medelvärde per medlem i teamet.
Vi gör ett par kolumner till vänster med olika roller och kompetenskrav för de olika rollerna. Och till höger för vi statistik på vårt team (max, min och medel för de olika kompetenserna).
Cellerna kan du ge värden från 0-3 (ingen, låg, medel, hög) beroende på om du vill ha en allmän nivå, eller kanske antal års erfarenhet, eller kanske bara: ok, ingen.
Författaren påpekar flera gånger att inte ha nivåer utifrån "mål" - utan på "krav".
Vill vi nu har ett "team of specialists" vill vi ha höga max-värden i de olika kompetenserna - men vi bryr oss mindre om medelvärdena. Söker vi istället ett "team of generalists" kanske vi är mer fokuserade på att få upp lägsta-nivåerna (eller medelnivåerna).

Vi får tipset att uppdatera denna kartläggning mer än en gång per år. Jag blir inspirerad att göra denna övning på mitt nuvarande uppdrag. Inte minst för att få lättare att kommunicera med beslutsfattare om vilken kompetens vi har, vilken vi behöver och kompetensutveckling för teamet.

Test Team Dynamics - Det märks att Rex Black och hans RBCS har stor erfarenhet om att få ett team att fungera. Här får vi tips på kompetensutveckling, hur man kan göra gap analysis - hitta luckor i kompetensen i sitt team - och hur man fyller luckorna.

När vi gjort en kompetenskartläggning och undersökt erfarenhet inom de tre områdena: test, teknik/mjukvara och domänkunskap så kan vi se inom vilka områden teamet har luckor. Här tipsar Rex Black även om en sak som Tore Testledare tipsar om: ta inte in folk i test teamet utan att undersöka deras styrkor och svagheter. Är det internrekrytering kanske är det människor med samarbetsproblem som andra avdelningar vill bli av med? Är det en vanlig rekrytering kanske individen är för erfaren inom utveckling: vill denne egentligen programmera men ser test som ett sätt att komma in i företaget. Detta är saker man behöver ha koll på innan man tar in någon i teamet - det är ju inte säkert att man blir bättre bara för att man blir fler. Till exempel blir inte ett team bättre på testautomatisering av man tar in en individ som är bra på att spela fotboll.

Författaren tycker att det är en bra idé att låta nya medlemmar i teamet få ett tag på sig att vänja sig innan man ger dem uppgifter utanför vad de är bekväma med. Chefer som pressar folk med attityder som "alla är ersättningsbara" märker snart att "shit vad illojala folk är som slutar hela tiden".

I en övning får vi några idéer för hur man göra för att fylla ett kompetenshål:

Anställ någon med den kunskapen. Antingen kan den personen bli den specialist som tar hand om det området framöver. Eller så kan man se till att kompetensöverföra från denne.
Hyr in en konsult med rätt kunskap. Detta är ett extra bra val om behovet är "en tillfällig topp". Vill man kompetensöverfåra från konsulten så skriver Rex Black att man börgöra det klart i förhand eftersom det kan ligga i konsultens intresse att inte släppa kunskap ifrån sig. Eftersom jag själv jobbar som konsult känner jag att detta kanske inte är en så himla lätt fråga. Ibland sitter man på dubbla stolar - å ena sidan behöver man sälja sig så mycket som möjligt, å andra sidan vill man att det ska gå så bra som möjligt för kunden. Å tredje sidan kan man vara mer eller mindre pedagogiskt lagd. Ser man till mina uppdrag hittils tycker jag att en bra överlämning har haft hög prio.
Outsourca testningen. Detta kan vara speciellt bra om det är testning som är svår att lära sig eller om det är bulk-testning som ska genomföras i "låglöneland". Jag tänker att till exempel webb-tester i olika webb-läsare, telefoner och plattor är bra testning att outsourca. Säkerhetstester är svårt att ha en specialist inom i varje utvecklingsprojekt. Inte sällan hör man om att last-tester lejs bort. Tester som kräver särskild utrustning kan kräva att man lejer bort dem. Exempel som jag ofta stöter på är klimat-, vibrations-, EMC-, eller akustiska tester. När det gäller att leja bort en hel testavdelning till låglöneland har jag blandad erfarenhet: jag har hört om företag som lejt bort testning, fått 100% pass och sen hittar mängder av fel i produktion istället. Jag tror nyckeln här är kommunikation och att ha någon på plats som överbrygger kulturskillnader.
Skicka någon på en kurs. Låt denne bli specialist eller se till att överföra kunskap.
Hyr in någon för att hålla en kurs. Här finns det många olika lösningar: antingen går hela gruppen (team av generalister?) eller bara vissa (team av specialister?). Men kostnaden blir antagligen högre per person om få går kursen.
Jobbrotation kan vara en lösning: man byter arbetsuppgifter för att få upp kompetensen hos fler.
I vissa fall kanske utvecklarna kan utbilda testarna för att sprida kunskap om kommande funktioner; tech previews och demos kan vara bra.

Fitting Test Within an Organization - Vi får igen motivation till varför oberoende testning är bra, men även att det kan vara en mycket god idé att bland graden av oberoende i sin testning (till exempel kanske kraven granskas av en extern part, kod granskas inom utvecklingsavdelningen, modultesterna görs av utvecklarna och så vidare).

Rex Black gör här en snygg koppling till Fred Brooks No Silver Bullets (som är med i The Mythical Man-Month) om att testning är komplext, inte av slump (som när man åker snöskoter i öknen) utan för att komplexitet är en inneboende egenskap av att testa mjukvara. Vi får läsa att mognaden och känslan för vem som ansvarar för kvalitet blir bättre och bättre i företag men att det ibland är långt kvar.

En viktig del i detta avsnitt är att det kan vara bra med oberoende testning, men det kan finnas fördelar med mindre oberoende testning också. Att granska sin egen kod har ju till exempel fördelen att det ofta går fort att rätta till de fel som hittas.

Vi får även fler tips på när outsourcening av test kan leda till problem. Till exempel vid patentskyddad eller sekretessbelagd kod: vågar man skicka den till folk man inte "känner"? Kulturella skillnader och skillnader i kommunikation kan ställa till det. Den minskade kostnaden kan vara överskattad eftersom det ofta krävs fler mellanchefer till exempel för att sköta kommunikation.

I en fallstudie ger författaren tips på hur man i en organisation kan ha olika nivåer av oberoende i olika kvalitetsfilter. I exemplet nämnde han: Krav-, design- och kod granskning; enhets-, integrations-, system-, systemintegrations- och acceptanstest. I exemplet hade han fem olika team som testade (externa oberoende testare, en testavdelning, utvecklarna själva, en fjärde part som tog hand om säkerhetstester) och till slut slutanvändarna som var involverade i acceptanstester.

Motivation - Avsnittet handlade om att förklara att det finns vissa typsituationer som testare hamnar i som är motiverande (erkännande) eller demotivera (jobba natt). Några klockrena situationer var "ni hittar så många fel åt våra utvecklare så vi måste jobba över - det kan ni gott göra också", en annan "releasen är ute - jag bjuder på middag och tar med vin".

Ett citat jag hörde av en kollega handlade om outsourcad testning där utvecklingschefen var oroad över releaseschemat eftersom "de där jävla testarna hittar så mycket problem hela tiden". En situation jag själv varit med om som varit mycket demotiverande var "det är två team som behöver simulatorn nu, så ert team får jobba natt". Tyvärr ser man ofta situationer där en projektledare eller chef kommer med ett trasigt bygge, eller något som kommer rykande färskt från kompilatorn och vill få det testat, utan syfte och utan mål. Det officiella bygget testades kanske dagen innan och om bara ett par dagar kommer en vettig testrelease.

Min erfarenhet av motiverande situationer är:

När får använda sin kreativitet för att angripa ett område och lyckas hitta problem i det (typexemplet är: "tänk på en siffra mellan 1 och 5" och man svarar "-257" och får svaret "Bus error... Dumping Core.").
När en felrapport tas emot med först lite förvirring och sen "Bra fångat!".

Men det som jag kan se som det största problemet, som Rex Black formulerar mycket bra, är när testavdelningen blir syndabock för ett projekts dåliga kvalitet - typiskt när alla andra i projektet tagit genvägar som underminerat kvaliteten. Det är förvånande att man kan höra folk resonera att "om vi bara slarvar lite nu så kommer vi få kvalitet gratis senare".

Communication - Testare använder typiskt tre olika nivåer:

Dokumentation om testartefakter (teststrategier, testfall, felrapporter...)
Feedback på granskade dokument (krav- och funktionsspecifikationer...)
Vi interagerar med utvecklare, projektledare och andra testare för att få koll på saker och samla information.

Vid vissa tillfällen gäller det att vara extra tydlig och ha ett syfte med det man säger. Ska man till exempel förmedla att systemtesterna gick dåligt så vill man inte svamla fram det utan vara korrekt och tydlig. Författaren ger ett exempel med fem delar om en till ett par meningar styck:

Något som inger förtroende: "Jag lade ett par timmar på att sammanfatta..."
Något som sammanfattar problemen: "Följande Skall-Krav är inte uppfyllda..."
Något som sammanfattar varför vi inte bara kan skita i att saker gick dåligt: "Vid en första anblick kanske det inte ser ut att vara allvarliga fel, men slutkunden..."
Sammanfatta besvikelsen i att nya fel forsätter att dyka upp trots att vi egentligen vill överlämna till kund imorgon: "Notera även att 18 nya fel rapporterades under den andra omgången systemtester.""
Ibland kanske vissa skall-krav tummas lite på för att få ut en release i tid - då vill man kanske se till att de inte bara glöms bort: "För att se till att leveransen kommer framåt har part X tillfälligt sänkt [...] men förväntar sig att dessa problem är lösta i nästa [...] "

Kapitel 11. Preparing for the Exam, Anteckningar och Kommentarer

Här förklarar Rex Black hur tentan typiskt ser ut. Hur kunskapsmålen definieras och att nationella noder, typ SSTB, kan överrida dessa rekommendationer om de känner för det.

För kunskapsmålen ger han ett par bra exempel:

K1: Minnas - till exempel att "failure" betyder icke-leverans eller avvikelse från förväntad leverans, service eller resultat.
K2: Förstå - till exempel likheter och skillnader mellan integrationstest och systemtest (likhet: man testar mer än en komponent och man kan testa kvalitetsaspekter (icke-funktionella aspekter) och skillnad: integrationstester fokuserar på interface mellan komponenter emedan systemtester undersöker hela systemet).
K3: Tillämpa - till exempel när man hittar randvärden för ekvivalensklass-indelning (mellan tillåtna och otillåtna värden), eller hur en generisk process kan se ut när man skapar testfall utifrån en tillståndsmaskin.
K4: Analysera - till exempel när man identifierar produktrisk och föreslår motåtgärder (minns ni de fyra teknikerna: minska risk, minska impact, delegera risk, eller ta smällen om den kommer? - se Riskbaserad Testning), eller när man analyserar felrapporter för att hitta root cause..

Vår vän Rex Black ger även tips på hur man kan tänka när det gäller flervalsfrågor (multiple choice questions):

Det finns en stam - en sann kärna som är själva frågan. Kanske ett diagram, eller bara själva problemet.
Det finns distraherare - svarsalternativ som är felaktiga.
Det finns det rätta svaret - eller det eller de rätta alternativen

Han förklarar även att en del frågor bara har är av typen a, b, c eller d; och att andra beskriver ett scenario med ett antal påståenden där de fyra alternativen går ut på att välja mellan dessa påståenden.

Innan appendixen ger Rex Black fyra tips inför tentan:

Gör inlärningsuppgifterna i boken.
Gör tentafrågorna i boken, eller om du gjort dem så gör en övningstenta.
Gå igenom ISTQB's ordlista.
Läs igenom boken och ISTQB's syllabus.

Tillhör Kategori Mjukvara
Tillhör Kategori Test
Tillhör Kategori Boktips