Det svenska testundret

Om man söker efter ”det svenska undret” i en känd sökmotor, kan man läsa om de perioder i svensk historia som kännetecknats av en snabb samhällelig och ekonomisk utveckling. Den första av dessa perioder inföll under 1800-talets senare decennier, då freden, vaccinet och potäterna banade vägen för stora framsteg inom industrin och vetenskapen. Den utvecklingen fortsatte sedan en bra bit in på 1900-talet. Det var under den här tiden som Alfa Laval, Asea, LKAB och LM Ericsson började växa sig stora och hjälpte till att sätta Sverige på världskartan som industrination.

Det svenska undret fortsatte under perioder under hela 1900-talet. Nyutvecklingar och innovationer på flera områden bidrog till att göra Sverige världskänt. När jag talar om det svenska undret tänker du kanske på

- musikundret (ABBA, Ace of Base, Robyn m fl),
- modeundret (Acne, Whyred, Filippa K, m fl),
- tennisundret (Björn Borg, Mats Wilander, Anders Järryd m fl),
- deckarundret (Sjöwall/Wahlöö, Henning Mankell, Stieg Larsson m fl),
- IT-undret (MySQL, Spotify, Skype m fl).

Listan fortsätter med golf-, kör- och app-under och så vidare, men du förstår principen. För ett land med blygsamma 9,5 miljoner invånare kan Sverige skryta med anmärkningsvärt många framgångshistorier.
I dag vill jag lyfta fram ytterligare en: det svenska testundret.

Om du läser det här inlägget på en dator eller mobil enhet med internetuppkoppling, så vill jag be dig att gå till din favoritsökmotor och knappa in ”software testing in Sweden”. Du kommer att få en hel massa länkar till föreningar, företag, organisationer, utbildningar, kurser, konferenser, produkter och naturligtvis många professionalla yrkesutövare. Alla representerar de den stora bredden inom kravhantering och programvarutestning som finns i Sverige i dag.

Låt oss titta närmare på vad ”lilla Sverige” faktiskt har att erbjuda:

Föreningar och communities

- SAST (Swedish Association for Software Testing) grundades 1995 som ett forum för yrkesverksamma programvarutestare. Sedan dess har verksamheten vuxit år för år och utökats med lokala föreningar som anordnar föreläsningar och seminarier.

- TestZonen är ett obundet och ideellt forum för diskussion om test, krav, kvalitet och processer. De anordnar dessutom mingelträffar (meetups) och en årlig konferens.

- På LinkedIn finns flera svenska grupper för diskussioner om krav och test.         

Konferenser

- Let’s Test är en konferens som har fokus på context-driven testing.

- TestZonen anordnar varje år en konferens för sina skribenter. Den bygger i hög utsträckning på deltagarnas egna idéer och initiativ.

- EuroSTAR-konferensen med Europas största fackmässa kommer att hållas i Sverige i år, närmare bestämt i Göteborg, den 4 - 7 november 2013.

- NFI Testforum är en återkommande konferens om test och kvalitetssäkring.     

 Utbildningar

- Som läsare av Informator-bloggen känner du säkert redan till Informators utbud av kurser inom krav och test. I utbildningsstegen hittar du kurser som ger dig verktyg, metoder, processer och modeller för att arbeta smart med krav och test. Om du önskar kan du även certifiera dig inom ramen för REQB och ISTQB.

- Kommersiella utbildningar erbjuds också av en rad företag 

- Flera yrkeshögskolor erbjuder hela utbildningar inom programvarutestning i bland annat Karlstad, Kungsbacka, Göteborg och Stockholm. 

- Akademiska kurser inom programvarutestning finns bland annat vid högskolorna i Dalarna, Luleå och Växjö.

Litteratur

-   Test och kvalitetssäkring av IT-system, Ulf Eriksson
-   Kravhantering för IT-system, Ulf Eriksson
-   Testdesign för programvara, Torbjörn Ryber (finns även i engelsk utgåva)
-   Testledning, David Pers & Mikael Ölund
-   Tore Testledare, David Pers 

Listan skulle självfallet kunna göras mycket längre, men jag nöjer mig med detta. Jag tycker att de exempel som nämns är bra representanter för programvarutestning, så som den ser ut i Sverige i dag. Det som jag slås särskilt av är hur många engagerade testare som finns runt om i landet, och deras vilja att träffas, utbyta tankar och lära sig nya saker av varandra. Att utvecklas i sin yrkesroll – om det så innebär att man lägger några timmar av sin fritid – och att ha roligt samtidigt. Test är fest.  Inte många länder har en så aktiv och levande testarcommunity som den vi har.

Krav och test är områden som har utvecklats starkt de senaste tio – femton åren. Och framtiden ser fortsatt ljus ut. Allt fler företag har förstått att ett ordentligt krav- och testarbete är en förutsättning för att projekten ska lyckas. IT-systemen tenderar att bli alltmer komplexa, något som ställer högre krav på kompetens inom krav och test. Testarna hjälper till att tillföra nytta till sina verksamheter, och det hjälper i sin tur till att höja statusen på yrket.  Samtidigt blir det hela tiden bredare och mer specialiserade mot olika områden. Att arbeta med test kan till exempel innebära att vara testledare, teststrateg, testautomatiserare, testdesigner eller testmiljöansvarig. Valmöjligheterna är med andra ord goda för den som vill hitta sin egen nisch.

Vad brinner du för? Om svaret är krav eller test, så har du hamnat helt rätt. Hos Informator hittar du ett gäng kursledare som är stolta över att vara en del av det svenska testundret. Vi ger dig grunderna och hjälper dig att ta nästa steg i din testkarriär.

