1. Abstract
Merging code that hasn’t been fully tested is one of the biggest reasons teams experience missed release dates and flaky test suites. Why? Merging code often means other developers start their new work based on the newly merged code, changes are queued up for the next release, and the code quickly becomes coupled to other changes. The result is often code freezes, failing test runs, late-night release “parties,” and painful go/no-go meetings where you get pinned between postponing the release or shipping with bugs. This problem is compounding as teams adopt AI-generated code — code that can look correct but hasn’t been validated end-to-end in a real environment.
Deploying to and testing ephemeral environments gives your team the ability to know for certain that new features are implemented correctly before committing those features to the release and before other developers start depending on the new code. An ephemeral environment is a short-lived, on-demand deployment spun up automatically for a feature branch and torn down when the branch is merged or closed. This approach isn’t just a nice-to-have; it is becoming an essential practice for any team that wants to ship with confidence.
This is a concepts-first workshop. Rather than locking attendees into a specific tool chain, we focus on the underlying patterns and principles that make ephemeral environment workflows effective — patterns you can apply regardless of your current CI/CD setup, hosting provider, or testing framework. That said, we do not stay purely theoretical. Throughout the workshop we walk through a complete, working reference implementation built on GitHub Actions for pipeline automation, Octopus Deploy for deployment orchestration, and Testery for test execution and management — a real application that provisions an environment per pull request and tears it down on merge.

2. Agenda
The workshop is delivered as seven modules. Timings below assume a 09:30 start and follow the break schedule provided by the organizers (10:55–11:20, 13:00–14:00, 15:30–15:55); each break falls on a module boundary.

Module 1 — Introduction (09:30–10:25, 55 min)
What ephemeral environments are
• Definition: a short-lived, on-demand deployment created automatically for a feature branch and torn down when that branch is merged or closed
• The four defining characteristics: on-demand, isolated, disposable, automated
• How they differ from the environments you already have — shared staging, a QA environment, a personal dev box, a PaaS preview app
Why it matters
• Opening discussion: what does the room’s release process actually cost them today?
• The merge-then-test failure mode — merging is a commitment to release, and other developers immediately start building on your code
• Running tests after the merge means sharing broken code with the team
• Downstream symptoms: code freezes, long-lived stabilisation branches, late-night release “parties,” go/no-go meetings where the only options are slip or ship bugs
• Why trunk-based development requires testing before the merge to work at all
What you are trying to get
• Merge confidence — knowing a feature is correct before it is coupled to everything else
• A window for manual review and sign-off before functionality is committed to a release
• More representative infrastructure than a workstation, and enough capacity to run tests in parallel
• Reduced variability — eliminating “works on my machine” from the equation
• Faster, earlier feedback for the developer who still has the context loaded
Results — what good looks like
• Case study: 12,000+ tests per hour, typically fewer than five failures, no more code freezes or release parties
• The metrics worth tracking: percentage of pull requests with a green end-to-end run before merge, time-to-feedback on a pull request, change failure rate, how often the trunk is broken
• Honest accounting of the costs: infrastructure spend, provisioning time, and the engineering effort to build and maintain it

Module 2 — Branching Strategies (10:25–10:55, 30 min)
• Why the branching model determines whether ephemeral environments are even possible
• The options and what each implies: GitFlow, GitHub Flow, release branches, trunk-based development with short-lived branches
• Recommendation: short-lived branches, one pull request per change, merged within days rather than weeks
• Keeping test code in sync with feature code — same repository versus separate test repository, and the versioning problem the split creates
• Branch naming conventions, and how they flow through to environment names, subdomains, and resource tags
• What breaks with long-lived branches: drift, merge conflicts in test code, environments that live long enough to become pets
• Discussion: attendees map their team’s current model and identify the first constraint they would hit
Break — 10:55–11:20

