Laden...

Qualitätssicherung: Wie konnte ein offensichtlicher Fehler in JellyBean 4.2 übersehen werden?

Erstellt von thetruedon vor 11 Jahren Letzter Beitrag vor 11 Jahren 5.899 Views
thetruedon Themenstarter:in
111 Beiträge seit 2011
vor 11 Jahren
Qualitätssicherung: Wie konnte ein offensichtlicher Fehler in JellyBean 4.2 übersehen werden?

Hallo,
Aktuelle Ereignisse bewegen mich hier mal etwas zu posten.
Im neuen JellyBean 4.2 von Google, genauer, in der Peoples App kam es scheinbar zu einem peinlichen Fehler der auch als "peinlichen und lächerlicher Pfusch" betitelt wurde.
Und zwar der Monat Dezember existiert gar nicht. Wodurch es nicht möglich wird z.B. Geburtstage von Kontakten in besagtem Monat einzutragen.
Ferner kann ich mir vorstellen das andere Apps die darauf zugreifen spätestens in 2 Wochen ein Problem haben werden.

Was meint ihr, darf sich ein Konzern wie Google mit Massenhaft Testern einen solchen Fauxpas in einem Releas leisten?
Wie konnte ein solcher Fehler übersehen werden und wie sichert man Qualität bei euch im Betrieb?

Oder teilt ihr meine Annahme dass das ganze ein versuch ist den Dezember 2012 auszublenden um dem drohenden Weltuntergang am 21. Dezember zu entkommen und den Göttern der Maya ein Schnippchen zu schlagen?

Kommt ein Mann in die Wirtschaft und sagt zum Wirt: 16 Bit!
Sagt der Wirt: Das ist ein Wort!

6.911 Beiträge seit 2009
vor 11 Jahren

Hallo thetruedon,

so einen Fehler sollte sich gar kein Unternehmen leisten - außer in Bezug aufs Finanzielle - können, denn das darf einfach nicht passieren. Die 12 Monate gibt es ja nicht erst seit Kurzem.

So ein Fehler wurde wohl durch mangelnde od. keine Tests nicht bemerkt. Durch Unit- und Integrationstest, später gefolgt von Beta-Tests ließe sich leicht sicherstellen, dass das Jahr in 12 Monate geteilt ist und auf diese Art und Weise der Tests kann auch die Qualität gesichert werden. V.a. dann wenn die gemeldeten Bugs durch neue Test-Fälle abgedeckt und behoben werden, so dass das "Sicherheitsnetz" immer dichter wird.

Als ich deinen ersten Absatz las, kam mir der Gedanke, dass das wohl Absicht ist um die Verbreitung der App, durch die Aufschreie durch den fehlenden Dezember (plump) zu ermitteln.

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

5.657 Beiträge seit 2006
vor 11 Jahren

Die 12 Monate gibt es ja nicht erst seit Kurzem.

Sehr schöne Bemerkung 😃))
Aber wahrscheinlich kommt einfach keiner auf die Idee zu testen, ob das Jahr tatsächlich 12 Monate hat?
Christian

Weeks of programming can save you hours of planning

1.002 Beiträge seit 2007
vor 11 Jahren

Hallo zusammen,

das ist leider wirklich ziemlich peinlich und hätte durch automatisiertes (und erst recht durch manuelles) Testen abgefangen werden müssen. Da hat wohl jemand die nullbasierte Zählung verpfuschst — und auch die gibt es ja nicht erst seit kurzem 😉.

m0rius

Mein Blog: blog.mariusschulz.com
Hochwertige Malerarbeiten in Magdeburg und Umgebung: M'Decor, Ihr Maler für Magdeburg

6.911 Beiträge seit 2009
vor 11 Jahren

Hallo,

hab vorhin noch vergessen zu erwähnen, dass sie den Kalender besser "googeln" hätten sollen.

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

thetruedon Themenstarter:in
111 Beiträge seit 2011
vor 11 Jahren

Also ich persönlich sitze selbst gerade an einem größeren Projekt mit Kalender daher fand ich das gerade schon interessant dass gerade einem der größten einem Anbieter u.a. eines Terminkalenders so etwas passiert (das wäre natürlich auch in anderen Bereichen nicht weniger schlimm)

