Deze versie van de methode is toepasbaar voor het vastleggen van as-is requirements en het testen van bestaande applicaties. Het ontwikkelteam werkt niet volgens de Black Box Dialog Methode. De volgorde waarin gewerkt wordt is anders dan bij het toepassen van de methode in nieuwbouw projecten.
Je begint met het vastleggen van de Black Box Dialog Collection. Dit kan omdat je een werkende applicatie voor je hebt.
De Black Box Dialog collections beschrijven het gedrag van het systeem op een wat hoger niveau.
Daarom worden de Black Box Dialog collections daarna aan een testanalist gegeven die BBD collection opsplitst in de afzonderlijke dialogen.
Deze worden vervolgens in een Test Tool als logische testscenario’s gemaakt.
Per dialoog worden de parameters bepaald die de dialoog kunnen beïnvloeden. Door testtechnieken los te laten op deze parameters wordt elk logisch testscenario 1 of meerdere keren fysiek gemaakt.
Heel belangrijk hierin is echter wel dat er gewerkt wordt op basis van een product-risico-inventarisatie. Het aantal testscenario’s wordt anders veel groter dan er binnen het project aan budget is.
Door op onderstaande figuur te klikken verschijnt deze in groter en leesbaar formaat.
Deze methode is toegepast bij een luchtvaartmaatschappij op een bedrijfskritische applicatie waarmee alle medewerkers worden ingeroosterd.
Dit roosterprogramma is een extern ontwikkelde applicatie waarmee alle werknemers ingepland worden die iets moeten doen met een vliegtuig tussen aankomst en vertrek, zoals tanken, schoonmaken, verslepen etc. De opdrachten krijgen ze op een handcomputer.
In de praktijk waren de BBDs – hoewel omvangrijk – toch zeer goed reviewbaar. De gereviewde BBDs bleken een solide basis voor gestructureerd testen. Omdat een BBD de verzameling is van alle mogelijke dialogen tussen de Actoren en het systeem, kan elke dialoogregel uit een BBD rechtstreeks vertaald worden naar een logisch testgeval. Door met de parameters van de dialoog te variëren volgen hier één of meer fysieke testgevallen uit.