Vad är test av mjukvara? Och varför är det så svårt? sid 6. Kom igång med prediktions- och evolutionsmodeller sid 19

Storlek: px
Starta visningen från sidan:

Download "Vad är test av mjukvara? Och varför är det så svårt? sid 6. Kom igång med prediktions- och evolutionsmodeller sid 19"

Transkript

1 ntimeger INSIKT I TID T E M A : S T R A T E G I E R F Ö R E F F E K T I V T E S T Nr 1 mars 2003 Vad är test av mjukvara? Och varför är det så svårt? sid 6 Kom igång med prediktions- och evolutionsmodeller sid 19 Krav och tester: Sju myter om felande länkar sid 24 Inbjudan till OnTime-seminarium om Test, se baksidan

2 Innehåll OnTime ska ge insikt i tid OnTime är en branschtidning som tar upp olika aspekter och nyheter inom området utveckling av inbyggda realtidssystem. OnTime ska ge möjlighet att ställa olika perspektiv mot varandra, och samtidigt visa helheten i teknikoch samhällsutveckling. Redaktion Ansvarig utgivare Christer Hoberg, vd Redaktionsråd Göran Carlzon, Erichs Communications Anders Magnusson, Göteborg Per-Ola Malm, Malmö Anders Åström, Linköping Reportage Sven Wennerström Redaktör Eva Holmquist, Jönköping Nätvariant av OnTime Ledare...3 Krav och risk vår ledstjärna i mörkret...4 Vad är test av mjukvara? Och varför är det så svårt?...6 Test av felhantering i distribuerade realtidssystem...13 Miljölagar driver på testutvecklingen...15 När fel inte får förekomma...17 Kom igång med prediktionsoch evolutionsmodeller...19 Krav och tester: Sju myter om felande länkar...24 Vårt område är inbyggda system.vi kommer aldrig att gå utanför detta område och måste därför behärska inbyggda system bättre än någon annan.våra uppdragsgivare kallar in oss när de står inför sin tuffaste uppgift: bryta ny mark, gå in på främmande teknikområden eller skapa nytt liv i ett projekt som gått snett. Vår affärsidé bygger på att tillföra våra uppdragsgivare nytt kunnande och effektivare metoder inom systemutveckling i kombination med överföring av den erfarenhetsbaserade, tysta kunskapen. För detta har vi utvecklat en metodik som gör att vi successivt för över vårt kunnande till uppdragsgivarens organisation.vi blir därmed så småningom överflödiga inom det dagliga jobbet, vilket som sagt är en del av vår affärsidé vår plats är först och främst inom de delar av projektet där de nya vägvalen är många och svåra. Jönköping (lokalkontor:växjö, Karlskrona, Ulricehamn) Box Jönköping Tel Fax Malmö (lokalkontor: Helsingborg) Box Malmö Tel Fax Göteborg (lokalkontor:trollhättan) Mölndalsvägen 30C Göteborg Tel Fax Stockholm (lokalkontor: Uppsala) Box Stockholm Tel Fax Linköping (lokalkontor: Örebro,Västerås) Teknikringen 9 SE Linköping Tel Fax München Leopoldstr. 236 DE München,TYSKLAND Tel Fax E-post Hemsida Produktion Erichs Communications AB, Linköping Grafisk design PO.Annonsbyrå AB Tryck NRS-Tryckeri 2 Nr 1 mars 2003

3 LEDARE Effektiv test en fråga om överlevnad Den intellektuella utmaningen kring test blir allt större i och med att de system som utvecklas blir allt mer komplexa. System kommunicerar med system. Mängden gränssnitt och möjliga kommunikationsvägar ökar. Allt detta innebär att informationsmängden, som måste hanteras av de organisationer som utvecklar systemen, ökar lavinartat. För dem som arbetar med test blir det allt svårare att fastställa vad som ska testas och hur det ska testas. Framför allt tar det mer tid, något som står i direkt konflikt med de nya ledorden för systemutveckling: snabbare, bättre, billigare. Något som var mycket tydligt på förra årets EuroSTAR (Software Testing and Review) var att kraven på reducerade kostnader för test blir mer och mer påtagliga. Otaliga deltagare vid konferensen presenterade modeller för att visa nyttan med test, ett resultat av att kostnaderna allt mer ifrågasätts. Lättviktsmodeller som Exploratory Testing där man gör avkall på formalitet och process till förmån för att åstadkomma resultat är på stark frammarsch. Viktigt fokusera rätt Vi står således inför ett mycket intressant problem. Trots ökande komplexitet och informationsmängd, vilket implicerar mer arbete, måste vi minska kostnaderna för test. Effektiviteten måste höjas så att vi hittar fler fel till samma kostnad (eller samma mängd fel till reducerad kostnad). När komplexiteten och mängden information ökar blir det allt viktigare att fokusera testerna rätt. De resurser som står till förfogande måste spenderas på ett sätt som medför att man får bra retur på investeringen, det vill säga att många fel upptäcks. Därför blir det allt viktigare med väl genomtänkta strategier för test. Samtidigt ökar betydelsen av kvalitativa tester i stället för kvantitativa tester. I en bra teststrategi ligger att testa rätt saker och att testa dem på rätt sätt. För att kunna testa rätt saker krävs kontroll och kunskap. Kontroll på kraven för systemet, de risker som är associerade med systemet, kunskap om hur systemet ska användas, hur systemet inte ska användas etc. För att testa på rätt sätt krävs det att man behärskar metoder som kan användas för att skapa relevanta testfall, baserat på den information som samlats in om systemet. Som alla vet finns det ett oändligt antal möjliga testfall även för relativt enkla system. För att vara effektiv krävs det därför att rätt testfall väljs. Felprioriteringar vanliga Verifiering och validering utgör ibland upp till 70 procent av projektens budget i många organisationer. Om man betänker att färre än 25 procent av de projekt som genomfördes i USA 1995 levererades enligt tidplan och budget (något som borde kunna fungera som riktmärke även för Sverige), borde test vara en prioriterad verksamhet. Verkligheten är allt som oftast annorlunda. Verifiering och validering genomförs många gånger av relativt oerfarna och ofta lågutbildade personer. När problem med effektiviteten upptäcks blir lösningen ofta att skapa nya processer, men utan att ha rätt resurser spelar det ingen roll hur bra processen är (om man aldrig tidigare bakat en kaka är sannolikheten relativt liten att man lyckas som konditor ). En nyckelfaktor till effektivitet är således erfarenhet och kunnande, en viktig insikt som många organisationer tyvärr inte gjort. Leverans enligt tidplan och budget För de organisationer som lyckas kombinera den formella kunskapen representerad av processer, metoder och tekniker med den tysta kunskapen som utgörs av erfarenhet, intuition och känsla, finns det stora möjligheter att genomföra effektiv test. Effektiv test skapar förutsättningar för upptäckt av fler fel till lägre (eller samma) kostnad, vilket kan medföra bättre produkter som levereras enligt tidplan och budget! I detta nummer av OnTime presenteras ett antal artiklar fokuserade på strategier för effektiv test som förhoppningsvis väcker tankar och ger inspiration. Trevlig läsning! Thomas Ericson Senior System Engineering Consultant Nr 1 mars

4 AV THOMAS ERICSON Krav och risk vår ledstjärna i mörkret Effektiva tester är en nödvändighet för att reducera de stora kostnader i projekt som associeras med verifiering och validering. Aktiviteter som kan utgöra upp till 70 procent av en projektbudget kräver fokus och noggrannhet! Test ligger på kritiska linjen, det vill säga påverkar leveransdatum direkt ifall testverksamheten blir försenad. Det innebär att vi inte har tid att påbörja den tidspressade testfasen med att börja fundera på hur vi ska testa och vad. Det arbetet måste påbörjas redan när projektet startas. I denna artikel väljer vi att fokusera på några aspekter av test som är kritiska för att just effektivisera testverksamheten. Tidig test En av de mest fundamentala strategier som kan anammas för att effektivisera, inte bara test utan hela projekt, är tidig test. Test har tyvärr traditionellt betraktats vara något som tar vid när utvecklingen (enligt en vattenfallsmodell) är färdig, vilket är ett förhållningssätt som tyvärr fortfarande finns kvar i många organisationer. Detta medför att test blir en reaktiv, istället för proaktiv, disciplin, det vill säga testningen syftar endast till att detektera fel, istället för att förhindra att de införs från första början. Att betrakta test som något som är aktuellt först i slutet av ett projekt medför också ofta att test under de tidiga faserna, modultest och integrationstest genomförs slarvigt (om de alls genomförs). Otaliga är de projekt där slarvet under de tidiga faserna, i ivern att komma till leverans, fått betalas dyrt i form av grova förseningar. Att försöka integrera/testa ett system där man slarvat med modultesterna är som att försöka tillreda en måltid där flera av ingredienserna passerat sitt bäst före-datum! Något som ofta blir väldigt tydligt vid en genomgång av den dokumentation som finns om test på olika nivåer, är att det i många organisationer genomförs mängder med aktiviteter i onödan. Ett annat problem är att man ofta testar för dyrt; systemkrav som kan testas effektivt och uttömmande på modultestnivå testas på systemnivå till stor kostnad. Något som med framgång introducerats i ett flertal organisationer är Master Test Planning (MTP). MTP syftar till att distribuera alla verifierings- och valideringsaktiviteter över de olika testnivåerna, från modultest via ett eller flera integrationssteg till systemtest. Fokus ligger på att verifiera kraven så tidigt som möjligt, till så låg kostnad som möjligt. Ju tidigare kraven kan testas, desto större konfidens i produkten när det väl är dags för systemtest! Systemkraven på en Watchdog kan till exempel testas relativt enkelt i en simulerad miljö under ett modultest, medan det kan vara kostsamt och tidsödande att testa på systemnivån. I detta fall bör det uttömmande testet genomföras under modultestet, och stickprov genomföras under integrations- och systemtesten. Framförallt är det viktigt att synliggöra för alla som arbetar i projektet hur och på vilken testnivå allt ska testas för att undvika redundans, och då är MTP utmärkt. Kravbaserad test Bland det mest kostnadseffektiva man kan göra är att få kraven så välformulerade och realistiska som möjligt. Redan när kraven för projektet etableras måste förberedelserna för systemtesterna initieras. Ett naturligt första steg är att låta testarna delta vid granskningar av kraven. En viktig egenskap hos krav är att de ska vara verifierbara, det vill säga att det går att skapa testfall för att testa kraven. Det är något som de som arbetar med test är synnerligen lämpade att avgöra. Eftersom testarna måste kunna kraven är det också kostnadsoptimerande att använda testare som granskare. Om man dessutom påbörjar arbetet med att planera hur kraven ska verifieras, upptäcker man ofta krav som inte är verifierbara i praktiken. När kraven börjar sätta sig ska systemtestfallen förberedas på allvar. Oavsett hur mycket man ansträngt sig med att etablera kraven, är det först när man börjar använda kraven som innebörden och konsekvenserna av dem uppdagas. Beroenden som man inte visste fanns, krav som saknades, krav som är motstridiga, krav som är orimliga etc. Denna typ av problem måste hanteras tidigt, eftersom det oftast blir kostsamt att hantera dem senare i projektet. För att kunna genomföra rättvisande tester krävs att en representativ testmiljö etableras. Detta är ett tidsödande arbete som måste initieras tidigt. Jag har själv skamset fått erkänna två veckor innan ett viktigt test att vi med de verktyg vi hade att tillgå skulle behöva drygt 46 år för att förbereda för testet. Ibland är det också nödvändigt att använda verktyg för att till exempel lasta systemet. Som exempel kan nämnas ett system som skulle kunna hantera datapaket per sekund. Vi hade inte tillräckligt med utrustning för att kunna generera det antalet datapaket på ett normalt sätt. Inte heller kunde vi säkerställa vilken sekund som datapaketen genererades. Vi var därför tvungna att utveckla ett verktyg som kunde skicka in rätt antal datapaket vid rätt tidpunkt. Utveckling av verktyg är tidsödande och riskfyllt. Om det ändå behövs vill man veta om det tidigt under projektet. Riskbaserad test Test (och alla andra kvalitetssäkrande åtgärder) handlar främst om att reducera risker. Det innebär att man behöver ta fram en riskanalys. För test finns sedan två viktiga parametrar att beakta; dels hur stor påverkan fel får på systemet om det inträffar, och dels hur stor risk är det att ett fel i verkligheten inträffar. Tänk er fyra olika fel i en digital tv-box: 1. I menyn för att sätta upp lösenordsskydd för vissa kanaler finns det ett stavfel. 2. Om man byter direkt från kanal 31 till kanal 4 och sedan till kanal 6 låser sig hela tv-boxen och måste startas om. 3. Om du tittar på kanal 3 kan du inte få fram information om vad som visas på kanalen. 4 Nr 1 mars 2003

5 A B C D E F G H I J K L M N O P Bild1:Tjänstestruktur för meddelandehanteringssystem. 4. Om en mycket ljus bild visas försvinner ljudet. Fel 1 inträffar varje gång du går in i den menyn. Det har dock mycket liten påverkan på systemet när det inträffar. Sannolikheten är antagligen liten att användaren överhuvudtaget upptäcker felet. Fel 2 inträffar bara om du gör tre kanalbyten efter varandra och bara när du byter 31 -> 4 -> 6. Sannolikheten att användaren gör just den kombinationen är liten, men felet inträffar varje gång du gör just den sekvensen. Påverkan på systemet är oerhört stor, hela systemet kan låsas. Sannolikheten att användaren försöker se information om vad som visas på kanalen är ganska stor. Felet påverkar enbart en extrafiness i systemet och samtliga huvudfunktioner fungerar fortfarande. Alltså har det en liten påverkan på systemet. Fel 4 är mycket allvarligt. Det påverkar en huvudfunktion, det vill säga ljudet. Det är också ganska sannolikt att en mycket ljus bild visas. Det är också ett fel som påverkar användaren av systemet. Alla fel av samma typ som fel 4 måste du hitta i ditt system. I övrigt fokuserar du testerna för att hitta de fel som har stor påverkan på systemets huvudfunktioner och de fel som har stor sannolikhet att användaren stöter på. För att kunna hitta de fel som har stor sannolikhet att användaren stöter på kan man använda så kallade användningsprofiler. Användningsprofiler Användningsprofiler handlar om att etablera statistiska modeller som beskriver ett systems användande. Baserat på dessa modeller kan sedan testerna fokuseras på de delar av systemet som har högst sannolikhet att användas, det vill säga delar i vilka fel skulle ha stor synlighet. Detta är en av grundtankarna bakom statistical usage testing. Ett exempel på detta kan vara ett meddelandehanteringssystem som hanterar meddelanden via fast eller mobilt telenät. Systemets tjänstestruktur, det vill säga den funktionalitet som systemet erbjuder en användare, kan överföras till exempelvis en grafisk representation. Det finns ett antal möjliga alternativ, till exempel lämna meddelande, hämta meddelande, ändra användarinställningar (fraser, PIN-kod), hämta samtalsinformation etc. Alla dessa alternativ svarar mot val i en meny, och en grafisk representation kan utgöras av ett träd som beskriver menystrukturen (se bild 1). Baserat på dessa möjligheter sätts sannolikheter, baserat på driftstatistik hos tidigare system eller intervjuer med potentiella användare etc, för varje val (eller gren). Det medför att alla alternativ från rot till löv (som representerar en tjänst) associeras med en sannolikhet. Genom att genomföra sina tester enligt lövens sannolikheter säkerställer man att de fel som finns kvar i systemet har så liten exponering som möjligt för användarna. I bild 1 går det till exempel utläsa att sannolikheten för H: P(H) är 0.4 * 0.4 = 0.16, vilket är mycket högre än sannolikheten för N: P(N) som är 0.1*0.2 = Därmed kan det fastställas att det är viktigare att testa H innan N testas, eftersom fel i H kommer att ha större exponering än fel i N. Att sätta upp användningsprofiler kan vara applicerbart även i andra sammanhang, till exempel för att välja vilka konfigurationer som testerna ska köras på. Eftersom det ofta inte är realistiskt att testa alla konfigurationer är det viktigt att välja de mest sannolika. Sammanfattning Många organisationer har problem med effektiviteten i sin testverksamhet. De resurser som spenderas, spenderas många gånger i onödan, eller med otillfredsställande resultat eftersom det saknas genomtänkta strategier för test. Genom att fokusera på tidiga kravbaserade tester av krav i kombination med riskhantering, skapas förutsättningar för att reducera kostnaderna och därmed öka effektiviteten. Nr 1 mars

