Enhancements aan Test Scenarios en Test Raamwerk

Inleiding

Om het testprotocol succesvol te kunnen doorlopen zijn er vier factoren die foutloos moeten zijn: De software, de systematiek regels en het testscenario en het testraamwerk.

Bij de testen tussen B&S VISI en Alfamail zijn een aantal fouten ontdekt die in het testprotocol geslopen zijn. Na afstemming tussen Bakker & Spees en Technia Transcat is vastgesteld dat een aantal testproblemen te wijten waren aan het testprotocol. De software en de systematiek zijn dus correct.
In dit issue beschrijven we de oplossing van deze problemen.

Problemen scenario 2:

Samenvoeging: het bleek dat scenario 2a en 2c letterlijk uit dezelfde tekst bestonden, waardoor deze 2 scenario's samengevoegd zijn tot scenario 2.

Het blijkt dat scenario 2 sinds de bouw van test scenario 7: "de volgordelijkheid van berichten" theoretisch en praktisch niet meer uitvoerbaar is.

Scenario 2 zet kort gezegd 2 subtransacties uit, waarbij er van 1 subtransactie het antwoord gebruikt wordt, waarna je niets kan met het antwoord van de tweede subtransactie. Nu hebben we voor scenario 7 op de bestelling die in scenario 2 gebruikt wordt om 2 subtransacties mee uit te zetten de “onlyonce” functie gezet, waarmee je test dat je maar 1 kok tegelijk een bestelling mag laten uitvoeren. Dus kun je scenario 2 niet uitvoeren, want dan moet je 2 koks aanschrijven.

Vervolgens is gekeken of we een aanvullend bericht of transactie in het testraamwerk aan moesten brengen om beide cases te ondersteunen. Maar dan lukt het niet om nog een enigszins realiteitsgetrouwe testcase in stand te houden.

Dus is gekeken wat er precies afgetest wordt en of dat niet veel beter op een andere plek in het raamwerk getest kan worden. Dat resultaat was meer dan positief: een “vraag ober aan kok” mag je wel parallel aan meerdere koks stellen.

Scenario 5b doet deze test blijkbaar ook al bij de “vraag”, net zoals 2 dat bij de “opdracht” testte. Hierin zit zelfs dezelfde check dat je maar met 1 van de antwoorden verder kunt. Dit maakt dat scenario 2 volledig als dubbel te noemen is ten opzichte van de bovengenoemde check in 5b. Dus het laten vervallen van scenario 2 heeft geen negatieveconsequenties voor de testscope

Scenario 2 is daarom verwijderd uit het testscenario -raamwerk.

probleem Scenario 4b, 4c, 5c, 5d

In deze scenarios staat de volgende tekst: Klant K stelt een tweede vraag aan Ober A. (In de vraagstelling kan Klant K de vraag niet invullen, omdat in het raamwerk de ElementCondition geen waarde voor condition heeft!!!) Dit klopt niet, zie de volgende element condition in het testraamwerk:

<ElementCondition id="ElementCondition2">
    <description>Na een antwoord volgt mogelijk een nieuwe vraag.
    </description>
    <condition>EMPTY</condition>
    <simpleElement>
        <SimpleElementTypeRef idref="Vraag"/>
    </simpleElement>
    <messageInTransaction>
        <MessageInTransactionTypeRef idref="BerichtInTransactie5"/>
    </messageInTransaction>
</ElementCondition>

Zonder enige aanpassing zou alleen foutieve software door de test heen komen.

Daarop zijn we overeengekomen dat we de testbeschrijving als volgt aanpassen: Klant K stelt een tweede vraag aan Ober A. (In de vraagstelling kan Klant K een nieuwe vraag invullen, omdat in het raamwerk de ElementCondition Empty heeft!!!)

Hiermee klopt de testbeschrijving met het testraamwerk en de test "default fixed" wordt toch nog uitgevoerd met de test tekst "Ober A biedt de menukaart aan die Klant K gevraagd heeft. Ober A kan het menukaarttype niet wijzigen", die wel 10x in de huidige testprotocollen staat. Deze aanpassing versterkt dus het testprotocol en verliest geen test aspecten. Het aanpassen van het testraamwerk zou dit probleem wel hebben, omdat dan de "empty" test zou verdwijnen.

nl-digigo / visi