SIGS DATACOM Fachinformationen für IT-Professionals

SOFTWARE MEETS BUSINESS:
The Conference for Software Architecture
Munich, 03 - 07 February 2020

Sessionsdetails

Talk: Di 3.1
Date: Tue, 04.02.2020
Time: 09:00 - 10:30
cart

Remote Mob Testing: Es geht auch über die Distanz!

Time: 09:00 - 09:45
Talk: Di 3.1 1)

 

Testen des gleichen Features, am gleichen PC, zur gleichen Zeit, aber von verschiedenen Standorten – durch den Gewinn von zwei Remote-Teammitgliedern aus Ungarn musste das agil arbeitende Team ihre Mob Testing-Routine anpassen. Denn schon während der ersten Test-Session sahen sie sich mit vorab nicht bedachten Herausforderungen konfrontiert. Dieser Talk beleuchtet diese, stellt viele Lösungsideen vor – auch solche, die für das Team nicht funktioniert haben -, gibt einen Ausblick auf die Qualitätsverbesserung und leitet nützliche Tipps ab.

Zielpublikum: Tester, Entwickler, Projektleiter
Voraussetzungen: Fachkenntnisse agile Methoden
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract
Die Vorteile von Mob Testing Sessions sind bekannt. Ebenso wie bei Mob Programming arbeiten alle Teammitglieder daran, dasselbe Feature, zur selben Zeit, am selben Computer und am selben Ort zu testen – außer sie arbeiten remote.
Nachdem wir regelmäßige Mob Testing Sessions erfolgreich in unser Team integriert hatten, stärkten wir unser Team durch zwei neue Teammitglieder, die dauerhaft im Homeoffice von Ungarn aus arbeiten. An regelmäßige Telefonkonferenzen mit Screensharing gewöhnt, machten wir uns keine großen Sorgen, die zwei neuen Teammitglieder schnell in unsere Mob Testing-Routine integrieren zu können. Doch schon während der ersten Test-Session sahen wir uns mit vorab nicht bedachten Herausforderungen konfrontiert:

  • Technologie (digitales Whiteboard, Kamera, Mikrofon, …)
  • Kultur (Sprache, Vermitteln von Mob Testing-Praktiken)
  • Session Setup (Wechsel des Drivers nach Ungarn, Erklärung des Kontextes)

In diesem Talk berichte ich in Bezug auf den Teamkontext detailliert, mit welchen unerwarteten Herausforderungen wir konfrontiert waren und wie wir mit diesen, beeinflusst von den Erfahrungen, die ich bereits in einem anderen remote arbeitenden Team gesammelt habe, umgegangen sind. Ich werde beleuchten, welche Maßnahmen für uns funktioniert haben und vor allem, was nicht funktioniert hat. Zudem gehe ich auf die positiven Nebeneffekte, wie z.B. ein besserer Teamzusammenhalt und bessere Qualität der Anwendung, sowie die Bedeutung von „jó reggelt“ ein. Zum Abschluss spreche ich über unsere Teamlösung für ein erfolgreiches Remote Mob Testing und Tipps und Tricks für Teams in ähnlichen Situationen. Zudem gebe ich einen Ausblick, wie wir die Lösung unserer Herausforderungen auf andere Teamkontexte übertragen haben.

 

The Oligopoly. What Is The Right Mix Of Test Automation Tools In A Software Development Company?

Time: 09:45 - 10:30
Talk: Di 3.1 2)

 

It is hard to find the right test automation tool, especially when your decision affects not one project, but many different ones.
On one side, in terms of agile transformation, each team should be allowed to pick a test automation tool by itself.
On the other side, for the sake of resource liquidity, you will seek to use same tools across similar projects.
As test manager, I continuously face the dilemma: should I support an anarchy of test automation tools across agile projects and let the fittest survive, or should I keep a monopoly?

Target Audience: Test Managers, Test Automation Engineers, Decision Makers
Prerequisites: Testing in Agile Development, Testing in Waterfall
Level: Practicing

Extended Abstract
At different times, we opted for different automation tools, such as Robot Framework, Protractor, Behat and Cucumber, Cypress and Jest. The decision was depending not only on the technical fulfilment of our use cases, but not much less from the knowledge availability, our release and deployment processes, as well as fitting into our tool landscape.
Each of those tools is doing its job on its dedicated place. What are they good for and what are the shortcomings? How will I conduct the decision process for a test automation tool in the future, out of my lessons learned?
This talk is not about "the right catalogue" of tools, but about a systematic approach at the tool selection, as well as about the transformation of this approach in scope of DevOps.
My shared experience will be interesting in the first line for decision makers managing multiple agile projects, working with JavaScript/NodeJS and PHP, as well as for test managers, supervising both legacy and greenfield projects.