#agiletest

Ihr nutzt ChatGPT oder Claude in euren Projekten? Ernsthaft? Dann lasst uns mal kurz reden. Nicht über Hype, nicht über „AI-first" und den ganzen Marketing-Bullshit – sondern über das, was in echten Projekten zählt: Datenschutz, Kosten, Kontrolle und Verlässlichkeit. Ich mache seit über 27 Jahren Testing und betone das auch gerne immer und immer wieder! Ich hab jede Welle mitgemacht – von manuellen Testprotokollen auf Papier bis hin zu KI-gestützter Testautomatisierung. Und wenn ich eines gelernt habe, dann das: Die besten Tools sind die, die du kontrollierst. Nicht die, die dich kontrollieren.  

Das Problem mit Claude, ChatGPT & Co. im Projektalltag

Klar, die Cloud-Modelle sind beeindruckend. GPT-5x, Claude 4.5 - 5 – die können Code generieren, Testfälle schreiben, Logs analysieren, und dir flaky Analysen zaubern. Keine Frage. Aber sobald ihr die in einem echten Projekt einsetzt, kommen Probleme, die euch kein Marketing-Bullshit-Bingo-Slide zeigt: 1) Datenschutz – oder: Wie erklärt ihr das eurem Datenschutzbeauftragten? Ihr arbeitet im Healthcare-Bereich? Im Government-Umfeld? Für Behörden? Dann wisst ihr: DSGVO ist kein Vorschlag. Und die Frage „Wo landen meine Daten?" ist nicht akademisch, sondern existenziell. https://www.youtube.com/watch?v=mros_5UuaZw Wenn ihr Testdaten, Fehlermeldungen, Logfiles oder Spezifikationen an die OpenAI-API schickt, dann verlassen diese Daten euer Netzwerk. Punkt. Egal was in den Terms steht – eure Compliance-Abteilung wird euch den Kopf abreißen. Und das zu Recht. Ich hab in Government-Healthcare-Projekten gearbeitet. Versucht mal, eurem Auftraggeber zu erklären, dass Patientendaten „nur kurz" über eine US-Cloud laufen. Viel Spaß dabei. 2) Kosten – der schleichende Tod eures Budgets Am Anfang ist alles billig. Ein paar API-Calls hier, ein bisschen GPT-5 dort. Und dann kommt die Rechnung. Rechnet mal durch: Wenn ihr ernsthaft KI-gestützt testet – also nicht nur mal eben „schreib mir einen Testfall", sondern systematisch Logs analysiert, Testcode generiert, Fehlerberichte auswerten lasst – dann reden wir schnell über tausende API-Calls pro Tag. Bei GPT-4 oder Claude Opus sind das Kosten, die sich gewaschen haben. Und das Beste: Die Preise können sich jederzeit ändern. Euer Budget nicht. 3) Verfügbarkeit – wenn die Cloud hustet, steht euer Testing still Ihr kennt das: Deadline, Regression-Suite muss laufen, und dann – „OpenAI API rate limit exceeded" oder „Service temporarily unavailable". Passiert. Regelmäßig. Und genau dann, wenn ihr es am wenigsten braucht. Eure CI/CD-Pipeline hängt an einem externen Service, den ihr nicht kontrolliert? Das ist kein Engineering. Das ist Glücksspiel. 4) Latenz – jeder Millisekunde zählt in der Pipeline Cloud-API-Calls haben Latenz. Netzwerk-Roundtrip, Queueing, Processing. Wenn ihr KI in eure Testpipeline integriert, summiert sich das. Bei einer Suite mit 500 Tests, die jeweils einen LLM-Call machen, könnt ihr mal locker 20-30 Minuten auf reine Wartezeit draufschlagen. Lokal? Sekunden.

5) Vendor Lock-in – der goldene Käfig

Heute OpenAI, morgen Preiserhöhung, übermorgen „wir ändern unsere API". Und ihr dürft dann alles umbauen. Oder ihr seid halt abhängig. Für immer. Von einem Unternehmen in San Francisco, das gerade mal ein paar Jahre alt ist.

Die Alternative: Ollama – KI die bei euch bleibt

Und jetzt kommt der Teil, wo es spannend wird.

Ollama ist ein Tool, das euch erlaubt, Open-Source-LLMs lokal zu betreiben. Auf eurem Rechner. Auf eurem Server. Ohne Cloud. Ohne API-Keys. Ohne Datenschutz-Diskussionen.

