Eine Mobile App genau so, wie sie sein soll: Viadi

Mar 11
2015

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.

Foto 10.03.15 21 16 35  Foto 10.03.15 21 16 43


 

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.

Foto 10.03.15 21 17 27   Foto 10.03.15 21 18 28

 


 

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!

Foto 10.03.15 21 15 18   Foto 10.03.15 21 15 23

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!

iOS8 Probleme mit der Orientation – Querformat und Hochformat gemischt

Feb 16
2015

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:

Und noch eine Randbemerkung: Meist ist bei den Issues die Schwierigkeit, sie zu reproduzieren. Nicht so in diesem Fall: Hier schaffe ich es nicht, das Problem wieder zum Verschwinden zu bringen 🙂

 

Why do some people like programming?

Jul 25
2013

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 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.

Mobile UI Design – Wie kann ich ein heisses UI erstellen?

May 09
2013

Das Benutzerinterface (User Interface, kurz UI)  ist bei mobilen Applikationen definitiv einer der entscheidenden Erfolgsfaktoren. Die Benutzer sind sich einen hohen Standard gewohnt und fordern diesen – im Gegensatz zum Umgang mit Geschäftsapplikationen auf dem Desktop – auch ein.

Wie kann nun ein UI ​erstellt werden, welches die Benutzer anspricht und optimal zu einer Lösung passt. Wie bei der Frage, ob ein Musikstück letztendlich zu einem Hit wird oder nicht, gibt es keine Garantie, indem man “alles richtig” macht, auch einen Volltreffer zu landen. Trotzdem gibt es etliche harte Fakten, die berücksichtigt werden müssen, damit ein UI überhaupt das Potential zu einem solchen Volltreffer haben kann. Diese Fakten habe ich in folgende grafische Darstellung verpackt.

UI-Design
Viele mobilen Applikationen sind weit unter dem Gefrierpunkt – also schlichtweg unbrauchbar. Das liegt dann aber nicht in erster Linie am UI, deshalb heisst die Aufforderung hier: Focus! Nur wenn der Umfang und die Ziele der Applikation vollkommen klar sind und sich die Lösung wirklich darauf beschränkt, ist es möglich, ein gutes UI für eine Applikation zu erstellen.

Damit kann dann ein UI entstehen, mit dem man zwar das Richtige tun könnte, aber eben, es ist immer noch unbenutzbar. Hier heisst der nächste Schritt: Design for Mobile! Unter Beachtung der Ergonomie und er wichtigsten Layoutregeln kann damit ein UI entworfen werden, das wirklich zum mobilen Gerät passt.

Nun gibt es viele Benutzeroberflächen, mit denen man zwar arbeiten kann, die aber uneinheitlich, unprofessionell und zusammengebastelt wirken. Hier hilft Keep to the Code! (nicht nur für Piraten ;-)). Das bedeutet die konsequente Benutzung von Standard Elementen gemäss den Richtlinien, wie sie z.B. in den jeweiligen Human Interface Guidelines (z.B von Apple oder Windows) festgehalten sind.

Die Darstellung gemäss den Vorgaben reicht aber noch nicht aus. Auch das Verhalten muss für den Benutzer so sein, wie er sich das eben gewohnt ist, sonst ist die Bedienung unintuitiv und ungewohnt. Dagegen hilft Be Predictable! Das bedeutet, dass auch das Verhalten analog den Standards ist und der Benutzer zu allen seinen Aktionen auch ein entsprechendes visuelles Feedback bekommt, um festzustellen, was nun im Hintergrund passieren wird.

Damit überschreiten wir immerhin schon einmal den Gefrierpunkt, sind aber noch weit davon entfernt, ein heisses UI erstellen zu können. Die Gefahr besteht natürlich, wenn alles gemäss den Standards und Richtlinien realisiert wird, dass die Applikation dann langweilig und hässlich daher kommt. Deshalb nun die Aufforderung Stand Out! Zeig, was das Besondere bei dir ist. Hier kommt die graphische Gestaltung zum Zug, die mit dem entsprechenden Können und der Sorgfalt umgesetzt werden muss.

Schönheit ist aber nicht alles – ebenso wichtig sind Umgangsformen, sonst werden die Benutzer nicht gern damit arbeiten. Dazu gehören sorgfältige Überlegungen, wie für einen Erstbenutzer der Start aussehen soll, ohne unnötige Vorbereitungsschritte, aber mit der benötigten Unterstützung. Daneben braucht es ein besonderes Augenmerk darauf, den Benutzer in seinem Fluss nicht mit unnötigen Popups und Dialogen zu bremsen und hinauszureissen, sondern die Arbeit dezent zu unterstützen. Eben Be Polite!