Freddy Gustavsson har arbetat med test och kvalitetssäkring av programvara sedan 2001.

Informator erbjuder flera spännande kurser inom Kravhantering och Testmetodik. Se alla våra kurser inom Krav och Test här

Läs mer

Auditability and V&V in the era of Machine Learning are worth a close review…

Developers, more often than architects, tend to get frustrated by declarative programming, because it boosts expressive power at the cost of less testability. Yet both the boost and the drop are a mild breeze compared to self-modifying and sub-symbolic Machine Learning (ML).

Reviews by humans

You can hardly get away without ML in today’s AI. It would be like a mainstream relational DB without SQL, or like a rule engine without declarative rules. And, you’ll run into auditability issues in all three, but they tend to be an order of magnitude bigger in “sub-symbolic” ML. It’s much easier to check whether the learning works accurately (a black-box test of a “black organism” ), than to see why or how. A clear-box view relates to the generated logic almost as loosely as an MRI-scan relates to what a patient is thinking.

Japanese industry robots started to assemble robots back in 2001. Today, robotics vendors offer complete lights-out manufacturing systems (in other sectors referred to as “no man in the loop” earlier). So, needless to say, auditability and reviews by humans are a key architectural issue. Be discrete precision manufacturing, avionics, automotive, power generation, medical equipment, or any other application where approval criteria (ISO etc.) are strict.

Decision-tree induction from data

 When the work of professor DonaldMichie (a distinguished codebreaker ahead of D-day) resulted in the first ML algorithms for rule mining and decision-tree induction from data, those were able to show the learnt-in logic as diagrams or rules, and even to generate conditional constructs in a mainstream programming language. This became particularly useful in the elicitation and processing of tacit knowledge (the implicit “knowwhy” underlying the explicit knowhow of a human).

Many IT roles are quite familiar with declarative rules, although in narrower contexts: In DB schemas (or UML models), the rules are typically about referential integrity along the lines of “on Delete cascade” in SQL DDL (see also the exclusive-or, {xor} , in the UML diagram). In design, rules are often invariants and preconditions/postconditions. In modeling, a UML state diagram defines visually the rules that govern event handling and state transitions. Etc.

A role model, UML pun intended, with an either-or referential integrity.

From Informator course AvanceradModellering, T2716 (structure-models chapter). 

Case Bases

The technology that followed in inductive ML (after decision-tree induction), Case Based Reasoning (CBR), was instance-based and used lazy generalization which expressed the induced commonalities (between cases in the learning-data set) only later, at test time. Although less explicit than decision trees or rules, this was still fairly comprehensible for humans to review.

Sub-symbolic “representation” of knowledge

However, the commercial breakthrough of self-modifying technologies, mainly neural networks and evolutionary algorithms, made audits both hot and tricky. In a neural network, the logic learnt during training is sub-symbolic, “packed” into weight values on connections and artificial neurons. Roughly speaking, a clear-box view relates to the generated logic almost as loosely as an EEG record relates to what a patient is thinking.

Therefore, many researchers argue that audit-related abilities of a subsymbolic-ML system, like reasoning about itself and meaningfully visualizing/animating/explaining its logic or its conclusions, improve greatly when its ML is combined with other (likely symbolic) AI techniques. If so, this is one of the rare cases in architecture where complexity and testability actually enhance each other rather than restrict.

     

Summing up

Architecture is not exempt from ML’s impact on AI, IT, and business processes. Although auditability was brought to the table already when robots started to assemble other robots, it is crucial today in all kinds of ML systems in a vast variety of applications and industry sectors.

by Milan Kratochvil

Trainer at Informator, senior modeling and architecture consultant at Kiseldalen.com, Advanced UML2 Professional (OCUP cert level 3/3). Main author: UML Extra Light (Cambridge University Press) and Growing Modular (Springer).

Milan and Informator collaborate since 1996 on architecture, modelling, UML, requirements, analysis and design. In the next couple of months, you can meet him at Architecture ( T1101 , T1430, in English or Swedish) or Modeling courses ( T2715, T2716 , mostly in Swedish).

Läs mer

Så hittar du flow i jobbet

Har du någonsin upplevt att hur något du gör fångar just din totala uppmärksamhet, att du känner flyt? Du glömmer både tid och rum - du är i din bubbla. Du har full kontroll över vad som händer och du skulle kunna hålla på hur länge som helst. Om ja, då har du fått uppleva det som inom psykologin kallas  flow.

Flow i arbetet är något som många av oss önskar kunde ske bara vi knäppte med fingrarna. Riktigt så enkelt är det inte. Men vad är det då som triggar fram flow i jobbet?

För dig som inte är bekant med flow så är det ett begrepp som används mest inom psykologin. Det är ett tillstånd som sker när människan sjunker helt in i en aktivitet och går bortom sin reflekterande självmedvetenhet samtidigt som den får en djup känsla av kontroll.

Första gången jag hörde ordet flow var under en presentation på mitt första jobb där jag jobbade som testare. Presentationen hölls av en kille som gång på gång upprepa ordet flow och berättade om hur flow kan uppstå i arbeten. Efter hans presentation bestämde jag mig för att få till ”flowet” i mitt arbete och började jobba effektivt med rätt fokus på de testfall som då skulle testas… Det gick sådär!

Nu, några år senare och några projekt mer erfaren har jag annan uppfattning av begreppet än vad jag hade som en nyexaminerad testare. För mig handlar det mest om att ha de rätta kunskaperna. Vi kan uppleva flow när vi får möjlighet att använda en hög grad av våra färdigheter i utmanande situationer. Balansen måste finnas där och det spelar ingen roll vilket yrke det handlar om.

