Användarna

Eftersom unittestning oftast utförs av programmeraren själv kan man utgå från att användaren av ASL, dvs. testaren, är mjukvaruutvecklare av något slag och att detta gäller för användarna av de flesta testverktyg. Man kan göra ett generellt antagande om att testare av mjukvara alltid har avancerade kunskaper om IT och de system de testar, samt att de ofta är systemutvecklare av något slag.

utvecklare och programmerare är en användargrupp som skiljer sig från andra typer av IT-användare. Inte så mycket på det sätt människor tar till sig information och bearbetar den, utan på vilken nivå de gör det och i sitt beteendemönster. Den här typen av expertanvändare (power-users) av informationsteknologi har kunskap om de system de använder, de önskar information av detaljerat och tekniskt slag samt använder ofta andra och mer avancerade verktyg än en normal användare. Verktyg som inte nödvändigtvis behöver vara alltför användarvänliga utan snarare innehåller en hög funktionalitet. De har en vana vid IT-hantering och de generella begrepp, symboler samt användningsmönster som är gemensamma för gränssnitt i de flesta IT-system. Detta ger möjlighet att snabbt tillägna sig ny mjukvara och börja använda den.

Kontrollbehov

Den historiska utvecklingen av gränssnitt har gått mot att alltmer skilja användaren från den bakomliggande tekniken. De skall slippa att ta hänsyn till filhantering, felhantering och inställningar. Många operationer automatiseras och användaren skyddas från ”farliga moment”. Denna utveckling har fått till följd att en del av kontrollen över tekniken har flyttats från användaren till gränssnittet.

Den viktigaste skillnaden mellan expertanvändare och normala användare är just behovet av kontroll. Utvecklare behöver ha direkt kontroll över de system de utvecklar och den miljö de verkar i. Exakt information och kontroll över verktygen är absolut nödvändigt för att kunna analysera och evaluera utvecklingsarbetet.

Det här kontrollbehovet tar sig oftast uttryck i att man föredrar kommandobaserade gränssnitt, använder enkla textbaserade program med fokus på funktionalitet, samt manipulerar filer och inställningar manuellt via texteditorer och kommandoprompt. Det finns en klassisk motvilja mot operativsystem och programvara som flyttar kontrollen från användaren till gränssnittet, tex Microsoft Windows. Dessa typer av gränssnitt döljer funktionaliteten och tar bort valmöjligheter för användaren som kan vara farliga/kritiska för systemet. Information som är för teknisk eller abstrakt för normalanvändaren reduceras bort.

IT-utvecklaren vill dock ha kvar sådana möjligheter att påverka och övervaka systemet och om man skall utveckla grafiska gränssnitt för den typen av användare bör man ta hänsyn till detta.

Utrymmesbehov

En förlängning på resonemanget om att användarna behöver kontroll, är att de behöver överblick över alla parallella arbetsuppgifter. Testningen sker samtidigt med andra faser i mjukvaruutvecklingen som programmering och i detta arbete används en mängd olika applikationer samtidigt. Samtidigt behöver användarna utrymme för andra aspekter av det dagliga arbetet. Kommunikation via email, dokumenthantering och schemaläggning är exempel på detta.

Vår applikation skall passa in i denna miljö och den skall kunna köras parallellt med övriga program – utan att stjäla vare sig för mycket arbetsyta eller för mycket prestandaresurser. Därför bör man utveckla en ”parasitic-posture”-applikation. Med detta menas att den skall kunna exekvera ”i bakgrunden” utan att låsa upp arbetsytan och därmed göra det omöjligt att samtidigt jobba med övriga program. Således bör användargränssnittet byggas så utrymmessnålt som möjligt.

(Riktlinje: Tillmötesgå användarens utrymmesbehov)

Behov av stöd - som hjälp och feedback

På grund av den mycket höga kunskapsnivån hos användarna finns inget stort behov av en stor hjälpsektion. Den tid det tar att utveckla en uttömmande och korrekt hjälpsektion står inte i paritet med behovet av den. Den behöver endast innehålla det mest nödvändiga. Fundamental kunskap om DPE som användarna redan besitter och är en förutsättning för att utveckla och testa DPE behöver man överhuvudtaget inte ta upp. Endast en enkel beskrivning av de olika beståndsdelarna och hur man hanterar dem. Ambitionen är att göra gränssnittet tillräckligt enkelt och intuitivt så att de flesta operationerna är självinstruerande och självklara.

Av samma anledning kan man rationalisera bort andra hjälpverktyg helt och hållet, som tutorial och walkthrough. Ett sådant stöd är endast irriterande och tidsödande för användarna, programmet är så begränsat och skall vara så lätt att handha att om sådant stöd ändå behövs, är designen misslyckad överlag.

Däremot urskiljer vi ett behov av information som är teknisk och ger insyn i det bakomliggande systemet, ASL. Användarna har använt det tidigare och kan tänkas vilja göra manuella justeringar vid sidan om. De är vana vid ASL och litar både på systemet och sin egen kapacitet. Den feedback som strömmar mot användaren under hanteringen bör därför informera honom vad gränssnittet manipulerar i ASL. Förtrogenheten med tekniken och systemen innebär också att felhantering vid tex. undantag kan presenteras med de meddelanden som produceras av exekveringsmiljön, istället för att formuleras om och anpassas till mer ”användarvänlig” feedback. Det är nästan fallet att användarna redan är anpassade efter systemet och inte tvärtom.

Installationsprocessen

Om man införlivade ett installationsstöd i gränssnittsapplikationen skulle det innebära att användarna slapp ett ganska ansträngande arbetsmoment, som både tar tid att lära sig och utföra. Men det finns i huvudsak tre argument mot att göra detta.

1. Det är ett moment som utförs ytterst sällan.

2. Det finns en nytta med att användaren lär sig momentet. Man får en inblick i filstrukturen, vilka beståndsdelar som skall vara med. En kunskap som underlättar för användaren att göra manuella justeringar i framtiden.

3. Att bygga in stöd för installationsmomentet skulle ta mycket tid.

Framförallt är det ett oprioriterat moment som inte nödvändigtvis behöver finnas med. Om man vill behålla applikationen så enkel och avskalad som möjligt bör alla sådana typer av oprioriterad verktyg rationaliseras bort. Enkelhet underlättar hanteringen av och förståelsen för programmet.