DEV Community: Shoeib Shargo

🔐 Understanding Web Application Firewall (WAF) for Software QA Engineers

Shoeib Shargo — Mon, 21 Apr 2025 15:00:06 +0000

As QA engineers, we’re often caught in the middle of development and security teams — balancing feature delivery with risk mitigation. But when it comes to Web Application Firewalls (WAFs), many of us have only a surface-level understanding, often leaving testing gaps and friction with DevSecOps.

This article distills the key takeaways from a session I recently delivered internally, breaking down what WAFs are, how they work, and how QA can actively contribute to WAF integration and testing.

What Is a WAF — And Why Should QA Care?

A Web Application Firewall protects web applications from common threats like SQL Injection (SQLi), Cross-Site Scripting (XSS), and Broken Authentication. Unlike traditional firewalls that operate on lower network layers, a WAF works at Layer 7 (Application Layer) and analyzes HTTP/HTTPS traffic.

🔁 It acts as a reverse proxy — inspecting, filtering, and deciding whether to forward traffic to your web servers.

Think of it as a smart bouncer that not only checks IDs but also reads your body language.

Forward Proxy vs. Reverse Proxy — Quick Refresher

Example of Forward Proxy

In the above diagram, the client’s real IP (192.168.1.10) is hidden. Server sees the proxy’s IP (203.0.113.5) instead of the client’s. It’s used for anonymity, security, and content filtering (e.g., VPN, corporate proxies).

Example of Reverse Proxy
In the above diagram, server’s real IP (10.0.0.1) is hidden. Client only sees the reverse proxy’s IP (203.0.113.5). It’s used for security, load balancing, and caching (e.g., Nginx, Cloudflare, AWS ALB).

Key Differences

Forward Proxy: Client-side (client requests go through the proxy before reaching the internet).
Reverse Proxy: Server-side (client requests are directed to the proxy, which forwards them to backend servers).

Purpose of Web Application Firewall (WAF)

Protects applications from common web threats like SQL Injection, Cross-Site Scripting (XSS), and Broken Authentication.
Works at Layer 7 (Application Layer) of the OSI Model.
Acts as a reverse proxy, shielding backend servers from direct exposure.

How Does a WAF Work?
Traffic Inspection

Looks into request headers, bodies, cookies, and URLs
Detects anomalies and known malicious patterns
Rule-Based Decisions

Signature-based (blocklists)
Behavioral-based (AI/ML models for zero-day threats)
Response Handling

Blocks, challenges (CAPTCHA), or logs the request
Sends alerts for attack attempts

WAF in Action: Threat Examples
🛑 SQL Injection (SQLi)
Payload:

GET /search?query=' OR 1=1 -- HTTP/1.1
The WAF inspects the query string, recognizes the ' OR 1=1 injection pattern, and blocks it before it hits your database.

⚠️ Cross-Site Scripting (XSS)
Payload:

GET /profile?name=<script>alert('XSS')</script>
WAFs catch and block scripts embedded in inputs that could steal sessions or deface content.

Where QA Engineers Come In

1. Functional Testing — Preventing False Positives
Ensure the WAF does not break valid user actions:

Form submissions with special characters (<, {}, etc.)
OAuth or SSO login flows
File uploads, multi-step forms

2. Security Testing — Catching False Negatives
Ensure the WAF does block real threats:

Simulate XSS and SQLi attacks
Test API rate limiting
Verify payload filters for headers and cookies

3. Performance Testing — Is the WAF Slowing Us Down?

Compare API response times before/after WAF
Run load tests with concurrency and observe latency

4. Regression Testing — After WAF Deployment

Run automated suites to catch functionality breakage
Validate all 3rd-party service integrations and APIs

Final Thoughts
A WAF isn’t just a security checkbox — it affects the entire request lifecycle. As QA engineers, it’s on us to ensure it’s properly configured, doesn’t block real users, and effectively filters real threats. And if we want secure applications, we can’t leave that responsibility to just the security team — QA has a huge role to play.

Let me know what kind of WAF testing you’re doing, or drop a comment if you’ve seen false positives break a release. Follow for more QA + DevSecOps insights.

LinkedIn
GitHub

Tackling Complex Microservice Issues: Insights for QA Engineers

Shoeib Shargo — Sat, 19 Oct 2024 15:37:13 +0000