Was Ollama kann Modelle lokal ausführen: Llama 3, Mistral, CodeLlama, Phi-3, Gemma, DeepSeek-Coder (nur privat alles andere siehe Datenschutz) – alles läuft auf eurer Hardware REST-API: Kompatibel mit dem OpenAI-API-Format – ihr könnt bestehenden Code oft 1:1 umstellen Kein Internet nötig: Einmal Modell runtergeladen, läuft das Ding auch im Flugzeug oder hinter der Firmen-Firewall Ressourcenschonend: Modelle wie Phi-3 Mini oder Mistral 7B laufen auf einer halbwegs aktuellen Grafikkarte oder sogar auf der CPU. Kein A100-Cluster nötig Kostenlos: Open Source. Keine Lizenzgebühren. Keine Token-Kosten Hardware-Realität Und jetzt kommt das, was die ganzen Cloud-Evangelisten nie erwähnen: Ihr braucht keine Monster-Hardware. | Modell | RAM/VRAM | Qualität für Testing | Geschwindigkeit | |--------|----------|---------------------|-----------------| | Phi-3 Mini (3.8B) | 4 GB | Gut für einfache Tasks | Sehr schnell | | Mistral 7B | 8 GB | Sehr gut für Codeanalyse | Schnell | | CodeLlama 7B | 8 GB | Top für Codegenerierung | Schnell | | Llama 3 8B | 8 GB | Allrounder | Schnell | | DeepSeek-Coder 6.7B | 8 GB | Exzellent für Code | Schnell | | Mixtral 8x7B | 32 GB | Premium-Qualität | Moderat | | Llama 3 70B | 48 GB+ | Nahe GPT-4-Niveau | Langsamer |  

Konkret: Was könnt ihr mit Ollama im Testing machen?

Jetzt wird's praktisch. Hier sind die Use-Cases, die ich in meinen privaten Projekten tatsächlich einsetze – nicht Theorie, sondern Praxis. Ich lasse Ollama und QWEN erst die spezifikationen meiner Projekte erarbeiten und dann entsprechend dieser spezifikation lasse ich dann entwickeln.

p.s. Falls ihr mal nach Thailand wollt unnd Motorräder braucht, hier der Shop meines sehr guten Freundes Randy, den ich zum testen meiner Funktionen im Test und Ai nutzen darf: https://www.aubanan-samui.shop/   1) Testfall-Generierung aus Spezifikationen

Ihr habt eine Spezifikation und braucht Testfälle? Statt die manuell rauszuziehen, lasst ihr das LLM arbeiten.

