Ob eine Lösung für Mobilgeräte gut ist, hängt von einigen wenigen Faktoren ab:

•  Fokussierung: Der Anwendungsfall, für welchen die Applikation gemacht ist, muss messerscharf umrissen sein.
• Beschränkung: Die wichtigsten Abläufe sollen optimal unterstützt werden. Die 80-20 Regel ist hier das Mass aller Dinge (oft reicht sogar auch 70-30). All die komplizierten Spezialfälle, die nur selten gebraucht werden, werden nicht unterstützt.
• Nutzung der Gerätespezifika: Mobilgeräte haben Stärken, die eine App unbedingt nutzen muss. In erster Linie sind das die offensichtlichen Möglichkeiten der Nutzung von Geolocation, Kamera oder Mikrofon, sowie die Verknüpfung mit Kalender und Kontakten. Daneben ist es aber auch entscheidend, die Bedienung auf die Interaktion via Touchscreen auszurichten. Damit wird eine Applikation viel direkter, unmittelbarer und intuitiver spür- und benutzbar.
• Perfektionierung: Innerhalb diesea klar definierten Scopes muss die App dann perfektioniert werden. Das beginnt bei der Benutzerinteraktion, indem jeder überflüssige “Tap” eliminiert wird und geht bis zur grafischen Gestaltung, die für den Gesamteindruck entscheidend ist.

Soweit die Theorie. Nun möchte ich das am praktischen Beispiel aufzeigen.

Die Aufgabe heisst: Gestalte eine Fahrplan-Applikation für den öV auf dem Mobilgerät.

Lösung 1: Die mobile Website der SBB

Ich bin zwar in der Lage, für meinen Heimweg aus dem Geschäft bis zur gewünschten Haltestelle vor der Kita eine entsprechende Verbindung herauszufinden, aber es ist harzig. Ich muss auf der Tastatur tippen, bis ich den vollen Namen der entsprechenden Haltestelle eingetippt habe. Keine Vorschläge, keine Nutzung des eigenen Standorts. Das Resultat ist zwar ok, aber der Weg dahin ist unerfreulich.

Lösung 2: Die SBB-Mobilapplikation

Hier ist schon einmal ein Quantensprung spürbar gegenüber der mobilen Website. Es fühlt sich viel direkter und responsiver an und es gibt auch schon erste Schritte in die richtige Richtung: Ich kann den Standort direkt einbeziehen und der “Take Me Home”-Button ist nett. Aber auch hier tippe ich wieder, und wehe ich vergesse das Komma zwischen Ortschaft und Haltestelle. Dann wird die Zieldestination nicht gefunden. Ich habe zwar die Möglichkeit, im Verlauf alte Suchabfragen aufzuspüren oder sie in den Favoriten zu organisieren, aber übersichtlich ist beides nicht.

Kommen wir also nun zur

Lösung 3: Die Applikation Viadi

Und hier ist nun wirklich alles comme il faut. Die Applikation ist klar fokussiert: Es geht darum, eine begrenzte Anzahl von Abfragen, die ich immer wieder machen muss, so effizient wie möglich umzusetzen. Die Abfragen sind auf elegante Weise grafisch umgesetzt. Die Benutzung ist extrem  intuitiv. Die Möglichkeiten von Location und Touchscreen werden konsequent genutzt. Und es ist offensichtlich, dass hier wirklich getüftelt wurde, um die Applikation und im Besonderen die Benutzung zu perfektionieren.

Ich benötige etwas Konfiguration, bevor ich die Applikation nutzen kann, aber die zu machen bin ich nur zu gerne bereit. Ich hinterlege meine Ziele in Form von Kacheln, die ich so gestalten kann, wie ich will: Grösse, Platzierung, Text, Bild – alles nach meinem Gusto. So werden also Arbeitsort, Wohnort, die relevantesten Ortschaften, Kita, Grosseltern etc. alles hinterlegt.

Nach dieser initialen Konfiguration bin ich bereit, um nun die Verbindungen abzufragen, indem ich einfach mit dem Finger einen Strich von der Start- zur Zielkachel ziehe. Und schon bekomme ich die Verbindungsvorschläge. Zeitaufwand: Sekundenbruchteile. Toll!

Und als Option habe ich sogar auch noch die Möglichkeit, beliebige Suchabfragen, welche über meine gespeicherten Kacheln hinausgehen, mit den gleichen Mitteln zu stellen, wie bei Lösung 2. Apropos Beschränkung: Mit den 4×4 Kacheln habe ich die Möglichkeit, maximal 16 x 15 = 240 verschiedene Verbindungen mit Fingerstrich abzufragen. Das ist eigentlich auch schon eine ganze Menge…

Der Punkt, in welchem ich noch Verbesserungspotential sehe, ist die Konfiguration der Kacheln. Hier wäre es schön, noch eine bessere Unterstützung für das Hinterlegen der Kacheln zu haben, z.B. mit indem direkt nach der Auswahl der Haltestelle Bilder aus der Umgebung via Google Places oder Beschriftungen von Restaurants, Institutionen, Firmen, etc. im nahen Umkreis vorgeschlagen zu bekommen. Das würde den Spass beim Hinzufügen von weiteren Start- und Zielpunkten noch erhöhen. Auch die Auswahl eines Kontaktes anstelle einer Haltestelle, wobei die App dann direkt die nächste Haltestelle ermittelt und das Foto des Kontaktes als Visualisierung verwendet, wäre elegant.

