Indledning· Beslutte· Analysere· Organisere· Forbedre· Inspicere· Vedligeholde·
QA Hjemmeside· Seneste nyheder· QA Ressourcer· QA IG· QA WG· QA Kalender·
Denne artikel er produceret som en del af arbejdet i W3Cs Interessegruppe for Kvalitetssikring. Offentlige kommentarer bedes venligst sendt til mailinglisten for det offentlige arkiv på public-evangelist@w3.org. Private kommentarer bedes sendt til Karl Dubost karl@w3.org.
Forfatteren anerkender de personer, der har bidraget med ideer og kommentarer.
Oversættelser af dette dokument er velkomne. Før du giver dig i kast med en oversættelse af dokumentet bedes du venligst læse vejledningen om oversættelser i vores Copyright FAQ, samt checke listen med eksisterende oversættelser af dette dokument (findes på http://www.w3.org/QA/translations#switch).
Uanset om du er leder, webudvikler, marketing- eller informationsmedarbejder, eller selvstændig webmaster har du læst om interessen for web standarder mange forskellige steder. Du forstår, at standarder giver dit netsted mange fordele i form af reducerede omkostninger, lettere styring og profitabilitet. Du har derfor besluttet dig for at ændre kurs - og basere dit netsted på standarder.
Desværre har du ikke fundet en vejledning, som forklarer hvordan du starter processen og organiserer forandringen frem mod et netsted, der overholder standarderne. Du tror måske, at det er et uopnåeligt mål hvis der er tale om store netsteder. Hvis du er usikker på hvad der menes med web standarder vil vi opfordre dig til at læse Hvad web standarder virkelig betyder [WEB-QUALITY], hvordan man køber og udvikler et netsted af høj kvalitet [REQ-WEBAGENCY] og hvorfor det giver økonomisk mening at udvikle et tilgængeligt netsted [WAI-PROFIT]
Uanset netstedets størrelse kan metoden i dette dokument anvendes; metoden passer således til såvel private netsteder som små og store virksomheders netsteder.
Vi fører dig gennem de enkelte trin - som du vil være i stand til selv at gennemføre - fra analysen af dit nuværende netsted til organiseringen af dit nye netsted. Hvert trin er tilrettelagt så det er selvstændigt; de kan gennemføres i et samlet workflow på forskellige tidspunkter, på forskellige niveauer og af forskellige personer uafhængig af deres vidensniveau.
Ligegyldig om dit netsted er stort eller lille er det nødvendigt at begynde at evaluere det i forhold til standarderne; sandsynligvis er der mange af siderne, der ikke overholder de kvalitetskriterier, du har defineret for kvaliteten af dit netsted.
Bring dine informationsmedarbejdere, tekniske medarbejdere, marketing og ledelsen sammen for at lave en liste over alle de ting, du gerne vil evaluere på dit netsted. I denne fase af arbejdet er der ingen grund til at prioritere de forhold, du gerne vil rette. Vi anbefaler imidlertid som minimum at checke validiteten (HTML og CSS), tilgængeligheden og internationaliseringen på dit netsted. Du kan finde forklaringer på teknikkerne nedenfor i denne artikel.
Denne artikel skitserer en metode til at forbedre dit netsted i overensstemmelse med W3C standarderne. Du kan ligeledes anvende strategien i forhold til andre krav, som dit netsted bør opfylde. Vi foreslår følgende ufuldstændige liste:
Nogle gange har du eller dit team ikke de nødvendige forudsætninger eller den nødvendige forståelse af problemerne på dit netsted; hvis dette er tilfældet så spørg om hjælp. Inviter en person, som er specialist i tilgængelighed eller internationalisering til at deltage i dit team. I forbindelse med tilgængelighed (handicappedes muligheder for at anvende dit netsted) kan du eksempelvis henvende dig til en lokal blindeorganisation - i de fleste tilfælde vil de være endog meget villige til at bistå dig. Hvis du er en del af en større organisation er det sandsynligt, at din virksomhed beskæftiger mennesker med funktionsnedsættelser. Spørg i personaleafdelingen og foreslå, at de deltager i dette projekt.
Nu da du ved hvad du vil teste, bliver du nødt til at afgøre hvilke problemer, der findes på dit nuværende netsted. En god metode er at udarbejde en komplet liste over de URI'er, der tilhører dit netsted. Det kan man gøre uden de store komplikationer - oftest er det nok at anvende en simpel spider, som forfølger links på siderne og gemmer dem i en almindelig tekstfil (fx med en URI pr. linje).
Det kan hænde, at den den teknologi som benyttes på dit netsted ikke er tilgængelig for en spider; dette kan på sin vis være en metode til at afgøre antallet af netsider, som er utilgængelige. Basalt set vil denne øvelse vise dig hvilke sider, der ikke kan indekseres af en søgemaskine, hvilket betyder at du i praksis udelukker trafik til dit netsted.
Når du har lavet din liste kan du anvende den med LogValidator [LOG-VALIDATOR], som er et program, der er specielt udviklet til at hjælpe dig med at teste. LogValidator tager en liste af URI'er og analyserer dem i forhold til det modul du har valgt at anvende når du begynder testen. (Dette er en opgave for dine systemfolk; diskuter med dem hvorledes det skal implementeres i din konfiguration.) For hver URI gennemfører programmet en serie tests og giver dig de tilhørende resultater.
Efter denne første analyse har du en oversigt over dit netsteds sundhedstilstand, og du kan fastlægge en strategi for at organisere det videre arbejde, herunder rettelse af siderne med fejl. Du har muligvis et meget stort antal sider, som ikke overholder dine krav. Eksempelvis kan det være, at alle dine sider er invalide i forhold til HTML/XHTML specifikationen. Fortvivl dog ikke - dette er faktisk en god nyhed! Hvorfor? For hvis du anvender en løsning baseret på skabeloner eller et content management system til at genere dine netsider så betyder det, at du helt sikkert har fejl i dine skabeloner.
Løsningen er enkel; du skal bare rette dine skabeloner og køre hele testen igen; herefter kan det være at du har færre fejl, eller måske slet ingen. Hvis det ikke er dig, der udvikler skabelonerne i løsningen, så spørg den eller de personer, der har udviklet content management løsningen til dit netsted om at foretage rettelserne. Og når tiden kommer til at re-designe dit netsted, så følg anbefalingerne i dokumentet Køb netsteder, som overholder standarderne [REQ-WEBAGENCY].
Fortvivl ikke hvis du fortsat har fejl i dine netsider efter denne først test - denne vejledning hjælper dig med at rette dem.
En yderlige fordel ved dette første trin er, at det giver dig et konkret overblik over alle siderne på dit netsted. Dette betyder, at du vil være bedre i stand til at re-dirigere dine besøgende til nye sider, hvis du ønsker at flytte en side eller slette en del af netstedet. Dermed undgår du at miste trafik fra eksterne links (eksempelvis fra andre netsteder og fra søgemaskiner.) Husk, at seje URI'er ikke ender blindt.
Du har nu en liste over alle de netsider, der ikke er valide eller som indeholder andre fejl og mangler. Det har ingen indflydelse på metoden om listen er kort eller lang. Det første princip er enkelt: "Ret ikke! Du skal forbedre og organisere dit arbejde"
Det er ikke nødvendigt at rette alle netsider på en gang. Det er der to primære grunde til:
Du bør heller ikke forsøge at løse en bestemt kategori af fejl for sig selv og lade de øvrige problemer ligge indtil dette er sket. Hvis du eksempelvis ønsker at gøre dine HTML sider valide og samtidig gøre dem tilgængelige bør du gøre begge dele på en gang. Hvis du laver den ene rettelse først, og venter med den anden til et senere trin i fejlrettelsen, risikerer du at introducere nye problemer og dermed påvirke resultatet af de første rettelser i negativ retning.
Derfor: Forsøg ikke at rette det hele på engang og løs ikke problemer i trin. I stedet bør du forbedre din proces.
I denne metode er nøglen til succes at være realistisk når der skal træffes beslutninger, og sikre at beslutningerne vil føre til de mest effektive resultater. Hvis du ønsker at forbedre dine netsider bliver du nødt til at afgøre hvor lang tid det vil tage at rette alle identificerede fejl på hver enkelt side. Prøv med et aktuelt udvalg af netsider, som har fælles problemer, og overvej en passende sammensætning af mennesker og ressourcer i relation til netstedets workflow.
Når du har fastlagt tidsforbruget for et begrænset antal sider, kan du foretage et mere præcist estimat af det samlede behov for mennesker og andre ressourcer til at løse opgaven, ligesom du vil have et estimat over hvor mange sider det er realistisk at rette hver dag.
Vi anbefaler, at du foretager rettelser på daglig basis i stedet for på uge- eller månedsbasis. Det vil være lettere for personen, der har fået opgaven, at planlægge tiden for arbejdet, og det vil tage kortere tid pr. dag end pr. uge. Det er lettere og en mere overskuelig opgave at rette 5 sider om dagen end 25 sider en dag på en uge.
Hold regelmæssige møder med det team, der har ansvaret for at gennemføre disse opgaver; noter deres meninger, argumenter og erfaringer. Dette vil hjælpe dig med at afgøre om gentagne problemer stammer fra content management systemet eller fra selve redigeringsprocessen. Dermed vil du blive i stand til på en gang at forbedre såvel din proces som kvaliteten af de værktøjer, du anvender.
Efter et stykke tid vil du være i stand til at fastsætte milepæle på grundlag af din erfaring med implementeringen af metoden. Eksempelvis: 50% af trafikken til dit netsted vedrører sider, som overholder de kvalitetskriterier, som du har fastsat. Når dette mål er nået, kan du løfte målet til 60%, etc. Uanset hvad du beslutter dig for at teste eller opnå, er det vigtigt at du begrænser dig og er realistisk; denne metode handler om skabe løbende, men opnåelige resultater og forbedringer.
Hvis projektet skal være en succes er det nødvendigt at inddrage alle, som tager del i publiceringen, i forløbet. Indblik i værktøjerne og de redskaber, der aktuelt anvendes vil hjælpe dig med forstå hvor problemerne opstår - er det et problem med værktøjet eller skyldes problemet snarere den person, som anvender værktøjet? Hvis fejlene skabes af et redigeringsværktøj, vil det hjælpe at opsamle kommentarer og diskutere problemerne med udviklerne af værktøjet så de kan forbedre deres software. Dette gælder især for store virksomheder, hvor der er mange brugere, og er en mere hensigtsmæssig måde at opnå forbedringer på.
Kommuniker forbedringerne, om ikke offentligt så i det mindste blandt medarbejderne i teamet. Det gør fremdriften synlig og motiverer alle til at fortsætte. Hvis du har identificeret problemerne, som findes i dit publiceringssystem, kan det kun gå fremad herfra.
LogValidator [LOG-VALIDATOR], som allerede er blevet nævnt i denne artikel, kan hjælpe dig med at forbedre dit netsted ved at identificere de dele af netstedet, der indeholder fejl. I sin grundudgave er dette værktøj designet til progressivt at checke om alle HTML dokumenter er valide. Det grundlæggende princip er enkelt: ud fra en web server logfil skaber programmet en liste over de dagligt mest læste sider; programmet samler herefter de første n sider af dette resultatsæt (hvor n er et tal, som defineres af dig) og sender dem til W3C Markup Validator. Efter validering sendes resultaterne tilbage til dig.
Hvad er fordelene? På denne måde retter du de mest læste sider først og evaluerer kvaliteten af dit netsted udfra dette princip - og ikke i forhold til det absolutte antal sider.
LogValidator er baseret på en åben og modulær arkitektur og er skrevet i Perl; du kan selv udvikle og tilføje moduler efter behov. Du kan eksempelvis udvikle en stavekontrol eller et modul, som checker om logoet og informationen i bundteksten er korrekt placeret på dine sider. Eller du kunne måske lave et modul, som checker for brudte links på dit netsted. Det er altså et værktøj, som er let at installere og som er del af CPAN arkivet.
Mulighederne er endeløse og det er derfor bedst at forblive realistisk når du fastsætter dine mål.
Efter at have taget LogValidator i brug kan du fortsætte ad forskellige veje når det gælder analyse af resultaterne fra LogValidator. Du kunne eksempelvis etablere en intern mailing liste hvor dit nye web QA team hver morgen modtager en liste over URI'er, som bør efterses, og hvor dit team enten er nødt til at rette indholdet eller rapportere hvis kilden til problemet ligger et andet sted.
Den trinvise metode hjælper dig med at vedligeholde kvaliteten på dit netsted, men det er stadig nødvendigt løbende at undersøge om problemerne gentager sig.
Gentag derfor den fuldstændige analyse en gang imellem (eksempelvis hver 3. måned) for at bekræfte om du har hævet den generelle kvalitet på netstedet, og ligeledes for at afdække problemer, som skyldes håndteringen af skabeloner. Dette vil ligeledes bistå dig i at nå de mål, du satte dig i begyndelsen. Hvis netstedets kvalitet ikke er stigende, bliver du nødt til at foretage ændringer i din proces.
Endelig vil det motivere dit team og de andre mennesker, der er involveret i arbejdet, at præsentere dem for resultaterne. Lidt efter lidt vil du opbygge en erfaring, som er værdifuld for din organisation. Lav en liste over alle de ting, der er sket, og udgiv den samtidig med at du gennemføre denne inspektion. Listen bliver en opdateret manual over kvaliteten på dit netsted.
I mange tilfælde findes der en style guide i din virksomhed, som beskriver virksomhedens farver og dets logo. Denne guide kan udvides med de enkle teknikker, der kan hjælpe folk med at forbedre netstedet hver gang man opdager en fejl.
Metoden i denne vejledning er dynamisk og ikke støbt i beton; det er nødvendigt at den udvikler sig efter dine behov. Det er nødvendigt at justere din publiceringsproces og dermed din QA proces hvis din publiceringsrutine indeholder krav, som ikke længere er relevante, eller hvis der er blevet tilføjet nye krav.
Den foreslåede løsningen til at evaluere og forbedre kvaliteten er opdelt i uafhængige komponenter, som ikke har indflydelse på hinanden. Du kan derfor fjerne komponenter, som der ikke længere er behov for, og tilføje nye komponenter efterhånden som behovet opstår.
Der kan opstå situationer, hvor det ikke er praktisk muligt umiddelbart at finde en løsning fordi det er umuligt for dig selv at foretage ændringerne. Det kan eksempelvis være, at du anvender et redigeringsværktøj, som ikke producerer valid kode. Du har forsøgt mange metoder og søgt at arbejde omkring problemet, men intet virker. Det er meget vigtigt at opsamle denne type information og sende den til producenten, ikke som privatperson, men på vegne af din virksomhed. Du udgør en del af virksomhedens marked og den vil tage din kritik til efterretning.
For at bevare kvaliteten på dit netsted, er du nødt til at belønne gode interne forfattere og hjælpe dem, som har problemer. Med mindre dine brugere kan se fordelene ved dine valgte metoder er det ikke en succes. Inviter dem, bed dem om at rapportere eventuelle problemer i processen, med værktøjerne, etc. Det vil forbedre hele organisationen.
Denne metode er enkel og har været anvendt i en årrække indenfor W3C til at sikre validiteten af alle HTML sider. Metoden kan være særdeles effektiv hvis du anvender den i din egen virksomhed eller i dit team.
Tak til de mennesker, der har gennemgået denne artikel: Olivier Théreaux, Stephanie Troeth, Denis Boudreau og alle folk på public-evangelist mailing-list.
Skabt: 2003-03-28 af Karl Dubost >karl@w3.org>