 | | | | | |||||||
| | | | | |||||||
| |
| | | |||||||
| | | | | |||||||
| | | | |
|
Begründung der methodischen Entscheidungen
Die folgend dargestellten Varianten des Ratespiels werden nicht durch den Lehrer
vorgegeben.
Vielmehr wird nach dem Aufwerfen des Problems und nach dessen Lösung durch die Schüler
nach solchen Schülerlösungen gesucht, die geeignet erscheinen, das entsprechende
Testverfahren vermitteln zu können.
Die komplexer werdenden Programme entstehen erfahrungsgemäß dadurch, daß die Schüler
selbst nach einer "Verbesserung" ihres Programms streben, zumindest dann, wenn
im Problemkern eine Spielidee enthalten ist.
Eine Erweiterung eines Lösungsalgorithmus ist aber oft mit Fehlern verbunden, was ja in
diesem Fall auch Absicht ist, um dessen Notwendigkeit zu motivieren.
Solche Blackboxverfahren wie Grenzwertanalyse und Fehlererwartung bzw. Whiteboxverfahren wie Erfassen aller Befehle werden durch die Schüler, entsprechend didaktisch reduziert in Formulierung und Vollständigkeit, intuitiv erfaßt. Die Behandlung erfolgt nicht in eigenen Unterrichtsreihen zum Testen, sondern simultan zur Vermittlung neuer Datentypen oder Algorithmengrundstrukturen.
Demgegenüber sind solche Verfahren wie das des Erzeugens von Testfällen mittels Ursache-Wirkungs-Graphen oder die Anwendung bereits bekannter Testverfahren beim Testen von Modulen nicht durch die Schüler selbst erschließbar oder offenkundig. Hier sind zum Festigen bereits vorhandener Kenntnisse zum Testen Unterrichtssequenzen zum methodischen Erzeugen von Testfällen sinnvoll.
Das nachfolgende Unterrichtsbeispiel sollte in einem Einführungskurs (z.B. "Elementare Datentypen und Algorithmengrundstrukturen - Einführung in das Programmieren mit TURBO-PASCAL"; 11/II oder 12/I) realisierbar und sinnvoll sein.
|