Aber wahrscheinlich kommt einfach keiner auf die Idee zu testen, ob das Jahr tatsächlich 12 Monate hat?

Also ich habe die Erfahrung gemacht, dass man lieber jede Banalität doppelt prüft ehe man am Ende dumm da steht und nachbessern muss, denn wenn so kleine Sachen nicht gehen hat man in fast jedem Fall am ende ein Problem bei den größeren Spezielleren Sachen die darauf aufbauen.

Und in dem Fall des Kalenders hätte man doch wenigstens einmal im Test Geburtstage generieren müssen wo auch welche im Dezember auftauchen müssten oder mal ein Jahr durch browsen.
Es ist mir echt ein Rätsel wie das passieren konnte.

Kommt ein Mann in die Wirtschaft und sagt zum Wirt: 16 Bit!
Sagt der Wirt: Das ist ein Wort!

W
872 Beiträge seit 2005
vor 11 Jahren

Wahrscheinlich hat der Entwickler je nach Sprache (C?) erwartet, dass die 0 fuer Januar steht und damit die 11 fuer Dezember.
Gerade wenn man in mehreren Sprachen entwickelt, ist so etwas schnell passiert.
Aber normalerweise sollte das schon beim Code Review auffallen.

Gelöschter Account
vor 11 Jahren

Mein Erfahrung ist das ein Konzern der Grössenordnung Google nicht auf 'massenweise Tester' hindeuten muss. Ich gehe einen Schritt weiter und sage das Testing eben nur innerhalb eines Projekts stattfindet. Die dort vorhandenen Tester sind im Prinzip halbe Programmierer(mit ausreichender Berufserfahrung). Ernstgememeinte Testprozesse sollte man bestenfalls outsourcen. Ich sehe da ein zweistufiges System zwischen -funktioniert wie es soll und -tut was es soll. Zumindest der letztere Zustand gehört abgegeben(Wenn man es sich leisten kann)

C
224 Beiträge seit 2009
vor 11 Jahren

Vielleicht ist es ja deswegen nicht aufgefallen, weil es eine Art "Problem anderer Leute" ist:
es ist so banal und es erscheint so einfach und unwichtig im Vergleich zu anderen nebenstehenden Codezeilen dass da die eigene Autokorrekturfunktion anspringt und und man im Gedanken etwas anderes liest, als da steht. Hier war eben ein "und" zuviel. Ist das aufgefallen?

106 Beiträge seit 2011
vor 11 Jahren

Ja, das doppelte "und" ist aufgefallen und meiner Meinung nach auch kein Problem anderer Leute(PaL) nach Adams Definition.

Am wahrscheinlichsten finde ich, das das prüfen auf 12 Monate zu banal war.
Man hätte aber wirklich, wie vorher schon angemerkt wurde, zumindest testen können ob sich Termine in allen Monaten anlegen lassen.

MfG
Rabban

49.485 Beiträge seit 2005
vor 11 Jahren

Hallo thetruedon,

wie das in dem konkreten Fall passieren konnte, weiß ich nicht und möchte mich auch nicht zu Spekulationen hinreißen lassen. Tatsache ist, dass es immer wieder Fälle gibt, in denen relativ offensichtliche Fehler übersehen werden, die teilweise spektakuläre Folgen haben, wie z.B den Absturz von Weltraumsonden oder Börsenkursen. Insofern befindet sich Google in guter Gesellschaft und was die (finanziellen) Folgen angeht ist der konkrete Fall vermutlich nicht mal annähernd rekordverdächtig.

Viel wichtiger ist, was man aus solchen Vorkommnissen lernen kann. Und im konkreten Fall kann man lernen, dass es wichtig ist, Grenz- und Randwerte zu testen. Im Zusammenhang mit Terminen, also insbesondere -0:01, 0:00, 0:01, 23:59, 24:00, 24:01 Uhr sowie den 0.0., 1.0., 0.1., 1.1., 2.1, 30.12. 31.12, 32.12., 0.13, 1.13. und am besten noch alle Monatsgrenzen, mindestens aber je ein Monat mit 28, 29, 30 und 31 Tagen. Und für Ende Februar je mindestens ein durch 4 mit Rest 0, 1, 2 und 3 sowie durch 100 und durch 400 ohne Rest teilbares Datum(*). Hättet ihr das alles berücksichtigt? Und fehlen noch wichtige Testfälle? Müssen nicht sinnvollerweise alle Kombinationen aus den genannten Datumsen und Uhrzeiten getestet werden? Lästig aufwändig, oder? Wer ohne Sünde ist, werfe den ersten Stein. 😃