6 AV JAMES A. WHITTAKER Vad är test av mjukvara? Och varför är det så svårt? Copyright 2000 IEEE. Publicerad med tillstånd av IEEE. Ursprungligen publicerad i IEEE Software, januari/februari 2000, med namnet What Is Software Testing? And Why Is It So Hard?. Testning av mjukvara kan sägas vara den minst förstådda delen av utvecklingsprocessen. James A.Whittaker ser på problemen i fyra steg och visar varför det är så knepigt att eliminera fel (buggar) och varför testning är en ständig kompromiss. Alla programutvecklare vet hur frustrerande det är när användarna rapporterar programvarufel. När detta händer frågar sig utvecklaren ofrånkomligen: Varför upptäcktes inte detta under test? Oräkneliga timmar lades säkerligen på noggrann testning av hundratals eller tusentals variabler och kodrader, så hur kan ett fel ha undsluppit detta? Svaret kräver i första hand en närmare granskning av testning i utvecklingssammanhang. För det andra kräver det förståelse av den roll som spelas av mjukvarutestare och utvecklare två mycket olika funktioner. Vi antar att de fel användarna rapporterar förekommer i ett program som verkligen har felaktigheter. Svaret kan då bli något av dessa: Användaren körde otestad kod. Det är inte ovanligt att utvecklare till följd av tidsbrist släpper otestad kod kod i vilken användaren kan hitta fel. Ordningen i vilken programsatserna exekverades i verkligt bruk skiljer sig från den som testades. Denna ordning kan vara avgörande för om ett program fungerar eller ej. Användaren exekverade en kombination av otestade indata-värden. Kombinationen av indatavärden som tusentals användare kan exekvera i ett programs interface är helt enkelt för många för att alla ska kunna testas. Testare måste göra svåra val om vilka värden som ska testas och ibland väljer man fel. Användarens operativsystem har aldrig testats. Vi kanske kände till systemet, men hade aldrig tid att testa det. Kanske hade vi inte möjlighet att efterlikna användarens kombination av hårdvara, perifera enheter, operativsystem och applikationer i vårt testlabb. Företag, som till exempel gör mjukvara för nätverk, skapar knappast ett nätverk med tusentals noder i sitt testlabb trots att användare kan, och gör, detta. Med hjälp av en översikt av problemen och processen vid mjukvarutestning undersöker den här artikeln de problem testare står inför. De tekniska bekymmer som lösningarna måste tillgodose identifieras också. Jag undersöker även de existerande grupper av lösningar som används i praktiskt bruk. Testare och testprocessen För att kunna planera och utföra tester måste testarna titta på vad mjukvaran ska utföra, den indata som ges och hur dessa kan kombineras, samt den omgivning i vilken mjukvaran slutligen ska fungera. Denna svåra, tidskrävande process kräver sofistikerat tekniskt kunnande och riktig planering. Testare måste inte bara ha goda utvecklingskunskaper testning innebär ofta en hel del kodning utan även ha kunskaper i formella språk, grafteori och algoritmer. Faktum är att kreativa testare har använt många relaterade områden inom datalogin som hjälp vid testproblem, ofta med imponerande resultat. Även enkla program kan uppvisa hinder för testarna. För att få en klarare syn på några av de svårigheter mjukvarutester innebär ska vi närma oss testningen i fyra faser: 1. Modell av mjukvarans omgivning 2. Val av testscenarier 3. Körning och utvärdering av testscenarier 4. Mätning av hur testerna framskrider Dessa faser skapar en struktur för testarna, i vilken man kan gruppera relaterade problem som måste lösas innan man går vidare till nästa fas. Fas 1: Modell av mjukvarans omgivning Testaren har till uppgift att simulera interagerandet mellan mjukvaran och dess omgivning. Testare måste identifiera och simulera de interface ett mjukvarusystem använder och räkna upp de indata som passerar varje interface. Detta är kanske den mest fundamentala uppgift en testare möter, och det kan vara svårt med tanke på de olika filformaten, kommunikationsprotokollen och tillgängliga tredjepartsinterface. De fyra vanliga interfacen är följande: Mänskligt interface inkluderar alla de vanliga metoder med vilka människan kommunicerar med mjukvaran. Vanligast är GUI, men även äldre varianter som exempelvis kommandorad och menydrivet interface används fortfarande. Indata från perifera enheter att tänka på kan vara musklick, tangentbordsaktiviteter och indata från andra tillbehör. Testarna avgör sedan hur dessa data ska organiseras för att förstå hur de ska utgöra en bra testsvit. Mjukvaruinterface, med samlingsnamnet API, innebär sättet på vilket mjukvaran använder ett operativsystem, databas eller bibliotek. De tjänster dessa applikationer tillhandahåller är utformade som test för indata. Utmaningen för testare är att inte bara kontrollera de förväntade utan även de oväntade tjänsterna. Alla utvecklare förväntar sig till exempel att operativsystemet ska spara filer åt dem. Den funktion man inte tänker på är att operativsystemet meddelar när lagringsmediet är fullt. Även felmeddelanden måste testas. Filsystemsinterface finns alltid när mjukvaran läser eller skriver data till externa filer. En utvecklare måste skriva mängder av felkontrollkod för att veta om filerna innehåller korrekt data och format. Följaktligen måste testare konstruera eller generera filer med innehåll som är både korrekt och felaktigt och filer som innehåller varierad text och format. Kommunikationsinterface ger direkt tillgång till fysiska enheter (såsom drivrutiner, con- 6 Nr 1 mars 2003

7 trollers och andra inbyggda system) och behöver ett kommunikationsprotokoll. För att testa sådan mjukvara måste testare kunna generera både korrekta och felaktiga protokollströmmar. Testare måste sammanställa (och skicka till mjukvaran som testas) många olika kombinationer av kommandon och data i rätt paketformat. Testare måste därefter förstå det sätt på vilket användaren kan agera och som faller utanför den kontroll den testade mjukvaran utför. Konsekvenserna kan bli allvarliga om programmet inte är förberett. Exempel på situationer som testaren måste förbereda är de följande: Genom att använda operativsystemet raderar en användare en fil som en annan användare har öppen. Vad händer nästa gång programmet vill öppna denna fil? En enhet blir omstartad mitt i en pågående kommunikations-session. Kommer mjukvaran att förstå detta och reagera på rätt sätt, eller kommer den att hänga sig? Två programvarusystem konkurrerar om samma tjänst från en API. Kommer API:n att kunna serva båda korrekt? Varje applikations unika miljö kan resultera i ett betydande antal användarageranden som måste testas. Att ta hänsyn till När ett interface uppvisar problem av oändlig storlek och komplexitet står testaren inför två svårigheter: Han måste noggrant välja värden för alla variabla indata och han måste bestämma indatasekvens. När man väljer värden, bestämmer testaren värdena på individuella variabler och förser systemet med intressanta kombinationer när programmet accepterar multipla variabler som indata. Testare använder ofta tekniken med gränsvärdesanalys för att välja enstaka variabelvärden vid eller runt gränserna. Exempelvis är testning av minimum, maximum och nollvärde av ett bekräftat heltal en vanligt accepterad idé. Det gäller även värden som omger vart och ett av dessa områden, till exempel 1 och 1 (vilka ju omger nollgränsen). Värdet mellan gränserna behandlas som samma siffra, om vi använder 16 eller gör ingen skillnad för den mjukvara som testas. En mer komplex situation är att välja värden för multipla variabler som behandlas samtidigt och potentiellt påverkar varandra. Testare måste ta hänsyn till hela vektorprodukten av värdekombinationer. För två heltal räknar man med båda positiva, båda negativa, en positiv och en negativ och så vidare. När man ska bestämma sekvensen för indata har testare problemet med sekvensgeneration. Testare behandlar varje fysiskt indata och abstrakt händelse som symboler i ett formellt språk och definierar en modell av det språket. En sådan modell låter testaren visualisera ett antal möjliga tester, för att se hur varje test passar in i helheten. Den vanligaste modellen är en graf eller ett logikdiagram, men det finns många varianter. Andra populära modeller inkluderar standarduttryck och grammatik, verktyg från språkteori. Mindre vanliga är stokastiska processer och genetiska algoritmer. Modellen är en representation som beskriver hur indata och händelsesymboler kombineras för att ge syntaktiskt korrekta ord och meningar. Dessa meningar är indatasekvenser som kan appliceras på mjukvaran vid testning. Ta till exempel uttrycket Filemenu.Open, vilket ger en dialogruta för filval; filename, vilket representerar valet (kanske genom musklickning) av en existerande fil, samt ClickOpen och ClickCancel,som innebär knapptryckningar. Sekvensen Filemenu. Open filename ClickOpen är korrekt såväl som många andra. Sekvensen ClickCancel Filemenu.Open är inte möjlig därför att cancelknappen inte kan tryckas ner innan Nr 1 mars

8 dialogrutan har anropats. Modellen för ett formellt språk kan göra sådana distinktioner mellan sekvenser. Exempel på textredigering Vi kan representera korrekta användningar av filvalsdialogen i till exempel en textredigerare med standarduttycket: Filemenu.Open filename* (ClickOpen ClickCancel) Där står asterisken för Kleene stängoperatör, vilket indikerar att filename-aktiviteten kan förekomma noll eller fler gånger. Detta uttryck betyder att det först erhållna indatat är Filemenu.Open, följt av noll eller flera val av filnamn (med en kombination av musklick och tangentbord). Sedan trycks på antingen Öppna- eller Stängknapparna. Denna enkla modell utgör alla kombinationer av indata som kan förekomma vare sig de är begripliga eller inte. För att skapa en fullständig modell av mjukvarans miljö för hela textredigeraren, skulle vi tvingas representera sekvenser för användarinterfacet och operativsystemets interface. Vi behöver dessutom en beskrivning av korrekta och korrumperade filer för att fullständigt kunna undersöka filsystemets interaktion. En sådan uppgift skulle kräva en generös användning av dekomposition och abstraktion. Fas 2:Val av testscenarier Många domänmodeller och variabla partitioner representerar en oändlig mängd testscenarier, som alla kostar tid och pengar. Endast en undergrupp kan användas i ett realistiskt schema för mjukvaruutveckling, så hur väljer en smart testare? Är 17 ett bättre heltal än 34? Hur många gånger ska ett filnamn väljas innan man trycker på knappen öppna? Dessa frågor, som har många svar, är föremål för forskning. Testpersonal föredrar dock svar som relaterar till att täcka källkod eller dess indatadomän. Testare strävar efter täckning: täckning av koduttryck (köra varje källkodsrad minst en gång) och täckning av indata (prova varje externt genererad händelse). Detta är de minimikriteria testare använder för att bedöma hur komplett deras arbete är; följaktligen är de tester man väljer de som bäst visar täckningsmålen. Om det räckte med kod och täckning av in-datavärden skulle utsläppta program ha mycket få fel. När det gäller koden så är det inte de enskilda koduttrycken som intresserar testare utan körbara vägar: sekvenser av koduttryck som resulterar i en exekvering av mjukvaran. Dessvärre finns det en oändlig mängd vägar. När det gäller indatadomänen är det inte enskilda indata som intresserar testaren utan indatasekvenser som, sett till helheten, står för scenarier som mjukvaran måste agera på. Det finns en oändlig mängd av dessa också. Testarna går igenom dessa oändliga sätt för att komma fram till bästa möjliga adekvata testdatakriterier, som på ett lämpligt och ekonomiskt sätt ska representera alla de oändliga möjligheterna. Bäst och adekvat är något subjektivt: testare söker vanligen det sätt som upptäcker flest fel. (Hög och låg felfrekvens samt uttydning av dessa tas upp senare). Många användare och professionella kvalitetssäkrare vill gärna att testarna ska utvärdera scenarier som avser typisk användning, alltså det som oftast händer i verkligheten. Sådana tester säkerställer att mjukvaran fungerar i enlighet med specifikationen och att de vanligast förekommande felen har upptäckts. Vi kan till exempel titta på textredigeringsexemplet igen. För att testa verklig användning inriktar vi oss på redigering och formatering, eftersom detta är vad verkliga användare gör mest. För att hitta fel är dock de mer svårkodade funktionerna för figurritning och tabellredigering ett troligare ställe att leta på. Kriterier för exekvering av testvägar Kriterier för riktiga testdata riktar in sig på täckning av exekverbara vägar eller på täckning av indatasekvenser, men sällan på båda. Det vanligaste kriteriet för val av exekverbar väg fokuserar på att täcka upp kontrollstrukturer. Till exempel: Gör ett urval av testfall som exekverar varje koduttryck minst en gång. Gör ett urval av testfall som gör att varje grenstruktur (If, Case, While osv.) utvärderas med varje möjligt värde. Flödeskontroll är dock endast en aspekt av källkoden. Det mjukvaran egentligen gör är att flytta data från ett ställe till ett annat. Adekvata testdatakriterier och dessas täckning beskrivs i dataflow-familjen. Till exempel: Gör ett urval av testfall som initialiserar varje datastruktur och sedan följaktligen används. Slutligen, felsådd, som är mer uppmärksammat av forskare än av praktiker, är intressant. Denna metod innebär att fel avsiktligen inplanteras i källkoden. Sedan utformas testscenarier för att finna dessa fel. Genom att finna de inplanterade felen finner testaren i bästa fall även riktiga fel. Ett kriterium enligt följande är alltså möjligt: Gör ett urval av testfall som visar alla de inplanterade felen. Kriterier för test av indatadomän Kriterierna för att täcka en indatadomäns område omfattar alltifrån en enkel täckning av ett interface till mer komplicerade statistiska mätningar. Gör ett urval av testfall som innehåller varje fysisk indata. Gör ett urval av testfall som gör att varje interfacekontroll (fönster, meny, knapp, osv.) kommer att stimuleras. Kriteriet diskriminering kräver slumpvis val av indatasekvenser, tills dessa statistiskt representerar hela den oändliga indatadomänen. Gör ett urval av testfall som har samma statistiska egenskaper som hela indatadomänen. 8 Nr 1 mars 2003