import requests import json def generate_testcases(specification: str, model: str = "mistral") -> str: """Generiert Testfälle aus einer Spezifikation via Ollama.""" prompt = f"""Du bist ein erfahrener Senior Test Engineer. Analysiere die folgende Spezifikation und erstelle daraus strukturierte Testfälle im Format: - Testfall-ID - Vorbedingung - Schritte - Erwartetes Ergebnis - Priorität (Hoch/Mittel/Niedrig) Berücksichtige dabei: - Positive und negative Testfälle - Grenzwerte - Edge-Cases - Fehlerszenarien Spezifikation: {specification} """ response = requests.post( "http://localhost:11434/api/generate", json={ "model": model, "prompt": prompt, "stream": False, "options": { "temperature": 0.3, # Niedrig für konsistente Ergebnisse "num_predict": 2048 } } ) return response.json() # Beispiel spec = """ Login-Funktion: - Benutzer gibt E-Mail und Passwort ein - Nach 3 Fehlversuchen wird der Account für 30 Minuten gesperrt - Passwort muss mindestens 8 Zeichen, einen Großbuchstaben und eine Zahl enthalten - Session-Timeout nach 30 Minuten Inaktivität """ testcases = generate_testcases(spec) print(testcases) Das ist kein Hexenwerk. Und das Ergebnis? Nicht perfekt – aber ein verdammt guter Startpunkt, den ihr in 10 Minuten reviewen und anpassen könnt, statt 2 Stunden von Null anzufangen.   2) Intelligente Fehleranalyse – Log-Parsing mit Verstand

Ihr habt einen Stack-Trace, eine Fehlermeldung, ein Logfile – und wollt verstehen, was da passiert ist? Das LLM kann euch den Kontext liefern.

def analyze_error(error_log: str, source_context: str = "", model: str = "llama3") -> str: """Analysiert Fehlermeldungen und gibt Lösungsvorschläge.""" prompt = f"""Du bist ein erfahrener Debugging-Experte. Analysiere den folgenden Fehler und liefere: 1. Root-Cause-Analyse: Was ist die wahrscheinlichste Ursache? 2. Betroffene Komponenten: Welche Teile des Systems sind betroffen? 3. Lösungsvorschlag: Konkreter Fix oder Workaround 4. Regressions-Risiko: Was könnte bei der Behebung kaputt gehen? Fehler: {error_log} {"Quellcode-Kontext:" + source_context if source_context else ""} """ response = requests.post( "http://localhost:11434/api/generate", json={ "model": model, "prompt": prompt, "stream": False, "options": {"temperature": 0.2} } ) return response.json() # Praxis-Beispiel error = """ selenium.common.exceptions.StaleElementReferenceException: Message: stale element reference: stale element not found at test_login.py:47 -> element.click() Previous action: page.wait_for_selector("#submit-btn") Test: test_login_with_valid_credentials Run: 3 of 10 failed (flaky) """ analysis = analyze_error(error) print(analysis) Das LLM erkennt sofort: StaleElementReference → DOM hat sich zwischen Finden und Klicken geändert → wahrscheinlich ein AJAX-Reload → Lösung: wait_for statt statischen Selektor. Und das alles lokal, ohne dass euer Fehler-Log bei irgendeinem Cloud-Anbieter landet. 3) Testcode-Generierung für pytest + Playwright Hier wird's richtig spannend. Ihr gebt dem LLM eine Page-Beschreibung und bekommt pytest-Code zurück. def generate_playwright_test( page_description: str, framework: str = "pytest-playwright", model: str = "deepseek-coder:6.7b" ) -> str: """Generiert Playwright-Testcode aus einer Seitenbeschreibung.""" prompt = f"""Du bist ein Senior Test Automation Engineer. Erstelle einen vollständigen {framework} Test für folgende Seite. Nutze: - pytest mit Playwright - Page Object Model Pattern - Assertions mit expect() - Sinnvolle Wartezeiten (keine time.sleep!) - Deutsche Kommentare Seitenbeschreibung: {page_description} Generiere zuerst die Page Object Klasse, dann die Testklasse. """ response = requests.post( "http://localhost:11434/api/generate", json={ "model": model, "prompt": prompt, "stream": False, "options": { "temperature": 0.2, "num_predict": 4096 } } ) return response.json()

Qwen ist hier besonders stark – das Modell ist speziell auf Code trainiert und liefert sauberen, idiomatischen Python-Code. Lokal. Kostenlos. Ohne Token-Limit.

4) BDD-Szenario-Generierung

Ihr arbeitet mit Behave oder pytest-bdd? Dann lasst euch Gherkin-Szenarien generieren:

def generate_bdd_scenarios( user_story: str, model: str = "mistral" ) -> str: """Generiert BDD-Szenarien aus einer User Story.""" prompt = f"""Du bist ein BDD-Experte. Erstelle aus der folgenden User Story vollständige Gherkin-Szenarien (Feature-File) in Deutsch. Berücksichtige: - Positiv-Szenario (Happy Path) - Mindestens 2 Negativ-Szenarien - Edge-Cases - Szenario-Outline mit Examples wo sinnvoll User Story: {user_story} Ausgabe als vollständiges .feature File. """ response = requests.post( "http://localhost:11434/api/generate", json={ "model": model, "prompt": prompt, "stream": False } ) return response.json() # Beispiel story = """ Als registrierter Benutzer möchte ich mein Passwort zurücksetzen können, damit ich wieder Zugang zu meinem Konto bekomme, wenn ich mein Passwort vergessen habe. Akzeptanzkriterien: - E-Mail mit Reset-Link wird innerhalb von 2 Minuten versendet - Reset-Link ist 24 Stunden gültig - Neues Passwort muss den Passwort-Richtlinien entsprechen - Nach erfolgreichem Reset werden alle aktiven Sessions beendet """ feature = generate_bdd_scenarios(story) print(feature) 5) Testreport-Zusammenfassung – für die, die keine 200 Seiten lesen wollen

Euer Allure-Report hat 500 Tests, 12 davon sind fehlgeschlagen, und der Projektleiter will ein „kurzes Summary". Klar.

def summarize_test_results( test_results: dict, model: str = "llama3" ) -> str: """Erstellt eine Management-taugliche Zusammenfassung der Testergebnisse.""" prompt = f"""Du bist ein Senior QA Lead. Erstelle eine prägnante Zusammenfassung der folgenden Testergebnisse. Struktur: - Executive Summary (3 Sätze) - Kritische Fehler (mit Handlungsempfehlung) - Risikobewertung für das nächste Release - Empfohlene Maßnahmen Testergebnisse: {json.dumps(test_results, indent=2, ensure_ascii=False)} """ response = requests.post( "http://localhost:11434/api/generate", json={ "model": model, "prompt": prompt, "stream": False } ) return response.json() 6) API-Test-Generierung aus OpenAPI-Specs Ihr habt eine Swagger/OpenAPI-Spec? Daraus lassen sich automatisiert pytest-Tests generieren: def generate_api_tests( openapi_spec: str, endpoint: str, model: str = "deepseek-coder:6.7b" ) -> str: """Generiert API-Tests aus einer OpenAPI-Spezifikation.""" prompt = f"""Du bist ein API-Testing-Experte. Generiere vollständige pytest-Tests für den folgenden API-Endpoint. Nutze: - requests oder httpx - Parametrisierte Tests (@pytest.mark.parametrize) - Positive Tests (200, 201) - Negative Tests (400, 401, 403, 404, 422) - Boundary-Value-Tests - Schema-Validierung der Response OpenAPI Spec (Auszug): {openapi_spec} Endpoint: {endpoint} """ response = requests.post( "http://localhost:11434/api/generate", json={ "model": model, "prompt": prompt, "stream": False, "options": {"temperature": 0.2, "num_predict": 4096} } ) return response.json() 7) Integration in die CI/CD-Pipeline

