Nordic Testing Days 2026

Test leadership is required at organizational and operational levels in many organizations. In this tutorial, we explain the fundamentals of test leadership and have practical exercises to understand it. We discuss what leadership means in different scenarios, where effective test leadership is needed, and where leadership is all too often missing.

Testing leadership is always needed, even if testing or development is subcontracted. Especially in larger organizations, organizational leadership is needed for testing, for example, to set the vision, harmonize testing across teams, increase productivity, align testing activities, and support different management levels and teams involved in testing.

The tutorial utilizes the ACT2LEAD heuristic about software testing leadership. To understand it properly, the audience is divided into teams with a brief exercise for each part of the heuristic. The ACT2LEAD heuristic consists of eight core practices of testing leadership.

We’ll go through eight principles in practice:

• ACT - how to add testing into all software development actions
• CONTEXT - how to choose the right testing based on context
• TRANSPARENCY - how to create visibility for the quality of testing practices and test results
• 2 - how to strike the perfect balance between automated testing and human-driven exploration
• LEARN - learning as a way to improve
• ENABLE - enabling a culture of quality and continuous improvement
• ADAPT - aligning testing efforts with product risks
• DIVERSE - implementing diverse testing approaches for finding diverse sets of defects and observations

The tutorial uses most of its time on several exercises set in the context of a large, imaginary corporation case study. In teams, participants create software testing leadership artefacts for the case study organization. The exercises are designed for the organizational level, but they also fit the team level.

The tutorial is ideal for roles like Head of Testing, QA Lead, and Test Manager. It is also good for anyone who wants to develop their competencies toward test leadership.

Each participant is encouraged to bring a laptop, though one per four people is sufficient. Internet access is needed, too.

Each participant gets an ACT 2 LEAD Software Testing Leadership Handbook as an e-book, which they can use to study this topic further.

Prerequisites for Attending the Tutorial:
Please bring a laptop if possible (group/pair work is also supported). During the session, you'll get free access to the ACT2LEAD Software Testing Leadership Handbook e-book, which we will use for hands-on exercises.

A high-level outline of the tutorial

• What is testing leadership
• ACT2LEAD heuristic for testing leadership, including a brief exercise
• Organizational and operational levels of testing leadership
• Short introduction to leading people and change
• Exercise: Stakeholder mapping
• Exercise: Create an organizational-level testing policy (principles)
• Exercise: Create an organizational-level strategy (guidelines)
• Exercise: Extended retrospective for visibility and continuous improvement
• Exercise: Testing in contracts
• Exercise: Competence development
• Optional Exercises, e.g., on Shift Left, Recruiting, Visibility, People, OKR

The general QA engineer role is on the rise as software projects become larger and more complex. General QA engineers have a broad set of skills to test complex systems end-to-end, going beyond the traditional QA role focused on component testing. They bring new perspectives by not being tied to one specific domain. This helps them test software more holistically across traditional boundaries.

Key Takeaways:

•  Adapt. Modern QA engineers must continuously expand their skills beyond traditional manual testing to stay relevant in a rapidly evolving industry.
• Collaborate. Quality is a shared responsibility — successful QA professionals work closely with developers, product teams, and business stakeholders beyond classic QA boundaries.
• Lead. QA engineers should drive quality culture, influence change, and become strategic contributors within their organizations, not just testers
  
  

Explore how critical thinking, curiosity, empathy, and human judgment are becoming even more important as AI continues to reshape software testing, education, and the workplace. Through engaging real-world examples and reflections on history, ethics, and technology, the session highlights why humans remain essential in guiding, questioning, and improving AI-driven systems. Attendees will gain practical insights into human-in-the-loop collaboration, ethical AI usage, and the future skills needed to thrive in an increasingly AI-powered world.

Key Takeawyas

• The presentation argues that as AI and LLMs become better at automation, the real differentiator becomes human judgment, curiosity, empathy, and critical thinking. The future is not “human vs AI,” but humans guiding AI responsibly.
• Critical thinking is becoming a survival skill in the AI era 
  A major theme is that people must learn to question information, recognize bias, and resist blindly trusting systems, algorithms, or AI-generated outputs. Especially in testing and quality assurance, asking the right questions matters more than ever.The best results come from “Human + AI” collaboration
• Rather than fearing AI, the presentation encourages using it as an amplifier for creativity, quality, and productivity, while keeping humans accountable for ethics, context, trust, and meaning. It positions testers and quality professionals as essential “humans in the loop.”

People who practice test-driven development (TDD) often describe it as a powerful approach. And while they make a convincing case, nothing beats experiencing it for yourself. So that's exactly what we'll do in this workshop.

