Levels of Automation Excellence

 How effective is your automation test suite?

How impactful is it for your product and your team?
Do you know how to grow your test suite without sacrificing quality and performance?

These questions are surprisingly difficult to answer — especially when your entire suite feels like it’s constantly on fire, your tests are untrustworthy, and production bugs are popping up like they’re going out of style. (Just me?)

To bring some clarity — and because testers love pyramids — I created the Automation Maturity Pyramid as a way to measure automation impact.

First, let’s remember why we write automation tests in the first place. At the end-of-the-day, automation tests should support two simple missions:

• Increase product quality & confidence
• Accelerate development & deployment

So when we think about the pyramid and its phases, everything we do should ultimately align with those missions.

The pyramid has four levels of maturity:

1. Confidence — Trusting your test results.
2. Short-Term Impact — Creating value in daily development.
3. Speed of Development — Scaling automation without slowing down.
4. Long-Term Impact — Sustaining trust, visibility, and continuous improvement.

Each phase builds on the one below it. Later stages only unlock their benefits once the initial foundation is solid. The pyramid is both tool and type agnostic, meaning you can apply it to any automation suite, framework, or testing type that fits your needs.

Remember, this journey takes time. Think of the pyramid as a compass, not a checklist to rush through. If you’re starting fresh, it’ll guide you from the beginning. If you already have a suite, it’s a framework to measure current impact and decide what to tackle next.

Phase 1 — Confidence

A pyramid collapses without a strong base. The same is true with automation. If teams don’t trust the test failures (or even successes), everything else becomes meaningless.

When results are unreliable, people stop acting on them. And when tests are ignored, automation loses its purpose. In many ways, unreliable automation is often worse than not having any at all.

The Tests Must Pass

Failures will happen. That’s not the issue. The danger is when teams normalize broken tests or flaky failures. Every red test should be taken seriously: investigated, understood, and resolved. While there are exceptions, the default culture must be: stop and fix. Adopt the mindset “all tests must pass”, and technical debt will quickly diminish before it starts. A mature automation test suite starts with an accountable mindset.

What Undermines Confidence

• Flakiness: Tests that pass or fail inconsistently without code changes. Common causes include race-condition, non-deterministic app behavior, dependent tests or poor test data management.
• Environment Instability: Where you will run your tests matter, especially if multiple options are needed. Can you guarantee tests will run reliably across all environments?
• Weak Data Strategies: Do tests always have the data they need? Is it static or dynamic? A strong data strategy reduces countless downstream failures. My favorite data management is through programmatic control.

Phase 1 is about establishing trust. Once failures are credible and environments stable, your suite stops being noise and starts being a safety net. A small, confident test suite is more impactful than a large, unstable one. Some actions items to consider:

• Research and implement flake-reduction practices for your tool of choice
• Create a culture of accountability: quarantine flaky tests and resolve them quickly
• Write tests environment-agnostically
• Define a consistent test data strategy that works across environments

If you’ve done these, you’re ready for Phase 2.

Phase 2 — Short-Term Impact

With trust established, the next step is to make automation useful right now. Tests should provide fast feedback and reduce risk during daily development.

If tests only run occasionally or if results arrive too late to act on, they don’t influence decision-making. The goal is to make automation an indispensable partner for developers, not a background chore.

This phase is all about defining an initial CI/CD strategy that suites your team’s development processes.

CI/CD Strategy

A good rule: the closer tests run to code changes, the more valuable they are. Running suites pre-merge ensures failures tie directly to specific commits, not multiple layers of changes. Fewer variables mean quicker triage.

Nightly or scheduled runs still have a place — especially for full regressions, but the longer the gap between code and results, the harder it is to debug.

Some common strategies:

• Pre-merge Tests: Run in under ~10 minutes. Cover critical paths first, then expand with performance in mind.
• Full Nightly Regression: Capture broader coverage where speed isn’t urgent.
• Custom Tag-Based Gates: Sub-groups of tests run based on criteria.

Results Visibility

Running tests is meaningless if no one notices the outcomes. Ensure results are clear, fast, and shared.

Every suite should generate artifacts accessible to all engineers. This includes screenshots, video, error logs and any other additional test information. Without proper artifacts, debugging failures becomes exponentially harder. Additionally, notifications should be immediate and integrated into tools your teams already use.

A professional rule of mine— act like Veruca Salt from Willy Wonka:
“I want those results and I want them now!”