Utmanande uppgifter där man inte har tillräckliga färdigheter kan ge stress och ångest samtidigt som det kan leda till tristess och minskat engagemang när du har färdigheterna, men inte tillräckligt utmanande arbetsuppgifter. Därför krävs det balans.

Så, vad krävs för att få  flow i arbetet då?

Svaret är enkelt: Ha den rätta kompetensen och färdigheten och att låta de komma till användning i arbetet. Det krävs även ett gott socialt klimat, det vill säga tillit i arbetsgruppen samt möjligheter till samarbete och nytänkande. Flowet uppstår egentligen av den starka drift vi människor har, att med egen förmåga kunna ta oss an en utmanande uppgift. Vi vill uppleva den eufori som flow kan ge oss och vi kan inte uppnå samma eufori genom att bara upprepa något. Vi behöver större utmaningar. Vi drivs av att få lära oss nya saker och just därför är det väldigt viktigt att vi får utbildning och kunskap. När vi sedan får använda dem – då upplever vi flow!

Parinaz Sabzikar,

Test Engineer

Informator erbjuder flera spännande kurser inom Kravhantering och Testmetodik. Se alla våra kurser inom Krav och Test här

Läs mer

Är manuella tester stenåldern, eller?

Automatiserade tester gör framsteg inom många branscher, inte minst inom mjukvaruutveckling. Team ägnar mycket tid åt att utforska och automatisera majoriteten av sina tester för att säkerställa att de utförs effektivt och för att frigöra tid åt andra aktiviteter. Med alla dessa fördelar, ställer sig många frågan: Är manuell testning fortfarande nödvändigt? Det rungande svaret är JA. Testautomatisering är en stor tillgång, men det finns fortfarande mängder av områden där manuell testning är bäst lämpad att användas.

Manuell testning är ett snabbt sätt att utvärdera en produkt samtidigt som den ger testaren chansen att stifta bekantskap med de funktioner som skall verifieras och kvalitetssäkras under utvecklingsprocessen. Manuell testning i sig är en form av utforskande testning, vilket gör att testaren med tiden förutom att lära dig mer om själva testobjektet, även förstår svagheter och kan identifiera riskområden som eventuellt behöver täckas med fler testfall.

Automatiserade tester kan exempelvis inte exakt tyda en app eller funktion från en användares perspektiv eftersom den enbart består av förinställda villkor. Mänskliga testare klarar däremot av att titta på helhetsbilden, bedöma om en användare kommer att ha en positiv eller negativ upplevelse av appen eller funktionen. Detta inkluderar det estetiska utseendet, användbarhet och funktionalitet. När defekter inte hittats av automatiska tester, så betyder det inte att allt fungerar som förväntat. Om till exempel en app saknar vissa funktioner som användarna behöver för att slutföra sina uppdrag, så är risken att användarna överger appen för en annan som har just önskade funktionerna. Manuell testning kan enkelt upptäcka dessa typer av avvikelser och eliminera dem före release.

Här är några exempel på områden där manuella tester är mest lämpade:

• Automatiserade testverktyg klarar inte av att bedöma färg, typsnitt eller bildstorlek. Det går inte heller att testa användarupplevelse samt användargränssnitt (GUI) med automatiserad testning.

• Under utvecklingsfasen är det vanligt att akuta situationer uppstår på grund av kravändringar eller problem som kräver snabba förändringar i funktionalitet eller beteende i modulen. I dessa fall spelar tiden för rättningsverifieringen och snabb feedback en mycket viktig roll. Automatiska tester tar mer tid att ställa om, eftersom testare först måste skapa testfall, programmera till det automatiserade verktyget, och sedan köra testerna. Det kan vara mer tidskrävande att bibehålla och ändra automatiserade skript än att utföra testerna manuellt. Manuell testning i dessa fall innebär snabbare testning och resultat.

• Manuell testning är det enda alternativet under det inledande skedet av produktutvecklingen. Det är först när produkten är stabil och i regressionsfas som automatiserade tester kommer till sin rätt. Automatiserade tester i en fas med många förändringar tenderar att orsaka onödiga kostnader i både tid och resurser, eftersom det krävs extra arbete för att anpassa testprogrammen efter förändringarna. Dessutom har det observerats att de flesta ”bra och viktiga” defekter oftast hittas via manuella tester (dvs utforskande tester). Testautomatisering kan inte ersätta en erfaren och domänkunnig testare när det kommer till att hitta viktiga produktbuggar.

• ”Negativa” tester (Negative testing) kan göras mer rigoröst via manuell testning.

• Ad-hoc tester kan inte utföras av automatiska tester.

• När ett enskilt testfall tillhörande en automatiserad testsvit få ett ”negativ” resultat så stoppas hela testsvitet på grund av resultatet. I en manuell testsvit så kan testaren ofta hitta ett sätt att kringgå felet (en ”workaround”) och testa vidare. Det vill säga - det är mer flexibilitet i manuell testning.

Manuell testning är alltså fortfarande viktig inom flera områden. Kan det då gå hand i hand med automatiserad testning? Absolut, men det resonemanget får vi ta en annan gång.

Chithanh Mach, 

Test Engineer

Informator erbjuder flera spännande kurser inom Kravhantering och Testmetodik. Se alla våra kurser inom Krav och Test här

Läs mer

Fredagsfix och andra fienden till framgångsrik testautomatisering

