Quality Narrative: Chat with Jan, Frontend Architect
The most frequent communication of them all, the one that can elevate the delivery to perfection, but also make us reinvent processes from the ground up, is the one between development and testing. To truly understand how to align on quality standards in that relationship, I decided to talk to one of most passionate developers I met to date. His name is Jan Buschtöns and he is Frontend Architect at Clark.
Jan joined CLARK back in May 2018 as a Software Architect & Ember.js / Frontend specialist. He recently passed the iSAQB Certified Professional for Software Architecture (CPSA-F) exam.
Ultimately, he wants to feel proud of his and his team’s work: “I personally identify with our product. In order to keep improving the lives of our customers, we need to stay ahead of the curve — in all regards.”
Some call him the “Frontend Critic” and his motto is “ship it, but don’t ship shit.” 🚢
Finding out what keeps Jan passionate about quality
Zlatan: Why is quality important to you?
Jan: I identify with my work and the product we build and I want to be proud of the things we ship. If you want to ship value to customers fast and often, you need to build a quality product, there is no other way in my opinion.
Zlatan: What indicates that your team puts quality first?
Jan: When we look at KPIs for development and QA teams, they might seem to oppose each other — ship as fast as possible from development side, and ship code without major bugs from QA side. The key is to strike a balance between these. In my opinion, in an ideal world, manual testing is a practice that should not happen often in the development lifecycle. We should automate as much as possible, and run the correct subset of tests in the correct places — not apply all tests at every single point. If you have a well partitioned codebase, and can test all parts individually, that allows you to continuously roll out small changes to production, minimizing the impact and risk. As a practice, e.g. a traceability matrix is one of the things that can help with achieving this. Automated static code and dependency graph analysis is just as, if not more, important and helps a lot in building and maintaining such a matrix.
Zlatan: What motivates you to contribute to test automation, on this way to fast and secure iterations?
Jan: I think it’s crucial that we enable engineers to easily write and run any kind of test. Having a proper test harness in the first place can make the whole difference, enabling proper test automation planning, and lowering the risk of future changes, as well as boosting engineer confidence. Retrofitting tests to existing code is far more complex than writing tests with the code from the get-go. Imagine joining a team to help them with certain features, or contributing to an open source project — you are there to add code and tests for that code, not to set up a test automation framework. When I see an existing framework in place, it makes it much easier to actually contribute the features themselves.
Zlatan: What are your expectations from QA Engineers that you collaborate with?
Jan: Product knowledge is the first thing for sure. This includes both the domain of the product itself, as well as the test environments for it, and areas of high risk. This helps in building efficient developer-tester relationships. Striking the right balance when it comes to the amount of testing is important as well. Overzealous testing scope hinders speed of development and causes friction in the team. Communication & mutual feedback is key. When the QA Engineer and Developer are well-aligned on these points and take the time to understand each other’s needs and concerns, the product & quality will ultimately profit from this.
Zlatan: Jan, thank you for helping us kick off the Quality Narrative journey and sharing your views on quality!
Jan: Thank you, it was my pleasure!