Lämplighets- och kunskapsprov för testare

2003-12-01 Artikelbanken Test Läst 16820 gånger

Inledning

Det här lämplighets- och kunskapsprovet har tagits fram för att vara till hjälp vid rekrytering av testare, testledare och liknande. Det kan även användas vid utvärdering av konsulter inom testområdet. Provet är tänkt att utgöra ett komplement till andra intervjutekniker. Den ursprungliga versionen av provet är utvecklat av det brittiska företaget Grove Consultants och Ulf Eriksson vid Konsultbolag1 har ansvarat för översättning och anpassning till svenska förhållanden.

Provets struktur

Provet består av 25 frågor, där varje fråga kan ge ett visst antal poäng. Frågorna är skapade och utvalda för att testa en persons färdigheter inom ett så stort testområde som möjligt, med uppgifter som sträcker sig från scenariotester till specifika frågor om testverktyg.

Testet tar 90 minuter att genomföra. Om kandidaten drar över tiden, kan man tillämpa straffpoäng, t ex en straffpoäng per extra minut. Om kandidaten lämnar in svaren innan tiden är ute, kan bonuspoäng tillämpas.

Högsta möjliga poäng är 150. Du kan välja att tillämpa en procentsats för att bedöma kandidatens resultat. Ett exempel:

  • Mindre än 50 % rätt – Inte godkänd.
  • 50 % till 65 % – Junior testare/praktikant
  • 65 % till 80 % – Testare
  • Mer än 80 % – Senior testare

Eftersom alla frågor har fria svarsalternativ, har du som rekryterare ansvaret att tolka kandidatens svar och sätta de poäng som du tycker är lämpliga.

Tack till Grove Consultants för att vi har fått möjligheten att översätta och anpassa det engelska testet till svenska och våra förhållanden. Denna version är skapad i november 2006.

Provfrågor

Besvara frågorna på separat svarsblankett. Avsatt tid är 90 minuter.

Nr Fråga Max
poäng
1 Vilket av följande påstående anser du vara viktigast och varför?
  1. Det främsta syftet med test är att visa att systemet uppfyller användarnas önskemål
  2. Det främsta syftet med test är att hitta fel.
 2
2 Du har genomfört alla tester och alla fick godkänt resultat. Är det bra eller dåligt? 2
3 Vad skulle du göra om du ombads testa ett system som är obekant för dig och det visar sig att dokumentationen är bristfällig eller saknas? 4
4 När du utför ett testfall finner du att det verkliga resultatet inte överensstämmer med det förväntade resultatet. Vad gör du? 3
5 Vad av följande är viktigast? Motivera ditt svar.
  1. Positiva tester
  2. Negativa tester
  3. Extremtester som syftar till att försöka förstöra systemet
 2
6 Hur definierar du ett bra testfall? 2
7 Du har fått i uppgift att testa det nya triangelprogrammet (se skärmbild nedan).

Som du kan se, består programmet av tre inmatningsfält och en knapp. Tanken är att användaren anger ett heltal i vart och ett av de tre fälten. När man klickar på OK-knappen, ska programmet skriva ett meddelande i en separat dialogruta som säger om triangeln är oliksidig (alla sidor har olika längd), likbent (två sidor har samma längd) eller liksidig (alla tre sidorna är lika långa).

Skriv en uppsättning testfall (dvs specificera testdata) som enligt din uppfattning på ett adekvat sätt testar programmet. Skriv testerna så att någon annan än du själv kan utföra dem.

 17
8 När du testar ovanstående applikation, hittar du något som du tror är en avvikelse – i stället för att skriva ut meddelandet om vilken sorts triangel det är i en separat ruta, skriver applikationen meddelandet i utrymmet mellan de tre textfälten och OK-knappen. Vad gör du? Motivera.
  1. Fortsätter testa samtliga testfall och rapporterar sedan felet.
  2. Slutar testa, rapporterar felet omedelbart och fortsätter sedan med alternativa testfall.
  3. Slutar testa, rapporterar felet och avvaktar en korrigering.
  4. Fortsätter testa och rapporterar felet senare, tillsammans med fel som hittats när andra testfall har utförts.
 3
