Je zou kunnen aannemen dat Grace Hopper, een computerwetenschapper aan de Harvard Universiteit, niet de beste dag had op 9 september 1947. Haar computer gaf herhaaldelijk foutmeldingen zonder duidelijke reden. Toen ze de computer openmaakte, vond Grace een echte bug, een mot om precies te zijn, die de werking verstoorde. Daarmee werd ze de eerste persoon die een computerbug meldde.
In werkelijkheid worden software bugs niet veroorzaakt door dingen zoals motten (hoewel onze ontwikkelaars zouden willen dat alle fixes zo eenvoudig waren!). Een softwarebug is eerder een fout in het systeem die ervoor zorgt dat het onjuiste resultaten produceert of zich onverwacht gedraagt. Bij Easy LMS streven we ernaar om een bugvrij systeem voor u te bouwen! Maar het is een feit dat een bugvrij systeem net zo zeldzaam is als een eenhoorn. Easy LMS wordt gebouwd door mensen en is onderhevig aan menselijke fouten, wat betekent dat er af en toe bugs doorheen glippen.
Omdat we weten hoe vervelend het is als er bugs zijn, hebben we een proces ingesteld om bugs zo snel mogelijk te laten repareren! Hier ziet u hoe dit proces werkt, vanaf de ontdekking van een bug door u tot de uiteindelijke oplossing.
Fase 1
Neem contact met ons op
De eerste stap in het proces is waar jij, als klant, in het spel komt. Laten we doen alsof je een nieuw examen maakt om de kennis van beveiligingsstandaarden van een nieuwe medewerker te testen. Om wat flair toe te voegen, gaat u het logo van uw bedrijf uploaden. In plaats van de afbeelding succesvol te uploaden, zie je het laadpictogram draaien, draaien en draaien ...
Nadat je het nog een paar keer hebt geprobeerd, ben je waarschijnlijk behoorlijk gefrustreerd. Easy LMS werkt duidelijk niet zoals het zou moeten! Wat moet je nu doen? Neem onmiddellijk contact op met support! Support is je aanspreekpunt tijdens het hele proces.
We zullen zoveel mogelijk informatie over de bug verzamelen
Via de chatbox bereikt u een lid van het ondersteuningsteam. Een van onze belangrijkste doelen op dit moment is om zoveel mogelijk informatie over de bug te verzamelen. Het voelt misschien alsof u Twenty Questions aan het spelen bent, maar deze stap is cruciaal zodat de ontwikkeling later het probleem kan oplossen. Deze vragen worden u gesteld:
Wat is het menupad naar de locatie waar het probleem optreedt?
Wat is de exacte URL?
Welk onderdeel is aangetast? Examens, cursussen, enzovoort.
Wat zijn de namen van de getroffen content en gebruikers?
Welk platform en apparaat gebruikt u?
Wat probeerde u te doen toen u het probleem ondervond?
Wat gebeurt er precies wanneer dit probleem optreedt?
Zodra je deze waardevolle informatie hebt gedeeld, zit jouw taak erop. Nu kun je achterover leunen, ontspannen en Easy LMS de touwtjes in handen laten nemen!
Fase 2
We reproduceren
Jouw taak zit er misschien op, maar niet voor de supportmedewerker met wie je hebt gesproken. Met uw toestemming logt hij of zij in op uw account en probeert hij of zij de bug te reproduceren. In ons eerdere voorbeeld zou een supportmedewerker naar hetzelfde Exam gaan en proberen zelf een logo te uploaden.
Als ondersteuning het probleem niet kan reproduceren, eindigt het proces hier. In zekere zin is het goed dat de bug niet kan worden gereproduceerd, want alles zou moeten werken. Toch helpt het ons niet om tot op de bodem uit te zoeken wat je hebt ervaren. In dit soort gevallen hebben we misschien nog een paar vragen en vragen we je om het ons te laten weten als het weer gebeurt. Aan de andere kant, als we de bug kunnen reproduceren (jakkes!), gaat het proces door.
Fase 3
We nemen op
Nu we hebben kunnen bevestigen dat het een bug is, leggen we alle informatie die u hebt verstrekt vast in een gestructureerd rapport. We loggen bugs in Jira, een hulpmiddel voor projectbeheer. Dit rapport helpt anderen om de exacte plaats en het aspect van de bug te bepalen. Het andere voordeel van het loggen van bugs op één plek is dat andere teamleden, waaronder ontwikkelaars, gemakkelijk kunnen zien of de klacht van een andere klant onder een bestaande bug valt.
Support zal uw gesprek dan labelen met het ID-nummer van de bug. Op die manier kunnen we uw contactgegevens vinden om u om meer informatie te vragen of u relevante updates te geven.
Dev ondersteuning is waar de magie gebeurt
Fase 4
We debug
Bij Easy LMS werken ontwikkelaars en support consultants samen in een team. Wanneer we bespreken waar we als volgende aan moeten werken, werkt iedereen discipline-overschrijdend om bugs te prioriteren ten opzichte van potentiële nieuwe functies op basis van tijdsurgentie. Tijdens dit gesprek bespreken we ook of een nieuwe functie beter zou zijn. In dat geval wordt de bug ingediend als een verzoek voor een functie.
Zodra je probleem is opgepikt door ontwikkeling, zullen zij het probleem identificeren, een oplossing voorstellen en de fix binnen twee dagen implementeren.
Fase 5
We communiceren
Woohoo! De bug is eindelijk opgelost! Je krijgt bericht van de supportmedewerker zodra deze wordt vrijgegeven.
Op dit moment willen we je ook bedanken voor je geduld. Bugs zijn voor niemand leuk! Niet voor jou. Niet voor support. Niet voor de ontwikkeling. Dus, uw begrip en communicatie met ons worden altijd gewaardeerd, en helpen echt om het proces een beetje gemakkelijker te maken voor iedereen die erbij betrokken is.
