Meny

Komma igång med incidentspårning och hantering i programvarutestning (exempelmallar ingår)

  • Huvud
  • Bug Defect Tracking
  • Komma igång med incidentspårning och hantering i programvarutestning (exempelmallar ingår)

getting started with incident tracking

Prova Vårt Instrument För Att Eliminera Problem

I dagens artikel kommer vi att lära oss allt om “Incident Tracking and Management” Process - Hur man spårar och hanterar incidenter i programvarutestning med exempelmallar.

Tänker du - ”STH har publicerat mycket innehåll på fel / spårning av fel , så hur kommer det att bli annorlunda ”? Det är precis anledningen till att vi först måste titta på vad vi menar med incident.

incidentspårning och hantering

Vad du kommer att lära dig:

Vad är incident?

Incidenter kan definieras med enkla ord som en händelse som påträffas under testning som kräver granskning.

Vid testning om det faktiska resultatet varierar från förväntat resultat kallas det fel, fel, fel, problem, fel eller en incident. Oftast är alla dessa termer synonyma.

Incidenter är emellertid en speciell kategori av problem som kan uppstå på grund av felkonfiguration, skadad data eller serverkrasch etc. Exempel är: Diskutrymmen fullt, fel vid körning (Runtime Error), tjänst otillgänglig etc.

Incidenter kan också inträffa på grund av vissa problem i mjukvaruutveckling, hårdvaruanvändning eller serviceförfrågan.

Skillnad mellan fel, fel, fel och incidenter:

  1. Fel : En åtgärd utförd av människor som resulterar i oväntat systembeteende.
    g .; felaktig syntax, felaktig beräkning av värden, missförstånd av programvara
    krav etc.
  2. Defekt: Detta är en term som vanligtvis används av testare. När testaren hittar ett misstag eller problem kallas det Defekt.
  3. Insekt: Bug är utvecklarens terminologi. När en defekt som hittats av en testare accepterats av utvecklaren kallas den för ett fel. Processen för att rätta till alla buggar i systemet kallas bug-fixing.
  4. Incident: Incident är ett oplanerat avbrott. När den operativa statusen för någon aktivitet går från att fungera till misslyckades och får systemet att bete sig oplanerat är det en händelse. Ett problem kan orsaka mer än en incident som ska lösas, helst så snart som möjligt.

Låt oss nu titta på några relaterade termer:

  1. Incident Repository : Incident Repository kan definieras som en databas som innehåller all viktig och relevant information om alla incidenter som inträffar i systemet. Denna information används sedan för att skapa incidentrapporten. Den innehåller fält som data, förväntade resultat, faktiskt resultat, datum och tid, händelsestatus etc.
  2. Allvarlighetsgrad: Händelsens potentiella påverkan avgör hur allvarlig den är. Det kan vara Major, Minor, Fatal eller Critical för omedelbar upplösning.
  3. Prioritet : Ställ in efter svårighetsgrad och påverkan på systemets arbetsstatus. Värdena kan vara höga, medelhöga, låga, mycket höga eller brådskande / omedelbara.
  4. Incident Status : Det aktuella tillståndet där hanteringen av incidenten är. Det kan vara nytt, pågår, löst och stängt.

Vad är incidenthantering?

Incident management är en process för att logga, registrera och lösa incidenterna så snabbt som möjligt för att återställa affärsprocessen eller tjänsten till det normala.

bästa spelutvecklingsprogramvaran för nybörjare

Incident Management Process

Incident management är den övergripande processen från loggning av incidenter till lösning av dem.

Det är en mycket kritisk process eftersom detta kommer att säkerställa att incidenterna behandlas är ett systematiskt och effektivt sätt. Dessutom, genom att effektivisera hela processen, finns det goda chanser att tidig fixning av problemen kan hända.

Följande är en schematisk framställning av processen och vi kommer att diskutera varje steg i detalj nästa.

Process för incidenthantering

# 1. Incidentidentifiering och loggning :
Incident Identification görs antingen via testning (med hjälp av verktyg eller annat), användaråterkoppling, infrastrukturövervakning etc.

Att logga en incident innebär helt enkelt att registrera följande info:

  • Exakt / lämpligt datum och tid för förekomst.
  • Incidentens titel tillsammans med typ och kort beskrivning
  • Namnet på personen som loggade händelsen och mer detaljerad beskrivning
    med felkoder när det är tillämpligt
  • Detaljer om den person som tilldelats händelsen för uppföljning
  • Händelsens nuvarande status
  • Bilagor inklusive tekniska diskussioner, beslut och godkännanden

# 2. Klassificering och prioritering:

Klassificering av incidenter hjälper oss att dela dem baserat på deras typ (programvara, hårdvara, serviceförfrågan etc.) så att det blir enklare att rapportera och analysera. Prioritering hjälper till att identifiera ordning / prioritering av incidenter som ska hanteras. Det beror på påverkan, svårighetsgraden och framför allt riskfaktorn.

# 3. Undersökning och analys: Det här steget är att bättre förstå problemet så att vi inte bara fixar det just nu utan samlar information för att förhindra att det uppstår igen.

# 4. Upplösning och återställning: Åtgärder vidtas för att avlägsna händelsen och återföra systemet till dess tidigare arbetsförhållande.

# 5. Incident Stängning: Upplösningen testas om och om systemet fungerar som avsett är incidenten stängd.

Incident Management System

Incidenthantering kan mycket väl göras manuellt eller statiskt med hjälp av kalkylblad, men det är mycket mer effektivt, dynamiskt och systematiskt när det görs via ett verktyg.

Ett incidenthanteringssystem används av många kundsupportcentraler för att skapa uppdateringar och lösa incidenter.

Populära verktyg för incidenthantering:

Några populära incidenthanteringsverktyg som kan användas för att spåra incidenter utöver buggar eller defekter är:

# 1. Sitta! (Support Incident Tracking):

Incident tracking tool 1

  • Support Incident Tracker (SiT) är en gratis öppen källkod och webbaserad applikation som använder PHP och MySQL för och stöder alla plattformar. Det är också allmänt känt som ett 'Help Desk' eller 'Support Ticket System'.
  • Användbart för att skicka e-post direkt från SiT, bifoga filer och registrera varje kommunikation i incidentloggen. SiT är medveten om servicenivåavtal och incidenter flaggas om de ligger utanför dem.

# 2. JIRA:

Incident tracking tool 2
JIRA är också ett populärt proprietärt incidenthanteringsverktyg som utvecklats av Atlassian och används för spårning av fel, fel eller incident. Det är ett Java-baserat verktyg som används för programvara och mobilappar. JIRA-schemat involverar arbetsflöden, behörigheter, konfigurationer, problemtyper etc. JIRA stöder också smidig testning.

För mer information och handledning, se: JIRA-handledningsserie.

# 3. Incident Tracking System:
Incident tracking system är programvara som används för att spåra incidenter. Det hjälper till att bestämma och analysera grundorsaken till incidenten tillsammans med lämplig lösning. Incident Tracking System är enkelt att använda och ger databasstöd för spårning och inspelning av incidenten.

Testincidentrapport:

  1. Testincidentrapport är en post skapad i defektförvar med unikt ID för varje incident som påträffats. Testincidentrapporten dokumenterar alla problem som hittats under de olika testfaserna.
  2. IEEE 829-1998 är standardformatet för testincidentrapport som används för att dokumentera varje incident som inträffar under testningen.

Översikt över IEEE 829-1998-mall ges nedan:

=> Ladda ner IEEE Incident Tracking Template här.

Följande är en kort förklaring av fälten:

# 1. Identifiera : Anger ID som är unikt och företagsgenererat nummer för att identifiera och lokalisera en incident.

# 2. Sammanfattning : Sammanfattar händelsen på ett kortfattat sätt. Innehåller tillräckliga detaljer för att förstå relaterade fakta, dvs. referenser, tillhörande testförfaranden, version av programvaran, testfall etc.

# 3. Incidentbeskrivning: Beskriver incident med följande detaljer: Ingångar

  • Förväntat resultat
  • Faktiskt resultat
  • Försök att upprepa
  • Anomalier
  • Datum och tid
  • Procedursteg
  • Testarens namn

Incident Tracking-rapportformat kan ändras i enlighet med branschstandarder och affärskrav.

Ett exempel på en som används i ett företag är:

=> Ladda ner modifierad incidentrapportmall här.

Slutsats:

Eftersom den här artikeln visar att incidenthantering inte skiljer sig mycket från bug tracking, så kommer detta att bli en underbar sammanfattning av processen med några ISO-standard och praktiska mallar i verkliga livet bifogade.

Ett annat försiktighetsord som vi vill lämna er alla innan vi avslutar den här artikeln är att försök att inte vara för knuten till definitionen av bug / defect / incident etc, eftersom de flesta företag inte skiljer mellan en term till den andra. Så alla används synonymt under större delen av tiden - det finns också vissa företag som kallar deras dokumentation inkonsekvenser som incidenter, andra samtalsmiljöfrågor som incidenter - så du ser, när dialekterna förändras med regioner, så gör teknisk QA terminologi. Det vi tar med dig är majoriteten, inte normundantagen finns alltid.

Glad läsning!

Rekommenderad läsning

^