Jeder bestätigte Befund wird behoben, auch die kleinen
Jeder Befund zählt, egal wie schwer er ist. Zu jeder Korrektur gehört ein Test, der vorher fehlschlägt und nachher besteht. So ist die Korrektur belegt und bleibt bestehen.
Die Qualitäts- und Sicherheits-Agents sind unser eigenes Werkzeug. Es prüft jeden Build auf einem festen Weg: QA, UX, Sicherheit, Pentest, SEO/AEO, technische Prüfung mit Lighthouse, Code-Review. Jeder bestätigte Befund wird mit einem Test behoben, der vor der Korrektur fehlschlägt und danach besteht. Jeder Fehler bleibt als dauerhafter Test erhalten.
Eigenes Produkt
| Branche | Interne Werkzeuge und Plattformen |
|---|---|
| Herausforderung | Verantwortung |
| Entscheidungsumfeld | Produktbewertung |
| Komplexität | Hoch |
| Leistung | Plattform |
Sie fragen sich vielleicht, warum eine Website oder Plattform von iwebforyou nicht einfach so ausgeliefert wird, wie sie entsteht. Die Antwort steht hier: Jedes Projekt durchläuft dieselbe Prüfung, bevor es zu Ihnen kommt. Die Tabelle zeigt, was jeder Agent prüft und wann er läuft. Der Text erklärt, was das für den Kunden bedeutet.
Agent | Was er prüft | Läuft |
|---|---|---|
SEO/AEO | Ob Seiten von Such- und Antwortmaschinen gefunden und zitiert werden (Websites) | Einmal |
Technische Prüfung | Die Qualität der Seiten mit Lighthouse (Websites) | Einmal |
Code-Review | Den Code des verwendeten Frameworks, auf Korrektheit | Bis zu 2 Runden |
UX | Wie die Seiten für einen Menschen funktionieren | Einmal |
Sicherheit | Die Schwachstellen der Anwendung | Bis zu 3 Runden |
Pentest | Ein simulierter Angriff, der zeigt, was ein echter Angreifer tun würde (Plattformen oder Sites mit Shop oder Buchungen) | Bis zu 2 Runden |
QA | Die ganze Anwendung, so wie ein Kunde sie benutzen würde | Bis zu 2 Runden |
Unsere Builds erzeugt der Planner. Jede Funktion besteht schon ihre eigenen Tests, bevor sie angenommen wird. Die Funktionen müssen aber auch alle zusammen richtig arbeiten. Eine Seite, die allein funktioniert, kann gestört werden, wenn eine andere hinzukommt. Ein Formular, das für sich sicher ist, kann von einer anderen Stelle aus erreichbar sein.
Deshalb folgt nach der Freigabe des Builds eine zweite Stufe, die bewusst von der ersten getrennt ist. Die Agents haben den Code nicht geschrieben. Ihre Aufgabe ist, ihn kritisch anzusehen.
Diese Stufe gibt dem Wort „geprüft“ in unserer Arbeit sein Gewicht. Kunden sehen sie selten. Deshalb beschreiben wir sie hier ausführlich.
Jede Prüfung sieht nur, wonach sie suchen soll. Ein Sicherheitsscan findet Schwachstellen, aber kein verwirrendes Formular. Eine optische Prüfung beurteilt das Aussehen, aber keinen ungeschützten Endpunkt. Ein Tester, der die Anwendung gut kennt, stolpert nicht dort, wo ein neuer Besucher stolpern würde. Das ganze Bild braucht viele verschiedene Prüfungen.
Das zweite Thema ist, was nach einem Befund geschieht. Ein Problem ist erst dann endgültig behoben, wenn auch festgehalten ist, wie man es gefunden hat. Ein Befund mit Test bleibt gelöst, denn der Test bewacht ihn von da an.
Es gibt drei Rahmenbedingungen. Der Weg muss ein klares Ende haben. Darum beendet jeder Agent seine Runden und schließt ab. Jeder Befund wird festgehalten und bekommt eine Entscheidung, bevor der Build weitergeht: Er wird entweder behoben oder bewusst akzeptiert, mit schriftlicher Begründung. Die Arbeit hinterlässt keine Testdaten in den echten Inhalten.
Das CMS ist ein Sonderfall. Innerhalb einer Website ist es nur lesbar. Ein Befund im CMS selbst wird als solcher festgehalten und in seinem eigenen Repository behoben. So erreicht die Korrektur alle Websites und nicht nur eine.
Die Grenzen stehen im Code: 5 Sessions pro Aufgabe, 3 Reparaturen des Qualitätstors, 3 Versuche pro Runde. Erreicht ein Thema eine Grenze, geht es zur Entscheidung an den Projektverantwortlichen, und die Ausführung läuft weiter.
Der erste Punkt ist, was nach dem Bericht geschieht. Ein langer Bericht hat nur Wert, wenn jeder Befund eine Entscheidung bekommt. Deshalb bleibt kein Befund mit dem Etikett „muss geprüft werden“ liegen. Die Notizen zu dem, was ein Agent nicht abgedeckt hat, werden ebenfalls gelesen. Sie können die wichtigste Zeile des Berichts sein.
Der zweite Punkt sind Kreisläufe. Ändert ein Agent Code und startet deshalb ein anderer neu, braucht der Weg ein klares Ende. Feste Runden sorgen dafür.
Der dritte Punkt ist die Bestätigung. Meldet ein Scanner ein „mögliches Problem“, wird zuerst geprüft, ob das Problem echt ist. Erst dann wird entschieden, ob es behoben oder verworfen wird.
Der Weg ist in jedem Projekt gleich. Jeder Agent läuft einmal, in fester Reihenfolge und mit einer festgelegten Zahl von Runden. Eine zweite Runde läuft nur, wenn die erste etwas korrigiert hat. Die nummerierte Liste gibt die Reihenfolge, die Tabelle oben zeigt, was jeder prüft.
SEO/AEO und technische Prüfung (Lighthouse), für Websites.
Code-Review, mit einer zweiten Runde nur für die Korrekturen der ersten.
UX. Gestalterische Befunde werden zu Vorschlägen in einer eigenen Datei und warten auf die Freigabe des Verantwortlichen, statt automatisch umgesetzt zu werden.
Sicherheit in bis zu drei Runden (Prüfkatalog, dann offene Suche, dann aktualisierter Katalog). Pentest in bis zu zwei Runden, für Plattformen oder Sites mit Shop oder Buchungen.
QA in zwei Runden über die ganze Anwendung. Eine einfache Informationsseite bekommt eine leichte QA. Eine Site mit Shop oder Buchungen bekommt eine intensive QA, die sie absichtlich zu „brechen“ versucht.
Das Backlog wird zu Vorschlägen (Dokumentation und Refactoring, nur als Vorschläge).
Abschließende Sicherheitsprüfung, und Pentest wo nötig, einmal, für die Änderungen aus Schritt 4. Der Agent behebt, was er findet, und hört dann auf, auch bei Befunden der Stufe Critical oder High.
Ein vollständiger Lauf des Qualitätstors, mit E2E-Tests. In den Zwischenschritten läuft nur das schnelle Tor.
Berichte.
Lighthouse, das bei der technischen Prüfung eingesetzt wird, ist ein automatisches Open-Source-Werkzeug. Es misst die Qualität einer Seite bei Leistung, Barrierefreiheit, SEO und bewährten Verfahren (siehe Quellen).
Es gibt sechs wichtige Entscheidungen. Jeder bestätigte Befund wird mit einem Test behoben, jeder Fehler wird zu einem dauerhaften Test, und jeder Befund bekommt eine Entscheidung. Die Notizen zur Abdeckung werden gelesen, der Sicherheitskatalog wächst, und ein Hauptbuch hält den Stand fest. Jede Entscheidung wird unten erklärt.
Jeder Befund zählt, egal wie schwer er ist. Zu jeder Korrektur gehört ein Test, der vorher fehlschlägt und nachher besteht. So ist die Korrektur belegt und bleibt bestehen.
Ein Fehler, den die QA findet, bleibt in einem Ordner mit Regressionstests. Was einmal gefunden wurde, wird von da an bei jedem Build geprüft.
Das Werkzeug prüft jede Behauptung und entscheidet: Es behebt sie oder verwirft sie mit schriftlicher Begründung. Jeder Befund wird mit Belegen bewiesen oder widerlegt.
Die Notizen der Agents zur Abdeckung werden gelesen. Denn die Notiz zu dem, was ein Agent nicht abgedeckt hat, kann die wichtigste Zeile seines Berichts sein.
Die Prüfliste des Sicherheits-Agents wird erweitert, sobald eine neue Art von Schwachstelle auftaucht. So beginnt das nächste Projekt mit dem Wissen des vorigen.
Ein Hauptbuch hält den Stand jedes Befunds fest: mit Commit behoben, verworfen, akzeptiert, an den Verantwortlichen übergeben, offen oder nicht bestätigt.
Das Ergebnis ist ein Build mit einer Spur, der man folgen kann: was jeder Agent geprüft hat, was er gefunden hat, was geändert wurde und welcher Test es jetzt schützt. Für den Kunden heißt das weniger Unbekanntes am Tag der Übergabe. Es heißt auch ein Protokoll, das Glaubwürdigkeit und langfristigen Bestand stützt.
Keine Prüfung kann einen Build ohne jeden Mangel versprechen, und wir behaupten das auch nicht. Wir veröffentlichen keine Befundzahlen, denn sie wären ausgewählt und nicht neutral. Was die Methode zusichert, ist klar: Der Weg ist fest, Befunde werden belegt, bevor sie behoben werden, und die Tests bleiben.
Wo diese Stufe in einem Projekt liegt, lesen Sie in unserem Ablauf. Die Sicherheitsseite einer echten Plattform zeigt die AWS-Infrastruktur für eine Gesundheitsplattform, oder starten Sie ein Projekt.
Nein. Die Agents übernehmen die lange, sich wiederholende Prüfung. Ein Mensch entscheidet, was menschliches Urteil braucht: Gestaltung, Inhalt und Prioritäten. Die Befunde der Agents werden bestätigt und dann entweder behoben oder mit Begründung verworfen.
Für jedes echte Problem schreiben wir eine automatische Prüfung, die fehlschlägt, solange das Problem besteht. Dann beheben wir das Problem, und die Prüfung besteht. Tritt das Problem wieder auf, wird die Prüfung wieder rot, und wir sehen es sofort.
Ja. Der Scan sucht bekannte Schwachstellen anhand einer Liste. Der Pentest ist ein simulierter Angriff: Er versucht, kleine Schwächen zu kombinieren, wie es ein echter Angreifer täte. Wir nutzen beides bei Plattformen und bei Sites mit Shop oder Buchungen.
Der Weg passt sich dem Projekt an. SEO/AEO und Lighthouse betreffen die Websites. Der Pentest betrifft Plattformen oder Sites mit Shop oder Buchungen, und eine reine Informationsseite bekommt eine leichtere QA. Was eine typische Site enthält, steht auf der Seite zu den Unternehmenswebsites.
Senden Sie eine Projektanfrage oder prüfen Sie Ihre aktuelle Website kostenlos. Jede Nachricht lesen wir selbst.