9 Du har skrivit en felrapport, men utvecklaren säger sig inte kunna reproducera felet. Vad gör du? Motivera svaret.
  1. Låter utvecklaren sätta felet som ej reproducerbart.
  2. Sätter själv felet som ej reproducerbart.
  3. Säger till utvecklaren att felet definitivt existerar och att du inte tänker godkänna det innan felet åtgärdas.
  4. Testar om felet, bekräftar att det existerar och kompletterar felrapporten till utvecklaren med information om detaljerade teststeg och eventuell ytterligare information.
 3
10 Scenario:
Du har två uppsättningar tester som ska utföras på den nya versionen av applikationen:

Uppsättning 1 – Regressionstestfall som syftar till att skapa förtroende för att applikationen inte är av sämre kvalitet än den förra versionen.
Uppsättning 2 – Testfall som testar ny funktionalitet.

När du utför regressionstestfallen upptäcker du ett antal fel. Vad gör du?		 6
11 Rita och beskriv V-modellen med dess 4 testnivåer. Beskriv var i modellen testplanering äger rum. 6
12 Beskriv de olika testnivåerna och vad som är målet med varje nivå. 10
13 Förklara betydelsen av termerna regressionstest och omtest. 4
14 Scenario:
Du har planerat att själv utföra 600 testfall. Varje testfall beräknas ta ungefär 10 minuter att utföra. Din chef säger nu att du måste slutföra testerna på en vecka. Vad gör du?		 5
15 Anser du att testverktyg är till nytta under testerna – varför eller varför inte? 4
16 Nämn tre kategorier av testverktyg och beskriv syftet med varje kategori. 9
17 Nämn två standarder inom testområdet. 2
18 Resonera kring hur du skulle gå tillväga för att testa följande tre krav?
  1. Systemet måste vara användarvänligt.
  2. Systemet måste vara enkelt att installera.
  3. Följande svarstider skall uppnås med det nya systemet:
    1. Det får inte ta mer än tre sekunder att starta webbapplikationen.
    2. Sökresultat ska visas efter högst fem sekunder.
 9
19 Varför är det viktigt att testa? 4
20 En telefonväxel på ett hotell kan utföra tre funktioner:
  1. Ringa till ett annat hotellrum genom att ange ett rumsnummer (201-500).
  2. Ringa ett externt samtal genom att slå 0 följt av telefonnumret.
  3. Ringa olika hotelltjänster
    1. 7 – Telefonist
    2. 8 - Rumsbetjäningen
    3. 9 – Receptionen
Skriv en uppsättning testdata och förväntat resultat för att testa systemet på ett korrekt sätt. Olika testfallstekniker ska användas.		 15
21 Beskriv vad som menas med termen ”statisk testning”. Nämn också tre statiska testtekniker. 4
22 Nämn fem sätt att prioritera testfallen. 10
23 Scenario:
Du ska testa två program och har planerat tre veckor för att testa bägge programmen. När det har gått två veckor har du genomfört samtliga tester för bägge programmen. Du ska nu avgöra vilket av de två programmen som du ska ägna mer tid åt att testa med hjälp av ytterligare tester. Använd nedanstående information för att fatta ditt beslut. Välj vilket av programmen du vill testa mer och motivera ditt svar.

Program A
Utvecklare: Bertil
Komplexitet: Medel
Antal rader kod: 2 000
Antal testfall: 100
Antal fel funna: 10 (1 med hög allvarlighetsgrad, 3 medium och 6 låg)

Program B
Utvecklare: Greger
Komplexitet: Medel
Antal rader kod: 2 000
Antal testfall: 100
Antal fel funna: 50 (10 med hög allvarlighetsgrad, 25 medium och 15 låg)

 4