Damit sind wir schon nahe an einem wirklich guten UI dran. Nun braucht es noch den Schliff für den Poweruser, da die App sonst eben nicht effizient bedienbar ist. Hier soll die Entwicklung des UI aus dem Vollen schöpfen, um z.B. mit Hilfe von Gesten effiziente Arbeitsweisen für geübte Nutzer anzubieten. Use the Force! Die Gesten müssen natürlich sehr sorgfältig gewählt werden, passend zu den Metaphern und basierend auf dem Verhalten, das sich der Benutzer von anderen Applikationen gewohnt ist.

Tja, und damit wäre nun also vieles richtig gemacht. Die Chancen, für ein wirklich gelungenes UI sind damit sicher schon sehr gut. Und wenn es dann noch gelingt, den Benutzer zu überraschen, dann ist die Ausgangslage für einen grossen Wurf sicher optimal.

Ps: Natürlich sind diese Punkte zu einem schönen Teil auch übertragbar auf andere UIs als nur für mobile Geräte!

Testing goes Mobile

May 07
2013

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

Mobile und Cloud – eine Kombination, die sich aufdrängt

Mar 19
2013

​An der Mobile Tech Conference 2013​ in München, die ich letzte Woche besuchen konnte, gab es eine Session zu Mobile & Cloud. Dass diese beiden Teile gut zusammenpassen, war mich auch vorher schon klar. Wie gut diese Kombination aber eben spielt und wie zwingend sie ist, wurde mir aufs Neue klar.

Die beiden Teile ergänzen sich dabei bezüglich ihrer Rolle einfach ideal: Cloud ist der Katalysator, der Enabler, der das ganze Schauspiel erst möglich macht. Cloud ist aber noch kein Nutzen, kein Anwendungsfall. Leute kaufen keine Clouds, Leute kaufen Lösungen. Und da setzt der Teil Mobile ein. Mobile ist der Driver, das sichtbare Werkzeug, welches das Potential der dahinterliegenden Cloud nutzbar macht.

Die Kombination Cloud & Mobile ist dabei nicht einfach eine weitere Variation der altbekannten Client-Server-Architektur. Der Client muss auch autonom sinnvoll arbeiten können. Statt dem Request-Response Pattern kommen andere Mechanismen zum Zug. Der Client muss sich zumindest einen sinnvollen Ausschnitt der Daten selber halten und damit kommen andere Kernfragen in den Vordergrund. Wie findet eine Synchronisation statt? Wie gehe ich mit Merge-Konflikten um? Wie erkenne ich veraltete Daten?

Cloud & Mobile ist eine fantastische Kombination, aber beileibe keine einfache Lösung. Die Knacknüsse gehen von Verbindungsproblematiken über die Sicherheitsbereiche bis hin zur Skalierbarkeit auf Backendseite.

Als letztes möchte ich noch auf einen Punkt beim UI eingehen: Auch hier ergeben sich durch das erwähnte Zusammenspiel zwischen Cloud & Mobile neue interessante Fragestellungen. Die Asynchronizität, die in dieser Architektur fix drin steckt, z.B. bei der Synchronisation, stellt auch neue Anforderungen an das Benutzerinterface. Die herkömmlichen Designansätze mit Wireframes etc. basieren stark auf der Annahme, dass am Anfang einer Änderung am UI eine Aktion des Benutzers steht. Das stimmt nun nicht mehr. Wie soll der Benutzer zB über einen Konflikt informiert werden, der während der Synchronisation im Hintergrund auftritt? Wenn ich ihm einen Dialog aufpoppen lasse, wie das sonst bei Schwierigkeiten, die ich dem Benutzer mitteilen will, üblich ist, so reisse ich ihn mitten aus irgendeinem anderen Ablauf heraus. Ich muss also Wege finden, seine Arbeit nicht zu stören, ohne ihm Informationen vorzuenthalten.

Mobile & Cloud: Eine Kombination mit ganz viel Potential, aber definitiv kein Quick Win, der eben mal schnell realisiert werden kann. Ich freue mich darauf, über solche Lösungen bezogen auf die Abraxas nachzudenken!

Professionelle SW-Entwicklung für iOS – ein Widerspruch?

Mar 30
2012

Um im Java- Kontext professionell SW zu entwickeln, gibt es verschiedene Bestandteile, die einfach dazugehören: Unit Testing, Continuous Integration, automatisierte Erstellung von Releaspaketen, Systemtestautomatisierung etc. Das ist – zumindest in dem Umfeld, in welchem ich mich bewege – allgemein akzeptiert und weitgehend selbstverständlich.

Mit dem Schritt in die Welt der SW Entwicklung mit iOS sind nun aber alle diese Errungenschaften in Frage gestellt. Das beginnt damit, dass bereits die Konzepte für die Unit Tests mit der Unterscheidung Logic und Application Unit Tests schlecht verständlich sind und entsprechend nur bruchstückhaft umgesetzt werden. Wer dann den Schritt macht und die verschiedenen Schritte ab command line anstossen will, braucht viel Geduld, Durchhaltewillen und Frustrationstoleranz. Offizielle Tutorials von Apple habe zumindest ich dazu keine gefunden. Da bleibt viel Spielraum für Trial and Error.

