August 2025 Quality Engineering Meetup in Berlin

In the middle of August — peak vacation season in Europe — we managed to pull off a record-breaking Quality Engineering meetup. Around 100 people showed up, making it our biggest gathering yet. That kind of turnout, especially when beaches and mountain trails are calling, tells me we’re doing something right, and people aren’t just coming for the talks, they’re coming because they genuinely enjoy this community.

Component Visual Testing: Our Journey from Flaky Screenshots to Stable UI Confidence

Full-page visual tests can be powerful, but anyone who’s worked with them knows they can also be slow, flaky, and overly sensitive to unrelated changes. At Qase, we wanted something faster and more stable for catching smaller, component-level issues.

That’s where visual component testing came in. As Anastasia explained, it’s like unit testing for the UI: you isolate a component, capture a baseline screenshot, run your changes, and compare the results. Because each test focuses on a single component, it runs quickly, produces far fewer false positives, and can be easily written by frontend developers themselves making it a natural part of their workflow.

By introducing component visual tests alongside our existing full-page tests, we’ve been able to reduce the number of full-page checks to only where they add real value, while dramatically increasing our coverage and stability at the component level.

The First Bug Is Always in the Conversation

Patrick Mölk’s talk at our recent meetup hit right at the heart of something I've praised for years: most bugs don't start in the codebase, they originate in the social part of the work, in communication and information loss. This social side of development and testing is chronically neglected in our industry unfortunately :(

As Patrick reminded us, there's no way to completely avoid information loss during transmission, it's inevitable. The real challenge, and duty of management and engineering, is to design processes that compensate for it.

Without clarity, context, and precision in how we talk and write, Quality Assurance becomes little more than damage control. If we get communication right, we can spend less time in meetings and more time actually delivering cheaper, faster, with fewer mistakes, and with features that do what users actually need.

Rebuilding a Ship at Sea: QA Behind the Kotlin Plugin Rewrite

Sergey Moryahin, Head of QA for Kotlin at JetBrains, shared the behind-the-scenes story of an ambitious rewrite of the Kotlin plugin. From aligning automation and exploratory QA to coordinating with developers across a fast-moving codebase, his talk was a story of adapting QA processes to real-world constraints.

One of the key takeaways was the importance of context sharing: adding automation QA engineers to exploratory QA meetings eliminated wasted cycles caused by enabling tests too early. Sergey also highlighted risk-based testing, focusing effort where it delivers the most value, and the need to re-evaluate tools as a project evolves (what worked for early development may not scale for complex integrations)

Perhaps most memorably, he introduced the idea of using "fear" as a quality signal: if developers hesitate to make changes because they don't trust the tests, it's a red flag that the suite needs work.

See you at the next meetup in Berlin on 9th October!

Please follow our Quality Engineering Meetup Berlin group to hear about upcoming meetups in Berlin. We’ll also be experimenting with new cities around Europe — follow us on LinkedIn to be the first to hear about new locations.