9 Gör ett urval av vägar som sannolikt kommer att exekveras av den typiske användaren. Sammanfattning Testforskare studerar algoritmer för val av minimala testsviter som möter kriterierna för exekvering av vägar och indatadomäner. De flesta forskare anser att det är klokt att använda flera kriterier när man tar beslut om att släppa en produkt. Experiment som jämför hur adekvata kriterier för testdata är behövs, såväl som nya kriterier. Testare bör vara medvetna om vilka kriterier som är inbyggda i deras metoder, samt förstå de begränsningar dessa kriterier har när man rapporterar resultat. Vi återkommer till adekvata testdata i den fjärde fasen (som handlar om testmätning) eftersom kriterier även fungerar som ett mått på hur fullständigt ett test är. Fas 3: Köra och utvärdera testscenarier Efter att ha identifierat lämpliga test brukar en testare konvertera dessa till exekverbar form, ofta som kod, så att testscenarierna simulerar typiskt agerande av en användare. Då det kräver mycket arbete att manuellt tillämpa testscenarier och fel lätt uppstår, brukar testare försöka automatisera detta så långt som möjligt. I många miljöer kan man använda automatiserade applikationer med hjälp av kod som simulerar användare. Det finns också hjälpfunktioner för detta. Fullständig automatisering kräver att man simulerar varje källa för indata och destinationer för hela operativmiljön. Testare inkluderar ofta datainsamlingskod i den simulerade miljön som så kallade taggar, det vill säga en resultatkontroll. Dessa taggar tas bort när mjukvaran släpps, men när testscenariot körs ger de värdefull information som hjälper testare att identifiera missar och isolera fel. Utvärdering av scenarier, den andra delen av fas 3, är svår att genomföra (och ännu värre att automatisera). Utvärdering innebär jämförelser mellan verkliga utdata, som ett resultat av körda testscenarier, och förväntade utdata såsom dessa dokumenterats i en specifikation. Specifikationen antas vara riktig; avvikelser är misslyckanden. I praktiken är det svårt att göra denna jämförelse. Teoretiskt är det omöjligt att jämföra två godtyckliga, Turing-körbara funktioner (för att se överensstämmelse). För att återgå till exemplet med textredigering: om utdata ska vara markera ett felstavat ord, hur avgör man då om varje felstavning har upptäckts? Denna svårighet är skälet till varför verklig-mot-förväntad-jämförelser vanligen görs av ett mänskligt orakel, en testare som visuellt ser på skärmdata och omsorgsfullt analyserar utdata. Två sätt att utvärdera ditt test När det gäller problemet med att utvärdera tester jobbar forskarna med två vägar: formalism och inbäddad testkod. Formalism innebär huvudsakligen ett hårt jobb med att formalisera sättet på vilket specifikationer skrivs, och hur design och kod härleds från dessa. Både objektorienterad och strukturerad utveckling innehåller mekanismer för såväl formellt uttryckta specifikationer som för att förenkla jämförelser mellan förväntat och verkligt resultat. Industrin har vanligen tagit avstånd från formella metoder. Nr 1 mars

10 Trots detta är en bra specifikation, även en informell sådan, till mycket god hjälp. Utan en specifikation kommer testare troligen endast att finna de mest uppenbara felen. Dessutom betyder frånvaron av en specifikation att massor av tid går förlorad när testare rapporterar ospecificerade funktioner som fel. Det finns huvudsakligen två typer av inbäddad testkod. Den enklaste typen är testkod som exponerar vissa interna dataobjekt eller tillstånd och gör det lättare för ett externt orakel att bedöma korrektheten. När den är införd är en sådan funktion osynlig för användaren. Testare kan se testkodsresultaten med exempelvis en test-api eller en debugger. En mer komplex typ av inbäddad kod är självtestande program. Detta innebär ibland att flera lösningar av problemet kodas och en lösning får kontrollera den andra, eller att inverterade rutiner som återställer operationerna skrivs. När en operation är utförd och sedan återställs, ska mjukvarans status vara samma som före operationen. I denna situation är oraklet inte perfekt, det kan finnas ett fel i båda operationerna, där det ena felet döljer det andra. Regressionstestning Efter att testarna överlämnat framgångsrikt återupprepbara felindikationer till utvecklarna, brukar dessa vanligen ta fram en ny version av mjukvaran (i vilken felet förhoppningsvis är borttaget). Testningen fortsätter med följande versioner till dess att en version anses vara klar att släppa. Frågan är hur mycket omtestning (kallad regressionstestning) av version n som är nödvändig med användning av de tester som gjordes på version n 1? Varje särskild ändring kan (a) rätta endast det problem som rapporterats, (b) misslyckas med att rätta problemet, (c) rätta till problemet men förstöra något som fungerat tidigare, eller (d) misslyckas med att rätta till problemet och förstöra något annat. Med tanke på dessa möjligheter förefaller det välbetänkt att köra om varje test från version n 1 på version n innan något nytt testas, trots att en sådan procedur är kostnadskrävande. Nya mjukvaruversioner har dessutom ofta många nya funktioner förutom rättade fel, så regressionstestning kommer att stjäla tid från testningen av ny kod. För att spara resurser har testarna ett nära samarbete med utvecklarna för att prioritera och minimera regressionstestningen. En annan nackdel med regressiv testning är att denna (tillfälligt) kan förändra avsikten med testdatakriteriernas korrekthet som valts ut i den tidigare testvalsfasen. När regressiva tester görs försöker testare endast att påvisa frånvaron av fel och tvinga applikationen att uppvisa ett specifikt uppförande. Resultatet av detta är att korrektheten i testdatakriterierna, vilket hittills styrt testvalen, nu ignoreras. Istället måste testarna säkerställa att en pålitlig ändring av koden har gjorts. Relaterade problem Det bästa är när utvecklare skriver kod med testningen i åtanke. Om koden är svår att testa och verifiera bör den skrivas om för att bli mer testbar. På liknande sätt bör en testmetod bedömas efter hur mycket stöd den ger för automatisering och orakelproblem. Alldeles för många metoder ger ringa ledning på något av områdena. Ett annat problem för testare vid test och verifiering är koordineringen av debuggeraktiviteter med utvecklarna. Eftersom systemfel identifieras av testarna och diagnostiseras av utvecklarna, uppstår två frågor: om felreproduktion och återexekvering av testscenariot. Felreproduktion är inte så enkelt som det kan verka. Den självklara lösningen är förstås att köra det problematiska testet och observera det felaktiga uppförandet igen. Dock innebär en omkörning av ett test ingen garanti för att exakt samma omständigheter skapas. När man kör om scenarier krävs att vi känner till exakt status för operativsystemet och all tilläggsmjukvara, Exempelvis kräver klientserver-applikationer att man återskapar de förhållanden som omgav både klienten och servern. Dessutom måste vi känna till status för testautomatiken, perifera enheter, samt eventuella applikationer i bakgrunden som körs lokalt eller över ett nätverk och kan påverka den applikation som testas. Det är inte så konstigt att en av de vanligaste kommentarerna som görs i ett testlabb är: Så här uppförde det sig inte förut Fas 4:Att mäta testningens framsteg Anta att jag är testare och en dag frågar min chef: Vad är statusen på din testning? Testare får ofta den frågan men är dåligt rustade att svara. Skälet är att dagens praxis är att räkna saker. Vi räknar hur mycket indata vi använt, den procent av koden vi täckt och det antal gånger vi startat applikationen. Vi räknar hur många gånger vi avslutat applikationen korrekt, antal missar vi funnit och så vidare. Uttydningen av sådan räkning är svår; är det bra eller dåligt när man finner mycket missar? Svaret kan vara varken eller. Ett stort antal fel kan betyda att testningen var noggrann och mycket få fel återstår. Det kan även betyda att mjukvaran helt enkelt har massor av fel och trots att många hittats, så återstår flera. Eftersom det ger liten insikt i testningens framsteg att räkna åtgärder, så förstärker många testare dessa data genom att besvara frågor som utformats för att säkerställa hur kompletta de funktionella och strukturella testerna är. För att kontrollera hur komplett en struktur är kan testare till exempel ställa följande frågor: Har jag testat för vanliga programmeringsfel? Har jag kontrollerat all källkod? Har jag tvingat fram initialisering och användning av alla interndata? Har jag hittat alla planterade fel? För att kontrollera hur komplett en funktion är kan testare ställa följande frågor: 10 Nr 1 mars 2003

11 Har jag tänkt igenom de sätt på vilket mjukvaran kan göra fel och valt tester som visar att den inte gör fel? Har jag använt alla indata? Har jag utforskat mjukvarans alla möjliga tillstånd? Har jag kört alla scenarier jag förväntar mig att en användare ska exekvera? Dessa frågor (huvudsakligen korrektheten i testdatakriterier) är till hjälp för testare, men att bestämma när man ska sluta testa, och släppa ut en produkt, är mer komplext än så. Testare vill ha kvantitativa mätningar av hur många fel som finns kvar i mjukvaran och risken för att dessa ska upptäckas på fältet. Vi kan närma oss det kvantitativa problemet strukturellt och funktionellt. Testbarhet Jeffrey Voas har från en strukturell utgångspunkt föreslagit testbarhet-stabilitet (testability) som ett sätt att bestämma komplexiteten i testningen av en applikation. Tanken att antal programrader är ett mått på hur svår testningen av programmet är, är förlegad. Saken är mycket mer dunkel och det är här testbarheten kommer in. När en produkt har hög testbarhet är den lätt att testa och följaktligen lätt att hitta felen i. Vi kan då övervaka testningen och se att eftersom antalet fel är färre, så är det mindre troligt att det finns många oupptäckta fel. Låg testbarhet kräver många fler tester för att kunna dra samma slutsatser; vi förväntar oss att felen är svårare att finna. Testbarhet är en fängslande idé, men ännu bara i sin linda; inga data om dess förutsägande möjligheter har ännu publicerats. Tillförlitlighetsmodeller Hur länge kommer mjukvaran att fungera innan något fel uppstår? Hur dyrt blir det att underhålla den? Det är definitivt bättre att ta reda på detta medan du fortfarande har mjukvaran i testlabbet. Från en funktionell synpunkt är tillförlitlighetsmodeller (matematiska modeller av testscenarier som försöker förutse framtida felmönster baserat på använda data) väl etablerade. Dessa modeller försöker alltså förutse hur mjukvaran kommer att uppföra sig på fältet baserat på hur den uppförde sig under testningen. För att åstadkomma detta behöver de flesta tillförlitlighetsmodeller en specificerad användningsprofil, en beskrivning av hur användare förväntas ge indata. För att kunna beräkna sannolikheten för ett misslyckande gör dessa modeller antaganden om den underliggande sannolikhetsfördelningen för förekomsten av fel. Såväl forskare som praktiker är skeptiska till att sådana profiler kan sammanställas korrekt. Dessutom har antaganden gjorda av vanliga trovärdighetsmodeller inte blivit teoretiskt eller experimentellt verifierade utom i speciella applikationsdomäner. Trots det har framgångsrika fallstudier visat att modellerna är pålitliga. Mjukvaruföretag står inför stora utmaningar vid testning av sina produkter, och utmaningarna växer varefter mjukvaran blir alltmer komplex. Det första och viktigaste att inse är komplexiteten vid testning och att ta detta på allvar. Mitt råd är: anställ den smartaste personal du kan hitta, hjälp dem att få de verktyg och den utbildning de behöver för att lära sig yrket och lyssna på dem när de berättar om kvaliteten på din mjukvara. Att ignorera dem kan vara det dyraste misstag du någonsin kommer att göra. Testforskare står på samma sätt inför utmaningar. Mjukvaruföretagen är angelägna om att finansiera bra forskningsidéer, men kraven på mer praktiskt och mindre akademiskt arbete är stora. Det är nu dags att knyta akademisk forskning till verkliga industriprodukter. Då blir vi alla vinnare. James A.Whittaker forskar och undervisar i datavetenskap på Florida Institute of Technology. Forskningen är inriktad mot test av mjukvara, datasäkerhet och sårbarhet inom dataområdet. Han är författare till boken How to Break Software och har fått publicerat över 50 vetenskapliga artiklar inom mjukvaruutveckling och datasäkerhet. Nr 1 mars

12 12 Nr 1 mars 2003

