Praxis-Tests planen

Letzte Änderung: 10/2023

Ein Praxis-Test im Team dauert in der Regel länger als ein Experten-Test durch nur eine Prüfende (in beiden Fällen folgt dann in der Regel eine abschließende Qualitätssicherung, die auch Zeit braucht). Dies schlägt sich auch in der Kalkulation des Aufwands und im Termin der Fertigstellung nieder.

Der Zeitaufwand hängt natürlich stark von der Erfahrung und dem Grad der Expertise bei Prüfenden und Assistierenden, und auch von der Team-Konstellation ab.

In der Team-Konstellation blinde Prüfende mit sehender Assistenz im internen Team bei DIAS war die Assistenz im Schnitt mit 50% des Zeitaufwands des blinden Prüfers eingebunden.

Hat das Team ausreichend Kapazität?

Bevor der Aufwand getrieben wird, mit dem Kunden in Kontakt zu treten und Fragen zu klären und ein Angebot zu erstellen, ist es sinnvoll, die verfügbare Kapazität des Teams unter Berücksichtigung anderer Aufgaben zu prüfen. Folgendes ist zu klären:

Ist bei Sichtung der Auftragslage im Team genügend Kapazität für den grob geschätzten Umfang des Tests vorhanden?
Falls das Team derzeit keine Kapazität hat: Kann der Test geschoben werden?
Kann der Test von anderen Personen übernommen werden, falls das Team während des Tests ausfallen sollte?
Ist ein Werkvertrag oder Unterbeauftragung formal möglich oder ausgeschlossen?

Ist der Gegenstand geeignet für die Prüfung?

Wenn Prüfende eine Behinderung haben, sollte das Angebot daraufhin untersucht werden, ob es sich für die Prüfung eignet bzw. diese effizient durchführbar ist. Beispiele, wann das nicht der Fall ist:

Screenreader-nutzende Prüfende: Wichtige Teile des Angebots sind komplett unzugänglich, d. h. es wird nichts ausgegeben, Elemente sind nicht mit der Tastatur oder – bei Apps – mit Wischgesten erreichbar. In diesem Fall macht eine Prüfung durch Screenreader-Nutzende wenig Sinn, der Aufwand wäre zu hoch.
Tastatur-nutzende Prüfende: Die Erreichbarkeit von Elementen über Tastatur oder Hilfsmittel, die auf der Tastaturerreichbarkeit aufsetzen, ist generell sehr schlecht. Es sollte abgewogen werden, ob dennoch eine Durchführung sinnvoll ist.
Spracheingabe-nutzende Prüfende: Bei effizienten Nutzung der virtuellen Mauseingabe über sprachgesteuertes Gitter sind auch Angebote prüfbar, die für Tastaturnutzer schlecht zugänglich sind. Der Zeitaufwand ist meist deutlich höher.

Je schlechter die Zugänglichkeit des zu prüfenden Angebots, desto zentraler ist die Einbeziehung der Assistenz. Wenn Assistierende selbst sehr gute inhaltliche Kenntnisse haben, ist eine Prüfung eher denkbar als in einer Situation, wo sie größtenteils von Prüfenden mit Behinderung angeleitet werden.

Hat das Team die notwendige technische Infrastruktur?

Sind erforderliche aktuelle Testgeräte und Peripherie (Tastaturen) vorhanden (gleiche Geräte bzw. OS-, Hilfsmittel- und App-Versionen für Prüfende und Assistenz)?
Sind Teams- oder Zoom-Accounts bzw. andere Kanäle für die Remote-Prüfung durch Prüfende vorhanden?
Ist stabiler und performanter Netzwerkzugang, ggf. VPN usw. vorhanden?

Wie kalkuliert man den Aufwand für einen Praxis-Test?

Erfahrungsgemäß ist der Testaufwand gerade bei App-Tests oft nicht leicht einzuschätzen. Eine Reihe von Parametern kann einen Einfluss auf den tatsächlichen Aufwand haben. Wir stellen diese in Form einer Checkliste dar. Diese Parameter sollten vor Angebotserstellung bekannt sein oder, falls nicht, durch Rückfragen beim Kunden geklärt werden.

1. Formale und kommerzielle Rahmenbedingungen der Prüfung, Kommunikation