herbivore

(*) Erst mit etwas Abstand ist mir aufgefallen, dass ich nicht angegeben habe, dass das durch 4 teilbare Datum nicht durch 100 und das durch 100 teilbare Datum nicht durch 400 teilbar sein sollte. Das ist oft das Problem von Spezifikationen (in dem Fall der Spezifikation der Testfälle), dass man im Grunde gar nicht genau genug sein kann. Und wenn man es nicht ist, fehlerträchtige Interpretationsspielräume lässt.

Gelöschter Account
vor 11 Jahren

@CoLo:

Nein, sorry du beschreibst nur den Umstand warum Developer überhaupt ihren eigenen Überprüfungen auf externe Individuen verlagern damit Sie ihre Eigenwarnehmung ausblenden. Das ist eine Erkenntnss die älter ist als die Softwareentwicklung selbst. Um eines auf den Punkt zu bringen was eigentlich sowieso jeder intelligente Mensch weiss: Niemand kann sich selbst überprüfen. Das funktioniert einfach nicht. Leider scheint es so das Techniker das eher verstehen als Entscheider. Schade!

EDIT: Randwerte sind wie herbivore schon sagt ein wichtiges Thema. Jeder der seinen Code nicht auf die minmale und maximale Eingangssituation geprüft hat darf sich nicht beschweren...

thetruedon Themenstarter:in
111 Beiträge seit 2011
vor 11 Jahren

Bei den Randwerten kann ich nur zustimmen.
Auch ich finde das immer wieder massiv lästig dass unsere Tests teilweise 3 mal solange dauern wie das schreiben einer einzelnen Funktion aber so läuft das nun mal und man sollte sich damit abfinden denn ist erst mal eine ich sag mal vorsichtig annähernd größtmögliche Anzahl an Testfällen geschrieben braucht man im Falle einer Änderung der Funktion/Klasse... nur ein Knöpfchen drücken um zu sehen ob nach wie vor diese Falle noch alle korrekt sind.
Aber auch Tests durch Anwender sind vor dem Release nötig denn wie schon erwähnt kann man sich im Prinzip nie 100% selbst Testen.

Nur mal zum Vergleich ich habe allein für eine Kalenderansicht in einem Projekt 49 Testfälle für die Positionierung von Einträgen in einer Monatsansicht.

Kommt ein Mann in die Wirtschaft und sagt zum Wirt: 16 Bit!
Sagt der Wirt: Das ist ein Wort!

G
497 Beiträge seit 2006
vor 11 Jahren

der konkrete Fehler bei Android 4.2 war doch ein reines UI-Problem, bei dem ein Control falsch angesteuert wurde. Zuerst wurden Min- und Maxwerte gesetzt, danach wurde die Werteliste zugeordnet. Dabei wurde übersehen, dass das Zuordnen einer Werteliste die Min- und Maxwerte anscheinend auf den Index der Werteliste zurücksetzt.

5.742 Beiträge seit 2007
vor 11 Jahren

Ich finde, Unit Tests Don't Find Bugs: the Death of QA passt hier ganz gut.

C
1.214 Beiträge seit 2006
vor 11 Jahren

Genauso ein Fehler ist mir auch mal unterlaufen. Ich musste ein exotisches Datumsformat parsen, habe ein entsprechendes Grundgerüst im Internet gefunden, hab ihn nach C++ konvertiert, paar Bugs gefixt, solche Spezialitätet wie Timezones getestet, und komplett übersehen, dass ein Monat in der Liste gefehlt hat. Ist weder meinen Kollegen noch der QA aufgefallen (wie auch? Man hat nicht zufällig in dem Monat getestet). Ist erst ein halbes Jahr später aufgefallen, als es soweit war ^^ Ist dann natürlich auch total offensichtlich, weil es funktioniert ja nicht.
Von Google hätt ich sowas allerdings nicht erwartet. Wir sind eine relativ kleine Firma mit vielleicht 50 Entwicklern in unserer Abteilung, jeder hat zig Projekte gleichzeitig, die natürlich alle dringen sind und brennen und die QA ist genauso überfordert. Da ist sowas zwar peinlich, aber zumindest intern nachvollziehbar. Ich könnte mir höchstens vorstellen, dass das Projekt bei Google intern ebenfalls eine geringe Prio hat.

