Menu

Kom godt i gang med hændelsessporing og styring i softwaretest (inkluderet eksempler på skabeloner)

getting started with incident tracking

Prøv Vores Instrument Til At Fjerne Problemer

I dagens artikel vil vi lære alt om 'Incident Tracking and Management' Process - Sådan spores og håndteres hændelser i softwaretest med eksempler på skabeloner.

Tænker du - “STH har offentliggjort meget indhold på defekt / bugsporing , så hvordan vil dette være anderledes ”? Det er netop grunden til, at vi først skal se på, hvad vi mener med hændelse.

hændelsessporing og styring

Hvad du lærer:

Hvad er hændelse?

Hændelser kan defineres i enkle ord som en begivenhed, der opstår under test, der kræver gennemgang.

Under test, om det faktiske resultat varierer fra det forventede resultat, kaldes det bug, defekt, fejl, problem, fejl eller en hændelse. Ofte er alle disse udtryk synonyme.

Hændelser er dog en speciel kategori af problemer, der kan forekomme på grund af forkert konfiguration, beskadigede data eller servernedbrud osv. Eksempler er: Diskpladser fulde, fejl i udførelse (Runtime Error), service utilgængelig osv.

Hændelser kan også forekomme på grund af nogle problemer i softwareudvikling, hardwarebrug eller serviceanmodningsfejl.

Forskel mellem fejl, fejl, fejl og hændelser:

  1. Fejl : En handling udført af mennesker, der resulterer i uventet systemadfærd.
    g .; forkert syntaks, forkert beregning af værdier, misforståelse af software
    krav mv.
  2. Defekt: Dette er et udtryk, der normalt bruges af testere. Når testeren finder en fejl eller et problem, kaldes det defekt.
  3. Insekt: Bug er udviklerens terminologi. Når en fejl fundet af en tester er accepteret af udvikleren, kaldes det en fejl. Processen med at rette op på alle fejl i systemet kaldes bug-fixing.
  4. Utilsigtet hændelse: Hændelse er en uplanlagt afbrydelse. Når den operationelle status for enhver aktivitet bliver fra at fungere til mislykket og får systemet til at opføre sig på en ikke-planlagt måde, er det en hændelse. Et problem kan forårsage mere end én hændelse, der skal løses, helst så hurtigt som muligt.

Lad os nu se på et par relaterede udtryk:

  1. Incident Repository : Incident Repository kan defineres som en database, der indeholder alle de vigtige og relevante data om alle hændelser, der opstår i systemet. Disse oplysninger bruges efterfølgende til at oprette hændelsesrapporten. Den indeholder felter som data, forventede resultater, faktiske resultat, dato og tid, hændelsesstatus osv.
  2. Alvorlighed: Den potentielle indvirkning af hændelsen vil afgøre deres sværhedsgrad. Det kan være større, mindre, dødelig eller kritisk til øjeblikkelig opløsning.
  3. Prioritet : Indstilles efter sværhedsgrad og indflydelse på systemets funktionsstatus. Værdierne kan være høje, mellemstore, lave, meget høje eller presserende / øjeblikkelige.
  4. Hændelsesstatus : Den aktuelle tilstand, hvor håndteringen af ​​hændelsen er. Det kan være nyt, i gang, løst og lukket.

Hvad er Incident Management?

Incident management er en proces til at logge, registrere og løse hændelserne så hurtigt som muligt for at gendanne forretningsprocessen eller tjenesten tilbage til normal.

Incident Management Process

Incident management er den overordnede proces, der starter fra logning af hændelser til løsning af dem.

Det er en meget kritisk proces, da dette vil sikre, at hændelserne bliver løst, er en systematisk og effektiv måde. Ved at strømline hele processen er der også en god chance for, at tidlig løsning af problemerne kan ske.

Det følgende er en skematisk gengivelse af processen, og vi vil diskutere hvert trin i detaljer derefter.

Incident management Process

type test i software engineering

# 1. Hændelsesidentifikation og logning :
Hændelsesidentifikation udføres enten via test (ved hjælp af værktøjer eller andet), brugerfeedback, infrastrukturovervågning osv.

At logge en hændelse betyder simpelthen at registrere følgende info:

  • Præcis / passende dato og tidspunkt for forekomst.
  • Hændelsestitel sammen med type og kort beskrivelse
  • Navn på den person, der loggede hændelsen og en mere detaljeret beskrivelse
    med fejlkoder, når det er relevant
  • Detaljer om den person, der er tildelt hændelsen til opfølgning
  • Hændelsens aktuelle status
  • Vedhæftede filer inklusive tekniske diskussioner, beslutninger og godkendelser

# 2. Klassificering og prioritering:

Klassificering af hændelser hjælper os med at opdele dem ud fra deres type (software, hardware, serviceanmodning osv.), Så det gør det nemmere at rapportere og analysere. Prioritering hjælper med at identificere rækkefølgen / prioriteten af ​​de hændelser, der skal håndteres. Det afhænger af virkningen, sværhedsgraden og vigtigst af risikofaktoren.

# 3. Undersøgelse og analyse: Dette trin er at forstå problemet bedre, så vi løser ikke kun det lige nu, men indsamler oplysninger for at forhindre gentagelse.

# 4. Opløsning og gendannelse: Der tages skridt til at fjerne hændelsen og bringe systemet tilbage til dets tidligere driftstilstand.

# 5. Lukning af hændelse: Opløsningen testes igen, og hvis systemet fungerer efter hensigten, er hændelsen lukket.

Incident Management System

Hændelsesstyring kan meget vel udføres manuelt eller statisk ved hjælp af regneark, men det er meget mere effektivt, dynamisk og systematisk, når det gøres via et værktøj.

Et hændelsesstyringssystem bruges af mange kundesupportcentraler til at oprette opdatering og løse hændelser.

Populære hændelsesstyringsværktøjer:

Nogle populære hændelsesstyringsværktøjer, der kan bruges til at spore hændelser ud over fejl eller mangler er:

# 1. Sidde! (Support Incident Tracking):

Incident tracking tool 1

  • Support Incident Tracker (SiT) er en gratis open source- og webbaseret applikation, der bruger PHP og MySQL til og understøtter alle platforme. Det er også almindeligt kendt som en 'Help Desk' eller 'Support Ticket System'.
  • Nyttigt at sende e-mails direkte fra SiT, vedhæfte filer og registrere enhver kommunikation i hændelsesloggen. SiT er opmærksom på serviceniveauaftaler, og hændelser markeres, hvis de ligger uden for dem.

# 2. JIRA:

Incident tracking tool 2
JIRA er også et populært proprietært hændelsesstyringsværktøj udviklet af Atlassian, der bruges til sporing af fejl, mangler eller hændelser. Det er et Java-baseret værktøj, der bruges til software og mobile apps. JIRA-ordningen involverer arbejdsgange, tilladelser, konfigurationer, problemtyper osv. JIRA understøtter også agil test.

For mere information og vejledning, se: JIRA tutorials-serie.

# 3. Incident Tracking System:
Incident tracking system er software, der bruges til at spore hændelser. Det hjælper med at bestemme og analysere årsagen til hændelsen sammen med en passende løsning. Incident Tracking System er let at bruge og giver databasesupport til sporing og registrering af hændelsen.

Test hændelsesrapport:

  1. Testhændelsesrapport er en post oprettet i defektlager med unikt ID for hver hændelse, der opstår. Testhændelsesrapporten dokumenterer alle problemer, der er fundet i de forskellige testfaser.
  2. IEEE 829-1998 er standardformatet til testhændelsesrapport, der bruges til at dokumentere hver hændelse, der opstår under test.

Oversigt over IEEE 829-1998 skabelon er angivet nedenfor:

=> Download IEEE Incident Tracking Template her.

Følgende er en kort forklaring af felterne:

# 1. Identificere : Angiver ID, der er unikt og virksomhedsgenereret nummer til identifikation og lokalisering af en hændelse.

# 2. Resumé : Opsummerer hændelsen på en kortfattet måde. Indeholder tilstrækkelige detaljer til at forstå relaterede fakta, dvs. referencer, tilknyttede testprocedurer, version af softwaren, testcases osv.

# 3. Hændelsesbeskrivelse: Beskriver hændelse med følgende detaljer: Input

  • forventet resultat
  • Faktisk resultat
  • Forsøg på at gentage
  • Anomalier
  • Dato og tid
  • Fremgangsmåde Trin
  • Testers navn

Rapportformat for hændelsessporing kan ændres i henhold til branchestandarder og forretningskrav.

Et eksempel på en anvendt i et firma er:

=> Download den ændrede hændelsesrapportskabelon her.

Konklusion:

Da denne artikel viser, er hændelsesadministration ikke meget forskellig fra fejlsporing, så dette vil være en vidunderlig opsummering af processen med nogle ISO-standard og praktiske skabeloner fra det virkelige liv.

Et andet ord med forsigtighed, som vi vil efterlade jer alle med, før vi slutter denne artikel, er at - prøv ikke at være for knyttet til definitionen af ​​bug / defect / incident osv., Fordi de fleste virksomheder ikke skelner mellem det ene udtryk og det andet. Så alle bruges synonymt for størstedelen af ​​tiden - også der er nogle virksomheder, der kalder deres dokumentation for uoverensstemmelse som hændelser, andre opkaldsmiljøproblemer som hændelser - så du kan se, da dialekterne ændrer sig med regioner, så gør teknisk QA det også terminologi. Det, vi bringer dig, er flertallet, ikke altid findes der normale undtagelser.

God læselyst!

Anbefalet læsning

^