Användarens guide till Support-Bugzilla - Digpro · Användarens guide till Support-Bugzilla...
Transcript of Användarens guide till Support-Bugzilla - Digpro · Användarens guide till Support-Bugzilla...
Användarens guide till
Support-BugzillaVersion 1.0
Digpro Solutions AB
Ulriksborgsgatan 5
112 18 , Stockholm
1
Innehåll
Inledning 2
Skapa ett konto 2
Användargränssnitt 3
Skapa ett ärende 3
Bugg- och problemrapportering 7 Exempel buggrapport 8
Beställningsförfrågan 9 Exempel beställningsförfrågan 10 Hantering av ärenden 10
Övrigt 13 Visa java-konsolen i Windows 10 13 Bifoga stacktrace från java-konsolen 13
2
Inledning Bugzilla fungerar som navet i Digpros ärendehantering. Om man som kund stöter på ett problem eller behov som gör att man vill komma i kontakt med Digpro är det genom Bugzilla kommunikationen i regel kommer att ske. Genom Bugzilla hanteras framför allt:
● Frågor kring hur Digpros applikationer fungerar
● Rapportering av eventuella fel och buggar
● Önskemål och beställningar kring utökad funktionalitet
I korthet är Bugzilla en kanal för att diskutera och hantera frågor kring Digpros applikationer med Digpros personal, egna kollegor och andra kunder till Digpro.
Skapa ett konto Första steget för att få tillgång till Support-Bugzilla är att en kollega med tillgång till systemet lägger upp ett ärende med en begäran om ett nytt konto. I begäran ska namn och e-mailadress till den nya användaren inkluderas. Har man inte redan en kollega som har ett konto i Support-Bugzilla kan man istället vända sig till sin kontaktperson på Digpro, i regel den så kallade kundansvarige.
Nästa steg, efter att begäran kommit in, är att personal hos Digpro skapar ett konto till den nye användaren som sedan får ett bekräftelsemail.
Genom att klicka på den övre länken under To complete the change, visit the following link: kommer man till sidan där lösenordet kan återställas.
3
Användargränssnitt När man loggar in på support-bugzilla.digpro.se möts man av en sida från vilken man kan posta nya ärenden, söka bland befintliga ärenden och ändra inställningar för t.ex. mailutskick.
Skapa ett ärende 1. För att skapa ett ärende börjar man med att klicka på File an issue på sidan man
möts av efter att ha loggat in.
4
2. Man får sedan välja under vilken kategori (kallad product) man vill att ärendet ska skapas. I regel väljer man här företaget man representerar men om man sitter med i en av applikationernas så kallade användarföreningar och vill framföra ett förslag till den kan man också välja att kategorisera sitt ärende under Användarföreningen.
5
3. Efter att ha valt en övergripande kategori länkas man till sidan för att skriva in den matnyttiga informationen kopplad till ärendet. Första steget här är att visa de mer ingående fälten genom att klicka på Show advanced fields (vilket förstås redan gjorts i bilden).
4. Under Component anger man vilken av Digpros applikationer/moduler som ärendet gäller.
6
5. Under Version anges applikationens version. Versionsnumret för Digpros applikationer kan man bland annat hitta i den aktuella applikationens fönster-namn samt under huvudmenyn, Hjälp -> Om i applikationen.
6. Under Severity väljer man vilken typ av ärende det handlar om. Nedan definieras de olika valen. Support: Generella supportfrågor Error report: Bugg- och felrapporter Order: Frågor gällande beställningar och vidareutveckling
7. Under Hardware väljer man vilken plattform (PC/Mac etc.) som används.
8. Under OS väljer man vilket operativsystem (Windows/MacOS etc.) som används.
Fältet Priority används till att sätta hur allvarligt man anser att felet är. Nedan definieras hur de olika valmöjligheterna ska användas. Övriga fel och ärenden: Beställningar samt mindre allvarliga buggar Fel som medför störning: Buggar/problem med påverkan på verksamheten Mindre akut: Buggar/problem med stor påverkan på
verksamheten Akut: Driftstopp (t.ex. att applikationen inte startar)
9. Fältet Assignee ska inte editeras utan administreras antingen automatiskt eller internt av Digpro.
10. Under fältet CC kan man om man vill lägga till mailadresser på de kollegor man tycker bör följa med i utvecklingen av det aktuella ärendet. Kravet för att man ska kunna lägga till en kollega är att hen har ett aktivt konto i Support-Bugzilla.
11. Fältet Alias används i nuläget inte och behöver alltså inte fyllas i.
12. Under fältet URL kan man lägga till eventuella URL:er som är relaterade till ärendet. Det kan t.ex. handla om en länk till en avbrottskarta.
13. I fältet Summary skriver man en kortare, informativ text som beskriver ärendet. Texten ska vara relativt kort men ändå så pass informativ att det tydligt framgår vad ärendet handlar om.
14. Hur fältet Description ska fyllas i beskrivs under rubrikerna Buggrapportering samt Beställningsförfrågan senare i användarguiden.
15. Under Attachment kan man lägga till filer som är relaterade till ärendet. Det kan t.ex. handla om printscreens från applikationens gränssnitt. Bifogas bilder bör formatet PNG används medans övriga dokument i regel ska bifogas som PDF.
16. Fältet Keywords sätts internt av Digpro.
7
17. I fältet Depends on kan man om man vill lägga till relaterade ärenden som måste lösas innan man kan gå vidare med det aktuella ärendet.
18. I fältet Blocks kan man om man vill lägga till relaterade ärenden som blockeras av det aktuella ärendet (alltså motsatsen till Depends on).
Bugg- och problemrapportering Om man har (eller misstänker att man har) hittat en bugg i en av Digpros applikationer ska detta rapporteras genom Support-Bugzilla. Det gäller även om man har ett problem relaterat till någon annan tjänst (t.ex. en integration) som Digpro levererat. Första steget i kedjan efter att en bugg rapporterats är i regel att Digpros personal försöker reproducera buggen i fråga i en lokal miljö. Det gör att det är viktigt att man med så stor tydlighet som möjligt återger vad som inte fungerar. I många fall kan det vara så att en given funktion fungerar vid ett visst tillvägagångssätt men inte vid ett annat och för att man ska hitta felkällan krävs det därför en fullständig specifikation av hur man burit sig åt då felet inträffat.
När man skriver buggrapport ska man utgå från formen Gör, Händer, Förväntat.
● Under Gör definierar man precis hur man ska göra för att återskapa buggen. Stegen ska vara numrerade och bör inledas med att man loggar in i applikationen (alltså: 1. Loggade in i dpPower - Demo energi AB 8.2)
● Under Händer återger man vad som händer när man slutför det avslutande steget under Gör. Det kan t.ex. handla om att man får upp en feldialog eller att applikationen inte reagerar.
● Under Förväntat beskriver man vad man förväntade sig skulle hända efter man slutförde det avslutande steget under Gör. Det kan t.ex. handla om att man vill att en viss symbol ska visas i en kartprodukt eller att en rapport i frågeverktyget ska leverera ett visst resultat.
Utöver de tre rubrikerna Gör, Händer, Förväntat, kan man vid behov också lägga till två extra rubriker, Övrigt och Stacktrace.
● Under rubriken Övrigt kan man lägga till ytterligare information som anser att det är viktigt att Digpros personal har kännedom om. Om man har egna misstankar om vad felet kan bero på (t.ex. korrupta objekt, ny version av applikationen etc.), vet att felet även kan återskapas vid andra tillvägagångssätt än under rubriken Gör eller har extra stora behov av att snabbt få hjälp kan detta delges Digpro under rubriken.
● Under Stacktrace postar man den eventuella stacktrace man får i java-konsolen (se beskrivning senare i användarguiden) efter att man slutfört det sista steget under rubriken Gör.
8
Vid problem som inte handlar om buggar är det inte alltid passande att återge information i en numrerad steg-för-steg lista. I dessa fall är det svårt att ge tydliga riktlinjer för hur informationen bör formateras för att vara så tydlig som möjligt. Men man bör i största möjliga mån, även i dessa fall, använda formen Gör, Händer, Förväntat, för att återge hur felet upptäcktes. Det är även extra viktigt att man delger kringliggande information av värde (som t.ex. sökvägar till filer, vad funktionen ska göra) under rubriken Övrigt för att Digpros personal tydligt ska förstå vad som inte fungerar.
Exempel buggrapport Nedan följer ett exempel på hur en väldefinierad buggrapport kan se ut. I det här fallet kan användaren inte placera en textkomponent till en brytare i schemat.
Gör:
1. Startar dpPower - Demo energi AB 8.2
2. Loggar in i valfritt förändringsset
3. Startar frågeverktyget genom ikonen i övre vänstra hörnet av huvudmenyn
4. Öppnar flik Frågor och väljer Elobjekt -> Brytare -> Brytare 10 kV, klickar på Sök
5. Högerklickar på en brytare i listan, väljer Visa -> Visa i annan vy -> Gör om till schema
6. Högerklickar på brytaren, väljer Placera komponent till objekt
7. Väljer Text ID schema i listan
8. Högerklickar och väljer Placera utan rotation
Händer:
Text ID:t till brytaren placeras inte i schemat efter att man utfört steg 8 och man får även en stacktrace.
Förväntat:
Att ID:t går att placera i schemat.
9
Övrigt:
- Problemet gäller oavsett spänningsnivå på brytaren. - Felet uppkom efter att vi uppgraderat till version 8.0.
Stacktrace:
2017-11-28 16:33:47 [1cda43fe:c7cbcf5b:3f45ea56:116ae55f] bios.jcommon.exception.BiosException: Unknown exception (bifoga alltid allt, hela stacktracen, från java-konsolen).
Beställningsförfrågan Om man är intresserad av eller har idéer kring utökad funktionalitet i en applikation är det viktigt att Digpro får en så djup förståelse som möjligt kring själva behovet. Digpros applikationer har ett stort bibliotek av funktioner vilket gör att det ibland kan vara så att den funktion som efterfrågas redan finns inkluderad. Även i annat fall fyller det också en stor funktion att Digpros personal har djup kännedom kring grundbehovet eftersom det gör det betydligt enklare att gemensamt diskutera sig fram till en lösning som är både framtidssäkrad och robust rent tekniskt.
En beställningsförfrågan bör vara uppbyggd kring tre huvudpunkter: Gör, Händer och Förfrågan.
● Under rubriken Gör definierar man tydligt vad man gör i anslutning till det att problemet/önskemålet uppkommer. Det kan t.ex. handla om att man letar efter en viss typ av information i ett formulär eller att man panorerar i en kartprodukt. Informationen kan, men behöver inte nödvändigtvis vara återgiven i en numrerad lista.
● Under rubriken Händer beskriver man problemet man har i anslutning till det som återges under rubriken Gör. Det kan t.ex. handla om att man anser att informationen i ett formulär är onödigt svår att tillgå eller att en kartprodukt uppfattas som plottrig.
● Under Förfrågan beskriver man själv hur man skulle vilja att applikationen såg ut eller betedde sig i anslutning till rubriken Gör.
Det kan även här, precis som vid buggrapportering, vara bra att lägga till en rubrik Övrigt där man delger övrig information som man tror eller anser är viktig för Digpro.
10
Exempel beställningsförfrågan Nedan följer ett exempel på hur en väldefinierad beställningsförfrågan kan se ut. I det här fallet är man intresserade av att se olika uppdragssymboler beroende på vilken applikation ett uppdrag är skapat i.
Gör:
1. Startar dpPower - Demo energi AB 8.2 2. Visar sidomeny, öppnar flik karta, öppnar kartprodukt Samlingskarta 3. Öppnar huvudmeny, Fönster -> Flytta vy till koordinater 4. Fyller i
X (N): 659 3000 Y (E): 672 000 Skala: 5 000
Händer:
Landar i en punkt i kartan (Täby) där många olika uppdragssymboler är utplacerade. Problemet är bara att alla har samma symbol och att det är svårt att skilja uppdragen åt.
Förfrågan:
Vi vill framför allt skilja på uppdrag beroende på vilken applikation de är skapade i, alltså beroende på om de skapats i dpCom eller dpPower. En idé skulle t.ex. kunna vara att dpCom-uppdrag symboliseras av en fiber och dpPower av en blixt.
Vi är i första läget intresserade av en tidsuppskattning så bestämmer vi efter det hur vi ska gå vidare.
Hantering av ärenden Första steget när ett ärende tas emot är att Digpros personal läser igenom informationen i sin helhet och sedan ger en första återkoppling till den som skapat ärendet. Det kan handla om att information saknas och att följdfrågor därmed behöver ställas eller helt enkelt att ärendet mottagits och väntar på att resurssättas. Beroende på hur ärendet klassificerats under fälten Severity och Priority samt vad som står under Description avgör Digpro hur ärendet ska prioriteras. Ärenden som anses akuta och har stor påverkan på verksamheten prioriteras av naturliga skäl högre än ärenden med lägre grad av påverkan.
Om ett ärende inte är så pass akut att det måste hanteras direkt kommer Digpros personal först och främst se till att det är tydligt definierat precis vad som ska göras och efter det lägga till ärendet i en intern kö. Att ärendet ställts i kö kan man se på fältet Keyword. Ärenden som uppskattas ta mindre än 4 timmar att slutföra taggas av Digpro med keywordet grab-me. Ärenden som uppskattas ta mer än 4 timmar taggas med
11
keywordet listed-gis samtidigt som ett ärende skapas i Digpros interna ärendehanteringssystem.
I ett ärende har man i stort sett samma möjligheter att i efterhand lägga till information som man har när man först skapar ärendet. Ser man t.ex. att man råkat fylla i fel information i ett visst fält är det med andra ord inget problem att rätta till det i efterhand.
Utöver de fält som specificerats under kapitlet Skapa ett ärende är det egentligen bara ytterligare två man som Support-bugzilla-användare behöver ha kännedom kring:
12
1. Till höger om fältet Modified finns en länk, History. Under den kan man själv se när och hur ärendet i fråga har hanterats.
2. Under fältet Status definieras vilken status ett ärende har för närvarande. Fältet har följande valbara alternativ: UNCONFIRMED NEW IN_PROGRESS FOR_CUSTOMER_FEEDBACK RESOLVED VERIFIED CLOSED
UNCONFIRMED - Är den initiala statusen för ett ärende innan det har tagits emot av Digpros supportavdelning.
NEW - Ett ärende har statusen NEW under tiden det genomgår en initial hantering och är kölagt.
IN_PROGRESS - När ett ärende aktivt hanteras av Digpro har det statusen IN_PROGRESS.
FOR_CUSTOMER_FEEDBACK - När Digpro har ställt en fråga till personen som skapat ärendet, sätts statusen till FOR_CUSTOMER_FEEDBACK. När man svarat på eventuella frågor kan man sätta tillbaka ärendet till samma status det hade innan det som stod som FOR_CUSTOMER_FEEDBACK. I regel antingen NEW eller IN_PROGRESS.
RESOLVED - Under tiden mellan det att Digpro anser att de har löst ett ärende men man som kund inte haft möjlighet att verifiera det i sitt eget system (t.ex. p.g.a. att man först måste uppgradera till en ny version av applikationen) ska ärendet ha statusen RESOLVED.
VERIFIED - När man som kund verifierat att en lösning fungerar i sitt system sätts statusen till VERIFIED.
CLOSED - Sista anhalt efter att en lösning verifierats är att ärendet stängs av Digpros personal genom att statusen sätts till CLOSED. Man kan endast sätta statusen CLOSED om ärendet tidigare är antingen i status RESOLVED eller VERIFIED.
13
Övrigt Nedan följer en kortare beskrivning av övriga delar som kan vara bra att känna till när man skapar ett ärende i Support-Bugzilla.
Visa java-konsolen i Windows 10 För att kunna läsa och bifoga så kallade stacktraces (felrapporter som ibland kan genereras av buggar i applikationerna) behöver man först slå på den så kallade java-konsolen. För att automatiskt få upp java-konsolen när man startar applikationen i Windows 10 kan man:
1. Öppna Start-menyn och skriv Kontrollpanelen 2. I sök-rutan, högst upp till höger i det nya fönstret, skriv Java och klicka på
ikonen med kaffekoppen som visas 3. I det nya fönstret, Java Kontrollpanel, öppna fliken Avancerat 4. Under rubriken java-konsol, välj Visa konsol 5. Klicka på OK
Bifoga stacktrace från java-konsolen Stacktracen som i vissa fall genereras av buggar i applikationen innehåller värdefull information som kan användas för att Digpro snabbare ska kunna hitta och implementera lösningar på de problem som rapporterats. När man bifogar en stacktrace är det viktigt att man bifogar allt som visades i java-konsolen efter att man utfört det sista steget under Gör: i buggrapporten. Stacktracen börjar med en tidsstämpel och på så sätt är det lätt att förstå varifrån felet härstammar.
14
Exempel på stacktrace kan ses nedan:
2018-01-23 09:13:04 [ee4546be:b8584049:7160ea79:da85b79b] java.lang.NullPointerException
at sys.insp.jcommon.plans.PlanContent.getLastInspection(PlanContent.java:46) at sys.insp.plugin.qt.view.InspPlanTemplatePanel.<init>(InspPlanTemplatePanel.java:70) at sys.insp.plugin.qt.view.InspPlanTemplateView.<init>(InspPlanTemplateView.java:29) at
sys.insp.plugin.qt.factory.InspPlanTemplateViewFactory.getInspPlanTemplateView(InspPlanTemplateViewFactory.java:96) at sys.insp.plugin.qt.factory.InspPlanTemplateViewFactory.build(InspPlanTemplateViewFactory.java:24) at bios.plugin.qt.factory.QtViewManager.createQtView(QtViewManager.java:580) at sys.insp.plugin.qt.factory.InspPlanTreeTableFactory$2.doCall(InspPlanTreeTableFactory.java:280) at bios.plugin.ClientAsynchVoidCall.call(ClientAsynchVoidCall.java:37) at bios.plugin.ClientAsynchVoidCall.call(ClientAsynchVoidCall.java:11) at bios.jcommon.AsynchCallService.lambda$submit$1(AsynchCallService.java:129) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source)