Automatisering av testfall är en av inneaktiviteterna i mjukvarubranschen just nu, men samtidigt är det inte ovanligt att höra uttalanden som "Vi testade att automatisera, men det fungerade inte" eller "Vi har lite automatiserade tester, men vi använder dem inte för de går sönder hela tiden". Måste det bli så här? Naturligtvis inte. Här kommer några viktiga checkfrågor. De kan låta självklara, men vara nog så viktiga att påminna sig om emellanåt.

1. Går det att automatisera det du vill testa?

Första frågan som bör ställas är så klart om det överhuvudtaget går att testa det du vill säkerställa på ett bra sätt. Är det ett API eller ett UI som ska testas så är det oftast lugna puckar, men hur testar du till exempel att videon som strömmas till användaren inte hackar eller ser dålig ut? Visst kan man kolla bit rates och jämföra olika frames och annat, men frågan är: Är insatsen som behövs värd besväret, eller blir det effektivare att fortsätta testa hela eller delar av testbasen manuellt?

2. Är testobjektet tillräckligt stabilt?

Hur mycket kommer gränssnittet att förändras under projektets gång? Ska du testa ett redan publicerat API? Go for it! Ska du testa ett UI vars arkitekt bestämmer sig för ett nytt utseende varje vecka? Glöm det! Manuella testare är oftast både anpassningsvilliga och luttrade efter många projekt med luddiga och föränderliga kravspecar, men ett testramverk är ytterst bokstavstroget. En knapp som har flyttats eller bytt namn löser testaren för det mesta med ett höjt ögonbryn, medan det automatiska testfallet får krupp och vägrar fortsätta. Dessutom krävs det varje gång en inte obetydlig insats för att rätta till de tester som gått sönder.

3. Automatiserade testfall kräver tid till underhåll!

Detta för oss osökt över till nästa punkt på listan: Det går inte att tro att man kan lägga en stund på att automatisera sina testfall och att man sen bara behöver exekvera dem för all framtid. Testfallen behöver underhållas kontinuerligt om inte ansträngningen för att laga dem ska bli för stor, vilket leder till att ramverket faller ur bruk och lika gärna kan slängas. Alltså kan man inte allokera 100% av resurserna till att utveckla nya testfall eller att exekvera manuella testfall - det kommer att straffa sig i längden!

4. Kan det återanvändas? Gör det!

I alla mjukvaruprojekt är underhållbarhet superviktigt. Men i automatiseringsprojekt där det ofta är förhållandevis få resurser som ska lösa allt från att skriva nya och underhålla gamla testfall till att utveckla testramverket och att rapportera resultat, så är det ofta kritiskt. Är klockan 16 på en fredag och utvecklarna har precis släppt ett antal API-förändringar som ska testas i helgen? Vill du behöva ändra på ett ställe i en utility-fil eller i alla dina 500 testfall? Trodde väl det...

Är de nödvändiga förändringarna i ramverket så stora att de tar dagar att fixa, så är antingen projektet blint för mjukvarans kvalitet eller så upptäcks inte regressioner när de kommer in. Detta innebär ofta att det tar minst lika lång tid att uppdatera ramverket som det tar att reda ut orsakerna till alla nya fallerande testfall. Dessutom kan personer som är upptagna med underhåll inte användas till att skriva nya testfall.

5. All makt åt integratörerna!

Naturligtvis går det att undvika mycket av dessa problem om man har processer på plats för att 1) förvarna testutvecklarna om att förändring är på gång så att de kan uppdatera ramverket i tid och 2) slänga ut eventuella förändringar som förstör testresultaten. Har man dedikerade integratörer så är dessa ofta bra personer att stå på god fot med som testare. De har koll på vad som är på gång och de vet ofta vad som troligtvis orsakar problem, speciellt om det är ett continuous integration-system där testautomatiseringen är inbakad i integrationsmiljön. Har intergatörerna makt att inte ta in eller slänga ut dålig kod eller kod som innehåller beteendeförändringar som inte rapporterats i förväg och inte ständigt blir överkörda av ivriga projektledare eller produktägare, så kan detta gå väldigt smidigt och kvaliteten över tid blir ofta hög. Är leverans NU det viktigaste, så får projektet räkna med att det uppstår luckor i testtäckningen och att kostnaderna för underhållet ökar.

6. Testa testkoden! Eller: Ändra aldrig något viktigt på en fredag...

Tyvärr är det ju inte bara utvecklarna av produktionskod som kan slå sönder ett testramverk, även testutvecklarna själva brukar vara bra på detta. Speciellt problematiskt brukar detta bli om man "bara" ska ändra "den där lilla grejen som inte påverkar något annat" en fredag eftermiddag eller strax innan man kör igång den där kritiska testsviten innan leverans. Det slutar ofta med gråt och tandagnisslan.

Att testare orsakar instabilitet brukar tyvärr också resultera i att utvecklarnas och projektets förtroende för testresultaten minskar drastiskt och ofta under en lång tid.

Är resultaten kritiska för projektet? Se då till att 1) testa och granska alla förändringar i testramverket ordentligt innan de kommer i produktion och 2) gör inga kritiska förändringar i till exempel centrala delar i ramverket precis innan några extra viktiga tester ska köras. Jag hoppas att jag inte har skrämt bort alltför många med mina exempel på allt som kan gå fel... Det viktiga är att du ser på testutveckling på samma sätt som du ser på utveckling av produktionskod. Då kommer säkert även ditt projekt att bli ett lyckat exempel på testautomatisering!

