Digitale Systeme testen und ihre Betriebsbereitschaft bestätigen

Ein Computer kann normal starten und trotzdem bei der ersten Aufgabe versagen, die sein Benutzer erledigen muss. Beim Testen wird ein konfiguriertes System bekannten Aktionen ausgesetzt und anschließend das tatsächliche Verhalten mit dem erwarteten verglichen. Das System kann ein einzelner Laptop, ein Drucker, eine Kontoeinrichtung oder eine von einem Team genutzte Anwendung sein.

Testen und Qualitätssicherung

Qualitätssicherung verbessert die Arbeitsweise, damit Probleme verhindert werden. Eine Standard-Einrichtungscheckliste, eine vereinbarte Sicherheitsgrundkonfiguration und eine Überprüfung des Testkonzepts sind Maßnahmen der Qualitätssicherung. Das Testen untersucht das konkrete System, das aus diesem Prozess hervorgegangen ist. Es ist Qualitätskontrolle: Es findet Fehlerzustände und liefert Belege für die Freigabeentscheidung.

Tests helfen, verlorene Arbeitszeit, blockierte Aufgaben und Sicherheitsvorfälle zu verhindern. Sie geben dem Verantwortlichen außerdem eine Grundlage für die Abnahme des Systems. Ein Ordner, der sich für die Fachkraft öffnet, dem Benutzerkonto aber den Zugriff verweigert, ist ein Problem, das vor dem ersten Arbeitstag des Benutzers gefunden werden sollte.

Von der Fehlhandlung zur Fehlerwirkung

Diese Begriffe beschreiben verschiedene Teile desselben Ablaufs:

Ein Test kann die Fehlerwirkung aufdecken. Anschließend wird ihre Ursache durch Diagnose nach dem Verfahren zur Fehlersuche und Fehlerbehebung ermittelt; das Testergebnis allein beweist nicht, welche Einstellung falsch ist.

Die Verifizierung prüft die Spezifikation: Wurde das System wie gefordert konfiguriert? Die Validierung prüft das Bedürfnis: Können Menschen ihre tatsächliche Arbeit erledigen? Ein Laptop kann seiner Einrichtungscheckliste entsprechen und dennoch eine Anwendung vermissen lassen, die der Benutzer benötigt. Deshalb helfen sowohl Benutzeraufgaben als auch betriebliche Richtlinien, die Tests festzulegen.

Stufe und Art wählen

Die Stufe eines Tests beschreibt, was untersucht wird. Entwickler testen einzelne Softwarekomponenten und deren Integration. Supportfachkräfte testen hauptsächlich das gesamte konfigurierte System. Systemintegrationstests prüfen Verbindungen zu anderen Systemen, etwa Cloudspeicher oder E-Mail. Abnahmetests ermöglichen Benutzern oder Verantwortlichen, die Eignung für den Einsatz zu prüfen.

Die Art eines Tests beschreibt das untersuchte Qualitätsmerkmal. Funktionale Tests prüfen, was das System tut. Nichtfunktionale Tests prüfen Performance, Gebrauchstauglichkeit, Barrierefreiheit, Sicherheit, Zuverlässigkeit und Kompatibilität. Dies sind getrennte Dimensionen: Ein Abnahmetest kann sowohl die Performance als auch die Funktion untersuchen.

Black-Box-Tests gehen von Anforderungen aus, ohne die interne Struktur zu untersuchen. White-Box-Tests nutzen Wissen über Code oder Konfigurationslogik. Die meisten Prüfungen von Aufgaben im Support sind Black-Box-Tests.

Tests können nicht jede mögliche Kombination aus Konten, Eingaben und Bedingungen abdecken. Priorisiere Bereiche, in denen Fehlerwirkungen wahrscheinlich oder schädlich sind, und teste früh genug, um Probleme zu beheben, bevor Benutzer vom System abhängen. Ein unauffälliger Testlauf belegt, dass diese Tests keine Fehlerzustände gefunden haben. Er beweist nicht, dass das System keine hat. Berücksichtige Anforderungen aus Sicherheits-, Barrierefreiheits- und Datenschutzrichtlinien, auch wenn die anfragende Person sie nicht erwähnt hat.

Anfragen vermischen oft eine Aufgabe, eine bevorzugte Lösung und eine vage Erwartung. Trenne diese Aspekte vor dem Testen und vereinbare, woran der Erfolg zu erkennen ist. Eine klare Anforderung ermöglicht es zwei testenden Personen, zur gleichen Entscheidung über Bestehen oder Fehlschlagen zu kommen.

Mit der Benutzeraufgabe beginnen

Eine Benutzeranforderung drückt ein Bedürfnis in Alltagssprache aus: „Ich muss Rechnungen in den Finanzordner scannen.“ Die zugehörigen Systemanforderungen benennen, was diese Aufgabe unterstützen muss: ein geeigneter Scannertreiber, Einstellungen für die Scanausgabe in einen Ordner, Schreibberechtigung und Zugriff auf den Dateiserver.

Eine funktionale Anforderung legt fest, was das System tut, etwa auf einem zugewiesenen Drucker drucken. Eine nichtfunktionale Anforderung legt fest, wie gut es funktioniert oder welche Einschränkungen gelten, etwa eine Zeitgrenze für die Anmeldung oder beschränkter Zugriff auf Finanzunterlagen. Beide benötigen Belege.

„Diesen Browser installieren“ kann ein Lösungsvorschlag für „Das Portal des Lieferanten öffnen“ sein. Die Installation des Browsers verifiziert eine Aktion. Die Ausführung der Aufgabe im Portal validiert das Bedürfnis des Benutzers.

Erfolg beobachtbar machen

Ein Erfolgskriterium, auch Abnahmekriterium genannt, gibt eine klare Bedingung für das Bestehen vor. Ersetze „schnell“, „einfach“ oder „sicher“ durch eine vereinbarte Messung oder ein sichtbares Ergebnis. Gib gegebenenfalls Aktion, Bedingungen, Schwellenwert und Einheit an.

Für einen Empfangs-PC kann aus „schnell und sicher“ Folgendes werden:

1. Vom Einschalten bis zu einem nutzbaren Desktop vergehen bei jedem von drei Tests höchstens 60 Sekunden.
2. Die Buchungsanwendung öffnet sich innerhalb von 5 Sekunden.
3. Der Bildschirm wird nach 5 Minuten ohne Eingabe gesperrt.
4. Die Person am Empfang nutzt ein Standardkonto und kann keine Programme installieren, die Administratorrechte benötigen.
5. Der Systemdatenträger ist verschlüsselt.

Die Zeitgrenzen sind vereinbarte Anforderungen, keine allgemeinen Standards für jeden Computer. Bitte die anfragende Person, sie vor dem Testen zu bestätigen. Andernfalls könnte eine testende Person nach Sichtung der Ergebnisse einen leicht zu erreichenden Schwellenwert wählen.

Weniger sichtbare Anforderungen finden

Frag, wer das System nutzen wird, welche Aufgaben wichtig sind, welche Geräte und Anwendungen verwendet werden und welche Einstellungen für Barrierefreiheit oder assistiven Technologien benötigt werden. Ergänze die Anforderungen aus Richtlinien. Eine Anmeldung kann vom Netzwerk, einem Identitätsdienst und MFA abhängen; eine Anwendung benötigt möglicherweise ein bestimmtes Betriebssystem, eine Datenbankverbindung oder einen Lizenzserver.

Kompatibilität bedeutet, dass diese benötigten Kombinationen zusammen funktionieren. Wenn Mitarbeiter zwei Browser nutzen, bleibt beim Testen nur eines Browsers ein Teil der Anforderung ungeprüft. Dokumentiere Abhängigkeiten, damit die Testumgebung sie enthalten kann.

Prioritäten mit Tests verbinden

Die MoSCoW-Prioritäten unterscheiden Muss, Soll, Kann und diesmal nicht enthalten. Eine nicht erfüllte Muss-Anforderung verhindert normalerweise die Freigabe zur Inbetriebnahme. Eine nicht erfüllte Kann-Anforderung kann zu einem akzeptierten bekannten Problem werden. Die Priorität hilft, Reihenfolge und Tiefe der Tests zu wählen, macht aber aus einem fehlgeschlagenen Ergebnis kein bestandenes.

Erstelle eine Rückverfolgbarkeitstabelle mit Anforderungs-ID, Erfolgskriterium, Testfall-IDs und Ergebnis. Eine Zeile ohne Test zeigt eine Lücke in der Abdeckung. Wenn sich eine Anforderung ändert, aktualisiere ihre Tests und die Tabelle gemeinsam. Testbare Anforderungen werden mit der anfragenden Person bestätigt; sie bestehen nicht einfach aus den Aufgaben, die gerade am leichtesten zu prüfen sind.

