Den 9. september 1947 hadde Grace Hopper, en datavitenskapskvinne ved Harvard University, ikke den beste dagen. Datamaskinen hennes ga gjentatte feilmeldinger uten noen klar grunn. Da Grace åpnet den, fant hun en faktisk feil, nærmere bestemt en møll, som forstyrret dens funksjon. Dermed ble hun den første personen som rapporterte en datamaskinfeil.
I virkeligheten skyldes ikke programvarefeil ting som møll (selv om utviklerne våre skulle ønske at alle feilrettinger kunne være så enkle!) En programvarefeil er snarere en feil i systemet som fører til at det produserer feil resultater eller oppfører seg uventet. Hos Easy LMS har vi som mål å bygge et feilfritt system for deg! Men faktum er at et feilfritt system er like sjeldent som en enhjørning. Easy LMS er bygget av mennesker, og er utsatt for menneskelige feil, noe som betyr at feil slipper gjennom fra tid til annen ?
Siden vi vet hvor irriterende det er når det oppstår feil, har vi en prosess på plass for å få feil rettet så raskt som mulig! Her får du et innblikk i hvordan denne prosessen fungerer, fra du oppdager en feil, til den endelige feilrettingen.
Fase 1: Du kontakter oss
Det første trinnet i prosessen er der du som kunde kommer inn i bildet. La oss si at du oppretter en ny eksamen for å teste en nyansatts kunnskap om sikkerhetsstandarder. For å legge til litt stil, går du for å laste opp bedriftens logo. I stedet for å laste opp bildet, ser du lasteikonet spinne, og spinne, og spinne ...
Etter å ha prøvd det et par ganger til, er du sannsynligvis ganske frustrert. Easy LMS fungerer tydeligvis ikke slik det burde! Hva bør du gjøre? Kontakt kundestøtte umiddelbart! Kundeservice vil være ditt kontaktpunkt gjennom hele prosessen.
Vi vil samle inn så mye informasjon som mulig om feilen
Gjennom chat-boksen kommer du i kontakt med et medlem av supportteamet. Et av våre viktigste mål på dette tidspunktet er å samle inn så mye informasjon som mulig om feilen. Det kan føles som om du leker Tjue spørsmål, men dette trinnet er avgjørende for at utviklingsavdelingen skal kunne feilsøke senere. Du vil bli stilt disse spørsmålene:
Hva er menystien for å nå stedet der problemet oppstår?
Hva er den nøyaktige URL-en?
Hvilken komponent er berørt? Eksamener, kurs, osv.
Hva er navnene på innholdet og brukerne som er berørt?
Hvilken plattform og enhet bruker du?
Hva prøvde du å gjøre da du opplevde problemet?
Hva skjer egentlig når dette problemet oppstår?
Når du har delt denne verdifulle informasjonen, er jobben din over. Nå kan du lene deg tilbake, slappe av og la Easy LMS ta styringen!
Fase 2: Vi gjengir
Jobben din er kanskje gjort, men den er ikke over for supportmedarbeideren du har snakket med. Med din tillatelse vil han eller hun logge inn på kontoen din og prøve å reprodusere feilen. For å referere til eksemplet fra tidligere, vil et supportmedlem vanligvis gå til samme eksamen og prøve å laste opp en logo selv.
Hvis supporten ikke kan reprodusere problemet, avsluttes prosessen her. På en måte er det bra at feilen ikke kan reproduseres, for da burde alt fungere. Likevel hjelper det oss ikke med å komme til bunns i hva du har opplevd. I slike tilfeller kan det hende vi har noen flere spørsmål, og vi vil be deg om å gi oss beskjed hvis det skjer igjen. Hvis vi derimot kan reprodusere feilen (jøss!), vil prosessen fortsette.
Fase 3: Vi spiller inn
Nå som vi har fått bekreftet at det er en feil, registrerer vi, eller det vi kaller "logger", all informasjonen du har oppgitt i en strukturert rapport. Vi logger feil i Jira, et prosjektstyringsverktøy. Denne rapporten hjelper andre med å finne det nøyaktige stedet og aspektet som feilen gjelder. Den andre fordelen med å loggføre feil på ett sted, er at andre teammedlemmer, inkludert utviklere, enkelt kan se om en annen kundes klage faller inn under en eksisterende feil.
Kundestøtte vil deretter merke samtalen din med feil-ID-nummeret. På den måten kan vi finne kontaktinformasjonen din for å be deg om mer informasjon eller gi deg relevante oppdateringer.
Det er i utviklingsstøtten magien skjer
Fase 4: Vi feilsøker
Hos Easy LMS jobber utviklere og supportkonsulenter sammen i et team. Når vi skal finne ut hva vi skal jobbe videre med, jobber alle på tvers av fagområder for å prioritere feil opp mot potensielle nye funksjoner basert på hvor mye det haster. I løpet av denne samtalen vil vi også diskutere om en ny funksjon ville vært bedre, og i så fall sendes feilen inn som en funksjonsforespørsel i stedet.
Når problemet ditt har blitt plukket opp av utviklingsavdelingen, vil de identifisere problemet, foreslå en løsning og implementere løsningen i løpet av to dager.
Fase 5: Vi kommuniserer
Woohoo! Feilen er endelig løst! Du vil bli varslet av supportmedlemmet så snart det blir utgitt.
På dette tidspunktet vil vi også takke deg for din tålmodighet. Bugs er ikke gøy for noen! Ikke for deg. Ikke for support. Ikke for utviklingen. Så vi setter alltid pris på din forståelse og kommunikasjon med oss, og det bidrar til å gjøre prosessen litt enklere for alle involverte.