Informator erbjuder flera spännande kurser inom Kravhantering och Testmetodik. Se alla våra kurser inom Krav och Test här

/Daniel Johansson, Test Automation Engineer

Läs mer

Testetik – vem har ”samvete” som sin arbetsuppgift?

Vi satt ett gäng testare och utvecklare vid en lunch och kom att prata om Volkswagens ”innovativa” lösning på problemet att få en motor att - enligt testprotokollet - vara både miljövänlig, högpresterande och bränslesnål.

Med de system som finns runt motorstyrning kan man få samma motor att uppfylla alla ovanstående kriterier, men inte på samma gång. Tydligen. Ökar man kväverening så ökas bränsleförbrukning och utsläpp av koldioxid. Tricket är att ge styrsystemet information om vilka tester som körs och optimera prestandan därefter, för att få motorn att passera testinstitutets nålsöga.

Vi funderade hur tankegångarna gått i de tyska ordningsamma korridorerna och hur utvecklare och testare funderat. Var det enbart en fråga om tolkningsbara formuleringar i kraven som ställts av testinstitutet? ”Kväveutsläpp vid stadskörning får inte överstiga X, bränsleförbrukning vid stadskörning får inte överstiga Y”. Men dessa två gränsvärden behöver inte uppfyllas samtidigt, eller? Fastän alla inblandade, med stor sannolikhet, förstod syftet och andemeningen med miljöcertifieringen, var det kanske möjligt att tolka kraven som man ville och skriva kod som styrde motors prestanda till sin fördel.

Om vi som testare får en lista med krav att validera och en del prestandatester att utföra: är det då vår uppgift att ifrågasätta huruvida funktionerna som testas är moraliskt försvarbara? Enligt de specifikationer och User Stories som givit oss fungerar allt perfekt. Men sen då? Borde utvecklarna och testarna reagera och påpeka det omoraliska och oetiska i att ”lura” systemet?

Frustrerad över att jag inte visste hur jag själv borde agera om jag skulle hamna i en liknande situation, började jag febrilt leta efter ”etik och ansvar” i alla ISTQB Syllabi (1). Jag sökte riktlinjer, stöd och råd. I Foundation Syllabus hittade jag en halv sida ”Code of ethics”. Där beskrivs (om än väldigt teoretiskt och övergripande) 8 områden att ta hänsyn till i sitt dagliga arbete.

De två första områdena är:

- Public – Certified testers shall act consistently with the public interest.

- Client and employer – Certified software testers shall act in a manner that is in the best interests of their client and employer, consistent with the public interest

Borde utvecklaren och testaren på VW ansett att kundens behov (en kod med avsikt att lura testinstitutens system) inte var i enlighet med ”Public interest”? Borde de ha vägrat att ta uppdraget? Skulle de gått till pressen? Man ska ju dessutom ha klientens eller uppdragsgivarens intressen i fokus.

Så hur slutade då lunchdiskussionen (som för övrigt sträckte sig längre än en lunch)? Vi kom fram till att:

- Det är inte enbart utvecklarens eller testarens ansvar eller uppgift att agera ”samvete”. Detta måste även komma långt tidigare i processen, från beslutsfattare högre upp. Kanske har utvecklare och testare inte kännedom om hela bilden och bakgrunden till alla beslut som tagits på vägen.

- Om du träffar på något som du anser vara oetiskt eller omoraliskt, påpeka detta skriftligen till din närmaste chef eller projektledare. Detta förhindrar kanske inte att programvaran kommer ut, men du har i alla fall påpekat något du tyckte var suspekt. Dessutom har du ryggen fri om en skandal är i annalkande.

Men detta var ju bara lunch-funderingar, från enstaka personer som inte var insatta i problemet, lösningen eller eventuella lagkrav som inte uppfyllts. Hur man ska agera beror troligen på många olika faktorer, olika från fall till fall, samt allvarlighetsgraden av konsekvenserna av det etiska ”övertrampet”. Och naturligtvis din egen moral och gräns för var etiska övertramp går. Det är lätt att beskriva vad man ska göra i teorin, men när verkligheten knackar på dörren blir allt mycket svårare.

Kanske är det därför ISTQB inte berör ett så svårt och känsligt ämne mer i detalj?

Förhoppningsvis har flera etik-diskussioner än vår ägt rum i fikahörn och konferensrum de senaste månaderna, till följd av avslöjandet av VW:s fadäs. Det är i så fall något positivt som denna ”etik-tsunami” drog med sig i svallvågorna!

Informator erbjuder flera spännande kurser inom Kravhantering och Testmetodik. Se alla våra kurser inom Krav och Test här

/Mikael Sten. 

Test Engineer 

Läs mer

Testetik – vem har ”samvete” som sin arbetsuppgift?

Vi satt ett gäng testare och utvecklare vid en lunch och kom att prata om Volkswagens ”innovativa” lösning på problemet att få en motor att - enligt testprotokollet - vara både miljövänlig, högpresterande och bränslesnål.

Med de system som finns runt motorstyrning kan man få samma motor att uppfylla alla ovanstående kriterier, men inte på samma gång. Tydligen. Ökar man kväverening så ökas bränsleförbrukning och utsläpp av koldioxid. Tricket är att ge styrsystemet information om vilka tester som körs och optimera prestandan därefter, för att få motorn att passera testinstitutets nålsöga.

