ISTQB och Use-Cases

Det farliga med en standard är att det som står i den ska räknas som det som gäller. Det är därför viktigt att informationen stämmer överens med resten av världen. Då jag just nu sitter och arbetar med test i Unified Process undersökte jag vad som står i Syllabusen om Use-Cases. Väljer att studera den internationella version som övriga länders översättning bygger på.

4.3.5 Use case testing (K2)

Tests can be specified from use cases or business scenarios. A use case describes interactions between actors, including users and the system, which produce a result of value to a system user. Each use case has preconditions, which need to be met for a use case to work successfully. Each use case terminates with post-conditions, which are the observable results and final state of the system after the use case has been completed. A use case usually has a mainstream (i.e. most likely) scenario, and sometimes alternative branches.

Use cases describe the “process flows” through a system based on its actual likely use, so the test cases derived from use cases are most useful in uncovering defects in the process flows during real-world use of the system. Use cases, often referred to as scenarios, are very useful for designing acceptance tests with customer/user participation. They also help uncover integration defects caused by the interaction and interference of different components, which individual component testing would not see.

Som metodare reagerar jag på de ord och förklaringar man använder sig av.

1) Mainstream Scenario: detta betecknas vanligen primary flow, basic flow eller happy flow. Mainstream är en helt ny beteckning.

2) Alternative branches: flow eller path är OK men branch är också en ny beteckning.

3) Sen står det att Use-Cases är mest effektiva för att hitta Real-World problem och därmed bäst för acceptanstest. Nu finns det ju en business modeling disciplin och där kan det finnas business use cases men ofta är det business processes, information och rules som beskrivs och dessa testas främst i acceptanstest. Use-Cases är ju kraven på SYSTEMET och testas främst i systemtest.

4) Sen säger man att ett Use-Case vanligen kallas scenarios vilket också är fel då ett scenario är EN väg genom ett use-case. Oftast finns det ett flertal scenarios som ska testas - detta är också tekniken för test av Use-Cases. Ta fram aktivitetsdigrammet och testa alla (om det går) scenarios.

5) Till sist blandar man in component testing och integration mellan komponenter där man blandar ihop component, component -integration och system testing. Det är som att skriva att use-case testing - som är en black-box teknik är bättre än komponenttest för att testa helheten. Ja det är ju rätt i princip men jämföra en en specifik teknik med en testnivå är väl knappast logiskt.

Helt uppenbart har den som skrivit texten inte rådfrågat en UP/Use-Case expert eftersom till och med de vanligaste begreppen och huvudsyftena är felaktiga.

Lite mer än så borde vi kunna förvänta oss av en internationell standard tycker jag.