AI isn’t some futuristic magic box anymore. It’s here, and it’s making real decisions. About loans. About diagnoses. About driving. When it messes up, the price isn’t just a bug report. It’s lost trust, money, or worse.

Which means: if it breaks, it matters. Testing can’t be an afterthought. How do we test systems that learn, adapt, and — sometimes — confidently hallucinate?

Not with old-school checklists. We need new habits. Here’s a 10-habit field guide to help your AI behave in the real world — not just in the lab.

Ten Habits for Taming Smart Systems

Here’s a quick cheat sheet of what to do, why it helps, and how to get started.

Why Testing AI Is Different

Testing normal code is like checking a recipe. Testing AI is like checking a chef who learned the recipe from watching Instagram. You already know how that goes. Sure, it may get great reviews at first, but throw in a new ingredient, and suddenly it forgets how to boil water. Pure meme material.

AI’s unpredictable. It can get things right in training but mess up when new data comes in. That’s why you need to test:

• The data itself: Is it balanced? Biased? Ridiculous?
• How stable the system is: Does it still work next month?
• The logic: Can you explain why it did that?

Testing at Each Project Stage

Think of it like a road trip. Here’s where to check the engine:

1. Define the Destination and Potholes. Write down what success looks like. Also: what can go wrong?

2. Check Your Fuel (Data). Is it clean? Representative? Or just five sunny-day driving clips?

3. Clean Before You Drive. Sanitize the inputs. Version the data. Lock in reproducibility.

4. Drive Like a Maniac (on purpose). Feed in garbage. Watch it fail — better now than in production.

5. Think Like a Hacker. Can someone fool it? Leak data? Break logic? Find out.

6. Make It Explainable. If it says “no,” you should be able to say why.

7. Set Roles. Who’s driving, who’s patching the tire, and who’s taking the call when it all goes flat?

8. Release Gradually. Start small. Monitor. Be ready to hit the brakes.

9. Re-Test When the Road Changes. If the road changes, so should your tests. New users or data? Re-test like it’s day one.

10. Learn From Each Trip. Hold review retros. What worked? What broke? Iterate.

⚠️ What Might Trip You Up

Even with good habits, beware of:

· 🧱 Opaque logic: The “Why did it do that?” shrug

· 🐢 Slow test cycles: Some models take hours to train

· 📜 Laws changing weekly: Stay alert

· 🎭 Creative attackers: Prompt injection is the new SQLi. One cleverly crafted input — and your model’s hallucinating confessions.

· 🔒 Privacy constraints: Limited real-world test data

Tip: Use synthetic (but realistic) data. Use smaller models when possible. Automate alerting.

Simple Setup for Live Monitoring

Treat your AI like a critical system, not a one-time deploy:

1. Log everything: Inputs, outputs, confidence scores.
2. Check for changes: Compare current behavior to past (did it drift?).
3. Set alerts: Get pinged when things go sideways.
4. Kick off re-tests: Kick off tests automatically when drift is detected.
5. Human-in-the-Loop: There is a reason we call it artificial intelligence. Escalate uncertain cases for human review. It sounds like common sense, but you’ll still have to really fight for it — thanks to the blind faith in AI’s magic.

Quick Q&A

Q: How often should I refresh test data?
A: At least quarterly — or sooner if your model starts behaving oddly.

Q: Is fake data legit?
A: Yes — if crafted carefully. It helps with rare edge cases and avoids privacy headaches.

Q: Can AI explain itself?
A: Sort of. Use explainability tools (like SHAP or LIME) to see what influenced a prediction.

Some Parting Words

If you build smart systems, test them smart too. The job doesn’t end when the model launches — it evolves as users, data, and the world around it changes.

With these habits, you’re not just covering edge cases — you’re building AI that behaves, adapts, and earns trust.

And remember: the goal isn’t to make AI look smart. It’s to make it work — for everyone.

There is more to read from Rahul in trendig‘s blog: https://trendig.com/en/blog/author/rahul-verma/

Picture This

You’ve built a smart assistant. It writes emails, answers questions, summarizes documents, maybe even tells jokes when the boss isn’t looking.

Then a customer asks something off-script. The assistant makes up a confident lie, leaks a name it shouldn’t know, or parrots some nonsense it read on the internet six months ago.

That’s not a feature. That’s a lawsuit waiting to happen.

When your product runs on generative AI, testing isn’t optional — it’s your early warning system. It catches hallucinations, bias, toxicity, and every strange edge case users will throw at you the day after launch.

This playbook isn’t for research labs. It’s for teams shipping real software to real people — with LLMs and GenAI stitched into the core.

1. Habits of a GenAI App That Won’t Backfire

If your product talks, writes, answers, or recommends — testing needs to be part of the build, not the clean-up crew.

Here’s what helps:

● Define success early. What counts as “good enough” output? What’s unacceptable? Get agreement before the first prompt is written.

● Test with actual user inputs. Don’t polish your test prompts. Use the weird, messy stuff people type when they’re tired, rushed, or angry.

● Check how it breaks. Feed it leading questions, contradictory instructions, and bad data. If it hallucinates or leaks info, you want to know before customers do.

● Watch how it changes over time. GenAI systems degrade silently. Monitor for drift, weird tone shifts, or declining response quality.

● Audit for bias. If your assistant treats one kind of user differently, that’s your problem to fix.

● Make outputs explainable. If the answer’s wrong, someone should be able to trace back why — even if it’s not always crystal clear.

● Run tests in short loops. Hook testing into your dev process so every new prompt or feature gets checked on the way in.

● Monitor around the clock. If your assistant starts saying strange things at 2 a.m., someone needs to know.

● Version prompts and outputs. Save everything. You’ll want a trail when something goes sideways.

● Run quarterly chaos drills. Let your engineers — or an external red team — try to make the system misbehave. Fix what they find.

If it feels like overkill, remember: users don’t care that it’s “just the model talking.” They’ll hold your product responsible.

2. From Prototype to Live Product (Without Regret)

Start by mapping out what your GenAI feature will actually do — and what kind of mess it could make if things go wrong.

A helpdesk bot that’s too polite to admit it doesn’t know? Bad.
A chatbot that makes legal guesses and gets them wrong? Worse.
A smart writing tool that leaks private info? Catastrophic.

Talk through the risks before you build. Then move to data.

Use real examples — user questions, documents, chat logs (safely anonymized, of course). Don’t just train and test on cleaned-up demo content. The real world is messier than anything your test team can invent.

While building, save every version of your prompts and outputs. What worked yesterday might break tomorrow after a library update. And don’t forget adversarial testing — users will poke, provoke, and mislead your app whether you like it or not.

When you’re close to launch, push a quiet canary release. Let the assistant handle a limited slice of real requests. Keep logs. Set up alerts. Watch what it does when it’s not supervised.

If your product falls under new “high-risk” categories in the EU AI Act (like employment tools, educational grading, legal summaries, or anything health-related), you’ll need formal testing and documentation before going live. The paperwork isn’t exciting, but skipping it is worse.

3. Real-World Problems Are Closer Than You Think

Even when your GenAI system works in testing, it can drift off course in production — slowly, then all at once.

Prompts that were once reliable start producing weird tangents. Answers grow overconfident. Tone shifts from helpful to smug. These aren’t bugs in the traditional sense — they’re signs the system is reacting to subtle changes in data, user behavior, or even model weights from upstream providers.

Also: regulations are tightening. The EU AI Act is real, and it will affect anyone offering GenAI to the public. ISO 42001 and NIST’s AI Risk Framework aren’t just checklists — they’re fast becoming the standards your partners and regulators expect. Your legal team already knows this.

Let’s not forget privacy. If your assistant is summarizing internal docs or customer tickets, you’re likely handling sensitive data. Logging without safeguards isn’t just risky — it’s illegal in some places.

And then there’s the carbon question. Governments are starting to ask what environmental cost your AI services carry. If your GenAI backend runs multi-billion parameter models 24/7, someone’s going to ask for the footprint.

4. Good Tools and Smarter Systems (Use What’s Out There)

You don’t need to roll your own safety framework. You just need to use what’s already available — and apply it consistently.

Use smaller models or API-efficient modes for most user-facing tasks. If you don’t need the biggest model for the job, don’t use it. It saves money, speeds up feedback loops, and limits risk.

Synthetic data can help fill gaps for edge cases or sensitive scenarios. Just don’t replace real data entirely — your users are always weirder than your generators.

Use modern observability tools — like Weights & Biases, Evidently, LangSmith — to track response quality, drift, prompt performance, and error spikes. Most let you flag bad outputs, collect user feedback, and tie it back to the prompt or feature that caused it.

If you’ve gone through ISO or NIST-aligned audits, say so. It makes a difference when someone asks, “Can we trust this system?”

5. Close the Loop Before It Closes on You

Once your GenAI feature is live, your monitoring loop needs to run 24/7. Here’s what that looks like:

● Log inputs, outputs, and user feedback — safely, with privacy in mind.

● Use drift detectors to track when the model starts producing odd results.

● Alert the right team when something changes significantly — not every minor glitch, but real shifts in tone, quality, or accuracy.

● Route flagged cases — like hallucinations or high-stakes summaries — to human reviewers.

● Automate retraining or prompt updates based on clear, tracked patterns, not gut feelings.

● Keep data hashed and access restricted. One leak is all it takes to lose trust.

When your loop is tight, you don’t just respond to issues — you anticipate them. Your product keeps improving. Your users notice.

6. The Takeaway

Generative AI doesn’t come with guardrails. That’s your job.

If you build products that talk, write, or recommend on behalf of your company, then testing and monitoring are what keep the experience great — and keep the damage contained when something goes wrong.

This isn’t about perfection. It’s about responsibility. If you treat testing like part of the creative process — not just a compliance box — you’ll ship something users love, legal respects, and your team can actually manage.

And that’s what building with GenAI in 2025 should feel like: exciting, but never out of control.

this was first published at trendig.com/ In case you are interested in this topic, there is more to read and learn there.

Due to an increasingly unstable political situation in a rapidly evolving digital world, the European Commission has created the DORA Regulation (Digital Operational Resilience Act), a uniform framework to ensure effective and comprehensive management of cyber security and information and communication technology (ICT) risks for companies in the financial sector.

