AddQ Consulting

Verktyg eller värktyg?

Eleonore Hammare — Tue, 15 May 2012 07:14:34 +0000

IT-stöd i form av nya system eller verktyg efterfrågas ofta från olika organisationer för att få ordning på sin verksamhet, sina kunder, sin försäljning eller vad det nu kan vara. Ofta möts jag av önskningar från olika verksamheter där man efterfrågar ett IT-system eller verktyg som ska rädda en viss situation, organisera upp det som behöver organiseras eller bringa in kunderna trots att inte försäljningsavdelningen eller produkterna ska förändras.

Det är inte så konstigt att en potentiell IT-systemköpare låter sig förblindas av att allt skulle kunna lösas med rätt IT-stöd. I samband med presentationer av olika IT-stöd får vi ofta en redogörelse för alla funktioner och fantastiska resultat som kan uppnås med just detta IT-stöd eller verktyg. Vi möts också regelbundet av artiklar där olika goda exempel på företag som har valt ett specifikt systemstöd lyfts upp som undergörande för verksamheten. Att köpa system på grundval enbart av säljande Power Pointbild leder till besvikelse och det blir ett värktyg i stället för ett verktyg.

Att ha verktyg eller värktyg i verktygslådan gäller även hantering av test och krav på ett professionellt och effektivt sätt. Olika organisationer har kommit olika långt i sin mognad för olika typer av verktyg och processer för att hantera sin kvalitetssäkring av projekt och releaser. Men oavsett mognad bör alla åtminstone ha ett intresse för att sträva efter att använda väl etablerade verktyg för att hålla ordning på alla krav och testfall och resultatet av testerna. Avsikten är minska de manuella rutinerna och minska risken för att buggar missas eller processer får uppfinnas inför varje release.

Ett annat specifikt område som är intressant att belysa avseende verktyg och värktyg är de så kallade beslutsstöden. Med beslutsstöd i det här sammanhanget avser jag verktyg för business intelligent som till exempel kan omfatta marknadsanalys, omvärldsanalys, data mining, segmentering och konkurrensanalys. Det verkar finnas en övertro också på beslutsstöd. Finns beslutsstödet på plats så löser sig allt. Så enkelt är det sällan (eller aldrig). Om förutsättningarna är dåliga blir resultatet därefter och besluten likaså. Det är enklare att köpa ett verktyg än att bygga upp en organisation och förbättra processer.

Men för att uppnå ett bra resultat måste verktyg kombineras med effektiva processer, rutiner och kompetens. Och precis som i vilka IT-projekt som helst ska det finns en kravspecifikation även för ett test- och kravhanteringsverktyg.

Målet är att gå från värktyg till verktyg.

AddQ Consulting går in som delägare i Poosty.

Petter Salomonsson — Mon, 14 May 2012 07:00:25 +0000

PRESSMEDDELANDE: 2012-05-14

AddQ Consulting går in som delägare i Poosty – Lanserar marknadens enklaste tjänst för krypterad e-post.

Idag, måndagen den 14 Maj, lanserar Poosty sin tjänst för enkel och säker e-posthantering, där man redan nu har ett antal kunder inom privat och offentlig sektor. AddQ Consulting har kvalitetssäkrat mjukvaruplattformen och har samtidigt gått in som strategisk partner och delägare i företaget.

Att skicka och ta emot krypterad och säker e-post ska från och med idag blir avsevärt mycket enklare och snabbare. Med hjälp av Poostys nylanserade tjänst kan så väl företag som privatpersoner skicka ett krypterat e-postmeddelande inom 30 sekunder utan att behöva byta e-postadress eller installera några extra program. Tjänsten, som fungerar både på datorn, surfplattan och genom telefonen, har kvalitetssäkrats av test- och kvalitetsäkringsspecialisten AddQ Consulting, vilka även har gått in som strategisk partner och delägare i företaget.

Kvaliteten och säkerheten i vår tjänst är grunden för vår affär. Genom samarbetet med AddQ Consulting har vi lyckats ta fram en tjänst som möter alla de krav som finns på tillförlitlighet och säkerhet. Varken en försvarminister, advokat eller en privatperson ska kunna säga att de inte kunde skicka ett säkert e-postmeddelande längre. , säger Anders Jonson, VD på Poosty.

Kvalitetssäkringen av Poostys e-posttjänst har skett genom agil metodik och har inkluderat både strukturerad och explorativ testning. För att finansiera samarbetet har Poosty gett AddQ ett delägarskap i företaget.