Über alles gesehen ist Viadi für mich wirklich das Werkzeug der Wahl, wenn es darum geht, die öV Verbindungen abzufragen, die ch ich in meinem Alltag brauche, und darüber hinaus ein exzellentes Beispiel, wie eine mobile Applikation realisiert werden sollte. Gratulation an die Hersteller. Und vielen Dank, Kai @warszas, für den tollen Tipp!

Bei unseren mobilen Lösungen haben wir an verschiedenen Stellen Probleme mit der neusten iOS Version festgestellt, wenn es darum geht, eine App in Hoch- und Querformat richtig darzustellen.

Dass dies nicht nur bei eigenen Lösungen so ist, sondern dass auch Apple selber mit den gleichen Schwierigkeiten kämpft, hat mich etwas amüsiert…

So kommt auf meinem iPad Air2 mit iOS 8.1.2 bei der Suche im Querformat die Tastatur im Hochformat reingeschlittert:

Andreas hat es in seinem Kommentar genau so beschrieben, wie ich es auch gemacht habe: Der leere Knopf auf dem Screen, bevor die Karte im Terminal eingeschoben wird, ist das Problem. Herzliche Gratulation! Du hast das Rätsel gelöst!

Ich bin davon ausgegangen, dass es nur funktioniert, wenn das Benutzerinterface möglichst schnell immer auf diesem Knopf rechts unten traktiert wird. Das würde dann etwa der Obsessive-Compulsive Tour entsprechen, wie sie James Whittaker in seinem Buch “Exploratory Software Testing” beschreibt.

Aber heute habe ich es jetzt noch in Slowmotion probiert, und es funktioniert auch so: Der Knopf rechts unten ist zwar leer, aber er reagiert trotzdem noch auf Klicks – und siehe da, schon kommt die Fehlerseite.

Interessant an diesem Fehler ist, dass der Fehler nicht darin besteht, dass etwas nicht funktioniert, was vom Kunden so verlangt wurde, sondern, dass etwas Zusätzliches in der Software enthalten ist. Das ist ein Pattern, das häufiger vorkommt, dass Software Funktionalität aufweist, die über die Spezifikation hinausgeht. Verhältnismässig häufig sind Sicherheitslöcher in diesen Teilen zu finden, die eben zusätzlich zur Spezifikation in der Software vorhanden sind. Und die sind im Testing unglaublich schwierig zu finden.

Zusammenfassend: Sicher kein schlimmer Fehler, ich sehe auch keine unmittelbaren Auswirkungen. Nichtsdestotrotz wäre eine explorative Testsession auf dieser Software sicher keine verlorene Zeit. Und einmal mehr überraschend, dass auch eine vom Workflow her nicht unendlich komplexe Applikation eben doch nicht ganz wasserdicht getestet wurde.

Nun noch eine kleine Anmerkung:

Unmittelbar nachdem ich dieses Rätsel publiziert habe, kam auch schon die Meldung von @Migros via Twitter.

@ThomasBriner Das würde uns aber auch interessieren. 🙂 ^jr

— Migros (@migros) 15. Januar 2015

Chapeau, wirklich beeindruckend, nicht nur die Data-Mining-Algorithmen funktionieren, sondern die Analyse der Treffer ist auch beeindruckend schnell!

Hier ein kleines Testing-Rätsel für alle, die gerne Software überlisten:

Die Subito-Terminals – die Self-Service-Kassen im HB ZH – haben unterdessen eine ziemlich ausgereifte Software, die einen effizienten Ablauf ermöglicht. Ich habe aber doch noch eine Möglichkeit gefunden, mit der deterministisch ein Fehler herbeigeführt werden kann:

Wer kann diesen Fehler reproduzieren?

Die Antwort darauf kommt in einer Woche hier im Blog. Viel Spass beim Experimentieren 🙂

Marcus Geduld hat diese Frage auf Quora für sich beantwortet – und mit jedem Abschnitt, den ich weiter gelesen habe, wuchs meine Überraschung, wie genau seine Antworten sich mit denen decken, die ich auf diese Frage jeweils gebe. Nur dass seine Antwort um Längen genauer und schöner formuliert ist als meine Versuche.

Insofern einfach unkommentiert seine Aussage. Enjoy it!

• I like creating something out of nothing. That’s not literally what you do when you’re programming, because there’s existing hardware and software that serves as a foundation for your work, but it sure feels that way. Someone has an idea and you build it from the ground up. When you begin, there’s just an empty text editor. When you’re done, there’s a (hopefully) working program.

• I like building things people use. It’s amazing to type up some code, press a button, and suddenly thousands of people on the Internet are playing with it.