The EU writes: “In the digital age, information and communication technology (ICT) supports complex systems used for everyday activities. It keeps our economies running in key sectors, including the financial sector, and enhances the functioning of the internal market. Increased digitalisation and interconnectedness also amplify ICT risk, making society as a whole, and the financial system in particular, more vulnerable to cyber threats or ICT disruptions. While the ubiquitous use of ICT systems and high digitalisation and connectivity are today core features of the activities of Union financial entities, their digital resilience has yet to be better addressed and integrated into their broader operational frameworks.

The use of ICT has in the past decades gained a pivotal role in the provision of financial services, to the point where it has now acquired a critical importance in the operation of typical daily functions of all financial entities. Digitalisation now covers, for instance, payments, which have increasingly moved from cash and paper-based methods to the use of digital solutions, as well as securities clearing and settlement, electronic and algorithmic trading, lending and funding operations, peer-to-peer finance, credit rating, claim management and back-office operations. The insurance sector has also been transformed by the use of ICT, from the emergence of insurance intermediaries offering their services online operating with InsurTech, to digital insurance underwriting. Finance has not only become largely digital throughout the whole sector, but digitalisation has also deepened interconnections and dependencies within the financial sector and with third-party infrastructure and service providers.”

After companies have gone through a two-year implementation phase by January 16, 2025 to determine their level of maturity with regard to DORA and proactively protect themselves against possible attacks and failures, they now face the mammoth task of ensuring permanent compliance with DORA even under changing framework conditions and internal structures. In particular, DORA’s strong focus on third-party risk management, i.e. the strict monitoring of all service providers and their robustness, presents financial companies with major challenges: This is because it is easier for ICT third-party providers to escape the company’s focus than their close interaction and dependency with the financial company would suggest.

DORA implemented = well protected against attacks?

With the implementation of DORA, most financial companies believe they are well positioned to protect themselves and their business processes in the event of a cyberattack. However, this assumption is too short-sighted, as it ignores the management of future changes, which must ensure operational resilience in the long term.

Managing change with DORA

At the time of the DORA as-is survey, some very large projects were being set up in the financial companies in order to take a closer look at existing and potential future risks. As a result, measures were derived and described with which these risks can be avoided, mitigated, transferred or spread.

The DORA Regulation specifies in particular detail how companies must protect themselves against service provider failures. This was prompted by a series of cyberattacks in the form of data encryption attacks (ransomware), which led to considerable economic damage, as many service providers are dependent on the same central infrastructure.

These processes are generally well established for new acquisitions. In particular, outsourcing management plays a key role. However, it is worth taking a closer look at the change processes, especially when companies use cloud services such as SaaS (Software as a Service), IaaS (Infrastructure as a Service) or PaaS (Platform as a Service). The key question is then: how do companies recognize changes in these services that could entail risks early enough? After all, these services are not directly within their sphere of control and changes are not automatically noticed and therefore not assessed in terms of the hidden risks.

In this context, DORA demands strict testing of every change before it goes live. Companies must ensure that risk changes are identified and evaluated at an early stage.

If the scope of services used changes over time, new risks may arise. These must be identified before a service continues to be used or is used again. However, complete identification of all relevant changes is often more complex than it seems at first glance.

Examples:

• When a department uses or changes software independently without the IT department being involved.
• If a service provider merges or replaces subcontractors, existing emergency plans no longer work as planned.
• If a change creates new threats to IT security that require an immediate risk reassessment.

It is therefore essential that all organizational units work closely with risk management. Quarterly reporting is no longer up to date — instead, risk management must be directly linked to change management in order to be able to react continuously to new risks. In the following, we explain some everyday scenarios whose implications for risk management only become apparent on closer inspection.

DORA change management: business and control

An HR application from a service provider (third-party service provider Third Party Risk) is initially introduced for purposes that are owed to a normal administrative act and can be classified as justifiably outsourceable in terms of confidentiality, availability and integrity risk — for example, employee time tracking. At this point, the risk analysis is typically carried out for those parts of the application that are intended to be used at that time.

However, the application has a much stronger tool potential and allows a lot in terms of use, so that the processes carried out in daily use are constantly being expanded. For example, employee meetings are now also to be logged. This data is generally classified as strictly confidential because sensitive or critical content could be recorded. From a risk management perspective, a “change request” is required even though no technical changes are made. And this is before the application is put into extended productive use.

This one example clearly illustrates the need for close cooperation between different organizational units with regard to risk management: Compliance has defined processes that make such risks visible, e.g. service management in accordance with ITIL. In this process framework, the specialist department (Fachbereich) reports the desired change in use, according to which data protection can reclassify confidentiality and risk management can request additional measures to protect the data from the service provider. Governance checks the economic efficiency, Legal checks contractual rights, Purchasing adjusts the contracts and changes, if necessary, the monitoring measures for the service provider. Due to the increased risk, additional tests are introduced in the specialist department (Fachbereich) and IT.

You need tried-and-tested processes to manage and control risks efficiently. Secure your place on a training course on sustainable requirements management in the specialist area!

DORA change management: IT and risk management

An external data center that manages the data of a financial company is thoroughly checked during the purchasing process and contracted with the conviction that it is secure. The checks are carried out regularly. However, every financial company must be aware that such data centers are repeatedly and often the focus of attacks, as the damage is multiplied by the number of users of such a service. It is therefore essential from the point of view of emergency preparedness to be able to switch from one service provider to another if a service provider gets into difficulties.

Let’s take as an example the contingency plan that in the event that the data of the data center operator were encrypted, the data could be displayed at another data center operator. Until the problem is resolved! This can sometimes take several weeks, as the attackers usually encrypt in such a way that importing a data backup also means importing the encryption. Fixing such a problem often takes so long because the actual information first has to be separated from the malicious information, as this has been hidden by the attackers and the search is always not easy.

Another good example is that of a sick customer from the insurance industry who has applied for an operation at this very moment and is waiting for approval of the costs. In the case of an urgent operation, he cannot wait long for this approval. However, the insurance company cannot make a blind cost commitment either. And the customer cannot or does not want to pay for the operation out of their own pocket. An operation can easily cost 15,000 euros or much more. What is the fate behind this financial decision?

A financial institution likes to prevent this by securing the data with a suitable stand so that this data can be processed on an interim basis by the same or better another service provider whose infrastructure was immune to this encryption.

Tried-and-tested methods are needed to ensure that service provider processes remain resilient. Book your training as a tester in the specialist area!

DORA change management: legal and compliance in the portfolio

By the deadline of January 17, 2025, most institutions have had their DORA project completed and meet the legal requirements. However, there are many uncertainties as to whether they will continue to do so in a year’s time and beyond. How will the company develop? And will they continue to do so in a year’s time and beyond? Which impact will any changes have on DORA compliance? Legal and Compliance must be able to assess the context of changes and their impact on DORA. To this end, they now work more closely with the specialist departments than ever before. A department cannot think in silos; many changes take place across departments. This is why it is now sensible and essential to have established reporting and decision-making channels in service processes (law, review, decision). To avoid getting lost in too much work, it is possible to use automatic checks. This allows all parties involved to concentrate fully on checking the real implications from a legal or compliance and governance perspective. Changes based on legal assessments belong in a portfolio and therefore compete with other projects. These resources must be kept free, as legal issues have top priority in most companies. Incidentally, this should also be implemented outside of DORA, as it applies in principle to all possible laws and regulations.

With our experience in automation and portfolio management, we help to automate risk processes. Find out more about our consulting services here!

DORA change management: Efficient management of risks

Risk management plays the main role in DORA. It is expected that there are clear processes in place to manage every relevant risk against digital resilience in risk management. In other words, from an everyday professional perspective: You can no longer get away with a reporting system based on Excel. From this starting point, it at first sounds like a lot of work. However, much of it can be automated, such as the evaluation of existing knowledge in the systems. For example, risk management can use automated reports to discover a server that (inadvertently) not has received any security updates. Automation also increases reporting quality and speed. An insecure server is usually not only a danger to itself, but also to the surrounding systems. This seemingly small risk could bring entire process chains to a standstill. This is why DORA is often started with a review of all process documentation, which plays a major role in assessing a risk.

But DORA also saves money, not just costs it. For example, it is much more economical to counteract damage associated with a risk than to wait until a risk occurs. Repairing the damage often costs ten or a hundred times as much. So even if the probability of occurrence is low but the damage is very high, the relatively inexpensive measures for risk avoidance, risk reduction or risk mitigation are worthwhile.

Risks can be reduced also with the motto “Always test before going live”, the effect of which is often underestimated. This topic is primarily aimed at identifying risks earlier, i.e. before they become productive.

DORA is committed to putting information and communication technology through its paces with a risk-based, proportional testing program.
In addition, all financial companies are audited again by a higher-level body, with the main purpose of helping to identify risks and thus ensure the resilience of financial companies throughout Europe. But what is being tested is the added value that companies are now creating: Digital resilience.

With our testing and automation experience, we save time and bring speed to quality monitoring, up to real-time, and help to demonstrate efficient control. Get in touch with our consultants!

DORA change management: control as a supervisory board or management board

As the Supervisory Board (Aufsichtsrat) and Management Board (Vorstand) play a central role in the governance and monitoring of DORA compliance, structured risk management is crucial. Efficient implementation requires automation, targeted portfolio management and clear monitoring mechanisms to ensure that processes remain resilient and governance is proven to work without being overly burdensome.

The introduction of DORA was an important milestone, but the real challenge lies in the continuous monitoring of daily operations and, in particular, daily change management. How can the Supervisory Board ensure that risks are identified and addressed in real time?

Examples of typical control issues of a supervisory board or management board:

• How is it ensured that all changes in IT systems and third-party services are systematically recorded, evaluated and approved?
• Are there automated monitoring mechanisms to detect new ICT risks in real time?
• How is reporting to the Management Board or Supervisory Board carried out?
  Are the indicators and KPIs for DORA risks prepared in a transparent and comprehensible manner?
• Which processes come into play when a service provider changes or new regulatory requirements arise?

These control issues show that DORA is not a one-off compliance project, but an ongoing management task that requires a clear allocation of responsibilities and stringent controls.

We help you to control DORA with less manual effort. Book an hour of board introduction with our DORA experts.

When will I be finished with DORA?

At trendig, we have extensive experience in the design and optimization of the processes outlined above and can support German banks, insurance companies and financial service providers in ensuring that DORA compliance is not just formal evidence but is developed into an integral part of corporate management in order to achieve digital resilience.

In the following, we would like to briefly outline some of the main ideas that we at trendig believe should be an essential part of your DORA compliance efforts.

Resilient ITC systems to minimize risk

