In the previous post, we looked at how many users to inject and when. Today we tackle a different problem. If every one of those users logs in with the same username, or adds the exact same product to their cart, you are not really testing realistic load. You are testing one specific code path over and over. Feeders solve this by handing each virtual user its own piece of data before it runs through the scenario. ...

In the previous post, we built a proper chained scenario and separated it cleanly from load setup. Today we focus entirely on that load setup, because how you inject virtual users into a scenario has a huge effect on what your test actually measures. A lot of people new to Gatling reach for atOnceUsers and stop there. It has its place, but it does not represent how real traffic behaves, and using it for everything will give you misleading results. ...

In the previous post, we got a bare bones Gatling project running with a single request. That is enough to prove your setup works, but it is nowhere near what a real load test looks like. Today we build something closer to reality, a scenario with several requests chained together, and we talk properly about how the Java DSL fits together. How the DSL Reads Gatling’s Java DSL is built to be read almost like a script, top to bottom. Once you get used to the shape of it, most of what you write ends up looking like a sentence describing user behavior. The three static imports you will use constantly are these. ...

Performance testing has a reputation for being complicated to get into. Heavy tools, confusing scripting languages, a steep learning curve before you even run your first load test. Gatling is one of the tools that actually breaks that pattern, especially now that it has a proper Java DSL. If you already write Java for a living, you can be productive in Gatling within a day. This is the first post in a twelve part series on building a real performance testing framework with Gatling and Java. We start right at the beginning, with project setup, and build up from there. ...

The Hype: Jason Huggins Just Announced Vibium, and Browser Automation Will Never Be the Same If you’ve spent any time in the software testing space over the last two decades, you know the name Jason Huggins. He’s the guy who created Selenium back in 2004, basically founding modern web test automation, and later gave us Appium for mobile. So when Jason Huggins drops a new open-source project, the entire testing community stops what it’s doing and looks up. ...

Running huge regression suites every time I push a small change to a repo is super inefficient and slow, especially as projects start growing and getting complex. Lately, I’ve been diving deep into AI-Driven Risk-Based Selection to make my testing workflow fast, targeted, and lean. Smarter Builds with Risk-Based Selection Instead of blindly firing off every single test on every commit, I’ve been tinkering with a script that inspects the exact files changed in a Git diff. The script parses the modified code, maps out the underlying dependencies, and picks only the top 15% or so of tests that are actually affected by those changes. ...

In the previous post, ZAP gave us automated coverage against a running API, probing for common vulnerability patterns in requests and responses. There is an entire category of risk that scan never touches, because it does not live in API behavior at all. It lives in what dependencies a service pulls in, and what a commit accidentally includes. This closing post in the OWASP series covers both. Why Dependency Scanning Is Its Own Category Every Spring Boot service pulls in dozens, often hundreds, of transitive dependencies, and any one of them can have a known vulnerability disclosed after you first added it. A service can pass every API test and every ZAP scan cleanly while still shipping a logging library with a critical, publicly known remote code execution flaw. Nothing about API level testing catches this, because the vulnerability is not in your code’s behavior, it is in a jar sitting in your classpath. ...

The last two posts covered specific, hand written test cases for BOLA, broken authentication, and excessive data exposure. Those tests are precise and fast, but they only catch what you thought to write a test for. OWASP ZAP, the Zed Attack Proxy, takes a different approach, actively probing an API for a much broader set of known vulnerability patterns automatically. This post covers wiring it into a pipeline as a regression gate, and just as importantly, how to keep it from becoming noise nobody reads. ...

In the previous post, we focused entirely on BOLA and object ownership checks. This post covers two more categories from the OWASP API Security Top 10 that tend to show up together in practice, broken authentication and excessive data exposure. Both are less about a single missing check and more about a general habit of trusting the client too much. Broken Authentication: Token Expiry A surprising number of APIs issue tokens correctly but never quite get around to enforcing their expiry properly. Testing this directly is simple once you have a way to generate an expired token. ...

In the previous post, we walked through why the OWASP API Security Top 10 deserves attention from a QE team directly, not just a security specialist. Broken Object Level Authorization sits at the top of that list, and for good reason. It is one of the easiest vulnerabilities to introduce by accident, and one of the easiest to test for once you know to look. What BOLA Actually Is BOLA happens when an API checks that a user is authenticated, but does not check that the authenticated user is actually allowed to access the specific object they are requesting. The classic example, a transaction history endpoint. ...