Module 3 — Deploying Ephemeral Environments (11:20–13:00, 100 min)
What has to be true
• Infrastructure has to be provisionable automatically, with no ticket and no human in the loop
• Something has to decide when to tear it down
• DNS has to resolve to the right instance
• Configuration and secrets have to be injected per environment
• Dependencies — databases, queues, third-party services — have to be available or stubbed
The options
• Namespace-per-branch on a shared Kubernetes cluster
• Full infrastructure-as-code stack per branch (Terraform, Pulumi, CloudFormation)
• Platform-native preview environments (Vercel, Netlify, Heroku review apps, Azure deployment slots)
• Container-per-branch on a shared host, or Docker Compose for smaller stacks
• Trigger models: per-pull-request, per-branch, or on-demand by label — and why per-pull-request is usually right
Trade-offs to weigh
• Provisioning time versus fidelity to production
• Cost, and how quickly it compounds across a busy repository
• Blast radius and isolation between environments
• Operational complexity, and who ends up owning it
Making it work in practice
• Lifecycle: create on pull request open, update on every push, tear down on merge or close
• TTL sweepers for orphaned environments, because teardown will fail sometimes
• DNS: subdomain per branch, wildcard certificates, and the collision cases
• Configuration and secrets management per environment
• Cost controls: TTL, auto-sleep, per-repository quotas
• Edge cases that trip teams up: parallel branches, dependency conflicts, naming collisions, migrations that do not roll back
Worked example
• End-to-end walkthrough of a real reference application: pull request opened → branch name normalised → images built and pushed → release created in Octopus Deploy → environment registered in Testery → URL posted back to the pull request
• The matching teardown path: pull request closed → environment deleted
• How the same pattern translates to GitLab CI, Jenkins, and Azure DevOps
Lunch — 13:00–14:00

Module 4 — Test Data (14:00–14:50, 50 min)
• Why data is the hardest part of ephemeral environments, and the part most teams underestimate
The options
• Isolated database per environment
• Shared database with tenant or namespace isolation
• Snapshot and restore from a golden image
• Synthetic generation on demand
• Production clone with masking — and the compliance questions that come with it
Trade-offs and recommendations
• Provisioning time, realism, isolation, storage cost, and regulatory exposure
• Which approach fits a small team, a large monolith, a microservice estate, and a regulated environment
Managing data through code
• Schema migrations versioned in the repository and run automatically on provision
• Seed scripts versioned alongside the application, not maintained by hand
• Factories and fixtures over curated database dumps
• Idempotent seeding, so a re-deploy does not corrupt state
• Tests that create the data they need through the API rather than depending on pre-existing records
• Anti-patterns: shared mutable fixtures, hardcoded record IDs, tests that depend on execution order, manual database preparation
• Cleanup and teardown — and why per-environment isolation makes most of this problem disappear
• Exercise: attendees classify their team’s current approach and pick a realistic target state

Module 5 — Creating Automated Tests (14:50–15:30, 40 min)
• Writing tests that do not know where they are running: base URL injection, no hardcoded hosts, configuration read from the environment
• Managing environment-specific variables and secrets in the test suite
• Test isolation and independence — the prerequisite for running anything in parallel
• Handling application readiness after a fresh deploy: health checks and smoke gates instead of arbitrary sleeps
• Deterministic waits, and the flakiness patterns that come from getting this wrong
• Per-test data setup rather than reliance on global state
• Scoping the suite: what runs on every pull request versus what runs nightly
• Framework-agnostic patterns, demonstrated in Playwright, with equivalents in Cypress, Selenium, and WebdriverIO
• Demo: taking an existing test and making it environment-agnostic
Break — 15:30–15:55

Module 6 — Adding Tests to CI/CD (15:55–16:40, 45 min)
• Wiring test execution into the pipeline immediately after deploy
• Gating on a fast smoke suite before committing to the full run
• Parallel execution and sharding, to keep pull request feedback inside a useful window
• Reporting results back into the pull request — status checks, annotations, and links to failures
• Quality gates: blocking merge on failure, required checks, branch protection rules
• Handling flaky tests without disabling the gate: quarantine, retry policy, and the discipline to actually fix them
• Artifacts that make failures diagnosable — traces, videos, logs, and where to store them
• The cultural piece: getting a team to treat the gate as a feature rather than a bottleneck, and what to do when someone asks to bypass it

Module 7 — AI-Driven Development (16:40–17:15, 35 min)
• The new risk profile: AI-generated code that passes review but fails at runtime, arriving at a volume no team can manually verify
• Why an ephemeral environment is the natural verification point for AI-authored changes
• Did the AI build what I asked for? Reviewing the running feature on its own environment before merge
• Did it introduce regressions? Finding out before the code reaches anyone else
• Closing the loop: feeding test results from the ephemeral environment back to the AI so it fixes its own bugs
• Agent-driven workflows: deploy → test → report → fix → re-test, and where a human still belongs in that loop
• Adapting quality gates to the failure patterns AI-generated code actually produces
• Attendee action plan — each person names the first change they will make when they get back, followed by open Q&A