Remember, Phase 2 is about usefulness. Once tests deliver fast, actionable feedback, they directly help teams ship better code, quicker. Developers know within minutes when a real-bug is introduced. Testers know when flake is first introduced, for immediate remediation.

Stick to the mantra: “all tests must pass”.

Once you start getting short-term feedback from your tests, it’s time to optimize them.

Phase 3 — Speed of Development

Once automation is trusted and embedded in the workflow, the focus shifts to efficiency. The question becomes: how can automation help us move faster without cutting corners?

At small scale, almost any automation adds value. But as suites grow, inefficiency turns automation into a bottleneck. Tests that take hours to run or are painful to debug become blockers instead of enablers. This phase has three areas of focus: writing, debugging and executing tests.

Write Tests Faster

Writing tests faster primarily comes down to test organization and structure. Expanding further:

• Standardize Structure: Use any pattern that makes sense to you and don’t worry about perfection. Any organization beats spaghetti-code chaos. Optimize over-time.
• Reuse Aggressively: Create helpers, builders, and shared libraries for scaleability.
• Proactive Test Planning: Review product tickets early to avoid last-minute gaps.
• Use AI-assisted Tooling: Just do it. There’s no excuse not to use AI anymore. Embrace our new overlords!
• Document: Look, we all know it sucks…but providing guides and common gotchas reduce ramp-up time as the team grows. What would past you wish they had when they first onboarded?

Debug Tests Faster

Test failures will happen so response time makes or breaks a suite’s value.

• Prioritize Readability: Choose clarity over cleverness; smaller, focused tests are easier to diagnose. Always write tests with future you in mind. “Will this make sense to me in six months?”.
• Reduce Variables: Run tests as close to the change as possible (prioritize pre-merge if not already implemented).
• Culture of Accountability: Build a habit of immediate triage: treat all fails with the same urgency so at least some resolution occurs.
• Improved Artifact Tools: Interactive runners, browser devtools, and in-depth logs are gold. Improve artifacts as needed.

Run Tests Faster

This one is simple. How fast do our tests run? Repeat after me: “Nobody brags about a three-hour test suite”. As the test suite grows, will the team still get quick value without slowing down the process?

• Parallelize: Split suites across multiple machines or containers. A must for pre-merge pipelines.
• Subset Tests: Run critical paths first; save broader regressions for later. Customize based on need and overall test performance.
• Optimize Code: Remove hard-coded waits, reduce unnecessary DOM interactions, apply tool best practices.

Phase 3 is about efficiency. Automation should accelerate delivery, not drag it down. When done well, it enables rapid iteration and frequent, confident releases. All of a sudden our monthly releases can now be reduced to weekly. Then daily. Then maybe even multiple times a day, if you’re feeling extra daring. All thanks to your automation test suite.

You deserve a raise.

Phase 4 — Long-Term Impact

The final phase is about sustainability. Once automation is fast, useful, and trusted, it must also deliver long-term value.

Teams and products evolve. Without continuous investment, automation rots: tests get flaky, results get ignored, and the pyramid crumbles. Which is all super sad. Professional advice, don’t be sad.

Long-term impact ensures automation remains a source of truth while showcasing just how cool your team is.

Metrics Inform, Not Punish

This phase is purely about responding to metrics, but use them wisely. Metrics should guide investment, not assign blame. Focus on impactful metrics that guide your automation roadmap. Simply, you don’t know what to improve if you don’t know what’s ineffective.

Some Suggestions:

• Test Coverage: Directional, not definitive. Pair with quality checks.
• Pass/fail and flake rates: Indicators of credibility.
• Execution time: Is the suite scaling with the team?
• Time-to-resolution (TTR): How quickly do teams fix failures?
• Defect detection efficiency (DDE): Percentage of bugs caught by automation.

If possible, consider augmenting these with a dashboard where visibility is further increased. Visual trends make it easier to consume historical trends and identify weaknesses. Plus bar graphs are fun and line graphs always look convincing. Don’t even threaten me with a good time and bring up pie charts.

This phase is small but important. It’s the culmination of all the previous phases, and purely intended to bring visibility into how well things went in the previous phases. It drives future revisions and ensures the test suite is never stagnant in it’s impact.

Phase 4 is all about trust at scale. Mature automation creates transparency, informs investment, and continues to improve over time.

Putting It All Together

The Automation Maturity Pyramid is a lot smaller than the Pyramids of Giza but much more relatable since those are real and in Egypt and this is thought-leadership and about testing. Just to clarify any confusion to this point.