Vi ser en ljus framtid för Poosty och är väldigt stolta över att ha gått in som strategisk partner och delägare. Genom att vi har kvalitetssäkrat tjänsten vet vi dessutom att den levererar den säkerhet, enkelhet och tillförlitlighet som den ska göra. , säger Petter Salomonsson, VD på AddQ Consulting.

För ytterligare frågor, vänligen kontakta:

Petter Salomonsson, VD på AddQ Consulting, 0708-398435.

(J)ästblogg: Surdeg, knäckebröd och småkakor

Eleonore Hammare — Mon, 07 May 2012 04:53:10 +0000

Det är trendigt att baka, både söta kakor och surdeg. Det är också trendigt med test. Så vad är inte mer naturligt än att ägna en blogg åt bakverk och test. Lättuggat och lättsmält eller mer tuggmotstånd? Vilken metod är bäst? Att testa surdegarna först och sedan gå på knäckebrödet för att avsluta med småkakorna? Eller att spara surdegen till sist, den kanske inte är lika jobbig då, eller den kanske till och med har försvunnit på något magiskt sätt. Olika metoder och teorier ger olika besked om vad som är bäst.

Målet med tester är att hitta så många fel som möjligt och gärna så tidigt så mycket så att rättningar hinner göras innan produktionssättning. Sedan finns det naturligtvis tester som inte kan tas i början, t.ex. regressionstester. Oavsett vilket så vill jag här ta några exempel från verkligheten på olika synsätt på vilken ordning kraven ska testas av.

En kombination av de olika kategorierna är ett lämpligt sätt att ta hand om respektive område som ska testas. Ha en bra struktur och överväg nytta av funktionen, komplexitet, svårighet och tidsåtgång för testerna. Jag har varit med om projekt där man varit fast övertygad om att (enligt RUP-teori) ta surdegarna först. Det vill säga de jobbigaste och mest komplexa områdena ska testas först för att sedan gå över till de mer lättsamma områdena. I projektet började testerna bra enligt denna modell men till slut blev det så tungrott att projektet fick blanda upp de komplexa testerna med mindre komplexa och lättare områden. Ett annat exempel som inte är helt ovanligt är att tiden i projektet inte räcker till och eftersom lanseringsdatumet är heligt är det lättare att korta av testtiden i projektet. Vilka tester prioriteras i sådana fall? Vanligtvis blir knäckebrödet och småkakorna som går igenom testerna medan surdegarna blir kvar.

Ett lite mer våghalsat exempel på ett projekt från verkligheten är där tidplanen var pressad och beslut fattades om att acceptanstesterna i princip skulle genomföras före systemtesterna. Jag kan meddela att även det projektet nådde i mål och systemets funktionalitet blev kvalitetssäkrat.

Oavsett hur testarbetet planeras ser jag det som viktigt att testplanen är iterativ. Det brukar skilja sig åt vilka områden som är viktigast i början av ett projekt jämfört med i slutet av ett projekt.

Ett sätt att ta sig an testplaneringen är att utgå från följande punkter (hämtade från Stefan Görling): Funktionalitet före stabilitet, Enskilda funktioners funktion snarare än kombinationerna av dem, De synliga funktionerna före de osynliga, De vanliga användningsfallen före de ovanliga.

Knäckebröd, småkakor eller surdegar, test alla sorter!

Har ni testat beslutsprocessen?

Eleonore Hammare — Fri, 04 May 2012 06:38:44 +0000

Test är ett mångfasetterat område och kan appliceras på i princip vad som helst. Det vanliga vi pratar om när det gäller test är testprocesser, testfall, testare och testledare, systemtest, modultest, regressionstest och acceptanstest. Men en stor del av ett IT-projekt handlar om beslut i olika lägen. Har vi någonsin testat hur beslutsfattandet går till? Är det kvalitetssäkrat? Vadå, hur menar jag nu? Vi har ju en projektledar, en testledare, en styrgrupp, en ledningsgrupp och en tydlig hierarki om vem som beslutar om vad. Javisst, men har vi testat om beslutsprocessen fungerar som tänkt? Antagligen inte.

