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 analysien 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.
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:
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()["response"]
# 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()["response"]
# 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()["response"]
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()["response"]
# 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()["response"]
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()["response"]
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.
Quellen:
https://github.com/ollama/ollama
https://github.com/deepseek-ai/DeepSeek-Coder
Neueste Kommentare