How I Discovered the Need for a Testing Framework by Building My Own Banking System

🚀 Introduction

When I started this project, my goal was simple.

I wanted to build a small backend application to practice clean coding and API design. I was not thinking about testing frameworks, automation, or QA processes.

I was thinking like a developer.

So I built a lightweight banking system.

👉 BankLite Testable App

It had everything I needed to feel satisfied as a developer:

• User login
• Balance checking
• Deposit functionality
• Money transfer

The application worked. The APIs responded correctly. From a development perspective, everything looked fine.

But that was only the beginning.

⚠️ The Moment I Realized Something Was Missing

Once the system was working, I naturally moved to testing it.

At first, my approach was very simple:

• Send a request using Postman
• Check the response
• Try another scenario
• Repeat

This felt productive for a short time.

But soon, I started feeling uncomfortable.

Not because the system was failing, but because my process had no structure.

😕 What Started Going Wrong

As I continued testing, several problems became obvious:

• I could not remember which scenarios I had already tested
• I was repeating the same tests without realizing it
• When something failed, I had no proper way to document it
• I could not confidently say whether my testing was complete

This was the turning point.

I realized I was not really doing QA. I was just experimenting.

💡 The Realization That Changed Everything

At that moment, I asked myself a simple but powerful question:

What is the difference between random testing and professional QA?

The answer became clear.

Testing is not just an activity. It is a structured process.

That is when I stopped testing blindly and started designing a system for testing.

🧭 Designing a Structured Testing Flow

Instead of jumping straight into execution, I began organizing my work into a proper flow.

📊 Testing Lifecycle

I started following a consistent structure:

• Requirements
• Acceptance Criteria
• Test Scenarios
• Test Cases
• Execution
• Defects

This changed how I approached testing completely.

Now, every test had a purpose. Every scenario was traceable.

🏗️ Understanding the System I Built

Before improving testing, I needed to understand the structure of my own application more clearly.

🧱 Application Architecture

My application followed a layered design:

Presentation Layer

• Web interface for browser interaction
• API clients such as Postman, curl, and automated tests

Application Layer

• Web routes handling HTML responses
• API routes handling JSON requests

Service Layer

• Business logic such as authentication, account operations, and transactions
• Input validation and rule enforcement

Storage Layer

• In-memory storage for balances and transactions

🧠 What This Taught Me

Because I built the system myself, I could clearly see:

• Which parts were easy to test
• Which parts were tightly coupled
• Where validation was weak
• Where edge cases were likely

This is something I had never experienced before when testing third-party applications.

🔧 From Testing Activity to QA Framework

At this point, I faced a choice.

I could continue testing manually without structure, or I could build something reusable and professional.

I chose to build a framework.

That is how this project evolved:

👉 BankLite QA Automation Framework

🧪 What I Built Into the QA Framework

📋 Test Planning

I started by defining:

• Clear requirements for each feature
• Acceptance criteria that describe expected behavior

This step alone reduced confusion significantly.

🧾 Test Case Design

I created structured test cases covering:

• Positive scenarios that confirm expected functionality
• Negative scenarios that validate error handling
• Edge cases that often reveal hidden issues

Testing was no longer guesswork. It became intentional.

🔌 API Testing with Postman

I built a complete Postman collection to simulate real usage.

This included:

• Authentication flows
• Account operations
• Validation scenarios

This helped me test the system as a real client would use it.

🤖 Automation with Pytest

Manual testing gave me confidence, but it was not scalable.

So I introduced automation using:

• Python
• Pytest
• Requests library

Now I could:

• Run tests repeatedly with consistency
• Validate responses automatically
• Detect regressions quickly

🐞 Bug Tracking and Reporting

This is where the project started to feel like real QA work.

Instead of just noticing bugs, I documented them properly:

• Steps to reproduce
• Expected result
• Actual result
• Severity

🔍 Real Issues I Discovered

During structured testing, I found actual problems in the system:

• Deposit validation issues
• Transfer logic inconsistencies
• Input handling gaps

📊 Execution Summary

• Authentication passed
• Balance retrieval passed
• Deposit failed in certain conditions
• Transfer failed for edge cases
• Input validation was inconsistent

🧠 Key Lessons From This Journey

1. Testing starts much earlier than I thought

Initially, I believed testing comes after development.

Now I understand that good testing starts at design time.

2. A well-designed system is easier to test

Because I controlled the architecture, I saw how:

• Clear separation of layers improves testability
• Reusable services simplify validation
• Clean APIs make automation easier

3. QA is about thinking, not just executing

The biggest shift for me was mental.

Testing is not about running steps. It is about:

• Asking the right questions
• Identifying risks
• Thinking beyond happy paths

4. Frameworks create confidence

Before building the framework:

• I was unsure about coverage
• I repeated work
• I missed scenarios

After building it:

• I had clear visibility
• I could repeat tests reliably
• I could demonstrate my work professionally

🔄 Looking Back

This journey started with a simple goal.

Build an application.

But it evolved into something much more meaningful:

• From writing APIs
• To understanding system design
• To thinking like a QA engineer
• To building a complete testing framework

🎯 Where I Am Now

I no longer see testing as a final step.

I see it as an integral part of building quality software.

💬 Final Thoughts

If you are learning QA, I strongly recommend this approach:

• Build something simple
• Then test it deeply
• Then improve your testing process

You will not just learn tools. You will understand why testing matters.

🔗 Explore My Work

• Backend Application → Repo 7
• QA Framework → Repo 8

📌 Open to Opportunities

I am currently looking for:

• Junior QA roles
• Remote opportunities
• API and automation testing work

🙌 Let's Connect

If you have feedback, suggestions, or opportunities, feel free to reach out.