24 En bankomat har följande funktionsbeskrivning:

Kunden matar in sitt kort. Bankomaten kontrollerar om kortet är giltigt. Om det inte är det ska kortet matas ut och kunden ska få ett felmeddelande. Om det är ett giltigt kort, ska systemet uppmana kunden att ange sin personliga kod. Systemet kontrollerar om koden är ogiltig – om den är det, visa meddelandet ”Koden är felaktig, försök igen.”. Om tre försök görs med ogiltig kod, behåller automaten kortet. Om den personliga koden är giltig, kan kunden välja en av följande transaktioner:

  • Kontantuttag utan kvitto.
  • Kontantuttag med kvitto.
  • Saldoförfrågan.
  • Avbryt.

Beskriv kortfattat varje testfall som du skapar för att testa systemet.

Ange förutsättningar för testfallen. Förutsättningar är en sammanfattande text som ofta beskrivs för flera testfall i en testspecifikation.

 10
25 Följande är ett utdrag ur en felrapport. Vilka potentiella problem kan du se i dialogen? Vilken information saknas i felrapporten?

Felrapport
ID: 12345
Miljö: Windows XP Home Edition
Prioritet: 3
Skapad av: Ture Testare
System: Ordersystemet

Felbeskrivning:
När jag loggar in och använder skärmbilden DF342, ska jag ha behörighet att ta bort poster. När jag försöker ta bort poster, får jag dock ett felmeddelande som säger att jag saknar behörighet.

Svar:
25 augusti: Utvecklare – Säkerheten måste konfigureras så att du får åtkomst till funktionen ”ta bort”. Felet stängs, detta är inget fel.

26 augusti: Testare – Jag hade konfigurerat säkerhet, det verkar inte fungera – jag har därför öppnat felet igen.

 10

Rättningsanvisningar

Nr Fråga Max
poäng
1 Bägge alternativen är korrekta. Syftet med test är både att hitta fel och att säkerställa att det uppfyller användarens behov (rätt för syftet). 2
2 Det beror på hur bra dina tester var och vad de testade. För att vara säker på förtroendet för applikationen, måste vi ha förtroende för testerna, data och miljön. 2
3 Prata med användare, utvecklare och andra för att få en förståelse för vad systemet är förväntat att göra. Dokumentera den här förståelsen och se till att detta granskas. Detta kan användas som substitut för krav- och/eller designdokumentation. Prata med testare som har testat systemet tidigare. Läs allt som finns skrivet om systemet så att dina antaganden klargörs. 4
4 Testaren ska först säkerställa om anledningen kan vara ett testfel (det vill säga testaren har gjort fel) eller om det är ett problem som är relaterat till miljön. Om inget av detta gäller, ska man kontrollera om felet redan är rapporterat. Om inte, skriv en felrapport eller ännu hellre, prata med utvecklingsgruppen om felet. 3
5 Alla tre är lika viktiga.

Om man bara fokuserar på positiva tester (tester som visar att systemet gör vad det ska göra) kommer man inte testa systemets felhantering. Dessa fel kommer troligen inte upptäckas förrän i samband med produktionssättning.

Om man i stället fokuserar enbart på negativa tester (tester som visar att systemet inte gör sådant som det inte borde) så kommer inte den normala användningen att testas.

Extremtester är viktiga eftersom de kan leda till stora konsekvenser (t ex systemet kommer inte igång igen efter strömavbrott, data förloras etc), men om man fokuseras på dem kommer man inte testa normal användning av systemet.

En sund balans krävs mellan samtliga dessa tre angreppssätt.

 2
