Im Testing Center von Microsoft Test Manager findet sich der Tab ‚Organize‘ unter dem sich vier Sub-Tabs finden.
Obwohl man sich laut den Breadcrumps in einem bestimmten Testplan befindet, werden in den vier Sub-Tabs per default alle Entitäten (Test Pläne, Test Konfigurationen, Testfälle, Shared Steps) innerhalb des TFS Team Projekts angezeigt, was einigermaßen verwirrend ist.
Grundsätzlich kann man sagen, dass die Spaltenbenutzung nicht ganz so intuitiv ist, wie man es sich wünschen würde:

• Zu den sichtbaren Spalten kann man mit einem `Geheimtrick` noch weitere hinzufügen. Rechtsklick auf die Spaltenüberschriften-Leiste und zahlreiche zusätzliche Spalten können zum Anzeigen ausgewählt werden.
• Auch kann man die Spalten aufsteigend/absteigend sortieren, indem man ein bzw. zwei Mal auf die entsprechende Spaltenüberschrift klickt.
• Einige Spalten kann man noch filtern. Wenn man mit der Maus über die rechte Ecke fliegt, erscheint aus dem Nichts ein Pfeil. Bleibt er grau, kann man nicht nach den Spaltenwerten filtern – wird er schwarz, kann man es.

Was noch sinnvoll gewesen wäre, wenn man die Tabs schon ‚Manager‘ nennt, wäre noch ein Zähler aller aufgeführten Entitäten in den einzelnen Sub-Tabs.
 
Test Plan Manager
In diesem Tab finden sich alle Testpläne eines TFS Teamprojekts aufgelistet. Eine Besonderheit stellt noch der Button ‚Edit run settings‘ dar, wohinter man die Datensammlung beim Testen erweitern kann – nähere Erläuterungen: hier.
 
Test Configuration Manager
Was es mit den Testkonfigurationen auf sich hat, kann man am besten an konkreten Beispielen verdeutlichen. Eine Konfigurationsvariable für einen Test ist beispielsweise das Betriebssystem – die einzelnen Werte der Konfigurationsvariable können also beispielsweise Windows, Linux oder MacOS sein. Eine weitere Konfigurationsvariable für das Testen von Webanwendungen ist beispielsweise der Browser. Diese Konfigurationsvariable kann die Werte Firefox, Chrome, Internet Explorer, Safari oder Opera annehmen. Eine Konfiguration ist eine mögliche Kombination aus den Werten der Konfigurationsvariablen, z.B. (Windows, Firefox). Legt der Testmanager also diese Konfiguration für den kommenden Testdurchlauf fest, dann teste ich den Testplan gegen die Anwendung auf Firefox auf einem Windows-Rechner. Genau das kann man im Sub-Tab Test Configuration Manager einstellen.
 
Test Case Manager
Bei einer Testsuite mit sehr vielen Testfällen friert MTM erstmal für ein paar Sekunden ein, bevor man weiterarbeiten kann. Man kann die Auswahl der Testfälle nun einschränken, indem man sich der üblichen Spaltenfilter oder eines erweiterten Filters bedient; letzteres indem man auf ‚Unfiltered‘ klickt. Jetzt kommt die nächste kleine Verwirrung, denn obwohl das Dropdown-Menü ‚Unfiltered‘ angezeigt hat, erscheint ein Filter, den man nun editieren kann. Z.B. kann man diesen default-Filter nun weiter einschränken, indem man noch eine weitere Teilbedingung hinzufügt, z.B. zur Ausgabe ausschließlich automatisierter Testfälle:

Mittels Run-Query kann die vorläufige Auswahl ermittelt werden und mittels ‚Save query‘ wird die Auswahl schließlich gespeichert. Ob diese nette Funktion ausreicht, um den Tab mit dem Begriff ‚Manager‘ zu adeln sei einmal dahingestellt.
 