But seriously, it’s about measuring your impact, one phase at a time. Building a successful automation test suite is hard without proper guidance. There’s many technical steps and failures can quickly become overwhelming and frustrating.

To recap:

• Confidence First: You have to trust your tests, always. The rest will follow.
• Early Wins: No matter the test suite size, obtain value. Start catching real issues.
• Take small steps: Steady improvements compound into big gains. Efficiency is a learning curve and only obtained through experience.
• Welcome Failures: Hello failures, come on it. Have a seat. Let’s talk about how you’re making my current life bad so we can make my future life good.
• Celebrate Progress: Building a reliable, impactful suite is a team achievement. Be proud of that green test run, those first 100 tests, or the first real-bug your suite caught. You’re a rockstar, genuinely.

Done well, automation isn’t overhead — it’s a strategic advantage. Build a base of trust, create fast feedback loops, optimize for speed, and commit to long-term transparency. That’s how you turn test automation into a driver of product success.

Best of luck in your climb. And as always, happy testing.

Handling Large Payloads in RestAssured: Best Practices and Examples

Introduction

When testing APIs with RestAssured, it's common to encounter scenarios that require sending large JSON or XML payloads. This is particularly relevant for bulk data uploads, complex configurations, or nested objects. If not handled effectively, large payloads can lead to code clutter, memory inefficiency, and maintenance challenges.

This blog outlines the common challenges and provides best practices to manage large payloads efficiently in RestAssured.

Challenges with Large Payloads

• Code Readability: Hardcoding large payloads directly in test methods makes code messy and difficult to maintain.

• Maintainability: Any change in the payload requires updates to the test code and possible redeployments.

• Performance: Large payloads can increase memory usage and slow down test execution if not optimized.

• Validation Complexity: Verifying large responses requires structured and scalable approaches.

Best Practices to Handle Large Payloads in RestAssured

1. Externalize Payloads in Files
Store payloads in separate files (e.g., .json or .xml) and load them at runtime.

• Advantages: Cleaner code, easy updates, and version control.

Example:

import io.restassured.RestAssured;

import java.nio.file.Files;

import java.nio.file.Paths;

public class LargePayloadTest {

    public static void main(String[] args) throws Exception {

        String jsonBody = new String(Files.readAllBytes(Paths.get("src/test/resources/largePayload.json")));

        RestAssured.given()

            .header("Content-Type", "application/json")

            .body(jsonBody)

            .when()

            .post("https://api.example.com/upload")

            .then()

            .statusCode(200);

    }

}

2. Use POJOs with Serialization
Represent payloads as Java objects and let RestAssured serialize them using Jackson or Gson.

• Advantages: Strong typing, compile-time checks, and easy field modifications.

Example:

class Employee {

    public String name;

    public int age;

    public List<String> skills;

}

Employee emp = new Employee();

emp.name = "John";

emp.age = 35;

emp.skills = Arrays.asList("Java", "Selenium", "RestAssured");

RestAssured.given()

    .contentType("application/json")

    .body(emp)

    .post("/employees")

    .then()

    .statusCode(201);

3. Use Template Engines for Dynamic Payloads
When most of the payload remains static but some fields change, template engines or simple string replacements work well.

• Tools: Apache Velocity, FreeMarker, or String.format().

Example:

String template = new String(Files.readAllBytes(Paths.get("template.json")));

String payload = template.replace("${username}", "john.doe")

                         .replace("${email}", "john@example.com");

4. Compress Large Payloads (If Supported)
If your API supports compression, use GZIP to reduce payload size and network latency.

Example:

RestAssured.given()

    .contentType("application/json")

    .header("Content-Encoding", "gzip")

    .body(CompressedUtils.gzip(jsonBody))

    .post("/bulkUpload");

5. Streaming Large Files
Avoid loading entire files into memory by streaming them directly during uploads.

Example:

File largeFile = new File("largeData.json");

RestAssured.given()

    .multiPart("file", largeFile)

    .post("/upload")

    .then()

    .statusCode(200);

When to Choose Which Approach

• Use external files for static or semi-static payloads.

• Use POJOs for strongly typed, programmatically generated data.

• Use templates for partially dynamic payloads.

• Use compression or streaming for very large payloads.

Summary
To handle large payloads in RestAssured efficiently:

• Avoid hardcoding payloads.

• Externalize or serialize data for cleaner, maintainable code.

