Välkommen till bloggen fylld med inspiration kring QA

Inom finanssektorn är användarupplevelse (UX) och tillgänglighet inte bara viktiga för kundnöjdhet och kundlojalitet, utan de är också avgörande för att uppfylla juridiska och etiska krav. En välutformad, användarcentrerad och tillgänglig finansiell tjänst kan avsevärt påverka ett företags framgång och rykte. Genom att integrera användarvänlighet, tillgänglighet och användarcentrerad design i kvalitetsstrategin kan finansiella applikationer inte bara uppfylla tekniska krav utan också leva upp till användarnas förväntningar och behov.

I takt med att finansiella tjänster blir alltmer digitaliserade, ökar också risken för dataintrång och cyberattacker. En proaktiv inställning till testning innebär att säkerhetsaspekter och potentiella sårbarheter adresseras och testas systematiskt genom hela utvecklingscykeln, vilket minimerar risken för allvarliga säkerhetsbrister och dataläckor. Det inkluderar implementering av säkerhetskodgranskningar, penetrationstestning och säkerhetsauditer från början av projektet.

Regulatoriska krav förändras löpande och kvalitetssäkring har en central roll i att säkerställa efterlevnad. Genom att ha effektiva QA-processer på plats, kan ni kontinuerligt ha koll på och verifiera att allt är i linje med de senaste reglerna. Det skyddar inte bara från eventuella juridiska risker utan bidrar också till att stärka ert rykte på marknaden.

I takt med den accelererande digitaliseringen inom bank- och finanssektorn har användningen av digitala tjänster blivit alltmer central. Denna utveckling medför stora fördelar i form av tillgänglighet och effektivitet men ställer samtidigt höga krav på kvalitetssäkringen (QA). För att säkerställa att digitala tjänster är pålitliga, säkra och erbjuder en sömlös användarupplevelse är en väl genomarbetad QA-process avgörande.  

Low code och No code-testning är metoder för att automatisera tester med minimal eller ingen kodning alls. Detta är en tydlig avvikelse från den tidigare praktiken där man arbetat nära koden och använde ettor och nollor till att nu använda mer naturligt språk och grafiska gränssnitt för att utföra automatiserade uppgifter. Denna metodik syftar till att förenkla och accelerera testprocessen genom att göra den tillgänglig för personer med olika tekniska kunskapsnivåer, inklusive de som inte har djup programmeringskompetens.  

Det finns en mängd olika verktyg och tekniker för testautomatisering, var och en utformad för att möta specifika testbehov. Att förstå dessa verktyg och deras kapacitet är avgörande för att effektivt automatisera testprocesserna inom mjukvaruutveckling.  

När en användare skaffar en ny app eller digital tjänst, uppstår ofta ett dilemma. Du som jobbat med UX och utveckling av appen, skulle helst vilja berätta allt för användaren om vilka smarta funktioner och snitsiga genvägar som finns. Vi brukar på engelska prata om user onboarding, att guida nya användare till att förstå och lära sig grunderna i appen.

Att vara konsult innebär ofta att man hoppar från ett uppdrag till ett annat utan någon paus. Det erbjuder spänning och utmaningar och att ständigt utvecklas för att undvika att fastna i rutiner och gamla vanor, men också att man är självmedveten för att undvika utbrändhet. Därför kan det vara en riktigt bra idé att använda tiden mellan uppdrag för att reflektera men framför allt ta tillfället i akt att lära sig nya saker.

Testautomatisering erbjuder en lösning för att hålla jämna steg med de ökade kraven på kvalitet och leveranshastighet. Genom att automatisera repetitiva och tidskrävande uppgifter inom test kan utvecklingsteam fokusera på mer komplexa och värdeskapande aktiviteter. Dock finns det några saker som är bra att undvika om du ska få den effekt av testautomatiseringen du hoppas på. Här listar vi det vanligaste fallgroparna vi stöter på.  

Den 28 juni 2025 kommer Europeisk Tillgänglighetslag (European Accessibility Act) gällande tillgänglighet för produkter, webbsidor och andra tjänster träda i kraft och som företag riskerar du vite om lagkraven inte uppfylls. För att närma dig lagen samt undvika exkludering av användare är vår rekommendation att använda dig av WCAG.

Att börja med testautomatisering kräver planering och förberedelse för att det ska få den effekt du önskar, så innan du dyker in i skript och verktygsval bör du lägga en solid grund. Det handlar om att förstå förutsättningarna och att göra nödvändiga förberedelser för att säkerställa en smidig övergång till automatiserad testning. Här är några av de saker som är bra att överväga innan du sätter i gång.  

Varje system är unikt och fungerar på sitt eget sätt, oavsett om det har anpassningar från tredje part eller är utvecklat helt från grunden. Det innebär att du behöver anpassa din testautomatisering för att nå önskat resultat.

I den dynamiska världen av mjukvaruutveckling är testautomatisering inte bara en teknisk fördel utan en strategisk nödvändighet. Det underlättar kontinuerliga tester, som exempelvis är en kritisk del av DevOps, och säkerställer att nya funktioner genomgår en grundlig och konsekvent utvärdering. Något som är särskilt viktigt i miljöer där ändringar ofta görs i kodbasen och som kräver snabba och pålitliga testlösningar.

Att hitta det perfekta testautomatiseringsverktyget är inte en lätt uppgift. Vilken typ av automationsverktyg som behövs för att anpassa sig till livscykeln för mjukvarutestning beror mycket på dess resurser, team och strategi. Så att tro att det finns ett testautomatiseringsverktyg som är det absolut bästa och passar lika bra för alla är att lura sig själv. Däremot finns flera olika populära verktyg som är trendiga just nu och som är designade för att enkelt anpassas till ditt projekt. Några exempel på de populära automationsverktygen som används i både enkla och komplexa system för att ge tillförlitlig och korrekt testkvalitet är Selenium, Appium, Katalon Studio, Cypress och Playwright.   Idag riktar vi ljuset mot ett av de senaste automationsverktygen som har visat sig vara en framgång - Playwright.