Eine Testumgebung bietet dir einen Ort, an dem du Einstellungen ändern, Aktionen wiederholen und Daten zurücksetzen kannst, ohne die tatsächliche Arbeit zu unterbrechen. Sie muss dem Zielsystem außerdem hinreichend ähneln, damit die Ergebnisse eine brauchbare Aussage ermöglichen.

Die Umgebung passend zum Zweck wählen

Die Produktivumgebung enthält tatsächliche Arbeit und echte Daten. Nichtproduktivumgebungen dienen unterschiedlichen Zwecken:

Eine virtuelle Maschine kann ein Testbetriebssystem auf einem vorhandenen physischen Computer ausführen. Ein Snapshot erfasst ihren Zustand vor einer Änderung. Durch das Zurücksetzen kann eine andere Person den Test vom selben Ausgangspunkt aus wiederholen. Halte diesen Ausgangszustand fest: Ein Test, der von einer unbekannten früheren Änderung abhängt, lässt sich schwer reproduzieren.

Repräsentative Ergebnisse erzielen

Vergleiche die Testumgebung mit den vorgesehenen Geräten. Prüfe Betriebssystemversion und Build, Anwendungen, Richtlinien, Hardwarekapazität, Netzwerkzugriff und Berechtigungen. Eine Anwendung, die mit 32 GB Arbeitsspeicher gut läuft, kann auf dem Laptop des Benutzers mit 8 GB langsam sein. Ein Testkonto mit Administratorrechten kann ein Zugriffsproblem für einen Standardbenutzer verdecken.

Ob eine Umgebung repräsentativ ist, hängt von der geprüften Aussage ab. Eine virtuelle Maschine kann viele Einstellungen prüfen, aber für ein Ergebnis zu einem physischen Drucker oder einem bestimmten Laptop wird weiterhin das jeweilige Gerät benötigt. Halte Unterschiede zwischen Test- und Produktivumgebung fest, damit der Bericht zur Betriebsbereitschaft erklären kann, was noch unbestätigt ist.

Konten, Daten und Rücksetzung vorbereiten

Verwende synthetische Daten wie erfundene Kunden und Beispielrechnungen oder geeignet anonymisierte Daten. Sind echte personenbezogene Daten erforderlich, halte die Richtlinie ein: Verwende nur das Nötigste, beschränke den Zugriff und entferne die Daten nach Abschluss der Tests. Schulungsdaten sollten realistisch genug sein, um die Aufgabe zu ermöglichen, ohne Kundendatensätze offenzulegen.

Beschrifte Testgeräte, -konten und -server eindeutig. Prüfe vor jedem Lauf das Ziel des Skripts. Auch ein gut geschriebenes Testskript kann Schaden anrichten, wenn es Nachrichten an echte Kunden sendet oder Daten auf einem Produktivserver löscht. Separate Testzugangsdaten und -ziele helfen, diesen Fehler zu vermeiden.

Bestätige vor dem Start die Eingangskriterien: Der vorgesehene Build ist installiert, Konten und Geräte sind verfügbar, Testdaten sind geladen, Werkzeuge funktionieren und Performance-Referenzwerte wurden erfasst. Speichere Gerätemodell, Betriebssystem-Build, Anwendungsversionen und Netzwerkangaben zusammen mit den Ergebnissen. Diese Angaben erklären, unter welchen Bedingungen ein Test bestanden wurde.

Einige abschließende Prüfungen müssen auf dem tatsächlich zu übergebenden System stattfinden. Vereinbare ein Zeitfenster, halte bei Änderungen eine Datensicherung oder eine Möglichkeit zum Rückgängigmachen bereit und bevorzuge Prüfungen mit rein lesendem Zugriff. Eine abschließende Geräteprüfung bestätigt den ausgelieferten Zustand; sie macht ein Produktivgerät nicht zu einem sicheren Ort für störende Experimente.

Ein Testkonzept macht aus einer Sammlung von Prüfungen eine abgestimmte Aufgabe. Es legt Zweck, Grenzen und Verantwortlichkeiten fest, bevor Ergebnisse vorliegen. So hängen die Tests nicht davon ab, wer an diesem Tag gerade verfügbar ist.

Festlegen, was die Arbeit umfasst

Benenne das Ziel und die zu testenden Geräte, Konten, Anwendungen und Verbindungen. Liste auf, was zum Umfang gehört und was ausgeschlossen ist. Nimm Testarten, Umgebung, Daten, Werkzeuge, Personen, Zeitplan, Risiken und Berichterstattung auf. Die anfragende Person sollte erkennen können, wie das Konzept die Anforderungen berücksichtigt.

Eine praktische Tabelle im Konzept kann jeden Test, seinen Zweck, die Daten und das erwartete Ergebnis nennen sowie Platz für das tatsächliche Ergebnis bieten. Detaillierte, wiederholbare Anweisungen gehören in verknüpfte Testfälle. Das Konzept koordiniert die gesamte Tätigkeit; ein Testfall beschreibt eine einzelne Prüfung.

Beginn und Abschluss vereinbaren

Eingangskriterien legen fest, was vor Testbeginn bereit sein muss. Für eine Reihe von Laptops könnten sie den Standard-Build und Testkonten auf allen 12 Geräten verlangen.

Endekriterien legen fest, was erfüllt sein muss, bevor die Tests als abgeschlossen gelten. Ein Beispiel: „Alle geplanten Tests durchgeführt, alle Muss-Anforderungen erfüllt und keine offenen Fehlerzustände mit kritischem oder hohem Schweregrad.“ Sie ermöglichen dem Verantwortlichen eine einheitliche Beurteilung der Ergebnisse. Eine Frist ist eine zeitliche Vorgabe und kein Beleg dafür, dass diese Bedingungen erfüllt wurden.

Blockierte und nicht durchgeführte Tests bleiben bei der Überprüfung der Endekriterien sichtbar. Ist ein benötigter Dienst nicht verfügbar, halte die Lücke und ihre Auswirkung auf die Entscheidung fest. Markiere die Anforderung nicht als erfüllt, weil der Fachkraft die Zeit ausgegangen ist.

Aufwand dort einsetzen, wo Fehlerwirkungen ins Gewicht fallen

Risikobasiertes Testen widmet wahrscheinlichen oder schädlichen Fehlerwirkungen mehr Aufmerksamkeit. Anmeldung, Zugriff auf Geschäftsdaten, die Hauptanwendung und Sicherheitseinstellungen verdienen normalerweise frühe Prüfungen. Ein Fehler beim Hintergrundbild kann kurz geprüft werden, weil er andere Auswirkungen hat.

Für 12 Vertriebslaptops könnte ein Konzept Anmeldung, E-Mail, Kundendatenbank, VPN, Drucken, eine Teamfreigabe, Verschlüsselung, Updates und Vergrößerung für einen Benutzer mit Sehbehinderung umfassen. Der interne Code der Datenbank gehört nicht zu diesem Supporttest. Beginne in einem separaten Testnetzwerk und führe anschließend die abschließenden Prüfungen mit den richtigen Konten durch.

Sind die Builds identisch, teste zwei Geräte gründlich und verwende auf allen 12 eine Checkliste zur Betriebsbereitschaft. Das stichprobenartige Prüfen gemeinsamen Verhaltens spart Zeit, gerätespezifische Merkmale müssen aber weiterhin einzeln geprüft werden. Verschlüsselungsstatus, Updates, Akkuzustand und Benutzerkonto können sich bei ansonsten identischen Laptops unterscheiden. Endekriterien, die erfüllte Muss-Anforderungen auf allen 12 verlangen, gelten weiterhin für alle 12.

Das Konzept bei Änderungen aktuell halten

Weise klare Rollen zu: Wer bereitet Konten vor, führt Testfälle durch, dokumentiert Fehlerzustände und nimmt das System ab? Plane Zeit für Korrekturen und Fehlernachtests ein. Ermittle Risiken wie nicht verfügbare Testgeräte oder eine nicht erreichbare Abhängigkeit und vereinbare den Umgang damit.

Wenn die anfragende Person eine Anforderung ändert, überarbeite das Erfolgskriterium, die Testfälle, den Zeitplan und die zugehörige Tabellenzeile zur Rückverfolgbarkeit gemeinsam. Bleibt das alte Konzept bestehen, entsteht eine Lücke zwischen dem erwarteten System und dem System, das die Belege tatsächlich beschreiben.

Eine andere Person sollte einen Testfall anhand seiner schriftlichen Anweisungen durchführen und ein vergleichbares Ergebnis erzielen können. Dazu braucht es einen bekannten Ausgangszustand, klare Aktionen und ein erwartetes Ergebnis, das vor dem Test festgelegt wird.

Eine wiederholbare Prüfung erstellen

