UKSTAR Speaker Siegfried Goeschl

Siegfried Goeschl

Company: Erste Group

Role in Company: Java Backend Developer

Country: Austria

Presentation Takeaways

1. Consider test tools as building blocks
2. Put Gatling on your radar when having strong development know-how
3. Be creative to extend the scope of your current test infrastructure

Speaker Biography

Siegfried Goeschl is currently an ASF member, Apache Turbine & JSPWiki PMC (Project Management Committee). Over the last 10 years he was also Apache Commons Committer & PMC working on commons-email & commons-exec, Apache XML-RPC Committer, Apache Isis & JSPWiki mentor and Apache Maven contributor. He became involved with Open Source in 2000 contributing JUnitPP (one of the first JUnit extensions ever), got involved with Maven, confused with Jelly and wrote an Avalon container now being part of Apache Turbine (this makes him to the last Avalonier in this part of the universe). His professional interests are centered around writing server-side Java code, full-text search, performance testing, quality assurance and build management. If there is some time left besides his company, consulting work, Open Source software development and family he helps at the local Java User Group and organizing the next GDG DevFest in Vienna.

Presentation Description

We all love to deliver well-tested and responsive software in rapid cycles to our customers. Consequently we invest a lot of time in test automation ranging from automated unit & integration tests to continuous performance testing. In this case study (Erste Bank’s George Online Banking) we follow the journey of introducing Gatling as simple tool to monitor the availability of REST endpoints. This monitoring turned out to be useful across multiple departments therefore a multi-tenant & multi-site test setup was introduced. To make the usage more convenient and accessible these tests were moved to a Jenkins automation server. Since Gatling test scripts are written in Scala you have all the programming power at your fingertips. The next step of the journey extended the Gatling scripts to compare the current JSON responses with recorded responses from the previous release in order to detect changes in the REST API. But at its heart Gatling is a performance test tool – turning the “functional” test suite into a full-blown performance test (including reporting) required just a few lines of code. At the end of this journey we look back at the separation of functional and performance test tools since both are means to the same end – delivering high-quality software.