Das Schöne an Ollama: Es hat eine REST-API. Das heißt, ihr könnt es direkt in eure Pipeline integrieren. Ollama als Service, der neben Jenkins, GitLab CI oder GitHub Actions läuft.

Der faire Vergleich: Cloud-KI vs. Ollama

Ich bin kein Ideologe. Hier die ehrliche Gegenüberstellung: Kriterium Cloud-KI (GPT-4/5, Claude) Ollama (Lokal) Qualität (Top-Modelle) Exzellent Sehr gut (70B) bis gut (7B) Datenschutz Problematisch bis unmöglich Vollständig unter Kontrolle Kosten (langfristig) Hoch und unvorhersehbar Einmal Hardware, dann 0€ Verfügbarkeit Abhängig vom Provider 100% unter eurer Kontrolle Latenz Netzwerk + Queue + Processing Nur lokale Inferenz Offline-Fähigkeit Nein Ja Compliance (DSGVO) Schwierig bis unmöglich Kein Thema Vendor Lock-in Ja Nein (Open-Source-Modelle) Customizing/Fine-Tuning Begrenzt/teuer Voll möglich Setup-Aufwand Gering (API-Key) Moderat (Installation)

Hört auf, eure Daten zu verschenken

Die Testing-Welt redet gerade über KI, als gäbe es nur OpenAI und Anthropic. Das ist Quatsch. Die Open-Source-Community liefert Modelle, die für unsere Zwecke mehr als ausreichend sind.

Ollama macht den Einsatz so einfach, dass es keine Ausrede mehr gibt.

Ihr wollt:

Testfälle generieren → Ollama + Mistral Fehler analysieren → Ollama + Llama 3 Code scaffolden → Ollama + QWEN BDD-Szenarien schreiben → Ollama + Mistral Reports zusammenfassen → Ollama + Llama 3

Alles lokal. Alles kostenlos. Alles DSGVO-konform. Alles ohne Vendor Lock-in.

Und das Wichtigste: Eure Projektdaten bleiben da, wo sie hingehören – bei euch.

Also: Runter mit der Cloud-Brille, Ollama installieren, und loslegen. Euer Datenschutzbeauftragter wird euch danken. Euer Budget auch. Und eure Tests werden trotzdem besser.

Die Frage hat mich echt zum Nachdenken gebracht, denn sind die manuellen Tester eigentlich auf Dauer gesehen überflüssig? Muss man ein technischer Tester werden, um seinen Arbeitsplatz in der Softwarebranche zu retten? Werden manuelle Tester in Zukunft ihren Wert und ihren Arbeitsplatz verlieren, wenn sie nicht bald zur Automatisierung übergehen?  

Testautomatisierung kann manuelle Tests NIEMALS ersetzen.