The Testing Assembly 2024 seminar offered a range of ideas on software quality assurance and we can’t really say objectively which were the top three speeches (sorry about the click bait), but these three were the favourites of VALA’s Tuomas Kiviluoto and Tomi Keskinen. Let’s go straight to it!

1. The 3-pillar, balanced quality model By Szilard Szell, Eficode

Link to the presentation slides

In short:

The 3-pillar quality model is built on the principles of flow, feedback, and continuous learning. These principles are put into practice through proactive, detective, and reactive QA. Companies usually focus on detective QA, but a balanced approach means giving equal attention to proactive and reactive QA as well.

Proactive QA means using agile practices to make sure quality is built into the product from the beginning. Detective QA leverages automation to find potential problems faster. Reactive QA focuses on feedback to provide transparency and trust.

To support these three pillars, companies need an internal developer platform with the necessary tools, services, and information. They should also implement a continuous QA strategy in their CI/CD pipeline and set balanced quality goals to cover different aspects of the product.

Personal thoughts:

I found the concept of a balanced quality model with Proactive, Detective, and Reactive QA pillars to be quite insightful.  

It highlighted the need for a holistic approach to quality assurance, encompassing not just testing and bug fixing but also preventive measures and continuous improvement.  

I particularly liked the emphasis on shifting both left and right, ensuring that quality is embedded throughout the entire software development lifecycle. 

New ideas and ponderings:

• How can we shift our team’s mindset towards a more proactive approach to quality, and what are the potential challenges we might face in doing so?
• Are there specific metrics we can track to measure the effectiveness of each of the three QA pillars in our current projects?
• How can we create a culture of continuous learning and improvement within our QA team, and what role does leadership play in fostering this culture?
• Could implementing this balanced quality model potentially lead to faster delivery times and higher customer satisfaction for our products?
• How can we ensure that the ‘shift left’ and ‘shift right’ principles are effectively integrated into our existing Agile development processes?

2. The only constant in a changing world is failure By Anssi Lehtelä, Senior QA, SOK

Link to the presentation slides

In short: 

The session delved into the failure analysis model, exploring its components: background, trigger, and impact. Antti shared personal examples of failures and how he analyzed them. A key point was the importance of blameless postmortems.

The session’s key takeaways were that everyone experiences failure, even big failures, and that organizations rarely discuss and analyze failures adequately. The emotional impact of failure on individuals is often overlooked, but addressing these feelings is crucial for creating a culture of psychological safety and continuous improvement.

Blameless postmortems involve a facilitator to prevent finger-pointing, focusing on what happened without speculation in order to understand and learn. Openly discussing feelings helps prevent shame and guilt, even when the issue is resolved. The session concluded by encouraging a “failure specialist mindset,” embracing failure as a learning opportunity.

Personal findings:

Anssi Lehtelä’s presentation on failure analysis and blameless postmortems resonated with me on a personal level.  

It’s refreshing to hear someone acknowledge that failure is an inevitable part of the learning process..  

The emphasis on discussing failures openly and analyzing them without blame is crucial for creating a culture of psychological safety and continuous improvement.  

New ideas and ponderings:

• How can I introduce the concept of blameless postmortems to my team and organization? What are some potential obstacles and how can I overcome them?
• Are there ways we can proactively identify and address the emotional impact of failures on our team members?
• How can we create a safe environment where individuals feel comfortable sharing their failures and learning from them without fear of judgment?
• Could incorporating failure analysis into our regular retrospectives help us learn and improve more effectively?
• What are some practical steps we can take to foster a “failure specialist mindset” within our team and encourage a culture of continuous learning from mistakes?

3. Code or Low Code – Navigating the Test Automation Options By Maaret Pyhäjärvi, Director, Consulting, CGI

Link to the presentation slides

In short: 

The session explored the tools used in testing, with demos ranging from code-based to low-code and even AI agent tools. The speaker emphasized that searching for the “one best tool” is futile and distracts from the actual goal of automation. Instead, focus on incremental learning, starting with tools that fit your current scope, needs, and skills, and get started. Results matter more than the specific tools.

Learning to use these tools effectively happens in layers. It’s not just about syntax, but also understanding the environment, integrations, data, warehouses, and even business knowledge. Take it a bit at a time, gradually going deeper. Eventually, you’ll become proficient in multiple tools and languages. AI-assisted automation will handle a significant portion of the work, but the remaining part still demands your skills. 

The session also discussed the trade-offs involved in tool selection. Consider, for example, the granularity and overhead in feedback pointing you to where things got broken, the pros and cons of open-source and licensed tools, and the tool’s capabilities for reusability and ease of integration.

Finally, Pyhäjärvi stressed the importance of a whole team approach for continuity and ownership. If testers use the same language and tools as developers, automation and documentation will remain valuable even after people move on. This might mean shifting away from tools like Robot Framework or the use of Gherkin syntax. Collaboration with developers is key, with the goal of incorporating test automation ideas already into unit tests. The concept of “explore to build,” where test automation failures are seen as opportunities for exploration and improvement, and the idea of hyperautomation, where automation can nowadays do so much more than mere regression testing, were also highlighted as valuable approaches to maximizing the benefits of test automation.

Personal thoughts:

Maaret Pyhäjärvi’s exploration of code and low code testing tools was very informative and topical.  

The concept of incremental learning and becoming “polyglot and polytool” resonated with me.. I also found Maaret’s urge to extend the use of automation outside of regression testing particularly relevant nowadays. 

I also appreciate the emphasis on collaboration between testers and developers, ensuring that test automation efforts are aligned with the overall development process.  

New ideas and ponderings:

• Evaluating Current Toolset: How well does our current toolset align with our project’s current scope and needs? Are there gaps we need to address, or are we overly reliant on specific tools that might hinder reusability, flexibility or ownership?
• Learning Opportunities: What are some practical ways we can foster incremental learning and skill development within our QA team, especially in the context of emerging technologies like AI-assisted automation?
• Collaboration Strategies: How can we improve collaboration between testers and developers in our organization? Are there specific practices, such as pair programming or shared code reviews, that we could adopt to promote knowledge sharing and alignment?
• Test Automation Maintenance: How can we ensure the long-term maintainability and sustainability of our test automation efforts, especially as team members and technologies evolve?
• AI-Assisted Automation Adoption: What are the potential benefits and risks of incorporating AI-assisted automation into our testing processes, and how can we best prepare for this shift?
• Open-Source vs. Licensed: What are the key factors to consider when deciding between open-source and licensed tools for our specific testing needs and context?

• Blog
|
• QA
|
• Software testing