We'll start with a brief explanation of TDD's red-green-refactor cycle. Red: write a test for the next bit of functionality you want to add. Green: write the code needed to make the test pass. Refactor: improve the code and the tests. Next, it's time to put that cycle into practice implementing a fairly simple algorithm. There's very little setup needed, so you can do this in any programming language you like.

In the last part of the workshop you'll share you experiences and your code. We'll reflect on those as a group, drawing lessons from it. And we'll discuss how the red-green-refactor cycle applies, even when you're writing something that's not unit testable, like test automation.

Prerequisites for Attending:
Please complete the setup of this workshop beforehand, by following the instructions in the "Setup for the kata"-section of the workshop repo: https://codeberg.org/joeposaurus/counterstring-codekata#setup-for-the-kata. The absolute minimum setup you need to do, is make sure you're able to write code and tests in a programming languague of your choice.

Key takeaways:

• TDD lets you take small steps with feedback at every step. 
• TDD lets you discover the right implementation as you go.    
• The ideas of TDD still apply when you're writing test automation.

Problem Context

• Brittle selectors: We spend hours fixing fragile XPaths and CSS selectors just to verify if a button is visible or a chart is correct
• Release changes: Automation code that is stable "now" suddenly becomes flaky after the release. The reason is the ever-changing platform. And automation is not always able to cope with it
• Code volume: Code analysis in our company showed us that assertion logic is typically five times (5x) larger in code size than action logic, consuming up to three months of dedicated maintenance effort every year

Solution
In this session, I introduce ViTO (Visual Testing Oracle), a production-deployed framework that leverages multimodal Generative AI (GenAI). ViTO "sees" the application exactly like a human does. The best part is that, in the end, it's just another block of code that can be embedded inside any framework.

Summary of what's in the talk
I will share:

1. The logic and algorithm of how we used GenAI to decouple verification from the underlying code resulted in a 50% reduction in our assertion codebase.
2. How we replaced thousands of lines of brittle verification logic with resilient, prompt-driven visual oracles that can handle complex data visualisations and unseen UI faults with zero extra effort. If you are tired of your tests breaking because a div changed, it's time to shift from structural selectors to a visual AI oracle.
3. The lessons learned from our initiative, and above all, where NOT to use GenAI
4. Access to the boilerplate code that you can implement within your repo
5. If time permits, a demo of the framework in action. If short on time, the link to the boilerplate is provided in the slides :)

Who is this for?

• QA Architects, Senior SDETs, Automation Engineers, Manual testers looking to transition to GenAI-based testing;
• Managers/architects looking for a language-agnostic framework to build GenAI-based assertions
• Anyone who wishes to know where to and where NOT to use GenAI in testing
• QA professionals looking for a starting point (boilerplate) code to embed GenAI in their automation

Key takeaways:

• In-code GenAI: How to implement GenAI directly "in-code" using any programming language
• Prompt Engineering for Testers: How to write resilient "Assertion Prompts" that replace complex conditional code and handle visual regression automatically.
• Real-World ROI: Evidence-based results from a production environment, showing a 50% reduction in code maintenance and expanded coverage for rich UI components.
• Deterministic AI: Practical strategies to control GenAI hallucinations using "concentrated screenshots"
• A sneak peek into what's coming in the future in GenAI for test automation

The security impact of missing input validation is usually underestimated.

The presentation explains and gives examples of how missing logical limits may lead to denial of service attacks on the application that seems quite secure - no injection or execution vulnerabilities needed.

As the presenter is a co-lead of the OWASP ASVS project, related security requirements are also pointed out.

Not a single word about AI.

How do you test an application that relies heavily on cloud services? Do you have a specific strategy for testing it, or do you simply run your tests regardless of the infrastructure costs?

Nowadays, many applications rely on different cloud services, such as databases, message queues, and file storage offered by cloud providers. Those cloud services bring considerable infrastructure costs and complexity in terms of testing cloud applications. The challenges include teams relying on mocks to test the application locally and in CI/CD, as well as extra costs to create test environments that use real services. However, a good alternative to deal with that is to use emulation tools to simulate those cloud services, providing good confidence and saving a lot of costs.

In this talk, we’ll explore how Testcontainers and LocalStack offer an affordable and scalable solution to cloud application testing without compromising on quality. This session will demonstrate (including a live showcase) how to use Testcontainers in combination with LocalStack to spin up containerized services to emulate all the AWS cloud services that your application depends on, enabling you to have your own cloud running locally on your machine or CI/CD. Together, those two tools can provide an efficient, cost-saving alternative to traditional cloud testing strategies.


Key takeaways:

• Learn how to create and run tests for cloud applications using free and open-source tools while reducing the costs of infrastructure and cloud services.
• Discover some common challenges when testing cloud applications and how to deal with them.
• Understand how to use real containerized cloud services instead of mocks to make your tests more closely mimic the production environment setup.