Man kan anta att Grace Hopper, en datavetare vid Harvard University, inte hade den bästa dagen den 9 september 1947. Hennes dator returnerade upprepade gånger fel utan någon tydlig anledning. När Grace öppnade den hittade hon en riktig bugg, en mal för att vara exakt, som störde dess funktion. Därmed blev hon den första personen att rapportera en datorbugg.
I själva verket orsakas programvarufel inte av saker som malar (även om våra utvecklare önskar att alla korrigeringar kunde vara så enkla!) Snarare är en mjukvarubugg ett fel i systemet som gör att det producerar felaktiga resultat eller beter sig oväntat. På Easy LMS strävar vi efter att bygga ett buggfritt system åt dig! Men faktum är att ett buggfritt system är lika sällsynt som en enhörning. Easy LMS är byggt av människor och är föremål för mänskliga fel, vilket innebär att buggar slinker igenom då och då.
Eftersom vi vet hur irriterande det är när det finns buggar har vi en process på plats för att få buggar fixade så fort som möjligt! Här är en inblick i hur denna process fungerar, från det att du upptäcker en bugg till den slutliga korrigeringen.
Fas 1
Du kontaktar oss
Det första steget i processen är där du som kund kommer in i bilden. Låt oss låtsas att du skapar ett nytt prov för att testa en nyanställds kunskaper om säkerhetsstandarder. För att lägga till lite känsla går du för att ladda upp ditt företags logotyp. Istället för att lyckas ladda upp bilden ser du laddningsikonen snurra och snurra och snurra ...
När du har försökt några gånger till är du förmodligen ganska frustrerad. Easy LMS fungerar uppenbarligen inte som det borde! Vad ska du göra nu? Kontakta support omedelbart! Support kommer att vara din kontaktpunkt genom hela processen.
Vi kommer att samla in så mycket information som möjligt om felet
Genom chattrutan når du en medlem av supportteamet. Ett av våra största mål vid denna tidpunkt är att samla in så mycket information som möjligt om buggen. Det kan kännas som att du spelar Tjugo frågor, men det här steget är avgörande för att utvecklingen ska kunna felsöka senare. Du kommer att få de här frågorna:
Vad är menysökvägen för att nå platsen där problemet uppstår?
Vad är den exakta URL:en?
Vilken komponent påverkas? Tentor, kurser, etc.
Vad är namnen på påverkat innehåll och användare?
Vilken plattform och enhet använder du?
Vad försökte du göra när du stötte på problemet?
Vad händer exakt när det här problemet uppstår?
När du har delat med dig av denna värdefulla information är ditt jobb över. Nu kan du luta dig tillbaka, slappna av och låta Easy LMS ta över styrningen!
Fas 2
Vi återger
Ditt jobb kanske är gjort, men det är inte över för den supportmedlem som du har pratat med. Med din tillåtelse kommer han eller hon att logga in på ditt konto och försöka reproducera buggen. För att återgå till vårt tidigare exempel skulle en supportmedlem vanligtvis gå till samma Exam och försöka ladda upp en logotyp själv.
Om supporten inte kan återskapa problemet avslutas processen här. På sätt och vis är det bra att felet inte kan återskapas, eftersom allt borde fungera. Men det hjälper oss inte att gå till botten med vad du upplevde. I fall som dessa kan vi ha några fler frågor och kommer att be dig att meddela oss om det händer igen. Om vi å andra sidan kan återskapa buggen (jösses!) fortsätter processen.
Fas 3
Vi spelar in
Nu när vi har kunnat bekräfta att det är en bugg kommer vi att registrera, eller vad vi säger "logga", all den information som du har lämnat i en strukturerad rapport. Vi loggar buggar i Jira, ett projekthanteringsverktyg. Den här rapporten hjälper andra att hitta den exakta plats och aspekt som buggen gäller. Den andra fördelen med att logga buggar på ett ställe är att andra teammedlemmar, inklusive utvecklare, enkelt kan se om en annan kunds klagomål faller under en befintlig bugg.
Support kommer sedan att märka din konversation med buggens ID-nummer. På så sätt kan vi hitta din kontaktinformation för att be dig om mer information eller ge dig relevanta uppdateringar.
Dev support är där magin händer
Fas 4
Vi felsöker
På Easy LMS arbetar utvecklare och supportkonsulter tillsammans i ett team. När vi tar upp vad vi ska arbeta med härnäst arbetar alla över discipliner för att prioritera buggar mot potentiella nya funktioner baserat på hur brådskande det är. Under det här samtalet kommer vi också att diskutera om en ny funktion skulle vara bättre, i vilket fall buggen skickas in som en funktionsförfrågan istället.
När ditt problem har tagits upp av utvecklingsavdelningen kommer de att identifiera problemet, föreslå en lösning och implementera lösningen inom två dagar.
Fas 5
Vi kommunicerar
Woohoo! Felet är äntligen åtgärdat! Du kommer att meddelas av supportmedlemmen så snart det släpps.
Vid denna tidpunkt kommer vi också att tacka dig för ditt tålamod. Buggar är inte roligt för någon! Inte för dig. Inte för support. Inte för utveckling. Så din förståelse och kommunikation med oss är alltid uppskattad och hjälper verkligen till att göra processen lite enklare för alla inblandade.