One of the key measures for reducing ICT risks is the establishment and maintenance of resilient ICT systems and tools. These must be designed in such a way that they minimize security vulnerabilities and are resistant to threats. Resilient IT infrastructures make a decisive contribution to ensuring operational stability and reducing the risk of failure.

Identification and classification of critical functions and processes

Effective risk management requires critical key functions and processes to be identified, classified and documented. Without a detailed record of these elements, targeted control and prioritization of security measures is not possible.

Continuous monitoring and reporting systems for ICT risks

Continuous monitoring of all sources of ICT risks is crucial in order to identify potential threats at an early stage and implement suitable protection and prevention measures. A reporting system for identified security vulnerabilities must be established for almost all services in order to enable a rapid response to new risks and minimize attack surfaces.

Automated and documented risk communication

Furthermore, cross-line, automated and recorded communication about changes to significant risks is essential. Relevant stakeholders in the fields of data protection, information security, risk management, IT, specialist departments, legal, purchasing and the Management Board must work closely together in order to assess risks at an early stage and coordinate appropriate measures.

Complete testing before changes go live

Before changes to software, hardware, infrastructure or services are put into productive operation, complete testing is essential. This applies not only to new implementations, but also to existing systems in order to minimize the risk of undetected vulnerabilities.

Real-time monitoring with immediate reporting capability

Comprehensive 24/7 monitoring is required to detect anomalous activities and ensure that IT security incidents are reported immediately. Effective incident response management can only be guaranteed if security problems are identified and escalated quickly.

Business continuity policies and contingency plans

The introduction and regular updating of business continuity guidelines as well as emergency and recovery plans is essential for operational security. Annual tests of these plans ensure that all necessary functions remain functional in the event of an emergency and that crisis scenarios can be managed efficiently.

Risk management for service provider dependencies

A critical point in risk management is recognizing the impact on emergency plans when framework conditions change. This is particularly relevant in the case of dependencies on service providers and sub-service providers, as contingency plans often depend on their stability. Companies must ensure that all partners involved also have robust contingency strategies in place.

Learning mechanisms from internal and external incidents

The continuous improvement of IT security requires the establishment of mechanisms for analyzing and evaluating external and internal ICT incidents. Companies must learn from past security incidents in order to continuously develop their protective measures and recognize future threats at an early stage.

Would you like to talk to one of our consultants? Then write to us at engineering@trendig.com.

FAQs: Frequently asked questions about DORA

What is DORA?

DORA is something of a maturity model for the cyber security of financial companies. The acronym stands for Digital Operational Resilience Act and is an EU regulation (EU 2022/2554) for digital operational resilience across the European financial sector. The focus is particularly on cyber security, ICT risk management and governance.

For whom is DORA important?

DORA affects all institutions and companies operating in the European financial sector. The aim is to ensure that banks, investment firms, credit institutions and other payment service providers such as crowdfunding platforms are robust against IT failures, cyberattacks or other digital threats.

What are the penalties for non-compliance with DORA?

In Germany, the Federal Financial Supervisory Authority (Bundesanstalt für Finanzdienstleistungsaufsicht BaFin) is responsible for national supervision. In addition to enormous reputational damage, non-compliance with DORA can result in fines of up to 2% of global annual turnover or EUR 10 million, whichever is higher.

Durch eine zunehmend instabile politische Lage in einer sich schnell weiterentwickelnden digitalen Welt hat die Europäische Kommission mit der DORA-Verordnung (Digital Operational Resilience Act) ein einheitliches Framework geschaffen, mit dem ein effektives und umfassendes Management von Risiken im Bereich Cybersicherheit und Informations- und Kommunikationstechnologie (IKT) für Unternehmen der Finanzbranche gewährleistet sein soll.

Die EU schreibt dazu: „Die Nutzung von IKT hat in den letzten Jahrzehnten einen derart zentralen Stellenwert bei der Erbringung von Finanzdienstleistungen erlangt, dass sie heute entscheidend zur Ausführung typischer alltäglicher Aufgaben aller Finanzunternehmen beiträgt. Auf Digitalisierung beruhen heute beispielsweise Zahlungen, die von bargeld- und papiergestützten Methoden zunehmend auf die Nutzung digitaler Lösungen verlagert wurden, sowie Wertpapierclearing und -abrechnungssysteme, elektronischer und algorithmischer Handel, Darlehens- und Finanzierungsgeschäfte, Peer-to-Peer-Finanzierung, Bonitätseinstufung, Schadensmanagement und Back-Office-Transaktionen. Auch der Versicherungssektor hat sich durch den Einsatz von IKT verändert — vom Aufkommen digitaler Versicherungsvermittler, die ihre Dienste online anbieten und mit InsurTech arbeiten, bis hin zu digitalen Versicherungsgeschäften.“

Nachdem Unternehmen bis zum 16. Januar 2025 eine zweijährige Umsetzungsphase durchlaufen haben, um ihren Reifegrad in Bezug auf DORA zu ermitteln und sich proaktiv gegen mögliche Überfälle und Ausfälle zu schützen, stehen sie nun vor der Mammutaufgabe, eine dauerhafte Compliance mit DORA auch unter sich ändernden Rahmenbedingungen und internen Strukturen sicherzustellen. Insbesondere der starke Fokus von DORA auf das sogenannte Third-Party Risk Management, also die strikte Überwachung aller Dienstleister und deren Robustheit, stellt Finanzunternehmen vor große Herausforderungen: Denn IKT-Drittanbieter entziehen sich dem Fokus des Unternehmens leichter, als die enge Interaktion und Abhängigkeit mit dem Finanzunternehmen vermuten lässt.

DORA implementiert = gut geschützt vor Angriffen?

Mit der Implementierung von DORA sehen sich die meisten Finanzunternehmen gut aufgestellt, um sich und ihre Geschäftsprozesse im Falle eines Cyberangriffs zu schützen. Doch diese Annahme ist zu kurzsichtig, denn sie lässt das Management zukünftiger Veränderungen außer Acht, der die operative Resilienz dauerhaft sichern muss.

Veränderungen mit DORA managen

Zum Zeitpunkt der Ist-Erhebung zu DORA wurden in den Finanzunternehmen zum Teil sehr große Projekte aufgesetzt, um die vorhandenen und zukünftig möglichen Risiken genauer zu beleuchten. Daraus folgend wurden Maßnahmen abgeleitet und beschrieben, mit denen diese Risiken vermieden, mitigiert, transferiert oder gestreut werden können.

Besonders detailliert wird in der DORA-Verordnung vorgegeben, wie sich Unternehmen gegen Dienstleister-Ausfälle schützen müssen. Anlass hierfür waren eine Reihe von Cyberangriffen in Form von Datenverschlüsselungs-Attacken (Ransomware), die zu erheblichen wirtschaftlichen Schäden führten, da viele Dienstleister von denselben zentralen Infrastrukturen abhängig sind.

Für Neuanschaffungen sind diese Prozesse in der Regel gut etabliert. Insbesondere spielt das sogenannte Ausgliederungsmanagement eine wesentliche Rolle. Ein genauerer Blick lohnt sich jedoch auf die Veränderungsprozesse, insbesondere wenn Unternehmen Cloud-Dienste wie SaaS (Software as a Service), IaaS (Infrastructure as a Service) oder PaaS (Platform as a Service) nutzen. Die zentrale Frage lautet dann: Wie erkennen Unternehmen rechtzeitig Veränderungen in diesen Diensten, die Risiken mit sich bringen könnten? Denn diese Dienste liegen nicht direkt in ihrem Kontrollbereich und Veränderungen werden nicht automatisch wahrgenommen und somit auch nicht hinsichtlich der darin verborgenen Risiken bewertet.

DORA fordert in diesem Zusammenhang strikte Tests jeder Veränderung vor der Produktivsetzung. Dabei müssen Unternehmen sicherstellen, dass Risikoveränderungen frühzeitig erkannt und bewertet werden.

Verändert sich bei genutzten Diensten der Leistungsumfang, entstehen oft neue Risiken. Diese müssen erkannt werden, bevor ein Dienst weiterhin oder erneut verwendet wird. Doch eine vollständige Identifikation aller relevanten Veränderungen ist oft komplexer, als es auf den ersten Blick scheint.

Beispiele:

• Wenn ein Fachbereich eigenständig Software nutzt oder verändert, ohne dass die IT-Abteilung involviert ist.
• Wenn ein Dienstleister fusioniert oder Subdienstleister austauscht, wodurch bestehende Notfallpläne nicht mehr wie geplant funktionieren.
• Wenn durch eine Änderung neue Bedrohungen für die IT-Sicherheit entstehen, die eine sofortige Risiko-Neubeurteilung erfordern.

Deshalb ist es essenziell, dass alle Organisationseinheiten eng mit dem Risikomanagement zusammenarbeiten. Quartalsorientiertes Meldewesen ist nicht mehr zeitgemäß — stattdessen muss das Risikomanagement direkt mit dem Veränderungsmanagement gekoppelt werden, um kontinuierlich auf neue Risiken reagieren zu können. Im folgenden erläutern wir einige alltägliche Szenarien, deren Tragweite hinsichtlich des Risikomanagements sich erst bei genauerem Hinsehen erschließen lässt.

DORA-Veränderungsmanagement: Business und Kontrolle

Eine HR-Anwendung eines Dienstleisters (Drittdienstleister Third Party Risk) wird zunächst für Zwecke eingeführt, die einem normalen Verwaltungsakt geschuldet sind und sich hinsichtlich Vertraulichkeits-, Verfügbarkeits- und Integritätsrisiko her vertretbar auslagerungsfähig einstufen lassen — zum Beispiel die Mitarbeiter-Zeiterfassung. Die Risikoanalyse wird zu diesem Zeitpunkt typerischerweise für diejenigen Teile der Anwendung durchgeführt, deren Verwendung zu diesem Zeitpunkt vorgesehen ist.

Die Anwendung verfügt aber über ein deutlich stärkeres Toolpotential und erlaubt in der Nutzung viel, so dass die ausgeführten Prozesse in der täglichen Nutzung beständig erweitert werden. Zum Beispiel sollen jetzt auch Mitarbeitergespräche protokolliert werden. Diese Daten sind in der Regel als streng vertraulich einzustufen, weil sensible oder kritische Inhalte erfasst werden könnten. Aus Sicht des Risikomanagements ist ein „Change Request“ erforderlich, obwohl technisch keine Veränderung vorgenommen wird. Und das, bevor die Anwendung erweitert produktiv genutzt wird.