At its core, software testing is about validating the data flow from point A to point B, ensuring that information moves seamlessly and accurately through every component of a system. In the complex landscape of modern software development, this fundamental principle becomes increasingly challenging to uphold. As applications grow in complexity—embracing asynchronous operations, microservices architectures, third-party integrations, and AI-driven features—the pathways that data takes become more intricate, and the potential for issues escalates.

Understanding the CAP Theorem and Database ACID Compliance

Before diving into specific issues, it's essential to grasp foundational concepts like the CAP theorem and ACID compliance of databases. The CAP theorem states that in any distributed data system, you can only guarantee two out of three properties: Consistency (C), Availability (A), and Partition Tolerance (P). Understanding which properties your system prioritizes is crucial for designing appropriate tests, especially in microservices architectures where services may prioritize different aspects.

Additionally, knowing whether the databases used are ACID-compliant (Atomicity, Consistency, Isolation, Durability) is vital for certain parts of your application. However, not all databases need to be ACID-compliant. For example, databases like Redis and OpenSearch are not fully ACID-compliant, but they serve critical roles in caching, real-time analytics, and search functionalities where high performance and scalability are required.

As QA engineers, it's important to understand the characteristics of these non-ACID-compliant databases and how they affect data consistency and reliability. We need to design test strategies that account for these trade-offs. This includes testing for eventual consistency, handling data synchronization issues, and ensuring that the system behaves predictably under various conditions.

1. Race Condition and Cache Inconsistency Issues

Modern applications often rely on asynchronous operations, particularly in microservices architectures. While this design enhances scalability and performance, it introduces challenges in ensuring that dependent operations occur in the correct sequence. Race conditions can occur when multiple operations attempt to access or modify shared data simultaneously without proper synchronization, leading to unpredictable outcomes. Additionally, caching mechanisms, while improving performance, can introduce data consistency issues across distributed systems if not managed carefully.

Technical Complexity:

Asynchronous Operations: The asynchronous nature of microservices means services operate independently, and communication between them is often event-driven. Ensuring that events are processed in the correct order without causing delays or bottlenecks requires careful design.
Caching Mechanisms: Implementing distributed caching systems like Redis, can improve response times but keeping cached data synchronized across multiple instances or services adds complexity, particularly when data changes frequently.
Race Conditions: When two or more operations compete to access or modify shared data, the lack of proper synchronization can lead to unpredictable outcomes.

QA Thoughts and Insights:

Comprehensive Test Scenarios: Develop test cases that cover asynchronous operations and potential timing issues. Simulate scenarios where operations overlap to detect race conditions.
Eventual Consistency Testing: Validate how the system behaves when data is not immediately consistent. Ensure the application can handle slight delays in data propagation without adverse effects.
Monitoring and Logging: Request developers to implement detailed logging around the Service and data updates to trace the sequence of events. This aids in identifying the exact point of failure when issues arise.
Collaboration with Developers: Work closely with the development team to understand the data flow and dependencies. This collaboration can lead to more effective testing strategies that target potential weak points.

2. Issues from Integration with Third-Party APIs and Services

Always remember users do not care whether the intended data is coming from Third-party API or not. Problems arising from integrations with external services, such as APIs not handling edge cases, rate limits causing failures, or changes in third-party platforms affecting functionality should be handled gracefully within the application.

Technical Complexity:

External Dependencies: Relying on third-party services introduces variables outside the team's control, including API changes, downtime, or inconsistent responses.
Error Handling: Ensuring that the application gracefully handles errors from external services requires robust exception management and fallback mechanisms.
Data Mapping and Validation: Differences in data formats or unexpected data from external services can lead to failures if not properly validated and sanitized.

QA Thoughts and Insights:

Mock Services: Utilize mock servers to simulate third-party APIs, allowing testing of various responses, including errors and unexpected data.
Contract Testing: Upon discussing with developers if possible implement contract tests to ensure that the integration points adhere to expected interfaces and data formats. Tools like Pact can be your friend here.
Resilience Testing: Test how the application behaves under failure conditions, such as timeouts, rate limits, or invalid responses from external services.

3. Data Consistency and Synchronization Issue in Distributed Systems

Data inconsistencies can emerge when there are synchronization challenges among various services or databases. Such issues may lead to unreliable data representations and hinder effective decision-making for the user. In distributed systems, ensuring data consistency across multiple services and databases is complex, especially when using a combination of ACID-compliant and non-ACID-compliant databases.

Technical Complexity:

