We’ve now hosted four Quality Engineering meetups in Berlin and we’re thrilled to announce that this will be a regular event! Keep an eye on our Berlin meetups page to be the first to know about upcoming events.
At this event, we had some intriguing discussions about why it’s important to feel passionate about your work, testing complex projects, and when it makes sense to embrace chaos.
Misconceptions among QA that prevent the growth and and release of great applications
Mobile QA engineer, IT Blogger, and QA Tutor Vladislav Kazachek presented his talk on what he thinks hinders both testing itself and testers’ career growth in mobile testing.
“To excel in quality engineering, stay current on tools and updates, collaborate closely with developers and peers, and embrace a passion for mobile apps and smartphones that keeps you engaged and inspired.”
I fully support what Vladislav says about the importance of passion. In my article about building a continuous learning mindset as a QA professional, I say that QA is a vast field, and it takes a solid commitment to ongoing learning. I believe this continuous learning journey is only possible if you’re genuinely passionate about the profession.
Testing Kotlin Compiler
Alexander Zakharenko, a QA engineer from JetBrains Kotlin team, gave a talk about testing one of the most complex projects I’ve seen — Kotlin compiler. Testing a programming language isn’t an easy job. You need to test not only the compiler itself with its intricacies, such as Garbage Collector (GC), but also the tooling around it, its integration with IDEs, and its performance.
The audience was really engaged with this talk — there were lots of questions and discussions, particularly around the topic of PICT. This tool helps manage the testing of projects with high combinatorial complexity.
Let’s say the module you have to test has five parameters with five possible values each. This means that complete combinatorial testing would require 3,125 test cases! However, PICT’s pairwise testing might reduce this to a manageable subset of around 25-30 test cases. Compiler has extremely high combinatorial complexity: it has hundreds of parameters affecting each other, and there’s literally no way to test all their combinations. Aleksandr and his team employed PICT to help with this.
People were also surprised to learn that the JetBrains Kotlin QA team uses a great deal of exploratory testing:
“With exploratory testing, we try to dig deep and research the problems. We don’t have test plans, but rather guidelines”
It’s really interesting to see how mature teams working on big and complex projects realize that automation can’t cover everything and that the importance of thoughtful manual testing is never going to decrease.
How we delegated chaos engineering to product teams
After the pizza break, we had another great talk: Aleksandr Ilin told a story about the evolution of chaos testing on his project.
Only a few people in the audience were actively using chaos testing, and there’s a reason for that: it’s scary and expensive. The goal of chaos testing is to improve the overall system resiliency by deliberately breaking parts of it. Understandably, people usually don’t want their production systems to be purposely broken on a regular basis. The motto “if something hurts, do it more often” isn’t the most intuitive one, but only practice can yield readiness for unforeseen events, and that’s a major part of what chaos testing does.
The main questions we discussed with the audience were how to predict the ROI of chaos testing and how to persuade management that it’s needed. Unfortunately, there’s no silver bullet here: pretty much all proactive risk reduction activities are budgeted based on a prognosis, not exact data. However, framing it as an investment activity can help.
Come hang out with us!
We will have our next meetup in Berlin in early December. Follow our meetup group to stay informed.
We also have meetups coming up in Stockholm on November 12, 2024, and Amsterdam on November 27, 2024.