13 AV STIG URSING Test av felhantering i distribuerade realtidssystem Allt fler tillämpningar styrs av distribuerade realtidssystem. Mer kritiska tillämpningar leder till behov av mer omfattande test. Ett mått på omfattning av test kan beskrivas som täckning, som vi alltså använder för att kunna planera och rapportera testerna. Vanligtvis använder vi täckning med avseende på krav för att bedöma tillräckligheten. Men kritiska tillämpningar innebär också att systemen i högre utsträckning är konstruerade för att kunna hantera fel. Kravställningen på felhanteringsmekanismer är ofta begränsad. Detta leder till att kravtäckning inte är en framkomlig väg för att försäkra oss om att ett kritiskt system har testats i tillräcklig omfattning. Ett alternativt mått på täckning är då produkttäckning, det vill säga man utgår från den implementerade produkten istället för kraven på den. I artikeln förklaras olika former av test av felhantering med stöd i användbara testfall. Testfallen är baserade på de element som ingår i produkten eller strukturen för ett distribuerat realtidssystem. Vi skapar förtroende med de beskrivna testfallen som förutsättning. Felhanteringsmekanismer För inbyggda realtidssystem är felhantering en väsentlig del av konstruktionen. Denna är oftast bara begränsat kravsatt, antingen som exceptions i use-case eller på formen Det ska finnas felhantering. Att kraven är få och otydliga innebär att de inte har dokumenterats på ett tillgängligt sätt och att en analys av om kraven är uppfyllda inte kan genomföras. Verifiering och validering av felhanteringsmekanismerna måste alltså göras på annat sätt. I dessa mekanismer ingår de delar av systemet som stödjer funktioner som feldetektering (fault detection), felfiltrering (error masking), återhämtning (recovery), omkonfigurering (system reconfiguration) och rapportering. Om dessa mekanismer är ineffektiva eller utför oönskade handlingar kan det ge allvarliga effekter på systemets tillförlitlighet. Även en begränsad minskning av till exempel feldetekteringsförmågan kan ge avsevärda konsekvenser på tillförlitligheten och andra områden. Felhanteringsmekanismer kan inte prövas under normalanvändning med rättfall. Vi måste skapa situationer med konstruerade eller pålagda fel, felfall, för att verifiera att felhanteringsmekanismerna är implementerade. I många fall ingår det att tröskelvärden i felhanteringen måste kalibreras. Exempelvis så ska ingen åtgärd göras för ett visst antal sporadiska fel men fel signaleras vid ett större antal feldetekteringar. Denna kalibrering syftar till att balansera den svåra avvägningen mellan hög säkerhet (signalera för alla fel) och hög tillgänglighet (filtrera bort fel). Ett typiskt exempel är att särskilja mellan brus på en givare och fel i givaren. Slutligen finns det ett behov av att validera att felhanteringen uppfyller kundens behov. Några egenskaper som kan ingå är detekteringsförmåga (sannolikheten att ett fel detekteras givet att det har inträffat), fördröjning till detektering (tiden från att ett fel inträffat tills det är detekterat) och fördröjning till åtgärd (tiden från det att felet är detekterat tills systemet är omkonfigurerat). Vid test av felhantering måste vi alltså på grund av begränsad kravsättning testa i annat syfte än att visa att kraven är uppfyllda. Antagandet att systemet bara ska kunna hantera förväntade indata är inte tillräckligt. I test av alla typer av system ingår det i större eller mindre omfattning att lägga på avvikelser från förväntade situationer, både på gränssnittet och internt. Ett annat ord för denna teknik är felinjicering. När den formaliseras betraktas den som svårtillämpad och exklusiv för säkerhetskritiska tillämpningar. Men med stöd i form av en checklista är vår erfarenhet att den blir tillgänglig och användbar för ett större antal. Testfall Ett stöd vid konstruktion av felfall baserade på produktstrukturen och som även kan användas för analys av täckningen av testerna ges i bild 1. Bussar och I/O gränssnitt o Felaktigt meddelande o Ogiltigt meddelande o Uteblivet meddelande o Felaktigt innehåll i meddelande o Ogiltigt innehåll i meddelande o Felaktigt signalvärde från sensor o Ogiltigt signalvärde från sensor o Utebliven signal från sensor o Hög ogiltig last på buss (babbling idiot) o Ogiltiga fördröjningar på bussen o Kortslutningar och avbrott Systemstart, omstart, programvaruladdning och nedstängning: o Felaktig eller ogiltig startsekvens o Avbruten startsekvens o Felaktig eller ogiltig omstart o Avbruten omstart o Felaktig eller ogiltig nerladdning o Avbruten laddning o Felaktig nedstängning o Avbruten nedstängning Funktioner: o Funktionsanrop i ogiltigt tillstånd o Ogiltig interaktion mellan funktioner o Uteblivet anrop av funktion o Överlast (för hög intensitet i funktionsanrop) o Ogiltig svarstid Nod eller delsystem o Omstart o Frånvaro o Okonfigurerad, felkonfigurerad eller oinitierad o Spänningsavbrott o Inkonsistenta systemtillstånd Tillstånd och övergångar o Ogiltiga tillstånd o Ogiltiga övergångar o Genvägar mellan tillstånd (sneak paths) Spänningsmatning o För hög spänning o För låg spänning o Kortvariga avbrott Bild 1:Testfall för felhantering Nr 1 mars

14 En sådan lista kan kallas en testkatalog, och den är speciellt användbar i matrisform. Kolumnerna i matrisen är de testfall som man använder om och om igen, matrisens rader är testobjekten. En effektiv katalog betingar ett stort värde för organisationen. Giltiga indata betyder alla indata för vilket systemet förväntas ha ett korrekt beteende, ogiltiga betyder då att de avviker från det specificerade värdeområdet. En parameter som representerar temperaturen från en sensor kan exempelvis ha ett värde som är lägre eller högre än vad som är specificerat för sensorn. Felaktiga indata betyder att indata ligger inom giltigt värdeområde men avviker från normalsituationen. Dessa illvilliga fel är besvärligare fall, då det gäller att identifiera orimliga värden eller ovanliga situationer. Ett enstaka högt men giltigt värde från temperatursensorn ska hanteras på ett visst sätt, en kontinuerlig höjd temperatur hanteras på ett annat sätt. De fel man först kommer att tänka på är ofta elektriska eller hårdvarurelaterade. Samtidigt vet vi av erfarenhet att många fel har sin orsak i programvaran, exempelvis beräkningsfel eller fel i villkor. Det är alltså viktigt att man skapar sig en uppfattning av vilken typ av fel man vill detektera, en felmodell. Olika konstruktions- och utvärderingsmetoder resulterar i vissa typer av fel. Från tidigare projekt har vi erfarenheten att en viss typ av fel är allvarliga, risker i den tänkta användningen av systemet medför kanske fokusering på andra typer av fel. Urval Var för sig blir mängden testfall i bild 1 omfattande, med kombinationer blir det ohanterligt. Strategin blir då: 1. Testa på så låg systemnivå som möjligt, det ger möjlighet till parallella aktiviteter samtidigt som kombinatoriken begränsas. 2. Använd alternativa metoder (analyser och granskningar) för att fånga klasser av fel och för att undvika att fel kommer in i implementationen. I många fall är det dock svårt att se att någon annan metod för utvärdering än dynamisk exekvering (test) ger tillräckligt förtroende. En direkt observation av resultatet av ett test, med till exempel fördröjda indata, är svårt att ersätta. Det finns två olika testtekniker att rekommendera för pålagda (injicerade) fel. Den ena fokuserar på potentiella problem, så kallat riskbaserat test, den andra fokuserar på genomförandet, så kallat utforskande test. Riskbaserat test utgår från en riskanalys med syfte att finna allvarliga felyttringar. Man ställer sig repetitivt frågan, Vad kan gå fel här? och söker efter svagheter, hot och konsekvenser. I de fall en FMEA har utförts, är det självklart en viktig ingång till urvalet vid riskbaserat test. FMEA är en analysmetod som utgår från att fel på låg nivå ansätts och eventuella konsekvenser utvärderas. En del tester av felhanteringsmekanismer brukar utgöras av så kallade utforskande test. Testfallen har då inte utfall som kan specificeras i förväg, utan resultatet får utvärderas mot oönskade händelser (feared events). Det innebär ofta att man planerar, konstruerar och kör sina tester i en aktivitet. Man utvecklar alltså testfall baserat på det man lär sig. Detta kan med fördel utföras som parvis testning, när två testare arbetar tillsammans och växelvis delar genomförandet, vilket samtidigt är ett sätt att skapa en kreativ och stimulerande miljö. En faktor som i hög grad påverkar förmågan att utföra test av felhanteringsmekanismer är observerbarhet och styrbarhet. Observerbarhet: möjligheten att läsa signaler som reflekterar systemets tillstånd Styrbarhet: möjligheten att lägga på signaler som ställer systemet i ett visst tillstånd För att skapa förtroende för att omfattningen av test är tillräcklig, mäter vi täckningen och påverkar utvecklingsarbetet för högre testbarhet. Test av egenskaper som säkerhet, tillgänglighet och tillförlitlighet ställer stora krav på förståelse för kundens behov. En förutsättning för att kunna kommunicera och rapportera omfattningen av genomförda tester är att vi mäter med en överenskommen måttstock. En överenskommen testkatalog ger stöd för uttalandet Nu är jag nöjd. Stig Ursing är seniorkonsult inom test och dependability engineering på. 14 Nr 1 mars 2003

15 AV SVEN WENNERSTRÖM Miljölagar driver på testutvecklingen När Lars Wallin arbetade med flygmotorerna i JAS-projektet föddes idén till ett nytt sätt att arbeta med motortester. Idéerna tog han med sig till arbetet med diagnossystem i Saab Automobiles bilmotorer. En av skillnaderna mellan bil- och flygmotorer, berättar Lars, är att bilmotorernas styrsystem är betydligt mer avancerade. Programvaran som finns i alla moderna bilmotorer innehåller inte bara funktioner för motorstyrningen. Ungefär hälften av programvaran svarar för att hela tiden övervaka hur motorn och bilen uppför sig. Diagnosfunktionerna, som blir allt mer omfattande, har drivits fram av striktare miljökrav för bilar. Emissionskraven gäller för hela bilens livslängd och för att kunna uppfylla dem finns ett system med sensorer som hela tiden styr och övervakar motorn. Data från sensorerna jämförs med en modell av hur bilen ska uppföra sig. Om sensorerna läser av värden som tyder på funktionsfel varnas föraren genom att en varningslampa tänds. Det är främst de hårda miljölagarna i Kalifornien som sätter press på biltillverkarna, säger Lars Wallin. Reglerna kräver att alla felaktigheter som riskerar att leda till ökade utsläpp upptäcks och rättas till. Hela bilserier kan tvingas tillbaka till fabriken för åtgärdande och det har hänt att biltillverkare har blivit stämda på miljardbelopp för att de inte uppfyllt lagkraven. Att misslyckas med att uppfylla miljökraven är alltså kostsamt. För en liten biltillverkare som Saab skulle det kunna leda till en ekonomisk katastrof om bilarnas diagnossystem inte fungerar som de ska. Det är alltså i högsta grad affärskritiskt att systemen fungerar som de ska och att vi lyckas verifiera att bilarna uppför sig som det är tänkt i utvecklingsarbetet, säger Lars Wallin. Svårt hitta normalanvändning Att verifiera hur en bil beter sig och skapa fungerande diagnossystem är särskilt krävande. För bilar är det nästan omöjligt att hitta en normalanvändning. Testernas körcykler ska avbilda olika användningsområden för bilarna, allt från ryckig stadstrafik till jämn motorvägstrafik. Men det finns fler faktorer att ta hänsyn till. Bilmodeller som säljs över hela världen utsätts för olika klimat med skiftande temperatur och luftfuktighet. Dessutom inverkar lufttrycket, och därmed på vilken höjd över havet bilen framförs. För att kunna bygga ett bra system måste vi alltså veta hur våra motorer uppför sig i alla möjliga situationer över hela världen, säger Lars Wallin. När bilmodellerna utvecklas testas först alla komponenter var för sig och slutligen testkörs hela bilen för att verifiera att allt fungerar som det är tänkt. Verifieringsarbetet för bilar är mycket intensivt. Bilens hela livscykel ska testas. För att täcka in så mycket som möjligt av det bilmodellen kommer att utsättas för under sin livslängd, körs testbilarna över mil på Nr 1 mars

16 Lars Wallin överför idéer från JAS Gripenprojektet till testverksamheten på Saab Automobile. olika håll i världen under de årslånga verifieringscyklerna. CAN-buss, systembussen för motorstyrning paket. Flight recordern kopplas till bilens Traditionellt genomförs testerna av ingenjörer som åker runt i världen och kör bilarna Upp till 150 kanaler kan läsas in samtidigt. och andra funktionskritiska enheter i bilen. fullproppade med mätinstrument, förklarar De flesta kanaler läses in med ganska låg frekvens, men systemet tillåter att upp till 30 Lars Wallin. Egentligen är det ett ganska ineffektivt sätt att bedriva test på, eftersom ingenjörerna ägnar en stor del av sin tid åt att vissa villkor och när villkoren uppfylls löser triggers läggs in. Varje trigger svarar mot köra bil istället för att analysera testdata. triggern ut och den aktuella kanalen läses in Det Lars Wallin vill åstadkomma och med upp till tio gånger så hög frekvens. genomför på Saab Automobile, är att flytta testingenjörernas arbete från testbanorna runt Förenklad felsökning om i världen in till skrivborden. Istället för Vi använder systemet med flight recordern i att ingenjörerna följer med bilarna till testbanorna, ska testfordonen framföras av chauffö- är i verifieringen, men vi använder också sys- tre faser i vår utveckling. Det tyngsta arbetet rer och alla mätdata spelas in och skickas till temet tidigare i utvecklingen, när vi testar på ingenjörerna för analys. komponentnivå mot motorsimuleringar. Vi använder en flight recorder för att Slutligen använder vi flight recordern i felsökningsarbetet. registrera mätdata från testbilarna. Den stora vinsten med att flytta in mycket av arbetet, är I felsökningen kommer möjligheten att att vi kan köra testerna parallellt på ett sätt använda triggers väl till pass. Ofta har de som var omöjligt när ingenjörerna själva som felsöker en god uppfattning om vad det körde bilarna. Vi kan samtidigt testa bilar i är som går fel. Genom att sätta triggers som flera olika klimat, vilket förkortar verifieringstiden avsevärt. Dessutom siktar vi på att går det att läsa ut mer av den information reagerar på de faktorer som spelar in på felet, kunna halvera antalet testbilar, vilket också som är intressant för felet. Dessutom markeras relevant information i datamaterialet som skulle innebära en stor besparing. Den flight recorder som används heter Frec ska analyseras. 2000, en svart låda stor som ett halvt mjölk- På det här sättet kan vi samla in data från flera bilar samtidigt. Vi kan utrusta bilar som får rulla i verklighetstrogen trafik. Systemet har vid något tillfälle till och med monterats i Saabs egna tjänstebilar. Ett liknande system för att samla in mätdata från bilens sensorer fanns redan när modellen 9-5 utvecklades i mitten av 90-talet. Data hämtades då från buffertarna i motorns styrsystem och behandlades i Microsoft Excel. Ganska snart stod det klart att arbetssättet med att hämta data från motorns egna system inte räckte till. Med Frec 2000 ökade datamängderna avsevärt och all data lagras nu i stället i en gemensam databas och analyseras med matematiska verktyg. Informationen vi samlar in påminner en del om de data som läkemedelsföretagen får in under sin utvärdering av nya preparat. När vi letade efter analysverktyg vände vi oss bland annat till läkemedelsindustrin och fann det statistiska verktyget Spotfire, som är bra på att analysera stora datamängder. Till mer avancerade modelleringsarbeten använder vi också MatLab. Effektiva tester avgör framtiden I framtiden ligger att flytta in mer och mer av testarbetet till skrivborden och att ytterligare förfina modellerna för hur bilen uppför sig. En begränsande faktor är idag att datakraften i bilen är begränsad och inte tillåter de mest avancerade beräkningarna. Istället används filter som bygger på statistiska data för att särskilja ett felaktigt beteende från naturliga avvikelser. Arbetet med att effektivisera testerna är på många sätt avgörande för Saab som liten tillverkare av motorer. Lars Wallin tror att kunderna har speciella förväntningar på motorer från Saab: Våra kunder förväntar sig ett stort kraftuttag ur en relativt liten motor. Som en liten tillverkare av motorer kan vi bara uppfylla det genom att vara effektiva i utvecklingen och testverksamheten. 16 Nr 1 mars 2003