3. Objectives
By the end of this workshop, attendees will be able to:
• Explain what an ephemeral environment is, how it differs from a shared staging environment, and articulate the business case to their own team
• Choose a branching strategy that keeps test code and feature code in sync and scales past a handful of developers
• Compare the main approaches to provisioning ephemeral environments and select the one that fits their infrastructure, budget, and team size
• Automate the full environment lifecycle — create on pull request, update on push, tear down on merge — including the orphan cleanup that teams usually forget
• Select a test data strategy appropriate to their context, and manage schema, seeding, and fixtures as versioned code rather than manual setup
• Write end-to-end tests that run unmodified against dynamic, branch-specific environments and remain reliable in parallel
• Wire test execution into the pipeline and establish quality gates that block broken code without becoming a bottleneck the team routes around
• Use ephemeral environments to verify AI-generated code before it merges, and feed test results back to the AI to close the fix loop
• Adapt all of the above to their existing tooling rather than rebuilding their pipeline from scratch

4. Target audience and Prerequisites
Who this is for
• QA engineers, SDETs, and test automation engineers who own an end-to-end suite
• DevOps, platform, and release engineers responsible for CI/CD pipelines and environments
• Developers practising — or trying to practise — trunk-based development
• QA leads and engineering managers evaluating whether this approach is worth the investment
Especially valuable for teams that
• Run end-to-end tests only at release time
• Maintain a contended shared staging environment
• Live with regular code freezes
• Are adopting AI coding tools and want a verification safety net
Prerequisites
• Working familiarity with Git — branches, pull requests, merges
• General understanding of CI/CD concepts (what a pipeline is, what a build and a deploy step do)
• Some exposure to an end-to-end test framework such as Playwright, Cypress, Selenium, or WebdriverIO
No prior experience with Octopus Deploy, Testery, GitHub Actions, Kubernetes, Django, React, or infrastructure-as-code is required. This is a concepts-first session: attendees do not need to use the demonstrated tools at their own company to get value from it.

5. Technical requirements from attendees
The workshop can be followed without a laptop — all demonstrations are performed by the trainer. Attendees who wish to follow along should install the following before arriving, as downloading it on conference wi-fi may not be practical:
• Git and a GitHub account
• Docker Desktop (or Docker Engine with the Compose v2 plugin) — the reference application runs entirely in containers
• Python 3.12 and Node.js 20 or later, for running the test suites on the host
• A code editor or IDE of their choice
• Approximately 5 GB of free disk space, and TCP ports 5173, 8000, and 5432 available

Detailed setup instructions and the sample repository will be circulated to registered attendees approximately two weeks before the conference, including a one-command Docker Compose start-up and a pre-pull step so that nobody spends the first module downloading images.
Reference application
Examples are built on a purpose-built sample application — Django and Django REST Framework on Python 3.12, React 18 with Vite and TypeScript, PostgreSQL 16, tested with pytest and with Playwright plus playwright-bdd. Its pipeline uses GitHub Actions, Octopus Deploy, and Testery to create an environment per pull request and delete it on close. Cloud infrastructure and credentials for the deployment portion are provided by the trainer and demonstrated live; attendees are not required to hold Octopus Deploy, Testery, or cloud provider accounts of their own.

1. Abstract
Hack AI Agents is a six-hour, hands-on workshop that turns QA engineers into AI-native testers. AI products fail in ways traditional test suites never catch - they hallucinate, leak bias, obey malicious prompts, and slip past safety guardrails. In this workshop you will learn how modern AI systems break, then test live LLMs for reliability, safety, and fairness using industry tooling like Promptfoo.
The format is a career accelerator built as a competitive hackathon. After a guided crash course in AI failure modes, teams move through timed challenge rounds - hunting hallucinations, exposing bias, running prompt-injection attacks, and probing safety guardrails - then document their findings and present them to the judges. You leave with reusable AI evaluation templates, documented findings, and the confidence to own AI quality end-to-end in AI-native products.