Jag gick en gång en kurs i ledarskap där vi, precis som på de flesta ledarskapsutbildningar, skulle identifiera våra styrkor och svagheter utifrån några givna parametrar. Utgångsläget den här gången var huruvida man använder huvudet, hjärtat eller benen mest i sitt ledarskap (och beslutsfattande). Det vill säga; är man analytisk, känslomässig eller springer fort. Jag kan avslöja att jag själv hamnade i kategorin mycket huvud och långa ben, det vill säga snabbt analysera läget och kliva framåt för att uppnå resultat. Jag vill dock påpeka att jag inte var helt utan hjärta men att de andra styrkorna framträdde tydligare.
Min erfarenhet från olika organisationer och projekt är att de lätt fastnar, karaktärsmässigt, i att antingen tänka för mycket och därmed bli långsamma, andra springer för fort framåt utan att kvalitetssäkra, tänka eller känna och ytterligare några går enbart på känsla. Då är det inte så himla dumt att reflektera lite och faktiskt testa hur beslutsprocessen fungerar (eller inte fungerar). Besluten som fattas är lika viktiga som arbetet som utförs. Att inte fatta beslut är också ett sätt att besluta. Och då måste vi vara säkra på att den modell vi valt för att fatta beslut fungerar och är optimal för syftet.

Hur skulle då ett test av beslutsprocessen kunna gå till? En testledare håller ihop testet, kör igenom ett testfall med olika scenarios där olika personer ska fatta olika beslut. En del i ett sådant test skulle också kunna vara att gå igenom tidigare fattade beslut och utvärdera om de var bra eller inte och vad som skulle kunna förbättras till nästa gång. Vet vi att en organisation är mer ben än hjärta så kan vi agera utifrån det förhållningssättet. Det handlar om att känna till sina styrkor och svagheter och använda dem på bästa sätt och stärka upp där man har sina svagheter. Alla personligheter behövs i projektet och i beslutsprocessen. Sammanfattningsvis blir det viktigaste i testet av beslutsvägarna att se så att alla dessa delar finns med och får utrymme i de olika forumen där beslut fattas. Då höjer vi kvaliteten i helheten även i beslutsprocessen. Test ur ett nytt perspektiv! Jag vill gärna ta del av erfarenheten från den som genomför detta test.

Agila metoder i vardagen.

Johan Bergström — Mon, 30 Apr 2012 08:57:38 +0000

Agila metoder i vardagen.

Inspirerad av Maria Jönssons inlägg här på AddQ-bloggen i januari och en känd mäklarfirmas slogan ” Vi bara testar lite, gör det du med” så har jag faktiskt kommit på mig själv med att testa lite även i min vardag.

Den första riktiga test som gjordes var när badrummet skulle renoveras i det radhus jag snart skulle flytta in i. Jag hade inte möjlighet att vara där hela tiden och jag bodde inte i huset för tillfället så jag kunde inte se framstegen dag för dag, jag var dessutom mitt uppe i en hektisk fas på uppdraget så jag hade ingen möjlighet att kommunicera med hantverkarna på dagtid. Badrummet var inte speciellt stort så alla hantverkarna hade andra jobb parallellt och varje delmoment hos mig var ganska litet så det var inte lönt att kontraktera dem på heltid.

Lösningen blev en Scrum board för hantverkarna. Jag började med ett sprint planeringsmöte med alla hantverkarna. Det var en snickare, en rörmokare en elektriker och en plattsättare som alla fick redogöra för vilka delmoment de var ansvariga för och ungefär hur lång tid varje moment skulle ta. Varje åtgärd som skulle göras fick en post-it lapp som sorterades så att alla moment kom i rätt följd. När arbetet drog igång så flyttade varje hantverkare lappen han jobbade med till pågående eller klar. Om lappen flyttades till klar så ringde han till nästa gubbe i kedjan och meddelade att nu var det dags att för honom, i och med att alla var med på sprint planeringen och hade ett hum om hur lång tid varje moment skulle ta så hade nästa gubbe redan grovt planerat in i sin kalender när han skulle göra vad. Hantverkarna tyckte det var en kul idé och att det funkade riktigt bra. Projektet blev visserligen lite försenat men bara med två timmar och det var helt acceptabelt.

Nästa tillfälle blev att utforskande testa laguppställningar i 7-manna fotboll i Sanktan för Täby United pojkar 00. Vi har nyligen slagit ihop två lag så en hel del för mig nya killar har tillkommit och jag har därför blivit tvungen att utforskande testa spelare på olika positioner. En reflektion efter två matcher är att när killarna får spela på en för dem ny position så skärper dem sig lite extra och är mycket mer fokuserade. Även om en del misstag sker på grund av osäkerheten i och med den nya positionen så övervägs det av den ökade skärpan så misstagen blir nog faktiskt färre än tidigare.

En ny utbyggnad på tidigare nämnda hus är planerad till hösten vilket är ett ännu större projekt än badrummet så det ska bli kul att se om hantverkarna även denna gång kan var lite agila, så varför inte testa lite igen.

Utforskande testmetodik – xBTM stämplad OK av James Bach

Michael Albrecht — Mon, 16 Apr 2012 04:23:45 +0000