Shared Steps Manager
Shared Steps sind zusammengefasste Testschritte, die in einem Testfall wiederverwendet werden können (das gern genommene Standardbeispiel ist ja der Login). Der Sub-Tab Shared Step Manager funktioniert analog zu dem Sub-Tab Test Case Manager. Zusätzlich gibt’s noch den Button “Create action recording“ – hier steht, was es damit auf sich hat. Warum es einen solchen im Shared Steps Manager gibt, nicht jedoch einen analogen im Test Case Manager bleibt wohl für immer das Geheimnis der Erbauer dieses Tools.

Automated UI tests are flaky by their nature. They are not unit tests, which are stable by their nature. If you try to fix a UI test, that fails 2 times while 10 times passing, you’ll find yourself in the Heisenbug hell. Even throwing man-years on debugging those flaky testcases, you can only reduce the flakyness of your testsuite, but you can’t dissolve it. When even Google’s ‚world class engineers‘ can’t beat that beast – we think we can? You can continue playing that game, but from this day on, I am out!
What does one FAILed UI test tell us? Nothing! If only one UI test PASSed out of hundered runs (given the same version of AUT) – the testcase is PASSed! Because it practically can’t PASS even once, if there would be a functional bug on its way. We don’t know why the other 99 runs have FAILed. Perhaps because the server of the testenvironment was under varying load (which BTW also lies in a testservers nature), perhaps because UI element x sometimes is faster than the UI element y, the test-driver itself is flaky or perhaps because the devil’s in the code. Even if the root cause is really a race-condition in the AUTs code: You won’t convince the dev to spend time on it, with your testruns telling him ’sometimes it works, sometimes not‘, as this is no reproducable base for his debugging.
CI-Tools have to adapt: Re-run is the magic word. If an automated UI testcase FAILes in the nightly testrun, rerun it. Repeat that till dawn. If it won’t PASS once in that night – then, and only then, it’s really FAILed and you have to analyze it in the morning.
These thoughts are nothing less than a paradigm change in UI testautomation. In the aseptic world of quality assurance you were teached that tests have to be stable, accurate and repeatable to be reliable. Now, you have to convince yourself that a FAIL is not an alert. It’s like the change in mind you have to execute coming from classical logic to fuzzy logic. Reality is fuzzy, UI tests are flaky.
Honor to my great test automation collegues @ GfK.

postscript: Ranorex uses herefore the auto-retry feature.

After some years experience: A test case that fails twice will most likely also fail a third time. The third run costs a disproportionate amount of time with very little gain in knowledge. In addition, very(!) flaky tests should be debugged.

Appium, welches in der Selenium-Welt berühmt ist, scheint mir nicht geeignet zu sein, langfristig angelegtes mobile testing zu betreiben.
Auch weitere Open-Source Projekte, die zu diesem Zweck ins Leben gerufen wurden, scheinen so langsam einzuschlafen, wie die Commit-Aktivitäten auf github nahelegen:
Robotium

Selendroid

So fallen diese drei Tools für diese Aufgabe aus. Die Frage, welches Tool Google eigentlich für die UI-Testautomatisierung von Android Apps nutzt, ist hier aus zweierlei Aspekten relevant. Erstens ist Google der Hersteller vom Android-Betriebssystem und hat daher genügend Insiderwissen, die richtigen Tools auszuwählen. Zweitens entwickelt Google selbst eine nicht unerhebliche Anzahl von geschäftskritischen Android Apps und muss diese natürlich auch zuverlässig testen.
Googles UI-Testautomatisierungslösung für Android Apps ist ohne Zweifel Espresso:
Artikel auf Googleblog
Talk auf Android Dev Summit
Talk auf Google I/O (inkl. tieferer Einblicke in Espresso-Codebase)

• Reine Oberflächentests – simulieren Benutzerinteraktionen
• Stark integriert in Android Development
  • Teil der Android Testing Support Library
  • Tests werden zusammen mit apk instrumentiert
  • Gestartet aus Android Studio
  • Im App-Code kann/muss man idle-Zustand setzen, damit Esspresso darauf reagiert.
  • Zum Programmieren in Java
• It is intended to test a single application but can also be used to test across applications. If used for testing outside your application, you can only perform black box testing, as you cannot access the classes outside of your application. (Quelle)
• Gutes Tutorial: http://www.vogella.com/tutorials/AndroidTestingEspresso/article.html#espresso_introduction