2. Agenda
9:00 – 9:20 Welcome & Challenge Brief
Event overview, goals and expected outcomes, judging criteria and scoring explained.
9:20 – 10:00 AI Testing Crash Course
The 7 categories of AI testing, why AI systems fail in production, and what makes a strong AI test case.
10:00 – 10:30 Promptfoo Walkthrough
Platform introduction, provided workflow overview, and what a successful evaluation run looks like.
10:30 – 10:55 Team Formation & Setup
Team creation, access check, first successful test run.
10:55 – 11:20 Break
11:20 – 12:10 Challenge Round 1: Hallucinations
Fact-checking outputs and identifying unsupported claims.
12:10 – 13:00 Challenge Round 2: Bias & Fairness
Testing for unequal behavior and comparing outputs across varied prompts.
13:00 – 14:00 Lunch Break
14:00 – 14:50 Challenge Round 3: Security
Prompt injection and instruction-override testing.
14:50 – 15:30 Challenge Round 4: Safety Guardrails
Probing refusal behavior, unsafe-content handling, and guardrail bypasses.
15:30 – 15:55 Break
15:55 – 16:35 Submission Preparation
Finalize findings, select top failures, write suggested fixes, prepare the final demo.
16:35 – 17:00 Presentations, Judging & Winners
Team demos, judge evaluation and feedback, awards and closing.

3. Objectives
By the end of the workshop, participants will be able to:
●    Recognize the seven categories of AI testing and explain why AI systems fail in production.
●    Design and run structured LLM evaluations with Promptfoo.
●    Detect hallucinations and identify unsupported or fabricated claims in model output.
●    Test for bias and fairness by comparing behavior across varied prompts and demographics.
●    Execute prompt-injection and instruction-override attacks to probe model security.
●    Assess safety guardrails and document guardrail bypasses.
●    Write clear, actionable findings with suggested fixes and present them to stakeholders.
Participants leave with reusable AI evaluation templates, documented findings, setup resources, and the identity shift into AI-native QA work.

4. Target Audience and Prerequisites
Who it's for: QA Engineers, SDETs, QA Leads, QA Managers, and technical testers who already understand quality and want to become fluent in AI reliability and evaluation. It suits people who want practical AI QA skills rather than generic AI inspiration, and who are ready to work in teams, compete, and present under pressure.
Not a fit for: those seeking a passive conference experience, pure beginners with no testing or technical background, or anyone who wants theory without implementation.
Prerequisites: No prior AI testing experience is required — the workshop opens with a guided introduction to AI failure modes and evaluation workflows before the challenge rounds begin. A basic testing or technical background is expected. Exposure to any programming language is helpful but not mandatory.

5. Technical Requirements
Tooling (walked through live):Must have Claude Code installed with minimum subscription.
Minimum system requirements:
●    macOS: macOS 13.5 (Ventura) or later (Apple Silicon), 8 GB RAM minimum (16 GB+ recommended), ~500 MB free disk space.
●    Windows: Windows 10 or 11 (64-bit), 8 GB RAM minimum (16 GB+ recommended), ~500 MB free disk space.
●    Stable internet connection for live LLM access.

1. Abstract
This workshop helps participants determine which tool fits their team best. Participants are introduced to the tools under consideration and to a reusable decision matrix that can support future tool-selection decisions.
Working with colleagues where possible, participants define their own organizational context, needs, and use cases. They identify must-haves and nice-to-haves, establish priorities, and consider alternative solutions when an important requirement is not covered by the available tools.
Participants assess the skills required to use each tool and compare them with the skills their team currently has. They then work through the proof-of-concept (POC) process, including the composition of the POC team, the timeline, success criteria, individual scorecards, and the comparison matrix.
The workshop also covers the purpose of a user guide, the roles of the tool champion and pilot team, and the importance of a well-planned rollout. It concludes with each team selecting the tool that fits its needs best and sharing its final decision.

2. Agenda