Artificiell intelligens (AI) har förändrat och kommer fortsätta att förändra QA vilket gör att vi som testare behöver vara redo. AI-drivna testverktyg kommer automatisera återkommande uppgifter, förutsäga problem samt förbättra effektivitet och precision. Det skapar mer tid åt kreativa uppgifter men ställer samtidigt nya krav på testaren. De som har förmågan att arbeta med system baserade på AI och dra nytta av att testa med AI kommer att vara eftertraktade. Testautomatisering i framtiden handlar inte om att ställa testare mot AI utan snarare hur man testar med hjälp av AI.

I dagens produktutveckling blir fokus på tillgänglighet allt viktigare. Det är grundläggande för att säkerställa att alla användare, oavsett eventuella funktionsnedsättningar, kan dra nytta av och njuta av en produkt. Att bygga in tillgänglighet från grunden ökar inte bara produktens räckvidd och målgrupp, det främjar också inkludering och respekt för användarnas mångfald. I denna kontext blir tillgänglighet inte bara en funktion, utan en grundprincip som driver innovation och skapar en positiv inverkan på samhället. 

När vi pratar om användbarhet handlar det om att skapa produkter som inte bara fungerar, utan som också är lätta att förstå och använda. Det handlar om att sätta användaren i centrum och skapa en upplevelse som är smidig och tillfredsställande. Ett användarvänligt gränssnitt minskar inlärningskurvan, ökar effektiviteten och skapar lojalitet. Våra UX-designers har identifierat vanliga misstag som många gör i sitt användbarhetsarbete. De delar även värdefulla tips om hur du kan förbättra användbarhetsarbetet. Med deras insikter blir användbarhet inte bara en målsättning utan en välgenomtänkt strategi för att skapa produkter som verkligen talar användarnas språk och ger en överlägsen upplevelse.  

I dagens digitala värld är säkerhet inte bara en funktion som är trevlig att ha - det är en absolut nödvändighet. Med cyberattacker som blir allt vanligare krävs det strikta säkerhetsprotokoll för att skydda din IT-infrastruktur. Därför har vi listat de tio viktiga åtgärder som du bör anta för att stärka ditt IT-försvar. Bland de olika säkerhetsramverken som är tillgängliga kommer vi att fokusera på kärnfunktionerna i National Institute of Standards and Technology (NIST) Framework: identifiera, skydda, upptäcka, svara och återställa.  

Att ha med användarna i utvecklingsprocessen är inte något nytt. Att förstå värdet av att inkludera användaren, att ha en genomtänkt strategi både för utvecklingsfasen, testerna samt hela livslängden kan vara det som bidrar till en framgång. Att våga ifrågasätta insikter, behov och värdet på ett organiserat och strukturerat sätt genom itererande tester under utvecklingsfasen kan vara det som leder till succé. Nedan följer en rad förklaringar och sanningar med användartesternas betydelse under utvecklingsprocessen.  

De senaste 20 åren som jag har jobbat med prestandatester har området inte förändrats nämnvärt. Men på sistone jag har börjat skönja några trender som kommer att förändra sättet vi bedriver prestandatester på. Vilka det är, kan du läsa om i detta inlägg.

Jag är ute i sista stund, som vanligt. Väntar in till det sista att skicka in ansökan. Väl inloggad fyller jag in mina uppgifter. Det är mycket som skall väljas, kontrolleras och fyllas i. Äntligen framme på sista sidan med den sköna gröna knappen ”SKICKA IN”. En känsla av välbehag infinner sig då man känner sig klar med alla sina uppgifter. Som när man gjort klart läxan eller rabattrensningen.   KLICK låter det från musen då jag trycker på den gröna knappen. Plötsligt står tiden stilla! Det enda som rör sig är markörens snurrande animering, sekundvisaren i mitt armbandsur och min puls som plötsligt rusar…snurr snurr, dunk dunk. Men nu så! Äntligen händer något på skärmen...HTTP 500, Internal server error!?

Det är inte ovanligt att ett uttryck som står för en specifik metodik eller process kan misstolkas, speciellt om man läser uttrycket bokstavligt. Testning i produktion eller Testing in Production faller definitivt under den kategorin. I detta blogginlägg ska jag förklara vad det faktiskt innebär.

Begreppet “teknisk skuld” myntades av mjukvaruutvecklaren Ward Cunningham, en av författarna till det agila manifestet och mest känd för att ha utvecklat den första wikin. I det här blogginlägget tittar vi närmare på vad teknisk skuld är, hur den uppkommer och vilka risker den medför. 

Att kalla ett segt system som inte kan användas för icke funktionellt är i mitt tycke missvisande. Namnsättningen har kommit till på grund av att dessa krav inte har med själva funktionen i systemet att göra. Kraven är dock väsentliga att uppfylla för att systemet ska fungera tillfredsställande för flertal användare i olika situationer.

Tankar som continuous har funnits med inom mjukvaruutveckling tidigare men har först på senare år blivit en egen disciplin, fått betydligt bättre verktygsstöd och används av allt fler, men fortfarande är det nytt för väldigt många. Det är ett modernt och flexibelt arbetssätt som möjliggör snabba leveranser till kund, något som det hela tiden ställs allt högre krav på. I continuousvärlden finns det dock en hel del begrepp och metoder att hålla koll på, i det här blogginlägget tittar vi närmare på Continuous Integration (CI) och Continuous Delivery (CD) och hur dessa fungerar.

Kvalitet kostar, men fel kvalitet kostar mer. Varför är det så viktigt med kvalitet, och vilka metoder kan du som Test Manager eller QA Manager använda i din organisation?

Även om det har pratats en hel del om continuous de senaste åren så är det fortfarande ett område som är nytt för många företag. Man vet inte riktigt vad det är, hur det fungerar eller varför det är viktigt att börja fundera på det. Och det som främst brukar nämnas kopplat till continuous är att det möjliggör betydligt snabbare leveranser till slutanvändaren, men anledningarna är flera.