Anhand dieses einen Beispiels wird schon die notwendige enge Zusammenarbeit aus verschiedenen Organisationseinheiten hinsichtlich des Risikomanagements gut sichtbar: Compliance hat Prozesse definiert, die solche Risiken sichtbar machen, z.B. ein Service-Management nach ITIL. Der Fachbereich meldet in diesem Prozess-Rahmenwerk die gewünschte veränderte Nutzung, der zufolge der Datenschutz die Vertraulichkeit neu einstufen und das Risikomanagement zusätzliche Maßnahmen zum Schutz der Daten beim Dienstleister einfordern kann. Governance prüft die Wirtschaftlichkeit, Recht prüft Vertragsrechte, Einkauf passt die Verträge an und verändert gegebenenfalls die Überwachungsmaßnahmen zum Dienstleister. Aufgrund des erhöhten Risikos werden zusätzliche Tests in Fachbereich und IT eingeführt.

Es braucht praxiserprobte Prozesse, um Risiken effizient zu managen und zu kontrollieren. Sichere Dir Deinen Schulungsplatz zu nachhaltigem Anforderungsmanagement im Fachbereich!

DORA-Veränderungsmanagement: IT und Risikomanagement

Ein externes Rechenzentrum, das die Daten eines Finanzunternehmens verwaltet, wird beim Einkauf gründlich geprüft und mit der Überzeugung unter Vertrag genommen, dass dieses sicher ist. Die Überprüfung erfolgt regelmäßig. Demgegenüber muss sich jedes Finanzunternehmen allerdings bewusst machen, dass solche Rechenzentren immer wieder und oft im Fokus von Angriffen stehen, da sich der Schaden mit der Anzahl der Nutzer eines solchen Dienstes multipliziert. Daher ist es aus Gesichtspunkten der Notfallvorsorge unbedingt notwendig, von einem Dienstleister zum anderen schwenken zu können, sollte ein Dienstleister in Schwierigkeiten gelangen.

Nehmen wir als Beispiel den Notfallplan, dass für den Fall, dass die Daten des Rechenzentrums-Betreibers verschlüsselt würden, die Daten bei einem anderen Rechenzentrums-Betreiber angezeigt werden könnten. Und zwar bis das Problem behoben ist! Denn das kann auch mal einige Wochen dauern, denn die Angreifer verschlüsseln meist so, dass das Einspielen einer Datensicherung auch das Einspielen der Verschlüsselung bedeutet. Die Behebung eines solchen Problems dauert deshalb oft so lange, weil erst die eigentlichen Informationen von den schadhaften getrennt werden müssen, da diese von den Angreifern versteckt hinterlegt wurden und sich die Suche nicht immer ganz einfach gestaltet.

Ein weiteres gutes Beispiel ist das eines kranken Kunden aus der Versicherungsbranche, der genau in diesem Augenblick eine OP beantragt hat und auf die Kostenzusage wartet. Bei einer dringenden OP kann er auf diese Zusage nicht lange warten. Eine blinde Kostenzusage kann das Versicherungsunternehmen aber auch nicht treffen. Und die OP kann oder will der Kunde nicht aus eigener Tasche bezahlen. Eine Operation kann leicht 15.000 Euro oder auch viel mehr kosten. Welches Schicksal steckt hinter dieser finanziellen Entscheidung?

Ein Finanzinstitut beugt diesem gerne vor, indem die Daten mit einem passenden Stand gesichert sind, so dass diese Daten beim gleichen oder besser einem anderen Dienstleister interimistisch verarbeitet werden können, dessen Infrastruktur gegen diese Verschlüsselung immun war.

Es braucht praxiserprobte Methoden, damit Dienstleister-Prozesse resilient bleiben. Buche Deine Schulung als Tester im Fachbereich!

DORA-Veränderungsmanagement: Recht und Compliance im Portfolio

Die meisten Institute haben zum Stichtag 17. Januar 2025 ihr DORA-Projekt abgeschlossen und erfüllen die gesetzlichen Anforderungen. Bei der Frage aber, ob sie dies auch in einem Jahr und darüber hinaus tun werden, gibt es viele Unsicherheiten. Wie entwickelt sich das Unternehmen weiter? Welche Auswirkungen ergeben sich aus etwaigen Veränderungen auf die Erfüllung von DORA? Recht und Compliance müssen den Zusammenhang von Änderungen und deren Wirkung auf DORA einschätzen können. Dazu arbeiten diese heute enger und engmaschiger als bisher mit den Fachbereichen zusammen. Ein Fachbereich kann dabei nicht im Silo denken, viele Veränderungen finden Fachbereichs-übergreifend statt. Deshalb ist es heute sinnvoll und unabdingbar, Melde- und Entscheidungswege in Service-Prozessen etabliert zu haben (Gesetz, Prüfung, Entscheidung). Um dabei nicht in zu viel Arbeit unterzugehen, ist es möglich, automatische Prüfungen zu verwenden. Dann können sich alle Beteiligten voll und ganz darauf konzentrieren, die echten Betroffenheiten juristisch oder hinsichtlich Compliance und Governance zu prüfen. Änderungen aufgrund von Rechtseinschätzungen gehören in ein Portfolio und konkurrieren so mit anderen Projekten. Diese Ressourcen müssen freigehalten werden, denn in den meisten Unternehmen gilt, dass rechtliche Themen höchste Priorität haben. Im Übrigen sollte dies auch abseits von DORA implementiert sein, denn es gilt im Prinzip für alle möglichen Gesetze und Regulierungen.

Mit unseren Erfahrungen in Automatisierung und Portfoliomanagement helfen wir, Risikoprozesse zu automatisieren. Erfahre hier mehr zu unseren Consulting-Dienstleistungen!

DORA-Veränderungsmanagement: Effizientes Steuern von Risiken

In DORA spielt das Risikomanagement die Haupt-Rolle. Es wird erwartet, dass es klare Prozesse gibt, die jedes relevante Risiko gegen die digitale Resilienz im Risikomanagement steuern. Das heißt aus dem Berufsalltag heraus gesprochen: Man kommt mit einem Meldewesen auf Basis von Excel nicht mehr gut durch. Von diesem Ausgangspunkt gedacht, klingt es zunächst nach sehr viel Arbeit. Vieles davon ist aber automatisierbar, wie z.B. die Auswertung des vorhandenen Wissens in den Systemen. So kann z.B. das Risikomanagement durch automatisierte Meldungen den einen Server entdecken, der (versehentlich) keine Sicherheitsupdates bekommen hat. Durch eine Automatisierung erhöhen sich zudem Meldequalität und -geschwindigkeit. Ein unsicherer Server stellt nämlich meist nicht nur eine Gefahr für sich, sondern auch für die umliegenden Systeme dar. Dieses scheinbar kleine Risiko könnte ganze Prozessketten zum Stillstand bringen. Deshalb startet man DORA auch gerne mit der Überprüfung aller Prozessdokumentationen, die bei der Einschätzung eines Risikos eine große Rolle spielen.

DORA spart aber auch Geld und kostet nicht nur. So ist es z.B. viel wirtschaftlicher, einem mit einem Risiko verbundenen Schaden entgegenzuwirken, als bis zum Eintritt eines Risikos zu warten. Den Schaden zu beheben kostet oft ein zehnfaches oder hundertfaches an Aufwand. Selbst wenn die Eintrittswahrscheinlichkeit also niedrig, der Schaden aber sehr hoch ist, rentieren sich die im Verhältnis preiswerten Maßnahmen zur Risikovermeidung, Risikoreduzierung oder Risikomitigation.

Risiken verringern kann darüber hinaus mit dem Thema „Immer Testen vor Produktiveinsatz“, dessen Wirkung gerne unterschätzt wird. Dieses Thema zahlt nämlich vor allem darauf ein, Risiken früher zu erkennen, also noch bevor sie produktiv entstehen.

DORA verpflichtet dazu, die Informations- und Kommunikationstechnologie auf Herz und Nieren zu prüfen, mit einem risikobasiertes, proportionalem Testprogramm.
Von übergeordneter Stelle werden darüber hinaus nochmal alle Finanzunternehmen geprüft, mit dem Hauptzweck der Hilfestellung, Risiken zu erkennen und somit europaweit für Resilienz der Finanzunternehmen zu sorgen. Aber geprüft wird das, was die Unternehmen jetzt an Mehrwert schaffen: Digitale Resilienz.

Mit unseren Test- und Automatisierungs-Erfahrung sparen wir Zeit und bringen Geschwindigkeit in die Qualitätsüberwachung, bis hin zu Echtzeit und helfen, eine effiziente Steuerung nachzuweisen. Tritt mit unseren Consultants in Kontakt!

DORA-Veränderungsmanagement: Kontrolle als Aufsichtsrat oder Vorstand

Da der Aufsichtsrat und Vorstand eine zentrale Rolle in der Governance und Überwachung der DORA-Compliance spielen, ist ein strukturiertes Risikomanagement entscheidend. Eine effiziente Umsetzung erfordert Automatisierung, gezieltes Portfoliomanagement und klare Überwachungsmechanismen, um sicherzustellen, dass Prozesse resilient bleiben und die Steuerung nachweislich funktioniert, ohne dabei den Aufwand zu hoch werden zu lassen.

Die Einführung von DORA war ein wichtiger Meilenstein, aber die eigentliche Herausforderung liegt in der kontinuierlichen Kontrolle im täglichen Betrieb und insbesondere im täglichen Veränderungsmanagement. Wie kann der Aufsichtsrat sicherstellen, dass Risiken in Echtzeit erkannt und adressiert werden?

Beispiele für typische Kontrollfragen eines Aufsichtsrats oder Vorstands:

• Wie wird sichergestellt, dass alle Veränderungen in IT-Systemen und Drittanbieter-Diensten systematisch erfasst, bewertet und genehmigt werden?
• Gibt es automatisierte Überwachungsmechanismen, um neue IKT-Risiken in Echtzeit zu erkennen?
• Wie erfolgt die Berichterstattung an den Vorstand bzw. Aufsichtsrat?
  Sind die Indikatoren und KPIs für DORA-Risiken transparent und verständlich aufbereitet?
• Welche Prozesse greifen, wenn sich ein Dienstleister ändert oder neue regulatorische Anforderungen entstehen?

Diese Kontrollfragen zeigen, dass DORA kein einmaliges Compliance-Projekt ist, sondern eine kontinuierliche Managementaufgabe, die eine klare Verantwortlichkeitsverteilung und stringente Kontrollen erfordert.

