DEV Community: Enayet Rashid

🏦 Bridging Development and QA: My Journey from Code Design to Manual Testing Mastery

Enayet Rashid — Tue, 31 Mar 2026 16:14:52 +0000

How I Learned Testable Design by Breaking My Own ATM System:

** It Started With a "Working" System**

I built an ATM simulator. It worked. At least, that's what I thought.

From a developer's perspective, everything looked fine:

Log in ✔
Check balance ✔
Deposit and withdraw ✔
Transfer funds ✔

Then I asked a simple question:

How do I know this system actually works correctly?

That question changed everything.

** The Illusion of "It Works"**

At first, I was testing informally:

Try a valid input → works
Try another valid input → works

I felt confident. But I wasn't testing. I was confirming my own assumptions.

** The Turning Point: When I Tried to Test Properly**

I decided to approach my own system like a QA engineer.

Not casually, but systematically.

That's when I realised something uncomfortable:

I didn't actually have clearly defined expected behaviour.

** From Code to QA: Where Everything Became Real**

I created a separate repository dedicated to manual testing.

Not random testing, but a structured QA workflow:

Requirements
Acceptance criteria
Test plan
Test scenarios
Test cases
Execution results
Defects

** Step 1: Writing Requirements Changed Everything**

Before writing a single test case, I had to answer:

What exactly is the system supposed to do?

So I formalised requirements like:

Authentication rules
Deposit validation
Withdrawal constraints

Each requirement included clear acceptance criteria.

** First Major Realisation**

I had written code before defining behaviour. That's backwards.

** Step 2: Designing Test Cases Exposed Gaps**

When I started writing test cases, something interesting happened.

I began asking questions like:

What happens if the user enters text instead of a number?
What if they withdraw exactly the balance?
What if they transfer to an invalid account?

These were not edge cases anymore. They were missing behaviours in my design.

** The Moment My System Started Breaking**

When I executed my test scenarios, I found real issues.

** Deposit Validation Issues**

Non-numeric input was not handled clearly
System behaviour was inconsistent

** Transfer Usability Problem**

Error messages were too generic
The user did not know what went wrong

** Input Handling Problem**

The system returned to the menu instead of re-prompting
The user flow was broken

These were not coding mistakes. They were design problems.

** Test Execution Made It Real**

** Execution Summary**

From actual execution:

✅ Authentication → Passed
✅ Balance → Passed
❌ Deposit → Failed
❌ Transfer → Failed
❌ Input Handling → Failed

All backed by:

Evidence screenshots
Execution notes
Scenario tracking

** Second Major Realisation**

Without execution tracking, testing is just opinion.

** Step 3: Defects Told Me the Truth**

I documented each defect clearly:

Steps to reproduce
Expected vs actual behaviour
Evidence
Impact

I did not use tools like Jira. I did not need them. Because the value was not in the tool, it was in the clarity of thinking.

** The Most Important Lesson: Design Impacts Testing**

At this point, something became very clear.

** Developer vs QA Mindset**

Developer Thinking	QA Thinking
It works	What can break?
Focus on happy path	Focus on edge cases
Code-focused	Behaviour-focused

** Critical Insight**

Poor design creates hidden defects. Testing simply reveals them.

** SDLC Reflection: Where This Matters in Real Life**

This experience made me think beyond my project.

** What Happens in Real Projects?**

If you skip proper planning:

Requirements are unclear
Test cases are inconsistent
Bugs are discovered late
Fixes become expensive

** Cost of Poor Planning**

Developers rework logic
Testers rewrite cases
Deadlines slip
Confidence drops

** Looking Back at My ATM Design**

Now I see my system differently.

Before Testing

This works fine

After Testing

Validation logic incomplete
Error messaging unclear
User flow inconsistent

** The Shift That Changed Everything**

I stopped asking: Does it work?
And started asking: Can it fail safely?

** What This Means Going Forward**