Du har förmodligen hört talas om shift left-trenden, en trend som rör hela mjukvaruindustrin och som innebär att förflytta sig längre åt vänster i utvecklingskedjan, närmare utveckling. Det här möjliggör att hitta och ta bort buggar tidigare, närmare införingspunkten och att jobba förebyggande kring defekter för att uppnå de affärsmål man satt upp.   Vi vet ju alla att det är billigare att ta bort buggar tidigare.

Under de senaste årens utveckling har kraven på snabba leveranser ökat, vilket har gjort att testautomatisering har fått större utrymme. Idag är det viktigare än någonsin att vara ifrågasättande kring produkten och redan i ett tidigt skede försöka lista ut vad som skulle kunna gå fel, för att snabbare kunna lösa det om problemet uppstår.  

Att lyckas med agila transformation har visat sig vara en stor utmaning för organisationer och team. Det är en stor förändring och det gäller att inse att man står inför ett långt och strukturerat arbete framöver och att det inte är något som sker över en månad. För att hjälpa er på vägen har jag tagit fram fem tips där jag sett att organisationer som jobbar med dessa bitar får väldigt stor nytta av dem och gör att de lyckas med sin resa att bli agila.Jag hoppas att de ska vara till hjälp för er också!  

De flesta förändringsarbeten är generellt sett svårt att hantera, men att lyckas med just agila transformationer har visat sig vara en stor utmaning för de flesta organisationer och team. En av anledningarna är att agila transformationer ofta orsakar förändringar i organisationen, i arbetssätten och i kulturen samtidigt! Vilket kräver oerhört mycket av alla individer då man påverkas samtidigt som man också driver förändringen. Det i sin tur ökar risken att misslyckas med något av områdena och förändringar som sker på felaktiga sätt gör människor förvirrade, frustrerade och oengagerade.   För att göra arbetet enklare kommer här några av de vanligaste fallgroparna vi ser att man hamnar i och som vi rekommenderar att undvika.  

En agil coach hjälper team, företag eller organisationer att fungera bättre - oftast vid en agil transformering eller vid förbättring av agila kulturer och metoder. Coachen skapar förutsättningar för teamet eller organisationen att nå uppsatta mål genom att lyssna, ställa frågor, analysera och ta bort hinder. En av de viktigaste arbetsuppgifterna är att få personer och team att förstå det agila mindsetet för att själva kunna hitta lösningarna man behöver för att komma framåt.  

Att vara agil eller att arbeta agilt är inte något som är exklusivt för ett specifikt område eller en specifik bransch. Det är ett förhållningssätt som handlar om att man vill se ett bättre slutresultat. Att vara villig, och intresserad av, att förbättra och förändra för att skapa mesta möjliga nytta. Eller som John Steinbeck en gång sa, ”att idag tänka annorlunda än igår skiljer den vise från den envise”. Oavsett om du jobbar inom IT eller ej.  

Agilt – ett koncept som ofta missuppfattas. Den vanligaste missuppfattningen är att agilt handlar om en viss typ av arbetsmetod som många tror att man kan införa och sedan påstå att nu jobbar man agilt. Tyvärr är sanningen långt ifrån så pass enkel. Agilt är mer en kultur och ett mindset för att uppnå vissa mål och har egentligen väldigt lite att göra med en specifik arbetsmetod. Det är också därför det finns så OERHÖRT många olika metoder som klassas som agila. Det kan skilja sig väldigt mycket mellan dessa metoder men de har en gemensam nämnare - att de alltjämt främjar eller skapar förutsättningar för att nå de agila målen.

Inom Medical Device råder hårda krav på dokumentation och att allt arbete som görs måste vara spårbart. Jag vet mycket väl hur enerverande det kan vara att behöva dokumentera för mycket men inom Medical Device finns det inget som heter överdokumentation och därför är utmaningen att dokumentera ”Just Enough”. I denna artikel kommer jag inte gå in på vad som ska dokumenteras inom Medical Device, det finns en bra checklista här som jag har använt flertal gånger. Jag kommer istället fokusera på hur dokumentationen kan struktureras med praktiska tips på hur ni kan fördela dokumentationsbördan, undvika tung dokumentation sent i projektet och ge er inspiration till att hitta rätt nivå av dokumentation.  

Efter en längre tid med produktutveckling inom Medtech ser jag 3 tydliga fallgropar de flesta bolag hamnar i. Ett för snävt Intended Use, snabba och enkla lösningar, samt att offra sin produktvision för att tillgodose behoven hos sin första och enda kund. Denna artikel är främst för er som ännu inte har någon CE-märkning på er produkt och fortfarande har möjlighet att med enkelhet göra förändringar i produkten men kan även inspirera er som redan har en CE-märkning och önskar förändring.  

Digitaliseringen går snabbt framåt men tyvärr håller inte säkerheten kring IT samma takt. Många företag prioriterar inte IT-säkerhet så mycket som de bör och det blir alltför många gånger brandsläckning för stunden. Idag försöker man få in samma IT-säkerhetstänk i medtechbranschen likt som för OT (operational teknologi) och för industriella kontrollsystem. I takt med att fler och fler bolag, både inom privata och offentliga sektorn blir mål för ransomware attacker ökar fokus och krav kring säkerhet hos allt fler.

Inom vården är det tyvärr väldigt vanligt att personalen upplever mycket stress, vilket leder till vissa begränsningar för den som skapar designlösningar för vårdens digitala och fysiska verktyg. Det blir kritiskt att verktyget är enkelt att använda då en design som inte är användarvänlig kan få stora konsekvenser.

De flesta kan nog hålla med om att det känns meningsfullt att jobba och bidra inom Medtechbranschen. Det infinner sig en känsla av att du gör skillnad. Du kanske förbättrar någons livskvalité, skapar ett värdigare liv för någon eller kanske till och med räddar liv. Alla medicinska lösningar som tas fram för att förbättra en persons livskvalité är positiva. Men, att tänka ett extra varv på hur du designar din lösning kan göra otrolig skillnad för slutanvändaren i det långa loppet.I denna artikel kommer jag berätta hur jag tänker när jag tar fram medicinska designlösningar med fokus på brukare som lever självständigt hemma och hanterar sin medicinska lösning till störstadel på egen hand.