Wir helfen, DORA mit weniger manuellem Aufwand zu kontrollieren. Buche eine Stunde Vorstandseinführung mit unseren DORA-Experten.

Wann bin ich fertig mit DORA?

Wir bei trendig verfügen über umfassende Erfahrung in der Gestaltung und Optimierung oben dargestellter Prozesse und können deutsche Banken, Versicherungen und Finanzdienstleister dabei unterstützen, dass DORA-Compliance nicht nur ein formaler Nachweis bleibt, sondern zu einem integralen Bestandteil der Unternehmenssteuerung ausgebaut wird, um digitale Resilienz zu erreichen.

Einige Hauptgedanken, die für uns bei trendig zu den essentiellen Bestandteilen Deiner Bemühungen rund um DORA-Compliance zählen sollten, möchten wir Dir im Folgenden noch einmal in kurzen Stichpunkten vorstellen.

Belastbare ITK-Systeme zur Risikominimierung

Eine der zentralen Maßnahmen zur Reduzierung von IKT-Risiken ist die Einrichtung und Pflege belastbarer IKT-Systeme und -Werkzeuge. Diese müssen so gestaltet sein, dass sie Sicherheitslücken minimieren und widerstandsfähig gegenüber Bedrohungen sind. Resiliente IT-Infrastrukturen tragen entscheidend dazu bei, die Betriebsstabilität zu sichern und Ausfallrisiken zu reduzieren.

Identifizierung und Klassifizierung kritischer Funktionen und Prozesse

Ein effektives Risikomanagement setzt voraus, dass kritische Schlüsselfunktionen und -Prozesse identifiziert, klassifiziert und dokumentiert sind. Ohne eine detaillierte Erfassung dieser Elemente ist eine gezielte Steuerung und Priorisierung von Sicherheitsmaßnahmen nicht möglich.

Kontinuierliche Überwachung und Meldesysteme für IKT-Risiken

Die fortlaufende Überwachung aller Quellen von IKT-Risiken ist entscheidend, um frühzeitig potenzielle Bedrohungen zu erkennen und geeignete Schutz- und Präventionsmaßnahmen einzurichten. Hierbei ist ein Meldewesen für erkannte Sicherheitslücken für fast alle Dienste zu etablieren, um eine schnelle Reaktion auf neue Risiken zu ermöglichen und Angriffsflächen zu minimieren.

Automatisierte und dokumentierte Risiko-Kommunikation

Ferner ist eine linienübergreifende, automatisierte und protokollierte Kommunikation über Veränderungen an wesentlichen Risiken essenziell. Dabei müssen relevante Stakeholder in den Feldern Datenschutz, Informationssicherheit, Risikomanagement, IT, Fachbereiche, Recht, Einkauf und Vorstand eng zusammenarbeiten, um Risiken frühzeitig zu bewerten und entsprechende Maßnahmen zu koordinieren.

Vollständige Tests vor Produktivsetzung von Änderungen

Bevor Änderungen an Software, Hardware, Infrastruktur oder Diensten in den produktiven Betrieb überführt werden, sind vollständige Tests unerlässlich. Dies gilt nicht nur für Neuimplementierungen, sondern insbesondere auch für bestehende Systeme, um Risiken durch unerkannte Schwachstellen zu minimieren.

Echtzeit-Monitoring mit unverzüglicher Meldefähigkeit

Zur Erkennung von anomalen Aktivitäten ist ein umfassendes 24/7-Monitoring erforderlich, das eine unverzügliche Meldung von IT-Sicherheitsvorfällen sicherstellt. Nur durch eine schnelle Identifikation und Eskalation von Sicherheitsproblemen kann ein wirksames Incident-Response-Management gewährleistet werden.

Business-Continuity-Richtlinien und Notfallpläne

Die Einführung und regelmäßige Aktualisierung von Business-Continuity-Richtlinien sowie Notfall- und Wiederherstellungsplänen ist für die Betriebssicherheit essenziell. Jährliche Tests dieser Pläne stellen sicher, dass alle notwendigen Funktionen auch im Ernstfall funktionsfähig bleiben und Krisenszenarien effizient bewältigt werden können.

Risikomanagement bei Dienstleister-Abhängigkeiten

Ein kritischer Punkt im Risikomanagement ist die Erkennung von Auswirkungen auf Notfallpläne, wenn sich Rahmenbedingungen ändern. Besonders relevant ist dies bei Abhängigkeiten von Dienstleistern und Sub-Dienstleistern, da Notfallpläne oft von deren Stabilität abhängen. Unternehmen müssen sicherstellen, dass alle beteiligten Partner ebenfalls über robuste Notfallstrategien verfügen.

Lernmechanismen aus internen und externen Vorfällen

Die kontinuierliche Verbesserung der IT-Sicherheit erfordert die Einrichtung von Mechanismen zur Analyse und Auswertung von externen sowie internen IKT-Vorfällen. Unternehmen müssen aus vergangenen Sicherheitsereignissen lernen, um ihre Schutzmaßnahmen kontinuierlich weiterzuentwickeln und zukünftige Bedrohungen frühzeitig zu erkennen.

(CTA) Möchtest Du mit einem unserer Consultants in den Austausch gehen? Dann schreib uns an engineering@trendig.com.

FAQs: Häufig gestellte Fragen zu DORA

Was ist DORA?

DORA ist so etwas wie ein Reifegradmodell für Cybersicherheit von Finanzunternehmen. Die Abkürzung steht für Digital Operational Resilience Act und ist eine Verordnung der EU (EU 2022/2554) für die digitale Betriebsstabilität im gesamten europäischen Finanzsektor. Der Fokus liegt insbesondere auf den Themen Cybersicherheit, IKT-Risikomanagement und Governance.

Für wen ist DORA wichtig?

DORA betrifft alle Institute und Unternehmen, die im europäischen Finanzsektor tätig sind. Es soll sichergestellt werden, dass Banken, Wertpapierfirmen, Kreditinstitute und andere Zahlungsdienstleister wie z.B. Crowdfunding-Plattformen gegen IT-Ausfälle, Cyberangriffe oder andere digitale Bedrohungen robust sind.

Welche Strafen drohen bei Nichteinhaltung von DORA?

In Deutschland übernimmt die Bundesanstalt für Finanzdienstleistungsaufsicht (kurz BaFin) die nationale Aufsicht. Neben enormen Reputationsschäden werden bei Nichteinhaltung von DORA Geldbußen von bis zu 2% des weltweiten Jahresumsatzes oder 10 Millionen Euro erhoben, je nachdem, welcher Betrag höher ist.

How agile methods and software development according to GAMP5 (Good Automated Manufacturing Practise) match

In many industries, special legal and regulatory requirements apply to assess and ensure product quality, risks and the effects of software. One such so-called ‘regulated environment’ is the pharmaceutical industry and the entire healthcare sector as such. Here, too, an approach known as ‘Good Automated Manufacturing Practice’ has become common practice almost without exception, known by the abbreviation GAMP5.

GAMP5 provides a set of rules for automatable processes. This also includes a recommended approach for software development and maintenance. As a rule, GAMP5 is based on a V-model approach to map quality-assured and documented development, maintenance and operation within a quality assurance system.

GAMP5 regulations in software development

An essential part of the GAMP5 standard is the assumption that all requirements have been recorded and documented before development begins, so that in the event of problems or damage, the responsible parties can be contacted and countermeasures planned. It also allows the success of a project to be clearly measured and documented at a later stage.

In contrast to the GAMP5 approach, an agile project management approach allows more freedom in short-term planning and can react more flexibly to changes and unexpected events. In addition, the flow of information between all parties involved is significantly faster due to direct communication. This means that errors can be detected and eliminated earlier.

Since the GAMP approach is highly standardised in a regulated environment and clarifies the expected results, the project duration, the approach and the costs in advance between all parties involved, this model has undeniable advantages for compliance and governance.
However, the disadvantage of the V-model is that it is only partially suitable for the development process due to its strict specifications and low flexibility.

GAMP5 regulations and an agile approach

However, there is nothing in the GAMP5 model that argues against making the development team’s approach agile. By taking advantage of both models, there is an opportunity to improve the overall quality and speed of a development without violating the regulatory requirements.

A purely agile approach in a regulated environment has the disadvantage of having to reimplement the entire documentation process. In practice, this often leads to considerable effort for coordination and release. These expenses are often underestimated and cost the project a lot of resources, which are then no longer available for the actual development and quality assurance.

Agile software development in a regulated environment — how to

If the advantages of the V-model and the agile approach can be successfully combined and the disadvantages kept to a minimum, it is possible to improve quality and development speed while still meeting regulatory requirements.

In principle, the organisation of the project must be adapted to the specific requirements that arise from the project objectives. Therefore, at this point, some rather general approaches that facilitate the start of agile software development in a regulated environment:

1. Agile methods can be used in the development teams

Experience shows that development teams are more productive and satisfied when they are released from the rigid organisational constraints of the V-model and allowed to organise themselves. In this context, software testing is an explicit part of the work: DONE means developed, tested and also documented.

2. All other parts of the project are organised according to the rules of the V-model

Usually, especially in large regulated organisations, the project management guidelines are strictly defined and can only be changed with a considerable amount of coordination effort. In most cases, the planned project duration and budget are simply not sufficient for this.

3. Clear communication interfaces between the agile and conventional sub-projects involving the establishment of an adapted role model

Since responsibilities are organised differently in the V-model and in the agile approach, the distribution of roles, responsibilities and communication channels should be coordinated at the start of the project. Without this coordination, there are often frictional losses and misunderstandings in communication.

4. Completed requirements engineering phase and fully defined acceptance criteria before development activities begin

In the V-model, subsequent changes or additions to the requirements can usually only be implemented with considerable organisational effort. One way to resolve the conflict between the rigid V-model and the flexible agile approach may be to define the requirements and acceptance criteria in such a way that the development teams are granted sufficient freedom in the implementation. Here, the Requirements Engineers are particularly challenged to strike a balance between resilient requirements and flexible implementation.

5. Transfer of defined and tested releases from the development team to the project

A good prerequisite for a successful project is the clear definition of milestones, each of which, when reached, is accompanied by a new release for the higher test levels. Among other things, this facilitates the communication of the project’s progress and the management of expectations for the overall project.

6. High test frequency in the development team, lower test frequency for the other test levels