17 AV SVEN WENNERSTRÖM När fel inte får förekomma För patienter vars njurar inte längre fungerar är dialys villkoret för att kunna leva vidare. Blodet renas i en maskin utanför kroppen och förs sedan tillbaka till patienten. Ett av de största företagen som utvecklar och säljer dialysutrustning är Gambro, med delar av sin utveckling och produktion i Lund. Drygt svenska patienter får sitt blod renat genom hemodialys. Det innebär att blodet leds ut ur kroppen, renas i en konstgjord njure dialysfiltret för att sedan föras tillbaka in i patienten igen. Kraven på dialysmaskinen är naturligtvis högt ställda. En maskin som kopplas till patientens blodomlopp får absolut inte skada patienten genom ett felaktigt beteende. Strax norr om Lund, i utkanten av forskarbyn Ideon, ligger Gambro. Jag kommer dit en lerig skånsk vinterdag för att ta reda på mer om hur test och validering går till i ett medicinteknikföretag med extremt högt ställda krav på hur produkterna ska fungera. Utvecklingen och tillverkningen ligger i Monitor Division. Inom Monitor Division finns avdelningen Design Quality, DQ, som ansvarar för verifiering och validering av produkterna. De huvudsakliga uppgifterna för DQ är att granska och godkänna alla nya produkter och förändringar som görs i existerande produkter. I arbetet ingår att granska kravdokumentationen och delta i de genomgångar, reviews, som görs under utvecklingsarbetet. Magnus Grén är chef för avdelningen: Vi säkerställer att alla våra produkter uppfyller de regler som finns för medicinteknisk utrustning. Både det amerikanska regelverket från FDA och det europeiska medicintekniska direktivet har högt ställda krav som vi måste följa. För att uppfylla de olika regelverken utnyttjas bland annat standarder, till exempel från ISO och IEC, som överensstämmer med kraven i regelverken. Standarderna ska vara erkända av respektive regelverk och kan omfatta såväl produktrelaterade krav som Gambros dialysmaskiner kan innebära skillnaden mellan liv och död för patienter med skadad njure. En sådan maskin måste helt enkelt fungera felfritt, vilket ställer stora krav på testarna. Magnus Grén är ansvarig för avdelningen som jobbar med verifiering och validering. processkrav, till exempel för riskhantering och utveckling. V-modell för nyutveckling Nya produkter utvecklas efter den så kallade v-modellen: Med en marknadsspecifikation som utgångspunkt analyseras kraven och överförs till en teknisk specifikation på systemnivå. Dessa krav bryts sedan ned till kravspecifikationer och konstruktionsbeskrivningar för delsystem, moduler och komponenter. DQ kommer in i utvecklingsarbetet redan när kravspecifikationen upprättas på systemnivå, säger Magnus Grén. Vi försöker så tidigt som möjligt granska kraven med avseende på entydighet, testbarhet, spårbarhet och genomförbarhet. Vi bidrar också till bevakningen av vilka standarder som är tillämpbara på produkten och att kraven i standarderna efterlevs under hela utvecklingsarbetet. Efter utförd implementation utförs verifiering, testning och integrationstestning på modul- och delsystemnivå av utvecklingsingenjörerna. DQ fungerar som ett stöd och granskar hur testerna utförs. Vi granskar hur testerna är utformade: vilka krav som ställs, att acceptanskriterierna är entydigt utformade och om testerna verkligen täcker in allt som måste testas, säger Magnus Grén och påpekar att en viktig del i arbetet är regelbundna granskningar, reviews: Jag håller granskning som metod väldigt högt. Hur duktig man än är så ser fler par ögon alltid mer. En annan fördel ur vår synvinkel är att vi via granskningen på moduloch delsystemnivå lär oss hur produkten är uppbyggd. Den kunskapen är viktig när vi ska utföra den slutgiltiga produktvalideringen. För att kontrollera att vissa av standarderna är uppfyllda anlitas externa testhus som komplement till de egna verifieringarna. Magnus Grén anser att det ger testerna Nr 1 mars

18 Gambros AK 200 ULTRA S, framtagen och tillverkad på Gambro i Lund. ytterligare trovärdighet. Att samarbeta med externa parter som är väl kända och erkända för sin verksamhet kan också ge ett mervärde till produkten när den ska marknadsföras. Formellt överlämningsmöte När utvecklingsprocessen har nått så långt att produkten existerar som ett system och tillverkningsprocessen är validerad, inleds produktvalideringen med ett formellt överlämningsmöte mellan utvecklingsavdelningen och DQ. Valideringen är den stora biten för oss på DQ. Det är då vi bland annat testar produkten mot krav baserade på avsedd användning och användarnas behov. På överlämningsmötet går vi igenom en checklista för att kontrollera att alla tester och verifieringar är utförda enligt vår utvecklingsprocess. På så vis försöker vi minimera risken att identifiera fel under produktvalideringen eftersom de problem som vi hittar i den fasen ofta är dyra att åtgärda. Som en del i valideringen säkerställs också att alla tester och verifieringar är utförda enligt Gambros utvecklingsprocess och med godkänt resultat. Valideringen utförs på systemnivå, varför testerna oftast är så kallade black-box-tester; produkten betraktas inte som en uppsättning delsystem, utan testerna är inriktade på hur produkten ska fungera när den används av kunderna. Som en del av valideringen utförs bland annat ett stort antal simulerade behandlingar. Valideringen sker alltid på serietillverkade produkter eller ekvivalenta. Slutligen CE-märks produkterna. Serviceteknikerna involveras Att testa nya produkter är inte hela arbetet för DQ. Varje år inkommer mellan 500 och 600 ändringsmeddelanden på existerande produkter. Det som föranleder förändringar kan vara förslag från produktionsavdelningen, önskemål om nya funktioner från marknadsavdelningen eller klagomål från kunder. Samtliga förändringar i dialysapparaterna ska testas och godkännas. När en förändring ska genomföras är det första steget att genomföra en problemanalys. Ofta är det svårt att utifrån rapporten veta exakt vad i maskinen som ska ändras. Det första steget är alltså att ta reda på vilket problem som ska lösas. Processen som används vid ändringar bygger i stort sett på samma principer som den som används för nyutveckling. Problemställningen leder fram till en System Change Request, CR, det vill säga en kravspecifikation som granskas och godkänns av DQ. Efter implementering testas ändringen för att säkerställa att den uppfyller kraven i CR och att den inte lett till oönskade sidoeffekter på övriga delar av systemet. Dessa tester granskas och godkänns också av DQ. I vissa fall utnyttjas även tekniker från säljbolagen i olika länder för att på ett tidigt stadium testa införda ändringar. På så sätt tas erfarenheter till vara från dem inom Gambro som arbetar närmast slutkunden. Som sista steg utför sedan DQ valideringen. Att serviceteknikerna är involverade under testningen är av stort värde. Dels har de med sin erfarenhet mycket att tillföra och dels kan de bekräfta att vi förstått det aktuella problemet och rättat till det. Effektivare test Arbetet med att testa och validera dialysutrustning måste alltid ske inom ramarna för de strikta regelverken för medicinteknisk utrustning. Men även inom dessa ramar går det att effektivisera testerna. Det är viktigt att DQ inte uppfattas som den sista barriären, säger Magnus Grén och menar att DQ:s roll aldrig får bli polisiär. Det arbetssättet är inte effektivt och kan aldrig accepteras. Det måste finnas en samsyn mellan utvecklingsingenjörerna och kvalitetsingenjörerna om vikten av tillräcklig testning, eller rättare sagt verifiering och validering. Den samsynen tycker jag finns här på Gambro och det ger styrka åt hela processen Istället vill Magnus Grén att DQ ska komma in så tidigt som möjligt i utvecklingsprocessen, för att se till att granska krav, testmetoder och testresultat. Ett sådant arbetssätt säkerställer produktkvaliteten på ett effektivt sätt. Dessutom kostar det betydligt mindre än om vi istället kommer med kommentarer eller identifierar fel i slutet av processen och därmed tvingas göra om mycket av arbetet. Ju närmare vi är deadline, desto svårare är det naturligtvis att vinna gehör för de här tankarna. Samtidigt inser alla att det finns potential att göra utvecklingen snabbare, billigare och med bättre kvalitet om det här perspektivet följs från början. 18 Nr 1 mars 2003

19 AV MAGNUS OHLSSON Kom igång med prediktionsoch evolutionsmodeller Det behöver inte vara svårt att komma igång med prediktions- och evolutionsmodeller. Med ganska enkla medel kan man uppnå användbara resultat. Men det gäller att i förväg tänka igenom vad man vill uppnå. Största delen av dagens mjukvaruprojekt är i huvudsak vidareutveckling av befintlig mjukvara, där man utökar funktionaliteten eller uppdaterar den mot nya standarder. Många projekt utvecklas inkrementellt, vilket också kan ses som en form av vidareutveckling. Skillnaden mot att nyutveckla ligger i att strukturer och beroenden till viss del finns på plats och man måste anpassa sig och bygga efter dessa. Detta resulterar i att man hela tiden får med sig ett arv från de äldre delarna, med allt vad detta innebär. Förutsättningarna för vidareutvecklingen bestäms redan på ett tidigt stadium i projektet. Även om man utvecklar inkrementellt är det lätt att glömma och hålla all väsentlig information i huvudet. Bra dokumentation av systemet och dess arkitektur underlättar därför. Tyvärr är inte dokumentationsnivån den önskvärda i alla projekt. Många organisationer hamnar därför i en situation där man efterhand som man bygger vidare på systemet spenderar mer och mer tid på att rätta fel som uppkommer. Situationen kan även vara den att man släpper nya versioner av mjukvaran efterhand som man rättar problem man har funnit. I slutänden är det oftast bara ett fåtal fel kvar, men dessa är oftast väldigt svåra att handskas med på grund av olika anledningar. Oftast är det bara en delmängd av komponenterna som skapar de största problemen, och man har en känsla för vilka de är. Det är lätt att bli förblindad av dessa och förbise komponenter som inte utmärker sig men som ändå kan vara problematiska. Prediktion och evolution Hur ska man då hantera dessa komponenter och hur kan man på ett tidigt stadium agera för att undvika problem längre fram i utvecklingen? Att arbeta preventivt kan låta självklart, men är inte alltid enkelt om man inte vet var man ska börja. Om man redan har hamnat i en nedåtgående spiral av ständiga rättningar och uppdateringar kan man behöva hjälp. Ett hjälpmedel för att fokusera sina resurser (till exempel granskningar och test) på de mest problematiska komponenterna är prediktionsmodeller. Dessa kan användas i förebyggande syfte för att tidigt peka ut komponenter som är på väg att bli problematiska. Beroende på hur de appliceras, och med vilka förutsättningar, kan de användas i både kortoch långsiktigt syfte. När man arbetar med prediktionsmodeller finns det två avvägningar man måste ta hänsyn till, förhållandet mellan hur lättanvänd och hanterbar den ska vara kontra hur exakt prediktionen ska bli. Man måste även ha en bra uppfattning om vad syftet med modellen är för att den ska bli ändamålsenlig. Datainsamling Grunden för att bygga modeller är tillgången till data från mjukvaran och processen samt om resurserna. Många organisationer ställs ofta inför dilemmat att inte ha en såpass utvecklad process att data samlas in kontinuerligt. Detta behöver inte hindra byggandet och användandet, då man oftast med en relativt enkel insats kan samla in nödvändig information. Det är ett av de ställningstaganden man måste göra när det gäller avvägningen mellan användbarhet och prediktionsprecision. Oftast finns möjlighet att på ett smidigt sätt inhämta data från befintliga verktyg och processer. Man kan till exempel från versionshanteringsverktygen extrahera information om komponenterna som ingår i systemet, hur ofta det har gjorts ändringar i dem och vilka ändringar som har gjorts. Vidare kan man nyttja informationen i tidrapporteringssystemen för att se hur mycket tid som har använts till olika aktiviteter. Ett fel man bör undvika för att ge en rättvisande prediktion är att samla in data från de sena processfaserna. Till exempel bör man inte samla in information om hur mycket tid man har lagt på att testa olika komponenter, för att prediktera hur felintensiva de är. Det är dock rimligt att göra detta om man vill arbeta med evolution eller prediktion för nästa release. Istället bör man fokusera på att använda sig av data från till exempel designfasen. Man måste ha klart för sig vad syftet med modellen är och vilken information som är relevant att samla in. När det gäller prediktions- och evolutionsmodeller finns ett antal måttyper som man bör fokusera på: Storleksmått Till exempel rader kod eller antalet if-satser. Antalet if-satser (och även vissa andra mått) kan ses som ett storleksmått eftersom antalet bidrar till storleken. En annan möjlighet är att använda dem som strukturmått. Strukturmått Cyklomatisk komplexitet, mängden modifierad kod och interface-karakteristika är exempel på strukturmått. Mängden modifierad kod kan ses som ett strukturmått med avseende på att det indikerar mängden strukturella förändringar i koden. Processmått Till exempel frekvensen för vissa aktiviteter i olika utvecklingsfaser, eller tiden att utföra vissa förändringar. Feldata Klassificering av olika fel och antalet fel funna i olika faser är exempel på olika typer av feldata. Alla dessa mått kan dessutom kombineras för att få fram andra intressanta, så kallade indirekta, mått. Det är till exempel möjligt att kombinera antalet funna fel med antalet rader kod för att räkna ut feldensiteten. Detta mått kan i sin tur sedan kombineras med mängden modifierad kod i olika komponenter för att ta reda på hur förändringarna påverkar feldensiteten. En sak som har utelämnats är kvalitativa Nr 1 mars