Oftast är svaret på den frågan att det är kravanalytikerns ansvar. Och visst kan man hålla med. Att samla in och analysera behov, och att formulera konkreta, testbara och tydliga krav, det ansvaret kan läggas på en person som innehar rollen kravanalytiker.   Men livscykeln för ett krav tar inte slut där.

Att utveckla produkter som ska bli Medical Device är komplext och det skiljer sig en del mot när man utvecklar icke-medicintekniska produkter såsom att specifika krav och processer måste följas på ett speciellt sätt. I denna artikel går jag igenom fem saker som skiljer sig och som ni behöver ta hänsyn till när ni utvecklar produkter inom MedTech. Ni får även några tips på vägen.  

Medtech-produkter. Phu tänker du med all rätt, jag tänkte detsamma. Jag kom in helt grön på test av Medtech-produkter och min uppgift var att sätta upp en End-to-End verifieringsplan i ett projekt som innefattade utveckling av både hård och mjukvara. Det finns en del saker som är bra att känna till samt tänka på vid testning av produkter inom Medtech och det tänkte jag gå igenom i denna artikel.  

Hur kan tillvaron avseende verktyg i ett utvecklingsteam se ut, specifikt om teamet och organisationen arbetar enligt en devops-modell? Det finns en mängd verktyg att tillgå, men hur hänger de ihop och i vilken mån behöver du bry dig om eller förstå hur de hänger ihop?   I den här artikeln går vi igenom vilka typiska verktyg vi stött på i team som vill leverera ofta.  

Grunden för ett testfall i automatiserade verktyg är att kunna tillämpa rätt testramverk och som jag berättade i förra artikeln använder Cypress både Mocha.js och Chai.js ramverk som kommer med vid installationen och som är baserade på JavaScript bibliotek.  

Blockchain är kanske en av de mest hypade teknikerna just nu och om man som QA-specialist ibland känner sig överöst av olika verktyg så är utbudet av befintliga verktyg för att testa blockchain-lösningar inte imponerande. Eftersom det är en väldigt hypad teknik kommer man säkert att börja se andra implementeringar utöver kryptovalutor så som Bitcoin och NFTer inom en snar framtid.  

Innan man kan börja skriva tester i Cypress bör man förstå hur verktyget är uppbyggt. Strukturen definierar hela arkitekturen och jobbflödet vilket underlättar arbetet i verktyget. De flesta testverktyg (som Selenium) använder nätverket för att skicka sina anrop till webbläsaren via en så kallad Driver vilket enkelt kan förklaras med att testerna körs utanför webbläsaren.

Vilka verktyg används av kollegor runt omkring idag? Att ta reda på det kan vara första steget mot att uppdatera sin personliga verktygskarta vad gäller utvecklings- och testarbete inom mjukvara. Men finns egentligen behovet? Man får ju tillgång till de verktyg man behöver av sin arbetsgivare, eller?

Något man kontinuerligt stöter på inom DevOps är behovet av att införa nya testverktyg. Men ibland handlar det inte om ett behov utan snarare att man vill ha ett verktyg som man är van vid istället för att använda de verktyg man redan har. Det behöver inte betyda att man inte ska byta verktyg men då bör det nya verktyget tillföra något man tidigare saknat, vara mer kostnadseffektivt eller ha andra fördelar.

Cypress är ett JavaScript-baserat testverktyg som fungerar på front-end-testning och API-testning i moderna webbapplikationer, Cypress är byggt ovanpå Mocha som också är ett JavaScript testramverk som använder BDD/TDD assertions.  

Shift left-trenden inom DevOps medför att man kommer i kontakt med verktyg som man tidigare kanske inte behövt hantera. Som utvecklare använder man testverktyg för API och GUI testning, till exempel SoapUI, JMeter, Postman, Selenium och Cypress. Medan man som testare behöver en bättre förståelse av Npm, Nuget och Maven som bygger ihop koden till en applikation. Ibland kan valet av rätt lösning kännas omöjligt i den djungel av tekniker, programmeringsspråk och verktyg som man idag behöver kunskap om, och som krävs för att säkerställa produktens kvalitet.  

Har du någon gång suttit i ett designprojekt, mitt i en kreativ fas och så önskar någon intressent utifrån teamet att få se framsteg eller resultat på ditt arbete? Du kanske känner att det inte riktig finns något att visa, men det ger en professionell bild av dig att alltid försöka bemöta en sådan förfrågan.  

Ett sätt att bevisa nyttan med UX är att utvärdera användbarheten av vår produkt. Genom att utföra mätningar kan vi utröna vilka förbättringsområden vi behöver fokusera på härnäst, bevisa för kunden att de gjorde rätt val när de valde vår produkt och även visa hur grundligt UX-arbete lönar sig för företaget.  

När Microsoft 2001 gjorde en surfplatta och försökte sälja den till allmänheten var det inget fel på produkten, den var välbyggd, hade vettiga funktioner och verkade inte för dyr i sammanhanget. Total flopp. 4 år senare var det Samsungs tur, samma sak där – en flopp.2011 släpper Apple en surfplatta, samma koncept, samma funktioner men inte en flopp. 10 år senare ligger det ett par surfplattor i varje hem. Apple lyckades med det konkurrenterna inte gjorde, nämligen att hitta balansen mellan användarnytta och affärsnytta.

Hur ska man veta att det är dags att skrota sin produkt och börja om? De flesta nybörjare likställer det med ett misslyckande, medan de bästa innovatörerna är de som har misslyckats flest gånger. Har du en ikonisk design i rockärmen, eller måste du tänka om?

Att enbart fokusera på produktens användbarhet är inte längre tillräckligt när man designar digitala produkter. Digitaliseringens snabba spridning och ökade betydelse medför att UX-designers behöver nya uppsättningar metoder och kunskap som hjälper dem att designa produkter som påverkar användarens känslor och användarengagemang. 

