Manuscript Oprettelse af sag

For at oprette en sag i Manuscript klikker man på  / øverst i menuen til venstre på siden.
En tom sags formular vises, og man kan her indtaste oplysninger om den fundne/opdagede fejl , forespørgsel mv.

Er der behov for eskalering af en sag, eller er sagen Kritisk: kontakt Systemforvaltning (tlf. 72 18 30 05)

Ved oprettelse af en sag er det vigtigt, at man gør sig umage med at indberette så præcist som muligt:

Beskrivelse af påkrævet information ved oprettelse af en Manuscript sag

Generelt

  • Inden sagen sendes, så spørg sidemanden, om han har kendskab til, at fejlen allerede er meldt.

  • Inden sagen sendes, og hvis det er et forretningsmæssigt spørgsmål/fejlmelding, så spørg sidemanden, om han kan afklare forretningsreglen.

  • Jo mere information, jo bedre.

  • Kun én fejlmelding i hver sag.

  • Undlad at ”råbe” i sagen (dvs. skrive med store bogstaver eller mange udråbstegn). Sagen løses ikke hurtigere af den grund.  

  • Er der behov for eskalering, så kontakt STAR Systemforvaltning på telefon 72 18 30 05.

Title

Kort og præcis beskrivelse af hvad sagen omhandler

Project

Produktion (dog ikke fejl som er fundet i forbindelse med udvikling og test af release)
201x-x (den release sagen vedrører / fejlen er fundet i)
Systemforvaltning
Dagpengetællertest
Tællervalidering dagpenge
DSDW & Jobindsats
Backlog projekter: (BI/Backend, DFDG, JCP, JobAG, JobKon, Jobnet)
Vitas 

Produktionsrelaterede sager
Test/Udviklingsrelaterede sager
Driftsrelaterede sager (certifikater, brugeroprettelser, osv.)
Sager relateret til Dagpengetællertest
Sager relateret til Dagpengetæller validering
Sager relateret til DSDW & Jobindsats
Udviklingsleverandørernes projekter til backlog sager
Sager relateret til Vitas

Priority

(til venstre for beskrivelsesfeltet)

Korrekt prioritering udfyldes jf. beskrivelse af prioriteterne

NB vedr. K1 - Kritiske sager

  • Der skal angives en begrundelse for, hvorfor det er en K1 sag, dvs. hvad fejlen blokerer, og hvad fejlen har af konsekvenser i praksis. Dette gælder både for nye sager og ved opprioritering af en eksisterende sag.

  • Hvorfor er sagen evt. en Patchkandidat

  • Hvis der er en workaround, skal sagen nedprioriteres til K2 (det kan dog være nødvendigt, at DFDG hjælper med at undersøge dette)

Area

Vælg relevant area

I 201x-x projekterne angives ISB/Epic, hvis fejlen/forespørgslen er relateret til en ISB/Epic på pågældende releasetest ellers Produktionsfejl eller øvrige områder.

Milestone

Skal sættes når udvikler committer koderettelse af en Bug til release i testmiljøerne. 
Her vælges den milestone der angiver hvornår der committes.
Når en ny sag oprettes skal dette felt stå til ”Any Release”
Milestone "Backlog" sættes på sager der lægges i backlog.

Category

Bug (Fejl) , Inquiry (Forespørgsler), Feature (ny funktionalitet), Schedule Item (Planlagte opgaver, tilbagevendende bestillingsopgaver)

Assigned to

Nye sager skal altid assignes til  Systemforvaltning (SF). Undtaget er sager, der oprettes til behandling internt i egen organisation/team.

Systemforvaltning (SF) visiterer og løser sagerne, eller sørger for at de kommer videre til det rigtige team til analyse og løsning. Husk altid at assigne en sag videre når du har besvaret den.

Assign så vidt muligt til SPOC/Team brugere, når der assignes mellem teams, og notificer evt. derudover personer.

Status

Står som Active når en ny sag oprettes.

Identification

Hvis der er behov for at angive personhenførbare data i en sag, skal de altid angives i dette felt. Det kan f.eks. være  CV nummer, CPR nummer. Alle personhenførbare data skal angives i dette felt, og må ikke indsættes i descriptionfeltet.

Logs, Requests og responses som indeholder vedhæftes sagen som attachment (må ikke indsættes direkte i beskrivelsesfeltet). 

Environment

Her angives hvilket testmiljø sagen vedrører (PreProd, T1, T2...)

System

Hvis muligt - angiv hvilket system sagen vedrører

Beskrivelse

En trin for trin beskrivelse af fejlen, og hvordan den genskabes.

Ved fejl i brugergrænseflade, skal der angives:

  • Den tilstand borgeren var i da fejlen opstod 

  • Anvendte testkritierier

  • Hvis der kommer en fejlmeddelelse i et klientsystem, skal denne inkluderes

  • Screendump

  • Det anvendte Certifikats RID

  • Tidspunkt hvor fejlen opstod

Hvis det er en service, der fejlmeldes, skal der angives:

  •   Navn på servicen.

  •   Version af servicen.

  •   Det fejlende request og response (vedhæftet - må ikke indsættes direkte i Descriptionfeltet, grundet persondata).

  •   Forventet response

Husk at vedhæfte dokumentation:

  •   Hvis der kommer en fejlmeddelelse i et klientsystem, skal denne inkluderes 

  •   Screendump

  •   request og response vedhæftes som fil

  •   Certifikat RID/FID

  •   Ved udredning af specifik hændelse - angiv GUID/messageidentifier, tidspunkt for hændelsen. Bemærk! Der må ikke angives personhenførbare data i dette felt. Brug feltet Identification eller vedhæft som fil.

  •   Et så eksakt tidspunkt som muligt for hvornår et request er fejlet, da vi skal bruge det når vi leder i logfilerne.

Relaterede sager

I description feltet: skriv case xxxxx, så oprettes et link til den relaterede sag. 
(xxxxx=sagsnummer)

NB! Log, kode og dataudtræk, reuquest/response skal altid vedhæftes som filer i Manuscript – må ikke indsættes direkte i Descriptionfeltet, grundet persondata