Nimm ID und Titel, die zugehörige Anforderung, Vorbedingungen, nummerierte Schritte, Testdaten und das erwartete Ergebnis auf. Ergänze bei der Durchführung das tatsächliche Ergebnis, den Status, die testende Person und das Datum. „Es funktioniert“ ist zu vage. „Das Konto wird als gesperrt angezeigt und ein korrektes Passwort bis zur Entsperrung abgelehnt“ beschreibt beobachtbares Verhalten.

Vorbedingungen verhindern, dass frühere Tests die Bedeutung späterer Tests verändern. Ein Kontosperrungstest kann fünf Fehlversuche nicht zuverlässig zählen, wenn für das Konto bereits drei fehlgeschlagene Versuche erfasst sind.

Eine Kontosperrung durchspielen

Setze für eine Anforderung zur Sperrung nach fünf fehlgeschlagenen Anmeldungen den Schwellenwert auf fünf. Beginne mit einem aktiven, nicht gesperrten Testkonto, dessen Zähler für Fehlversuche auf null steht. Führe diese Schritte ohne eine Pause durch, die lang genug wäre, um den Zähler zurückzusetzen:

1. Gib viermal ein falsches Passwort ein.
2. Prüfe, ob das Konto noch aktiv ist.
3. Gib ein fünftes Mal ein falsches Passwort ein.
4. Versuche es mit dem richtigen Passwort.

Das erwartete Ergebnis nach vier Fehlversuchen ist, dass keine Sperrung eintritt. Der fünfte führt zur Sperrung und das richtige Passwort wird abgelehnt, bis ein Administrator das Konto entsperrt oder die Sperrfrist endet. Setze das Konto vor einem weiteren Lauf zurück, damit die Ausgangsbedingungen übereinstimmen.

Daten wählen, die einen Fehler aufdecken können

Positivtests prüfen erlaubte Aktionen und zulässige Eingaben. Negativtests prüfen, ob verbotene Aktionen und unzulässige Eingaben sicher zurückgewiesen werden. Ein Negativtest ist bestanden, wenn die geforderte Zurückweisung erfolgt; „zurückgewiesen“ bedeutet nicht automatisch „fehlgeschlagen“.

Manche Kurse fassen ungültige und fehlerhafte Daten zusammen. Für ein Testkonzept ist entscheidend, dass die gewählten Fälle sowohl Regelverstöße als auch ungeeignete Eingaben prüfen.

Ein Minimum von 12 schließt genau 12 ein. Werden nur 11 und 15 getestet, kann ein Fehlerzustand übersehen werden, der fälschlich mehr als 12 verlangt. Am oberen Rand muss 64 akzeptiert und 65 zurückgewiesen werden. Gib weitere Passwortbedingungen an, damit die Längenprüfung nicht mit einer anderen Regel verwechselt wird.

Prüfen, ob ein Ergebnis plausibel ist

Auch unerwartet gute Ergebnisse müssen geprüft werden. Eine Datei mit 2 GB enthält 16 Gigabit. Eine Verbindung mit 1 Gbit/s benötigt daher mindestens 16 Sekunden für die Übertragung, noch ohne zusätzlichen Protokollaufwand. Ein gemeldeter Kopiervorgang von 0,1 Sekunden deutet darauf hin, dass die Messung diese Netzwerkübertragung nicht abgebildet hat. Halte die Beobachtung fest, prüfe die Methode und ziehe bei Bedarf eine Fachperson hinzu. Aktualisiere Testfälle, wenn sich Anforderungen und Konfigurationen ändern; wiederholte Tests nur des erwarteten Ablaufs decken mit der Zeit keine neuen Probleme mehr auf.

Testen verbraucht Strom, Geräte und Arbeitszeit. Effizientes Testen erhält den erforderlichen Grad an Sicherheit und vermeidet dabei ungenutzte Ressourcen, unnötige Neueinrichtungen und wiederholte Arbeit ohne zusätzlichen Belegwert.

Energie aus Leistung und Zeit berechnen

Leistung ist die pro Zeit umgesetzte Energie. Rechne Watt in Kilowatt um und multipliziere dann mit den Betriebsstunden:

Ein Server mit einer Leistungsaufnahme von 120 W nimmt 0,12 kW auf. Läuft er 30 Tage durchgehend, ergibt das 720 Stunden und einen Verbrauch von 86,4 kWh. Läuft er nur an zehn Testtagen jeweils 8 Stunden, ergibt das 80 Stunden und einen Verbrauch von 9,6 kWh. Der Unterschied beträgt 76,8 kWh, eine Einsparung von etwa 89 %. Diese Werte setzen die angegebene konstante Leistungsaufnahme voraus; tatsächliche Messungen können den Verbrauch eines Geräts ermitteln.

Umgebungen wiederverwenden und ungenutzte Ressourcen anhalten

Verwende Testgeräte, virtuelle Maschinen und Snapshots erneut, wenn sie die Testanforderungen erfüllen. Automatisiere wiederkehrende Prüfungen und halte Ergebnisse digital fest. Bei identischen Builds kann eine Stichprobe gründlich getestet werden, während jedes Gerät weiterhin die nötigen individuellen Prüfungen der Betriebsbereitschaft erhält.

Fahre nach dem Testen virtuelle Testmaschinen herunter und entferne ungenutzte Cloudressourcen. Prüfe den tatsächlichen Ressourcenzustand der Plattform: Bei Azure kann eine virtuelle Maschine nach dem Herunterfahren innerhalb des Betriebssystems weiterhin zugeordnet bleiben und Kosten für Rechenleistung verursachen. Das Aufheben der Zuordnung beendet diese Kosten; erhaltene Datenträger verursachen weiterhin Speicherkosten. Befolge die dokumentierten Schritte der Plattform zum Anhalten und Löschen und prüfe, was bestehen bleibt.

Effiziente Einstellungen anhand tatsächlicher Arbeit prüfen

Nicht benötigte Autostartprogramme und Hintergrunddienste verbrauchen Prozessorzeit und Arbeitsspeicher. Miss Ressourcennutzung und Antwortzeit vor und nach einer Konfigurationsänderung unter vergleichbaren Bedingungen. Gib einer virtuellen Maschine den benötigten Arbeitsspeicher und die benötigte Prozessorleistung, ohne dem Host ungenutzte Kapazität zu entziehen.

Einstellungen für den Energiesparmodus und das Ausschalten des Bildschirms senken den Energieverbrauch bei Inaktivität, ihr Zeitpunkt muss aber zur Aufgabe passen. Ein Informationsbildschirm am Empfang muss möglicherweise den ganzen Tag sichtbar bleiben. Ein Gerät mit geplanten nächtlichen Updates muss während dieses Zeitfensters aufwachen oder verfügbar bleiben. Eine Energiespareinstellung ist nicht erfolgreich, wenn sie eine Muss-Aufgabe verhindert.

Entferne einen benötigten Hintergrunddienst nicht allein deshalb, weil er in einer Ressourcenüberwachung erscheint. Der Test prüft die vereinbarte Konfiguration und ihre Wirkung; ein Fehlschlag wird zur Untersuchung dokumentiert. Effizienz und Performance werden wie andere Einstellungen anhand derselben Benutzeranforderungen und Richtlinien gemessen.

Hardware während ihrer Nutzungsdauer einsetzen

Tests können zeigen, dass ein älteres Gerät die Anforderungen noch erfüllt. Dadurch lassen sich der Ersatz und die dafür benötigten Materialien aufschieben. Auch die Wiederverwendung von Testhardware verringert Abfall. Die Energieeinsparung hängt vom Gerät und seiner Arbeitslast ab: Bei vielen Laptops und Smartphones macht die Herstellung einen großen Teil der Umweltbelastung aus, während ein ineffizienter Server im Betrieb so viel Strom verbrauchen kann, dass ein Ersatz günstiger ist.

Hat ein Gerät das Ende seiner Nutzungsdauer erreicht, organisiere die sichere Datenlöschung und ein zugelassenes Recycling. Wiederverwendung ist nur dann sinnvoll, wenn das Gerät für seine nächste Aufgabe geeignet bleibt und seine bisherigen Daten geschützt sind.

Ein funktionaler Test verfolgt eine Aufgabe bis zu ihrem nutzbaren Ergebnis. Das Öffnen eines Programms ist nur der Anfang, wenn der Benutzer damit Arbeitsergebnisse bearbeiten, speichern, senden oder drucken muss.

Die gesamte Aufgabe verfolgen

Beginne mit den funktionalen Anforderungen und liste die Aktionen auf, die der Benutzer ausführen muss. Typische Prüfungen im Support umfassen Anmeldung; Öffnen benötigter Anwendungen; Bearbeiten und Speichern freigegebener Dateien; interne und externe E-Mails; Drucken; WLAN- und VPN-Zugriff; Scannen; benötigte Websites sowie einen Anruf mit Kamera und Headset.

