Per Erik Strandberg /cv /kurser /blog

http://www.pererikstrandberg.se/blog/320-advanced-software-testing.jpg 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:

  1. Test Basics, 32 sidor
  2. Testing Process, 28 sidor
  3. 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
  4. Test Techniques, 4 sidor
  5. Tests of Software Characteristics, 4 sidor
  6. Reviews, 34 sidor
  7. Incident Management, 24 sidor
  8. Standards and Test Process Improvement, 48 sidor
  9. Test Tools and Automation, 34 sidor
  10. People Skills and Team Composition, 44 sidor
  11. 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:

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:

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

Möjligheter då? Vad anses positivt?

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:

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

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.

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 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:

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:

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:

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:

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:

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):

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:


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