Det är fortfarande inte helt ovanligt att folk blandar ihop UI med UX, det är inte heller förvånande. Både UX och UI har en stor påverkan på hur en produkt uppfattas visuellt, men de har helt olika funktioner i produktutvecklingen. I denna artikel kommer vi förtydliga hur de kompletterar varandra.   Eftersom en produkt inte kan ha UX utan UI och tvärt om så behöver dessa två professioner jobba tillsammans för att kunna uppnå en älskvärd produkt.  

I takt med digitaliseringen blir det allt viktigare att du har din information i en säker och kontrollerad miljö så att ingen obehörig kommer åt den. Det innebär förmodligen att du behöver sätta dig in i området kring säkerhet och vilka åtgärder du måste vidta för att undvika intrång. När du gör det kommer du säkert att bli bekant med en hel del nya ord och förkortningar som inte är helt enkla att förstå. Därför har vi tagit fram en ordlista med de vanligaste och kanske krångligaste av dem.  Vi hoppas att den ska hjälpa dig att förstå begreppen och dess betydelse. 

I dagens digitala värld blir det allt viktigare att säkerställa att ditt företags samlade information inte kan hittas och tas av andra. Därför bör du kontinuerligt jobba för en bättre säkerhet genom att löpande göra tester för att ta reda på om det finns sårbarheter. Vi vet att informationssäkerhet kan vara klurigt så i denna artikel kommer jag förklara skillnaden mellan sårbarhetsskanning och pentest. Jag hoppas ett det ger dig en bättre förståelse av testerna och vilken betydelse de har för ditt företag.  

User experience design går enkelt beskrivet ut på att skapa en produkt eller tjänst som dina användare kommer att älska! Bra User Experience (UX) är det som gör att användaren kan använda produkten eller tjänsten utan frustration och vill fortsätta använda den, vilket in sin tur leder till att användaren får en bra upplevelse av hela ditt varumärke.

Oavsett om ni jobbar i en agil organisation, en organisation under agil transformation, eller en mera traditionell organisation så tjänar ni på att se över er kravdokumentation. Detta gäller både när den först skrivs och när den ska underhållas kontinuerligt. Med relevant dokumentation sparar ni tid på att alla slipper vara på alla möten, ni slipper missförstånd då alla kan titta på samma källa till information, och ni får en hållbarhet i organisationen då ni skapar ett kollektivt minne.

Att hitta rätt icke funktionella krav för ditt system är verkligen inte lätt. Men, genom ett metodiskt tillvägagångssätt och kunskap om vilka frågor som är viktigast kan du, verksamheten och utvecklingsteamen hitta rätt tillsammans.

Vi vet alla att det är viktigt att inkludera verksamheten i IT-utvecklingen – utan involvering blir det lätt onödiga missförstånd, förseningar och att fel saker kanske utvecklas. Lösningen är ofta att lägga över detta ansvar på en enda person (produktägare) och sedan inkludera produktägaren i teamet som representant för verksamheten. Det är tyvärr inte så hållbart och kan resultera i både kvaliteten och engagemanget blir lidande. Därför kommer här 3 tips på hur du som produktägare kan skapa tid som gör att detta kan undvikas.  

Även om statisk kodanalys är ett mycket effektivt sätt att tidigt identifiera defekter i koden automatiskt så uppstår den stora effekten när maskinens snabbhet kombineras med en människas intelligens, smak, kreativitet och kritiska tänkande. Medan statisk analys (se tidigare artikel om Statisk analys) använder verktyg som skannar och analyserar källkoden automatiskt är kodgranskning till stor del ett manuellt arbete.   Detta är den tredje artikel i en artikelserie med fyra delar som beskriver hur man kan införa en automatiserad test-pipeline och fokusera på de aktiviteter som kan göras så tidigt som möjligt i implementationsarbetet.  

Idag ställer vi otroligt höga krav på användarvänlighet, funktion och prestanda men trots det är det förvånansvärt få som jobbar väldigt lite eller inte alls med just prestanda. I och med digitaliseringen och den utveckling som har skett är det minst sagt riskfyllt att "slarva" med vissa tester då företagets publika applikationer är avgörande för en affär. Och hur ska du veta att en produkt verkligen uppnår dagens höga krav om du inte har testat alla delar som måste testas?

Att kartlägga prestanda och snabbt kunna härleda och avhjälpa prestandaproblem blir hela tiden viktigare. Bland annat på grund av att slutanvändare idag inte bara ställer krav på tillgänglighet, utan även svarstider. Med nya driftmodeller blir det dock svårare att spåra och kartlägga systemsamband och traditionell monitorering fungerar inte längre lika bra. 

Den första nivån av automatiserade tester i en CI/CD pipeline är ofta statisk kodanalys. Statisk analys av mjukvara utförs utan att egentligen exekvera koden, i motsats till dynamisk analys, som är analys som utförs då mjukvaran körs.   Man använder verktyg som skannar och analyserar källkoden, vilket är ett effektivt sätt att hitta defekter i koden och visualisera dem för programmeraren. På det här viset kan defekter fångas upp tidigt, långt innan de hamnar i systemet och orsakar förödelse när koden byggs och produktionssätts.   Detta är den andra artikel i en artikelserie med fyra delar som beskriver hur man kan införa en automatiserad test-pipeline och fokusera på de aktiviteter som kan göras så tidigt som möjligt i implementationsarbetet.

Den billigaste och snabbast fixade defekten är den som aldrig behöver hittas eller fixas, eftersom den aldrig har införts från början. Här har QA en stor uppgift i att vara riktigt bra på kod och reducera antalet defekter som från början införs.   Detta är den första artikel i en artikelserie med fyra delar som beskriver hur man kan införa en automatiserad test-pipeline och fokusera på de aktiviteter som kan göras så tidigt som möjligt i implementationsarbetet.