49.485 Beiträge seit 2005
vor 11 Jahren

Hallo winSharp93,

Ich finde,
>
passt hier ganz gut.

das und insbesondere die darin enthaltene Aussage ...

... I was very embarrassed to find that my software had lots of bugs. Simply put, he used my software in ways that I hadn't intended.

... zeigen aber eigentlich nur, das dort der Unterschied zwischen Korrektheit und Robustheit nicht berücksichtigt wurde. Ein Programm ist - so wie Spezifikationen üblicherweise gestaltet sind - korrekt, wenn es für korrekte Eingaben korrekte Ergebnisse liefert. Es ist robust, wenn es sich bei fehlerhaften Eingaben angemessen verhält, also typischerweise nicht abstürzt und den Fehler meldet.

Meine Grenzwert-Testfälle von oben berücksichtigen sowohl Korrektheit als bis zu einem gewissen Maße auch Robustheit, weil nicht nur Werte (gerade noch) innerhalb des erlaubten Wertebereichs getestet werden, sondern auch welche (gerade eben) außerhalb des erlaubten Wertebereichs getestet werden.

Allerdings kann man die Überprüfung der Robustheit noch viel weiter treiben. Zwar gibt es oben mit -0:01 immerhin einen Wert mit einem abweichenden Format, aber man könnte und sollte noch weit exotischere Eingaben prüfen, wie z.B. 0:001, 0,01, a:b, 12345678901234567890..., %17&"/$ usw.

Und wenn man das tut, wenn man also schon bei den Unittests (und erst recht bei TTD) die Robustheit einkalkuliert, dann wird auch der Programmcode die gewünschten QA-Anforderungen erfüllen. Ein solches Vorgehen zwingt dann (gerade bei TTD) den Entwickler dazu, für den gesamten möglichen Wertebereich und nicht nur für den erlaubten Wertebereich eine angemessene Reaktion zu implementieren.

Das Gesagte würde ich unter dem Aspekt "was kann man aus solchen Vorkommnissen lernen" weiterhin als vollkommen ontopic ansehen.

Hallo Coder007,

... dass ein Monat in der Liste gefehlt hat.

was zeigt, dass man mit dem Test von Grenzwerten alleine auch keinen Blumentopf gewinnen wird. Auch innerhalb des erlaubten Wertebereichs sollte man auf eine möglichst gute Abdeckung achten. Immerhin, wenn man wie oben angeregt tatsächlich alle Monatsgrenzen getestet hätte, wäre auch dieser Fehler aufgefallen. Das zeigt wieder mal, dass man beim Test nichts als gegeben oder selbstverständlich ansehen sollte. Nettes Beispiel!

herbivore

5.742 Beiträge seit 2007
vor 11 Jahren

Und wenn man das tut, wenn man also schon bei den Unittests (und erst recht bei TTD) die Robustheit einkalkuliert, dann wird auch der Programmcode die gewünschten QA-Anforderungen erfüllen

Die Frage ist aber doch gerade, ob das überhaupt möglich ist: Als Entwickler bringt man da durchaus eine gewisse "Betriebsblindheit" mit oder wie Sebastian.Lange es IMHO ganz gut auf dem Punkt bringt "Niemand kann sich selbst überprüfen".

IMHO sollte es auch gar nicht Aufgabe der Unittests sein, auf Robustheit zu testen: Was bringt es mir, wenn ich weiß, dass eine Komponente (die in einem Unittest ja komplett isoliert getestet wird) zwar "robust" ist?
Ich darf nicht einfach folgern, dass wenn in einem System nur "robuste" Komponenten arbeiten, dass System auch robust ist.

