Template wählen. Lock klicken.
Client Profile⌄
Seedalina Bank · Development⌄
● locked · ready to use
MANUELLES + AUTOMATISIERTES TESTEN
Ein Datenpool. Zwei Eingänge.
Deine manuellen Tester:innen sperren und verbrauchen Testdaten über die Browser Extension. Deine automatisierten Tests tun über die API oder den npm-Client genau dasselbe—im selben Pool, mit denselben Templates, denselben Lock-Regeln. Keine Seite kann Daten greifen, die die andere gerade braucht.
DIE LÜCKE HEUTE
Manuelles Testen und Automatisierung laufen auf zwei verschiedenen Daten-Setups.
Manuelle Tester:innen greifen sich eine Zeile aus einer Tabelle. Die Automatisierung hat ihr eigenes Seed-Script. Niemand merkt, wann beide auseinanderdriften—bis zwei Testläufe um denselben „Testuser“ konkurrieren, oder eine manuelle Testperson mit Daten testet, die die Automatisierung schon verbraucht hat.
MANUELLE TESTPERSON
Tabelle, Zeile 47.
Drei Sprints später immer noch „der Testuser“. Niemand weiss mehr, wer ihn gerade benutzt.
AUTOMATISIERUNG
Seed-Script, hartcodiert.
Einmal geschrieben, längst von der Tabelle abgewichen, und niemand aktualisiert es, bis ein Test fehlschlägt.
↓
SEEDALINA
Ein Entity Pool.
Dieselben Lock-, Release- und Consume-Regeln für alle. Beide Seiten sehen dieselben Daten, im selben Zustand, zur selben Zeit.
01
Parallele Läufe, ein gemeinsamer User
Manuelles Explorationstesten und ein CI-Lauf greifen gleichzeitig auf denselben Account zu. Einer von beiden verliert.
02
Edge Cases leben jeweils nur in einem Kopf
Ein Kunde unter 18, eine überfällige Rechnung—von Hand eingetippt oder im Script hartcodiert, nie zwischen beiden geteilt.
03
Drift, den niemand bemerkt
Tabelle und Seed-Script starteten synchron. Drei Sprints später passt keines mehr zum anderen.
04
Onboarding, doppelt
Eine neue manuelle Testperson und ein:e neue:r SDET bekommen beide separat erklärt, woher Testdaten eigentlich kommen.
EIN POOL, ZWEI EINGÄNGEMANUELLE TESTER:INNEN AUTOMATISIERUNG
Dieselbe Entity, derselbe Lock-Status—egal wer fragt.
Das Popup der Browser Extension ruft GET /business-objects auf und sperrt oder verbraucht einen Datensatz. Dein Playwright-Test oder npm-Client ruft denselben Lifecycle auf—lock(), release(), consume()—auf demselben Datensatz. Wer zuerst kommt, bekommt ihn.
→derselbe Datensatz←
getTestData() aufrufen. Fertig.
// playwright / npm client
const testUser = await getTestData(
'test-user', 'support'
);
✓ locked · ready to use
CODE FIRST, NICHT CONFIG FIRST
Vier Zeilen decken das meiste ab.
● ● ●one-line-fetch.ts
const testUser = await getTestData( 'test-user', 'support' );
Typisiert, sofort nutzbar, kein Setup-Boilerplate. Nichts, was eine manuelle Testperson wissen müsste, nichts, das die Automatisierung pflegen muss.
● ● ●parametrized.spec.ts
for (const item of await pool('client-profile')) {
test(`onboarding · ${item.id}`, async ({ page }) => {
await page.goto('/onboarding');
});
}Playwright erzeugt automatisch einen Test pro Pool-Eintrag—keine gepflegte Liste von Usernamen, die mit dem synchron bleiben muss, was manuelle Tester:innen schon verbraucht haben.
● ● ●on-demand.ts
await orderTestData('invoice', {
status: 'overdue'
});Fehlt die genaue Variante im Pool, lösen sowohl der Order-Button der Extension als auch dieser Aufruf dieselbe Bestellung aus und warten auf dieselbe Generierungs-Pipeline.
● ● ●lifecycle.ts
await testUser.lock(); await testUser.consume(); await testUser.release();
Sperren, benutzen, freigeben—oder mit consume() endgültig verbrauchen. Automatisierung und manuelle Tester:innen folgen denselben drei Verben.
FUNKTIONIERT MIT DEM, WAS DU SCHON HAST
Kein neues Test-Framework zu lernen.
PlaywrightNode / TypeScript über npm-ClientChrome- & Edge-ExtensionDocker, self-hosted
Auch sicher für die QA-Leitung. Synthetische Daten, redigierte Logs und sichere E-Mail-Domains werden einmal auf Template-Ebene erzwungen—und gelten für jeden Consumer, manuell oder automatisiert. Niemand muss daran denken, etwas zu bereinigen.
GET FIRST ACCESS
Schluss mit zwei Testdaten-Setups.
Ein Pool, ein Regelwerk, zwei Eingänge.