Bits 'n Pieces about Software Development, Mobile Applications and Testing
Auf der Titelseite des Blogs von Ilari Aegerter bin ich auf diese tolle Anweisung gestossen:
Nach einer halben Sekunde nachdenken ist mein Impuls dann klar: Natürlich klicke ich da drauf! Die Folgen dieses Klicks haben mich dann begeistert. Genaueres ist wie gesagt hier nachzulesen.
Und – ja: Ich glaube, wir dürfen uns nicht von irgendwelchen Anweisungen abschrecken lassen. Das ist wohl sogar eher ein Ansporn 😉
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?
Das hätte ich nun so nicht erwartet:
Gemäss einer in Forbes publizierten Umfrage “The Happiest Jobs In America” ist der Job, der eben am meisten glücklich macht, der Software Quality Assurance Engineer. Und das weit vor dem HR Manager, dem Finanzanalysten oder dem Software Engineer.
Spannend!
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
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!
Wie gut muss die Qualität des Codes beim Testwerkzeug sein? Die Schulbuchantwort ist klar: (Mindestens) Gleich gut wie diejenige des produktiven Codes. Dafür gibt es verschiedene Gründe. Da wäre beispielsweise die Lebensdauer des Codes zu nennen: Der Code, mit dem die Regressionstests ausgeführt werden, lebt ebenso lang, wenn nicht sogar noch länger, wie das System under Test (SUT). Oft überleben sie das SUT sogar und werden als Referenz für das Nachfolgesystem weiter benützt.
Die Notwendigkeit ist also klar gegeben. Trotzdem ist es schon hart genug, die Testautomatisierung synchron zur Entwicklung hochzuziehen und eine ausreichende Abdeckung mit automatisierten Systemtests zu erreichen. Bereits dafür fehlt oft die nötige Zeit oder die Ressourcen. Und deshalb bleibt dann manchmal eben die Codequalität auf der Strecke.
Die bei uns eingesetzten Werkzeuge Findbugs, PMD und Checksyle kennen da keine Gnade. Die Rulesets sind die gleichen wie beim produktiven Code und entsprechend fliegen uns auch die Violations um die Ohren. Und dann ist da noch das Problem, dass ich beim neuen Code darauf achte, regelkonform zu sein, aber dann sind da noch die Hunderte von Violations, die eben schon vorher drin waren. Und das schlägt dann eben auch noch etwas auf die Motivation.
Ähnliche Probleme stellen wir auch bei unseren Unittests fest. Auch da fällt es schwer, die gleiche Qualität zu erreichen und einzufordern.
Da bleibt wohl nichts anderes übrig, als sich wieder einen Ruck zu geben – und dann los auf die Violations. Heute wird aufgeräumt!
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
This is rather a personal collection of the links and annotations i picked up during the ATD 2010 that i just don’t want to lose:
Exploratory Testing:
Testing in the agile world:
Acceptance Tests and Notations:
Testing as Investigation Process:
How to improve in SW Testing:
Interesting Tools:
All these articles, ideas and tools seem to me to be interesting as well as relevant to my work in the software development. Let’s see how far i get in reading… 🙂
Im Google Testing Blog habe ich heute einen fantastische Parabel zur Frage gelesen, wieviel code coverage ausreicht. Viel Spass beim Lesen!
Im Blog von James Bach (dem Autor des Artikels “Test Automation Snake Oil“, in dem ich immer wieder neuen Input zum darüber Nachdenken entdecke) habe ich ein Video gefunden, das mich einfach begeistert hat.
Hier ist es:
Einfach cool, ist es nicht?
Gedankensplitter, Links, Ideen zu Software Entwicklung, Mobiile Applications und Software Testing.
Dieser Blog stammt von Thomas Briner-Lienhard , Software Engineer bei Ergon Informatik in Zürich.
9th sphere web design
Comments