• Set-up and introduction
• Attendees who are participating with co-workers can work together and use their own organizational context
• Assign tester numbers to tables
• Introduce the decision matrix
• Explain how the matrix can be reused for future decisions
• Introduce the tools being considered
• Explain the general considerations and organizational use cases that must be evaluated
• Consider alternative solutions when an important requirement is not covered
• Explain how the page works
• General Considerations Activity
• Explain the importance of use cases
• Participants define their own needs as the customer
• Explain why priorities matter
• Separate must-haves from nice-to-haves
• Discuss how individual needs affect priorities and how priorities help identify what matters most
• Use Cases Activity
• Identify the skills required to use each tool
• Consider all relevant skills and the risk of overlooking critical capabilities
• Skill Inventory Activity — Part 1
• Identify the skills the team currently has
• Skill Inventory Activity — Part 2
• Explain what a POC team is and why it matters
• Discuss the appropriate composition of a POC team
• Explain the POC process
• Step through the process
• Define the POC timeline
• Explain why the POC should not be repeatedly stopped and restarted
• POC Timeline Activity
• Explain why success criteria are important
• Show how success criteria are used to evaluate the tools
• Explain how they keep everyone aligned
• Success Criteria Activity
• Explain the value of the scorecard and how it is used
• POC team members document their individual scores for each use case
• Combine the individual results on the scorecard
• Use additional scorecard copies where required
• Scorecard Activity
• Explain the purpose and value of the comparison matrix
• Explain how the comparison matrix is used
• Use the matrix to collate scorecard data
• Comparison Matrix Activity
• Explain what a user guide is and why it matters
• Identify who should act as the champion
• Identify who should be part of the pilot team
• Explain why a well-planned and structured rollout matters
• Determine which tool fits each team best
• Final Decision Activity
• Each team shares which tool it selected

3. Objectives

• A reusable matrix for making future tool-selection decisions
• A clearer understanding of the organizational considerations that affect tool selection
• Defined and prioritized use cases based on their own needs
• A distinction between must-have and nice-to-have requirements
• An inventory of the skills required by each tool
• An inventory of the skills currently available within their team
• A clearer understanding of the purpose and composition of a POC team
• A structured POC process and timeline
• Defined success criteria for evaluating candidate tools
• Experience using individual scorecards
• A comparison matrix that collates scorecard results
• An understanding of the purpose of a user guide
• A clearer view of the roles of the tool champion and pilot team
• An understanding of why a structured rollout plan matters
• A final decision about which tool fits their team best

  4. Target Audience and Prerequisites

Individuals and co-workers involved in defining organizational needs, evaluating tools, participating in a POC, or selecting the tool that best fits their team.
Participants attending with colleagues can work together so that the activities reflect their own organizational context.

1.Abstract
These are the voyages of the starship Tester. Its continuing mission is to explore strange new systems, to seek out new bugs and changes, and to boldly go where no one has gone before! Participants do not embark on this journey alone. Rick Tracy isn’t just talking about their crewmates - though their role is vital. He’s talking about the vehicle used to explore the infinite expanse of possibilities. For each person, this ""ship"" is slightly different and may lead them to different destinations. Therefore, it’s crucial to understand how it's built, how it functions, and how to construct a new one when needed. This workshop examines both the fundamentals and innovations that enable effective testing. It takes a deep dive into the elements that allow testers to perform their work well. Environmental configurations, directed datasets, catch-alls, charters, checkpoints, and criteria mapping form the hull, while tools, scripts, and best practices fill out the systems. The group then explores how to enhance existing testing structures through well-established strategies or new technologies, such as AI-assisted testing. Finally, participants work together to build their fleet of ships and test them on a mission to determine whether they’ve designed the right S.S. Tester for their needs. If you're looking to enhance your testing in a fun and tangible way, this workshop is for you. If you're looking for a few hours of entertainment while accidentally learning something, this workshop is for you. And if you're seeking to meaningfully improve your testing through fundamentals, proven tactics, and innovation, this workshop is for you.