Hur bygger man en automatiserad kvalitetssäkringsprocess som både är effektiv på att hitta defekter (fel, buggar eller annan oönskad funktionalitet) och samtidigt har en så hög automatiseringsgrad som möjligt?Naturligtvis kan man ha samma approach som förr i tiden, men automatisera det som tidigare var manuellt arbete. Många känner till testautomatiseringsverktyg som exempelvis Selenium eller WebDriver som interagerar med systemet som testas, via det grafiska användargränssnittet.

Steget från att planera till att implementera kan ibland kännas oöverkomligt. Var och hur börjar man? Varför känns det som att man bara står och trampar? De absolut vanligaste felen är att försöka implementera för mycket och för fort. Förändring tar tid, inte minst om det är frågan om att skapa en ny kultur. Det går inte heller att genomföra förändring på egen hand. Hur bra idéer du än har så måste du ha hjälp och se till att få med andra på tåget. I det här blogginlägget tipsar jag om hur du kan gå tillväga för att implementera din teststrategi.  

Ibland kan det hända att ett team som vill anamma agil testning börjar fundera på hur man förbättrar kvalitén på en produkt så tidigt som möjligt och startar med att lista testtyper som de vill införa men fastnar sedan i en osäkerhet på var de olika aktiviteterna ska ske. Jag har själv fått frågan när någon vill börja med systemtester, end to end-tester eller liknande men det är oklart var i processen de passar in. I vissa fall finns det klara svar men i andra så beror det på de kringliggande processerna och hur övrig testning sker. Det som är en väl fungerande lösning i en organisation kanske inte alls passar i en annan.  

Att vara testledare på distans innebär du ställs inför olika utmaningar, till exempel kan du behöva hantera kulturella skillnader och skapa ett bra klimat för samarbete och förtroende. Idag när allt fler företag och organisationer jobbar med outsourcade team och/eller jobbar på distans med anledning av den pågående covid-19 pandemin kan det ge dig som testledare en del funderingar kring hur du bäst ska jobba med ditt team. Genom att från början bygga ett förtroende i teamet ökar dina chanser för att få ett mer framgångsrikt team. Här delar jag med mig av mina 3 bästa tips för att skapa det där starka och viktiga förtroendet. 

Under de senaste åren har kravet på att få en fullvärdig leverans ökat och kravet på kvalitet har höjts betydligt. Beställarna av olika system vill naturligtvis validera att systemet möter de krav som har beställts från början, tillkommit under utvecklingens gång samt de krav som har förändrats. I det här blogginlägget berättar jag vad som är viktigt att tänka på kring acceptanstester, eller som de också kallas - verksamhetstester och User Acceptance Test (UAT), för att nå ett så bra resultat som möjligt.

Du kan aldrig testa allt, därför behöver du fundera på vilka affärsmässiga risker som finns i ditt utvecklingsprojekt. Med det här som utgångspunkt kan du planera för i vilken ordning du ska testa, hur du ska minimera riskerna kring test och hur testerna ska prioriteras, så att du testar det mest kritiska först. Din teststrategi kommer då att ha samma affärsmässiga prioritering som styr hela utvecklingsprojektet. I det här blogginlägget beskriver jag hur du ska tänka när det kommer till riskbaserad test.   

Det finns många faktorer som spelar in för ett framgångsrikt testarbete. Först och främst behöver du lägga en bra grund som består bland annat av att testa tidigt, testa regelbundet och automatisera de tester som med fördel kan ske per automatik.    

På samma sätt som att du behöver fundera på hur du ska genomföra dina funktionella tester, är det viktigt att ta fram en strategi för icke funktionella tester. Dessa tester omfattar egenskaper hos systemet som till exempel prestanda, säkerhet, användarbarhet och underhållsbarhet.  

Innan du sätter igång med ett utvecklingsprojekt bör du ha en grundlig och stabil plan, en teststrategi som beskriver metodiken, arbetssättet och hur testerna ska prioriteras. I det här blogginlägget tittar vi närmare på några av de främsta anledningarna till varför du bör ta fram en teststrategi.  

När vi skriver automatiserade tester vill vi tillföra maximalt med värde till minsta möjliga kostnad eller tid. Det totala antalet testfall för att verifiera att ett stort modernt komplext system är felfritt, är i det närmaste oändligt. ”Allt” kan inte automatiseras. Här tittar jag närmare på vad som inte kan/bör automatiseras och varför. 

Förra inlägget handlade om processen som krävs för att planera och implementera visualisering av prestanda - generella best practices för långsiktig nytta. I denna artikel tar vi upp konkreta exempel på visualiseringar för olika grupperingar som vi rekommenderar och som vi vet av erfarenhet fungerar bäst.

Att visualisera sin prestanda är viktigt ur flera aspekter och för flera målgrupper. Men vad är meningsfullt att visualisera? Och hur undviker man att hamna i ett läge där man stirrar på en skärm fullproppad med grafer och oklara mätvärden - som ger noll nytta? Vad bör man tänka på vid uppsättning av visualisering? Detta handlar det här blogginlägget om.  

Feature flagging är en kostnadseffektiv och enkel programmeringsmetod som gör det möjligt för utvecklare att slå på eller stänga av funktionalitet i en programvara utan att behöva släppa eller ändra produktkoden. Att omsluta kod med feature-flaggor möjliggör att frikoppla funktionsutrullning från koddistribution.

Att skapa välfungerande team för IT-utveckling har ofta sina utmaningar. Hur påverkar behovet av till exempel IT-arkitektur , drift, testning, UX och kravställning sättet vi sätter samman personer som tillsammans bidrar till att leverera kvalitet på bästa sätt? Traditionellt sett var det tidigare vanligt att gruppera likasinnade personer som förstod varandra i samma team, men idag har man sett stora fördelar med att istället jobba i tvärfunktionella team.   