6 Ett bra testfall är ett testfall som potentiellt kan hitta ett fel i systemet. Om testfallet inte gör att ett fel hittas, bidrar det till att öka förtroendet för systemet. Ett testfall måste också vara effektivt så att inte flera testfall testar samma sak. 2
7 Testfall bör finnas för följande situationer:
  1. En giltig oliksidig triangel
  2. En giltig liksidig triangel
  3. En giltig likbent triangel
  4. För var och en av de tre varianterna av två lika långa sidor i giltiga likbenta trianglar?
  5. Där en av sidorna har längden noll?
  6. Där en av sidorna har negativ längd?
  7. Där summan av längden av två sidor är lika med längden av den tredje?
  8. För var och en av de tre varianterna av testfall 7?
  9. I vilket summan av längden för de två sidorna är mindre än längden av den tredje?
  10. För var och en av de tre varianterna av testfall 9?
  11. I vilka alla tre sidor har längden noll?
  12. Med icke-heltal som indata?
  13. Med fel antal indatavärden?
  14. Har du specificerat förväntat värde för samtliga testfall?

Extra pluspoäng kan ges för ytterligare testfall som prestanda, tillförlitlighet och konfiguration.		 17
8 Det här är inte ett allvarligt problem eftersom meddelandet skrivs ut. Bästa lösningen skulle kunna vara A eller D – det är nödvändigt att fel rapporteras så tidigt som möjligt så att utvecklarna kan hinna åtgärda det. Det är dock beroende av felets allvarlighetsgrad och prioritet. Det här felet hindrar inte fortsatta tester – det kan även vara så att andra liknande problem uppstår med andra meddelanden och denna extra information kan hjälpa utvecklaren med ytterligare undersökningar. 3
9 Rätt svar är D – det kan vara ett problem med skillnader mellan din miljö och utvecklarens miljö. Felet kan också ha blivit löst i samband med någon annan rättning i den nya versionen. 3
10 Analysera felen för att dra en slutsats om varför de har uppkommit. Är testfallen utförda på fel sätt eller i fel miljö? Om felen har tillkommit i den nya versionen, behövs mer fakta om felen och allvarlighetsgraden. Om det är många fel som har kommit tillbaka är det troligen ineffektivt att utföra ytterligare tester i detta stadium. I stället bör man arbeta tillsammans med utvecklarna med att ta fram en ny version av systemet med felen korrigerade och omtestade innan man går vidare med den andra uppsättningen testfall. 6
11

Kravhantering och testplanering sker längs V-modellens vänstra sida. Testgenomförande sker längs den högra sidan. Det viktiga är att testarbetet ska pågå under hela utvecklingens livscykel och att testplaneringen sker så tidigt som möjligt.

 6
12
  • Komponenttest
    Detaljerade tester som syftar till att hitta fel. Utförs ofta av utvecklare. Kan även heta enhetstest, unit-test eller programtest.
  • Integrationstest (eller komponentintegrationstest)
    Här kombineras komponenter så att komponenternas gränssnitt testas. Testnivån utförs ofta av utvecklare. Integration kan göras med olika strategier såsom top-down, funktionell, bottom up och big bang.
  • Systemtest
    Funktionella och ickefunktionella tester på övergripande nivå. Först testas systemet, sedan de system som det finns kopplingar till, både inom och utanför organisationen. Test av ickefunktionella aspekter såsom prestanda och användbarhet.
  • Acceptanstest
    Test som utförs av kund/användare i syfte att stärka förtroendet för att systemet stödjer affärsverksamheten och uppfyller de specificerade kraven.

Här kan även svara att varje testnivå är kopplad till en kravnivå på motsvarande sida (som kan illustreras som horisontella streck mellan aktiviteter till höger och aktiviteter till vänster).

 10
13 Regressionstestinnebär att utföra tester i syftet att säkerställa att systemet inte har återgått till ett sämre läge än i den tidigare versionen av systemet. Regressionstest kan göras genom att utföra redan utförda, godkända tester igen för att kontrollera att de fortfarande får godkänt resultat. Man kan också välja ut de 10 eller 100 viktigaste funktionerna som alltid ska fungera.