2. Agenda
9:00 Introduction and warmup
10:00 Starship Academy (learning the specialization)
11:00: Basics of Test Environment Starships
12:00 Shakedown Flight
12:30 Lunch Break
13:30 Debriefing
14:00 Improving the Starship
15:00 Designing the Armada
16:00 Full Starship Creation
16:45 Debrief and Closing
The day begins with an introduction to different roles each participant can fulfill in this simulation. There is a choice of 6 roles based on the particular skills and interests of each individual, and academies are created based on this. In the Academy you will dive into your specific skillset and mindset and design how it will best serve you on this mission, and how you add value as a part of the crew. We will also explore backgrounds and get to know one another a bit better and where we are coming from when it comes to our testing and struggles with environments or organization. After the Academy final exam we will pause, and when participants rejoin we will have ships ready to be filled with crew. These ships require one of each 6 specializations; this will be where the different specializations and interests will join together as one. We form up, get to know the skills and goals of each role, and then design our first ship (environment) with a few basic prompts. This leads into the shakedown, where all ships will partake in a simulation meant to reflect issues found in test environments, and use specific situations I and others have encountered in trying to test with less than ideal test environments. Each role has a specific task, reflective of the tasks we do as professional testers, to help their ship get through the test flight. This helps the crews of every ship learn what skillsets, tools or strategies they may have been missing, and with a debrief, they get a chance to put their learnings together and muse a bit. Once we return from a break we dive deeper into specific techniques and tools that enhance our ability to test, mostly by looking at how the environment is either helping or hindering our efforts. We'll discuss important concepts like test representation, drift, scope creep, and fit for purpose, among others. Teams will stick with their crew and use this knowledge to design improvements on their ships. Once completed, we give one crew member per team the chance to explain to their shipmates how their current test environments are set up, and using the techniques learned, work together to design a "fleet" of test environments responsive to their needs. This becomes the final exercise of the day, with everyone pitching in to build up ships (test environments) and practice the skills they will need when implementing this back in their organizations.

3. Objectives
To learn about setting up testing in organizations through an exciting metaphor
To get practical steps to improving testing in your organization
To customize your “ship” to have an effective vehicle for testing
Test Environments are the forgotten child of testing, and I want to change that. Presentations and workshops on this topic are often very dry and don't draw large audiences; my experience so far is that this skin helps to bring the concepts across in a much more applicable and fun way. Participants can use the skills learned here to create or enhance their test environments to work for them, and overcome a host of issues otherwise commonly found in most organizations where there is little attention for the subject. They not only learn the skills in an engaging way, but they get step by step instructions on how to do this at their own companies afterwards, with a full example for one of their crew per ship they can later emulate. I use this structure myself when examining and enhancing test environments, in both test management roles and also migration and more technical setup tasks.

4. Target audience and Prerequisites
The target audience is anyone who works with or is impacted by a test environment. This is a pen and paper workshop; no enhanced laptops or other toolsets needed. It is important that we have room enough in the space; 6 table clusters for the academies at first, and then the space to create tables of six people per ship.

1. Abstract
Shi(f)t Happens - Skills That Matter Even More in the AI Era
This workshop isn’t about AI. It’s about the human skills that become more valuable as AI takes over the routine parts of software development.
As AI automates more of the coding, generating, and scaffolding work, what stays firmly in human hands are the things machines still struggle with:

• Figuring out the real problem behind the request
• Spotting risks, gaps, and inconsistencies early
• Sharing understanding across roles — Dev, QA, Product, UX
• Making good decisions when things are messy or unclear
• Challenging assumptions before they cost time and quality
• Connecting technical solutions with real user and business needs
• This workshop lets you practise these skills through hands‑on, energetic activities.
• It’s not theory — you learn by doing, by misunderstanding, by discovering, and by seeing how people think differently.
  Why this matters now
  The AI shift is real. AI can already write code, draft tests, generate docs, and automate repetitive tasks.
  But it cannot yet:
• Understand team dynamics or social nuance
• Prioritise in the middle of business ambiguity
• Make value‑based tradeoffs
• Sense misalignment before it becomes a defect
• Replace the critical eye of a skilled QA or tester
• These human strengths are becoming the core of modern software work.

2. Agenda

• Intro
• Workshop Part 1
• Lunch
• Workshop Part 2
• Break​
• Workshop Part 3a
• Break
• Workshop Part 3b
• Wrap up

3. Objectives
What participants walk away with

• Better awareness of how they think and communicate under pressure
• Tools for creating shared understanding in mixed teams
• New insight into cognitive biases and common traps
• Confidence to ask better questions and frame problems clearly
• A shift from “doing tasks” toward “understanding purpose”

4. Target audience and Prerequisites
Who this is for
Developers, QAs, testers, product people, designers, architects — anyone who works with other humans to build software.
Technical requirements
Analog Tech: Post-it notes, pens, and paper for active brainstorming and sketching.

