5.1 Grundläggande krav
Alla punkter för obligatorisk funktionalitet är nu lösta och testade. Det går att importera export-filerna från Perception och relevant data sparas eller uppdate-ras i motsvarande tabeller i databasen. För att säkerställa funktionen för felhan-teringen, vid importer, har ett antal exportfiler manipulerats så att de med flit genererar fel vilket resulterat i att respektive felmeddelande visats. Till varje projekt går det att spara samt uppdatera specifika värden och för de tester som idag beräknas i Perception går det att skapa motsvarande rapporttabeller med hjälp av färdiga mallar. Tabellerna går sedan att kopiera till ett dokument med bibehållen formatering. Det finns en instruktion i rapportverktyget som beskri-ver hur det ska användas samt vilka krav som ställs på export-filerna från Per-ception. I de fall en användare kan mata in data kontrolleras innehållet och in-formativa status-meddelanden visas både när värden sparats eller ifall något inte är korrekt ifyllt.
Det som återstår att göra är att konfigurera servern i det interna nätverket samt publicera rapportverktyget. Access till servern måste också säkerställas.
5.2 Tilläggsfunktioner
Under utvecklingen av rapportverktyget har flera av tilläggsfunktionerna hun-nits med att utvecklas. Dels har det funhun-nits tid men för flera av funktionerna har prioriteringen eskalerats vartefter värdet av dessa förtydligats. När projektet startade var strukturen för export-filerna ännu inte helt klar och en möjlig lös-ning var att lägga samman information för flera Recordings i samma export-fil.
Under utvecklingens gång togs dock beslut om att det fortsättningsvis ska gene-reras en exportfiler per Recording vilket gör att filerna i sig blir mindre i om-fång men antalet filer ökar. Med det beslutet höjdes prioriteringen att kunna im-portera flera filer samtidigt. Av samma anledning höjdes prioriteringen att filer automatiskt ska raderas efter import. Filerna i sig är inte speciellt stora, sett i megabyte, men på sikt skulle det kunna röra sig om ett mycket stort antal filer och det finns ingen vinning i att de lagras och tar upp plats på servern. Att kun-na sortera tabellen, på startsidan, har också fått en högre prioritering efter dis-kussioner om hur det kan se ut framöver. Prioriteringen var dock inte lika hög som de andra två punkterna men tack vare färdiga bibliotek för denna funktion gick det väldigt snabbt och enkelt att implementera.
En tilläggsfunktion som fått betydligt högre prioritet men som inte har lösts är möjligheten att välja testtyp via en drop down-lista i Perception. Detta är något som behöver ses över och lösas för att rapportverktyget ska kunna garantera full funktionalitet.
5.3 Design
Målsättningen var att göra prototypen så lik den färdiga slutprodukten som möj-ligt (se figur 22). Det finns några ändringar som gjorts framförallt när det gäller rapporterna. Initialt var tanken att Recording och Sweep skulle väljas i tabellen och att det sedan skulle finnas en knapp som genererade slutrapporten. Efter diskussioner togs beslut om att istället placera val av Recording och Sweep un-der tabellerna eftersom det då direkt går att kopiera tabellerna och således be-hövs ingen extra knapptryckning. I övrigt är det mindre justeringar av disposi-tion, avgränsare och fontstorlekar som tillkommit.
5.4 Tester
Återskapa projekt
Vid återskapandet av det tidigare projektet hittades några avvikelser som kunde justeras dels genom att ändra en exportparameter från Perception, dels genom att lägga till funktion för en av enheterna. Ett av värdena redovisas, i slutrappor-ten, med prefixet mega (MA²·s) men exporteras utan prefix från Perception. För att lösa det har funktion lagts till som testar att dela talet med 1000000 och med 1000 och lägger, i respektive fall, till prefixen M respektive k framför talet om värdet blir större än ett.
Efter de åtgärderna kunde hela projektet återskapas med rätt värden.
Figur 22: Jämförelse av prototyp (till vänster) mot färdig applikation (till höger)
Validering av kod
All HTML och CSS har validerats och några fel har åtgärdats. Det mest primära felet bestod av att id, för drop down-listorna Recordings och Sweeps, förkom på flera ställen. Eftersom dessa läses in som partiella vyer lästes också deras id:n in flera gånger och för att komma runt det har koden gjorts om så att id inte längre används för dem. Istället hanterats funktionen genom taggarna <select>
och <option> samt attributet selected (se figurerna 23 och 24).
Det finns ett antal punkter kvar som W3C anser är fel men alla dessa rör koden som har med tabellernas format att göra för rapportmallarna. W3C anser att ko-den är föråldrad och att CSS ska användas istället men vid tester av W3Cs re-kommenderade lösning följer inte formateringen med till dokumentet på ett till-fredsställande sätt. Till exempel ändrades bredden på tabellen från attributet width=”100%” (vilket fungerar som tänkt vid kopiering) till att istället använda Bootstrap-klassen class=”w-100”. Det ger samma resultat i webbläsaren men när tabellen kopieras till dokumentet blir tabellen betydligt bredare än margina-lerna. När rapportverktyget testades i olika webbläsare fungerade tabellerna i samtliga och därför kommer formateringen för tabellerna att kvarstå.
Test av CSS gav ett resultat utan anmärkning.
Responsivitet och test av webbläsare
I samtliga webbläsare responderar rapportverktyget på samma sätt och fungerar som tänkt. I enstaka fall blir rapportmallarna bredare än skärmen men det finns stöd för att scrolla tabellen i sidled. Eftersom verktyget nästan uteslutande är tänkt att fungera för större skärmar anses detta acceptabelt. Rapportverktyget fungera som tänkt i samtliga testade webbläsare med endast mycket små skill-nader som till exempel hur formulärelement visas. Detta är inget som kan verkas i koden utan styrs helt av webbläsaren. Det är inte heller något som på-verkar design eller funktion.
Figur 23: Första lösningen, med id, för att komma åt värdena i listan med Sweeps
$("#commonTableSweeps > #sweeps").val()
Figur 24: Ny lösning, utan id, för att komma åt värdena i listan med Sweeps
$("#commonTableSweeps > select > option:selected").val()
Tillgänglighet
Alla genomförda tester gav godkända resultat vilket, i Lighthouse, motsvarar värden mellan 90 och 100 (se figurerna 25, 26 och 27). För tillgänglighet gavs betyget 100 av 100 på samtliga sidor. Performance och Best Practice fick ned-slag på några enstaka punkter som rör att JavaScript och CSS hämtas från exter-na sidor och från Bootstrap respektive jQuery men eftersom det påverkar resul-tatet väldigt lite och vinningen är så stor anses det acceptabelt.
Figur 25: Lighthouse-resultat
för Import logfile Figur 26: Lighthouse-resultat
för Project settings Figur 27: Lighthouse-resultat för Create report