Bestimme für jede Aufgabe den abschließenden Beleg. Ein Druckdialog beweist nicht, dass der zugewiesene Drucker eine lesbare Seite ausgegeben hat. Eine Speichermeldung ist ein stärkerer Beleg, wenn die Datei geschlossen, erneut geöffnet und auf den erwarteten Inhalt geprüft werden kann.

Das richtige Konto verwenden

Führe Benutzeraufgaben mit dem Konto des Benutzers oder einem Testkonto mit denselben Gruppenmitgliedschaften durch. Ein Administrator kann Dateien erreichen oder Einstellungen ändern, die einem Standardbenutzer nicht zugänglich sind. Tests nur als Administrator können genau das Berechtigungsproblem verdecken, auf das der Benutzer stoßen wird.

Melde dich für eine Vertriebsfreigabe mit einem Testkonto des Vertriebs an. Öffne die Freigabe, erstelle „Quote-test.docx“, speichere und schließe die Datei und öffne sie erneut. Prüfe den Inhalt. Versuche dann, mit demselben Konto die Personalabteilungsfreigabe zu öffnen. Wenn Vertriebsmitarbeiter nicht auf die Personalabteilung zugreifen dürfen, lautet das erwartete Ergebnis „Zugriff verweigert“. Dokumentiere die positiven und negativen Ergebnisse getrennt.

Eine Fachkraft benötigt möglicherweise ein autorisiertes Werkzeug mit erhöhten Rechten, um eine geschützte Einstellung zu prüfen. Das ist eine andere Prüfung als der Nachweis, dass der Benutzer eine Aufgabe ausführen kann. Halte Konto und Berechtigungsstufe in jedem Ergebniseintrag fest.

Eine schnelle Prüfung oder einen ausführlichen Test wählen

Ein Smoke-Test ist eine kurze, oberflächliche Prüfung grundlegender Funktionen: Start, Anmeldung, Netzwerkverbindung und Hauptanwendung. Führe ihn zuerst durch, um einen Build zu erkennen, der für eingehendere Tests nicht bereit ist. Schlägt die Anmeldung fehl, lassen sich viele spätere Aufgaben nicht sinnvoll versuchen.

Ein bestandener Smoke-Test belegt nicht, dass jede Aufgabe funktioniert. Fahre mit den geplanten Ende-zu-Ende-Testfällen fort, einschließlich seltenerer, aber benötigter Aktionen. Eine Anwendung kann sich öffnen und dennoch beim Speichern eines Berichts oder beim Verbinden mit einem Dienst versagen.

Korrekturen und zugehöriges Verhalten erneut testen

Der Fehlernachtest wiederholt den fehlgeschlagenen Test nach einer Korrektur. Er beantwortet, ob das ursprüngliche Problem behoben ist. Der Regressionstest wiederholt zuvor bestandene Prüfungen und sucht nach Beeinträchtigungen durch die Änderung.

Wiederhole nach einem Druckertreiber-Update zuerst den fehlgeschlagenen Drucktestfall. Prüfe dann das Drucken aus den anderen wichtigen Anwendungen und das Scannen, sofern dasselbe Treiberpaket es beeinflussen könnte. Behalte das ursprüngliche fehlgeschlagene Ergebnis und ergänze die neuen Ergebnisse, damit die Dokumentation sowohl den Fehlerzustand als auch den Beleg für seine Korrektur zeigt.

Die benötigten Kombinationen prüfen

Kompatibilitätstests decken die Betriebssysteme, Browser, Geräte und Dateiformate ab, die Benutzer tatsächlich benötigen. Ein Portal, das in einem Browser funktioniert, bestätigt nicht den zweiten unterstützten Browser. Dokumentiere die getesteten Versionen und Kombinationen; die Aussage „Das Portal funktioniert“ verdeckt sonst einen Teil des Umfangs. Wähle auch nach einer kleinen Änderung Regressionstests für die Funktionen, die sie beeinflussen könnte.

Performance-Tests ersetzen „Es fühlt sich langsam an“ durch Messungen unter bekannten Bedingungen. Stabilitätstests fragen, ob akzeptables Verhalten über längere Zeit anhält. Ein kurzer erfolgreicher Lauf ist daher nur ein Teil der Belege.

Die Kennzahl passend zur Anforderung wählen

Die Antwortzeit misst die Wartezeit von einer Aktion bis zu ihrem Ergebnis in Sekunden oder Millisekunden. Der Durchsatz misst die Arbeit pro Zeiteinheit, etwa Seiten pro Minute oder Mbit/s. Die Ressourcenauslastung umfasst Prozessorauslastung in Prozent, Arbeitsspeichernutzung, Datenträgeraktivität und Netzwerknutzung. Die Netzwerklatenz ist die Verzögerung in Millisekunden; der Paketverlust ist der Prozentsatz der Anfragen ohne Antwort.

Halte unter normalen Bedingungen gemessene Referenzwerte fest. Vergleiche spätere Ergebnisse mit diesen Werten und den vereinbarten Schwellenwerten. Ein Prozessorwert von 70 % sagt ohne Kenntnis der Arbeitslast und des normalen Verhaltens dieses Systems wenig aus.

Realistische Bedingungen wählen

Ein Testlauf mit einem einzelnen Benutzer in ruhiger Umgebung kann die Performance an einem arbeitsreichen Morgen nicht belegen. Ein Dauerlasttest kann stetig steigende Arbeitsspeichernutzung oder eine Verlangsamung aufdecken, die erst nach Stunden sichtbar wird. Wiederhole Messungen mit derselben Methode und dokumentiere Bedingungen wie einen Kaltstart, Updates im Hintergrund und den Energiemodus.

Mehr als den Durchschnitt betrachten

Bei Anmeldezeiten von 4,2; 3,8; 4,0; 9,6 und 4,1 Sekunden beträgt die Summe 25,7 Sekunden. Die Division durch fünf ergibt einen Mittelwert von 5,14 Sekunden. Sortiert lauten die Werte 3,8; 4,0; 4,1; 4,2 und 9,6. Der Median beträgt also 4,1 Sekunden und das Maximum 9,6 Sekunden.

Das Kriterium „Median höchstens 5 Sekunden und keine Anmeldung über 10 Sekunden“ ist erfüllt. Der langsame Lauf hebt den Mittelwert über 5 Sekunden, das Kriterium legt aber nicht den Mittelwert fest. Halte die langsame Beobachtung zur Untersuchung fest; entferne sie nicht allein deshalb, weil sie ungewöhnlich ist.

Ein Prozentkriterium benötigt auch die zugehörige Anzahl. „95 % von 20 Seitenaufrufen unter 2 Sekunden“ verlangt 19 passende Aufrufe. Ein langsamerer Aufruf ist zulässig, zwei sind es nicht. Eine verlorene Antwort auf 20 Ping-Anfragen entspricht 5 % Verlust. „Unter 2 Sekunden“ schließt genau 2 Sekunden aus, während „höchstens 2 Sekunden“ sie einschließt.

Einen Fehlschlag vor der Untersuchung dokumentieren

Nutze Task-Manager, Ressourcenmonitor oder Leistungsüberwachung unter Windows; Aktivitätsanzeige unter macOS oder top, htop und free -h unter Linux. Eine Zeitmessung erfasst die Wartezeit des Benutzers, während ping bei der Messung von Latenz und Verlust hilft. Halte Einheiten und Methode bei jedem Ergebnis fest.

Zu wenig Arbeitsspeicher, Autostartprogramme, ein Treiber, der Energiemodus, Hardwarekapazität, Softwarefehler und externe Dienste können die Performance beeinflussen. Ein nicht eingehaltener Schwellenwert zeigt ein zu untersuchendes Problem, nicht dessen Ursache. Miss nach der Korrektur erneut unter vergleichbaren Bedingungen, damit der Vorher-nachher-Vergleich aussagekräftig ist.

Ein System kann seine technischen Funktionen erfüllen und dennoch alltägliche Aufgaben für manche Benutzer erschweren oder unmöglich machen. Prüfungen der Gebrauchstauglichkeit und Barrierefreiheit betrachten die Aufgabe aus Sicht des vorgesehenen Benutzers, einschließlich seiner Einstellungen und assistiven Technologie.

Die Aufgabe beobachten, ohne sie zu übernehmen

Gebrauchstauglichkeit betrifft Effektivität, Effizienz und Zufriedenheit: Können Menschen ihre Ziele mit akzeptablem Aufwand und einer akzeptablen Nutzungserfahrung erreichen? Gehe wichtige Aufgaben durch, notiere Schritte und Zeit und suche nach verwirrenden Beschriftungen oder unklaren Fehlermeldungen. Beobachte dann einen repräsentativen Benutzer beim Versuch, ohne zu helfen. Hilfe kann den Punkt verdecken, an dem die Benutzeroberfläche nicht mehr verständlich ist.