Distributed Systems: In microservices architectures, data is often distributed across multiple services, each with its own database or storage mechanism. Coordinating data changes across these services is complex.
Eventual Consistency Models: Some systems rely on eventual consistency, where data updates propagate over time rather than instantaneously, leading to temporary discrepancies. This is especially relevant when using non-ACID-compliant databases like OpenSearch.
Concurrency Issues: Simultaneous operations on the same data can result in conflicts or overwriting of information.
RDS Reader-Writer Delay: In relational databases like Amazon RDS using a read replica setup, there can be replication lag between the writer (primary) and the reader (replica). This delay means that data written to the primary database may not be immediately available on the replica database, leading to temporary inconsistencies in read operations.

QA Thoughts and Insights:

Data Consistency Tests: Design tests that verify data integrity across all modules and services after operations that modify data. This includes checking that data is consistent between primary and replica databases.
Latency Simulation: Introduce artificial delays in data propagation during testing to observe how the system handles stale data.
Conflict Resolution Strategies: Know the implemented logic from Developers to ensure that the Service has clear rules for resolving data conflicts, such as last-write-wins or merge strategies, and that these are tested thoroughly.
End-to-End Testing: Conduct end-to-end tests that cover complete user flows across multiple services. This helps identify issues that may not be apparent when testing services in isolation.

4. Performance Bottleneck Issues and Resource Management

Performance issues, such as slow searches, delays in execution, and timeouts during bulk operations, can significantly impact user satisfaction. They may lead to loss of revenue or customers if not addressed promptly.

Technical Complexity:

Resource Intensive Operations: Bulk data processing and complex queries can strain system resources, leading to slow performance or crashes. This is particularly relevant when using databases like OpenSearch for search functionalities.
Inefficient Algorithms: Suboptimal code can significantly impact performance, especially as data volumes grow. Algorithms with poor time complexity can become bottlenecks.
Scalability Limitations: Systems not designed with scalability in mind may perform well under low load but degrade rapidly as usage increases.

QA Thoughts and Insights:

Performance Testing: Implement load testing on business-critical Services to evaluate how the system performs under various levels of stress and identify bottlenecks.
Regression Analysis: Ensure that new code changes do not negatively impact performance by comparing metrics before and after changes. Incorporate performance benchmarks into the CI/CD pipeline.
Scalability Planning: Invoke a discussion with DevOps and Developers to encourage architectural designs that support horizontal scaling and efficient resource utilization. Validate that the system can scale out to handle increased loads without degradation.

5. Issues in AI Enabled Features

A newly added concern for QA is the behavior of AI-implemented features. Issues like irrelevant responses from AI or their inability to process certain inputs reveal problems that can cause user frustration and diminish trust in AI capabilities.

Technical Complexity:

Input Validation: The system may lack robust input validation, allowing malformed data to be processed by the AI model.
Model Limitations: The AI model may not be fine-tuned to handle or filter out irrelevant inputs effectively.
Resource Constraints: The AI processing pipeline may suffer from timeouts due to insufficient computational resources allocated for processing complex inputs.

QA Thoughts and Insights:

AI Testing Strategies: Develop specialized testing methods for AI features, including validation datasets that cover a wide range of inputs i.e. challenging or malicious data to evaluate how the AI system handles unexpected inputs.
User Simulation: Use real-world data to simulate how users interact with AI features, identifying gaps in understanding or performance.
Ensure Clear Error Handling: When the AI system cannot process an input or is unsure of a response, make sure it handles the situation gracefully.

Conclusion:

Addressing complex software issues requires a deep understanding of technical challenges and a proactive approach to testing. As QA engineers, we must develop comprehensive testing strategies that consider the intricacies of modern applications. By collaborating closely with development teams, implementing robust testing methodologies, and focusing on both technical and user experience aspects, we can help build more reliable, efficient, and user-friendly software systems.

Standard Naming Convention for UI Elements to Use with Selenium Locators

Shoeib Shargo — Fri, 16 Sep 2022 21:42:57 +0000

How many of you have put your Thinking Cap on before writing a variable name? Well, I certainly do more often than not. If you are working on a big project, sometimes it becomes a tedious job to correct variable naming conventions among the team members.

In the case of UI test automation using Selenium or any other tools for that matter, it becomes way more complex to decide variable names for different web elements. Enough with the talks, let’s show you the chart that will help you distinguish between varieties of web elements and keep your sanity in check.

