Knowledge Hub

Creating value – for customers and for people.

sabina.engdahl@systemverification.com (Sabina Engdahl) — Tue, 19 May 2026 07:22:08 GMT

Can you tell us a bit about yourself, your background and what has shaped your career so far?

Professionally, I have spent the past twelve years in the staffing, consulting, and recruitment industry, working across a range of sales and leadership roles. Building my career in fast-paced companies and highly competitive markets has taught me the importance of delivering strong customer value and quality in every customer engagement.

QA in the Age of AI — Trust Is the New Benchmark

johan.pearson@systemverification.com (Johan Pearson) — Thu, 30 Apr 2026 08:10:54 GMT

Speed Without Alignment Is Risk

AI is producing code faster than most teams can reason about it. Features ship. Pull requests merge. Systems grow. And somewhere in that velocity, a question gets harder to answer:

From Bug Hunter to Strategist: My Journey from Manual Tester to Test Manager

Fathallah Embarek — Tue, 31 Mar 2026 13:06:22 GMT

The Foundation: Why Manual Testers Make the Best Managers

Manual testing is sometimes dismissed as an "entry-level job." That is a fatal misconception. Those who have spent years putting applications through their paces develop skills you won’t learn in any management seminar:

• User Empathy: Manual testers know exactly where software "hurts."
• Risk Instinct: They can literally smell which components are hiding the bugs.
• Perseverance: Anyone who has executed 100 manual test cases knows the true meaning of discipline.

The Turning Point: A Shift in Perspective

The transition to management happens in the mind. You stop asking, "How do I find this bug?" and start asking, "How do I optimize the process to catch bugs as early as possible?"

Here are the three pillars that shaped my growth:

1. From Bug Hunting to Risk Assessment: As a manager, you realize you never have time for 100% coverage. I had to learn to make risk-based decisions. We invest our resources where the impact is highest.

2. Mastering the Tools: I didn’t need to become a full-stack dev, but I had to learn the language of automation. Deciding whether a regression belongs in a Groovy script (QF-Test) or requires manual exploration is key to a high ROI.

3. Stakeholder Management: You become the bridge between Devs, Product Owners, and Leadership. You provide the data for the ultimate question: "Is our release at risk?"

Vom Bug-Jäger zum Strategen: Meine Reise vom manuellen Tester zum Testmanager

Fathallah Embarek — Tue, 31 Mar 2026 13:05:08 GMT

Die Basis: Warum manuelle Tester die besten Manager werden

Manchmal wird manuelles Testen als „Einstiegsjob“ belächelt. Ein fataler Irrtum. Wer jahrelang Anwendungen auf Herz und Nieren geprüft hat, entwickelt Fähigkeiten, die man in keinem Management-Seminar lernt:

• Empathie für den User: Manuelle Tester wissen, wo eine Software schmerzt.
• Risiko-Instinkt: Sie riechen förmlich, in welchen Komponenten sich die Bugs verstecken.
• Durchhaltevermögen: Wer 100 Testfälle manuell durchgespielt hat, weiß, was Disziplin für einen bedeutet.

Der Wendepunkt: Die Veränderung der Perspektive

Der Übergang zum Testmanagement findet im Kopf statt. Man hört auf, sich zu fragen: „Wie finde ich diesen Bug?“ und fängt an sich zu fragen: „Wie optimiere ich den Prozess, um Fehler frühzeitig finden zu können?“

Hier sind die drei Säulen, die meinen Aufstieg geprägt haben:

1. Von der Fehlerjagd zur Risikobewertung

Als Tester wollte ich jeden Stein umdrehen. Als Manager weiß man: Wir haben nie Zeit für 100% Testabdeckung. Ich musste lernen, risikobasiert zu entscheiden. Wo können gravierende Fehler sich befinden? Dort investieren wir unsere Ressourcen, egal ob manuell oder automatisiert.

2. Werkzeuge und Automatisierung verstehen

Ich musste kein Full-Stack-Entwickler werden, aber ich musste die Sprache der Automatisierung lernen. Ein Testmanager muss entscheiden können: „Diese 200 Regressionstests wandern in ein Groovy-Skript in QF-Test, aber das neue Feature testen wir diese Woche intensiv manuell.“ Die Balance ist der Schlüssel zum Return of Investment (ROI).

3. Stakeholder-Management

Plötzlich redet man nicht mehr nur mit Entwicklern, sondern auch mit Product Ownern und andere Verantwortlichen. Ein Testmanager liefert die Datenbasis für die alles entscheidende Frage: „Ist unser Release gefährdet?“

From Certification to Practice: AI Testing for Accessibility

Prasanth Sivakumar and Tobias Kirsch — Wed, 25 Mar 2026 11:42:22 GMT

Introduction

