DEV Community: Uziman Oyedele

Why Manual Testing Isn’t “Old School” - It’s the Secret Sauce for Smart Automation

Uziman Oyedele — Tue, 28 Oct 2025 12:36:40 +0000

Hey there, fellow testers! Let me tell you a secret: manual testing isn’t just “doing things by hand.” It’s the R&D lab for automation. Think of it like this: automation is a super-fast robot. You give it instructions, and it follows them perfectly. But here’s the catch: that robot is only as smart as the person who programmed it. Manual testing? That’s the human brain behind the code, curious, messy, and full of “what ifs” that machines miss.

1. “Why” Comes Before “How”: Testing the Testability

Let’s be real: when you’re testing a new feature, do you just blindly follow a script? Hell no. You poke around. You try weird combinations. You ask, “What if I do this?” That’s exploratory testing, the heart of manual work.

Remember that time you typed random gibberish into a login field, and the app crashed? Or clicked a button five times in a row, and it froze? Automation scripts would never think to do that; they only test what you tell them to. But those “unexpected” bugs? They’re gold. They uncover usability nightmares (like a checkout flow that makes users want to scream) or edge cases (like what happens when you try to buy 10,000 items at once).

Here’s the kicker: Automation is precise, but it’s also stupid. It needs manual testing to feed it intelligence. And before you even think about automating a feature, ask yourself: Is this thing stable enough to automate? If you can’t manually test it three times in a row without it breaking, automating it is like building a house on quicksand. You’re just adding tech debt.

2. Building the Intelligent Automation Framework

Manual testers aren’t just bug hunters, we’re automation architects. We figure out the “path of least resistance” through an app. Like, which buttons are reliable? Which screens load slowly? Which fields are prone to typos? That’s our job.

Take a simple example: say you’re testing a form with a dropdown menu. A manual tester might notice that the dropdown sometimes takes 2 seconds to load. So when writing an automation script, we’d tell the bot to wait before clicking, preventing flaky tests. Our test logs? They’re the “ground truth” for automation. They tell you which UI elements are finicky (avoid those!) and which flows are rock-solid (automate those!).

And here’s another thing: risk-based prioritization. As a senior tester, I know which parts of the app are high-stakes (like payment processing) versus low-risk (like a font size setting). Manual testing lets us find the “biggest bang for your buck” bugs, then automation polices them. Automation is for regression (making sure old stuff still works), not discovery (finding new problems). Let manual testing do the heavy lifting of finding the risks first.

3. The User Experience (UX) Imperative: Where Humans Shine

Automation can check if a button works. But can it tell you if that button feels right? If the workflow is intuitive? If the color contrast is so bad that you can’t read the text? Nope. That’s where manual testing comes in with empathy.

Think about logging into an app. Automation checks: “Does the login button click? Does it redirect?” Manual testing checks: “Is the login page cluttered? Is the ‘forgot password’ link easy to find? Does the loading spinner make you panic?” Those little details? They make or break user satisfaction. You can’t automate “user frustration”, but a manual tester can feel it.

And let’s not forget accessibility. When I’m testing, I naturally think: “What if someone uses a screen reader? What if they have limited dexterity? What if their phone is zoomed in?” Basic automation scripts rarely consider that. Manual testing forces us to step into other people’s shoes, and that’s not just good testing, it’s ethical.

Final Thought: Manual Testing Isn’t Obsolete - It’s Essential

Look, I love automation. It saves time, runs repetitive tests, and keeps our apps stable. But it’s a tool, not a replacement for human intuition. Manual testing is the “why” behind the “how.” It’s the curiosity that finds the hidden bugs, the stability that makes automation viable, and the empathy that makes apps usable.

So next time someone says, “We don’t need manual testers anymore,” smile and say: “Sure, but who’s going to teach the robots to think like humans?”

—P.S. If you’ve ever had a moment where manual testing saved your ass (or your app), drop a comment below. I’d love to hear it.

QA Strategy: Your Test Plan as a Governance Contract

Uziman Oyedele — Thu, 23 Oct 2025 23:00:15 +0000

We've all been there: testing is wrapping up, and suddenly the Project Manager asks why we didn't test "Feature X," or a developer pushes back on a "High" severity bug. Why does this confusion happen?

Because the Test Plan wasn't treated as a contract.

My first post covered the Discovery and Specification phases of test planning. Now, let's talk about the final, most crucial step: turning that document into a ratified agreement a QA Governance Contract that protects the project, the quality, and you.

For context, the principles I discuss here were recently applied during my strategic engagement on a project. My role involved establishing the System Test Plan, a crucial step for any high-stakes platform. I use this ongoing, real-world project to demonstrate how a Test Plan transitions from a static document into a live, governing force for the development lifecycle.