• I like playing God. Programming allows you to build little worlds and then play with them, making adjustments and watching the effects. It’s like owning a toy planet and saying, “I’m going to make it rain, today. Oh, look! All the little people have opened umbrellas!” This playing-God aspect of programming makes it similar to writing novels, painting paintings, or directing plays.

• I like working within systems that demand precision. This is exactly what some people hate about programming, but it thrills me. A misplaced semicolon or the smallest typo can be disastrous. This keeps me on my toes. It’s like being the butler on “Downton Abbey” or “Upstairs, Downstairs.” Everything must be just so. Some people like precision; others like being about to say, “I can’t describe it, but you know what I mean…” I’m the former type.

• I like solving puzzles. If you want to see if programming is for you, try out this puzzle book: The Little Schemer – 4th Edition: Daniel P. Friedman, Matthias Felleisen, Duane Bibby, Gerald J. Sussman: 9780262560993: Amazon.com: Books

• I like research. Programming tends to involve much googling and reading through documentation.

• I like experimenting. There’s a large component of trial-and-error.

• I like writing poetry, which is very similar to programming. Both the poet and the programmer are obsessed with words, obsessed with formal rules, obsessed with seeing how far they can push those rules, and obsessed with expressiveness. Programmers often talk about how expressive a particular programming language is. They mean something very similar to what a poet means when he tries to come up with expressive wording.Both poetry and code can be exquisitely beautiful — and in very similar ways. People are often surprised that I’m a programmer who also directs Shakespeare plays, but I’ve met lots of programmers who are into Shakespeare, crossword puzzles, scrabble, and so on. Joshua Engel is another Quora user who writes code and directs Shakespeare plays.

• I like communicating. Most good programmers will tell you that code is first-and-foremost meant to be read by people — even to the extent that we’ll sometimes write it in a way that is inefficient but easy-to-read.

•  “There are only two hard things in Computer Science: cache invalidation and naming things.” — Phil Karlton. I love the hard work of “naming things.” Programmers generally have to come up with short words or phrases that label parts of the systems they’re writing. It’s crucial that these names be clear and apt.Why? Because if you name something cButton, the next guy who has to work on your code may be befuddled. If you’d called it closeButton, he would have instantly known what you were referring to. Sometimes “he” is me a few weeks (or a year) later, when I’m reading my own code. It’s embarrassing to come across cButton and think, “What did I mean by that?”Last week, I was modifying someone else’s code. It was for as web page with sections. Each section had a logo at the top. The original programmer had referred to those logos internally as “headers,” e.g. “header1” and “header2.” I didn’t notice that, and so I named something within one of the sections “header.” When I later looked over the code, I got totally confused between his headers and mine.Then I thought it over and realized that his “headers” were always graphical logos and mine were text. So I renamed his “logo1” and “logo2” and mine “title.”This is just one small example of the sort of naming issues that constantly crop up. You either enjoy this sort of thing or you don’t. I do.

• I like learning. Like sharks, programmers die if they stop moving. Because technology changes so fast, being a programmer means that “school” never stops. Even though I’ve been coding for years, I must constantly read programming books, follow blogs, and so on. There’s no coasting!I got into the game as a Flash programmer, which was lucrative for about ten years. Now Flash seems to be on its way out, so it’s back to the books! But even while I was mostly coding Actionscript (Flash’s language), I needed constant training, because that language went through many versions, some as different from each other as Spanish is from Portuguese.There are many good programming books and courses, but you can’t really learn to code by instruction. That will get you started, but they only real way to learn is to write code, fail, analyse the failure, and learn from it. So you must enjoy being an autodidact. I do.

• I like being a detective. Maybe 60% of programming is debugging — figuring out how something works. That often means a ton of sleuth work. Sometimes you have to pick and entire program apart and put it back together again.

• I like solitary work. Programming allows me to do lots of that.

• I like collaborating. Nowadays, Few programmers work completely alone. Most are part of a team, and they spend part of the week doing close work with others and part in isolation. I feel a strong need for both sorts of work, and I like alternating between the two.

​Die Problematik ist allgegenwärtig und wohlbekannt: Die Mitarbeitenden einer Organisation bringen ihre privaten mobilen Geräte mit in die Firma und wollen sie auch für geschäftliche Arbeiten nutzen.

Nun war wieder längere Zeit Funkstille in diesem Blog… Natürlich hängt das damit zusammen, dass in intensiven Zeiten der Blog als einer der ersten unter die Räder kommt. Es hat aber auch viel damit zu tun, dass ich mich beruflich nun seit 2012 neu schwergewichtig mit der Entwicklung von mobilen Lösungen auseinandersetze.

Ebenfalls ein unglaublich spannendes und dynamisches Thema! Natürlich ist das Testing gerade auch für mobile Lösungen ein grosses Feld, das immer noch ein Mauerblümchendasein fristet und auf intensive Beackerung wartet. Darüber werde ich versuchen, in Zukunft vermehrt zu berichten. Ab und zu werde ich mir aber auch erlauben, interessante Themen aus dem Feld Mobile Computing einzustreuen, die wenig oder keinen direkten Bezug zum Testing haben. Insofern willkommen bei der Symbiose aus Testing und Mobile oder eben: Testing goes Mobile