Vi funderade hur tankegångarna gått i de tyska ordningsamma korridorerna och hur utvecklare och testare funderat. Var det enbart en fråga om tolkningsbara formuleringar i kraven som ställts av testinstitutet? ”Kväveutsläpp vid stadskörning får inte överstiga X, bränsleförbrukning vid stadskörning får inte överstiga Y”. Men dessa två gränsvärden behöver inte uppfyllas samtidigt, eller? Fastän alla inblandade, med stor sannolikhet, förstod syftet och andemeningen med miljöcertifieringen, var det kanske möjligt att tolka kraven som man ville och skriva kod som styrde motors prestanda till sin fördel.

Om vi som testare får en lista med krav att validera och en del prestandatester att utföra: är det då vår uppgift att ifrågasätta huruvida funktionerna som testas är moraliskt försvarbara? Enligt de specifikationer och User Stories som givit oss fungerar allt perfekt. Men sen då? Borde utvecklarna och testarna reagera och påpeka det omoraliska och oetiska i att ”lura” systemet?

Frustrerad över att jag inte visste hur jag själv borde agera om jag skulle hamna i en liknande situation, började jag febrilt leta efter ”etik och ansvar” i alla ISTQB Syllabi (1). Jag sökte riktlinjer, stöd och råd. I Foundation Syllabus hittade jag en halv sida ”Code of ethics”. Där beskrivs (om än väldigt teoretiskt och övergripande) 8 områden att ta hänsyn till i sitt dagliga arbete.

De två första områdena är:

- Public – Certified testers shall act consistently with the public interest.

- Client and employer – Certified software testers shall act in a manner that is in the best interests of their client and employer, consistent with the public interest

Borde utvecklaren och testaren på VW ansett att kundens behov (en kod med avsikt att lura testinstitutens system) inte var i enlighet med ”Public interest”? Borde de ha vägrat att ta uppdraget? Skulle de gått till pressen? Man ska ju dessutom ha klientens eller uppdragsgivarens intressen i fokus.

Så hur slutade då lunchdiskussionen (som för övrigt sträckte sig längre än en lunch)? Vi kom fram till att:

- Det är inte enbart utvecklarens eller testarens ansvar eller uppgift att agera ”samvete”. Detta måste även komma långt tidigare i processen, från beslutsfattare högre upp. Kanske har utvecklare och testare inte kännedom om hela bilden och bakgrunden till alla beslut som tagits på vägen.

- Om du träffar på något som du anser vara oetiskt eller omoraliskt, påpeka detta skriftligen till din närmaste chef eller projektledare. Detta förhindrar kanske inte att programvaran kommer ut, men du har i alla fall påpekat något du tyckte var suspekt. Dessutom har du ryggen fri om en skandal är i annalkande.

Men detta var ju bara lunch-funderingar, från enstaka personer som inte var insatta i problemet, lösningen eller eventuella lagkrav som inte uppfyllts. Hur man ska agera beror troligen på många olika faktorer, olika från fall till fall, samt allvarlighetsgraden av konsekvenserna av det etiska ”övertrampet”. Och naturligtvis din egen moral och gräns för var etiska övertramp går. Det är lätt att beskriva vad man ska göra i teorin, men när verkligheten knackar på dörren blir allt mycket svårare.

Kanske är det därför ISTQB inte berör ett så svårt och känsligt ämne mer i detalj?

Förhoppningsvis har flera etik-diskussioner än vår ägt rum i fikahörn och konferensrum de senaste månaderna, till följd av avslöjandet av VW:s fadäs. Det är i så fall något positivt som denna ”etik-tsunami” drog med sig i svallvågorna!

Informator erbjuder flera spännande kurser inom Kravhantering och Testmetodik. Se alla våra kurser inom Krav och Test här

/Mikael Sten. 
Test Engineer 

Läs mer

Sagan om projektledarkråkan som skulle ut och åka

Detta är sagan om projektledarkråkan som skulle ut på en resa med sitt projekt men inte hade någon som styrde över kvalitetsaktiviteterna. 

Projektledaren kan vi kalla Håkan för enkelhetens skull. Håkan hade varit med i gamet ett tag och kände att han hade koll på hur projekt skulle bedrivas. Dessutom var han omgiven av väldigt kompetenta utvecklare, enligt sin egen mening. Detta innebar att Håkan inte hade mycket till övers för olika aktiviteter för att säkra kvaliteten. Det brukade ändå lösa sig på slutet då man körde igenom några testfall för att se att saker och ting snurrade. Håkan hade nyligen läst om Scrum och fann det tilltalande att arbeta på detta sätt eftersom man då snabbt kunde komma igång och producera kod istället för att ha långa diskussioner med kunden. Det kunde man lösa på vägen helt enkelt förstod han, efter att ha läst om lyckade projekt på nätet.

Projektet drog igång och man hade arbetat med kunden Kurt tidigare. Därför ansåg man att man hade en bra uppfattning om vad Kurt ville ha. Dessutom kunde Kurt vara ganska obeslutsam så man var inte så intresserad av att sitta i en massa möten med honom och diskutera krav. Man skulle köra Scrum och då skulle det lösa sig på vägen. Några av utvecklarna hade också läst en del om agil utveckling och fastnade för att sätta upp en automatiserad byggmiljö och man producerade även ett antal automatiserade testfall som skulle köras när man gjorde ett nytt bygge. Tyvärr hade man lite svårt att få dessa testfall stabila och de uppdaterades inte efterhand som koden förändrades. Efter ett tag blev det att man helt enkelt inte exekverade dem.

Samma sak hände med morgonmötena. Det kom egentligen inte upp något speciellt och alla hade koll på vad de skulle göra så man tyckte helt enkelt att det var bättre att lägga denna tid på att producera kod. Tanken var även att Kurt skulle vara med på demonstrationerna men eftersom han hade fått mer ansvar var han tvungen att resa ganska ofta vilket förhindrade honom att delta på dessa. Håkan löste detta genom att även ta på sig rollen som produktägare eftersom han ju visste vad Kurt egentligen ville ha.