Eine angeheftete App oder ein verbundenes Netzlaufwerk kann eine tägliche Aufgabe verkürzen. Prüfe, ob jede Anpassung weiterhin die Zugriffs- und Sicherheitsanforderungen erfüllt.

Zugang für Menschen mit Behinderungen prüfen

Barrierefreiheit betrifft die Frage, ob Menschen mit visuellen, auditiven, motorischen oder kognitiven Behinderungen das System wahrnehmen, bedienen und verstehen können. Bildschirmleseprogramme, Bildschirmlupen, Sprachsteuerung und Schaltersteuerung sind Beispiele für assistive Technologie.

WCAG 2.2 gliedert die Barrierefreiheit im Web in wahrnehmbar, bedienbar, verständlich und robust. Die Kriterien haben die Stufen A, AA und AAA. Viele Organisationen verwenden AA; diese Stufe schließt auch die Anforderungen von A ein. Die WCAG wurden für Webinhalte verfasst und dienen auch als Orientierung für Apps und Dokumente.

Praktische Prüfungen umfassen:

• Erledige die Aufgabe mit der Tastatur und halte den Fokus sichtbar.
• Prüfe mit einem Bildschirmleseprogramm, ob Schaltflächen, Felder und Überschriften aussagekräftige Namen haben.
• Vergrößere Text auf 200 % und prüfe, ob Inhalte oder Funktionen verloren gehen.
• Bestätige, dass die Bedeutung nicht allein von Farbe abhängt und Videos Untertitel haben.
• Prüfe die Größe der Ziele für den Zeiger. WCAG 2.2 AA verwendet ein Minimum von 24 mal 24 CSS-Pixeln mit festgelegten Ausnahmen.

Kontrast genau beurteilen

Für normalen Text beträgt das Mindestkontrastverhältnis auf Stufe AA 4,5:1. Für großen Text beträgt es 3:1. Groß bedeutet mindestens 18 Punkt oder 14 Punkt bei Fettschrift. Dies sind Verhältnisse zwischen Vorder- und Hintergrund von 1:1 bis 21:1.

Ein Kontrastprüfwerkzeug ergibt für #767676 auf Weiß etwa 4,54:1; damit wird der Schwellenwert für normalen Text erfüllt. #777777 ergibt etwa 4,48:1: Das genügt nicht für normalen, aber für großen Text. Runde einen Wert unter dem Schwellenwert nicht auf, damit er besteht.

Die tatsächliche Einrichtung des Benutzers testen

Konfiguriere die benötigte Vergrößerung, Skalierung, Kontrastdesigns, Zeigergröße, das Bildschirmleseprogramm, Liveuntertitel, die Einrastfunktion oder Diktieren. Bestätige, dass die Einstellungen nach Abmeldung und Neustart erhalten bleiben, und führe dann die Geschäftsaufgabe damit aus. Auf einem Bildschirm, der bei der Skalierung der Fachkraft korrekt aussieht, kann bei der 200-%-Einstellung des Benutzers ein Bedienelement verloren gehen.

Automatisierte Prüfwerkzeuge finden Probleme wie fehlende Textalternativen und geringen Kontrast. Sie können nicht vollständig beurteilen, ob Beschreibungen aussagekräftig und Lesereihenfolgen sinnvoll sind oder ob Aufgaben praktisch erledigt werden können. Ergänze manuelle Prüfungen mit Tastatur und Bildschirmleseprogramm und beziehe nach Möglichkeit Benutzer mit ihrer eigenen assistiven Technologie ein.

Sicherheitsprüfungen bestätigen, dass erforderliche Schutzmaßnahmen vorhanden sind und richtig wirken. Eine blockierte Aktion kann das erfolgreiche Ergebnis sein: Ein Vertriebskonto sollte Vertriebsdateien nutzen können, während ihm der Zugriff auf geschützte Personalunterlagen verweigert wird.

Wissen, was geschützt wird

Vertraulichkeit beschränkt, wer Daten sehen kann. Integrität schützt Daten und Einstellungen vor unzulässigen Änderungen. Verfügbarkeit hält das System für die Menschen nutzbar, die es benötigen. Sicherheitstests auf Supportebene verbinden diese Ziele mit vereinbarten Konto-, Geräte- und Netzwerkeinstellungen.

Teste nur Systeme, für deren Prüfung du berechtigt bist, und halte den vereinbarten Umfang ein. Scans, das Erraten von Passwörtern und Umgehungsversuche benötigen eine Erlaubnis; spezialisierte Penetrationstests erfolgen auf Grundlage einer schriftlichen Vereinbarung.

Identitäten und Berechtigungen prüfen

Wende das Prinzip der geringsten Rechte an: Gib einem Konto nur den Zugriff, den seine Rolle benötigt. Prüfe Gruppenmitgliedschaften, benötigte Freigaben, Passwortrichtlinie, MFA, Kontosperrung, deaktivierte Gastkonten oder ungenutzte Konten sowie die Entfernung von Konten ausgeschiedener Mitarbeiter. Ändere werkseitige Passwörter auf Geräten und in Anwendungen.

Nutze sowohl erlaubte als auch verbotene Aktionen. Bestätige, dass ein Standardbenutzer den benötigten Ordner öffnen kann, und bestätige dann, dass ein geschützter Ordner dieser Rolle den Zugriff verweigert. Bei einer Installation, die Administratorrechte benötigt, ist das erwartete Ergebnis eine Aufforderung zur Eingabe von Administratorzugangsdaten, die der Standardbenutzer allein nicht erfüllen kann.

Ein Standardbenutzerkonto verhindert nicht jede Softwareinstallation: Manche Programme werden im Benutzerprofil installiert. Lautet die Anforderung „keine Softwareinstallationen“, wird zusätzlich eine Richtlinie zur Anwendungssteuerung benötigt, die ebenfalls getestet werden muss. Leite aus einer Prüfung der Administratorrechte keine weitergehende Aussage über sämtliche Software ab.

Geräte- und Netzwerkeinstellungen untersuchen

Prüfe den Firewallstatus für alle Netzwerkprofile, aktiven Endpunktschutz und aktuelle Definitionen, Datenträgerverschlüsselung, Bildschirmsperre bei Inaktivität, erforderliche Updates sowie deaktivierte, nicht benötigte Dienste oder Fernzugriffe. Bestätige die benötigten Netzwerkports und den zugelassenen WLAN-Schutz wie WPA2 oder WPA3.

Unter Windows kann eine autorisierte Eingabeaufforderung mit erhöhten Rechten manage-bde -status C: ausführen. Prüfe beim Systemlaufwerk auf „Protection On“. PowerShell kann die Zustände der Firewallprofile auflisten:

Get-NetFirewallProfile | Select-Object Name, Enabled

Domain, Private und Public sollten jeweils „True“ anzeigen, wenn die Anforderung für alle Profile aktiviert ist. Bei einem lokalen Konto hilft net user t.sales, den aktiven Status und die Gruppenmitgliedschaft zu prüfen. Unter macOS meldet fdesetup status den FileVault-Status. Dokumentiere die tatsächliche Ausgabe und vergleiche sie mit der Anforderung.

Daten und Ausnahmen kontrollieren

Prüfe, ob sensible Dateien an zugelassenen Orten liegen, nur für die richtigen Rollen zugänglich und bei Bedarf durch Verschlüsselung geschützt sind. Entferne Testdaten und Dateien der Fachkraft vor der Übergabe. Wende erforderliche Anmeldehinweise und Datenschutzeinstellungen an.

Prüfe gezielt auf häufige Konfigurationsrisiken: zu weit gefasste Berechtigungen, schwache Authentifizierung, fehlende Patches, erreichbaren Fernzugriff und unsichere Standardeinstellungen. Eine Einstellung in einer zentralen Verwaltungsoberfläche genügt nicht, wenn sie auf dem Gerät nicht angewendet wurde.

Sicherheitseinstellungen können den Aufwand für Benutzer erhöhen: MFA-Abfragen und kürzere Sperrintervalle sind Beispiele. Teste die vereinbarte Richtlinie und dokumentiere jede beantragte Ausnahme zur Genehmigung durch die sicherheitsverantwortliche Person. Eine persönliche Vorliebe berechtigt nicht dazu, eine erforderliche Schutzmaßnahme abzuschwächen.

Ein Ergebnis ist nützlich, wenn eine andere Person erkennen kann, was erwartet wurde, was geschah und wie beides zueinander steht. Halte beim Testen Fakten fest, auch Fehlschläge, die später korrigiert werden.

Den Status anhand der Belege wählen

Formuliere das erwartete Ergebnis vor dem Test anhand der Anforderung. Dokumentiere das tatsächliche Ergebnis, während es eintritt. Eine Übereinstimmung bedeutet bestanden; eine Abweichung bedeutet fehlgeschlagen. Beurteile den Schweregrad dieser Abweichung getrennt davon.

