4.5 Samarbetsbaserade testangreppssätt Flashcards

1
Q

Vad är samarbetsbaserade testangreppssätt?

A

Fokuserar på
att undvika defekter genom samarbete och kommunikation

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Vad är en användarberättelse?

A

Den representerar en funktion som kommer att vara värdefull för antingen en användare eller köpare av ett system eller programvara.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Vilka 3 C:n innehåller en användarberättelse?

A

Kort, konversation och bekräftelse
Card, Conversation, Confirmation

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Vad innebär kort/card i en användarberättelse?

A

Mediet som beskriver en användarberättelse (t.ex. ett registerkort, en post på en elektronisk tavla)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Vad innebär konversation/conversation i en användarberättelse?

A

förklarar hur programvaran kommer att användas (kan
dokumenteras eller verbalt)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Vad innebär bekräftelse/confirmation i användarberättelse?

A

– acceptanskriterierna

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Hur ser det vanligaste formatet för en användarberättelse ut?

A

“Som en [roll] vill jag att [målet ska uppnås], så
att jag kan [resulterande affärsvärde för rollen]”, följt av acceptanskriterierna.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Vad för teknik kan man använda när man skriver användarberättelser?

A

Brainstorming och mindmapping

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Vad är positivt med att skriva användarberättelser tillsammans?

A

Samarbetet gör att teamet får en gemensam vision om vad som ska
levereras, genom att ta hänsyn till tre perspektiv: verksamhet, utveckling och testning.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Hur bör bra användarberättelser vara?

A

Oberoende, Förhandlingsbara, Värdefulla, Uppskattningsbara, Små
och Testbara (INVEST: Independent, Negotiable, Valuable, Estimable, Small and Testable).

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Om en intressant inte vet hur man testar en användarberättelse: vad kan det bero på?

A

Det kan tyda på att användarberättelsen inte
är tillräckligt tydlig, eller att den inte speglar något värdefullt för denne, eller att intressenten bara behöver hjälp med att testa

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Vad är acceptanskriterier?

A

De villkor som en implementering av
användarberättelsen måste uppfylla för att accepteras av intressenter

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

I vilken del av de tre c:na i användarberättelser är acceptanskriterier ett resultat av?

A

Konversationen / conversation

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Vad används acceptanskriterier för?

A
  • Definiera omfattningen av användarberättelsen
  • Uppnå konsensus bland intressenterna
  • Beskriva både positiva och negativa scenarier
  • Fungera som bas för acceptanstestning av användarberättelser (se kapitel 4.5.3)
  • Möjliggöra rätt planering och uppskattning
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Säg två vanliga sätt att skriva acceptanskriterier på

A
  • Scenarioorienterat (t.ex. formatet Given/When/Then som används i BDD, se kapitel 2.1.3)
  • Regelorienterat (t.ex. verifieringslista med punkter, eller tabellform med input-outputmappning)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Vad står ATDD för?

A

Acceptanstestdriven utveckling

17
Q

Vad är ATDD för typ av testmetod?

A

En test-first-metod

18
Q

När skapar man testfallen i ATDD?

A

Innan användarberättelsen implementeras

19
Q

Vilka gör testfallen i ATDD?

A

Teammedlemmar med olika perspektiv, t.ex. kunder, utvecklare
och testare

20
Q

Vilket är det försa steget i ATDD?

A

En specifikationsworkshop där användarberättelsen och (om inte ännu definierad)
dess acceptanskriterier analyseras, diskuteras och skrivs av teammedlemmarna. Ofullständigheter,
oklarheter eller defekter i användarberättelsen löses under denna process.

21
Q

Vad gör man i ATDD efter att man haft sin specifikationsworkshop?

A

Man skapar testfallen

22
Q

Vem skapar testfallen i ATDD?

A

Av hela teamet eller av testaren själv

23
Q

Vad baseras testfallen på i ATDD?

A

På acceptanskriterierna.

24
Q

Hur kan man se på testfallen i ATDD?

A

Kan ses som exempel på hur programvaran fungerar. Detta kommer att
hjälpa teamet att implementera användarberättelsen korrekt.

25
Vad är skillnaden på exempel och tester i ATDD?
De är detsamma, därför används dessa termer ofta omväxlande.
26
På vilket sätt ska testfallen skrivas i ATDD?
På ett sätt som är förståeligt för intressenterna. Vanligtvis innehåller testfallen meningar på naturligt språk som inkluderar de nödvändiga förutsättningarna (om några), indata och sluttillstånd.
27
Vad för typ av testfall brukar man ha i ATDD? 3
Vanligtvis är de första testfallen positiva, och bekräftar det korrekta beteendet utan undantag (exception) eller feltillstånd. Efter att de positiva testfallen är genomförda ska teamet utföra negativa tester. Slutligen bör teamet täcka icke-funktionella kvalitetsegenskaper (t.ex. prestandaeffektivitet och användbarhet).
28
Hur ska man tänka när man skriver testfall i ATDD kopplat till användarberättelsen?
- Testfallen måste täcka alla egenskaper hos användarberättelsen - Ska inte gå utanför berättelsen. - Acceptanskriterierna kan dock beskriva några av de problem som beskrivs i användarberättelsen. - Fler testfall ska inte beskriva samma egenskaper hos användarberättelsen.
29
När utvecklarna vägleds av ett format som stöds av ett ramverk för testautomatisering kan de automatisera testfallen genom att använda vägledningen vid implementationen av funktionen som beskrivs av en användarberättelse. Acceptanstesterna blir då .....
.. exekverbara krav