När ett utfört testfall har resulterat i att man har hittat ett fel och felet har korrigerats genomför man omtest. Det innebär att testaren utför testfallet igen för att säkerställa att felet är rättat på ett tillfredsställande sätt.

 4
14 Om man antar att varje arbetsdag består av 7 timmar effektiv arbetstid, så skulle arbetsuppgiften ta
600 * 10 = 6 000 minuter = 100 timmar = drygt 14 dagar.

Det finns flera olika alternativ som kan övervägas:

  • Arbeta övertid – det ska inte betraktas som första utväg.
  • Begära fler testare – inte heller detta är bästa lösningen, speciellt inte om du måste lägga tid på utbildning och stöd för den nya personalen.

Bättre alternativ:

  • Prioritera om testerna och genomför de viktigaste testerna först.
  • Om färre än de 600 testfallen inte kan utföras inom den avsatta tiden, behöver man göra en riskanalys av konsekvenserna av att vissa av testerna inte körs.
  • Utför de resterande testerna efter den första veckans tester och därpå följande driftsättning, under förutsättning att du får använda den tiden.
 5
15 Testverktyg är en mycket viktig hjälp i testarens arbete. Testverktyg kan även göra testaren mer effektiv i sitt arbete.

I regressionstester kan ett verktyg för automatisering göra det möjligt att genomföra ett större antal tester än om testerna skulle genomföras manuellt.

Ett verktyg som innehåller både krav, testfall och felrapporter gör det lättare att välja regressionstestfall tack vare spårbarhet. Det ökar också möjligheten att följa förloppet eftersom det gör det lättare att se bedöma hur stor del av arbetet som är avverkat.

Dock ska man ha i åtanke att verktygen själva inte automatiskt gör bra testare, och att man inte heller ska införa verktygsstöd om testprocessen är kaotisk, det leder till mer och snabbare kaos.

 4
16 Syftet med den här frågan är att se om kandidaten har någon som helst kännedom om verktyg. Syftet är inte att namnge specifika verktyg utan snarare att se om kandidaten kan skilja på olika typer av verktyg.

Några kategorier av verktygsstöd:

  • Verktyg för att lagra krav i en databas
  • Verktyg för att skapa och kopiera testdata
  • Automatiseringsverktyg
  • Prestandatestverktyg
  • Kodtäckningsverktyg
  • Verktyg för statisk analys
  • Teststyrningsverktyg (även kallat test management)
  • Verktyg för nätverksövervakning
 9
17 Exempel på standarder:
  • BS 7925-1 Glossary of testing terms – ordlista över testtermer
  • BS 7925-2 Component testing – komponentteststandard
  • ISO 9000 och ISO 9001, bägge är kvalitetsstandarder
  • IEEE 829 Testdokumentation
  • IEEE 1028 Granskningar
  • IEEE 1044 Incidentrapportering
 2
18 Systemet måste vara användarvänligt

Frågan är vad som menas med användarvänligt. Frågor man bör ställa sig när man får ett sådant krav:

  • Användarvänligt för vem som kan vad och som har vilken bakgrund?
  • Vilka är användarna?

Tänkbart angreppssätt för att kunna genomföra testerna:

  • Intervjua användare och beställare för att utröna vad de menar med användarvänligt.
  • Identifiera ett antal viktiga/frekventa/svåra arbetsuppgifter i systemet.
  • Fastställ rimlig tid för genomförande av varje sådan uppgift (t ex det bör inte ta mer än fem minuter att lägga upp en order för att systemet ska anses ha hög användbarhet).
  • Beskriv detaljerade testfall för ett antal sådana arbetsuppgifter.
  • Låt flera användare genomföra samma uppsättning av testfall.
  • Diskutera med användarna samtidigt som de genomför testfallen samt efteråt för att få kompletterande information om vad användarna upplevde som svårt eller enkelt.