• Use templates for flexibility and compression or streaming for very large files.

• Choose the right approach based on payload type and test goals.

🔍 Tools and Technologies I Use for Digital Forensics Investigations

Digital forensics plays a critical role in modern cybersecurity — whether it’s responding to a data breach, investigating insider threats, or performing incident analysis after suspicious behavior. In my work as a security-minded engineer and DevSecOps practitioner, I’ve frequently had to identify, collect, and analyze digital evidence across endpoints, servers, and cloud environments.

In this blog post, I’ll walk you through the tools and technologies I rely on to conduct effective digital forensics investigations — categorized by use case.

---

🧠 What Is Digital Forensics?

At its core, digital forensics is about identifying, preserving, analyzing, and reporting on digital data in a way that’s legally sound and technically accurate. The goal is to reconstruct events, identify malicious activity, and support security incident response.

---

🧰 My Go-To Tools for Digital Forensics Investigations

---

🗂️ Disk & File System Analysis

These tools help examine hard drives, deleted files, system metadata, and more:

• Autopsy (The Sleuth Kit) – A GUI-based forensic suite for analyzing disk images, file recovery, and timelines.

• FTK Imager – For creating and previewing forensic images without altering the original evidence.

• dd / dc3dd – Command-line tools to create low-level forensic disk images in Linux environments.

• EnCase (Basic familiarity) – A commercial powerhouse in forensic investigations, used primarily for legal-grade evidence analysis.

---

🧬 Memory Forensics

Memory (RAM) often holds short-lived but critical evidence, like injected malware, live sessions, or loaded processes.

• Volatility Framework – Extracts details like running processes, DLLs, command history, network activity, and more from memory dumps.

• Rekall – An alternative memory analysis framework focused on automation and deep system state inspection.

✅ I’ve used Volatility to trace injected PowerShell payloads and enumerate hidden processes in live incident simulations.

---

🌐 Network Forensics

Capturing and analyzing network traffic is essential for spotting data exfiltration, command-and-control activity, or lateral movement.

• Wireshark – Industry standard for packet analysis and protocol dissection.

• tcpdump – Lightweight CLI tool to capture traffic in headless environments or remote systems.

• NetworkMiner – Parses PCAP files to extract files, sessions, and credentials automatically.

---

📊 Log & Timeline Analysis

Understanding what happened — and when — is key to reconstructing incidents.

• Timesketch – A timeline analysis tool for visualizing and collaborating on event data.

• Log2Timeline (Plaso) – Converts log files, browser histories, and system events into structured timelines.

• Sysinternals Suite – Includes gems like Procmon, PsExec, and Autoruns for Windows incident response.

---

🧪 Malware Analysis (Static & Dynamic)

Understanding what a file does — before or while it runs — helps detect advanced threats and APT tools.

• Ghidra – Powerful open-source reverse engineering tool from the NSA for analyzing executables.

• x64dbg / OllyDbg – Popular debuggers for inspecting Windows executables.

• Hybrid Analysis / VirusTotal – Cloud-based tools to scan files and observe sandbox behavior.

• Cuckoo Sandbox – An open-source automated sandbox for observing malware behavior in a VM.

---

☁️ Cloud & Endpoint Forensics

Modern investigations often span cloud platforms and remote endpoints:

• AWS CloudTrail, GuardDuty – Audit user and API activity in cloud environments.

• Microsoft Azure Defender – For cloud-native threat detection and log correlation.

• CrowdStrike Falcon / SentinelOne – Endpoint Detection and Response (EDR) tools for retrieving artifacts, hunting threats, and isolating compromised machines.

---

🧰 Scripting & Automation

Scripting accelerates collection, triage, and analysis — especially in large-scale environments.

• Python – I use it to build custom Volatility plugins, PCAP parsers, or automate alert triage.

• Bash / PowerShell – For live memory dumps, log gathering, process inspection, and rapid automation.

---

🧩 MITRE ATT&CK & DFIR Methodology

I map artifacts and behaviors to MITRE ATT&CK techniques (e.g., T1055 – Process Injection) to align with industry standards and communicate findings effectively.

I also follow established methodologies like:

• SANS DFIR process

• NIST 800-61 Incident Handling Guide

• Custom playbooks for containment, eradication, and recovery

✅ Summary: Digital Forensics Tools I Use

🔹 Disk & File System Analysis

• Autopsy (Sleuth Kit) – GUI-based forensic suite