Ein Netzwerkausfall, der einen E-Mail-Test verhindert, macht ihn zu einem blockierten Test. Er zeigt nicht, dass E-Mail den Test bestanden hat oder durchgefallen ist. Halte diese Lücke im Bericht sichtbar.

Für Kollegen nutzbare Belege dokumentieren

Halte Testfall- und Anforderungs-IDs, Gerät, Konto, testende Person, Datum und genaue Uhrzeit fest. Nimm die Schritte, Messwerte mit Einheiten, Fehlertexte und -codes sowie relevante Bildschirmfotos und Protokolleinträge auf. Verwende eindeutige Daten wie 2026-10-21 und einheitliche Statusbezeichnungen.

„Drucken funktioniert nicht“ lässt zu viel offen. Ein besserer Eintrag lautet: „Um 10:42 Uhr blieb der Druckauftrag aus der Textverarbeitung 30 Sekunden in der Warteschlange, dann erschien ‚Error – Printing‘; das Protokoll des Druckdienstes verzeichnete um 10:42 Uhr einen Fehler.“ Er trennt sichtbare Beobachtungen von einer Vermutung über ihre Ursache.

Jede Fehlerwirkung benötigt einen Fehlerbericht mit eindeutiger ID, Titel, Umgebung, Schritten zur Reproduktion, erwartetem und tatsächlichem Ergebnis, Belegen, Schweregrad, Priorität und aktuellem Status. Verknüpfe den Bericht mit dem Test, damit eine prüfende Person ihn bis zur Korrektur und zum Fehlernachtest verfolgen kann.

Auswirkung und Dringlichkeit trennen

Der Schweregrad misst die Auswirkungen des Fehlerzustands. Die Priorität gibt an, wie bald er behoben werden sollte. Beide stimmen häufig überein, dienen aber unterschiedlichen Entscheidungen. Ein falsch geschriebener Firmenname auf einem Anmeldebildschirm hat einen niedrigen Schweregrad, kann aber vor einer Einführung für Kunden dringend sein. Ein Problem mit großen Auswirkungen in einem Jahresbericht kann eine niedrigere unmittelbare Priorität haben, wenn der Bericht gerade nicht ansteht.

Nutze eine niedrige Priorität nicht, um große Auswirkungen zu verdecken. Die Freigabeentscheidung berücksichtigt weiterhin Schweregrad und Muss-Anforderungen.

Die Grundlage jeder Quote angeben

Angenommen, 48 Testfälle waren geplant: 42 bestehen, 3 schlagen fehl, 2 sind blockiert und 1 wird nicht durchgeführt. Durchgeführt wurden die bestandenen und fehlgeschlagenen Fälle, also 45. Die Bestehensquote der durchgeführten Tests beträgt etwa 93,3 %; die der geplanten Tests beträgt 87,5 %. Beide beschreiben dieselben Ergebnisse mit unterschiedlichen Bezugsgrößen.

Gib neben Prozentwerten auch Anzahlen an, damit die drei nicht durchgeführten Fälle nicht hinter einer hohen Quote verschwinden. Suche nach Mustern über Geräte, Zeiten, Builds und Netzwerke hinweg: Drei Fehlschläge aus einer Lieferung deuten auf eine gemeinsame Ursache hin, die untersucht werden sollte, beweisen diese Ursache aber nicht.

Behalte das ursprüngliche fehlgeschlagene Ergebnis, wenn eine Korrektur erfolgt. Ergänze Korrektur und Ergebnis des Fehlernachtests mit Datum. Das Überschreiben der fehlgeschlagenen Zeile zerstört Belege für die Änderung und macht die Dokumentation irreführend.

Protokolle zeigen Ereignisse innerhalb eines Systems, die möglicherweise nicht auf dem Bildschirm erscheinen. Werte sie zusammen mit dem Aufgabenergebnis und Performance-Messungen aus, um den zeitlichen Ablauf zu rekonstruieren.

Den relevanten Eintrag finden

Ein Systemprotokoll ist eine mit Zeitstempeln versehene Aufzeichnung von Ereignissen, Fehlern und Zugriffsaktivitäten. Die Windows-Ereignisanzeige enthält die Protokolle Anwendung, Sicherheit, Installation, System und weitergeleitete Ereignisse sowie komponentenspezifische Anwendungs- und Dienstprotokolle. Einträge haben Felder wie Uhrzeit, Quelle, Ereignis-ID, Ebene und Beschreibung.

Zu den Windows-Ebenen gehören Kritisch, Fehler, Warnung, Informationen und Ausführlich. Sicherheitsereignisse verwenden Überwachung erfolgreich oder Überwachung fehlgeschlagen. Eine fehlgeschlagene Überwachung kann bei einem Negativtest erwartet sein, etwa bei einem verbotenen Anmeldeversuch; ihre Bedeutung hängt vom erwarteten Testergebnis ab.

Nutze unter Linux journalctl für das systemd-Journal und relevante Dateien unter /var/log. Nutze unter macOS die Konsole. Die Standard-Schweregrade von Syslog reichen von 0, Notfall, über Alarm, Kritisch, Fehler, Warnung, Hinweis und Information bis 7, Debug. Eine niedrigere Syslog-Zahl bedeutet einen höheren Schweregrad.

Nach Zeit und Identität zuordnen

Prüfe vor einem Test Geräteuhr und Zeitzone. Notiere die Uhrzeit jedes Schritts und filtere das relevante Protokoll nach diesem Zeitfenster und der Quelle. Lies sowohl Ereignisse unmittelbar vor der Fehlerwirkung als auch die Fehlerwirkung selbst. Vergleiche sie mit dem fehlerfreien Verhalten der Referenz, da einige Warnungen regelmäßig auftreten.

Bei einer um 10:42 Uhr fehlgeschlagenen Laufwerksverbindung folgt auf ein IP-Adressereignis um 10:41:58 Uhr eine DNS-Zeitüberschreitung für files.example.com um 10:42:05 Uhr und ein Fehler der Laufwerksverbindung um 10:42:06 Uhr. Sichere die Einträge zur Zeitüberschreitung und zur Laufwerksverbindung zusammen. Sie lenken die Untersuchung auf die Namensauflösung, belegen aber für sich genommen nicht die endgültige Ursache.

Kontoereignisse verstehen

Das Windows-Sicherheitsereignis 4624 dokumentiert eine erfolgreiche Anmeldung; 4625 eine fehlgeschlagene Anmeldung; 4740 eine Kontosperrung. Sie hängen von aktivierter Überwachung ab. Für die relevanten 4625-Einträge ist die Überwachung fehlgeschlagener Anmeldungen nötig; 4740 benötigt die Überwachung erfolgreicher Benutzerkontenverwaltung.

Ein Kontosperrungstest kann mehrere Ereignisse zu fehlgeschlagenen Anmeldungen erzeugen, darunter ein weiteres, wenn das richtige Passwort nach der Sperrung abgelehnt wird. Bei einem Domänenkonto können Belege auf verschiedenen Computern liegen, darunter auf dem Domänencontroller, der das Konto verwaltet. Ordne Konto, Uhrzeit und Computer zu. Erwarte keine feste Ereignisfolge in einem einzigen Protokoll.

Alarmmeldungen und Verläufe im Kontext lesen

Eine Alarmmeldung benachrichtigt jemanden, wenn ein festgelegtes Ereignis eintritt oder ein Schwellenwert erreicht wird: ein angehaltener Dienst, eine fehlgeschlagene Datensicherung oder ein nahezu voller Datenträger. Stelle eine erforderliche Alarmbedingung in der Testumgebung sicher her und bestätige, dass die Alarmmeldung ankommt. Halte Ziel und Zeitpunkt fest.

Leistungskennzahlen umfassen Prozessorauslastung, verfügbaren Arbeitsspeicher, freien Speicherplatz, Datenträgeraktivität, Durchsatz, Latenz, Verlust und Antwortzeit. Eine kurze Prozessorspitze bei der Anmeldung unterscheidet sich von mehreren Minuten mit 95 % bei Inaktivität. Vergleiche Dauer, Arbeitslast und Referenzwerte.

Suche nach wiederkehrenden Zeitabständen, Fehlschlägen nach Neustarts oder Problemen, die auf ein Subnetz beschränkt sind. Übernimm relevante IDs und Meldungen in den Ergebniseintrag. Eine Warnung ist ein zu deutender Hinweis und kein automatischer Fehlerzustand; ein unauffälliger Bildschirm ist kein Grund, bei kritischen Tests auf Protokolle zu verzichten.

Automatisierung kann eine Prüfung auf vielen Systemen wiederholen, ohne durch Ermüdung Schritte auszulassen. Ihr Wert hängt davon ab, was die Prüfung tatsächlich belegt und ob jemand das Ergebnis überprüft hat.