20 mätningar, det vill säga de subjektiva mät- Felintensitet ningarna eller uppfattningarna. Dessa kan tillföra olika aspekter, klargöra oklarheter och besvara frågor angående vissa omständigheter. Problemet är att det tar en hel del tid att samla in denna information och syftet med våra prediktions- och evolutionsmodeller är inte att skapa denna djupa inblick. * Röd Gul Övre nivå Modellbygge Baserat på insamlad information kan vi bygga modeller för att analysera data, med syfte att förbättra och kontrollera våra processer. En modell bygger på en teori (syftet) som beskriver bakgrunden och det förväntade resultatet. Viktigt att veta är att modeller av sin natur är instabila. När en organisation blir medveten om ett fenomen förändras ofta beteendet, och därmed förutsättningarna för modellen. Därför är det viktigt att kontinuerligt uppdatera sina modeller. Byggstenarna i själva modellen är ett antal statistiska metoder av olika avancerad karaktär, beroende på vad man vill uppnå. Dessa metoder kan i sin tur kombineras på olika sätt, ungefär som man kombinerar olika mått, för att uppnå önskat resultat. Inom de statistiska modellernas ramar finns det även utrymme för justering och anpassning på ett antal punkter. Detta ligger dock utanför ramarna för denna artikel. Modellexempel Vi ska visa hur man kan bygga en modell för prediktion av felintensiva komponenter som sedan kan utökas och användas för att följa evolutionen hos dessa. Vi visar även hur man kan undersöka strukturella förändringar hos komponenterna i det berörda systemet för att få indikationer på vad som orsakar problemen. Prediktion och evolution De två modellerna har sitt upphov i att skapa ett gemensamt språk för kvalitetsfolk, utvecklare och chefer för att kunna fatta gemensamma beslut som alla förstår innebörden av. Modellerna bygger på teorin om att det till * Undre nivå * * * * Grön * * Release Figur 1.Trenden för en komponent över ett antal releaser. största delen är samma komponenter som uppvisar flest fel i varje release. Man kan dela in dem i tre kategorier beroende på hur felintensiva eller degenererade de är: även vara kandidat för re-engineering. Ifall man inte reagerar och hanterar de gula komponenterna finns risk för att de passerar den övre felnivån och klassificeras som röda. Gröna (normal evolution) Dessa representerar normal evolution och en viss fluktuation är normal. Komponenterna är enkla att uppdatera, dvs funktionaliteten kan utökas och fel kan rättas utan att man behöver spendera allt för mycket tid. Dessutom behövs inte systemexperter för att underhålla dessa komponenter. Man ska följa upp komponenterna från release till release för att kunna hitta illavarslande trender och ifall någon komponent överstiger en viss felnivå, (den undre nivån i figur 1), ska man hantera Röda ( mission impossible ) En röd komponent är problematisk och kostsam att underhålla. Röda komponenter har en tendens att ställa till stora problem i slutet av projekten, när det dessutom finns lite tid och pengar kvar att spendera. De ses oftast vara i allt för dåligt skick, dvs mission impossible. För att hantera dessa komponenter behöver vi människor med expertkunskap. Dessa komponenter är inte längre kandidater för re-engineering, de måste göras om. problemet innan den klassificeras som gul. De olika kategorierna finns exemplifierade i Gula (kod-degenerering) När en komponent passerar den undre nivån klassificeras den som gul och behöver speciellt fokus för att framtida problem ska undvikas. Komponenter som klassificerats gula är kandidater för specifikt riktade förbättringsinsatser. Detta kan innebära en mer rigid process, där fokus ligger på till exempel granskningar. Komponenten kan Figur 1. Exemplet visar utvecklingen för en specifik komponent över ett antal releaser. De data vi använder oss av i exemplen kommer från 28 mjukvarukomponenter som är från två releaser. Dessa utgör en del av ett stort realtidssystem inom telekommunikationsområdet. Programspråket är ett företagsinternt språk som är en föregångare till SDL. För komponenterna samlades tio olika mått 20 Nr 1 mars 2003

TDDI02. Programmeringsprojekt. Föreläsning 3 Jonas Lindgren, Institutionen för Datavetenskap, LiU

TDDI02. Programmeringsprojekt. Föreläsning 3 Jonas Lindgren, Institutionen för Datavetenskap, LiU TDDI02 Programmeringsprojekt. Föreläsning 3 Jonas Lindgren, Institutionen för Datavetenskap, LiU På denna föreläsning: Verifikation, Validering och Testning XP Extreme Programming Vad är ett fel? I engelskan

Läs mer

BLI VÄN MED DIN BUGG. Frukostseminarium. Göteborg 2014-02-07

BLI VÄN MED DIN BUGG. Frukostseminarium. Göteborg 2014-02-07 SNART BÖRJAR DET! BLI VÄN MED DIN BUGG Frukostseminarium Göteborg 2014-02-07 AGENDA Introduktion Vad är en bugg? Vad innebär kvalitet i mjukvara? Buggutställning Att rapportera buggar En riktigt bra buggrapport

Läs mer

Resiliens att kunna utnyttja möjligheter och hantera kriser och förändringar. Coachens dag

Resiliens att kunna utnyttja möjligheter och hantera kriser och förändringar. Coachens dag Resiliens att kunna utnyttja möjligheter och hantera kriser och förändringar. 1 Resiliens Ett system agerar resilient om det bibehåller sin funktion (gör det det ska) i både väntade och oväntade förhållanden

Läs mer

Så här gör du. om du vill genomföra en framgångsrik innovationstävling

Så här gör du. om du vill genomföra en framgångsrik innovationstävling Så här gör du om du vill genomföra en framgångsrik innovationstävling Det här materialet hjälper er att planera och sätta förutsättningarna för att driva kampanjer, antingen en eller regelbundet. Ibland

Läs mer

Övningstenta (Kursplan 2011) Ver 2015, 2015-12-19

Övningstenta (Kursplan 2011) Ver 2015, 2015-12-19 Swedish Software Testing Board (SSTB) International Software Testing Qualifications Board (ISTQB) Foundation Certificate in Software Testing Övningstenta (Kursplan 2011) Ver 2015, 2015-12-19 Tillåten tid:

Läs mer

Configuration testing Why? Vad det är tänkt att koden ska göra. Performance testing Kommentarer Skriva om koden som kommentar

Configuration testing Why? Vad det är tänkt att koden ska göra. Performance testing Kommentarer Skriva om koden som kommentar Skapa testfall Testing Köra testen Hitta fel Inspections and reviews Verifiera resultatet Formal methods Static analysis Completeness Verifiering Kvalitet Maintainability Validering Traceability Fault

Läs mer

Från vaga testuppdrag till förankrad teststrategi

Från vaga testuppdrag till förankrad teststrategi Från vaga testuppdrag till förankrad teststrategi Dataföreningen Stockholm, 18-okt-2012 Rikard Edgren Qamcom Karlstad rikard.edgren@qamcom.se Agenda 1. Testuppdrag 2. Projektomgivning 3. Produktelement

Läs mer

ANPASSNING FÖR ÖVERLEVNAD: 3 SÄTT ATT ANPASSA SIG TILL FÖRÄNDERLIG MILJÖ

ANPASSNING FÖR ÖVERLEVNAD: 3 SÄTT ATT ANPASSA SIG TILL FÖRÄNDERLIG MILJÖ ANPASSNING FÖR ÖVERLEVNAD: 3 SÄTT ATT ANPASSA SIG TILL FÖRÄNDERLIG MILJÖ Praktiska råd för projektörer 5 MINUTERS LÄSTID ANPASSNING FÖR ÖVERLEVNAD Den hårda konkurrensen i en osäker ekonomi kombinerat

Läs mer

Bakgrund och motivation. Definition av algoritmer Beskrivningssätt Algoritmanalys. Algoritmer. Lars Larsson VT 2007. Lars Larsson Algoritmer 1

Bakgrund och motivation. Definition av algoritmer Beskrivningssätt Algoritmanalys. Algoritmer. Lars Larsson VT 2007. Lars Larsson Algoritmer 1 Algoritmer Lars Larsson VT 2007 Lars Larsson Algoritmer 1 1 2 3 4 5 Lars Larsson Algoritmer 2 Ni som går denna kurs är framtidens projektledare inom mjukvaruutveckling. Som ledare måste ni göra svåra beslut

Läs mer

Testning på 3 föreläsningar. PV7180 Verifiering och Validering. Litteratur. Vad är testning? Varför testa och olika syn? Målet med testning

Testning på 3 föreläsningar. PV7180 Verifiering och Validering. Litteratur. Vad är testning? Varför testa och olika syn? Målet med testning ning på 3 föreläsningar Första föreläsningen Översikt PV7180 Verifiering och Validering Föreläsning 3 ning del 1 Andra föreläsningen Coverage ing, OO-ing, Utvärdering av tekniker Tredje föreläsningen Automatiserad

Läs mer

Inlämningsuppgift : Finn. 2D1418 Språkteknologi. Christoffer Sabel E-post: csabel@kth.se 1

Inlämningsuppgift : Finn. 2D1418 Språkteknologi. Christoffer Sabel E-post: csabel@kth.se 1 Inlämningsuppgift : Finn 2D1418 Språkteknologi Christoffer Sabel E-post: csabel@kth.se 1 1. Inledning...3 2. Teori...3 2.1 Termdokumentmatrisen...3 2.2 Finn...4 3. Implementation...4 3.1 Databasen...4

Läs mer

Objektorientering/1.2. 3 Klasser

Objektorientering/1.2. 3 Klasser 3 Klasser 3.1 Att hantera många objekt 3.2 Klasser 3.3 Krav för att bilda en klass 3.4 Får två objekt vara helt identiska? 3.5 Måste vi använda klasser i objektorientering? 3.6 En klassbeskrivning 3.7

Läs mer

campus.borlänge Förstudie - Beslutsstöd för operativ tågtrafikstyrning

campus.borlänge Förstudie - Beslutsstöd för operativ tågtrafikstyrning campus.borlänge Förstudie - Beslutsstöd för operativ tågtrafikstyrning En rapport från CATD-projektet, januari-2001 1 2 Förstudie Beslutsstöd för operativ tågtrafikstyrning Bakgrund Bland de grundläggande

Läs mer

Utforskande testning

Utforskande testning Utforskande testning SAST Stockholm, 2012-02-23 Rikard Edgren Qamcom Karlstad rikard.edgren@qamcom.se Utforskande testning är en stil för programvarutestning som betonar varje testares frihet och ansvar

Läs mer

PMM (Process Maturity Metrics) Allmänt. Mätetal för framgångsfaktorer. 1. CM konfigurationsstyrning

PMM (Process Maturity Metrics) Allmänt. Mätetal för framgångsfaktorer. 1. CM konfigurationsstyrning PMM (Process Maturity Metrics) PMM är en metod för att mäta processmognad i utvecklingsprojekt. I korthet går metoden ut på att man utvärderar sin utvecklingsprocess med avseende på ett antal framgångsfaktorer

Läs mer

Föreläsning 2. Operativsystem och programmering

Föreläsning 2. Operativsystem och programmering Föreläsning 2 Operativsystem och programmering Behov av operativsystem En dator så som beskriven i förra föreläsningen är nästan oanvändbar. Processorn kan bara ges enkla instruktioner såsom hämta data

Läs mer

ToDo ios-applikation. Mikael Östman. Mikael Östman - mo22ez Linnéuniversitetet

ToDo ios-applikation. Mikael Östman. Mikael Östman - mo22ez Linnéuniversitetet ToDo ios-applikation Mikael Östman 201205 Mikael Östman - mo22ez Linnéuniversitetet mo222ez@student.lnu.se Abstrakt Detta är en slutrapport för det projekt jag bedrivit inom ramen för kursen Individuellt

Läs mer

Vanliga frågor för VoiceXpress

Vanliga frågor för VoiceXpress Vanliga frågor för VoiceXpress 1) Hur stort ordförråd (vokabulär) innehåller VoiceXpress? VoiceXpress innehåller ett mycket omfattande ordförråd, och svaret på frågan varierar en aning beroende på hur

Läs mer

Mina listor. En Android-applikation. Rickard Karlsson 2013-06-09. Rickard Karlsson - rk222cu Linnéuniversitet rk222cu@student.lnu.

Mina listor. En Android-applikation. Rickard Karlsson 2013-06-09. Rickard Karlsson - rk222cu Linnéuniversitet rk222cu@student.lnu. Mina listor En Android-applikation Rickard Karlsson 2013-06-09 Rickard Karlsson - rk222cu Linnéuniversitet rk222cu@student.lnu.se Innehållsförteckning 2. Innehållsförteckning 3. Abstrakt 4. Inledning/bakgrund

Läs mer

1. (3p) Inom MDI-området framhåller man att människor lär sig via metaforer. Hur menar man att detta går till?

1. (3p) Inom MDI-området framhåller man att människor lär sig via metaforer. Hur menar man att detta går till? 1. (3p) Inom MDI-området framhåller man att människor lär sig via metaforer. Hur menar man att detta går till? Att lära sig via metaforer innebär att man drar nytta av kunskap som användaren redan har,

Läs mer

Elements, säkerhetskopiering och dina bilder

Elements, säkerhetskopiering och dina bilder Elements, säkerhetskopiering och dina bilder Mattias Karlsson Sjöberg, december 2011. Moderskeppet.se Lär dig tänka rätt och använda rätt verktyg för att säkerhetskopiering, datorbyte och hårdiskbyte.

Läs mer

Fönsterbeteende. Mike McBride Jost Schenck Översättare: Stefan Asserhäll

Fönsterbeteende. Mike McBride Jost Schenck Översättare: Stefan Asserhäll Mike McBride Jost Schenck Översättare: Stefan Asserhäll 2 Innehåll 1 Fönsterbeteende 4 1.1 Fokus............................................. 4 1.1.1 Fokuspolicy..................................... 4

Läs mer

Regressionstestning teori och praktik

Regressionstestning teori och praktik Regressionstestning teori och praktik Lic. Emelie Engström emelie.engstrom@cs.lth.se Software Engineering Research Group LUND UNIVERSITY Sweden SWELL the Swedish Research School in Software Verification

Läs mer

Introduktion Schenker-BTL AB, Stab IT Beskrivning över informationsintegreringmed Schenker, metodbeskrivning version 1.

Introduktion Schenker-BTL AB, Stab IT Beskrivning över informationsintegreringmed Schenker, metodbeskrivning version 1. Schenker har interna system som handhar information som är av intresse för våra kunder/partners. Idag finns ett flertal av dem tillgängliga via Internet, sk Online-tjänster. Dessa erbjuder inte bara hämtning

Läs mer

Utvärdering. Övergripande (1) Med/utan användare. Övergripande (2) Fredag 1 oktober F1. Ann Lantz - Anna Swartling -

Utvärdering. Övergripande (1) Med/utan användare. Övergripande (2) Fredag 1 oktober F1. Ann Lantz - Anna Swartling - Utvärdering Fredag 1 oktober 13-15 F1 Ann Lantz - alz@nada.kth.se Anna Swartling - ast@kth.se Övergripande (1) Av den verkliga världen: Hur agerar man, vad händer? Hur används teknik? Beteendevetenskapliga

Läs mer

men borde vi inte också testa kraven?