@FindBy(xpath = ".//*[@id='lastName']") public WebElement loc_txtLastName;

Thank you for reading so far. Hope it was helpful in some way. Nonetheless, I will keep writing such articles based on my experience and knowledge that may help you with the day-to-day tasks as a Test Automation Engineer. Stay connected!

Selenium Parallel testing using Java ThreadLocal and TestNG

Shoeib Shargo — Fri, 10 Jun 2022 13:22:41 +0000

No, writing just parallel = “tests” & thread-count =”2" in your testng.xml file won’t cut it. That is because Selenium WebDriver is not thread-safe by default. In a non-multithreaded environment, we keep our WebDriver reference static to make it thread-safe. But the problem occurs when we try to achieve parallel execution of our tests within the framework. Every thread you create to parallelize your tests tries to overwrite the WebDriver reference since there could be only one instance of static WebDriver reference.

To overcome this problem, we can take help from the ThreadLocal class of Java. Wondering what is ThreadLocal? Simply put, it enables you to create a generic/ThreadLocal type of object which can only be read and written (via its get and set method) by the same thread, so if two threads are trying to read and write a ThreadLocal object concurrently, one thread would not see the modification of the ThreadLocal object done by the other thread, thus, making the thread-local object thread-safe.

A typical thread-local object is made private static and its class provides initialValue, get, set, and remove methods. The following example shows how you can create a Generic type thread-local object

//create a generic thread-local object
private static ThreadLocal<String> myThreadLocal = new ThreadLocal<String>();
//set thread-local value
myThreadLocal.set("Hello ThreadLocal");
//get thread-local value
String threadLocalValue = myThreadLocal.get();
//remove thread-local value for the current thread
myTheadlocal.remove();

Now that we have seen how ThreadLocal works, we can go ahead and implement it in our Selenium framework making the WebDriver session exclusive to each thread. Let’s create a BroweserManager class to manage the WebDriver instance alongside browsers.

public class BrowserManager {