Tillsammans med James Bach, en av grundarna för SBTM och TBMT, har AddQ gått igenom sin kurs Utforskande Testmetodik – xBTM.

Kursen som AddQ håller innehåller delar av SBTM, TBTM och självklart sammanslagningen xBTM.

James tycker att AddQs vidarutveckling av tidigare kända tekniker är imponerande. Han uppskattar verkligen när bra tekniker kombineras och förädlas som i fallet med xBTM där modellbaserad testdesign är en stor del.

Kort om utvecklingen av SBTExecute

Per Almström — Thu, 12 Apr 2012 13:34:43 +0000

Vi skjuter ju både högt och lågt på den här bloggen, och idag tänkte jag rikta pipan nedåt och ta med er på en tur bakom kulisserna och berätta lite om vårt verktyg för stöd av sessionsbaserad testning, SBTExecute, som florerar här på sidan med jämna mellanrum.

Utöver mitt vanliga dagsverke som konsult arbetar jag med att vidareutveckla SBTExecute utifrån önskemål om ny funktionalitet eller ändringar som kommit fram antingen från oss på AddQ eller från er som använder verktyget ute i vardagen. Vi presenterar verktyget framförallt som exempel och stöd till vår kurs i ”Utforskande testmetodik – xBTM”, men är förstås väldigt glada att det även används av andra testare där ute som vill komma igång med utforskande testning och har ett behov av att planera och strukturera sina tester samt redovisa en sammanställning av testresultaten.

(på bilden: Johan Bergström och Michael Albrecht, AddQ Consulting)

Det är också väldigt roligt att få feedback på verktyget från så många användare som möjligt – och det är en fantastisk morot för oss att förfina våra processer, refaktorera vår kod och automatisera tester … allt för att kunna få ut nya versioner med ny funktionalitet snabbare.

För processförfiningen har jag på utvecklarsidan tagit stor hjälp av Maven för att

förenkla hanteringen av beroenden till andra paket

till exempel slipper jag själv leta upp och ladda ner jar-filer från olika håll – Maven sköter detta åt mig
genom att definiera paket och versioner som verktyget är beroende av i en enda fil kan en ny utvecklare (eller jag, igen, på en annan dator) komma igång och börja koda på nolltid

underlätta versionering och paketering inför release

versionen på verktyget specifieras på ett ställe, och ett handsmitt Maven-bygge ser till att alla filer får rätt namn och paketeras i en leverabel (egentligen två, en .zip och en .tar) tillsammans med tillhörande dokumentation

köra en svit regressionscheckar på komponentnivå

dessa går framförallt igenom hur sessionsrapporterna i Excelformat tolkas, att informationen finns i rätt celler och att cellerna är i rätt format

om önskvärt även köra en svit regressionscheckar på systemnivå

dessa kräver att applikationen är byggd, och att en databas är uppsatt, då de går igenom import från ett trettiotal exempel-Excelrapporter till databasen samt generering av rapporter i html- och pdf-format för en ensam iteration, ett urval av iterationer och alla iterationer

Icke att förglömma, förstås, den fantastiska hjälp som står att få i form av manuell, utforskande, testning. Vi försöker se till att få med åtminstone ett par sessioner av utforskande regressionstestning som komplement till de automatiska checkarna inför varje release – utöver, såklart, testningen som görs kring nya funktioner.

Ett automatiserat regressionsfångstnät, med andra ord, som täcker applikationens vanligaste användningsfall – i ljuv harmoni med skickligt utförd utforskande testning – ser till att vi tryggt kan leverera nya versioner som är bättre, mer lättanvända och felfriare.

Vi kan också få ut nya versioner snabbare – så sätt oss gärna på prov! Har du använt verktyget och önskar att något vore annorlunda? Har du försökt använda verktyget men fastnat på vägen? Skulle du vilja använda verktyget men saknar någon vital funktionalitet? Skicka gärna in dina synpunkter och önskemål, så får vi försöka göra verklighet av dem.

Robert Johansson först ut att certifiera sig till Technical Test Analyst.

Johan Sandström — Tue, 27 Mar 2012 16:30:55 +0000

I början av februari, 2012, genomförde Grove Consultants den första ISTQB Advanced Technical Test Analyst utbildningen i Sverige, där SSTB medverkade vid examineringen.

Under denna tidiga utbildning deltog och certifierade sig senare Robert Johansson från AddQ Consulting, till Technical Test Analyst via ISTQB.

Ett Stort Grattis till Robert önskar vi på AddQ Consulting!