Because I designed the system with separation of concerns:

I can now add an API layer
I can automate tests using Pytest
I can introduce UI automation

This is no longer just a project. It is a foundation for real QA and automation work.

** Final Takeaways**

Writing code is not enough
Testability is a design decision
Requirements drive testing
Testing reveals design flaws
Real QA is structured, not random

** Closing Thought**

I started this project to build an ATM system, but I ended up learning something much bigger. The moment I stopped treating QA as something you do after coding and started treating it as a design constraint from the beginning, my code improved before I even wrote it. I didn't just learn how to test software - I learned that the most valuable test cases are the ones that make you realise your design was incomplete

** Repositories**

ATM Simulator

https://github.com/enayetrashid/atm-simulator

Manual Testing Practice

https://github.com/enayetrashid/manual-testing-practice

From if Statements to Classes: How Refactoring Taught Me Testable Code

Enayet Rashid — Fri, 27 Mar 2026 11:12:28 +0000

I am a self-taught learner. So when I decided to build a Python calculator, I didn't start with classes or design patterns. I started with the messiest, most beginner thing possible - everything crammed into one script. And honestly? That was the right decision.

This article is about how I evolved that calculator through three versions, and what each step taught me about writing code that's actually testable - which matters a lot when you're learning QA automation like I am.

👉 GitHub: https://github.com/enayetrashid/python-calculator-evolution

Version 1 - The "Just Make It Work" Phase

My first version was pure chaos by design. No functions, no classes; just raw logic from top to bottom.

a = float(input("Enter first number: "))
b = float(input("Enter second number: "))
operation = input("Enter operation (+, -, *, /): ")

if operation == "+":
    print(a + b)
elif operation == "-":
    print(a - b)
elif operation == "*":
    print(a * b)
elif operation == "/":
    print(a / b)

It worked. But the moment I asked myself "how do I test this?" I had no answer. You can't test code that demands user input just to run. This was my first real lesson:

If input and logic live together, testing becomes nearly impossible.

Version 2 - Introducing Functions

I pulled the calculation logic out into separate functions. A small change - but it changed everything.

def add(a, b):
    return a + b

def subtract(a, b):
    return a - b

Now I could write an actual test:

def test_add():
    assert add(2, 3) == 5

No input prompts. No manual interaction. Just pure logic I could verify instantly. This felt like a superpower.

The lesson: Functions are the foundation of testable code. If you can't call it in isolation, you can't test it properly.

Version 3 - Moving to OOP

Finally I wrapped everything in a class and added proper error handling:

class Calculator:
    def add(self, a, b):
        return a + b

    def divide(self, a, b):
        if b == 0:
            raise ZeroDivisionError("Division by zero")
        return a / b

The divide method was a turning point for me. Adding that guard clause meant I could now test failure scenarios too - not just the happy path.

def test_divide_by_zero():
    calc = Calculator()
    with pytest.raises(ZeroDivisionError):
        calc.divide(10, 0)

The lesson: OOP isn't just about organisation - it's about making your code extensible and testable at scale.

Why This Matters Beyond the Calculator

I'm learning QA automation, and this little project taught me something that no tutorial explained clearly:

The structure of code directly affects how easy it is to test.

In real automation work with tools like Pytest or Playwright, you never test everything in one place. You separate test logic, business logic, and test data. This calculator evolved through exactly that same pattern:

Version	Structure	Testability
Version 1	Everything inline	Nearly impossible to test
Version 2	Functions	Testable in isolation
Version 3	OOP	Scalable and extensible

Key Takeaways

Start simple - but don't stay simple
Refactoring is a skill, not just a task
Testability should guide your design decisions from the beginning
Even the smallest projects can teach big engineering concepts

Final Thought

This wasn't really about building a calculator. It was about learning to think like someone who cares about quality - not just getting something to run, but building it so it can be verified.

What's the simplest project that taught you something fundamental? I'd love to hear it in the comments.