Systemet måste vara enkelt att installera.

Vad menar vi med ”enkelt”. Frågor att ställa:

  • För vem?
  • Finns det någon installationsdokumentation att följa?

Angreppssätt för att kunna testa:

  • Följ installationsdokumentationen (om det finns någon).
  • Låt en oerfaren användare/tekniker installera systemet för att se hur enkelt det är att installera.
  • Dokumentera tester och granska dessa tillsammans med de som ska installera.

Krav på svarstider

Några frågor att resonera kring:

  • Vad händer om systemet inte lever upp till de ställa prestandakraven?
  • Ett bättre definierat krav skulle kunna involvera ett intervall, t ex 3 sekunder i 95 % av fallen och max 5 sekunder i resterande fall.
  • Är svarstiderna realistiska med tanke på systemets arkitektur?
  • Vad har utvecklarna gjort för att säkerställa att kravet är uppfyllt?
  • Finns det prestandatestverktyg? Kan open source-alternativ användas? Om det av någon anledning inte är möjligt att använda verktyg, skulle man kunna genomföra ett antal tester, klocka resultatet och presentera genomsnittet. Det blir inte så exakt men duger eventuellt.
  • Vad innebär det att söka? Hur mycket information? Definiera eventuellt en normal sökning och en omfattande sökning.
 9
19
  • För att hitta fel.
  • För att kontrollera om kraven är uppfyllda.
  • För att programvara alltid innehåller fel.
  • För att fel som hittas efter driftsättning kan kosta mycket pengar.
  • Ibland krävs test av kontraktsmässiga eller juridiska skäl.
  • För att systemets kvalitet inte ska bli sämre över tiden (regressionsfel).
  • För att få ett underlag för mätning.
 4
20

Positiva testfall

Indata Förväntat resultat
7 Telefonist
8 Rumsbetjäningen
9 Receptionen
201 Rum 2<01 (giltigt gränsvärde)
405 Rum 405 (giltig ekvivalensklass)
500 500 (giltigt gränsvärde)
0 Extern linje

 

Negataiva testfall

Indata Förväntat resultat
1 Fel (negativt test, inget gränsvärde)
6 Fel (negativt test, inget gränsvärde)
200 Fel (ogiltigt gränsvärde)
501 Fel (ogiltigt gränsvärde)
5500 Fel (ogiltig ekvivalensklass)
Alla andra
knappar samtidigt		 Fel (extremtest)

 

Övriga tester

112 Ska kunna ringas utan att slå nolla
0, vänta en minut Testar om det blir en time out
Många ringer 9 Prestandatest
15
21 Statiska tester är sådana där programmet inte exekveras (körs). Några exempel på statiska testtekniker:
  • Granskning av dokument.
  • Walkthrough.
  • Skrivbordstester där testaren stegar igenom flöden i programkoden.
  • Kodgranskning.
  • Granskning med hjälp av verktyg, t ex kontroll av att kodningsriktlinjer är uppfyllda.
 4
22
  • Be kunden att prioritera kraven. De viktigaste kraven bör testas mest.
  • Be kunden prioritera testfallen.
  • Prioritera baserat på vad som är mest kritiskt för kundens affärsverksamhet.
  • Prioritera baserat på fel som skulle få stora konsekvenser.
  • Prioritera tester där fel skulle vara mest synliga, exempelvis fel i användargränssnittet före fel i admin-verktyg.
  • Prioritera tester där det är störst sannolikhet för fel, t ex nya eller svåra delar.
  • Prioritera delar i systemet som ofta ändrats.
  • Prioritera delar i systemet som historiskt haft med många problem.
  • Prioritera komplexa eller tekniskt kritiska delar i systemet.
 10
23 Saker att resonera kring:
  • Olika programmerare skrev A och B.
  • Bägge programmen har samma svårighetsgrad.
  • Programmen är lika stora.
  • Det är samma testare för både A och B.
  • Lika många testfall är utförda för programmen.
  • Antalet funna fel är högre i program B.