Legen Angebot und Auftrag den Prüfgegenstand und den Arbeitsumfang hinreichend verbindlich fest?
Ist geregelt, was passiert, wenn Zeitvorgaben durch vom Kunden oder vom Prüf-Team verursachte Gründe nicht eingehalten werden können?
Sind Aufwände für Kommunikation / Abstimmung mit dem Kunden inkludiert? Werden sie extra berechnet?
Werden Konferenzen mit Zwischenberichten, Fragerunde usw. erwartet?
Wenn die Kommunikationsumgebung vom Kunden vorgegeben ist, ist diese für Team-Mitglieder barrierefrei nutzbar (Stichwort Webex)?
Ist geklärt, ob Folgefragen a) zu den Ergebnissen und b) zur anschließenden Umsetzung Teil des Angebots sind?

2. Prüfgegenstand, Versionen

Ist die Anwendung öffentlich zugänglich oder nur in einer Entwickler-Version? Bei Apps: Ist die App im App Store zugänglich oder nur über TestFlight bzw. als APK-Datei verfügbar?
Ist das Angebot technisch stabil (nicht buggy)?
Kann eine stabile Version für den Testzeitraum zur Verfügung gestellt werden?
Falls nein, wird es eine Folge von sich ändernden Versionen geben? Dies kann den Aufwand extrem erhöhen.

3. Neue Inhalte

Ist mit Änderungen oder Erweiterungen des Prüfgegenstands während des Tests zu rechnen (z. B. neue Produkte, Angebotsformate, saisonale Sales mit unerwarteten Formaten, Voucher, Prompts mit Kundenbefragungen usw. in eCommerce-Webanwendungen oder -Apps)?

4. Technische Voraussetzungen (Accounts, Registrierung, Authentifizierung)

Ist vor der bzw. für die Nutzung das Anlegen von User-Konten erforderlich?
Stellt der Kunde User-Konten / Logins bereit bzw. Test-User Accounts?
Ist bei Einrichtung / vor Nutzung Authentifizierung notwendig?
Müssen Zahlungsinformationen hinterlegt werden?
Können Prozesse vollständig getestet werden, ohne dass den Prüfenden eigene Kosten entstehen (denkbar wären Dummy-User, 100% Rabatt Voucher, kostenlose Stornierungsmöglichkeiten bei Käufen o. ä.)?

5. Abhängigkeiten der Nutzung bzw. Testung von externen Faktoren

Benötigt die App-Testung Anwesenheit vor Ort, etwa wenn gleichzeitig physische Prozesse stattfinden, welche die App spiegelt (z. B. ein Ladevorgang)?
Verlangt der Test Interaktion mit lokalisierter Hardware (z. B. RFID-Sensoren an Türen, Verpackung usw.)?
Spielen Position und Ort des Prüfers (über GPS) eine wichtige Rolle?
Werden AR-Funktionen der App getestet, die Nutzung in einem bestimmten Kontext erzwingen?
Bestehen Abhängigkeiten zu anderen Apps, Prozessabhängigkeiten ("Test ist erst möglich, wenn…") Kundenvorgaben oder Ressourcen (Auth-Code Generatoren, Testpläne oder Vorgaben)?

6. Funktionseinschränkungen mit Auswirkung auf das Testen

Lassen sich Screenshots auf dem Testgerät erstellen (manche Apps verhindern das aus Datenschutz- oder Sicherheitsgründen)?
Sind manche Zustände oder Bereiche nur simuliert oder gar nicht zugänglich?

7. Reporting / Aufbereitung der Ergebnisse

Reporting: Ist das etablierte Format passend (z. B. Bericht strukturiert entlang der EN Kriterien)?
Wird Issue-Export oder eine zusätzliche abweichende Aufbereitung verlangt?
Braucht oder erwartet der Kunde zusätzlich eine Priorisierung der Ergebnisse?
Sind Screenshots erforderlich?
Werden konkrete Verweise auf Code-Beispiele erwartet?
Soll der Report in einer anderen Sprache vorliegen (z. B. Englisch)?
Gibt es Vorgaben für bestimmte Testumgebungen (z. B. muss mit Screenreader X oder auf Gerät Y getestet werden)?
Werden Aussagen zu zusätzlichen Anforderungen, etwa aus dem Bereich Gebrauchstauglichkeit, Erklärung zur Barrierefreiheit, rechtliche Auskünfte usw. verlangt?
Werden Videos erwartet, die bestimmte Abläufe / Probleme / Barrieren dokumentieren?