Wiederholbare Arbeit an Werkzeuge geben

PowerShell- und Bash-Skripte können Einstellungen untersuchen, Makros Aktionen wiederholen, Oberflächenwerkzeuge Anwendungsaufgaben ausführen und Überwachungswerkzeuge Messwerte sammeln. Konfigurations-, Schwachstellen- und Barrierefreiheitsscanner vergleichen ausgewählte Merkmale mit Regeln oder Referenzwerten.

Diese Werkzeuge eignen sich für Regressionstests und Prüfungen, die auf jedem Gerät benötigt werden. Ein Skriptfehler wiederholt sich ebenfalls auf jedem Gerät. Vergleiche daher zuerst sein Ergebnis mit einem bekannten System und einer manuellen Prüfung. Aktualisiere das Werkzeug, wenn sich das System ändert. Wiederholung macht eine Methode einheitlich, aber keine falsche Methode richtig.

Die Aussage auf die Prüfung begrenzen

Test-NetConnection files.example.com -Port 445 kann „TcpTestSucceeded : True“ melden. Das belegt, dass eine TCP-Verbindung zu diesem Serverport erfolgreich war. Es belegt nicht, dass der Benutzer eine Freigabe öffnen, ein Dokument erstellen oder es speichern kann.

Um Dateizugriff nachzuweisen, führe die Benutzeraufgabe mit den richtigen Berechtigungen aus und prüfe ihr Ergebnis. Eine Portprüfung und ein funktionaler Aufgabentest liefern unterschiedliche Belege. Ihre Kombination kann helfen, eine Fehlerwirkung einzugrenzen, aber keiner ersetzt den anderen.

Ein falsch positives Ergebnis ist ein gemeldetes Problem, das nicht besteht. Ein falsch negatives Ergebnis ist ein tatsächliches Problem, das das Werkzeug übersieht. Ein falsch positives Ergebnis kann Zeit verschwenden oder die Übergabe verzögern; ein falsch negatives Ergebnis kann trügerisches Vertrauen erzeugen. Ihr jeweiliger Schaden hängt von der Prüfung ab. Eine unsichere Sicherheitseinstellung zu übersehen, ist meist schwerwiegender, als sie unnötig zur Überprüfung zu markieren.

Einen KI-Entwurf vor der Nutzung prüfen

KI-Werkzeuge können Testfälle und Daten vorschlagen, Protokolle zusammenfassen, auf mögliche Muster hinweisen und Berichte entwerfen. Sie können auch Befehle erfinden, wichtige Fälle auslassen oder Schlussfolgerungen schreiben, die die Belege nicht stützen.

Ordne erzeugte Testfälle der Anforderungsliste zu. Ergänze fehlende Negativ-, Grenzwert- und Barrierefreiheitsprüfungen. Prüfe vorgeschlagene Befehle anhand der offiziellen Dokumentation und probiere sie dann in der Testumgebung aus. Vergleiche eine Protokollzusammenfassung mit den ursprünglichen Zeilen, einschließlich der Zeitstempel und Konten, die sie zu beschreiben vorgibt.

Bei einem Passwortbereich von 12–64 Zeichen und einer Sperrung nach fünf Fehlversuchen ist ein Entwurf mit einem Passwort aus 15 Zeichen und einem Testfall mit fünf Fehlversuchen unvollständig. Ergänze die Längen 11, 12, 64 und 65, prüfe, dass vier Fehlversuche das Konto nicht sperren, und teste die Entsperrung. Lege passende Ausgangsbedingungen fest, damit jeder Fall die vorgesehene Regel misst.

Die abnehmende Person bleibt für die Ergebnisse verantwortlich. Zur Überprüfung gehört, ob die Schlussfolgerung eines Werkzeugs über seine Messungen hinausgeht, nicht nur die Korrektur seiner Rechtschreibung.

Verarbeitete Informationen schützen

Verwende für Arbeitsmaterial nur von der Organisation zugelassene KI-Dienste. Füge keine Passwörter, personenbezogenen Daten, vertraulichen Protokolle oder internen Hostnamen in einen nicht zugelassenen Dienst ein. Maskiere sensible Werte und halte Nutzungs- und Datenschutzrichtlinien ein. Eine nützliche Zusammenfassung rechtfertigt nicht, die darin zusammengefassten Informationen offenzulegen.

Prüfungen der Betriebsbereitschaft bestätigen den Zustand des tatsächlichen Geräts oder Systems unmittelbar vor der Übergabe. Frühere Testbelege können einen älteren Build, ein anderes Konto oder ein Stichprobengerät beschreiben. Führe deshalb für jedes ausgelieferte Gerät eine unterschriebene und datierte Checkliste.

Benutzer und Verbindungen prüfen

Bestätige, dass das Konto existiert, aktiviert ist und den richtigen Gruppen angehört. Prüfe gegebenenfalls die Anmeldung, die Änderung des temporären Passworts und die MFA-Einrichtung. Entferne Testkonten und das Profil der Fachkraft und vergib keine Administratorrechte, sofern die Rolle sie nicht erfordert.

Prüfe Adresse, Gateway und DNS-Server. Unter Windows zeigt ipconfig /all die IP-Konfiguration. Unter Linux zeigt ip a die Adressen, ip route die Routen einschließlich des Standardgateways und resolvectl status das DNS auf Systemen mit systemd-resolved. ip a allein belegt weder die Gateway- noch die DNS-Konfiguration.

Nutze ping, um zu prüfen, ob Netzwerkziele antworten, nslookup für die Namensauflösung und eine Dienstportprüfung wie Test-NetConnection für benötigte Dienste. Führe anschließend die tatsächliche Aufgabe aus. Manche Netzwerke blockieren Ping, daher belegt eine ausbleibende Antwort allein nicht, dass alle Dienste nicht verfügbar sind. Bestätige benötigte WLAN-Profile, VPN, Freigaben und Drucker.

Speicherplatz mit der Anforderung vergleichen

Prüfe freien Speicherplatz, Kontingente, Netzwerkspeicher, Cloudsynchronisierung und Datensicherung. Ein als 512 GB verkauftes Laufwerk fasst 512 Milliarden Byte. Die Division durch 2³⁰ ergibt etwa 476,8 GiB; Windows bezeichnet diese binär berechnete Zahl gewöhnlich als „GB“.

Verwende für das Kriterium „mindestens 20 % frei“ Werte für freien und gesamten Speicherplatz auf derselben Messgrundlage. Zwanzig Prozent von 476,8 sind etwa 95,4. Sind 61,2 frei, beträgt der Anteil etwa 12,8 %, und die Prüfung schlägt fehl. Entferne gegebenenfalls verbliebene Installations- und Testdateien und miss erneut. Wer 61,2 mit den beworbenen 512 vergleicht, ohne die Einheiten zu berücksichtigen, vermischt Messgrundlagen.

Updates und Schutz bestätigen

Prüfe Betriebssystem, Anwendungen, Browser, Treiber und Firmware anhand der erforderlichen Versionen. Führe ausstehende Neustarts durch und aktualisiere die Definitionen des Endpunktschutzes. Windows Update und winver, das macOS-Softwareupdate und die Linux-Paketverwaltung liefern relevante Belege.

Prüfe Datenträgerverschlüsselung, Firewall, aktiven Endpunktschutz, Zeit bis zur Bildschirmsperre, geänderte Standardpasswörter und deaktivierte, nicht benötigte Dienste. Bestätige die zugelassenen Einstellungen für Dateispeicherung und Datensicherung am Gerät selbst, nicht nur in einer Verwaltungskonsole, die das Senden der Richtlinie meldet.

Mit der funktionierenden Aufgabe abschließen

Führe einen Smoke-Test der erwarteten Funktionen und Performance durch. Erledige Benutzeraufgaben als Benutzer oder mit einem gleichwertigen Konto. Verwende autorisierte Administratorrechte nur für Prüfungen, die sie benötigen, etwa ein Werkzeug mit erhöhten Rechten zur Prüfung des Verschlüsselungsstatus.

Fehlt ein VPN-Profil, dokumentiere die fehlgeschlagene Prüfung, ergänze das Profil nach dem zugelassenen Verfahren und wiederhole den VPN-Zugriff und alle betroffenen Aufgaben. Halte Korrektur und erneute Prüfung in der Dokumentation dieses Geräts fest. Die Prüfung eines anderen Laptops desselben Modells belegt nicht den Zustand dieses Geräts.

Eine Empfehlung zur Betriebsbereitschaft vergleicht die Belege mit den Anforderungen und Endekriterien. Der Verantwortliche muss sehen können, was bestanden wurde, was offen bleibt und welche Risiken bei einer sofortigen Inbetriebnahme akzeptiert würden.

Die Entscheidung aus den Aufzeichnungen ableiten