   public static WebDriver doBrowserSetup(String browserName){
        WebDriver driver = null;
        if (browserName.equalsIgnoreCase("chrome")){
            //steup chrome browser
            WebDriverManager.chromedriver().setup();
            //Add options for --headed or --headless browserlaunch
            ChromeOptions chromeOptions = new ChromeOptions();
            chromeOptions.addArguments("-headed");

            //initialize driver for chrome
            driver = new ChromeDriver(chromeOptions);
            //maximize window
            driver.manage().window().maximize();
            //add implicit timeout
            driver.manage()
           .timeouts()
           .implicitlyWait(Duration.ofSeconds(30));
        }
   return driver;
}

After that, it’s time to create our BaseTest class where we will create a static WebDriver as a ThreadLocal and then set the driver to its object which will be accessible throughout the test with the help of our BrowserManager class.

public class BaseTest {
    protected static 
    ThreadLocal<WebDriver> threadLocalDriver = new ThreadLocal<>();
    @BeforeTest
    public void Setup(){
        WebDriver driver = BrowserManager.doBrowserSetup("chrome");
        //set driver
        threadLocalDriver.set(driver);
        System.out.println("Before Test Thread ID: "+Thread.currentThread().getId());
        //get URL
        getDriver().get("https://www.linkedin.com/");
    }
    //get thread-safe driver
    public static WebDriver getDriver(){
        return threadLocalDriver.get();
    }
    @AfterTest
    public void tearDown(){
        getDriver().quit();
        System.out.println("After Test Thread ID: "+Thread.currentThread().getId());
        threadLocalDriver.remove();
    }
}

Inside @BeforeTest annotation we have called the doBrowserSetup() static method from BrowserManager class which returned a WebDriver reference with ChromeDriver initialized in it. Then we have set the returned WebDriver reference in our threadLocalDriver object. Now that our threadLocalDriver is set making the WebDriver reference thread-safe, we can use it across the test framework.

Inside @AfterTest annotation we are just quitting the browser and then removing the current thread’s value (in this case, returned WebDriver reference from the doBrowserSetup() static method) from the threadLocalDriver object.

Let’s complete the test by adding Test classes to it. We will run a login test on a demo site.

package Pages;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.WebElement;
import org.openqa.selenium.support.FindBy;
import org.openqa.selenium.support.PageFactory;
public class Login {
    WebDriver driver;
    @FindBy(className = "login")
    WebElement linkLogin;
    @FindBy(id = "email")
    WebElement txtEmail;
    @FindBy(id = "passwd")
    WebElement txtPassword;
    @FindBy(id = "SubmitLogin")
    WebElement btnSignIn;
    @FindBy(xpath = "//span[contains(text(),'viva test')]")
    WebElement lblUserName;
    @FindBy(xpath = "//li[contains(text(),'Invalid email address.')]")
    WebElement lblInvalidEmail;
    @FindBy(xpath = "//li[contains(text(),'Authentication failed.')]")
    WebElement lblInvalidPassword;
    public Login(WebDriver driver){
        this.driver = driver;
        PageFactory.initElements(driver, this);
    }
    //valid email and valid password
    public String doLogin(String email, String password){
        linkLogin.click();
        txtEmail.sendKeys(email);
        txtPassword.sendKeys(password);
        btnSignIn.click();
        return lblUserName.getText();
    }
    //Invalid email
    public String loginWithInvalidPassword(String email, String password){
        linkLogin.click();
        txtEmail.sendKeys(email);
        txtPassword.sendKeys(password);
        btnSignIn.click();
        return lblInvalidPassword.getText();
    }

}

Now create a test class based on the above class i.e. LoginTestRunner1.

package TestRunners;
import Base.BaseTest;
import Pages.Login;
import Utils.BrowserManager;
import Utils.JsonReader;
import org.json.simple.parser.ParseException;
import org.testng.Assert;
import org.testng.annotations.Test;
import java.io.IOException;
public class LoginTestRunner1 extends BaseTest {
    @Test
    public void loginTest() throws IOException, ParseException {
        getDriver().get("http://automationpractice.com/");
        Login login = new Login(getDriver());
        //valid email and valid password
        String user = login.doLogin("test_viva@test.com", "123456");
        Assert.assertEquals(user, "viva test");
    }
}

Create LoginTestRunner2 class:

package TestRunners;
import Base.BaseTest;
import Pages.Login;
import Utils.BrowserManager;
import Utils.JsonReader;
import org.json.simple.parser.ParseException;
import org.testng.Assert;
import org.testng.annotations.Test;
import java.io.IOException;
public class LoginTestRunner2 extends BaseTest {
    @Test
    public void loginWithInvalidEmailTest() throws IOException, ParseException {

        getDriver().get("http://automationpractice.com/");
        Login login = new Login(getDriver());
        //invalid email and valid pass
        String lblInvalidEmail = login.loginWithInvalidEmail("viva@te.com", "123456");
        Assert.assertEquals(lblInvalidEmail, "Authentication failed.");
    }
}

Finally, let’s write parallel = “tests” & thread-count =”2" in our testng.xml file.

<!DOCTYPE suite SYSTEM "https://testng.org/testng-1.0.dtd"> 
<suite  verbose="1" name="E-commerce portal automation" parallel="tests" thread-count="2" >
    <test name="invalid email login" >
        <classes>
            <class name="TestRunners.LoginTestRunner2"/>
        </classes>
    </test>
    <test name="valid email login">
        <classes>
            <class name="TestRunners.LoginTestRunner"/>
        </classes>
    </test>
</suite>

Now run the test. See the output below:

Before Test Thread ID: 15
Before Test Thread ID: 14
After Test Thread ID: 15
After Test Thread ID: 14
BUILD SUCCESSFUL in 48s
4 actionable tasks: 4 executed

That’s it. WebDriver instance has now become thread-safe, and as the output shows it is being used by the multiple threads concurrently thanks to ThreadLocal class.

Don't just learn it, do it!

Shoeib Shargo — Sat, 26 Mar 2022 07:27:29 +0000

As they say, you can't learn to swim by just watching. I guess it stands true for building a Test automation framework from the scratch as well. No matter how many tutorials you watch online until you get your hands dirty with codes, you have not truly grasped it.

In my current company, I have been assigned to a project to build an automation framework from the scratch in addition to being vigilant manually. Rookie myself was drowned in watching tutorials which led me nowhere because I was still fearful of making mistakes.

Once I let go of that feeling and started writing codes, everything came naturally to me. Well of course all the knowledge that I had gathered watching tutorials and reading blog articles was helping me subconsciously.

Yes, I have made mistakes along the way but to err is human. The more you progress in building an automation framework, the more you know what should you do to make your tests less flaky. I will share the key things that you should keep in mind while building an automation framework soon.

The lesson being; don't just learn it, do it.