Andererseits brauche ich, um ein robustes System zu realisieren, nicht nur lauter robuste Komponenten: Wenn Komponente A crasht, wenn irgendwo ein null Wert steht (und somit nicht robust ist), aber nur von Komponente B aufgerufen wird, die aber genau sicherstellt, dass dieser Fall nie eintritt, würde ich im gesamten trotzdem von einem robusten System sprechen.

Insofern unterstützte ich den verlinken Artikel durchaus in seiner Aussage, dass UnitTests keine Bugs "finden" (da sie schon während der Entwicklungszeit ausgeführt werden, ist ein fehlschlagender Unittest IMHO noch kein "Bug" im herkömmlichen Sinne, da er ja sofort gefixt wird, d.h. nie in einer Nicht-Entwicklungsversion auftaucht), sondern hauptsächlich bei der Entwicklung helfen. IMHO ist das aber auch richtig so; genau dafür gibt es ja Integrations- und Systemtests.

Klar - ich stimme dir zu, dass man sich beim Unittest-Schreiben Gedanken über mögliche, exotische Werte machen muss.
Aber m.E. nur innerhalb der definierten Grenzen der Komponente, die man damit testet.

T
708 Beiträge seit 2008
vor 11 Jahren

Da fällt mir doch gleich wieder das Thema "Apple und Zeitumstellung" ein.
Es war so, dass am Tage der Zeitumstellung der Wecker (in vielen Fällen) seine Funktion verweigert hatte. Wenn mich nicht alles täuscht, ist das sogar zweimal aufgetreten.

Das dies ein recht komplexes Thema ist, steht außer Frage. Dazu kommt noch, dass alle weiteren Funktionen und Zusatzprogramme auf diese Umstellung reagieren müssen.

Aktuell hat es auch mal wieder einen Autohersteller getroffen, der mehrere Millionen Kfz zurückrufen muss, weil ein vergleichsweise einfaches Teil Probleme verursacht.

Im Fall von Android wurden sicherlich auch umfangreiche Unittests gemacht. Aber der Kalender an sich kennt natürlich den Dezember, einzig die GUI beim Anlegen des Datums war fehlerhaft.

Es kann und wird nie unfehlbare Software (und auch Hardware) geben. Zwar entwickeln sich die Tests immer weiter, aber die Geschwindigkeit, mit der heutzutage entwickelt wird tut ihr übriges, dass nicht alles auf Herz und Nieren getestet wird.
Wichtig ist doch nun die Reaktion, wie schnell Google ein Update bereitstellt, damit der Fehler behoben wird.

Traurig finde ich nur den Aufschrei von vielen News-Seiten, vorzugsweise den sehr Apple orientierten. Man denke doch mal zurück an den Todesgriff, Kratzer in der Schale, Grünstich bei der Kamera oder das "zufällige" mitloggen der kompletten Bewegungsdaten im Mobilfunknetz.
Die mediale Diskussion ist doch nur noch ein in zwei Lager gespaltenes Bashing, die auf der Suche von Fehlern bei dem anderen sind...

49.485 Beiträge seit 2005
vor 11 Jahren

Hallo winSharp93,

Niemand kann sich selbst überprüfen

das gilt insbesondere, wenn der Programmierer die Spezifikationen missverstanden hat. Sowas ist wirklich schwer ohne fremde Hilfe zu finden. Aber das ist ja nur ein Aspekt, der zudem in konkreten Fall nicht zieht, denn jedem Programmierer und Tester ist klar, dass man auch im Dezember Termine anlegen könnten müsste.

In vielen Fällen kann man sich also durchaus selber überprüfen. Und man kann lernen sich selber immer besser zu überprüfen. Insofern lasse ich grundsätzliche Einwände gegen die Sinnhaftigkeit von Unit-Tests und TDD nicht gelten.

Beim Testen nimmt man einfach einen anderen Blickwinkel ein als beim Programmieren oder sollte es zumindest tun.

Allerdings wird das Subthema, wie gut man sich selbst überprüfen kann, jetzt doch langsam offtopic, zumal das in Tatsächlicher Nutzen von Unit-Tests [und TDD] und den weiteren Beiträgen schon ausführlich diskutiert wurde. Bei Bedarf dort weiter, oder in einen ganzen neuen Thread speziell zum Thema "Wie schizophren kann/sollte/muss man beim Programmieren vs. Unit-Testen sein?".

herbivore