Robert som är en erfaren test- och integrationsledare med bred kompetens inom både testmetoder och testplanering har arbetat i alla testfaser inom ett flertal branscher och med olika typer av arkitektur samt har även aktivt fungerat som lärare för metodkurser (PTM/TAKS), certifieringskurser (ISEB/ISTQB) samt testledarkurs (Affärsdriven Testledare).

Vi frågade några av våra deltagare vad dom tyckte om AddQ Dagen 2012.

Johan Sandström — Mon, 26 Mar 2012 10:27:39 +0000

Måndagen den 19:e Mars gick AddQ Dagen 2012 av stapeln och vi frågade några av våra deltagare vad de tyckte om seminariet och här kommer svaren.

Vilka kunskaper tar du med dig hem från AddQ Dagen?

..att AdHoc-testning inte är att förakta men heller inte tillräckligt.

- Martin Börlin, Aftonbladet

Vad anser du är den hetaste trenden inom test och kvalitetssäkring just nu?

De flesta vill ju jobba agilt, men gör de det verkligen? Konsten att få till många och bra testfall till den korta beskrivningen underskattas mycket. Jag gillade framför allt de två grabbarna Johan Bergström och Michael Albrecht. Deras presentation och idéer är klart bra och lätta att tillämpa.

- Eva Strickert, FC Management AB

Vad tror du är framtiden inom test och kvalitetssäkring?

Jag tror det måste fortsätta att utvecklas. Det flesta utanför testvärlden vet inte vad ET (Exploratory Testing) är.

- Bo Rydberg, Sogeti Sverige AB

Strukturerad Exploratory Testing med verktyg anpassade för att testa den egna produkten. Man utvecklar (eller få hjälp att utveckla) smarta Tools som kan hjälpa till att förenkla testandet helt anpassat efter den produkt man testar. Man använder alltså inte kommersiella testrobotar. En ny roll; ”tool smith” är en självklarhet i testteamet.

- Andreas Fridén, Phadia AB

Ett stort Tack! till alla er som deltog på detta års halvdagsseminarium.

Bör man testa ett bolags värderingar innan man tar anställning?

Henrik Lönn — Mon, 26 Mar 2012 07:35:09 +0000

Bör man testa ett bolags värderingar innan man tar anställning?

Många företag nämner att de har värderingar som de lever efter. Men lever verkligen alla företag efter sina värderingar, eller är det bara en pappersprodukt som skapats för att det ligger i tiden eller för att lyckas anställa de bästa och mest eftertraktade personerna?

Många företag har värderingar som kanske tagits fram vid någon trevlig konferens eller där företagsledningen själva skrivit ner några värderingar som är lämpliga för just deras bolag. Men är det inte så att personalen borde vara med och ta fram värderingarna för företaget?

För mig är det viktigt att medarbetarna i bolaget har varit med och tagit fram vilka värderingar man känner är viktiga och brinner för. Om man blir erbjuden en anställning vid ett bolag där man känner att värderingarna som beskrivs är något som man själv kan skriva på och acceptera. Kan man då testa att dessa värderingar på något sätt för att säkerställa att det bolaget uppger stämmer?

Ett alternativ kan vara att kanske ställa frågan om bolaget har någon kulturansvarig eller liknande roll, vilken säkerställer att värderingarna efterföljs.

Finns det fler möjligheter att stämma av om värderingarna bolaget målar upp stämmer överens med verkligheten?

Förmodligen finns det en mängd olika varianter för att testa ett bolags värderingar på. Kan man använda sig av någon kreativ testteknik för detta?

Utforskande tester av värdegrunden kanske är en variant? Vara så kreativ att man hittar de perfekta frågorna för att se om företaget följer sina värderingar.

Eller så frågar man helt spontant någon av de anställda som jobbar på företaget man sökt jobb på. ”ursäkta, vilka är ert företags värderingar?”

Varför inte testa värderingar på AddQ? Här behöver du inte var spontan eller kreativ utan bara ställ frågan, och så får du ett snabbt svar; ständigt lärande engagemang & långsiktighet.

Hur många andra bolag har sina värderingar på baksidan av säljmaterialet? Varför inte göra ett test, titta på ditt bolags säljmaterial, vänd på det och se vad finner du där? Bolagets värderingar? Om inte så kanske de inte betyder så mycket för just ditt bolag?

Vad anser du vara viktigt när du väljer arbetsgivare? Om det är så att bolagets värderingar är viktiga för dig så skulle jag råda dig till att testa värderingarna på det bolaget där du söker ditt nästa jobb.

Är du intresserad av att testa AddQ´s värdegrunder, titta in på vårt kontor så får du testa oss!