Felen är ofta toppen på ett isberg och förekommer ofta i klungor. Det är därför troligt att det finns ytterligare fel i program B som ännu inte hittats. Därför kan det vara lämpligt att testa program B ytterligare en vecka. Man bör inte heller vara helt nöjd med kvaliteten hos program B. Genom att testa ytterligare en vecka kan man få ökat förtroende för programmet.

Man bör även analysera om testfallen för program A är korrekt valda/utförda. Om testerna är genomförda på fel sätt är det sannolikt att felen ännu inte hittats.

Man bör även ta reda på mer om kraven och om de tester som genomförts tidigare eftersom kvaliteten på tidigare krav- och testnivåer på verkar resultatet på senare testnivåer. Om utvecklarnas tester är bristfälligt genomförda eller om kraven är dåliga i något av systemen, bör det systemet testas mer.

 4
24
  1. Ogiltigt kort – bankomaten matar ut kortet.
  2. Giltigt kort, ogiltig personlig kod. Felmeddelandet ”Koden är felaktig, …” visas. Kunden anger sedan giltig personlig kod.
  3. Giltigt kort, ogiltig personlig kod, felmeddelandet ”Koden är felaktig, …” visas. Kunden anger ogiltig kod ytterligare två gånger. Bankomaten tar kortet.
  4. Giltigt kort, giltig personlig kod och därefter Avbryt.
  5. Giltigt kort, personlig kod med fler tecken än tillåtet. Ska ge felmeddelande.
  6. Giltigt kort, korrekt personlig kod plus ytterligare efterföljande tecken. Ska ge felmeddelande.
  7. Giltigt kort, personlig kod med färre tecken än tillåtet. Ska ge felmeddelande.
  8. Giltigt kort, giltig personlig kod och kontantuttag utan kvitto.
  9. Giltigt kort, giltig personlig kod och högre kontantuttag än vad det finns täckning för på kontot, med och utan kvitto.
  10. Giltigt kort, giltig personlig kod och kontantuttag med kvitto.
  11. Giltigt kort, giltig personlig kod och saldoförfrågan.
  12. Extremtester som t ex:
    1. Mata in två kort.
    2. Tryck på flera knappar samtidigt

Förutsättningar:
Kund med pengar på kontot, bankomatkort och giltig kod.

 10
25 Potentiella problem/information som saknas:
  • Felrapporten saknar datum då felet skapades.
  • Status saknas (öppnad, åtgärdad, stängd, godkänd etc)
  • Ägare saknas.
  • Prioritet finns, men allvarlighetsgrad, dvs risk för kunden, saknas.
  • Version på det testade systemet saknas – det är mycket troligt att testarna har en annan version av systemet än utvecklarna och att felet har åtgärdats i den senare versionen.
  • Ifrågasätt felets prioritet, ska det vara prioritet 3 (och vad betyder prioritet 3).
  • Felmeddelandet som testaren fick, saknas i felrapporten. Felmeddelandet kan ge ledning till utvecklaren om felets natur.
  • Det verkar som om kommunikationen leder till en dialog. Det finns en risk att testaren och utvecklaren fortsätter bolla frågan fram och tillbaka. Problemet bör skickas till CCB (Change Control Board) eller till en beslutsfattare. Alternativt bör de prata med varandra i stället.
  • Utvecklarens svar pekar på en annan del av systemet (säkerhet) – det här kan vara en indikation på att utvecklare försöker stänga felet snabbt utan att genomföra en tillräckligt grundlig undersökning. Orsaken kan också vara att testaren inte har lagt tillräckligt mycket tid på att dokumentera problemet.
 10

KONTAKTA OSS

Har du frågor? Vill du ha hjälp med områden inom kravhantering och test?
Hör av dig till oss! Vi hjälper dig gärna. 

Kontakt 

Dela artikeln