• FTK Imager – Create and inspect forensic images

• dd / dc3dd – Low-level disk imaging on Linux

• EnCase – Commercial tool for deep disk investigations (basic familiarity)

🔹 Memory Forensics

• Volatility – Extract processes, DLLs, and sessions from RAM dumps

• Rekall – Advanced volatile memory analysis

🔹 Network Forensics

• Wireshark – Protocol and packet analysis

• tcpdump – Command-line traffic capture

• NetworkMiner – Extracts files and sessions from PCAP files

🔹 Log & Timeline Analysis

• Timesketch – Timeline visualization and correlation

• Plaso (log2timeline) – Converts raw logs into a forensic timeline

• Sysinternals Suite – Live system inspection (Procmon, PsExec, Autoruns)

🔹 Malware Analysis

• Ghidra – Static reverse engineering

• x64dbg / OllyDbg – Debuggers for binary inspection

• Hybrid Analysis / VirusTotal – Behavioral analysis and threat intel

• Cuckoo Sandbox – Automated dynamic malware analysis

🔹 Cloud & Endpoint Forensics

• AWS CloudTrail / GuardDuty – Monitor API and security activity

• Microsoft Defender / Azure Logs – Cloud-native alerting and forensics

• CrowdStrike Falcon / SentinelOne – EDR tools for endpoint activity and IOC collection

🔹 Scripting & Automation

• Python – For custom plugins, log parsers, automation

• Bash / PowerShell – For system triage, memory dumps, and log collection

🔹 Methodology

• Align findings with MITRE ATT&CK

• Follow structured DFIR frameworks like SANS, NIST 800-61, and custom playbooks

🎯 Final Thoughts

Digital forensics isn’t just for breach responders — it’s a key skill for DevSecOps, SDETs, and any security-conscious engineer. Whether you’re building incident response workflows, simulating attacks, or validating your EDR, knowing how to collect and interpret evidence makes you far more effective.

🔐 How I Used OOPS Concepts in My Selenium Automation Framework (with Real-World Examples)

In today’s test automation world, building scalable, maintainable, and readable frameworks is non-negotiable. One of the key enablers of such robust automation design is the effective use of Object-Oriented Programming (OOPS) principles.

In this post, I’ll walk you through how I have practically applied OOPS concepts like Encapsulation, Inheritance, Abstraction, and Polymorphism in building a modern Selenium automation framework using Java and Page Object Model (POM)—with real-world use cases from a payments application.

---

🧱 1. Encapsulation

 – Grouping Page Behaviors & Data

In POM, each web page is represented by a Java class. All locators and associated actions (methods) are bundled into the same class, providing encapsulation.

Example:

A LoginPage.java might contain:

public class LoginPage {

    @FindBy(id="username")

    private WebElement usernameInput;

    @FindBy(id="password")

    private WebElement passwordInput;

    @FindBy(id="loginBtn")

    private WebElement loginButton;

    public void login(String user, String pass) {

        usernameInput.sendKeys(user);

        passwordInput.sendKeys(pass);

        loginButton.click();

    }

}

This hides internal mechanics from external classes, exposing only the method login()—a clean interface for test classes.

🧬 2. Inheritance

 – Reusability of Test Utilities

Inheritance is used to extend common functionality across test components like base test setup, common utilities, or driver management.

Example:

public class BaseTest {

    protected WebDriver driver;

    @BeforeMethod

    public void setup() {

        driver = new ChromeDriver();

        driver.manage().timeouts().implicitlyWait(Duration.ofSeconds(10));

    }

    @AfterMethod

    public void tearDown() {

        driver.quit();

    }

}

Then, individual test classes inherit this:

public class LoginTests extends BaseTest {

    @Test

    public void testValidLogin() {

        new LoginPage(driver).login("user", "pass");

        // assertions

    }

}

🎭 3. Polymorphism

 – Interface-Based Design

Polymorphism allows flexible and scalable design, especially when using interface-driven development.

Use Case: Suppose your framework needs to support both Chrome and Firefox.

public interface DriverManager {

    WebDriver getDriver();

}

Concrete implementations:

public class ChromeManager implements DriverManager {

    public WebDriver getDriver() {

        return new ChromeDriver();

    }

}

public class FirefoxManager implements DriverManager {

    public WebDriver getDriver() {

        return new FirefoxDriver();

    }

}

Now, switching browsers is easy without changing test logic:

DriverManager manager = new ChromeManager(); // or FirefoxManager

WebDriver driver = manager.getDriver();

🧩 4. Abstraction

 – Hiding Implementation Behind Layers

Abstraction is used in frameworks via utility and wrapper classes to hide the complexity of Selenium commands.

Example: Create a utility method for dropdown handling:

public class DropdownUtils {

    public static void selectByVisibleText(WebElement dropdown, String text) {

        new Select(dropdown).selectByVisibleText(text);

    }

}

Now testers use just:

DropdownUtils.selectByVisibleText(dropdownElement, "United States");

This hides internal logic and improves readability.

🏁 Final Thoughts

OOPS principles are not just theoretical—they are the foundation of real-world, enterprise-grade test automation frameworks. By applying:

• Encapsulation (clean page classes),

• Inheritance (shared test logic),

• Polymorphism (browser/interface abstractions), and

• Abstraction (utility layers),

you build a test architecture that’s scalable, readable, and easily maintainable.

This approach isn’t limited to Selenium. You can apply the same mindset in API testing frameworks, Appium, Playwright, and beyond.

🔧 Intercepting Android API Traffic with Burp Suite and a Rooted Emulator

Testing the security and behavior of Android apps often requires intercepting and analyzing API requests and responses. In this guide, we’ll walk through setting up an Android emulator to work with Burp Suite, enabling interception of HTTPS traffic and performing advanced manipulations like brute-force attacks.

⚠️ Requirements:

• Android Emulator (AVD)

• Root access (via Magisk)

• Burp Suite (Community or Professional Edition)

---

🛠 Step-by-Step Setup Guide

✅ 1. Install Burp Suite

• Download Burp Suite Community Edition (2023.6.2) from PortSwigger.

• Launch the app and navigate to:

  Proxy → Options → Proxy Listeners → Import/Export CA Certificate

✅ 2. Export and Install Burp CA Certificate

1. Export the CA Certificate in DER format and save it with a .crt extension.

2. Transfer this .crt file to your emulator (drag and drop works fine).

3. On the emulator:

   • Open Settings → Security → Encryption & Credentials

   • Tap Install from SD card

   • Choose the transferred certificate.

4. Confirm installation:

   • Go to Trusted Credentials → User and verify the certificate is listed.

---

🔓 3. Root the Emulator

To trust user-installed certificates at the system level (bypassing Android’s certificate pinning), you must root the emulator.

Tools You’ll Need:

• Magisk APK (v26.1 or later)

  👉 Download from Magisk Releases

• AlwaysTrustUserCerts.zip

  👉 Download from NVISOsecurity GitHub

• rootAVD tool

  👉 Download from rootAVD GitHub

Rooting Process:

1. Ensure your AVD is running before executing the root script.

2. Unzip rootAVD and run the following command in terminal:

./rootAVD.sh ~/Library/Android/sdk/system-images/android-33/google_apis/arm64-v8a/ramdisk.img

2. ✅ For Play Store-enabled AVDs, use google_apis_playstore in the path.

3. Your emulator will shut down automatically after patching.

---

⚙️ 4. Install Magisk & Trust Certificates

1. Restart your emulator and open the Magisk app.

2. Navigate to Modules → Install from Storage → Select AlwaysTrustUserCerts.zip

3. The emulator will restart again.

4. Verify the certificate now appears under System certificates, not just User.

---

🌐 5. Connect Emulator to Burp Suite

In Burp Suite:

1. Go to Proxy → Options → Add Listener

2. Choose an IP from the 172.x.x.x range.

3. Set port to 8080 and click OK.

On the Emulator:

1. Connect to Wi-Fi.

2. Long press the connected Wi-Fi → Modify Network → Proxy: Manual

3. Set:

   • Host: Burp Suite IP (e.g., 172.x.x.x)

   • Port: 8080

   • Save the changes.

---

🚀 6. Intercept Traffic

• Launch your Android debug app.

• Open HTTP History in Burp Suite to monitor incoming requests/responses.

---

🎯 Conclusion

You now have a fully configured Android emulator that allows you to:

• Intercept and inspect HTTPS API traffic

• Analyze request/response headers and payloads

• Perform manual or automated security tests (e.g., brute force attacks)

This setup is ideal for mobile QA, security testing, or reverse engineering Android applications in a safe, isolated environment.

---

💬 Feel free to bookmark or share this guide with fellow testers or developers diving into mobile app traffic inspection.

Happy hacking!