Den huvudsakliga anledningen till att kontinuerliga metoder inom utveckling av IT-system har slagit igenom stort är förmågan att kombinera snabbare leveranser, minskade kostnader och minskad risk. Idag finns det modernare varianter av Continuous Delivery (CD) som ytterligare maximerar leveranshastigheten och samtidigt minskar risken. I det här blogginlägget beskriver jag progressive delivery och hur det fungerar som kontinuerlig test i produktion.   

Jag började med penetrationstestning 2005. På den tiden var dåliga lösenord en väldigt vanlig anledning till att vi lyckades ta över ett bolags IT-infrastruktur. Vad som är väldigt intressant är att idag, 14 år senare, är det minst lika vanligt med dåliga lösenord.   

Något det ofta pratas om, kanske framför allt kopplat till testautomatisering är enhets- och integrationstester. Men vad innebär dessa tester i praktiken och hur används de? Det går jag igenom i det här blogginlägget!  

Det har pratats otroligt mycket om DevOps de senaste åren, ibland ses det nästan som någon form av universallösning för alla möjliga former av utmaningar inom traditionell mjukvaruutveckling. Men faktum är att utmaningarna med DevOps är många, så många att det inte ens är lönt att försöka lista dem. Därför vill jag uppmana dig att sikta på NoOps istället, vilket är betydligt enklare och smidigare!    

Automatisering av tester är vardag på många företag idag. Vad många upplever är dock testsviter som inte inger det förtroende som eftersöks, och tester som går sönder så fort koden ändras. Det beror ofta på test som fokuserar på implementationsdetaljer snarare än beteende. Med det menas att testet bryr sig mer om hur applikationen är byggd än om vad den är menad att göra. För användaren gäller det motsatta, nämligen att applikationen fungerar som tänkt oavsett hur. Vad krävs då för att skapa tester som tänker som en användare?

Att prestandatesta sina mjukvaror är otroligt viktigt för att vara säker på att de klarar av den kapacitet de är tänkta att klara av. Inom prestanda är det dock en hel del ord och begrepp att hålla koll på, därför har vi satt ihop en ordlista där vi har samlat de viktigaste. 

Maria Mårefors jobbar som konsult på QESTIT och har bland annat uppdrag som Service/UX-designer på Volvo Trucks i Göteborg på sin lista av erfarenheter. Maria är också en väldigt uppskattad föreläsare och håller presentationer i många olika sammanhang.  I det här blogginlägget hittar du en sammanfattning av hennes session om User Experience Design där hon bland annat pratar om vilka delar UX består av och hur företag ska gå tillväga för att ge kunderna den bästa användarupplevelsen. Vill du ta del av den inspelade föreläsningen så hittar du länken i slutet.

Tiden då testare och utvecklare kunde sitta på varsitt håll och jobba är förbi, det fungerar helt enkelt inte längre. Teamen måste bli mer agila, agila på riktigt och dela på ansvaret - från ax till limpa. Det kan däremot krävas en del arbete för att få ihop teamet som önskat, därför delar vi i det här inlägget med oss av fem värdefulla tips för ett starkare team.  

Att förstå den kontinuerliga cykelns (eller DevOps-cykelns) 6 C:n och se till att automatisera mellan dessa steg, kommer att vara den största utmaningen och främsta målet för många IT-chefer under de kommande åren. I det här blogginlägget har vi därför listat dessa och ger dig en kortare förklaring kring varje C och vad de innebär. 

För att kunna jobba effektivt med sina krav och tester så är det viktigt att ha ett verktyg som hjälper dig och underlättar arbetet. Men hur vet man vilka verktyg som är bäst – och framförallt vilket passar bäst för det behovet du har? Det har vi tagit reda på och i den här bloggartikeln berättar vi mer.  

En vanlig utmaning för många som jobbar inom test och utveckling idag är övergången mellan de olika världarna. När en organisation går från mer fasta arbetssätt, såsom vattenfallsprojekt, till mer agila metoder så innebär det ofta ett antal utmaningar. I det här blogginlägget listar vi därför tre konkreta tips för hur du kan underlätta den agila transformationen.   

Att byta ut ett arbetssätt som de flesta är vana vid och som “alltid har fungerat” kan förstås vara svårt. Både för att det krävs en stor förändring i mindset och för att det i de flesta fall kräver en hel del förberedelser för att det ska gå vägen. I det här blogginlägget tittar vi på tre viktiga saker att tänka på innan du tar steget mot continuous-världen där en stor och viktig del är tekniken.   

Kontinuerlig kompetensutveckling är ofta en stor boost för vårt självförtroende, något som gör oss både mer självsäkra och som utvecklar oss på flera plan. Men ibland kan det vara svårt att veta hur man ska gå tillväga rent konkret, här kan du som teamleader göra en hel del för att hjälpa ditt team att kontinuerligt utveckla sin kompetens.  

Att anlita externa konsulter kan ge fler fördelar, till exempel genom expertis och nya infallsvinklar. För att resultatet av samarbetet ska bli så bra som möjligt är det dock viktigt att hitta rätt konsult, vilket ofta är lättare sagt än gjort.

Test och utveckling har förändrats och utvecklats mycket de senaste decennierna och det finns ingenting som tyder på att utvecklingen är på väg att stanna upp, tvärtom. Förändring kan dock kännas lite jobbig och läskig ibland men kommer ofta med många fördelar. För att kunna upptäcka dessa fördelar och även ta del av dem, gäller det att vara redo för framtiden.   

På vissa arbetsplatser känns det direkt när du kliver innanför dörren, på andra är det mer otydligt. Men ändå så finns den där, på alla arbetsplatser - kulturen.  Det kan handla om hur vi vill vara mot varandra, hur vi vill att andra ska må, ska det vara högt i tak på företaget eller andra faktorer som är viktiga för er för att ni ska må bra och trivas på jobbet.  Med tanke på att vi spenderar en hel del tid på våra arbeten, en sisådär 2 080 timmar per år (det blir några timmar fram till pensionen), är det minst sagt naturligt att vi vill trivas och må bra på jobbet.  Oavsett om kulturen på just din arbetsplats är väldigt tydlig eller inte.