men borde vi inte också testa kraven? men borde vi inte också testa kraven? Robert Bornelind Presentation på SAST, 24 februari 2011 SQS Software Quality Systems Sweden AB Innehåll Introduktion Kvalitet, tid och kostnad Process Testning av

Läs mer

Kristian Almgren Artificiell Intelligens Linköpings Universitet 2011. Talstyrning

Kristian Almgren Artificiell Intelligens Linköpings Universitet 2011. Talstyrning Talstyrning Abstrakt Talstyrning är en teknik som gör det möjligt för oss människor att mer eller mindre verbalt kommunicera med en dator eller ett system. Det här är ett tillvägagångssätt inom AI och

Läs mer

Slutrapport Get it going contracts

Slutrapport Get it going contracts Slutrapport Get it going contracts Författare: Anthony Dry Datum: 2011-06-02 Program: Utvecklare av digitala tjänster Kurs: Individuellt mjukvaruutvecklingsprojekt 7.5p Linnéuniversitetet (Kalmar) Abstrakt

Läs mer

Processinriktning i ISO 9001:2015

Processinriktning i ISO 9001:2015 Processinriktning i ISO 9001:2015 Syftet med detta dokument Syftet med detta dokument är att förklara processinriktning i ISO 9001:2015. Processinriktning kan tillämpas på alla organisationer och alla

Läs mer

Programmering. Seminarier i datavetenskap, datorteknik och informationsteknik. Niklas Broberg niklas.broberg@chalmers.

Programmering. Seminarier i datavetenskap, datorteknik och informationsteknik. Niklas Broberg niklas.broberg@chalmers. Programmering Seminarier i datavetenskap, datorteknik och informationsteknik Niklas Broberg niklas.broberg@chalmers.se 2015-09-24 Hur många från Datavetenskap? Datateknik? Informationsteknik? Översikt

Läs mer

Preliminär specifikation av projekt

Preliminär specifikation av projekt Preliminär specifikation av projekt Projektets namn: Infraröd Minneslåda (numera omdöpt till FastSync) Uppdragsgivare: Alex Olwal aolwal@cs.columbia.edu Deltagare: Johan Ullberg Nils

Läs mer

Anledning: Generellt så undviker QUPER att göra fullständiga förutsägelser för relationerna mellan ett systems fördelar, kostnad och kvalitet.

Anledning: Generellt så undviker QUPER att göra fullständiga förutsägelser för relationerna mellan ett systems fördelar, kostnad och kvalitet. Fråga 1. QUPER Påstående: QUPER är en modell för att elicitera krav Anledning: Generellt så undviker QUPER att göra fullständiga förutsägelser för relationerna mellan ett systems fördelar, kostnad och

Läs mer

PH Bicycle Storage 8000 Testplan

PH Bicycle Storage 8000 Testplan PH Bicycle Storage 8000 Testplan Projektdeltagare: Mattias Nordahl (dt07mn0@student.lth.se) Hannes Nevalainen (dt07hn2@student.lth.se) Daniel Olofsson (dt07do1@student.lth.se) Fredrik Andersson (dt07fa5@student.lth.se)

Läs mer

Programdesign. Dokumentera. Dokumentera

Programdesign. Dokumentera. Dokumentera Programdesign Dokumentera Välj datastruktur så programmet blir så enkelt som möjligt. Välj algoritm så programmet blir lättläst, robust och effektivt. Analysera programmet för att få en bra metod. Överväganden

Läs mer

PROGRAMMERING. Ämnets syfte. Kurser i ämnet

PROGRAMMERING. Ämnets syfte. Kurser i ämnet PROGRAMMERING Ämnet programmering behandlar programmeringens roll i informationstekniska sammanhang som datorsimulering, animerad grafik, praktisk datoriserad problemlösning och användaranpassad konfiguration

Läs mer

TDDC74 - Projektspecifikation

TDDC74 - Projektspecifikation TDDC74 - Projektspecifikation Projektmedlemmar: Namn Efternamn abcde123@student.liu.se Namn Efternamn abcde123@student.liu.se Handledare: Handledare handledare@ida.liu.se eller handledare@student.liu.se

Läs mer

Collector en Android-app för att samla saker. Kim Grönqvist (kg222dk) 2013-06-10 Slutrapport

Collector en Android-app för att samla saker. Kim Grönqvist (kg222dk) 2013-06-10 Slutrapport Collector en Android-app för att samla saker Kim Grönqvist (kg222dk) 2013-06-10 Slutrapport Abstrakt Jag har gjort en Android-app för att samla saker, Collector. Med den kan man upprätta att göra-listor

Läs mer

Projektkaos. Chaos-rapporten. 34% av projekten avslutades i tid och enligt budget... ... 66% misslyckades!

Projektkaos. Chaos-rapporten. 34% av projekten avslutades i tid och enligt budget... ... 66% misslyckades! Projektkaos. Chaos-rapporten 34% av projekten avslutades i tid och enligt budget...... 66% misslyckades! 1 Standish Group, 2003 (www.standishgroup.com) Praxis Hantera krav Använd komponentarkitekturer

Läs mer

SMARTA SÄTT ATT HITTA NYA KUNDER! Lyckas är att ligga steget före

SMARTA SÄTT ATT HITTA NYA KUNDER! Lyckas är att ligga steget före fem SMARTA SÄTT ATT HITTA NYA KUNDER! Lyckas är att ligga steget före Fem smarta sätt att hitta nya kunder Om inte du hittar dem, så kommer dina konkurrenter att göra det För varje företag är nya kunder

Läs mer

Vad är. Domändriven design?

Vad är. Domändriven design? Vad är Domändriven design? 1 Domändriven design är utvecklare och domänexperter som arbetar tillsammans för att skapa mjukvara som är både begriplig och möjlig att underhålla. ett sätt att fånga och sprida

Läs mer

LiTH. WalkCAM 2007/05/15. Testplan. Mitun Dey Version 1.0. Status. Granskad. Godkänd. Reglerteknisk projektkurs WalkCAM LIPs

LiTH. WalkCAM 2007/05/15. Testplan. Mitun Dey Version 1.0. Status. Granskad. Godkänd. Reglerteknisk projektkurs WalkCAM LIPs Testplan Mitun Dey Version 1.0 Status Granskad Godkänd 1 PROJEKTIDENTITET Reglerteknisk projektkurs, WalkCAM, 2007/VT Linköpings tekniska högskola, ISY Namn Ansvar Telefon E-post Henrik Johansson Projektledare

Läs mer

Exempel på verklig projektplan

Exempel på verklig projektplan Exempel på verklig projektplan Detta är ett exempel på en proffessionell projektplan hämtad ur verkliga livet. Den visas inte i sin fullständighet, det mesta är bortklippt, men strukturen och mycket av

Läs mer

PROGRAMMERING. Ämnets syfte. Kurser i ämnet

PROGRAMMERING. Ämnets syfte. Kurser i ämnet PROGRAMMERING Ämnet programmering behandlar programmeringens roll i informationstekniska sammanhang som datorsimulering, animerad grafik, praktisk datoriserad problemlösning och användaranpassad konfiguration

Läs mer

Föreläsning 7 Mentala modeller, metaforer och emotionell interaktion. Kapitel 5 (3) i Rogers et al.

Föreläsning 7 Mentala modeller, metaforer och emotionell interaktion. Kapitel 5 (3) i Rogers et al. Föreläsning 7 Mentala modeller, metaforer och emotionell interaktion Kapitel 5 (3) i Rogers et al. Översikt Human Action Cycle Konceptuella modeller Metaforer ikoner Emotionell design Antropomorfism Agenter

Läs mer

Så avancerad att vi blev tvungna att skapa en ny kategori

Så avancerad att vi blev tvungna att skapa en ny kategori Vi presenterar Fluke VT02 Visual IR Thermometer Så avancerad att vi blev tvungna att skapa en ny kategori Visuell inspektion Inga fel kan identifieras med blotta ögat Traditionell IR-termometer Optimerad

Läs mer

International Olympiad in Informatics 2011 22 29 July 2011, Pattaya City, Thailand Tävlingsuppgifter Dag 2 Svenska 1.3. Papegojor

International Olympiad in Informatics 2011 22 29 July 2011, Pattaya City, Thailand Tävlingsuppgifter Dag 2 Svenska 1.3. Papegojor Papegojor Yanee är fågelentusiast. Sedan hon läst om IP over Avian Carriers (IPoAC), har hon spenderat mycket tid med att träna en flock papegojor att leverera meddelanden över långa avstånd. Yanees dröm

Läs mer

Kort om World Wide Web (webben)

Kort om World Wide Web (webben) KAPITEL 1 Grunder I det här kapitlet ska jag gå igenom allmänt om vad Internet är och vad som krävs för att skapa en hemsida. Plus lite annat smått och gott som är bra att känna till innan vi kör igång.

Läs mer

Metoder och verktyg för funktionssäkerhet

Metoder och verktyg för funktionssäkerhet Metoder och verktyg för funktionssäkerhet Projektstart 1. Hantera kraven En bra process är grunden för att hantera kraven i ett säkerhetsprojekt. Det krävs att du har en tydlig spårbarhet mellan krav och

Läs mer

Manual HSB Webb brf 2004 03 23

Manual HSB Webb brf 2004 03 23 TERMINOLOGI I Polopoly används ett antal grundläggande begrepp för publicering och hantering av information, eller innehåll som det också benämns. Nedan följer en kort genomgång av denna grundläggande

Läs mer

V!cto. Att tjäna pengar genom bättre testning med

V!cto. Att tjäna pengar genom bättre testning med Att tjäna pengar genom testning med Att tjäna pengar genom testning med 1 (50) Det finns tre vägar till test: 1: Testautomati- Att bygga sering Att bygga Att bygga Att bygga Att bygga Att bygga Att bygga

Läs mer

TPFD - TestPlan Före Design BESKRIVNING AV AKTIVITETER

TPFD - TestPlan Före Design BESKRIVNING AV AKTIVITETER TPFD Beskrivning Rev 4 1(10) TPFD - TestPlan Före Design BESKRIVNING AV AKTIVITETER Anv.krav Terminologi Detaljkrav Konfigdok Hantera Utgåvor Projektplan Testplan Test-o-felrättning Ändringslogg Återst.

Läs mer

Kreativitet som Konkurrensmedel

Kreativitet som Konkurrensmedel www.realize.se 1 Kreativitet som Konkurrensmedel Vi är på väg in i Idésamhället. Ord som kreativitet och innovation upprepas som ett mantra. Det är många som vill. Det är färre som kan. Realize AB är ett

Läs mer

Version 1.0. 2013-02-13 Testteam 4 Testledare: Patrik Bäck

Version 1.0. 2013-02-13 Testteam 4 Testledare: Patrik Bäck Version 1.0-2013-02-13 Testteam 4 Testledare: Patrik Bäck 0 Sammanfattning Testplanen är utarbetad som ett svar på Konsumentverkets förfrågningsunderlag avseende upphandling av ett nytt budget- och skuldsaneringssystem,

Läs mer

Formell Verifiering. Hur vet man att ett system fungerar korrekt? Lisa Kaati

Formell Verifiering. Hur vet man att ett system fungerar korrekt? Lisa Kaati Formell Verifiering Hur vet man att ett system fungerar korrekt? Lisa Kaati Innehåll Motivering Formell verifiering Modellkontroll (model checking) Verifiering av kod Forskning Dator system finns överallt

Läs mer

Enhetstester på.netplattformen

Enhetstester på.netplattformen Enhetstester på.netplattformen Praktikfall ur verkligheten Copyright Prolore 2007. All Rights Reserved. Viktor Laszlo Vem är jag 11 år inom test Prolore: specialiserat på Testautomatisering, Prestandatest

Läs mer

Viktig produktsäkerhetsinformation

Viktig produktsäkerhetsinformation 2011-10-13 Viktig produktsäkerhetsinformation UniCel DxI system för immunanalys* Alla versioner av programvaran * Inklusive de fristående UniCel DxI 600 och 800-systemen, och de integrerade UniCel DxC

Läs mer

2014-2015 Alla rättigheter till materialet reserverade Easec

2014-2015 Alla rättigheter till materialet reserverade Easec 1 2 Innehåll Introduktion... 4 Standarder... 5 Översikt: Standarder... 6 1058.1-1987 IEEE Standard för Software Project Management Plans... 7 Ingående dokument... 8 Syfte och struktur... 9 ITIL... 10 ITIL

Läs mer

Att välja verktyg för portföljhantering. - Vad vet en leverantör om det?

Att välja verktyg för portföljhantering. - Vad vet en leverantör om det? Att välja verktyg för portföljhantering - Vad vet en leverantör om det? Agenda Problem som ska lösas med verktyg Olika typer av verktyg Att utvärdera och välja verktyg Egenutvecklat eller standard Förankring

Läs mer

Inledning. Vad är ett datorprogram, egentligen? Olika språk. Problemlösning och algoritmer. 1DV433 Strukturerad programmering med C Mats Loock

Inledning. Vad är ett datorprogram, egentligen? Olika språk. Problemlösning och algoritmer. 1DV433 Strukturerad programmering med C Mats Loock Inledning Vad är ett datorprogram, egentligen? Olika språk Problemlösning och algoritmer 1 (14) Varför använda en dator? Genom att variera de program som styr datorn kan den användas för olika uppgifter.

Läs mer

Mot en gemensam definition av systemiskt tänkande - i dag och inför framtiden.

Mot en gemensam definition av systemiskt tänkande - i dag och inför framtiden. Mot en gemensam definition av systemiskt tänkande - i dag och inför framtiden. Det har nu gått ungefär 25 år sedan det blev möjligt att bli legitimerad psykoterapeut på familjeterapeutisk grund och då

Läs mer

Introduktion till algoritmer - Lektion 1 Matematikgymnasiet, Läsåret 2014-2015. Lektion 1

Introduktion till algoritmer - Lektion 1 Matematikgymnasiet, Läsåret 2014-2015. Lektion 1 Kattis Lektion 1 I kursen används onlinedomaren Kattis (från http://kattis.com) för att automatiskt rätta programmeringsproblem. För att få ett konto på Kattis anmäler du dig på Programmeringsolympiadens

Läs mer

PROGRAMMERING. Ämnets syfte. Kurser i ämnet

PROGRAMMERING. Ämnets syfte. Kurser i ämnet PROGRAMMERING Ämnet programmering behandlar programmeringens roll i informationstekniska sammanhang som datorsimulering, animerad grafik, praktisk datoriserad problemlösning och användaranpassad konfiguration

Läs mer

Produktstöd - Vägledning till dokumentationskraven i SS-EN ISO 9001:2000

Produktstöd - Vägledning till dokumentationskraven i SS-EN ISO 9001:2000 Document: STG/PS K 525SV1 Produktstöd - Vägledning till dokumentationskraven i SS-EN ISO 9001:2000 SIS, Projekt Kvalitetsledning 1 1) Introduktion Produktstöd Två av de viktigaste målsättningarna i arbetet