As the EU AI Act becomes broadly applicable in 2026, trust in AI stops being optional - it becomes a legal requirement. High-risk systems in healthcare, finance, human resources (HR), automotive, and the public sector will need more than just working code. They will need proof: evidence of safety, transparency, and fairness. And that evidence will come from testers.
This will change the game for QA leaders and testers. Testing is not only about functionality or performance anymore - it is about being audit-ready, compliant, and trustworthy.
In this hands-on tutorial, Usha Kandala will strip away the jargon of the EU AI Act and show attendees how to turn its requirements into practical testing strategies. Participants will dive into real case studies - classifying systems by risk, designing test approaches for bias and robustness, and preparing the kind of documentation regulators expect. The session will also explore tools like Fairlearn, SHAP, and audit checklists that make compliance testable and repeatable.
Attendees will leave with their own AI Compliance Test Readiness Kit, including a risk classification worksheet, a bias-testing demo, a sample conformity checklist, and clear strategies for building test evidence that regulators will actually accept.
Whether attendees are already testing AI systems or just getting ready for what is coming, this session ensures that “testing at its best” means testing that not only finds bugs, but also builds trust.

1. Abstract
Performance testing is no longer a niche activity reserved for specialists. As modern applications become increasingly distributed, QA engineers and developers need practical skills to validate system performance, identify bottlenecks, and detect performance regressions before they reach production.
This full-day, hands-on workshop introduces modern performance testing using a fully open-source stack built around k6 OSS and Grafana OSS. Participants will learn how to design, execute, and analyze load tests while gaining practical experience with performance metrics, dashboards, and investigations.
Starting with a simple demo application, attendees will progressively build load tests with k6, explore different workload models, define performance assertions and pass/fail criteria, generate tests with k6 Studio, and extend testing beyond HTTP services to infrastructure components such as databases.
The workshop also demonstrates how observability improves performance testing. Participants will collect test results with Prometheus, visualize performance data in Grafana, and correlate load-test results with application and infrastructure metrics to better understand system behavior under load and quickly identify the root causes of performance issues.
Finally, attendees will explore how AI assistants can accelerate performance testing by helping generate test scenarios, create dashboards, interpret results, and investigate regressions, reducing manual effort throughout the testing process.
By the end of the workshop, participants will understand the fundamentals of performance testing, know how to design and execute realistic load tests with k6, analyze results using an open-source observability stack, and apply AI-assisted techniques to make performance testing faster and more effective.

2.Agenda
●     Performance testing fundamentals
●     Workshop setup: installing the demo application and k6
●     Create your first load test with k6
●     Visualize and interpret performance results
●     Model workloads using request-based rate
●     Define assertions and pass/fail criteria
●     Generate tests with k6 Studio and handle dynamic data
●     Parameterize test data
●     Test infrastructure components such as databases
●     Explore the k6 ecosystem and extensibility
●     Run cloud and hybrid performance tests
●     Use AI assistants to accelerate test creation, analysis, and investigations

3. Objective
By the end of this workshop, participants will:
●     Gain a solid understanding of the fundamentals of modern performance testing.
●     Learn a practical workflow for designing, executing, and evaluating load tests.
●     Understand how observability complements performance testing to diagnose bottlenecks and regressions.
●     Become familiar with an end-to-end, fully open-source performance testing stack built around k6, Prometheus, and Grafana.
●     Leave with the confidence to apply these techniques and tools to their own applications and testing workflows.

4. Target audience and prerequizites
Software developers, QA engineers, DevOps engineers, and anyone interested in performance testing, observability, or the Grafana ecosystem. No prior experience with k6 or load testing is required, although basic programming knowledge is recommended.

The importance of creating accessible web applications is undebatable. Whether viewed from a moral or business perspective, accessibility is essential.
Unfortunately, implementing and testing accessibility can be complex.
In this hands-on workshop, Asaf Shochet Avida equips participants with the tools and techniques needed to test and build accessible web applications. He explores the principles of inclusive design and demonstrates how to test websites using assistive technologies to ensure they work for everyone.
The session covers topics such as semantic markup, ARIA roles, accessible forms, and navigation. Participants then move into coding exercises to apply what they have learned.
The workshop incorporates automated testing tools to validate implementations, AI-powered tools to create and verify accessible components, and practical methods to ensure compliance with accessibility standards.
By the end of the workshop, attendees gain the knowledge and hands-on experience needed to create accessible websites that serve all users, using modern techniques and tools for inclusive design and testing.
Participants are invited to join this coding-focused workshop to strengthen their expertise in web accessibility and inclusive design.