Phase 4: Testen und Präsentieren

Webseitenprojekt · Phase 4 von 4 · Meilenstein M4

Ziel dieser Phase

Du prüfst deine Seite gründlich, vergleichst sie mit deinem Plan, stellst sie vor und blickst auf das Projekt zurück. Danach ist das Projekt abgeschlossen (Meilenstein M4).

Endet dein Projekt in IT 11.7 nach der Grundstufe, bearbeitest du diese Phase ebenfalls. Die Tests zu Formular und Daten (Punkt 5 und 6) entfallen dann, und in der Präsentation erklärst du eine Stelle im HTML oder CSS.

Schritt 1: Systematisch testen

„Bei mir geht’s“ reicht nicht. Ein Test prüft eine Sache gezielt, und du schreibst das Ergebnis auf. Fehler, die du selbst findest, findet in der Präsentation niemand mehr.

Schritt 1: Testplan abarbeiten mittel

Lege im Projektplan eine Tabelle mit den Spalten Test | Wie geprüft? | Ergebnis | behoben? an. Überprüfe mindestens diese Punkte und ergänze eigene Tests für deine Muss-Anforderungen:

1. Links: Jeder Link im Menü und im Text führt zur richtigen Seite.
2. Handy: Geräteansicht mit 360 px Breite. Kein seitliches Scrollen, alles lesbar und mit dem Finger bedienbar.
3. Tastatur: Mit der Tabulatortaste durch die ganze Seite. Erreichst du jeden Link, jeden Knopf und jedes Feld? Siehst du immer, wo du bist?
4. Kontrast: Jede Farbkombination mit dem Kontrastprüfer.
5. Formular: Absenden mit leeren Feldern, mit falschen Werten (zum Beispiel Buchstaben statt Zahl) und mit richtigen Werten.
6. Daten: Was passiert, wenn die JSON-Datei fehlt? (Benenne sie testweise um.) Was zeigt der Filter, wenn kein Eintrag passt?
7. Konsole: keine roten Fehlermeldungen.
8. Bilder: Alle Bilder erscheinen und haben passende Alternativtexte. Alle Quellen stehen auf quellen.html.

Tipp 1

Teste besonders die Ränder: leere Eingaben, sehr lange Texte, ein Filter ohne Treffer, die erste und die letzte Seite einer Galerie. Dort verstecken sich die meisten Fehler.

Tipp 2

Lass eine zweite Person testen, die die Seite noch nicht kennt. Wer den Code geschrieben hat, klickt unbewusst immer richtig.

Ergänzend: HTML automatisch prüfen

Der Validator des W3C prüft, ob dein HTML den Regeln entspricht: validator.w3.org (Du verlässt jetzt Maternet, englisch). Dabei lädst du deine Datei auf einen fremden Server hoch. Prüfe deshalb vorher, dass keine persönlichen Daten darin stehen.

Schritt 2: Soll und Ist vergleichen

Ein Soll-Ist-Vergleich stellt gegenüber, was geplant war (Soll) und was entstanden ist (Ist). Abweichungen sind normal. Wichtig ist, dass du sie erklären kannst.

Schritt 2: Soll-Ist-Vergleich mittel

Vergleiche dein Ergebnis mit dem Projektplan (Abschnitt 2 und 5):

• Welche Muss- und Kann-Anforderungen sind erfüllt, welche nicht?
• Welche Termine hast du eingehalten, welche nicht?
• Begründe jede Abweichung: Was war der Grund, und wie hast du darauf reagiert?

Trage das Ergebnis im Projektplan (Abschnitt 8) ein.

Tipp 1

Eine gute Begründung nennt die Ursache und die Entscheidung: „Das Quiz habe ich gestrichen, weil der Filter länger gedauert hat als geplant. Der Filter war eine Muss-Anforderung, das Quiz nur eine Kann-Anforderung.“

Schritt 3: Präsentieren

Schritt 3: Das Projekt vorstellen mittel

Stelle dein Projekt in etwa fünf Minuten vor (die genaue Zeit nennt deine Lehrkraft). Diese Gliederung hilft:

1. Thema, Ziel und Zielgruppe in zwei bis drei Sätzen
2. Vorführung der Seite: Zeige, wie eine Person aus deiner Zielgruppe die Seite nutzt, auch auf dem Handy.
3. Eine Code-Stelle erklären, auf die du stolz bist, zum Beispiel deinen Filter
4. Ein Problem und deine Lösung
5. Soll-Ist-Vergleich in einem Satz: Was ist anders geworden als geplant?

Tipp 1

Probiere die Vorführung vorher einmal am Präsentationsrechner aus. Starte Live Server vor der Präsentation und halte die Seiten schon offen.

Tipp 2

Für die Code-Stelle: Vergrößere die Schrift im Editor (Strg und +) und erkläre in der Reihenfolge, in der der Code abläuft, nicht von oben nach unten.

Schritt 4: Rückmeldung geben und nehmen

Nach jeder Präsentation geben die Zuhörenden kurz Rückmeldung. Gute Rückmeldung ist konkret, freundlich und bezieht sich auf die Seite, nicht auf die Person.

Leitfragen für die Zuhörenden:

• Habe ich verstanden, für wen die Seite ist und was sie leisten soll?
• Was war besonders gelungen? (konkret: „Der Filter nach Preis …“)
• Was würde ich als Nutzerin oder Nutzer anders machen wollen?

Wer präsentiert, hört zu, fragt nach und verteidigt sich nicht. Du entscheidest danach selbst, was du übernimmst.

Schritt 5: Zurückblicken und abgeben

Schritt 5: Rückblick und Abgabe leicht