Why Governance Matters: Managing the Unknowns
Risk Mitigation Starts with a Section
The Power of Entry and Exit Criteria
Making Defect Management Official
The Walkthrough Workshop: Forcing Consensus (Phase 3)
Key Takeaway

Why Governance Matters: Managing the Unknowns

The core job of a Test Plan, especially in any project, is to capture and manage risks before they become project-breaking issues. Your plan must be more than just a list of steps; it must be the agreed-upon mechanism for handling every crisis. It helps to give direction on how we are to go about our test activities.

Risk Mitigation Starts with a Section

The most essential governance sections are those that force conversation about potential failure:

Dependencies, Risks, Issues, and Assumptions: This is the QA crystal ball.

Dependency Example: “Testing is dependent on a fully functional, integrated Slack Test Environment.” If that dependency isn’t met, you have a formal, signed-off reason to halt testing, preventing wasted effort.
Risk Example: “Risk: Late changes to the Leaderboard logic could break core data display.” By documenting this, you proactively ask for more time or resources for regression testing when that change occurs.

The Power of Entry and Exit Criteria

This is where you gain control. Testing should never be a continuous loop—it needs clear start and stop gates. The Entry and Exit Criteria you define in the plan are non-negotiable checks that prevent wasted time.

Caption: Here's a screenshot of the Entry and Exit Criteria table from the System Test Plan. These gates are non-negotiable checks that protect the entire testing cycle.

The Governance Question	The Required Clause
When can we START testing?	Entry Criteria: Smoke Testing is passed; Test Environment is stable; All required test data is loaded.
When can we FINISH testing?	Exit Criteria: 100% of Critical and High severity defects are closed; 100% requirements coverage is achieved; Test Completion Report is signed off.

QA Thinking: If the system under test team hands me a build, and it fails the Smoke Test (Entry Criteria), the Test Plan gives me the authority to reject the build and send it back to development without starting the full system test. That’s efficiency through governance!

Making Defect Management Official

A defect management process is only as good as the team’s commitment to it. By including the Defect Management section in the Test Plan, you formalize:

Severity Definitions: Clearly defining what constitutes a Critical vs. a Medium defect. This eliminates arguments during triage.
Resolution SLAs: Setting hard time limits (e.g., Critical defects must be fixed and retested within 1 business day). This keeps the development team accountable to quality.

Caption: Defining defect severity before testing starts is crucial. This table from the Test Plan ensures the entire team agrees on the business impact of a Critical bug.

The Walkthrough Workshop: Forcing Consensus (Phase 3)

The single most valuable step in my entire process is the Walkthrough Workshop. This is where the Test Plan stops being a QA document and starts being the team's document.

Before requesting final sign-off, I arrange a dedicated 30-minute meeting with the Project Manager, Dev Lead, and Business Analyst.

What to Achieve in the Workshop:

Review Scope: Confirm everyone agrees on what is In and Out of Scope (especially important for non-functional testing).
Verify Risk: Ensure the Dev Lead agrees with the identified risks and dependencies (e.g., Is the Slack Integration dependency correctly captured?).
Confirm Criteria: Get verbal agreement on the Entry and Exit Criteria.

By the end of this workshop, there are no surprises. When you ask for the final signature (v1.0), it’s a commitment, not a courtesy.

Key Takeaway

The Test Plan is your QA legacy on a project. It sets your professional boundaries, enforces quality standards, and serves as your defense against scope creep and uncontrolled risk. Don't just write it, use it as the signed contract for quality delivery.

The QA Superpower: Using the Test Plan and strategy to Prevent Bugs, Not Just Find Them

Uziman Oyedele — Thu, 23 Oct 2025 21:41:51 +0000

Hey everyone,

Let’s talk about that feeling when you join a new project. It’s that mix of excitement and sheer terror, right? You walk in with your brain fired up, your testing instincts honed, and you’re ready to dive in. But you can’t just head straight for the backlog and start clicking buttons.

I learned the hard way that our first, most critical job as QA pros isn't just finding bugs. It's something much bigger. It's about crafting the strategy that prevents them from ever happening in the first place.

And how do we do that? With our secret weapon: The Test Plan.

A great test plan (and the strategy behind it) is our QA superpower. It takes those fuzzy, high-level project goals and turns them into a clear, living roadmap that everyone on the team can actually follow. After years of jumping into new projects and learning from a few mistakes along the way, this is the personal process I’ve developed to turn business requirements and team chaos into a rock-solid quality strategy.

