getting started with incident tracking
I dagens artikkel skal vi lære alt om “Incident Tracking and Management” Prosess - Hvordan spore og administrere hendelser i programvaretesting med eksempler på maler.
Tenker du - “STH har publisert mye innhold på feil / sporing av feil , så hvordan skal dette være annerledes ”? Det er akkurat grunnen til at vi først må se på hva vi mener med hendelsen.
Hva du vil lære:
- Hva er hendelse?
- Forskjellen mellom feil, feil, feil og hendelser:
- Hendelsesprosess
- Incident Management System
- Testhendelsesrapport:
- Konklusjon:
- Anbefalt lesing
Hva er hendelse?
Hendelser kan defineres med enkle ord som en hendelse som oppstod under testing som krever gjennomgang.
Mens du tester om det faktiske resultatet varierer fra forventet resultat, blir det referert til som feil, feil, feil, problem, feil eller en hendelse. Ofte er alle disse begrepene synonyme.
Hendelser er imidlertid en spesiell kategori av problemer som kan oppstå på grunn av feilkonfigurasjon, ødelagte data eller serverkrasj etc. Eksempler er: Diskplassene er fulle, feil i kjøring (Runtime Error), tjenesten utilgjengelig osv.
Hendelser kan også oppstå på grunn av noen problemer i programvareutvikling, maskinvarebruk eller serviceforespørselsfeil.
hva er de forskjellige typene testing
Forskjellen mellom feil, feil, feil og hendelser:
- Feil : En handling utført av mennesker som resulterer i uventet systematferd.
g .; feil syntaks, feil beregning av verdier, misforståelse av programvare
krav mv. - Defekt: Dette er et begrep som vanligvis brukes av testere. Når testeren finner en feil eller et problem, blir det referert til som Defekt.
- Feil: Bug er utviklerens terminologi. Når en feil funnet av en tester er akseptert av utvikleren, kalles det en feil. Prosessen med å rette opp alle feil i systemet kalles bug-fixing.
- Hendelse: Hendelsen er et uplanlagt avbrudd. Når den operative statusen til en aktivitet går fra å fungere til å mislykkes og får systemet til å oppføre seg på en ikke-planlagt måte, er det en hendelse. Et problem kan føre til mer enn én hendelse som skal løses, helst så snart som mulig.
La oss nå se på noen relaterte termer:
- Incident Repository : Incident Repository kan defineres som en database som inneholder alle viktige og relevante data om alle hendelser som oppstår i systemet. Denne informasjonen blir deretter brukt til å lage hendelsesrapporten. Den inneholder felt som data, forventede resultater, faktisk resultat, dato og klokkeslett, status for hendelsen etc.
- Alvorlighetsgrad: Den potensielle innvirkningen av hendelsen vil avgjøre alvorlighetsgraden. Det kan være stort, mindre, dødelig eller kritisk for umiddelbar oppløsning.
- Prioritet : Still inn i henhold til alvorlighetsgrad og innflytelse på systemets arbeidsstatus. Verdiene kan være høye, middels, lave, veldig høye eller haster / øyeblikkelig.
- Hendelsesstatus : Den nåværende tilstanden hvor håndteringen av hendelsen er. Det kan være nytt, pågår, løst og lukket.
Hva er Incident Management?
Hendelsesadministrasjon er en prosess for å logge, registrere og løse hendelsene så raskt som mulig for å gjenopprette forretningsprosessen eller tjenesten tilbake til det normale.
Hendelsesprosess
Hendelsesadministrasjon er den overordnede prosessen fra logging av hendelser til løsning av dem.
Det er en veldig kritisk prosess, da dette vil sikre at hendelsene blir adressert er en systematisk og effektiv måte. Ved å effektivisere hele prosessen er det også en god sjanse for at tidlig løsning av problemene kan skje.
Følgende er en skjematisk fremstilling av prosessen, og vi vil diskutere hvert trinn i detalj neste.
#1. Hendelsesidentifikasjon og logging :
Hendelsesidentifisering gjøres enten via testing (ved hjelp av verktøy eller annet), tilbakemeldinger fra brukerne, overvåking av infrastruktur, etc.
Å logge en hendelse betyr ganske enkelt å registrere følgende info:
- Nøyaktig / passende dato og tidspunkt for forekomst.
- Hendelsestittel sammen med type og kort beskrivelse
- Navnet på personen som loggførte hendelsen og mer detaljert beskrivelse
med feilkoder når det er aktuelt - Detaljer om personen som er tilordnet hendelsen for oppfølging
- Gjeldende status for hendelsen
- Vedlegg inkludert tekniske diskusjoner, beslutninger og godkjenninger
# 2. Klassifisering og prioritering:
Klassifisering av hendelser hjelper oss med å dele dem basert på deres type (programvare, maskinvare, tjenesteforespørsel, etc.), slik at det blir enklere å rapportere og analysere. Prioritering hjelper til med å identifisere rekkefølgen / prioriteten til hendelser som skal håndteres. Det avhenger av påvirkning, alvorlighetsgrad og viktigst av risikofaktoren.
# 3. Undersøkelse og analyse: Dette trinnet er å bedre forstå problemet, så vi løser ikke bare det akkurat nå, men samler informasjon for å forhindre at det oppstår igjen.
# 4. Løsning og gjenoppretting: Det tas skritt for å fjerne hendelsen og bringe systemet tilbake til dets tidligere arbeidstilstand.
# 5. Hendelseslukking: Oppløsningen testes på nytt, og i tilfelle systemet fungerer som forutsatt, er hendelsen lukket.
Incident Management System
Hendelsesadministrasjon kan godt gjøres manuelt eller statisk ved hjelp av regneark, men det er mye mer effektivt, dynamisk og systematisk når det gjøres via et verktøy.
Et hendelsesstyringssystem brukes av mange kundesupport-kundesentre for å lage oppdateringer og løse hendelser.
Populære verktøy for hendelsesadministrasjon:
Noen populære verktøy for hendelsesadministrasjon som kan brukes til å spore hendelser i tillegg til feil eller mangler er:
#1. SiT! (Support Incident Tracking):
- Support Incident Tracker (SiT) er en gratis åpen kildekode- og nettbasert applikasjon som bruker PHP og MySQL for og støtter alle plattformer. Det er også kjent som en 'Help Desk' eller 'Support Ticket System'.
- Nyttig å sende e-post direkte fra SiT, legge ved filer og registrere all kommunikasjon i hendelsesloggen. SiT er kjent med servicenivåavtaler, og hendelser blir markert hvis de ligger utenfor dem.
# 2. JIRA:
JIRA er også et populært proprietært verktøy for hendelsesadministrasjon utviklet av Atlassian brukt til bug, defect eller incident tracking. Det er et Java-basert verktøy som brukes til programvare og mobilapper. JIRA-ordningen innebærer arbeidsflyter, tillatelser, konfigurasjoner, problemtyper osv. JIRA støtter også smidig testing.
For mer informasjon og veiledning, vennligst sjekk: JIRA opplæringsserie.
# 3. Incident Tracking System:
Hendelsessporingssystem er programvare som brukes til å spore hendelser. Det hjelper til med å bestemme og analysere årsaken til hendelsen sammen med en passende løsning. Incident Tracking System er enkelt å bruke og gir databasestøtte for sporing og registrering av hendelsen.
Testhendelsesrapport:
- Testhendelsesrapport er en oppføring opprettet i defektregister med unik ID for hver hendelse som oppstår. Testhendelsesrapporten dokumenterer alle problemene som er funnet i de forskjellige testfasene.
- IEEE 829-1998 er standardformatet for testhendelsesrapport som brukes til å dokumentere hver hendelse som oppstår under testing.
Oversikten over IEEE 829-1998-malen er gitt nedenfor:
=> Last ned IEEE Incident Tracking Mal her.
Følgende er en kort forklaring av feltene:
#1. Identifisere : Spesifiserer ID som er unikt og firma generert nummer for å identifisere og lokalisere en hendelse.
# 2. Sammendrag : Oppsummerer hendelsen på en kortfattet måte. Inneholder tilstrekkelige detaljer for å forstå relaterte fakta, nemlig. referanser, tilhørende testprosedyrer, versjon av programvaren, testtilfeller etc.
# 3. Hendelsesbeskrivelse: Beskriver hendelse med følgende detaljer: Innganger
- forventet resultat
- Egentlige resultatet
- Forsøk på å gjenta
- Avvik
- Dato og tid
- Fremgangsmåte trinn
- Testers navn
Rapportformatet for hendelsessporing kan endres i henhold til bransjestandarder og forretningskrav.
Et eksempel på en som brukes i et selskap er:
=> Last ned den endrede malrapporten for hendelser her.
Konklusjon:
Siden denne artikkelen viser at hendelsesadministrasjon ikke er veldig forskjellig fra feilsporing, vil dette være en fantastisk oppsummering av prosessen med noen ISO-standard og praktiske virkelige maler vedlagt.
Et annet ord med forsiktighet som vi vil la dere alle være med før vi avslutter denne artikkelen er at - prøv å ikke være for knyttet til definisjonen av bug / defect / incident etc, fordi de fleste selskaper ikke skiller mellom det ene begrepet til det andre. Så alle brukes synonymt for det meste - også, det er noen selskaper som kaller dokumentasjonen deres uoverensstemmelser som hendelser, andre samtalemiljøproblemer som hendelser - så du ser, ettersom dialektene endres med regioner, det gjør også teknisk QA terminologi. Det vi bringer til deg er flertallet, ikke de normale unntakene eksisterer alltid.
Glad lesning!
Anbefalt lesing
- Beste verktøy for testing av programvare 2021 [QA Test Automation Tools]
- Programvaretesting QA Assistant Job
- Programvare Testing Course: Hvilket programvare Testing Institute skal jeg delta?
- Velge programvaretesting som din karriere
- Programvaretesting Teknisk innhold Writer Freelancer Jobb
- Noen interessante intervjusspørsmål om programvaretesting
- Programvaretestkurs Tilbakemelding og anmeldelser
- Programvaretesting Hjelp tilknyttet program!