Security testing with TMAP

Software projects are often about new features, speed and user experience. But imagine this: you've built a beautiful app, everyone is excited, and then it happens. An unauthorized person gains access to sensitive data. Suddenly your reputation is gone, customers are angry, and your team is under fire. Welcome to the world of security. Or rather: the lack thereof.

schedule 19 aug 2025
bookmark_border TMap® Quality for cross-functional teams
create

What does security mean as a quality attribute within TMap?

Within TMap quality attributes, security simply means: how well is your system protected against unauthorized access, misuse, or changes that don't belong in it?

And that goes far beyond just “keeping hackers out”. Consider also:

  • a developer who accidentally gives the wrong permissions;
  • test data containing real personal data that ends up in production;
  • an API that is open without anyone noticing.

In other words, security isn't just about building walls, it's also about plugging all the little chinks and holes in your system.

Why is security so important in software projects?

Software or apps that aren't secure are practically unusable. Eéa leak can have huge consequences: fines (think AVG), reputation damage, or simply the loss of (trust from) your customers.

Why is security so important in software projects?

Software or apps that are not secure are practically unusable. A leak can have enormous consequences: fines (think AVG), damage to your reputation, or simply the loss of (trust from) your customers.

And especially in Agile and DevOps teams, where speed and collaboration are important, that risk is high. Everyone wants to release quickly, but if security is forgotten in the process, the damage later is often incalculable.

A poorly secured system:

  • makes you vulnerable to data breaches and hacks;
  • costs a tremendous amount of time and money in remediation;
  • increases dependence on specific security experts;
  • frustrates developers and administrators who have to “put out fires”.

In short: security is not an extra. It is the foundation on which you build.

  1. “The test data that was on the street”
    During a sprint, the decision was made to use real customer data in the test environment, “because that works the fastest”. Until someone discovered that this environment was accessible from the Internet. Consequence: sensitive data was up for grabs.
  2. “The forgotten admin”
    A developer once created an admin account to quickly fix something. Useful at the time, but no one deleted the account. Years later, it turned out that this account still allowed access to production.
  3. “The API everyone was allowed to use”
    A new mobile app had an API with no access restrictions. During a penetration test it turned out that anyone with a little knowledge could access and manipulate data.

Situations like this sound like “bad luck” but in reality they are signs that security has never been structurally tested.

How do you test security with TMap?

Within TMap, you test security by including targeted questions and scenarios’s in your testing approach:

  • Authentication: How do you verify that someone is really who they say they are?
  • Authorization: Does someone only have access to the functions and data intended for them?
  • Data shielding: Is sensitive data properly protected (encryption, masking, no real data in test environments)?
  • Logging and monitoring: Can you see and track suspicious activity?
  • Resilience: How does the system respond if someone tries to force it (e.g., by brute force or SQL injections)?

With TMap, you make security an explicit part of your testing criteria. That means that you not only look at “does it work,” but also: “does it continue to work safely, even if someone tries to push the limits,”

How does Testlearning help you do this?

At Testlearning, we know that security is not a luxury, but a must. That is why the quality attribute security is an integral part of our e-learning TMAP: Quality for Cross-Functional Teams.

In this training you will learn how you, as a tester, developer or product owner:

  • include security structurally in your test approach;
  • collaborate in Agile teams in order not to forget about security during fast releases;
  • risks’s in security become visible before it goes wrong.

And you will learn all this in a way that suits your working practice: interactive, practice-oriented and flexible to follow: wherever and whenever it suits you.

What you can do now

Stay still for a moment with the system you are working on today. Is it secure?

  • Are you sure that sensitive data does not end up in the wrong environment?
  • Are there no “hidden”accounts or unused access ports?
  • Are you structurally tested for security risks?

If you have any doubts about this, it is already a signal. Do you want to learn how to tackle this structurally? Then start today with our TMAP training. Because you don't arrange security only after an incident. You build it in from the beginning. Want to know more? Contact us!