Ideally, each build process in the development team should be concluded with an automated test run. This is easiest to implement if the unit tests are created by the developers in the source code.
The higher the test level, the less often testing is required, since the lower test levels already ensure a large part of the quality requirements. Here, it has proven useful to strive for the most complete coverage possible of the unit tests, taking into account the identified risks.

7. Taking into account the different speeds and approaches in the project plan

In the project plan, there will most likely be different requirements for the frequency of progress and defect reports, since the development teams usually generate daily builds with defect reports, while the other testers may work with weekly or monthly releases and reports.

8. Test management and release processes must be adapted to the hybrid approach.

In the agile development process, the degree of automation of testing should be very high and the release process should be based on milestones. The higher the test level, the more formal and manual the testing will be, which puts the focus of test management on the completeness of documentation and the organisation of the tests.

Taking these key aspects into account, the introduction of agile software development can also be successful in a regulated environment. A systematic approach is the basic requirement for integrating agile software development methods while adhering to regulatory requirements.

If you would also like to benefit from our expertise in regulated environments, then let’s talk about your specific challenge. You can contact us at techtalk@trendig.com and we look forward to talking to you.

Wie sich agiles Vorgehen und Softwareentwicklung nach GAMP5 (Good Automated Manufacturing Practise) vereinen lassen

In vielen industriellen Branchen gelten besondere gesetzliche und regulatorische Bestimmungen, um die Produktqualität, die Risiken und die Wirkungen einer Software einschätzen und sicherstellen zu können. Ein solches sogenanntes “reguliertes Umfeld” ist die Pharmabranche bzw. der gesamte Gesundheitssektor als solches. Auch hier hat sich ein Vorgehen nahezu ausnahmslos verbreitet, dass sich “Good Automated Manufacturing Practice” nennt und mit GAMP5-Standard abgekürzt wird.

GAMP5 stellt ein Regelwerk für automatisierbare Prozesse dar. Dazu gehört auch eine empfohlene Vorgehensweise für die Softwareentwicklung und Wartung. In der Regel sieht GAMP5 ein Vorgehen nach dem V-Modell vor, um die qualitätsgesicherte und dokumentierte Entwicklung, Wartung und den Betrieb im Rahmen eines Qualitätssicherungssystems abzubilden.

GAMP5-Regulatorien in der Softwareentwicklung

Ein wesentlicher Bestandteil des GAMP5 Standards ist es davon auszugehen, dass vor Beginn der Entwicklung sämtliche Anforderungen erfasst und dokumentiert sind, um im Fall von Problemen oder Schadensfällen Verantwortliche zu kontaktieren und Gegenmaßnahmen planen und später den Erfolg eines Projektes eindeutig messen und dokumentieren zu können.

Im Gegensatz zum Vorgehen nach GAMP5 ergibt ein agiles Projektmanagement mehr Freiheit in der kurzfristigen Planung und kann flexibler auf Änderungen und unerwartete Ereignisse reagieren. Darüber hinaus ist der Informationsfluss zwischen allen Beteiligten aufgrund der direkten Kommunikation deutlich schneller. Somit können Fehler früher entdeckt und beseitigt werden.

Da das Vorgehen nach GAMP im regulierten Umfeld hoch standardisiert ist und zwischen allen Beteiligten die erwartbaren Ergebnisse, die benötigte Zeit, das Vorgehen und die Kosten vorab klärt, hat dieses Modell unbestreitbare Vorteile für die Einhaltung von Compliance und Governance.

Nachteil des V-Modells ist jedoch, dass es durch seine strikten Vorgaben und die geringe Flexibilität nur bedingt für den Entwicklungsprozess geeignet ist.

GAMP5-Regularien und agiles Vorgehen

Es spricht jedoch im GAMP5 Modell nichts dagegen, die Vorgehensweise des Entwicklungsteams agil zu gestalten. Durch Nutzung der Vorteile beider Modelle ergibt sich die Chance, insgesamt die Qualität und die Geschwindigkeit einer Entwicklung zu verbessern, ohne die Vorgaben der Regulierungsanforderungen zu verletzen.

Ein rein agiles Vorgehen im regulierten Umfeld hat den Nachteil, den gesamten Dokumentationsprozess neu implementieren zu müssen. Dies führt in der Praxis häufig zu erheblichen Aufwendungen für die Abstimmung und Freigabe. Diese Aufwendungen werden häufig unterschätzt und kosten das Projekt viele Ressourcen, die für die eigentliche Entwicklung und Qualitätssicherung dann nicht mehr zur Verfügung stehen.

Agile Softwareentwicklung im regulierten Umfeld — HowTo

Wenn es gelingt, die Vorteile des V-Modells und des agilen Vorgehens miteinander zu verbinden und die Nachteile so gering wie möglich zu halten, kann man die Qualität und die Entwicklungsgeschwindigkeit verbessern und dennoch die Vorgaben der Regulatorik einhalten.

Grundsätzlich muss die Organisation des Projektes an die konkreten Anforderungen, die sich aus den Projektzielen ergeben, angepasst sein. Deshalb an dieser Stelle einige eher allgemeine Vorgehensweisen, die den Start in agile Softwareentwicklung im regulierten Umfeld erleichtern:

1. In den Entwicklerteams können agile Methoden eingesetzt werden

Die Erfahrung zeigt, dass Entwicklerteams produktiver und zufriedener sind, wenn sie organisatorisch aus dem starren Korsett des V-Modells herausgelöst sind und sich selbst organisieren dürfen. Hierbei ist das Softwaretesten ausdrücklicher Bestandteil des Arbeitens: DONE bedeutet dabei entwickelt, getestet und auch dokumentiert.

2. Alle anderen Teile des Projektes werden nach den Regeln des V-Modells organisiert.

Üblicherweise sind besonders in großen regulierten Organisationen die Projektmanagement-Richtlinien stark vorgegeben und nur mit erheblichem Aufwand in der Abstimmung veränderbar. In der Regel reichen die geplante Projektlaufzeit und die Budgetvorgaben dazu nicht aus.

3. Klare Kommunikationsschnittstellen zwischen den agilen und den herkömmlichen Teilprojekten mit Etablierung eines angepassten Rollenmodells

Da im V-Modell und in der agilen Vorgehensweise Verantwortungen unterschiedlich organisiert sind, sollte zum Projektstart eine Abstimmung über die Rollenverteilung, die Verantwortungen und die Kommunikationswege stattfinden. Ohne diese Abstimmung kommt es häufig zu Reibungsverlusten und Missverständnissen in der Kommunikation.

4. Abgeschlossene Requirements Engineering Phase und vollständig definierte Abnahmekriterien vor Beginn der Entwicklungstätigkeiten

Im V-Modell sind spätere Änderungen oder Ergänzungen der Requirements i.d.R. nur mit erheblichem organisatorischen Aufwand durchführbar. Eine Möglichkeit, den Konflikt zwischen rigidem V-Modell und flexiblem agilen Vorgehen zu lösen, kann darin bestehen, die Requirements und Abnahmekriterien so zu definieren, dass den Entwicklerteams ausreichend Freiheiten in der Umsetzung gewährt werden. Hier sind die Requirements Engineers besonders gefordert, die Balance zwischen belastbaren Anforderungen und flexibler Umsetzung herzustellen.

5.Überführung definierter und getesteter Releasestände vom Entwicklerteam an das Projekt

Eine gute Voraussetzung für ein gelungenes Projekt ist die klare Definition von Meilensteinen, deren Erreichung jeweils mit einem neuen Release für die höheren Teststufen einhergeht. Dies erleichtert u.a. die Kommunikation des Projektfortschritts und das Erwartungsmanagement des Gesamtprojektes.

6. Hohe Testfrequenz im Entwicklerteam, niedrigere Testfrequenz der anderen Teststufen

Idealerweise sollte im Entwicklerteam jeder Build-Process von einem automatisierten Testlauf abgeschlossen werden. Dies ist am einfachsten umzusetzen, wenn bereits im Source Code die Unit Tests von den Entwicklern angelegt werden.

Je höher die Teststufe, umso seltener muss getestet werden, da die niedrigeren Teststufen bereits einen großen Teil der Qualitätsanforderungen sicherstellen. Hier hat es sich bewährt, eine möglichst vollständige Coverage der Unit Tests unter Berücksichtigung der identifizierten Risiken anzustreben.

7. Berücksichtigung der unterschiedlichen Geschwindigkeiten und Vorgehensweisen im Projektplan

Im Projektplan wird esmit hoher Wahrscheinlichkeit unterschiedliche Anforderungen an die Frequenz von Fortschritts- und Defektberichten geben, da die Entwicklerteams i.d.R. tägliche Builds mit Defect Reports generieren, während die anderen Tester vielleicht mit wöchentlichen oder monatlichen Releases und Reports arbeiten werden.

8. Das Testmanagement und die Freigabeprozesse müssen an die hybride Arbeitsweise angepasst werden

Im agilen Entwicklungsprozess sollte der Automatisierungsgrad des Testens sehr hoch sein und der Freigabeprozess an Meilensteinen orientiert werden. Je höher die Teststufe umso formaler und manueller wird das Testen ausfallen, was den Schwerpunkt des Testmanagements auf die Dokumentenvollständigkeit und die Organisation der Tests legt.

Unter Berücksichtigung dieser Schwerpunkte kann eine Einführung agiler Softwareentwicklung auch im regulierten Umfeld gelingen. Ein systematischer Ansatz ist dabei die Grundvoraussetzung, um agile Softwareentwicklungsmethoden unter Einhaltung der regulatorischen Anforderungen zu integrieren.

Wenn auch Du von unserer Expertise in regulierten Umfeldern profitieren möchtest, dann lass uns über Deine konkrete Herausforderung sprechen. Wir sind unter techtalk@trendig.com für Deine Anfrage erreichbar und freuen uns, mit Dir ins Gespräch zu kommen.

AI or not (yet) AI — The current dilemma of corporate management

AI in the here and now

Even if it still looks like hype at the moment: The focus on artificial intelligence is here to stay. Why? Because some companies are using AI in a very targeted, meaningful and therefore successful way and therefore have the potential to transform the world. They will lead the way and artificial intelligence will be the key to success. Companies can become faster and, to a large extent, more efficient in some activities. The money saved will increase profits and therefore the opportunities to invest in new projects on the one hand and payouts and bonuses for the staff involved on the other. Artificial intelligence is primarily a tool for increasing efficiency in many different areas. Depending on how well the company is already positioned, these increases in efficiency are accompanied by staff reductions or support the existing staff to significantly increased performance.