Läs mer

Automatiserade testsystem

Automatiserade testsystem Automatiserade testsystem Fredrik Edling, Tekn. Dr. Enea Services Stockholm fredrik.edling@enea.com Min bakgrund 2000: Civilingenjör teknisk fysik, inriktning mot tillämpad fysik 2004: Teknisk doktor,

Läs mer

Pussel DISC/Morot Kombination

Pussel DISC/Morot Kombination Pussel DISC/Morot Kombination Kommunikation Exempel på agenda för första coaching mötet ID: 72955 Ensize International AB Analysdatum: 2012-06-14 Tid: 14 minuter Utskriftsdatum: 2013-09-23 Ensize International

Läs mer

Linköpings Tekniska Högskola Institutionen för Datavetanskap (IDA), Software and Systems (SaS) (c) Klas Arvidsson

Linköpings Tekniska Högskola Institutionen för Datavetanskap (IDA), Software and Systems (SaS) (c) Klas Arvidsson Linköpings Tekniska Högskola Institutionen för Datavetanskap (IDA), Software and Systems (SaS) (c) Klas Arvidsson 2012-01-14 Introduktion Det första du behöver veta om PintOS är att det är ett riktigt

Läs mer

EAs krav vid ackreditering av flexibel omfattning

EAs krav vid ackreditering av flexibel omfattning SWEDAC DOC 12:1 2012-05-10 Utgåva 1 Inofficiell översättning av EA 2/15 M:2008 EAs krav vid ackreditering av flexibel omfattning Swedac, Styrelsen för ackreditering och teknisk kontroll, Box 878, 501 15

Läs mer

Vägledning inför beställning av utvärdering vid Malmö högskola

Vägledning inför beställning av utvärdering vid Malmö högskola Vägledning inför beställning av utvärdering vid Malmö högskola 1. Vad är det övergripande motivet bakom utvärderingen vad är syftet? Varför? Detta är en av de viktigaste frågorna att ställa sig inför planeringen

Läs mer

Regression med Genetiska Algoritmer

Regression med Genetiska Algoritmer Regression med Genetiska Algoritmer Projektarbete, Artificiell intelligens, 729G43 Jimmy Eriksson, jimer336 770529-5991 2014 Inledning Hur många kramar finns det i världen givet? Att kunna estimera givet

Läs mer

Bilaga KeyControl Felsökning

Bilaga KeyControl Felsökning Bilaga: Felsökning 1. Allmänt Genom att ge så detaljerad information som möjligt om problemet och de operationer som föregick problemet underlättas supporten. Du viktigaste komponenterna är - Operativsystemet

Läs mer

Dr. Gustav Taxén MDI-Gruppen, CSC / VIC-Sthlm gustavt@kth.se

Dr. Gustav Taxén MDI-Gruppen, CSC / VIC-Sthlm gustavt@kth.se Att utvärdera spel Dr. Gustav Taxén MDI-Gruppen, CSC / VIC-Sthlm gustavt@kth.se Att utvärdera spel Buggar / logikfel: QA Upplevelsen: Playtesting Utvecklingsprocessen: Post Mortem BUGGAR / LOGIKFEL Unit

Läs mer

Sju riktlinjer vid utveckling av hemsidor för mobil och desktop

Sju riktlinjer vid utveckling av hemsidor för mobil och desktop Sju riktlinjer vid utveckling av hemsidor för mobil och desktop Denna artikel går igenom hur du gör en hemsida användarvänlig till både vanliga desktopdatorer och mobilanvändare utan att behöva ha två

Läs mer

Vinjetter TDDC91 Datastrukturer och algoritmer

Vinjetter TDDC91 Datastrukturer och algoritmer Vinjetter TDDC91 Datastrukturer och algoritmer 17 augusti 2015 2 Scenario 1 Man har inom Posten Logistik AB skrivit programvara för sortering av kundinformation och vill standardisera användningen av sorteringsalgoritmer.

Läs mer

Vår resa till bra Acceptanstestning. Ingela Hagman Thomas Cook Northern Europe

Vår resa till bra Acceptanstestning. Ingela Hagman Thomas Cook Northern Europe Vår resa till bra Acceptanstestning Ingela Hagman Thomas Cook Northern Europe Testledare Ingela Hagman Profil: - Verksamhetsnära - Ej tekniktung Egenskaper: - Noggrann - Struktur - Envishet - Positiv -

Läs mer

Kursplan för Matematik

Kursplan för Matematik Sida 1 av 5 Kursplan för Matematik Inrättad 2000-07 SKOLFS: 2000:135 Ämnets syfte och roll i utbildningen Grundskolan har till uppgift att hos eleven utveckla sådana kunskaper i matematik som behövs för

Läs mer

IBSE Ett självreflekterande(självkritiskt) verktyg för lärare. Riktlinjer för lärare

IBSE Ett självreflekterande(självkritiskt) verktyg för lärare. Riktlinjer för lärare Fibonacci / översättning från engelska IBSE Ett självreflekterande(självkritiskt) verktyg för lärare Riktlinjer för lärare Vad är det? Detta verktyg för självutvärdering sätter upp kriterier som gör det

Läs mer

Kristoffer Eriksson Christer Oscarsson Andreas Dahlberg Martin Bengtsson

Kristoffer Eriksson Christer Oscarsson Andreas Dahlberg Martin Bengtsson Rapport grupp 4 Software Engineering Kristoffer Eriksson Christer Oscarsson Andreas Dahlberg Martin Bengtsson 2009-10-29 Processer Sprinter Scrum har varit till stor hjälp för oss för att nå våra mål,

Läs mer

på ett stort spelföretag Andreas Ström

på ett stort spelföretag Andreas Ström på ett stort spelföretag Andreas Ström - Spelföretag som är B2C och B2B orienterat. Bygger en pokerplattform som säljs och driftas som en tjänst till andra företag. - Grundades 1999 i Uppsala - Scrum sedan

Läs mer

Vad påverkar designen?

Vad påverkar designen? Vad påverkar designen av ett gränssnitt? Vi ser arbetet med design av ett användargränssnitt som något som liknar en arkitekts arbete. En arkitekt ska i sin utformning av en ny byggnad se till att: Byggnaden

Läs mer

Spelutveckling - Gameplay. Design och produktion

Spelutveckling - Gameplay. Design och produktion Spelutveckling - Gameplay Design och produktion Vad är ett spel? Finns olika åsikter Några exempel som räcker på egen hand Coola features Akta er för feature creep För mycket features kan dränka gameplay

Läs mer

Länkade listor och automatisk testning

Länkade listor och automatisk testning 1 (6) Länkade listor och automatisk testning Algoritmer och datastrukturer Obligatorisk nr 3 Syfte Att ge träning i programmering av länkade listor på låg abstraktionsnivå med primitiv pekarmanipulering.

Läs mer

Cargolog Impact Recorder System

Cargolog Impact Recorder System Cargolog Impact Recorder System MOBITRON Mobitron AB Box 241 561 23 Huskvarna, Sweden Tel +46 (0)36 512 25 Fax +46 (0)36 511 25 Att mäta är att veta Vi hjälper dig och dina kunder minska skador och underhållskostnader

Läs mer

STRESS ÄR ETT VAL! { ledarskap }

STRESS ÄR ETT VAL! { ledarskap } { ledarskap } STRESS ÄR ETT VAL! SLUTA SÄTTA PLÅSTER PÅ DINA SYMPTOM NÄR DU ÄR STRESSAD. LÖS PROBLEMEN VID KÄLLAN ISTÄLLET OCH FUNDERA ÖVER VILKA VAL DU GÖR SOM CHEF. E n undersökning visar att 70 procent

Läs mer

Kurser och seminarier från AddQ Consulting

Kurser och seminarier från AddQ Consulting Kurser och seminarier från AddQ Consulting Med fokus på kvalitet och effektivitet bidrar vi till att underlätta människors vardag. Kompetensutveckling är nyckeln till framgång för dig som jobbar med test,

Läs mer

Nulägesanalys & Kravspecifikation

Nulägesanalys & Kravspecifikation Nulägesanalys & Kravspecifikation Thord Schibler/Johan André Examensarbetare vid AU-System Mobile 1999 3 augusti 1999 Innehåll Ordlista & Förkortningar 1 1 Bakgrund 2 1.1 Inledning... 2 1.2 Avgränsningar...

Läs mer

Att komma igång med Riskbaserad Testning

Att komma igång med Riskbaserad Testning Att komma igång med Riskbaserad Testning Mårten Mattsson Testarkitekt Marten.mattsson@sogeti.se Att komma igång med Riskbaserad Testning Agenda Introduktion Hur ska vi jobba med testning? Hur kommer vi

Läs mer

Vad är molnet?... 2. Vad är NAV i molnet?... 3. Vem passar NAV i molnet för?... 4. Fördelar med NAV i molnet... 5. Kom igång snabbt...

Vad är molnet?... 2. Vad är NAV i molnet?... 3. Vem passar NAV i molnet för?... 4. Fördelar med NAV i molnet... 5. Kom igång snabbt... Produktblad för NAV i molnet Innehåll Vad är molnet?... 2 Vad är NAV i molnet?... 3 Vem passar NAV i molnet för?... 4 Fördelar med NAV i molnet... 5 Kom igång snabbt... 5 Bli kostnadseffektiv... 5 Enkelt

Läs mer

Anpassningsbar applikationsstruktur för flerpunktsskärmar

Anpassningsbar applikationsstruktur för flerpunktsskärmar Datavetenskap Opponent(er): Rikard Boström Lars-Olof Moilanen Respondent(er): Mathias Andersson Henrik Bäck Anpassningsbar applikationsstruktur för flerpunktsskärmar Oppositionsrapport, C/D-nivå 2005:xx

Läs mer

Objektorientering Användning

Objektorientering Användning Objektorientering Användning Samt repetition av klasser Suzana Ramadani 1 Repetition Objektorientering bygger på Abstraktion Hierarkisk strukturering Inkapsling Klassificering Generalisering specialisering

Läs mer

FMEA-Grunder. FMEA kan användas vid flera olika tillfällen vid framtagning av en produkt/tjänst.

FMEA-Grunder. FMEA kan användas vid flera olika tillfällen vid framtagning av en produkt/tjänst. FMEA-Grunder Historik. 1957 uppfann man arbetssättet/metoden med FMEA (Failure Mode and Effect Analysis, feluppkomst och effektanalys.) Det var komplexiteten och snabbheten inom den tekniska utvecklingen

Läs mer

men borde vi inte också testa kraven? Robert Bornelind

men borde vi inte också testa kraven? Robert Bornelind men borde vi inte också testa kraven? Robert Bornelind Presentation på SAST 15 års jubileum 14 oktober 2010 SQS Software Quality Systems Nordic Innehåll Introduktion Kvalitet, tid och kostnad Process Testning

Läs mer

Teoretisk del. Facit Tentamen TDDC (6)

Teoretisk del. Facit Tentamen TDDC (6) Facit Tentamen TDDC30 2014-08-29 1 (6) Teoretisk del 1. (6p) "Snabba frågor" Alla svar motiveras väl. a) Vad är skillnaden mellan synligheterna public, private och protected? (1p) Svar:public: Nåbar för

Läs mer

Före Kravspecifikationen

Före Kravspecifikationen projektidé BP0 förstudie BP1 förberedelse BP2 Kravspecifikationen Beskriver VAD som ska utföras i projektet? projektdirektiv beslutspunkter specifikationer planer kunddokument rapporter protokoll M beställarens

Läs mer

Lärandelab 3 Patientsäkerhet - om resiliens och hur vi kan utveckla vårt arbete med patientsäkerhet. Berit Axelsson och Axel Ros Qulturum, RJL

Lärandelab 3 Patientsäkerhet - om resiliens och hur vi kan utveckla vårt arbete med patientsäkerhet. Berit Axelsson och Axel Ros Qulturum, RJL Lärandelab 3 Patientsäkerhet - om resiliens och hur vi kan utveckla vårt arbete med patientsäkerhet Berit Axelsson och Axel Ros Qulturum, RJL 1 Patientsäkerhet ur andra perspektiv Att lära av det som går

Läs mer

10 tips för ökad försäljning

10 tips för ökad försäljning 10 tips för ökad försäljning Innehållsförteckning Tips 1 Kundvård...3 Tips 2 Vad har du egentligen på gång?...4 Tips 3 Ställ jobbiga frågor...5 Tips 4 När tiden inte räcker till...6 Tips 5 Låt kunden skriva

Läs mer

Från Smart TV till Smartare upplevelse Av: Kim Huber och Connie Huanca

Från Smart TV till Smartare upplevelse Av: Kim Huber och Connie Huanca Från Smart TV till Smartare upplevelse Av: Kim Huber och Connie Huanca System vi undersökte Den system vi valde att undersöka var en av de senaste smart tv som finns i markanden och var nämnd till bästa

Läs mer

Hur hanterar man krav på säkerhet?

Hur hanterar man krav på säkerhet? Hur hanterar man krav på säkerhet? Agenda Introduktion Krav i förhållande till en kvalitetsmodell Mål Policy Krav Säkerhet som kvalitetsfaktor kvalitetsfaktorn Den gemensamma underliggande kvalitetsfaktorn,

Läs mer

Köpguide för mobila växlar. Modern telefoni till företaget är långt ifrån vad det var för bara några år sedan.

Köpguide för mobila växlar. Modern telefoni till företaget är långt ifrån vad det var för bara några år sedan. Köpguide för mobila växlar Modern telefoni till företaget är långt ifrån vad det var för bara några år sedan. Tänk om din nya telefonilösning kunde förenkla din vardag och hjälpa dina medarbetare att arbeta

Läs mer

Processbeskrivning Test

Processbeskrivning Test ProcIT-P-017 Processbeskrivning Test Lednings- och kvalitetssystem Fastställt av Sven Arvidson 2012-06-20 Innehållsförteckning 1 Inledning 3 1.1 Symboler i processbeskrivningarna 3 2 Testprocessen 4 2.1

Läs mer

Objekt-orienterad utveckling. Objektorienterad analys och design. Objekt-orienterad programutveckling. Objekt-orienterad analys och design: Litteratur

Objekt-orienterad utveckling. Objektorienterad analys och design. Objekt-orienterad programutveckling. Objekt-orienterad analys och design: Litteratur Objekt-orienterad utveckling Saker man vill uppnå: Objektorienterad analys och design Sven-Olof Nyström Uppsala Universitet 16 mars 2005 en systematisk metod för att gå från problembeskrivning till färdigt

Läs mer