When Prasanth, a senior consultant at System Verification, completed the ISTQB AI Testing (CT‑AI) certification last year, he made an observation that stayed with us for a while. Many of the ideas in the syllabus did not feel completely new. Instead, they finally provided clear names for problems we had already been encountering in everyday testing work.

A few months later, Tobias, a principal consultant at System Verification, completed the ISTQB Testing with Generative AI (CT‑GenAI) certification, and naturally we compared impressions. Rather than discussing the theory in isolation, the conversation quickly moved toward a practical question: where do these concepts actually appear in real projects?

CT‑AI covers the specific challenges of testing AI‑based systems: how to deal with machine learning, non‑deterministic behaviour, limited test oracles, and risk‑based strategies for systems that learn or adapt. CT‑GenAI focuses on working with generative AI tools in testing workflows—understanding their outputs, managing hallucination risks, and validating results that cannot be checked against a fixed expected value.

Accessibility testing turned out to be a surprisingly good example. In projects with CI pipelines and automated accessibility scans, it becomes visible very quickly where automation works well and where human judgement is still required. Some aspects of accessibility can be validated deterministically and automated quite reliably. Other aspects depend heavily on context and real user experience. This combination makes accessibility testing a useful example for many of the challenges described in the two courses.

The Oracle Problem in Accessibility Testing

One concept from AI testing that becomes visible very quickly in accessibility work is the Oracle Problem. This refers to situations where determining the correct result of a system is difficult or impossible to define precisely.

Automated accessibility tools such as axe‑core, Pa11y, or Lighthouse are very good at detecting violations where the expected result is clearly defined. Typical examples include missing form labels, invalid ARIA roles, or insufficient colour contrast.

In those situations, the result is binary: the violation either exists or it does not.

However, accessibility testing also includes situations where interpretation is required. Alt text is a simple example. An automated tool can check whether an image contains an alt attribute, but it cannot reliably evaluate whether the description is actually meaningful for screen reader users.

Both of the following alt text values would pass automated checks:

“image”
“Submit registration form button”

Both technically pass, but only one of them is actually useful.

One possible strategy in these situations is to compare outputs from different AI‑based description or captioning models against the same set of images. Where both agree, the result is likely reliable. Where they disagree, that disagreement highlights cases worth human review. The differences do not tell you which answer is right, but they reliably surface the cases where interpretation is genuinely ambiguous.

Combining Different Testing Approaches

The Oracle Problem makes clear that no single approach will cover everything. That is not a theoretical observation—it shapes how the work needs to be structured.

Automated accessibility checks provide very fast feedback during development. In some projects, these checks already run on every pull request and scan hundreds of components at different stages: component level, integration, and before release. Catching issues early keeps them cheap to fix.

In practice, the most effective accessibility work reaches further back than test execution. Building accessibility criteria into requirements and design reviews catches structural problems before they become expensive. During development, accessibility linters give developers immediate feedback in the IDE, long before anything reaches a pipeline.

With agentic AI coding tools, there is another opportunity: accessibility expertise can be made explicit in the agent’s context rather than relying on developer memory. This can take the form of a dedicated accessibility reviewer persona or integrating accessibility expectations into a senior frontend developer role definition. Code analytics tools can then provide visibility into whether those rules are actually being applied in the parts of the codebase that matter most.

AI‑supported analysis adds another layer: pattern detection across large defect sets, suggested fixes, and classification by severity. Useful—but with a catch. Large language models can produce answers that sound plausible and still be wrong. We have seen generated fix suggestions that were technically coherent but addressed the wrong ARIA pattern for the context. They would have passed a non‑specialist review.

That is why AI‑generated suggestions always go through a specialist before being acted on. Not as bureaucracy, but as quality control.

Manual accessibility testing remains essential. Exploratory and experience‑based testing helps evaluate real user scenarios and usability aspects that automation cannot reliably assess.

In one project, automated scans reliably detected missing labels, but issues with dynamic status messages only became visible during manual screen reader testing. When a user submits a form and a confirmation message appears dynamically, accessibility guidelines require that message to be announced to screen reader users via a live region. An automated tool can check whether a live region exists in the DOM, but it cannot simulate the interaction, verify timing, or judge whether the wording makes sense in context. That required a tester using an actual screen reader and working through the real user journey.

Automation narrows the scope. It does not replace judgment.

Limits of Automated Accessibility Checks

Even within automated checks, not all checks are equally reliable. Automated accessibility testing is extremely helpful, but its limitations are real and worth understanding in detail.

Colour contrast checks are a good illustration. In one project, a hero banner had white text over a photograph. The automated tool calculated the contrast ratio against an average background colour and passed it. A manual check showed that in parts of the image, the text was nearly unreadable.

This becomes even harder with gradients, background images, or semi‑transparent layers. The calculated value stops being a reliable proxy for what users actually perceive, and manual verification ends up doing the work the tool cannot.