Phase 1: The Recon Mission – Getting the Lay of the Land
- 1. Figure Out Where You Are in the Story
- 2. Check the Foundation
Phase 2: Making Friends and Building the Blueprint
- 3. Get Out and Talk to People
- 4. Nail Down the Scope and Write the Darn Thing
Phase 3: Getting Everyone on the Bus
- Draft and Peer Review v0.1
- Formal Review v0.2
- The Walkthrough Workshop
- Final Sign-off v1.0
The 13 Pillars of a Rock-Solid Test Plan

Phase 1: The Recon Mission – Getting the Lay of the Land

My first week on any new project is less about testing and more about playing detective. It’s about listening, watching, and just soaking it all in. You have to understand the terrain before you can navigate it.

1. Figure Out Where You Are in the Story

I always start by asking the big, dumb questions to get my bearings. Don't be shy, you need to know this stuff.

Project State: Are we at the drawing board, in the middle of building, or is it already a frantic scramble to test? Am I creating a plan from scratch, or am I trying to make sense of an existing one? Is this a brand-new app or just a new coat of paint on something that’s already live?
Who’s Building It? Is it our own dev team down the hall, or are we bringing in a third-party vendor? Trust me, testing for a vendor is a whole different ball game.
What's the Point? What are the core features we’re actually building, and what real-world headache are they supposed to solve for the user?
Who’s It For? Are we building something for our own internal team, or is this for paying customers? The answer to that question defines everything about our risk tolerance and what we prioritise.
The Team: Who’s the boss? Who are the coders I’ll be working with? And, most importantly, who actually has the final say when things get tough?

2. Check the Foundation

Before I start building anything, I need to see if there’s already a decent foundation in place. We don't want to tear down a perfectly good house, but we absolutely need to make sure it’s not about to fall over.

Test Artefacts: Is there a Test Strategy or Plan already gathering dust somewhere? If so, my job is to dust it off, see what works, and figure out how to make it better. If not, it’s my job to convince everyone we need one.
Execution Phases: What testing are we actually expected to do? (System Testing, SIT, Regression, UAT). Knowing this upfront saves a world of pain later when someone tries to add performance testing two days before launch.
Environments & Tools: What are the playgrounds we get to work in (DEV, TEST, UAT)? And what tools are we using for managing tests, automation, and the inevitable flood of defects?
Delivery Model: Are we Agile, Waterfall, or some kind of hybrid monster? This dictates everything from how we structure our sprints to how we run our regression cycles.

> The Big Idea: This first phase is all about building your foundation. It’s how you figure out if you can work with the current system or if you need to be the agent of change for the sake of quality.

Phase 2: Making Friends and Building the Blueprint

Once I have a map of the landscape, it’s time to get to know the people and start putting the actual plan together.

3. Get Out and Talk to People

You can read every document on the server, but the real story, the juicy details, the why behind the what—that lives in people's heads. I make it my mission to find the key players and buy them a coffee (or at least jump on a call).

The Business Analyst (BA): My go-to for the "why." They’re the keeper of the user's story and can translate business-speak into something I can actually test.
The Tech Architect/Dev Lead: My source for the "how." They can tell me about the tech stack, the hidden risks, and the clever solutions they’ve built.
The Project Manager (PM): The keeper of the triple threat: budget, schedule, and stakeholder expectations.

And I always hunt for the unsung heroes, the people who make the logistics happen:

Who runs the Defect Management Tool? (This person is your best friend.)
Who’s the Build Lead? (Crucial for knowing when code is actually ready for you).
Who wrangles the Test Environments and Test Data? (Find these people. Thank them. Bring them gifts. They are the gatekeepers to everything.
Who are the Business Stakeholders? (You’ll need them when it’s time for User Acceptance Testing).

4. Nail Down the Scope and Write the Darn Thing

With all the puzzle pieces on the table, it’s time to define the most important part of the plan: the scope. I write down, in no uncertain terms, what we will test (tying it directly to user stories) and, just as importantly, what we won't.

This "Out of Scope" section isn't about being negative; it's our shield against scope creep. It’s where we say, "No, we are not testing performance on day one," or "That future feature? We'll test it when it's actually built."

If the team has a template, great. If not, I create one based on the principles that have never let me down.

Phase 3: Getting Everyone on the Bus

A test plan sitting in a folder, unsigned, is just a collection of good intentions. It's worthless. The real magic happens when the team reads it, debates it, and ultimately agrees to it.

Draft and Peer Review `v0.1`

I write the first messy draft and send it to my fellow QA colleagues. They're my sanity check, they catch the things I'm too close to see.

Formal Review `v0.2`

After I’ve incorporated their feedback, it goes to the Project Manager, Dev Lead, and BA. This is where the real feedback starts.

The Walkthrough Workshop

This step is not optional. I schedule a 30-minute meeting and walk the core team through the plan, section by section. This is where we hash it out, where we debate the fine points, and where we leave the room with a single, unified vision for:

Test Approach: How we're going to test this thing.
Defect Management: How we'll handle bugs when we find them.
Entry and Exit Criteria: When testing starts and, more importantly, when we're done.

Final Sign-off `v1.0`

Once we’ve reached a consensus, I ask for the formal sign-off. This document is now our constitution, the single source of truth for how we handle quality on this project.

The 13 Pillars of a Rock-Solid Test Plan

So, what goes into this "constitution"? Over the years, I’ve boiled it down to 13 non-negotiable sections. If you get these right, you’ll cover your bases and build a plan that actually works.

Solution Overview: In plain English, what the heck are we building?
Document Purpose: Why are you even reading this? (Spoiler: To keep us all on the same page).
In Scope / Out of Scope: The "yes" list and the "not gonna happen" list. Crucial for sanity.
Test Approach: The rules of the game. How we’ll trace requirements and handle regression.
Testing Process: Our journey through the 5 phases of testing (Discovery → Planning → Spec → Execution → Completion).
Test Execution Phases: The specific rules for each stage: Smoke, System, and UAT.
Test Artefacts: The stuff we’ll create, like test cases and traceability matrices.
Release Approach: How and when new code will land in our test environments.
Test Environment + Test Data: The playgrounds and the toys we need to do our jobs.
Defect Management: The plan for how we'll triage bugs, define severity, and get them fixed.
Roles and Responsibilities: Who’s doing what. The ultimate "who to ask when" guide.
Dependencies, Risks, Issues, and Assumptions: The known unknowns. What could trip us up?
Metrics and Reporting: How we’ll show our progress and prove our value.

See the pattern? We start wide, looking at the whole landscape. We zoom in, building knowledge and relationships. Then we bring it all together, getting buy-in from the entire team.

This is how you stop being just the "bug finder" and start becoming the Quality Strategist the team can't live without.

Happy testing!

DEV Community: Uziman Oyedele

Why Manual Testing Isn’t “Old School” - It’s the Secret Sauce for Smart Automation

1. “Why” Comes Before “How”: Testing the Testability

2. Building the Intelligent Automation Framework

3. The User Experience (UX) Imperative: Where Humans Shine

Final Thought: Manual Testing Isn’t Obsolete - It’s Essential

QA Strategy: Your Test Plan as a Governance Contract

Table of Contents

Why Governance Matters: Managing the Unknowns

Risk Mitigation Starts with a Section

The Power of Entry and Exit Criteria

Making Defect Management Official

The Walkthrough Workshop: Forcing Consensus (Phase 3)

What to Achieve in the Workshop:

Key Takeaway

The QA Superpower: Using the Test Plan and strategy to Prevent Bugs, Not Just Find Them

Table of Contents

Phase 1: The Recon Mission – Getting the Lay of the Land

1. Figure Out Where You Are in the Story

2. Check the Foundation

Phase 2: Making Friends and Building the Blueprint

3. Get Out and Talk to People

4. Nail Down the Scope and Write the Darn Thing

Phase 3: Getting Everyone on the Bus

Draft and Peer Review `v0.1`

Formal Review `v0.2`

The Walkthrough Workshop

Final Sign-off `v1.0`

The 13 Pillars of a Rock-Solid Test Plan

DEV Community: Uziman Oyedele

Why Manual Testing Isn’t “Old School” - It’s the Secret Sauce for Smart Automation

1. “Why” Comes Before “How”: Testing the Testability

2. Building the Intelligent Automation Framework

3. The User Experience (UX) Imperative: Where Humans Shine

Final Thought: Manual Testing Isn’t Obsolete - It’s Essential

QA Strategy: Your Test Plan as a Governance Contract

Table of Contents

Why Governance Matters: Managing the Unknowns

Risk Mitigation Starts with a Section

The Power of Entry and Exit Criteria

Making Defect Management Official

The Walkthrough Workshop: Forcing Consensus (Phase 3)

What to Achieve in the Workshop:

Key Takeaway

The QA Superpower: Using the Test Plan and strategy to Prevent Bugs, Not Just Find Them

Table of Contents

Phase 1: The Recon Mission – Getting the Lay of the Land

1. Figure Out Where You Are in the Story

2. Check the Foundation

Phase 2: Making Friends and Building the Blueprint

3. Get Out and Talk to People

4. Nail Down the Scope and Write the Darn Thing

Phase 3: Getting Everyone on the Bus

Draft and Peer Review v0.1

Formal Review v0.2

The Walkthrough Workshop

Final Sign-off v1.0

The 13 Pillars of a Rock-Solid Test Plan

Draft and Peer Review `v0.1`

Formal Review `v0.2`

Final Sign-off `v1.0`