In the following, I would like to take a closer look at individual points in order to provide a different perspective away from the hype and towards a planned approach:

AI is a tool, not a magic remedy

First of all: artificial intelligence is a tool. It can be used to perfection, or it may not. AI does not always mean success and, above all, not always efficiency. Because AI is software. And that means that AI applications, like other software, need to be regularly and reliably maintained in order to function as intended. This is often not taken into account in current deployment scenarios, but must be an integral part of any project planning.

Nothing works without clean data

The use of AI requires data. Sometimes there is more, sometimes there is a lot. On the one hand, this data must be available and, on the other, it must be processed in such a way that it makes sense to use it so that it serves the purpose of using artificial intelligence. The data must be tagged (marked) and a distinction must be made as to which data is training data and which is test data. What do you want to achieve with the data? What should the AI deliver based on this data? In what form? Should it generate something complex?

Different types of AI make the difference

Depending on the objective and the amount of data available, it is important to find the right AI basis that should be selected for the procedure.

1. NLP (Natural Language Processing)

NLP is the abbreviation for Natural Language Processing and stands for the interaction of computers and human (“natural”) language, which they should be able to understand and interpret. Typical areas of application include text translations, text summaries or sentiment analysis based on spoken audio sequences.

2. machine learning

The aim of machine learning is to develop systems that learn from data. These systems are not explicitly programmed for a specific task, but are trained to recognize patterns and make decisions based on the data with which they have been trained. Machine learning includes various algorithms and models in which predictions are to be made taking into account many influencing factors, making recommendations based on previous behavior, in image recognition or, for example, for medical diagnoses.

3. deep learning

Deep learning is a sub-area of machine learning in which artificial neural networks with many layers (hence “deep”) are used to model complex patterns in data. Deep learning techniques are particularly powerful when processing large volumes of unstructured data such as images, sounds and text. This technology is behind many modern AI applications such as voice-controlled assistants, facial recognition systems and self-driving automobiles.

4 LLM (Large Language Models)

LLM stands for Large Language Model, which is a type of deep learning model developed specifically for understanding and generating natural language. These models are trained on large collections of text data and can generate coherent and in-context texts based on the input. They can take on more demanding tasks such as conducting a dialog in a specific context, generating code according to specific requirements or answering complex questions.

Start small, achieve big results

The point at which companies can successfully use AI applications is entirely individual. The best way for teams to get started is to select a specific area for implementation and carefully consider where they have a high level of overview knowledge and can narrow down the scope of what the AI should be able to achieve. The more defined the goal is, the more successful you will be with AI. A general solution for all possible tasks may seem promising at first, but will then be very unsatisfactory and have many shortcomings. Solutions that specifically address a problem and have enough data for training and can be thoroughly tested from the very beginning will provide support for employees and make companies more successful and efficient. Some applications will certainly be that efficient that they can indeed replace many jobs, but not all of them. After all, the aim is to increase efficiency. And artificial intelligence, contrary to its name, has no intelligence — it makes decisions mathematically. As soon as decisions have to be made with intelligence, humans are needed. This will not change in the future. AI models are only as good as the data and how they are trained and tested.

Generative artificial intelligence will completely change the way we work

Companies will and must experiment. What works and what doesn’t? What works but doesn’t make sense? What works, makes sense and ensures the company’s success? In the long run? Companies will have to develop their own customized AI solutions. This means that they will operate with their own data — taking into account data protection, security and, most importantly, company expertise on their own servers in order to make their processes, working methods and, finally, their core business more efficient. Securing the future of many companies will depend on this. This is because all market participants will try to do everything possible to gain a competitive advantage. Companies will offer their services and products with less effort and consequently in less time. We are moving towards a rapid development in competition. Those who are too late will be left behind.

If you want to have a chat about AI implementation in your company or are looking for specific services, write to us at ai@trendig.com or check out our engineering page.

KI oder (noch) nicht KI — Das aktuelle Dilemma der Unternehmensführung

Ki im Hier und Jetzt

Auch wenn es derzeit noch nach Hype aussieht: Die Thematisierung von künstlicher Intelligenz wird sich lange halten. Warum? Weil einige Unternehmen sehr zielgerichtet und sinnvoll und somit erfolgreich KI einsetzen und so das Potential haben werden, die Welt zu transformieren. Sie werden vorangehen und Künstliche Intelligenz wird dabei der Schlüssel zum Erfolg sein. Die Unternehmen können bei einigen Tätigkeiten schneller und dabei zu einem großen Teil effizienter werden. Das gesparte Geld erhöht den Gewinn und somit die Möglichkeiten der Investition in neue Projekte auf der einen und Ausschüttungen und Tantiemen für das beteiligte Personal auf der anderen Seite. Künstliche Intelligenz ist dabei vor allem ein Werkzeug, um die Effizienz an vielen verschiedenen Stellen zu steigern. Je nachdem, wie gut das Unternehmen bereits aufgestellt ist, werden diese Effizienzsteigerungen von Personalabbau begleitet oder unterstützen das bestehende Personal zu deutlicher Leistungssteigerung.

Im Folgenden möchte ich einen genaueren Blick auf einzelne Punkte richten, um eine andere Perspektive weg vom Hype hin zu einem planvollen Vorgehen einzunehmen:

KI ist ein Werkzeug, kein Wundermittel

Zunächst einmal vorweg: Künstliche Intelligenz ist ein Tool. Ein Werkzeug. Es kann perfekt eingesetzt werden, oder auch nicht. KI bedeutet nicht immer Erfolg und vor allem nicht immer Effizienz. Denn KI ist Software. Und das heißt, dass KI-Applikationen wie andere Software auch regelmäßig und zuverlässig gewartet werden müssen, um wunschgemäß zu funktionieren. Das wird in derzeitigen Einsatzszenarien oft nicht berücksichtigt, muss aber fester Bestandteil jeder Projektplanung sein.

Ohne saubere Daten geht nichts

Der Einsatz von KI bedarf Daten. Mal sind es mehr, mal sind es sehr sehr viele. Und diese Daten müssen zum einen vorhanden sein und zum anderen so aufbereitet werden, dass deren Einsatz Sinn macht, damit sie den Zwecken des Einsatzes der Künstlichen Intelligenz auch dienen. Die Daten müssen getaggt (markiert) werden und es muss unterschieden werden, welche Daten Trainingsdaten sind und welche Testdaten sind. Was will man mit den Daten erreichen? Was soll die KI anhand dieser Daten ausliefern? In welcher Form? Soll sie etwas aufwändig generieren?

Verschiedene Arten von KI machen den Unterschied

Abhängig von der Zielsetzung und von der zur Verfügung stehenden Datenmenge, gilt es die richtige KI-Basis zu finden, die für das Vorgehen ausgewählt werden soll.

1. NLP (Natural Language Processing)

NLP ist die Abkürzung für Natural Language Processing und steht für die Interaktion von Computern und menschlicher (“natürlicher”) Sprache, die sie verstehen und interpretieren können sollen. Typische Anwendungsgebiete sind z.B. Textübersetzungen, Textzusammenfassungen oder Stimmungsanalysen anhand von gesprochenen Audio-Sequenzen.

2. Maschinelles Lernen

Beim maschinellen Lernen sollen Systeme entwickelt werden, die aus Daten lernen. Diese Systeme werden nicht explizit für eine bestimmte Aufgabe programmiert, sondern sie werden darauf trainiert, Muster zu erkennen und Entscheidungen auf Grundlage der Daten zu treffen, mit denen sie trainiert wurden. Das maschinelle Lernen umfasst verschiedene Algorithmen und Modelle, bei denen Vorhersagen unter Berücksichtigung vieler beeinflussender Faktoren getroffen werden sollen, Empfehlungen aufgrund bisheriger Verhaltensweisen ausgesprochen werden, in der Bilderkennung oder z.B. für medizinische Diagnosen.

3. Deep Learning

Deep Learning ist ein Teilbereich des maschinellen Lernens, bei dem künstliche neuronale Netze mit vielen Schichten (daher “tief”) eingesetzt werden, um komplexe Muster in Daten zu modellieren. Deep Learning-Techniken sind besonders leistungsfähig bei der Verarbeitung großer Mengen unstrukturierter Daten wie Bildern, Tönen und Texten. Diese Technologie steckt hinter vielen modernen KI-Anwendungen wie sprachgesteuerten Assistenten, Gesichtserkennungssystemen und autonom fahrenden Fahrzeugen.

4. LLM (Large Language Models)

LLM steht für Large Language Model, das eine Art von Deep-Learning-Modell ist, das speziell für das Verstehen und Erzeugen natürlicher Sprache entwickelt wurde. Diese Modelle werden anhand umfangreicher Sammlungen von Textdaten trainiert und können so auf Grundlage der Eingaben zusammenhängende und kontextbezogene Texte erzeugen. Sie können anspruchsvollere Aufgaben übernehmen wie z.B. einen Dialog in einem bestimmten Kontext führen, Code nach bestimmten Anforderungen generieren oder komplexe Fragen beantworten.

Klein starten, Großes erreichen

An welcher Stelle Unternehmen KI-Applikationen erfolgreich einsetzen können, ist ganz individuell. Am besten starten Teams, indem sie sich einen spezifischen Bereich für den Einsatz auswählen und sorgfältig abwägen, an welcher Stelle sie ein hohes Überblickswissen haben und den Rahmen, was die KI leisten können soll, sehr gut einschränken können. Je definierter das Ziel ist, desto erfolgreicher wird man mit KI werden. Eine generelle Lösung für alle möglichen Aufgaben wirkt im ersten Moment vielversprechend, wird dann aber sehr enttäuschend sein und viele Unzulänglichkeiten aufweisen. Lösungen, die speziell ein Problem angehen und genügend Daten für das Trainieren vorweisen und von Anfang an tiefgreifend getestet werden können, werden Mitarbeiter entlasten und die Unternehmen erfolgreicher und effizienter werden lassen. Einige Applikationen werden sicherlich so effizient sein, dass sie in der Tat viele Arbeitsplätze ersetzen können, jedoch nicht alle. Ziel ist ja eine Effizienzsteigerung. Und Künstliche Intelligenz hat entgegen ihrer Namensgebung keine Intelligenz — sie entscheidet mathematisch. Sobald Entscheidungen mit Intelligenz getroffen werden müssen, braucht man den Menschen. Das wird sich auch in der Zukunft nicht ändern. KI-Modelle sind so gut, wie die Daten sind und wie sie trainiert und getestet werden.