Wie erstellt man ein Angebot für einen Praxis-Test?

Nach Festlegung des Scope (was soll geprüft werden) und der Art der Prüfung ermöglicht eine Einschätzung des Aufwands (inklusive Risikoabwägung). Nun kann ein Angebot erstellt und ein Preis für die Leistung ermittelt werden.

Scope, repräsentativ oder nicht

Prüfende und Assistenz erstellen gemeinsam eine Seiten- bzw. Ansichten-Auswahl basierend auf dem kommunizierten Bedarf. Ist die Feststellung der Konformität (oder der Nicht-Konformität) das Ziel, muss die Seiten- bzw. Ansichten-Auswahl repräsentativ sein. Soll nur kurz getestet werden (wichtigste Findings) ist der Aufwand pro Seite / Ansicht natürlich geringer.

Auf Kundenwunsch können weitere Geräte (Tablets) bzw. Betriebssystem-Umgebungen oder Browser mit hinzugenommen werden. Dies kann häufig Abweichungen in den Ergebnissen bedingen, die dann differenziert erfasst werden müssten, etwa wenn der Test derselben App auf dem Smartphone anders läuft als auf einem Tablet.

Auf Kundenwunsch ist auch Ausschluss von externen Tastaturen im Test denkbar, Dem Kunden muss dann jedoch vermittelt werden, dass ein solcher Test dann kein Konformitätstest sein kann – wichtige Kriterien können ohne externe Tastatur nicht geprüft werden.

Art der Prüfung

Ein vollständiger Web- oder App-Test nach EN 301 549 enthält sehr viele Prüfschritte. Viele davon sind meist nicht anwendbar, andere ggf. redundant. Wenn der Kunde einen Gesamtüberblick über den Grad der Konformität benötigt, ist ein vollständiger Test aller Erfolgskriterien trotzdem sinnvoll. Braucht er erst einmal Hinweise auf die gravierendsten Barrieren, ist auch ein vereinfachter Test mit einer begrenzten Auswahl von Prüfschritten oder einem festgelegten Zeitlimit denkbar.

Preisfindung

Bei der Preisfindung sollten die unter Aufwandseinschätzung genannten Parameter berücksichtigt werden. Sie alle können den Aufwand erhöhen, in Kombination z. T. erheblich.

Basispreis und Komplexitätsfaktoren: Eine Möglichkeit ist, einen Basispreis für eine Ansicht festzulegen und diesen je nach Komplexität der Ansichten mit einem Faktor zu multiplizieren. Wieviel Zeit und Arbeit dann für wen im Prozess entsteht, wird nicht ausgewiesen.
Zeitbasierte Schätzung: Ein anderer Ansatz ist die Zeitschätzung mit verschiedenen Stundensätzen für den Prüfenden, die Assistenz und die Qualitätssicherung (QS), etwa über die Festlegung von geschätzten Aufwandsanteilen. Ein Richtwert ist 60% Prüfende, 30% Assistenz, 10% QS, aber das hängt davon ab, wie selbstständig die Assistenz arbeitet und welcher Art die Barrieren der App sind. Je weniger erfahren Prüfende und Assistenz sind, desto wichtiger wird die QS (und desto höher ihr Anteil).
Rabatte: Denkbar ist die Festlegung des Angebotspreises auf Basis des Scopes und der Aufwandschätzung, und das Einräumen eines Rabatts für einen Re-Tests des gleichen Angebots. Ähnliches gilt beim App-Test für die Durchführung eines zweiten parallelen Tests in der jeweils anderen Systemumgebung (Android oder iOS).

Mit dem Kunden ist ggf. zu klären, ob es Obergrenzen gibt, die zu beachten wären (z. B. wegen interner Grenzen oder formaler Vorgaben bezügl. Ausschreibungspflicht). Kann die Leistung ggf. in mehrere unabhängige Aufträge aufgeteilt werden?

Zeitrahmen

Lässt sich der Starttermin planen (Testgegenstand stabil verfügbar, Auftrag formal erteilt, Kapazität des Teams frei)?
Lässt sich die benötigte Zeitdauer des Tests einschätzen? Hier muss der Zeitbedarf für andere Verpflichtungen berücksichtigt werden. Eine Reihe von Faktoren (siehe: Wie kalkuliert man den Aufwand für einen Praxis-Test?) erhöhen das Risiko, die Zeitdauer und den Aufwand zu unterschätzen.