Im September haben unsere Tester 38 Bugs in sechs Live-Produkten erfasst, und keiner davon führte zu einem Absturz. Jeder war ein leiserer Fehler, etwa eine Meeting-Aufnahme mit einer stummen Lücke oder eine lange Beschreibung, die sich nicht speichern lässt. Beispiele für Softwarefehler dieser Art rutschen durch einen schnellen Check der Hauptfunktionen, weil die Probleme erst beginnen, wenn etwas Ungewöhnliches passiert, etwa ein eingehender Anruf oder ein entfernter Benutzer.
Jedes der folgenden Produkte durchlief einen Bug Crawl, bei dem einer unserer Ingenieure die App so nutzt, wie es ein neuer Kunde tun würde, und alles festhält, was nicht funktioniert. Manuelles Testen dieser Art findet, was automatisierte Prüfungen übersehen, weil ein Skript nur dem Pfad folgt, den jemand vorab geschrieben hat.
In diesem Digest behandelte Apps:
- Workdeck (SaaS)
- Truck Simulator: World (iOS)
- Bluedot AI Note Taker (Android)
- Laxis (web)
- Venue: Relaxing Design Game (iOS)
- AI Chatbot & Keyboard: Sage AI (iOS)
Frühere Berichte finden Sie im Bug-Crawl-Archiv.
Ein gelöschter Workdeck-Benutzer bekam eine Fehlermeldung statt des Anmeldebildschirms
- App: Workdeck (SaaS)
- Schweregrad: Kritisch
- Typ: Kontozugriff und Fehlermeldungen
Für den schwerwiegendsten Fehler in Workdeck brauchte es zwei Konten. Als Administrator angemeldet, entfernte unser Tester einen Teamkollegen, der noch eine aktive Sitzung hatte. Jeder Klick aus dem gelöschten Konto brachte danach “Error! Unexpected error” hervor, obwohl Workdeck diese Person hätte abmelden und die Anmeldeseite anzeigen sollen.
Mehrere weitere Fehler steckten in den Formularen, die Workdeck für Teamprojekte und Einstellungen nutzt. Das Aktivieren des Kontrollkästchens Timesheet erzeugte einen rohen technischen Hinweis, der mit “Invalid value ‘true’ supplied to” begann. Das Absenden einer Spesenrichtlinie ohne Namen schickte die Anfrage zweimal ab und stapelte zwei identische Meldungen “Error! Invalid request” übereinander, von denen keine das leere Feld Policy Name erwähnte.
Was Sie auf Ihrer Seite prüfen sollten: Löschen Sie ein Konto oder entziehen Sie einem Benutzer Rechte, während diese Person noch arbeitet, denn die Sitzung sollte in dem Moment enden, in dem der Zugriff endet. Lösen Sie anschließend jeden Fehler aus, den Ihr Backend zurückgeben kann, und lesen Sie, was auf dem Bildschirm ankommt. Eine rohe Validierungsausgabe oder eine doppelte Meldung bedeutet, dass die Oberfläche Serverantworten unübersetzt direkt an den Benutzer weiterreicht.
Wie so etwas gefunden wird: Testen von Webanwendungen, bei dem sich Tester mit jeder Rolle anmelden, die Ihr Produkt unterstützt, einschließlich einer Person, deren Zugriff vor einer Minute verschwunden ist.
Truck Simulator: World spielte trotz Stumm-Schalter Musik ab
- App: Truck Simulator: World (iOS)
- Schweregrad: Schwerwiegend
- Typ: Geräteeinstellungen und Kontoabläufe
Unser Tester startete in Truck Simulator: World eine Fahrsitzung und schaltete das iPhone 12 dann in den Stumm-Modus. Die Spielmusik lief weiter. Wer sein Telefon im Zug oder in einem Meeting stumm schaltet, erwartet, dass alle Apps auf einmal still werden.
Der Fotomodus des Spiels schnitt nicht besser ab, denn ein Tippen auf Capture oder Share ließ den Bildschirm nur flackern, ohne ein Bild zu speichern oder das Teilen-Menü zu öffnen.
In den Einstellungen konnte ein Spieler, der sich nie angemeldet hatte, trotzdem die Option Account Deletion öffnen, obwohl kein Profil zum Löschen existierte. Apple und Google prüfen diesen Ablauf genau, wie unsere Übersicht der Anforderungen an die Kontolöschung in Apps erklärt.
Was Sie auf Ihrer Seite prüfen sollten: Behandeln Sie das Telefon selbst als Teil des Produkts. Der Stumm-Schalter, die Fotomediathek und das Teilen-Menü des Systems liegen außerhalb Ihres Codes, doch Spieler geben dem Spiel die Schuld, wenn eines dieser Teile nicht richtig funktioniert. Öffnen Sie die App danach als Gast und prüfen Sie, ob die Kontolöschung und andere Optionen nur für Mitglieder bis zur Anmeldung verborgen bleiben.
Wie so etwas gefunden wird: Spieletests auf echten iPhones, bei denen Tester die Hardwaretasten drücken, zu denen ein Spieler ganz automatisch greift.
Bluedot nahm während eines Telefonats Stille auf
- App: Bluedot AI Note Taker (Android)
- Schweregrad: Schwerwiegend
- Typ: Unterbrechungen und Transkription
Unser Tester startete auf einem Samsung Galaxy A35 eine Aufnahme in Bluedot, nahm dann einen eingehenden Anruf an und blieb etwa 25 Sekunden in der Leitung. Der Timer lief die ganze Zeit weiter, sodass nichts auf dem Bildschirm auf ein Problem hindeutete. Bei der Wiedergabe zeigte sich jedoch eine stumme Lücke, wo das Gespräch hätte sein sollen. Die App hatte nicht gewarnt, dass das Mikrofon keinen Ton mehr aufnahm.
Von allen Beispielen für Softwareausfälle in diesem Monat richtet die stumme Lücke den größten Schaden an. Nutzer merken das fehlende Audio erst, wenn sie zu dieser Stelle der Aufnahme zurückgehen. Denselben Fehler haben wir im Digest des Vormonats gesehen, wo January: AI Health Tracker während eines Weckers weiterzählte und jedes Wort verlor, das während des Klingelns gesprochen wurde. Zwei Produkte in zwei Monaten deuten darauf hin, dass Unterbrechungen ein blinder Fleck von Aufnahme-Apps sind.
Auch die Transkripte hatten Probleme, denn Bluedot ordnete jede Zeile dem ersten Sprecher zu, auch das, was eine andere Person gesagt hatte. Selbst die E-Mail zu einer geteilten Datei gab die Länge falsch an und führte eine 16-Sekunden-Aufnahme als 1 Minute lang.
Was Sie auf Ihrer Seite prüfen sollten: Koppeln Sie jede Fortschrittsanzeige an das tatsächlich aufgenommene Audio, denn ein Timer, der bei ausgefallenem Mikrofon weiterzählt, signalisiert den Nutzern, dass alles in Ordnung ist. Einen Anruf mitten in der Aufnahme anzunehmen ist der schnellste Weg, diese Verbindung zu testen. Testen Sie danach mit zwei Stimmen und vergleichen Sie alles, was das Produkt meldet, von den Sprecherkennzeichnungen bis zur Dauer in einer geteilten E-Mail, mit dem, was wirklich passiert ist.
Wie so etwas gefunden wird: Testen mobiler Anwendungen auf echten Android-Telefonen und iPhones, bei denen ein eingehender Anruf die Aufnahme tatsächlich unterbrechen kann.
Laxis ließ 1.024 Zeichen eingeben, speicherte aber nur 500
- App: Laxis (web)
- Schweregrad: Schwerwiegend
- Typ: Eingabevalidierung und Meeting-Steuerung
Unser Tester füllte das Feld Description einer neuen KI-Vorlage in Laxis, bis das Feld bei 1.024 Zeichen keinen Text mehr annahm. Ein Klick auf Save brachte dann eine Fehlermeldung, nach der das Limit bei 500 lag. Der Meeting-Assistent hatte für dasselbe Feld zwei verschiedene Limits festgelegt, sodass der Nutzer es erst erfuhr, nachdem er doppelt so viel getippt hatte, wie die App behalten würde.
Bei der Benennung von Ordnern gab es ein anderes Validierungsproblem: Zu kurze und zu lange Eingaben lösten gleichermaßen “Folder creation failed” aus, ohne Hinweis darauf, was zu ändern ist. Eine so wenig hilfreiche Meldung aufzuspüren ist die Aufgabe von Negativtests, die eine App absichtlich mit fehlerhaften Eingaben füttern und die Reaktion prüfen.
Auch die Aufnahmesteuerung versagte: Ein Klick auf Pause stoppte die Aufnahme nicht, und ein stilles Meeting von 10 bis 20 Sekunden hing tagelang im Status “Processing” fest.
Was Sie auf Ihrer Seite prüfen sollten: Notieren Sie die Limits, die Ihre Oberfläche anzeigt, und die Limits, die Ihr Server durchsetzt, und suchen Sie dann nach jeder Abweichung zwischen beiden Listen. Jede Abweichung bedeutet, dass ein Nutzer zuerst die Arbeit erledigt und danach auf den Fehler stößt. Unterziehen Sie die Aufnahmesteuerung derselben Prüfung mit Fällen, die niemand einplant, etwa einer Pause mitten in der Aufnahme oder dem Speichern eines Meetings ohne Sprache.
Wie so etwas gefunden wird: Funktionstests, die jedes Formular mit leeren Werten, überlangen Texten und anderen Eingaben belasten, die ein echter Nutzer ausprobieren könnte.
Venue gab seinem Server die Schuld, als das Telefon offline war
- App: Venue: Relaxing Design Game (iOS)
- Schweregrad: Schwerwiegend
- Typ: Konnektivität und Kontoabläufe
Unser Tester schaltete den Flugmodus ein und versuchte dann in Venue eine Aktion, die eine Internetverbindung braucht. Das Inneneinrichtungsspiel zeigte einen Serverfehler und sagte nichts über die fehlende Verbindung. Gegen einen Fehler auf Seiten des Unternehmens kann ein Spieler nichts tun, das WLAN wieder einzuschalten dauert dagegen nur Sekunden. Die irreführende Meldung verschweigt den einzigen Schritt, der helfen würde.
Venue teilte außerdem den Gastkonto-Fehler von Truck Simulator: World und ging noch einen Schritt weiter. Ein Spieler, der sich nie registriert hatte, konnte die Löschung vollständig durchlaufen, ohne Erklärung, welche lokalen Daten gelöscht würden. Auf den Design-Bildschirmen wiederum luden einige Stoffvorschauen nicht und blieben leer.
Was Sie auf Ihrer Seite prüfen sollten: Geben Sie jedem Fehler, auf den Ihre App stoßen kann, eine eigene Meldung, von einer abgebrochenen Verbindung bis zu einem fehlenden Bild, denn eine einzige Sammelmeldung schickt Nutzer auf die Suche nach der falschen Lösung. Lassen Sie destruktiven Schritten dieselbe Sorgfalt zukommen, sodass der Bildschirm genau erklärt, was verschwinden wird, bevor ein Gast etwas löscht.
Wie so etwas gefunden wird: Usability-Tests, die auf echten Telefonen mitten in einer Aufgabe die Verbindung kappen und prüfen, ob jede Meldung einem Spieler hilft, weiterzukommen.
Was diese Beispiele für Softwarefehler Ihrem Testplan hinzufügen
Jede Zeile unten geht auf einen Fehler aus diesem Monat zurück, und zusammen deckt die Liste die Arten von Softwarefehlern ab, denen wir am häufigsten begegnen.
- Jede Fehlermeldung: Der Text sollte die tatsächliche Ursache nennen, etwa eine verlorene Verbindung, ein leeres Feld oder ein gelöschtes Konto, und den Nutzern sagen, was sie als Nächstes tun können.
- Jedes Limit: Oberfläche und Server sollten sich auf dieselbe Zahl einigen.
- Jede Fortschrittsanzeige: Ein Timer oder eine Statusanzeige sollte widerspiegeln, was die App tatsächlich aufgenommen oder verarbeitet hat.
- Jedes Telefonereignis: Der Wechsel in den Stumm-Modus, ein eingehender Anruf und ein verlorenes Signal sollten jeweils eine angemessene Reaktion der App erhalten.
- Jeder Kontostatus: Testen Sie jeden Bildschirm als Gast, als regulärer Nutzer und als jemand, dessen Zugriff gerade entzogen wurde.
- Jede KI-Unterhaltung: Suchergebnisse sollten den richtigen Chat öffnen, und Folgefragen sollten beim ursprünglichen Thema bleiben.
Fehler des Monats
Unsere Wahl fällt auf Sage AI, einen iPhone-Assistenten mit Chatbots für Aufgaben wie Schreiben, Übersetzen und Reiseplanung. Zwei Fehler brachen das grundlegendste Versprechen des Produkts: Was auf dem Bildschirm steht, sollte die Unterhaltung sein, die Sie aufgerufen haben.
Zuerst suchte unser Tester im Tab Chats nach einem Stichwort, tippte auf das passende Ergebnis und landete in einem anderen Chat. Der zweite Fehler kam vom Assistenten Travel Buddy, der eine Frage zu einer Reise nach Mexiko beantwortete und dann den Faden verlor. Als unser Tester mit “what’s the weather there in December?” (wie ist das Wetter dort im Dezember?) nachhakte, ging es in der Antwort um Thailand und Visabestimmungen.
Eine Suche, die den falschen Chat öffnet, lässt Menschen an allem anderen auf dem Bildschirm zweifeln. Ein Assistent, der das Thema eine Nachricht später vergisst, zwingt Nutzer, von vorn zu beginnen. Zu prüfen, wie ein KI-Produkt den Kontext über eine ganze Unterhaltung hinweg hält, ist ein zentraler Teil unserer Arbeit im Bereich KI-Testing.
Eine lobende Erwähnung geht an die Bluedot-Aufnahme, die während eines Anrufs stumm wurde. Für eine Notiz-App ist ein fehlender Abschnitt eines Meetings der eine Fehler, den Nutzer selten verzeihen.
Fehler wie diese finden wir jeden Monat, indem wir Produkte so nutzen, wie Kunden es tun. Lassen Sie uns als Nächstes Ihre App testen.
FAQ
Was sind typische Beispiele für Softwarefehler?
Typische Beispiele für Softwarefehler sind Schaltflächen, die nichts tun, Formulare, die gültige Eingaben ablehnen, Fehlermeldungen, die auf die falsche Ursache verweisen, und Daten, die falsch oder gar nicht gespeichert werden. Viele der teuersten Fehler bringen nie etwas zum Absturz. Solche Fehler überstehen einen routinemäßigen Testdurchlauf und zeigen sich erst, wenn echte Nutzer auf eine Unterbrechung, ein schwaches Netz oder einen ungewöhnlichen Kontostatus stoßen.
Welche Arten von Softwarefehlern gibt es?
Die wichtigsten Arten von Softwarefehlern sind Funktions-, Usability-, Kompatibilitäts-, Performance- und Sicherheitsfehler. Funktionsfehler verhindern, dass eine Funktion ihre Aufgabe erfüllt, während Usability-Fehler funktionierende Bildschirme verwirrend machen. Kompatibilitätsfehler treten nur auf bestimmten Geräten, Browsern oder Systemeinstellungen auf. Performance-Fehler zeigen sich als langsame Bildschirme oder Abstürze unter Last, und Sicherheitsfehler legen Daten oder Zugriffe offen, die geschützt bleiben sollten.
Was ist der Unterschied zwischen einem Bug und einem Softwareausfall?
Ein Bug ist ein Mangel im Code oder im Design, und ein Ausfall ist das, was ein Nutzer erlebt, sobald dieser Fehler ausgelöst wird. Typische Beispiele für Softwareausfälle sind eine Checkout-Seite, die nicht lädt, ein Dokument, das nach dem Speichern verschwindet, und eine Rechnung mit falscher Summe. Ein einziger Bug kann viele Ausfälle verursachen oder gar keinen, wenn niemand genau die Schritte ausführt, die das Problem auslösen.
Wollen Sie einen Bug Crawl für Ihre App?
Wir setzen einen unserer QA-Ingenieure darauf an und senden Ihnen einen detaillierten, reproduzierbaren Bericht mit Videobelegen.