Definitiv aufs Glatteis begibt sich, wer dann noch die automatisierten Regressionstests gegen das UI in die continous Integration reinnehmen will. Zwar kann man neuerdings das von Apple zur Verfügung gestellte Tool UIAutomation von der commandline anstossen. Um aber die verschiedenen Funktionsweisen und Parameter zu verstehen, ist man dann schon auf sich selber gestellt. Auf den Befehl man instruments erhält man die wenig befriedigende Antwort No manual entry for instruments.

Der Eindruck, der unweigerlich dabei entsteht, ist, dass die SW-Entwicklung für iOS einfach alles beiseite lässt, was sich an Best Practices in anderen Gebieten etabliert hat. Liegt das daran, dass die Programmiung von iPhone Apps primär die Nacht-und-Nebel-Aktion von 1-Personen-Teams ist, die ihre App mal schnell zusammenstricken? Oder sind einfach die Tools noch nicht soweit, weil Apple den Fokus auf andere Bereiche legt?

Überleben als embedded Tester im Scrum Team

Mar 15
2012

Am Swiss Testing Day vom 14.3.12 habe ich diesen Talk zum Thema “Überleben als embedded Tester im Scrum Team” gehalten.

Das Interaktionsgeflecht habe ich mit den Seilen im Laufe des Talks erarbeitet. Die Reaktionen waren sehr gut. Ich hatte einige spannende Gespräche zu verschiedensten Punkten aus Methodik, Tooling, Staffing etc. Hier ist das Handout des Vortrags: Ueberleben_als_embedded_Tester_im_Scrum_Team_120305_Handout.pptx

Systemtests eines RESTful Webservices mit rest-assured

Mar 09
2012

Für einen RESTful Webservice habe ich mich auf die Suche gemacht nach hilfreichen Werkzeugen. In einem ersten Schritt bin ich bei den Browser Plugins gelandet, wie z.B. dem “Rest Advanced Client” für Chrome.

 

Für erste Versuche mit dem Webservice sind diese Plugins durchaus geeignet. So bekomme ich ein erstes Gefühl, ob das so funktioniert wie ich das gerne hätte. Ich kann mit Query Params und Path Params herumspielen und versuchen die Objekte in verschiedenen Mime-Types zu Posten.

Um dann aber den Webservice auf Herz und Nieren zu prüfen und diese Prüfung immer wieder ausführen zu können, brauche ich dann ein Tool, welches automatisiert die Requests auslöst. Dabei bin ich auf das Werkzeug rest-assured http://code.google.com/p/rest-assured/ gestossen. Und dieses Werkzeug hat es mir angetan…

Schon das Setup ist wirklich einfach:

Und trotzdem lassen sich damit dann auch kompliziertere Sachen machen:

Statuscode abfragen – kein Problem.

Request posten mit nach xml serialisiertem Objekt – ein Kinderspiel.

Inhalte der Response überprüfen – komfortabel über den “Pfad” im XML

Kurz und gut, dieses Tool kann absolut alles was ich brauche und lässt sich ganz einfach mit JUnit ausführen. Sehr zu empfehlen!

Embedded Testing in Scrum

Jan 14
2012

Als Teammitglied mit dem Fokus Testing im Scrum Team drin. So macht es meiner Meinung nach Sinn. So sind die Wege wirklich kurz, Bugs werden gefunden und gefixt mit minimalem Overhead und ich bin als Tester wirklich embedded – mitten im Team drin. Soweit die guten Neuigkeiten.

Die Schwierigkeiten, die wir zuvor mit konventionellen Testphasen nach der Implementierungsphase hatten, sind aber natürlich nicht verschwunden. Wie erfahre ich, was wirklich implementiert wurde und was Req Engineering und Entwicklung noch bilateral abgesprochen haben? Wie vermeide ich Doppelspurigkeiten zwischen Test auf verschiedenen Stufen – üblicherweise Integrationstest, die der Entwickler in JUnit schreibt und meinen automatisierten Systemtest?

Basierend auf einem Workshop bei Janet Gregory  haben wir zwei Synchronisierungspunkte in unserem Prozess eigeführt zwischen dem Entwickler und dem Tester eines bestimmten Features:

Das Meeting “Share-Test-Ideas” zur Absprache, wer welche Tests macht. Diese Synchronisierung findet bevor oder zu Beginn der Umsetung eines Features statt.

Und dann noch die “Show-Me-Session” sobald das Feature testbar und im Nightly Build drin ist, um zu besprechen, was nun wirklich realisiert wurde.

Diese Klammer um die Umsetzung bewirkt zwar keine Wunder, bringt aber enorm viel für die Zusammenarbeit und die Effizienz.

Im März 2012 werde ich am Swiss Testing Day einen kurzen Vortrag zu diesem Thema halten: Überleben als Embedded Tester im Scrum Team -Heisse Drähte, enge Verknüpfungen und gordische Knoten

 

Categories