Generative künstliche Intelligenz wird unsere Arbeitsweise komplett verändern

Unternehmen werden und müssen experimentieren. Was geht und was nicht? Was geht, aber ist nicht sinnvoll? Was geht, ist sinnvoll und sichert den Unternehmenserfolg? Langfristig? Unternehmen werden eigene, maßgeschneiderte KI-Lösungen entwickeln müssen. Das heißt, sie operieren mit eigenen Daten — unter Berücksichtigung von Datenschutz, Sicherheit und nicht zuletzt Unternehmensknowhow auf eigenen Servern, um ihre Prozesse, Arbeitsweisen und nicht zuletzt ihr Kerngeschäft effizienter zu gestalten. Die Zukunftssicherung wird bei vielen Unternehmen davon abhängig sein. Denn alle Marktteilnehmer werden das Mögliche auszuschöpfen versuchen, um einen Wettbewerbsvorteil zu erlangen. Unternehmen werden ihre Dienstleistungen und Produkte mit weniger Aufwand und demzufolge auch in kürzerer Zeit anbieten. Wir bewegen uns auf eine rasante Entwicklung im Wettbewerb zu. Wer zu spät kommt, wird den Anschluss verlieren.

Wenn Du über die KI-Implementierung in Deinem Unternehmen reden möchtest oder nach bestimmten Services suchst, dann schreib uns an ai@trendig.com oder schau auf unserer Engineering-Seite vorbei.

Als erfahrene Tester wissen wir alle, wie Äquivalenzklassen und Grenzwerte uns beim Testfalldesign helfen können. Insbesondere die Grenzwertanalyse (GWA) lenkt unsere Aufmerksamkeit auf Werte, die eine hohe Wahrscheinlichkeit haben, Fehler zu finden — Fehler, welche die Entwickler möglicherweise einfach durch die Verwendung des falschen relationalen Operators implementiert haben. Schauen wir uns das mal an:

Angenommen, wir möchten die Implementierung der folgenden Anforderung testen: “Wenn Sie 18 Jahre oder älter sind, können Sie bei uns eine Kfz-Versicherung abschließen”. Die Grenze liegt bei “Alter = 18”, also würden wir es mit 17 (wo wir erwarten, dass wir KEINE Kfz-Versicherung beantragen können) und 18 (wo wir erwarten, dass wir eine Kfz-Versicherung beantragen können) testen. Die folgende Tabelle fasst die Testfälle (TFs) für diesen Ansatz zusammen:

Der obige Ansatz (1) zeigt das erwartete Ergebnis bei korrekter Implementierung. Aber schauen wir uns auch mal an, wie die Ergebnisse für die beiden Testdaten-Werte 17 und 18 aussehen, wenn der Entwickler diese Entscheidung — fehlerhafterweise — mit einem falschen relationalen Operator umgesetzt hat:

Da TF (1) und (6) für die Eingabewerte 17 und 18 die gleichen Ergebnisse liefern, wird die fehlerhafte Implementierung (x = 18) nicht erkannt. Dazu bräuchten wir einen dritten Testfall, z.B. den Eingabewert 19. TF (1) gibt ein wahres, TF (6) ein falsches Ergebnis für den Eingabewert 19, so dass der falsche relationale Operator erkannt werden kann.

So weit, so gut. Deshalb testen wir Hochrisikoanwendungen mit DREI Werten pro Grenze, das wissen wir alle. Das ist nichts Neues, also wo ist der Haken?

der unterschied zwischen “abdeckungswerte pro grenze” und “abdeckungswerte pro grenzwert”

Schauen wir uns den ISTQB CTFL Syllabus 4.0 an, dort heißt es: “In der 3-Wert-Grenzwertanalyse gibt es für jeden Grenzwert drei Überdeckungselemente: den Grenzwert und seine beiden Nachbarn. […] Um bei der 3-Wert-Grenzwertanalyse eine 100%ige Überdeckung zu erreichen, müssen die Testfälle alle Überdeckungselemente, d. h. die identifizierten Grenzwerte und deren Nachbarn, ausführen.” Nun, in dieser neuen Version des ISTQB-Lehrplans (v4.0) ist explizit nicht von “drei Abdeckungswerten pro Grenze” die Rede, sondern von “drei Abdeckungswerten pro Grenzwert”. Und das ändert die Regeln deutlich:
Erinnere Dich, dass wir in der alten Definition der 3-Wert-GWA die Grenze von 18 mit DREI Überdeckungselementen getestet haben: 17, 18 und 19 (wie oben gezeigt). Jetzt aber müssen wir für die 3-Wert-GWA drei Überdeckungselemente pro Grenzwert verwenden. Die Grenzwerte im obigen Beispiel sind 17 und 18. Für den unteren Grenzwert von 17 sind daher die Überdeckungselemente 16, 17 und 18 und für den oberen Grenzwert von 18 sind die Überdeckungselemente 17, 18 und 19 (die Grenze und ihre Nachbarn). Deshalb gilt: Die korrekte Umsetzung der 3-Wert-GWA benötigt VIER Testfälle: 16, 17, 18 u. 19 !

Dieser Ansatz mit vier Überdeckungselementen pro Grenze hat einen weiteren Vorteil: Das Black-Box-Testfalldesign verwendet die Spezifikation (s.o.) als Testgrundlage, daher ist 18 die Grenze und 17 und 18 sind die Grenzwerte. Wir Tester wissen aber nicht, wie die Entwicklung diese Bedingung umgesetzt hat. Statt “wenn x >= 18, dann…” könnte sie es auch wie in TF (7) gezeigt umgesetzt haben: “wenn x > 17 dann…” — was funktional äquivalent ist. Bei Black-Box-Tests wissen wir nicht, welche Implementierung gewählt wurde. Schaue Dir vor diesem Hintergrund jetzt mal die folgende Tabelle an:

Wenn Du diese Implementierung mit dem alten 3-Wert-GWA-Ansatz testest, bei dem 17, 18 und 19 als implementierte Überdeckungselemente (7) verwendet werden, wird die falsche Kodierung in (12) nicht erkannt. Der überarbeitete Ansatz mit vier Überdeckungselementen (16, 17, 18, 19) zeigt jedoch den Fehler: Er ergibt 16/falsch für TF (7) und 16/wahr für TF (12).

Durch das Testen von Hochrisiko-Anwendungen mit vier statt drei Überdeckungselementen pro Grenze können Fehler erkannt werden, die sonst möglicherweise übersehen werden. Am Ende musst Du — als gut ausgebildeter und erfahrener Tester — eine Entscheidung treffen, welche Methode Du wählst. Dazu müssen viele Faktoren berücksichtigt werden, jetzt kennst Du einen weiteren.

Wenn Du mehr über die Testfallermittlung unter Zuhilfenahme von Grenzwerten erfahren möchtest (“Grenzwertanalyse”), dann besuche eine unserer ISTQB-Foundation-Level-Schulungen online oder in Deiner Wunsch-Stadt. Ab 2024 nach neuem ISTQB-Foundation-Level-Lehrplan Version 4.0.

As experienced testers we all know how equivalence classes and boundary values can help us with test case design. Especially boundary value analysis (BVA) directs our attention to values that usually have a high probability of finding defects, which developers might have implemented simply by using the wrong relational operator. Let’s investigate:

Assume we want to test the implementation of the following requirement: “If you are 18 years or older you can apply for car insurance with our company”. The boundary is at “year = 18”, so we would test it with 17 (where we expect NOT to be able to apply for car insurance) and 18 (where we expect to be able to apply for car insurance). You can summarize your test cases (TCs) for this approach in the following table:

The above approach (1) shows the expected result due to a correct implementation. However, let’s see what the results are for the two test values 17 and 18, if the developer has — by error — implemented the decision using a wrong relational operator:

Because TC (1) and (6) give the same results for the input values 17 and 18, the wrongful implementation (x = 18) will not be detected. We would need a third test case for this, e.g. input value 19. TC (1) gives a true, TC (6) a false output for the input value 19, so the wrong relational operator can be detected. So far so good, that’s why we test high risk applications with THREE values per boundary, we all know that. Nothing new here, so where is the catch?

the difference between “coverage values per boundary” and “coverage values per boundary value”

Let’s look at the ISTQB CTFL Syllabus 4.0: “In 3-value BVA, for each boundary value there are three coverage items: this boundary value and both its neighbors. […] To achieve 100% coverage with 3-value BVA, test cases must exercise all coverage items, i.e., identified boundary values and their neighbors.” Well, the new version of the ISTQB syllabus explicitly does not talk about “three coverage values per boundary”, it talks about “three coverage values per boundary VALUE”. And this changes the rules dramatically:

Remember, in the old definition of the 3-value-BVA we tested the boundary of 18 with THREE coverage items: 17, 18 and 19 (as shown above). But now we have to use for the 3-value-BVA three coverage items per boundary VALUE. The boundary VALUES in the above example are 17 and 18. Therefore for the lower boundary value of 17, the coverage items are 16, 17 and 18 and for the upper boundary value of 18 the coverage items are 17, 18 and 19 (the boundary and its neighbors). Therefore: For the correct implementation of 3-value-BVA we need FOUR test cases: 16, 17, 18 and 19!

This approach using four coverage items per boundary has a further advantage. Black box test case design uses the specification as a test basis, hence 18 is the boundary and 17 and 18 are the boundary values. But we testers do not know how the developer has implemented this condition. Instead of “if x >= 18 then…” she might have implemented it like shown in TCs (7): “if x > 17 then…” — which is functionally equivalent. Doing black box testing, we do not know which implementation was chosen. Now look at the following table:

Testing this implementation with the old 3-value-BVA approach, using 17, 18 and 19 as implemented coverage items (7) will not detect the false coding in (12). However, the revised approach using four test cases (16, 17, 18, 19) will show the defect:It results in 16/false for TCs (7) and 16/true for TCs (12).

Testing high risk applications with four coverage items per boundary instead of three can detect defects that might otherwise be overlooked. In the end, you — as a well-educated and experienced tester — have to make a decision, which method to choose. Lots of factors need to be considered for this, now you know one more.

If you would like to learn more about test case design with the help of boundary values (“boundary value analysis”), then attend one of our ISTQB Foundation Level training courses online or at your preferred location. From 2024 according to the new ISTQB Foundation Level syllabus version 4.0.