Det rullade på och dagen för leverans närmade sig och man började köra lite manuella tester i sin utvecklingsmiljö. Håkan tyckte det såg bra ut även om det fanns några små konstigheter om man gjorde saker som man inte borde göra med systemet. Med andra ord skulle det lösa sig. Systemet levererades till Kurt som tillsammans med några kollegor började acceptanstesta systemet i sin produktionsmiljö. Det Kurt såg gjorde honom inte glad. Vissa funktioner fanns inte med, det fanns saker som han inte förstod varför de fanns med, prestanda och tillförlitlighet var under all kritik samt att en av de viktigaste punkterna, användbarheten, var helt förbisedd. Projektet hade kört rakt ner i kvalitetsdiket!

Håkan skyllde på Kurt att han inte hade varit tydlig eller närvarande i projektet medan Kurt skyllde på Håkan för att han inte hade lyssnat och kört projektet på sitt eget sätt. Det ingen av dem såg var att det inte fanns någon som styrde test- och kvalitetsarbetet när projektledarkråkan skulle ute och åka...

Sensmoralen från denna saga är att det inte bara går att läsa något på nätet och sedan tro att man kan implementera det rakt av och få det att snurra. Det vi ser idag är att både mer traditionella projekt och agila projekt kör i diket på grund av att många projektledare och beslutsfattare inte har förståelse för varför test och andra kvalitetssäkringsaktiviteter behövs och hur dessa skall genomföras på bästa sätt, beroende på vilken utvecklingsmodell man har valt.  Det krävs utbildning, kunskap och erfarenhet om man vill undvika detta!

Informator erbjuder flera spännande kurser inom Kravhantering och Testmetodik. Se alla våra kurser inom Krav och Test här

Dr. Magnus C. Ohlsson,
Quality Assurance Specialist

Läs mer

Historien upprepar sig när kunskapen inte finns

Åren går men problemen består skulle man kunna säga… I drygt tjugo år har jag mött företag med olika mognadsgrad med avseende på hur bra kontroll de har på sin mjukvaruutveckling. Problemen som har presenterats för mig har inte varierat allt för mycket och det som till en början gjorde mig en aning chockad visade sig senare bara vara en indikation på den resa som väldigt många företag gör och har gjort under dessa år. Från att själv har gjort en lång kunskapsresa under många år på universitetet var detta också resan där dessa företag antingen hade samlat på sig kunskap aktivt eller lärt sig av sina misstag.

När jag började arbeta som konsult i början av 2000 fick jag möjlighet att samarbeta med en erfaren kollega som lärde mig många saker om test och testarbete, en sann mentor. Tillsammans var vi ute hos ett antal företag och gjorde processutvärderingar med fokus på hur man bedrev sin testverksamhet. Dessa uppdrag och diskussionerna vi hade lärde mig oerhört mycket och gav mig erfarenheter som är applicerbara än idag. Åren gick och jag lämnade konsultbranschen för att arbeta som chef på både mindre och större företag. På dessa företag bedrev vi även processförbättringsprojekt i varierande grad beroende på hur mogna företagen var. Efter några år var jag sedan tillbaka i konsultbranschen igen och första uppdraget var att göra en processutvärdering.

Efter att ha genomfört de första intervjuerna började jag se ett mönster. Ett mönster som jag kände igen allt för väl från de första åren som konsult. Problembilden var den samma då som förr så min fråga var om det inte hade hänt mer på de tio år som hade passerat? Jag började fundera på att leta fram en gammal rapport och göra en ”sök-ersätt” på företagsnamnet och krydda med några citat om problem med att få ordning på den agila utvecklingen och på så sätt göra det enkelt för mig. Nu blev det inte så utan arbetet med en djupgående analys inleddes och genomfördes. Rapporten blev omfattande och kunden var nöjd med resultatet, både analysen och den handlingsplan vi lade fram.

Under resans gång funderade jag väldigt mycket på varför det inte hade hänt mer på dessa tio åren. Slutsatsen blev att det har hänt massor av saker och att många företag har utvecklats och blivit mognare. Jag kom också till insikten att under dessa år hade det tillkommit flera företag som inte har mjukvaruutveckling som sitt primära eller ens sekundära levebröd. Exempelvis handlar det om företag där man utvecklat vissa stödsystem ute i de olika affärsenheterna och sedan beslutat sig för att ta bilda en IT-enhet eller företag vars produkter har utvecklats mot att bli mer och mer beroende av mjukvara runtomkring. Min insikt var att det saknades kompetens om vad test och aktivt kvalitetsarbete innebär och att man också hade inställningen att man kan själv och därför sprang på mina efter mina.

Min uppfattning är att dessa företags resa hade både blivit billigare och enklare om man hade tagit ett helhetsgrepp om kompetensutvecklingen satsat på att utbilda sin personal på olika nivåer i organisationen om vad test och kvalitetssäkring innebär. Detta oavsett om man arbetar traditionellt eller mer agilt. I början av 2000 fanns det tyvärr inte så många utbildningar inom området men idag finns det ett betydligt större utbud som bör passa både mindre och mer mogna organisationer för programvaruutveckling. Om inte så skulle vara fallet så går det alltid att skräddarsy en utbildning för de speciella krav en organisation kan ha eller anpassa till exempel övningar till internt material.