1. Beurteile dein Projekt selbst mit den Kriterien unten: erfüllt, teilweise oder noch nicht.
2. Beantworte im Projektplan (Abschnitt 8): Was mache ich beim nächsten Projekt anders? Was hat mir beim Arbeiten am meisten geholfen?
3. Gib deinen Projektordner als ZIP-Datei ab:
   • Prüfe vorher, dass alles im Ordner liegt: alle HTML-Seiten, style.css, app.js, deine JSON-Datei, der Ordner bilder und projektplan.txt.
   • Klicke im Explorer mit der rechten Maustaste auf den Ordner und wähle „Komprimieren“ bzw. „In ZIP-Datei komprimieren“ (die Bezeichnung hängt von der Windows-Version ab).
   • Benenne die ZIP-Datei mit deinem Projektthema, zum Beispiel projekt-fahrradverleih.zip, und gib sie so ab, wie deine Lehrkraft es sagt.
   • Öffne die ZIP-Datei zur Probe einmal: Lässt sich die Seite daraus starten?

Kriterien

Nach diesen Kriterien gibt dir deine Lehrkraft Rückmeldung zu deinem Projekt. Lies sie schon am Anfang des Projekts, dann weißt du, worauf es ankommt. Am Ende nutzt du sie für deine Selbsteinschätzung.

Es gibt zwei Listen. Welche für dich gilt, sagt dir deine Lehrkraft:

• IT 11.7: Das Projekt wird nach der Grundstufe beurteilt (Phase 1, 2 und 4).
• IT 12.6: Das Projekt wird vollständig beurteilt (alle vier Phasen). Die Liste enthält die Punkte aus 11.7 noch einmal. Sie sind mit „(wie 11.7)“ gekennzeichnet.

Kriterien IT 11.7: Grundstufe

Bereich	Das gehört dazu
Planung und Dokumentation	Projektplan vollständig: Ziel, Zielgruppe, überprüfbare Muss- und Kann-Anforderungen, Seitenplan, Skizze für Handy und breiten Bildschirm. Arbeitstagebuch regelmäßig geführt. Soll-Ist-Vergleich mit begründeten Abweichungen.
Inhalt und HTML	Inhalt passt zu Ziel und Zielgruppe, eigene Texte. Mindestens drei Seiten und quellen.html mit gemeinsamem Menü. Vollständiges Grundgerüst. Sinnvolle Gliederung (header, nav, main, footer, Überschriften in richtiger Reihenfolge), passende Elemente, Bilder mit Alternativtext.
Gestaltung	eigenes CSS in einer eigenen Datei, ohne Framework, Farben als Variablen. Einheitlich und übersichtlich nach den Designgrundsätzen. Layout mit Abständen und Flexbox.
Handy und Barrierefreiheit	bei 360 px Breite ohne seitliches Scrollen nutzbar, mindestens eine Media Query. Kontrast mindestens 4,5 : 1. Mit der Tastatur bedienbar, Fokus sichtbar.
Code verstehen	übersichtlich eingerückt, Kommentare an wichtigen Stellen. Du kannst jedes Element und jede CSS-Regel erklären, auch auf Nachfrage.
Quellen und Regeln	alle fremden Inhalte mit Quelle und Lizenz, keine echten persönlichen Daten, keine Einbindungen von fremden Servern.
Präsentation	verständlich, im Zeitrahmen, mit Vorführung (auch in der Handy-Ansicht) und Erklärung einer Stelle im HTML oder CSS.

Kriterien IT 12.6: vollständiges Projekt

Bereich	Das gehört dazu
Planung und Dokumentation (wie 11.7)	Projektplan vollständig und aktuell, Arbeitstagebuch, Soll-Ist-Vergleich mit begründeten Abweichungen. Die Anforderungen enthalten auch Daten, Interaktion und Formular.
Inhalt und HTML (wie 11.7)	Inhalt passend und selbst geschrieben, mindestens drei Seiten und quellen.html, Grundgerüst, Gliederung, passende Elemente, Alternativtexte.
Gestaltung, Handy und Barrierefreiheit (wie 11.7)	eigenes CSS ohne Framework, einheitlich, 360 px ohne seitliches Scrollen, Kontrast, Tastatur. Das gilt auch für alles, was JavaScript erzeugt (zum Beispiel Kacheln oder Fehlermeldungen).
JavaScript und Daten	eigene JavaScript-Datei mit defer. Daten in einer eigenen JSON-Datei (mindestens sechs Objekte), mit fetch geladen, verständliche Meldung bei Ladefehlern. HTML wird aus den Daten erzeugt. Mindestens eine Interaktion (filtern, sortieren oder suchen) über Ereignisse. Keine Fehler in der Konsole.
Formular	mindestens drei Felder verschiedener Art, Prüfung mit HTML und JavaScript, Fehlermeldungen direkt am Feld, die sagen, was zu tun ist. Bestätigung mit den Eingaben, ausgegeben mit textContent.
Code verstehen	sprechende Namen, Kommentare über jeder Funktion. Du kannst den Ablauf deines JavaScript-Codes erklären, auch an einer Stelle, die deine Lehrkraft auswählt.
Quellen und Regeln (wie 11.7)	alle fremden Inhalte mit Quelle und Lizenz, keine echten persönlichen Daten, keine Einbindungen von fremden Servern.
Präsentation (wie 11.7)	verständlich, im Zeitrahmen, mit Vorführung (auch auf dem Handy) und Erklärung einer Stelle im JavaScript-Code.

Geschafft

Du hast eine eigene Webanwendung von der Idee bis zur Präsentation umgesetzt. Den Ordner mit Plan, Skizzen und Code kannst du behalten. Er zeigt, was du kannst.