← Übersicht
Referenz

Glossar

Begriffe aus den Modulen — Deutsch, Englisch und wie Entwickler sie nennen. Alphabetisch nach deutschem Begriff.

Daten Datenstruktur   QS Qualitätssicherung   Anforderung Requirements   Entwickler Entwickler-Begriff

A – D

Deutsch Englisch Kontext / Modul
Abrechnung Daten Payslip Das Berechnungsergebnis pro Mitarbeiter pro Monat — Modul 03
Abrechnungslauf Daten Payroll Run Der monatliche Lauf der alle Mitarbeiter berechnet — Modul 03
Abzug Daten Deduction Einzelne Abzugsposition (KV, LSt, …) — Modul 03
Akzeptanzkriterien Anforderung Acceptance Criteria Bedingungen unter denen eine Funktion als „fertig und korrekt" gilt — Modul 05
Anforderung Anforderung Requirement Was das System tun soll — Modul 05. Entwickler sagen: „requirement"
Anwenderfehler QS User Error Benutzer hat Daten falsch eingetragen — kein Software-Bug — Modul 13
Array Entwickler Array Entwickler-Begriff für Liste [ ] in JSON — Modul 02
Bug QS Bug / Defect Fehler im Software-Produkt. „Bug" ist der informelle, „defect" der formelle Begriff.
Bug-Ticket QS Bug Report / Ticket Strukturierte Fehlermeldung mit 5 Feldern — Modul 07
Datensatz Daten Record Alle Informationen zu einer Entität an einem Ort. Entwickler: „Object" — Modul 01
Datentyp Daten Data Type Text, Zahl oder Datum — bestimmt, was Software damit tun kann — Modul 01
Dienstvertrag Daten Employment Contract Entität mit Gehalt, Ausmaß, KV, Gültigkeitsdatum — Modul 03

E – G

Deutsch Englisch Kontext / Modul
Endpunkt Entwickler Endpoint Adresse einer API — z.B. /api/mitarbeiter/4721 — Modul 10
Entität Daten Entity Eine Art von Datensatz im System (Mitarbeiter, Vertrag, …) — Modul 03
Ereignis Daten Event Definierter Moment der automatisch Aktionen auslöst (Eintritt, Austritt) — Modul 11
Ereignisgesteuert Entwickler Event-driven Architekturprinzip von P&I LogaHR — Modul 11
Erwartet / Tatsächlich QS Expected / Actual Kernfelder eines Bug-Tickets — Modul 07
Feld Daten Field Einzelne Information in einem Datensatz. Entwickler: „Key" für den Namen — Modul 01
Fehlerfall QS Error Case Ungültige Eingabe — was tut das System wenn etwas fehlt? — Modul 12
Freigabe / Release QS Release P&I liefert 3x/Jahr: Februar, Juni, Oktober — Modul 08
Grenzfall QS Edge Case / Boundary Gültige Extremwerte — Eintritt am 1. oder letzten Tag, Februar — Modul 12
Gültigkeitszeitraum Daten Validity Period Ab wann bis wann eine Regel gilt — Modul 04
Hotfix QS Hotfix Korrektur außerhalb des regulären Release-Zyklus — meist bei kritischen Bugs — Modul 08

I – L

Deutsch Englisch Kontext / Modul
Integrations-Test QS Integration Test Prüft ob mehrere Teile zusammen korrekt funktionieren — Modul 06
Key Entwickler Key Entwickler-Begriff für den Namen eines Feldes — Modul 01
Konfiguration Daten Configuration / Config Einstellungen die Verhalten steuern (SV-Sätze, KV-Mindestgehälter) — Modul 04
Kundendaten QS Customer Data Vom Kunden eingetragene Mitarbeiterdaten — dritte Triage-Schicht — Modul 13
L16 Daten Annual Wage Statement (Austria) Jahreslohnzettel — Jahressumme aus 12 Abrechnungsläufen, geht via ELDA ans Finanzamt — Modul 14
Liste Daten List / Array Mehrere Datensätze hintereinander — [ ] in JSON — Modul 01, 02
Log Entwickler Log Protokoll was das System getan hat — oft JSON; Entwickler schicken dir Logs wenn etwas fehlschlägt
Lohnzettel Daten Payslip Monatliches Berechnungsergebnis pro Mitarbeiter — Modul 03, 07

M – R

Deutsch Englisch Kontext / Modul
Manueller Test QS Manual Test Du prüfst inhaltlich ob das Ergebnis stimmt — deine Haupttätigkeit — Modul 06
Mitarbeiter Daten Employee Stammdaten-Entität — Modul 03. Entwickler: „Employee Object"
Normalfall QS Standard Case Der typische erwartete Ablauf — Ausgangspunkt jedes Testplans — Modul 12
Object Entwickler Object Entwickler-Begriff für einen Datensatz { } in JSON — Modul 01, 02
Priorität QS Priority Wie dringend ein Ticket bearbeitet wird — separat von Severity (Schweregrad)
Regression QS Regression Ein bisher korrektes Feature schlägt nach einem Update fehl — Modul 06
Regelkonfiguration Daten Business Rules / Config SV-Sätze, KV-Mindestgehälter als Datensätze mit Gültigkeitsdatum — Modul 04
Reproduzierbar QS Reproducible Ein Fehler den man gezielt nachstellen kann — Voraussetzung für ein gutes Ticket — Modul 07
Root Cause QS Root Cause Die tatsächliche Ursache eines Fehlers — nicht nur das Symptom. Entwickler sagen: „what's the root cause?"

S – Z

Deutsch Englisch Kontext / Modul
Schnittstelle Entwickler Interface / API Verbindung zwischen zwei Systemen — Modul 10
Schritte (Ticket) QS Steps to Reproduce Schritt-für-Schritt Anleitung zum Nachstellen eines Fehlers — Modul 07
Schweregrad QS Severity Wie schlimm der Fehler in seiner Auswirkung ist — separat von Priority (Dringlichkeit)
Sonderfall QS Edge Case Auch: Grenzfall — selten aber möglich, oft Fehlerquelle — Modul 05, 12
Standard (-Bug) QS Product Bug Fehler im P&I Produkt selbst — betrifft alle Kunden gleich — erste Triage-Schicht — Modul 13
Stiller Fehler QS Silent Error System läuft ohne Alarm — Ergebnis ist trotzdem falsch — Modul 01, 04
Triage QS Triage Einordnen wo ein Problem sitzt (Standard / Config / Kundendaten / Anwenderfehler) — Modul 13
Unit-Test QS Unit Test Automatisierter Test einer einzelnen Funktion — Modul 06
Value / Wert Daten Value Was konkret in einem Feld steht — Modul 01
Wert → siehe Value
XML Daten XML Älteres Textformat für Daten — ELDA-Meldungen laufen über XML — Modul 02, 09

Ticket-Felder auf Englisch — Kurzreferenz

Deutsch Englisch Hinweis
Titel Title  oder: Summary Kurz und spezifisch — was, wo, wann
Schritte Steps to Reproduce Nummerierte Liste — so konkret dass jeder es nachstellen kann
Erwartet Expected Result Mit konkreter Zahl wenn möglich
Tatsächlich Actual Result Was das System stattdessen ausgegeben hat
Kontext Context  oder: Environment Kunde, Release-Version, KV, Mitarbeiterzahl

Glossar · PV-QS-Academy · 2026