En av de viktigaste aspekterna med att gå en kurs är, både enligt mig själv och väldigt många kursdeltagare, mötet med andra personer oberoende av om det är personer från en annan avdelning eller ett annat företag. Att få lyssna till andras problemställningar och erfarenheter är något som man inte får genom att läsa en bok hemma på sin kammare. De diskussioner man har på luncherna eller fikapauserna har en väldigt stor betydelse för att sätta in kunskapen i ett sammanhang. Det är också på kursen man kan få hjälp av en erfaren lärare att börja bena ut vad ens problem består av för att sedan koppla detta till kursinnehållet för att sedan komma tillbaka till arbetsplatsen utrustad med applicerbara förbättringsverktyg.

Har du påbörjat din kunskapsresa?

Skribent: Dr. Magnus C. Ohlsson

Informator erbjuder flera spännande kurser inom Kravhantering och Testmetodik. Se alla våra kurser inom Krav och Test här

Läs mer

En beagle till kaffet, någon?

En tidig höstmorgon för ett par år sedan åkte jag med fyrans spårvagn genom Göteborg. Lätt morgontrött satt jag på en av fönsterplatserna och lät blicken svepa lite förstrött över allt som råkade passera utanför rutan. I närheten av Korsvägen åkte vi förbi ett café. Precis innan vagnen svischade förbi hann jag läsa texten på markisen. Där stod att de erbjöd sallader, smörgåsar och beagles. Det tog en sekund eller två, men sedan vaknade testaren i mig ur sin behagliga morgonslummer. ”Beagles? Är inte det en hundras? Hm... Aha, vänta nu, de menar förmodligen bagels! Ja, så måste det vara.”

Människans hjärna är en fantastisk konstruktion med en alldeles speciell förmåga att kunna uppfatta mönster. Den här morgonen var min hjärna redan fullt sysselsatt med att registrera och bearbeta nya synintryck. Och inte nog med det. Den såg även till att jämföra de nya intrycken med den kunskap om världen som den redan hade. Det var här som den upptäckte en avvikelse från ett förväntat mönster och slog larm genom att lyfta fram informationen till en medveten tanke. Bara sådär.

Nedan kan du se ett grafiskt mönster med tecken ordnade i rader. Titta noga på mönstret och se om du kan upptäcka något som sticker ut!

oooooooooooooooooooooooooooo oooooooooooooooooooooooooooo oooooooooooooooooooooooooooo oooooooooooooooooooooooooooo oooooooooooooooooooooooooooo oooooooooooooooooooooooooooo ooooooooooooocoooooooooooooo oooooooooooooooooooooooooooo

Förhoppningsvis noterade du det annorlunda tecknet i mitten av den näst nedersta raden. Pröva samma sak med det här mönstret:

XOXOXOXOXOXOXOXOXOXOXOXOXOXO XOXOXOXOXOXOXOXOXOXOXOXOXOXO XOXOXOXOXOXOXOXOXOXOXOXOXOXO XOXOXOXOXOXOXOXOXOXOXOXOXOXO XOXOXOXOXOXOXOXOXOXOXOXOXOXO XOXOXOXOXOXOXOXOXOXOXOKOXOXO XOXOXOXOXOXOXOXOXOXOXOXOXOXO XOXOXOXOXOXOXOXOXOXOXOXOXOXO

Gissningsvis upptäckte du även här det udda tecknet utan några större svårigheter.

I båda fallen är det snabbaste sättet att lösa problemet förmodligen inte att läsa tecken för tecken. En bättre strategi är istället att luta sig tillbaka, avfokusera, blinka några gånger och sedan låta blicken svepa över mönstret i fråga. Pröva själv! Ser du hur de udda tecknen sticker ut från mängden?

Den här förmågan att hitta avvikelser i större datamängder är något som faktiskt går att dra nytta av som mjukvarutestare. Tekniken har till och med ett särskilt namn. James Bach och Michael Bolton (testaren, inte sångaren!) kallar den för blink testing. De beskriver den som något testare regelbundet gör. Faktum är att just testare ofta är väldigt skickliga på att upptäcka subtila skillnader där inga borde finnas, eftersom det kan visa på buggar i mjukvaran. Ta olika färgnyanser på olika skärmbilder till exempel, eller navigationselement som byter position och texter mellan olika sidor. Det är typiska fel som kan vara lätta att missa. Blink testing gör det möjligt att fånga dem.

Den här tekniken går att använda i andra lägen också. Till exempel för att snabbt bläddra igenom en lång loggfil och se om det dyker upp några textrader eller textblock som skiljer sig markant från den övriga texten i filen. Det kan ju vara ett tecken på att något ovanligt fel har inträffat och loggats. En annan möjlighet är att kika på innehållet i en katalog på hårddisken. Finns det filer med konstiga namn eller extrema storlekar? Då kan det ju vara något som en testare vill titta lite närmare på.

Blink testing är en heuristik. Med det menas att den ibland hjälper oss att lösa ett problem och ibland inte. Det beror på i vilket sammanhang vi använder den. Det finns inte heller några garantier för att vi upptäcker alla eventuella konstigheter. Däremot kan den hjälpa oss att upptäcka en del, och det är ju vackert så. Lägg den därför bland alla de andra teknikerna i din verktygslåda, och pröva den gärna nästa gång du ska blicka över en större mängd data. Lycka till!

Freddy Gustavsson har arbetat med test och kvalitetssäkring av programvara sedan 2001.

Informator erbjuder flera spännande kurser inom Kravhantering och Testmetodik. Se alla våra kurser inom Krav och Test här

Läs mer