Inhaltsverzeichnis
Ein Testkonzept beschreibt, was du testest, wie du testest und wann ein Test als bestanden gilt. In der Projektarbeit lieferst du damit den Nachweis für systematische Qualitätssicherung.
Enthält:
- Testziele, Testumfang, Testumgebung
- Testfälle (je: ID, Vorbedingung, Schritte, erwartetes Ergebnis)
- Abnahmekriterien
Output:
- 1 bis 2 Seiten Konzept plus 5 bis 10 Testfälle (Richtwert, Vorgaben variieren)
- Testprotokoll als Nachweis der Durchführung
Das Testkonzept entsteht idealerweise parallel zur Anforderungsdefinition. Wenn du weißt, was deine Lösung können soll, kannst du direkt festlegen, wie du das prüfst. Hier bekommst du eine klare Struktur, Entscheidungshilfen für die Testfallauswahl, Vorlagen und konkrete Beispiele.
Testkonzept vs Testplan vs Testprotokoll
Die Begriffe werden oft verwechselt. In der Projektarbeit ist die Unterscheidung wichtig, weil Prüfende erwarten, dass du weißt, was du dokumentierst.
Was: Beschreibt, was und wie getestet wird.
Inhalte: Testziele, Testumfang, Testumgebung, Testfälle, Abnahmekriterien.
Wann: Vor der Testdurchführung erstellen.
In der Projektarbeit: Fast immer gefordert, meist im Hauptteil.
Was: Beschreibt Organisation und Zeitplanung der Tests.
Inhalte: Ressourcen, Verantwortlichkeiten, Zeitplan, Risiken, Eskalationswege.
Wann: Bei größeren Projekten mit mehreren Beteiligten.
In der Projektarbeit: Selten separat gefordert, oft ins Testkonzept integriert.
Was: Dokumentiert die durchgeführten Tests und deren Ergebnisse.
Inhalte: Testfall-ID, Datum, tatsächliches Ergebnis, Status (bestanden/fehlgeschlagen/blockiert).
Wann: Während und nach der Testdurchführung.
In der Projektarbeit: Zeigt, dass du tatsächlich getestet hast. Oft im Anhang.
Für die meisten Projektarbeiten gilt: Testkonzept mit Testfällen im Hauptteil, Testprotokoll als Nachweis (Hauptteil oder Anhang). Ein separater Testplan ist bei IHK-Projektarbeiten selten nötig. Prüfe die Vorgaben deiner Prüfungsordnung.
Testkonzept: Aufbau und Struktur
Der Aufbau des Testkonzepts folgt einer logischen Struktur. Du beschreibst zuerst die Ziele, dann den Umfang, die konkreten Testfälle und schließlich die Kriterien für die Abnahme.
Du beschreibst, was du mit den Tests erreichen willst.
Beispiel: „Die Tests sollen sicherstellen, dass alle im Pflichtenheft definierten Funktionen korrekt arbeiten und die Anwendung unter Normallast stabil läuft."
Zu vage formulieren. „Das System soll funktionieren" ist kein Testziel.
Du legst fest, was getestet wird und was nicht.
Beispiel: „Getestet werden: Benutzeranmeldung, Dateneingabe, Berichterstellung. Nicht getestet werden: Bestandssysteme, da diese bereits produktiv laufen."
Nicht begründen, warum etwas ausgeschlossen wird. Prüfende fragen sich sonst, ob du es vergessen hast.
Du beschreibst, in welcher Umgebung du testest – inklusive der Testdaten.
Beispiel: „Die Tests erfolgen auf einem Testsystem mit Windows 11, aktuellem Browser und einer Kopie der Produktionsdatenbank mit anonymisierten Testdaten."
Testdaten dokumentieren:
- Quelle: Produktionsdaten-Kopie, synthetische Testdaten oder Seed-Daten aus Testframework.
- Anonymisierung: Bei personenbezogenen Daten: Namen, E-Mails und andere identifizierende Merkmale durch Platzhalter ersetzen (DSGVO).
- Reproduzierbarkeit: Datensatzgröße (z. B. „100 Testdatensätze"), Version/Seed angeben, damit Tests wiederholbar sind.
Im Produktivsystem testen. Nutze immer eine separate Testumgebung mit Testdaten.
Du definierst, wann die Tests als bestanden gelten. Die konkreten Schwellwerte hängen von Prüfungsordnung, Auftraggeber und Projektrisiko ab – folgende Werte sind Richtwerte.
Beispiel (Richtwert): „Alle Testfälle mit Priorität 1 müssen bestanden sein. Bei Testfällen mit Priorität 2 sind offene Punkte akzeptabel, sofern Workarounds existieren und ein Fix-Termin definiert ist."
Entscheidungslogik für offene Punkte:
- Severity: Kritisch (blockiert Kernfunktion), Hoch (wichtige Funktion betroffen), Mittel (Workaround möglich), Niedrig (kosmetisch).
- Workaround: Gibt es eine alternative Lösung, bis der Fehler behoben ist? Dokumentieren.
- Retest-Termin: Wann wird der behobene Fehler erneut getestet? Festlegen und nachverfolgen.
- Akzeptanz-Check: P2 offen lassen nur, wenn: Workaround existiert UND Fix terminiert UND kein Risiko für Datenverlust/Sicherheit.
Keine messbaren Kriterien. „Das System soll zufriedenstellend laufen" ist nicht prüfbar.
Welche Testfälle nehme ich?
Du kannst nicht alles testen. Die Kunst liegt darin, die richtigen Testfälle auszuwählen. Dieser Schnellcheck hilft dir, aus deinen Anforderungen sinnvolle Testfälle abzuleiten.
- Kernprozesse (Happy Path): Was ist der häufigste Standardablauf? → Mindestens 2 bis 3 Testfälle
- Kritische Anforderungen: Welche Funktionen sind geschäftskritisch oder wurden explizit gefordert? → Je 1 Testfall
- Risiken: Wo droht Datenverlust, Sicherheitslücke oder Systemabsturz? → Je 1 Testfall
- Häufige Fehlerquellen: Wo treten erfahrungsgemäß Probleme auf? → 1 bis 2 Testfälle
- Grenzwerte: Was passiert bei Minimal- und Maximalwerten? → 1 bis 2 Testfälle
- Negativfälle: Was passiert bei Fehleingaben? → Mindestens 1 Testfall
Beispiel: Aus der Anforderung „Benutzer kann sich mit E-Mail und Passwort anmelden" leitest du ab: TC-LOGIN-001 (korrekter Login), TC-LOGIN-002 (falsches Passwort), TC-LOGIN-003 (leere Felder), TC-LOGIN-004 (gesperrter Account nach 3 Fehlversuchen).
Testfälle richtig formulieren
Ein Testfall beschreibt einen einzelnen Test so präzise, dass ihn jemand anderes wiederholen könnte. Er besteht aus einer eindeutigen ID, einer Beschreibung, Vorbedingungen, konkreten Schritten und dem erwarteten Ergebnis.
Die ID ist eine eindeutige Nummer, mit der du den Testfall im Protokoll referenzierst. Nutze ein Schema wie TC-001, TC-002 oder gruppiere nach Funktionsbereichen: TC-LOGIN-001, TC-EXPORT-001.
Die Beschreibung fasst in einem Satz zusammen, was der Test prüft. Sie sollte so präzise sein, dass du beim Lesen sofort weißt, worum es geht. Vermeide vage Formulierungen wie „Funktion testen".
Die Vorbedingungen beschreiben den Ausgangszustand. Was muss gegeben sein, damit der Test starten kann? Beispiel: „Benutzer ist eingeloggt. Im Warenkorb liegt mindestens ein Artikel." Ohne klare Vorbedingungen sind Tests nicht reproduzierbar.
Die Testschritte beschreiben die einzelnen Aktionen. Nummeriere sie und formuliere imperativ: „1. Menüpunkt Einstellungen öffnen. 2. Passwort-Feld anklicken. 3. Neues Passwort eingeben." Je präziser die Schritte, desto weniger Interpretationsspielraum.
Das erwartete Ergebnis beschreibt, was nach dem letzten Schritt passieren soll. Formuliere es so konkret wie möglich: „Erfolgsmeldung ‚Passwort geändert' wird angezeigt. Bei erneutem Login wird das neue Passwort akzeptiert."
Ein guter Testfall prüft genau eine Sache. Wenn ein Test fehlschlägt, weißt du sofort, wo das Problem liegt. Kombinierst du mehrere Prüfungen in einem Testfall, wird die Fehlersuche schwieriger. Teile komplexe Abläufe lieber in mehrere Testfälle auf.
Testfallkategorien in der Projektarbeit
In der Projektarbeit solltest du verschiedene Arten von Tests dokumentieren. Das zeigt Prüfenden, dass du unterschiedliche Szenarien bedenkst und nicht nur den Idealfall testest.
Funktionale Tests prüfen, ob eine Funktion das tut, was sie soll. Sie bilden den Kern deiner Testfälle und orientieren sich an den Anforderungen aus dem Pflichtenheft. Beispiel: „Benutzer kann sich mit korrekten Zugangsdaten einloggen."
Grenzfalltests prüfen das Verhalten an den Rändern des erlaubten Bereichs. Was passiert bei sehr langen Eingaben? Bei leeren Feldern? Bei der maximalen Anzahl von Einträgen? Diese Tests finden oft Fehler, die im Normalbetrieb verborgen bleiben.
Negativtests prüfen, ob das System Fehleingaben korrekt behandelt. Sie sind das Gegenstück zu funktionalen Tests: Statt zu prüfen, ob etwas funktioniert, prüfst du, ob das System richtig reagiert, wenn etwas schiefgeht. Beispiel: „Fehlermeldung bei ungültigem Passwort."
Nicht-funktionale Tests prüfen Qualitätseigenschaften wie Performance, Sicherheit oder Benutzerfreundlichkeit. Sie werden oft vergessen, sind aber für ein vollständiges Testkonzept wichtig. Wähle ein bis zwei Aspekte, die für dein Projekt kritisch sind.
Performance: „Ladezeit der Übersichtsseite bei 100 Datensätzen unter 2 Sekunden."
Sicherheit: „SQL-Injection im Suchfeld wird abgefangen, keine Fehlermeldung mit Datenbankdetails."
Browser-Kompatibilität: „Anwendung funktioniert in Chrome, Firefox und Edge ohne Darstellungsfehler."
Datenintegrität: „Nach Abbruch während des Speicherns sind keine inkonsistenten Daten in der Datenbank."
Usability: „Fehlermeldungen sind verständlich und zeigen, wie der Fehler behoben werden kann."
TC-PERF-001: Ladezeit Übersichtsseite
Ladezeit bei 100 Datensätzen
Vorbedingung
Testdatenbank enthält exakt 100 Datensätze. Browser-Cache ist geleert. Netzwerk-Throttling deaktiviert. Gleiche Testbedingungen: lokaler Rechner, Chrome-Browser.
Schritte
- Browser-Entwicklertools öffnen (Netzwerk-Tab).
- „Disable cache" aktivieren.
- Übersichtsseite aufrufen.
- Ladezeit bis zum DOMContentLoaded-Event ablesen.
- Test dreimal wiederholen und Durchschnitt bilden.
Erwartetes Ergebnis
Durchschnittliche Ladezeit liegt unter 2 Sekunden. Alle 100 Datensätze werden korrekt angezeigt.
Hinweis: Messwerte sind umgebungsabhängig. Dokumentiere Gerät, Browser und Netzwerk, damit die Messung reproduzierbar ist. Alternative Messpunkte: Load, TTFB, LCP.
Für eine IHK-Projektarbeit mit 8 bis 10 Testfällen könnte die Verteilung so aussehen:
- 4 funktionale Tests für die Kernfunktionen
- 2 Grenzfalltests für kritische Eingabefelder
- 2 Negativtests für typische Fehleingaben
- 1 bis 2 nicht-funktionale Tests (je nach Projekttyp)
Testebenen in der Projektarbeit
In der Softwareentwicklung unterscheidet man verschiedene Testebenen. Für die Projektarbeit ist wichtig zu wissen, welche davon realistisch sind und was du dokumentieren solltest.
Unit-Tests: Prüfen einzelne Funktionen/Methoden. Bei Entwicklungsprojekten sinnvoll, aber nicht zwingend für die Doku. Erwähne sie kurz, falls vorhanden.
Integrationstests: Prüfen das Zusammenspiel von Komponenten (z. B. Schnittstellen). Relevant bei Projekten mit mehreren Systemen.
Systemtests: Prüfen das Gesamtsystem aus Nutzersicht. Hier dokumentierst du am ausführlichsten, da dies die meisten Projektarbeiten betrifft.
Abnahmetests: Prüfung durch den Auftraggeber. Dokumentiere das Ergebnis im Abnahmeprotokoll.
Für die meisten Projektarbeiten gilt: Fokussiere dich auf Systemtests (manuelle Tests aus Nutzersicht). Wenn du automatisierte Unit- oder Integrationstests hast, erwähne sie im Testkonzept und zeige ein Beispiel. Prüfende schätzen das, erwarten es aber nicht zwingend.
Anforderungen und Testfälle verknüpfen
Eine Traceability-Matrix zeigt auf einen Blick, welche Testfälle welche Anforderungen abdecken. Das hebt deine Projektarbeit positiv hervor, weil Prüfende sofort sehen, dass du methodisch vorgehst.
| Anforderung | Testfall-IDs | Status |
|---|---|---|
| ANF-001: Login | TC-LOGIN-001, TC-002 | Bestanden |
| ANF-002: Datenexport | TC-EXPORT-001, TC-003 | Bestanden |
| ANF-003: Bericht | TC-REPORT-001 | Bestanden |
Bei kleineren Projekten reicht auch ein Verweis im Testfall selbst: „Prüft Anforderung ANF-001". Die vollständige Matrix kannst du in den Anhang auslagern.
Testprotokoll erstellen
Das Testprotokoll ist der Nachweis, dass du tatsächlich getestet hast. Pro Testfall dokumentierst du: ID, Datum, tatsächliches Ergebnis und Status (bestanden, fehlgeschlagen, blockiert).
Bei fehlgeschlagenen Tests ergänzt du eine Fehlerbeschreibung und dokumentierst, wie du den Fehler behoben hast. Prüfende schätzen diese Transparenz. Ein Projekt ohne gefundene Fehler wirkt unglaubwürdig.
Du kannst das Testprotokoll als Tabelle im Hauptteil zeigen oder eine Zusammenfassung im Text schreiben und die vollständige Tabelle in den Anhang auslagern.
Testkonzept Beispiele
Hier siehst du konkrete Beispiele für Testfälle aus verschiedenen Projekttypen. Achte darauf, wie jeder Testfall alle Elemente enthält und präzise formuliert ist.
TC-LOGIN-001: Login-Funktion
Test mit korrekten Zugangsdaten
Vorbedingung
Benutzer ist nicht eingeloggt. Testbenutzer „test@firma.de" existiert.
Schritte
- Login-Seite aufrufen.
- E-Mail „test@firma.de" eingeben.
- Passwort „Test123!" eingeben.
- Button „Anmelden" klicken.
Erwartetes Ergebnis
Weiterleitung zum Dashboard. Benutzername wird in Navigation angezeigt.
TC-EXPORT-003: CSV-Export
Export mit Sonderzeichen
Vorbedingung
Mindestens ein Datensatz enthält Umlaute und Semikolons.
Schritte
- Datenübersicht öffnen.
- Datensätze mit Sonderzeichen markieren.
- Export-Funktion auswählen (Format CSV).
- Export starten.
Erwartetes Ergebnis
CSV-Datei erstellt. Umlaute korrekt. Semikolons in Textfeldern escaped.
TC-LOGIN-005: Falsches Passwort
Prüfung der Fehlerbehandlung
Vorbedingung
Benutzer ist nicht eingeloggt. Testbenutzer existiert.
Schritte
- Login-Seite aufrufen.
- Korrekte E-Mail eingeben.
- Falsches Passwort eingeben.
- Button „Anmelden" klicken.
Erwartetes Ergebnis
Fehlermeldung „Zugangsdaten ungültig" erscheint. Passwortfeld geleert.
Vorlage zum Kopieren
Diese Vorlagen kannst du direkt in Word oder Excel übernehmen. Ersetze die Platzhalter in eckigen Klammern durch deine Inhalte.
| Testziele | Die Tests sollen sicherstellen, dass [Funktionen] korrekt umgesetzt sind und [Qualitätskriterium] erfüllt wird. |
| Testumfang | Getestet: [Funktionen]. Nicht getestet: [Ausnahmen] (Begründung: [Grund]). |
| Testumgebung | [System], [Browser/Software], [Testdaten-Quelle]. |
| Abnahmekriterien | Alle Testfälle Priorität 1 bestanden. Max. [X] offene Punkte bei Priorität 2. |
| ID | Beschreibung | Vorbedingung | Schritte | Ergebnis |
|---|---|---|---|---|
| TC-[XX]-001 | [Was wird getestet] | [Ausgangszustand] | 1. [Aktion] 2. [Aktion] | [Messbares Ergebnis] |
Tipp: Ergänze Spalten für „Priorität" und „Anforderung" (ANF-ID), um Traceability zu zeigen.
| ID | Datum | Ergebnis (IST) | Status | Bemerkung |
|---|---|---|---|---|
| TC-LOGIN-001 | [Datum] | [Was passiert ist] | Bestanden | [Analyse / Lösung] |
Typische Fehler vermeiden
Zu vage Testfälle: Formulierungen wie „Funktion testen" oder „System prüfen" sind nicht nachvollziehbar. Schreibe so präzise, dass jemand anderes den Test wiederholen könnte.
Schwach: „Login testen."
Besser: „Login mit korrekten Zugangsdaten: E-Mail und Passwort eingeben, Weiterleitung
zum Dashboard prüfen."
Nur Positivtests: Wenn du nur testest, ob etwas funktioniert, fehlt die Hälfte. Prüfe auch, was passiert, wenn Eingaben falsch sind oder Grenzwerte erreicht werden.
Schwach: Alle Tests zeigen erfolgreiche Abläufe.
Besser: Mix aus funktionalen Tests, Grenzfalltests und Negativtests.
Keine Abnahmekriterien: Ohne klare Kriterien weiß niemand, wann die Tests abgeschlossen sind. Definiere vorab, welche Tests bestanden sein müssen.
Schwach: „Das System sollte funktionieren."
Besser: „Alle Testfälle mit Priorität 1 müssen bestanden sein."
Testprotokoll fehlt: Das Testkonzept allein zeigt nur die Planung. Ohne Protokoll wissen Prüfende nicht, ob du tatsächlich getestet hast und wie die Ergebnisse waren.
Nächster Schritt: Vom Test zur Abnahme
Dein Testkonzept ist fertig, wenn Testziele, Testumfang, Testumgebung und Abnahmekriterien definiert sind. Deine Testfälle sind vollständig, wenn jeder Testfall ID, Beschreibung, Vorbedingungen, Schritte und erwartetes Ergebnis enthält.
- 1. Testfälle priorisieren: Kennzeichne kritische Tests mit Priorität 1.
- 2. Tests durchführen: Arbeite die Testfälle systematisch ab.
- 3. Protokoll führen: Dokumentiere Ergebnisse, Fehler und Lösungen.
- 4. Abnahme vorbereiten: Prüfe, ob alle Abnahmekriterien erfüllt sind.
Nach erfolgreichen Tests folgt die Abnahme durch den Auftraggeber. Das Abnahmeprotokoll dokumentiert, dass die Lösung den Anforderungen entspricht und vom Auftraggeber akzeptiert wird.
In der Dokumentation beschreibst du im Fazit, wie die Tests verlaufen sind und ob die Abnahmekriterien erfüllt wurden. In der Reflexion kannst du beschreiben, was du über Qualitätssicherung gelernt hast.
Abgabe vorbereiten: Prüfe die formalen Anforderungen deiner Prüfungsordnung. Bei IHK-Projektarbeiten sind oft Seitenumfang und Anhänge genau vorgegeben. Ein Blick auf Gliederung und Inhaltsverzeichnis hilft, nichts zu vergessen.
Häufig gestellte Fragen
Wie umfangreich sollte das Testkonzept in der Projektarbeit sein?
Der Umfang hängt von der Projektgröße und den Vorgaben ab. Bei IHK-Projektarbeiten reichen typischerweise ein bis zwei Seiten für das Konzept plus fünf bis zehn dokumentierte Testfälle. Wichtiger als die Länge ist, dass du zeigst, dass du systematisch getestet hast.
Wie priorisiere ich Testfälle und was muss zwingend bestanden sein?
Nutze drei Prioritätsstufen (Richtwert – konkrete Vorgaben variieren je nach Prüfungsordnung und Auftraggeber): P1 (kritisch) = Kernfunktionen, die für die Abnahme bestanden sein müssen. P2 (wichtig) = Funktionen, bei denen offene Punkte mit Workaround akzeptabel sein können. P3 (nice-to-have) = Optimierungen, die nicht abnahmeentscheidend sind. Entscheidungslogik P2: Offener Punkt akzeptabel, wenn Workaround existiert UND Fix-Termin definiert ist UND Risiko niedrig (kein Datenverlust, keine Sicherheitslücke).
Was zeige ich im Hauptteil und was kommt in den Anhang?
Hauptteil: Testkonzept (Ziele, Umfang, Kriterien), 3–5 repräsentative Testfälle als Beispiele, Zusammenfassung der Testergebnisse. Anhang: Vollständige Testfall-Tabelle, detailliertes Testprotokoll, Screenshots von Testergebnissen, Traceability-Matrix. Im Hauptteil verweist du auf den Anhang („siehe Anhang A3").
Wie dokumentiere ich Testdaten und Anonymisierung?
Beschreibe kurz die Testdaten-Quelle (z. B. „Kopie der Produktionsdatenbank mit anonymisierten Kundendaten" oder „synthetische Testdaten"). Bei personenbezogenen Daten: Erwähne, dass Namen, E-Mails und andere identifizierende Merkmale durch Platzhalter ersetzt wurden. Ein Satz genügt: „Die Testdaten wurden gemäß DSGVO anonymisiert, personenbezogene Daten durch fiktive Werte ersetzt."
Welches Format ist am sinnvollsten für Testfälle?
Eine Tabelle in Word oder Excel ist am praktischsten. Spalten: ID, Beschreibung, Vorbedingung, Schritte, erwartetes Ergebnis, Status. Im Hauptteil zeigst du die wichtigsten Testfälle. Die vollständige Tabelle kannst du in den Anhang auslagern und im Text darauf verweisen.
Wie viele Testfälle sollte ich in der Projektarbeit zeigen?
Bei einer IHK-Projektarbeit sind fünf bis zehn dokumentierte Testfälle typisch. Wähle Testfälle, die verschiedene Kategorien abdecken: Standardabläufe, Grenzfälle, Fehlerbehandlung, mindestens ein nicht-funktionaler Test. Zeige lieber wenige aussagekräftige Tests als eine lange Liste oberflächlicher Prüfungen.
Muss ich jeden Testfall einzeln dokumentieren?
Nein, nicht jeden Testfall vollständig im Hauptteil. Daumenregel: Im Hauptteil zeigst du 3–5 repräsentative Testfälle ausführlich (verschiedene Kategorien: funktional, Grenzfall, Negativtest). Die vollständige Testfall-Tabelle mit allen Tests kommt in den Anhang. Im Text verweist du darauf: „Die vollständige Testfall-Übersicht befindet sich in Anhang A3." Das hält den Hauptteil lesbar und zeigt trotzdem Vollständigkeit.
Was mache ich, wenn Tests fehlschlagen?
Dokumentiere fehlgeschlagene Tests ehrlich. Beschreibe das Problem, deine Analyse und wie du es behoben hast. Prüfende schätzen diese Transparenz, weil sie echte Projektarbeit zeigt. Ein Projekt ohne gefundene Fehler wirkt unglaubwürdig.
Wie gehe ich mit offenen Fehlern bei der Abnahme um?
Klassifiziere jeden offenen Fehler nach Severity (kritisch/hoch/mittel/niedrig). Dokumentiere, ob ein Workaround existiert. Lege einen Retest-Termin fest. Kritische Fehler ohne Workaround blockieren die Abnahme. Mittlere Fehler mit Workaround können akzeptiert werden, wenn der Fix terminiert ist. Das zeigt professionelles Fehlermanagement.
Wie messe ich Performance-Werte richtig?
Definiere den Messpunkt (z. B. DOMContentLoaded für initiales Rendering, Load für vollständige Seite, TTFB für Serverantwort). Führe mindestens 3 Messungen durch und bilde den Durchschnitt. Dokumentiere die Testbedingungen (Gerät, Browser, Netzwerk), da Messwerte umgebungsabhängig sind. Nutze Browser-Entwicklertools oder Lighthouse für reproduzierbare Ergebnisse.
Weitere interessante Artikel 
Gliederung der Projektarbeit 
Plagiate vermeiden 
Projektarbeit schreiben: Aufbau und Tipps