Har ditt företag ofta arbetstoppar som ni har svårt att ta er igenom utan att det leder till för stressade medarbetare? Eller behöver ni någon som kan kvalitetssäkra ert arbete genom nya infallsvinklar? Om du kan svara ja på båda dessa frågor kan det vara tid att fundera på att anlita en extern testare. Här hittar du fem andra anledningar.   

Att komplettera varandra i ett team är en av de främsta framgångsfaktorerna för att utvecklas och gör ett bra gemensamt jobb. Det gäller inte bara när det kommer till kompetenser, utan det är minst lika viktigt att personligheter, mindset och erfarenheter kompletterar varandra.  

I tvärfunktionella agila och kontinuerliga team är tanken att teamen ska vara självständiga och oberoende. Arbetsrollerna försvinner och fokuset ligger istället på kompetenser. Att arbeta i tvärfunktionella team på det här viset där alla medlemmar i någon mån har kompetens om varandras områden är ett måste när allting måste gå fort, eftersom det blir väldigt sårbart när jobbet är personberoende. Att arbetsrollerna försvinner gör att det blir viktigare att fokusera på individen, men det är inte den enda anledningen till att det är viktigt. 

Som i alla branscher är vi ständigt i förändring. Det i sin tur ställer krav på nya kompetenser och egenskaper för att lyckas. Som QA Manager finns det några nyckelkompetenser som kommer bli allt viktigare i framtiden. I det här inlägget förklarar vi vilka dessa är samt varför de kommer behövas. 

Testautomatisering är något av en trend som det har pratats mycket om de senaste åren. Det finns något av en generell missuppfattning idag om att digitaliseringen och den snabba utvecklingen innebär att allt måste, och bör testas automatiskt. Men så är inte fallet. Förvisso är maskiner idag smarta och kan göra många bra saker, men än så länge kan de bara göra det vi ber dem om. Det är förstås utmärkt när vi behöver kunna testa produkter på djupet, på flera olika nivåer, på ett effektivt sätt.  

Att kommunikation är A och O för att lyckas bra i ett team är mer regel än undantag. I ett team som ska jobba tätt tillsammans och på kort tid leverera produkter med rätt kvalitet är behovet av kommunikation extra stort. Det är däremot inte bara viktigt för leveranser, utan kan också påverka individerna i teamet mycket, både positivt och negativt. 

Personliga egenskaper, rätt mindset och rätt kompetenser är alla tre saker som spelar in när det är dags att skapa ett utvecklingsteam. Något av en utmaning för många av dagens QA Managers. Samtidigt så är rätt kompetenser i teamen en förutsättning för att lyckas med utvecklingsarbetet i framtiden.

Inför en ny lagändring brukar det komma en första indikation cirka 1,5–2 år innan lagen träder i kraft. Därefter följer som regel en lång och utdragen beredningsprocess. ESMA, det organ inom EU som har ansvar att stärka investerarskyddet och främja stabila och korrekt fungerande finansmarknader, meddelar sedan inte sin slutversion förrän nio månader innan de ska träda i kraft. Under tiden kommer olika tolkningar och frågeställningar som gör det svårt att planera krav- och utvecklingsarbetet.  

Att gå från en vattenfallsbaserad utveckling till en mer agil approach upplevs ofta medföra slitningar inom IT då det gäller att balansera resurser, hantera förändringsprocessen och samtidigt hålla takten i utvecklingsarbetet. För att lyckas och inte ge upp på vägen gäller det därför att ta små steg, för om du tar ett för stort scoop från början finns risken att förändringen upplevs övermäktigt. Det beror ofta på att man inte tillåter sig att ha tålamodet att se resultatet av det nya agila arbetssättet på längre sikt.  

Det finns inget som hindrar att hela verksamheten arbetar agilt. Många ursprungsidéer för det agila arbetssättet kommer till exempel från fordonsindustrin. Ett agilt arbetssätt innebär att verksamheten har den smidighet som krävs för att ständigt förbättras och utvecklas för att nå sina mål. Arbetssättet bygger på att alla medarbetare varje dag strävar efter att genom tillbakablickar, lärdomar och öppenhet för förändringar utföra saker bättre än de gjorde dagen innan.   I det här inlägget går jag igenom 6 steg som tar dig närmare ett agilt arbetssätt för kravhantering och på så sätt maximerar verksamhetsnyttan.  

När du läser den här artikeln så hoppas jag att du lämnar med konkreta förslag på hur du kan bevisa eller argumenterar nyttan med UX där du befinner dig eller vill hamna. Jag kommer att gå igenom egna erfarenheter och förslag där jag mött en positiv respons och kommit en bit på vägen. Den här artikeln är mest gynnsam för dig som jobbar med UX och vill veta mer om hur du kan argumentera för din profession, eller för dig som är mottagare för dessa argument.  

Produktutveckling är inte alltid en dans på rosor. Speciellt inte när produkten mår bäst av att team med lite olika tankesätt jobbar väldigt nära varandra under en längre period. Det är då det behövs extra mycket fokus på att få till ett bra samarbete och att verkligen se till att dra nytta av varandras kunskaper. Satsa allt på att vara en bra lyssnare, inkludera varandra i olika utvecklingsmoment, och se till att skapa en bra teamkänsla!  

Det blir alltmer vanligt att använda sig av SaaS lösningar (software as a service), mycket för att det är kostnadseffektivt, smidigt att använda då drift och underhåll sköts av leverantören samt kan ha hög säkerhet. Varför jag skriver kan är för att det kan gå fel om man inte är noggrann och kravställer säkerheten före köp. Allt för många köper en SaaS lösning med samma inställning som vid köp av en bil, de förväntar sig att den som byggt bilen har sett till att den är säker och bra.  

En effektiv och fungerande kommunikation i teamet handlar om så mycket mer än bara utbyte av information. En förbättrad kommunikation är viktig för att bygga, underhålla och förbättra relationer mellan individer och grupper i en organisation och är en stor framgångsfaktor för hur väl ditt team presterar och levererar kvalitet till kund.