The issue here is not randomness. The tool produces the same result every time. The difficulty is that correctness depends on human perception and context, which the tool cannot model.

Human in the Loop and Automation Bias

Another issue that appears in practice is automation bias: the tendency to trust automated results more than they deserve, especially after long stretches of green builds.

We noticed this ourselves. After weeks of clean accessibility scans, the team gradually stopped questioning what the scans were actually covering. Nobody was being careless—it simply became background noise.

The mitigation is simple but effective: periodic manual spot checks of a random sample of passed results. It keeps the team honest about what the tooling really covers and what it does not.

Non‑Determinism in Generative AI

When generative AI tools are used in testing workflows, their probabilistic nature introduces a different kind of uncertainty. The same prompt can produce slightly different outputs when run twice—not necessarily wrong, just different.

This means you cannot validate generative AI output the same way you validate a deterministic check. What works instead is evaluating outputs against characteristics: is the output relevant, technically accurate, and aligned with the actual problem?

One practical technique is using a second language model to review the output of the first against those criteria. This does not remove uncertainty, but it catches a reasonable share of obvious issues before a human reviewer steps in.

Conclusion

The certifications gave us better language for things we were already navigating. That matters, especially when explaining to stakeholders why a green build does not automatically mean the product is accessible.

What the courses do not fully prepare you for is the messiness of applying these ideas under real project constraints. In practice, teams make pragmatic trade‑offs. That is fine—but it is important to be honest about them.

Accessibility testing turned out to be a particularly good lens for this. The mix of deterministic checks and human judgment, the real impact on users, and the clear limits of tooling surface the fundamental questions quickly. For anyone working through these certifications and looking for a concrete place to apply them, accessibility testing is well worth the time.

Key Takeaways

The Oracle Problem shows up constantly in accessibility testing, especially where tools can detect presence but not meaning.
Effective accessibility validation requires a combination of automated checks, AI‑supported analysis, and manual testing.
Generative AI outputs can be plausible without being correct. Human review is essential to make AI‑assisted testing trustworthy.
Exploratory and experience‑based testing is where many real accessibility issues are discovered—and where human testers still add irreplaceable value.

WEBINAR: When AI Meets Autonomous Systems – Designing for Reliable Robotics from Day One

sabina.engdahl@systemverification.com (Sabina Engdahl) — Fri, 20 Mar 2026 10:30:39 GMT

This is the central argument Faseeh Ahmad, robotics engineer and AI researcher at System Verification, made at last week’s webinar. With a PhD in robotics and AI from Lund University and hands-on experience with industrial robot arms, autonomous systems, and the Boston Dynamics Spot robot, Ahmad brought a rare combination of academic depth and real-world engineering perspective to a question that's becoming impossible to ignore: how do we ensure reliability when AI controls physical machines? 

From Dance Floor to Digital: Lessons in Accessibility & AI

tobias.kirsch@systemverification.com (Tobias Kirsch) — Tue, 17 Mar 2026 12:44:59 GMT

Image: Tobias Kirsch

Accessibility is not something we build for people. It is something we build with people.

In this year, I have been running inclusive dance courses for people with cognitive and learning disabilities and for people who are blind or visually impaired. What started as a local initiative has influenced my work in digital accessibility, test automation, and AI-assisted quality engineering more than I expected.

Earlier in my life, I spent many years teaching sports and dance classes, building communities, and completing formal coaching certifications. After a longer pause, I’m reconnecting with that foundation, this time with a new lens shaped by accessibility work, engineering, and AI.

The deliberate bridge between analog accessibility and digital engineering has fundamentally changed how I approach accessibility testing, automation design, and collaboration. The lessons learned outside of software have directly improved how I design test strategies and understand accessibility in real systems.

Sustainable Nearshore Delivery: insights from Sarajevo

Bobby.kociski@systemverification.com (Bobby Kociski) — Fri, 06 Mar 2026 10:35:56 GMT

System Verification has supported customers for many years. One of the most appreciated service is our Nearshore service from Sarajevo, a model shaped by the growing demand for high quality combined with cultural and operational alignment, based on long term relations and build on trust.

Nancy’s Journey into IT: From Finance to Software Testing

Nancy Pinto — Wed, 04 Mar 2026 15:23:20 GMT

From Banking to IT – The Courage to Start Over

What many people don’t expect: I am a career changer.

Quality Assurance as an Enabler: Trusting AI and Robotics in the Real World

faseeh.ahmad@systemverification.com (Faseeh Ahmad) — Wed, 11 Feb 2026 08:53:57 GMT

Image source: Steve Jurvetson, Wikimedia Commons

Quality Assurance Beyond Testing

Quality assurance is often associated with testing at the end of development. In practice, it is much broader. QA is about building confidence in a system throughout its entire lifecycle, from early design decisions to deployment and long-term operation.