Berücksichtige zuerst jeden geplanten Testfall, einschließlich blockierter und ausgelassener Tests. Bestätige die Muss-Anforderungen, prüfe Fehlerzustände nach Schweregrad und vervollständige die Checkliste zur Betriebsbereitschaft. Berücksichtige das Risiko offener Probleme und die Auswirkungen einer Verzögerung. Schreibe eine begründete Empfehlung für die zur Abnahme des Systems berechtigte Person.

Typische Ergebnisse sind freigegeben, freigegeben unter Auflagen und nicht freigegeben. Auflagen nennen bekannte geringfügige Probleme, praktikable Workarounds und einen Termin für die Korrektur. Ein ungelöstes Problem mit hohem Schweregrad, das eine Muss-Anforderung betrifft, verhindert üblicherweise die Freigabe; die vereinbarten Endekriterien bestimmen die Entscheidung.

Eine hohe Gesamtbestehensquote kann eine nicht erfüllte Muss-Anforderung nicht aufheben. Ebenso muss ein Problem mit geringen Auswirkungen nicht jedes Gerät aufhalten, wenn der Verantwortliche es nach den Kriterien akzeptieren kann.

Betroffene Systeme unterscheiden

Angenommen, bei 12 Vertriebslaptops verlieren drei nach zehn Minuten Inaktivität den VPN-Zugriff und alle haben das falsche Hintergrundbild. Die VPN-Nutzung aus der Ferne ist eine Muss-Anforderung und die Endekriterien erlauben keine offenen Fehlerzustände mit hohem Schweregrad.

Die drei Geräte mit dem VPN-Fehlerzustand sind erst nach Korrektur und Fehlernachtest betriebsbereit. Die anderen neun können zur Übergabe empfohlen werden, wenn das Hintergrundbildproblem mit niedrigem Schweregrad dokumentiert und akzeptiert wird. Benenne die einzelnen Geräte in der Entscheidung; eine Aussage über die gesamte Lieferung würde den Unterschied verdecken.

Dasselbe Prinzip gilt für eine Teilmenge von Aufgaben nur dann, wenn der Verantwortliche diesen Umfang vereinbart hat. Eine Fachkraft darf eine nicht erfüllte Anforderung nicht stillschweigend entfernen, um ein bestandenes Ergebnis zu erzeugen.

Den vereinbarten Schwellenwert anwenden

Ein Kriterium von „95 % von 20 Aufrufen unter 2 Sekunden“ benötigt 19 passende Aufrufe. Achtzehn ergeben 90 % und bestehen damit nicht, auch wenn die Anwendung nach Aussage der Benutzer schnell wirkt. Dokumentiere die Unterschreitung als Fehlschlag. Akzeptiert der Verantwortliche das Risiko, behalte die fehlgeschlagene Messung und dokumentiere, wer die Ausnahme akzeptiert hat.

Anforderungen können in der Praxis miteinander in Konflikt stehen. Ein Schadsoftwarescan beim Start kann die Anmeldung verlangsamen oder MFA einen Schritt hinzufügen. Gib die gemessene Einbuße, den von der Richtlinie geforderten Sicherheitsgewinn und den genehmigten Kompromiss an. Ändere weder stillschweigend einen Schwellenwert noch schwäche eine Schutzmaßnahme ab, damit beide Tests scheinbar bestehen.

Den Bericht überprüfbar machen

Ein Testabschlussbericht nennt Umfang, Umgebung und Daten; Anzahlen nach Status; Bestehensquoten mit ihren Bezugsgrößen; offene Fehlerzustände und Schweregrade; Abweichungen vom Konzept; verbleibende Risiken und die begründete Empfehlung. Verknüpfe Schlussfolgerungen mit Testfallergebnissen, Protokollen oder Belegen aus der Checkliste.

„Keine Fehlerzustände gefunden“ beschreibt die durchgeführten Tests. Nenne nicht getestete Bereiche, damit dies nicht als Zusicherung verstanden wird, dass es nirgendwo Fehlerzustände gibt. Auch das Erreichen einer Frist erfüllt keine Endekriterien: Jedes akzeptierte Risiko muss vom zuständigen Verantwortlichen dokumentiert werden.

Nutze nach einem Update oder einer Konfigurationsänderung Regressionstests und Prüfungen der Betriebsbereitschaft, um die weitere Eignung für den Einsatz zu bestätigen. Eine frühere Abnahme gilt für den getesteten Zustand; geändertes Verhalten benötigt neue Belege.

Die Übergabe gibt Benutzern ein funktionierendes System und dem Supportteam genügend Informationen, um es zu betreuen. Die Abnahme hält fest, wer wann bestätigt hat, dass es betriebsbereit ist, und welche Auflagen verbleiben.

Vorbereiten, was jede Zielgruppe benötigt

Benutzer benötigen das Gerät oder den Dienst, sicher übermittelte Anmeldedaten, eine kurze Kurzanleitung, installierte Anwendungen und verbundene Ressourcen, bekannte Probleme mit Workarounds und eine Anleitung, wie sie Hilfe erhalten. Technische Kollegen benötigen außerdem die Konfigurationsdokumentation und die Belege für akzeptierte Probleme.

Dokumentiere Konfigurationsentscheidungen mit ihren Gründen. „Bildschirmsperre nach fünf Minuten, gemäß Sicherheitsrichtlinie erforderlich“ erklärt mehr als die Einstellung allein. „Anzeigeskalierung 150 % wegen Sehbehinderung“ hilft der nächsten Fachkraft, eine wichtige Anpassung bei Support oder Neueinrichtung beizubehalten.

Die Führungskraft benötigt das Ergebnis zur Betriebsbereitschaft, verbleibende Risiken und Entscheidungen, die eine Genehmigung erfordern. Ein Benutzer benötigt normalerweise die Schritte für die erste Anmeldung und Informationen zur Erledigung täglicher Aufgaben. Erhalten beide denselben technischen Bericht, ist der jeweils nützliche Teil schwerer zu finden.

Zugang sicher übermitteln

Sende Benutzernamen und temporäres Passwort über getrennte Kanäle. Verlange, dass das temporäre Passwort bei der ersten Anmeldung geändert wird. Befestige kein Passwort am Gerät und füge es nicht in dieselbe Nachricht wie den Benutzernamen ein.

Bestätige die MFA-Einrichtung oder das vereinbarte Verfahren bei der ersten Nutzung. Entferne Testkonten, Testdateien und unnötigen Zugriff der Fachkraft, bevor der Benutzer die Verantwortung für das Gerät übernimmt. Das Supportteam sollte nicht rätseln müssen, welche temporären Änderungen bestehen bleiben.

Benutzerabnahme dokumentieren

Bitte den Benutzer oder Verantwortlichen, die wichtigsten Aufgaben auszuführen, häufig in einem kurzen gemeinsamen Durchgang oder einem Benutzerabnahmetest. Verwende realistische Beispieldaten in einer Schulungsumgebung, wenn das Üben die Produktivarbeit nicht beeinflussen soll.

Die Abnahmebestätigung hält Datum, abnehmende Person und etwaige Auflagen fest. Bekannte Probleme benötigen ihre Workarounds und vereinbarte Korrekturtermine. Ein an einen Arbeitsplatz geliefertes Gerät ohne Abnahme ergibt keine vollständige Übergabedokumentation.

Eine Nachricht an den Benutzer kann lauten: „Dein neuer Laptop ist bereit. Melde dich mit deinem gewohnten Benutzernamen an und wähle ein neues Passwort, wenn du dazu aufgefordert wirst. Bleibt der zweite Bildschirm nach dem Energiesparmodus dunkel, ziehe das Kabel der Dockingstation ab und stecke es wieder ein. Wende dich an den Service Desk, wenn das Problem weiterhin besteht.“ Der Workaround nennt eine Handlung, die die Person ausführen kann; technische Erkenntnisse bleiben in der Supportdokumentation.

Die ersten Nutzungstage begleiten

Zeige neue Funktionen oder geänderte Arbeitsabläufe kurz. Weise Benutzer auf den Service Desk hin und zeige, wie sie ein Ticket erstellen. Erfasse Rückfragen, antworte innerhalb der vereinbarten Servicezeiten und eskaliere Probleme, die du nicht lösen kannst. Kommuniziere respektvoll und vermeide es, einen nicht bestätigten Behebungstermin zu versprechen.

Beobachte nach der Übergabe Protokolle, Alarmmeldungen und Benutzerrückmeldungen genau. Manche Fehlerwirkungen treten erst bei tatsächlichen Arbeitslasten oder selteneren Aufgaben auf. Ergänze nützliche Erkenntnisse in der Checkliste und im Testkonzept für die nächste Bereitstellung. Ein akzeptiertes bekanntes Problem bleibt für Benutzer und Support sichtbar, bis es behoben und erneut getestet wurde.