Skriv testfall för systemintegrationen med verksamhetens egna exempel

Välj ett resultat som går att se

Börja med en liten del av flödet. Beskriv vad mottagaren ska kunna se eller göra efter att uppgiften har skickats vidare. Undvik att skriva att hela integrationen ska fungera; välj ett resultat som går att kontrollera utan att gissa vad ordet fungerar betyder.

Ett konstruerat exempel är att en nyregistrerad förfrågan ska finnas hos mottagaren med rätt referens och angiven status. Förklara var resultatet ska synas och vem som kan avgöra om innehållet stämmer. Exemplet beskriver en metod för granskning, inte en befintlig funktion hos en viss produkt.

Skriv ned startläget före kontrollen

Anteckna vilka uppgifter som redan finns och vilken version av flödet som ska prövas. Beskriv om mottagande system ska innehålla en motsvarande post från början eller om den ska saknas. Det hjälper er att skilja en ny överföring från gammal information som redan låg där.

Bestäm vilka exempel ni får använda och vilken miljö som är avsedd för kontrollen. Använd godkänt testunderlag. Om ett steg kan skapa en verklig beställning, ett mejl eller någon annan extern åtgärd behöver ansvariga först bestämma hur testet ska avgränsas.

Kopiera den här mallen för varje testfall

Fyll i ett kort som går att läsa fristående:

• Testfallets namn och vilket behov det gäller.
• Startläge i avsändande och mottagande system.
• Underlag eller exempel som ska användas.
• Händelsen som sätter i gång flödet.
• Förväntat resultat och var det kontrolleras.
• Vad som inte ska skapas eller ändras.
• Vem som utför kontrollen och bedömer svaret.
• Observerat resultat, datum och nästa steg.

Låt förväntat resultat stå kvar när ni dokumenterar utfallet. Annars blir det svårt att se om det som hände motsvarade planen eller om planen skrevs om efteråt.

Ta med ett exempel som inte går raka vägen

Välj ett känt undantag ur verksamhetens arbete. Det kan vara att en nödvändig referens saknas eller att uppgiften redan finns hos mottagaren. Be ansvarig utvecklare förklara vilken hantering lösningen är tänkt att ha och skriv hur ni kan observera den.

Utgå från undantagslistan inför automatisering. Om det saknas ett beslut om vad som ska hända är det en öppen verksamhetsfråga. Markera den som sådan, i stället för att låta den som kör kontrollen hitta på det förväntade beteendet.

Spara vad ni faktiskt observerade

Skriv vilket testfall som kördes, när det gjordes och vilket resultat som visades. Spara en relevant hänvisning som de ansvariga får ta del av. Skilj observationen från din tolkning av orsaken: att en uppgift saknas är en observation, medan förklaringen kan behöva undersökas.

Om ord eller statusvärden är oklara, gå tillbaka till den gemensamma ordlistan. Förtydliga betydelsen innan testfallet bedöms igen. Ändras själva förväntningen ska både den nya formuleringen och skälet till ändringen gå att följa.

Bestäm vad som behövs för nästa beslut

Sammanställ vilka fall som motsvarade förväntningarna, vilka som avvek och vilka som ännu inte kunde köras. Låt ansvariga avgöra vilka frågor som måste besvaras innan nästa steg. Ett godkänt exempel är ett underlag i bedömningen; det säger inte att alla tänkbara situationer är täckta.

Börja med AI-kartan om ni först behöver beskriva arbetsflödet och dess praktiska behov. Ta sedan med testfallen till dialogen om lösningen. AI-assisterad originalguide med en redaktionell arbetsmall; inga testresultat, leveranstider eller effekter för ett verkligt kundprojekt påstås.