qa Archives - RONY BARUA

Why Developers Don’t Fully Trust AI (Yet): The Gap Between Intelligence and Understanding

🧩 Introduction

Artificial Intelligence (AI) is everywhere — from writing code snippets to generating test cases, fixing bugs, and even suggesting architectural patterns. Developers use tools like ChatGPT, Copilot, and Tabnine every day to save time and effort. Yet, most developers will tell you — they still don’t fully trust AI.

Why? Because AI can follow instructions, but it doesn’t understand reality. It can tell you how to go to the fourth floor of a building — but if there are no stairs between the second and third, it won’t know you can’t get there.

This simple analogy reveals a deeper truth: AI doesn’t see, imagine, or reason like humans. It predicts. And that’s why developers treat AI as a helper, not a decision-maker.

⚙️ What AI Actually Does

AI doesn’t think; it calculates.

When you ask AI a question, it doesn’t know the answer — it predicts the most likely words that should come next based on patterns it has seen before.

For example:

🏢 If you ask, “How can I reach the fourth floor?”
AI might answer: “Take the stairs or elevator.”

But if your building doesn’t have stairs between the second and third floor, AI won’t know. It doesn’t understand the building; it only understands the pattern of what most buildings look like.

That’s how it works with code too. AI can predict what a “Login API test case” looks like because it has seen thousands of similar examples. But if your API has a custom authentication token logic or unique workflow, AI might fail completely.

🧠 Developers Trust Logic, Not Guesswork

Software developers — and QA engineers like us — live by logic. Every line of code has a reason, every test has an expected result.

AI, on the other hand, doesn’t explain why. It just gives you an answer that sounds right.

For instance:

AI might generate a test case for a “Forgot Password” function.
But it may miss verifying email token expiry time or invalid token reuse — things only a human tester would think of.

This lack of contextual reasoning makes developers cautious.

🎨 Creativity: The One Thing AI Still Can’t Imitate

AI can produce, but it can’t create.

When a developer faces a new problem — say, designing a unique caching strategy or optimizing load times under unusual network constraints — AI struggles because it depends on existing data.

Creativity isn’t about patterns. It’s about breaking patterns when they no longer work.

AI can paint you a picture using past images.
But it can’t imagine a world that doesn’t yet exist.

That’s what makes human developers irreplaceable.

🔍 Real-World Understanding vs. Pattern Prediction

Developers often deal with messy, real-world systems — bugs caused by hardware, network latency, human behavior, or even business politics.

AI doesn’t experience these things. It doesn’t “know” what a late-night production issue feels like. It can’t sense when something “looks off” in a UI or when an error message feels confusing to a user.

A QA engineer, on the other hand, can feel those gaps — because we understand the user.

That empathy and intuition are beyond any AI model’s reach right now.

🧪 Why QA Engineers Are Especially Careful

As QA professionals, our job is to find what others miss.
If we depend blindly on AI, we’ll miss the very things AI can’t see.

For example:

AI might mark a test as “passed” because it matches the expected output.
But a human tester notices the button color changed — a minor UI bug that affects usability.

AI doesn’t know what feels right; it only knows what looks correct statistically.

That’s why smart QA engineers use AI for speed — but keep human judgment for quality.

🧭 The Real Role of AI in Software Development

AI is not a replacement; it’s an enhancement.
It accelerates routine tasks, generates documentation, and helps you brainstorm.

But the responsibility — the final decision — must remain human.

Here’s how most experienced teams use AI safely:

Code generation: AI drafts snippets; humans review and optimize.
Test case creation: AI suggests scenarios; QA verifies coverage and adds edge cases.
Bug triage: AI clusters similar issues; humans prioritize based on business impact.

It’s collaboration — not automation.

🧱 The “Fourth Floor” Lesson for Developers

Let’s go back to your building analogy.

Imagine AI as a smart assistant standing at the front gate. You ask, “How can I reach the fourth floor?”
It answers, “Take the stairs.”
But you know there’s no stairway from floor two to three.

If you blindly follow AI, you’ll get stuck.
If you think critically, you’ll redesign the staircase.

That’s the essence of why developers don’t fully trust AI — not because AI is wrong, but because AI doesn’t know when it’s wrong.

🌍 Conclusion: Trust Requires Understanding

AI is brilliant at prediction, not perception. It’s fast, but it lacks awareness.

Developers and testers thrive on logic, experience, and creativity — the very qualities AI can’t replicate.

The future isn’t about AI replacing developers; it’s about developers who know how to use AI wisely.

AI can help you reach the fourth floor faster — but only if you’ve already built the stairs.

Lessons from 17 Years in Software Quality Assurance

When I began my journey in Software Quality Assurance (QA) over 17 years ago, I thought my role was simple: find bugs, report them, and move on. But as I grew in this career, I learned QA is far more than bug hunting. It’s about collaboration, leadership, foresight, and protecting the quality of products that real people rely on every day.

Now, after nearly two decades, I want to share the six most inspiring lessons I’ve learned in QA. These lessons shaped my approach to testing, leadership, and teamwork—and they remain just as relevant today as when I first started.

1. Lead by Example, Not by Title

In the early days, I believed leadership was tied to a title—like QA Lead or Test Manager. But experience taught me that real leadership is about action, not position.

In QA, leadership comes in many forms:

Helping a junior tester structure their first test cases
Guiding a team toward smarter test strategies
Promoting collaboration between testers, developers, and business analysts
Encouraging open discussions instead of finger-pointing when issues arise

I’ll never forget mentoring a new graduate who joined my team. They were overwhelmed by the complexity of test planning. Instead of simply correcting their mistakes, I walked them through my approach step by step. Months later, they were creating detailed, reliable test plans on their own—and even coaching others.

👉 Lesson: You don’t need a title to be a leader. Every day is an opportunity to inspire through your actions.

2. Chasing Speed Without Purpose Is Risky

The tech world loves speed. Agile, DevOps, and automation all emphasize faster delivery. But here’s the reality: speed without quality is dangerous.

I’ve seen projects rush releases just to “meet the deadline.” The result?

Angry customers
Expensive post-release bug fixes
Lost trust in the product and team

On the flip side, I’ve also seen the power of speed done right. On one project, I led an automation initiative that reduced regression testing from 8 hours to just 20 minutes. That speed was valuable because it was built on accuracy. Every test was reliable, every scenario meaningful.

👉 Lesson: Don’t confuse speed with success. A broken release delivered quickly is not an achievement—it’s just failure delivered faster.

3. Quality Thrives When Everyone Owns It

For a long time, QA was treated like a safety net at the end of development. Developers built, testers tested, and if things broke, testers were blamed. That mindset is outdated.

Modern QA is about shared responsibility. Quality belongs to the entire team, not just the testers.

Developers must write clean code and unit tests
Business analysts must define precise requirements
Product managers must set realistic goals and acceptance criteria
Testers must validate, explore risks, and ensure coverage

On projects where QA was involved from day one, the results were always stronger. Reviewing requirements, attending design sessions, and contributing to sprint planning reduced bugs dramatically. When everyone owns quality, the product succeeds.

👉 Lesson: Quality isn’t something QA adds at the end. It’s something the whole team builds together from the start.

4. Stand Tall, Never Sacrifice Quality

Deadlines are always tight. Business pressure is always real. And often, the question comes: “Can we release even if testing isn’t done?”

Here’s my hard-learned truth: compromising on quality always costs more in the end.

I’ve seen rushed releases crash in production, requiring days of emergency fixes and damaging client relationships. What looked like a “quick win” turned into a costly disaster.

Yes, deadlines matter. But a QA professional’s role is to defend the product and the customer. It’s about standing firm and saying: “We can release quickly, but we cannot release poorly.”

👉 Lesson: Deadlines are temporary, but poor quality lasts forever. Protecting quality is protecting the business.

5. Write It Down, Don’t Let Words Disappear

This may sound simple, but it’s one of the most powerful lessons I’ve learned: oral communication is the weakest form of documentation.

In fast-paced projects, I’ve heard it all:

“I thought you understood.”
“Didn’t we agree in the meeting?”
“I mentioned it yesterday.”

But spoken words vanish. People forget. Teams change. Without written records, misunderstandings multiply.

That’s why I insist on lightweight but effective documentation:

Test cases written with clarity
Bug reports with full reproduction steps and evidence
Meeting notes summarizing what was decided

This doesn’t mean endless paperwork. It means just enough documentation to ensure alignment and avoid confusion. Many times, a simple Jira note or Confluence page has saved us hours of backtracking.

👉 Lesson: If it’s not written, it doesn’t exist. Documentation builds clarity and prevents mistakes.

6. Draw the Line: Define Boundaries and Deliverables Clearly

One of the biggest lessons I’ve learned in large projects is the importance of system boundaries and deliverables.

When boundaries are unclear, QA teams waste time testing areas outside their scope—or worse, miss critical areas that fall within their responsibility. Similarly, when deliverables aren’t clearly defined, confusion erupts over what was promised versus what was delivered.

On one government project I worked on, there was confusion over whether third-party payment gateway behavior was part of our scope. By clarifying the system boundary, we focused only on integration points, not the inner workings of the gateway. This saved time, prevented unnecessary arguments, and ensured everyone understood what was truly required.

To succeed, teams must:

Clearly identify system boundaries (what’s inside scope vs. outside scope)
Document deliverables in detail (features, reports, integrations, test evidence)
Align on acceptance criteria with all stakeholders

👉 Lesson: Quality depends on clarity. Define boundaries and deliverables early, and you’ll prevent endless confusion later.

Final Thoughts

After 17+ years in QA, these six lessons remain my compass:

Lead by Example, Not by Title
Chasing Speed Without Purpose Is Risky
Quality Thrives When Everyone Owns It
Stand Tall, Never Sacrifice Quality
Write It Down, Don’t Let Words Disappear
Draw the Line: Define Boundaries and Deliverables Clearly

These are not just professional lessons—they are principles I live by. They shaped me into the QA Lead I am today, and I believe they will remain relevant no matter how much technology evolves.

The future of QA will include AI testing, advanced automation, and smarter tools. But the foundation of quality—clarity, leadership, teamwork, and responsibility—will never change.

QA is Not the Enemy of Developers — QA is the Partner in Success

In the world of software development, one common misconception persists: Quality Assurance (QA) engineers are the “enemies” of developers. Developers often see QA as the ones who “break” their code, point out flaws, and delay releases. But the truth is the exact opposite. QA is not the enemy — QA is the partner of developers. Both roles share the same mission: delivering high-quality, reliable software that delights end-users.

As a Software QA Lead with over 17 years of experience, I’ve seen firsthand how shifting this mindset transforms projects, reduces conflicts, and accelerates success. Let’s dive deeper into why QA and developers should be partners, not rivals.

Why Developers Often See QA as the “Enemy”

It’s not unusual to hear developers complain about QA. Some common reasons are:

Bug Reports Feel Like Criticism:
Developers put in hours of effort writing code. When QA raises defects, it may feel like personal criticism rather than constructive feedback.
Deadlines vs. Quality:
Developers work under tight deadlines, and QA sometimes appears to “slow things down” with additional testing and bug verification.
Different Mindsets:
Developers aim to make software work. QA aims to find where it breaks. This difference in perspective often leads to tension.

But these are not signs of rivalry. They are signs of complementary roles.

Why QA is the True Partner of Developers

Instead of looking at QA as the team that breaks code, developers should see QA as their safety net and quality booster. Here’s why:

1. QA Prevents Rework and Saves Time

When QA finds issues early, developers spend less time fixing bugs after release. Fixing a defect in production costs exponentially more than fixing it during testing.

2. QA Ensures Developers’ Work Shines

Developers write features, but QA ensures those features perform flawlessly in real scenarios. Without QA, a developer’s great code might fail in production due to overlooked edge cases.

3. QA Brings the User’s Perspective

Developers focus on implementation, while QA thinks like the end-user. Together, they create software that is both technically strong and user-friendly.

4. QA Supports Continuous Improvement

QA feedback isn’t about fault-finding. It’s about improving coding practices, strengthening test coverage, and preventing similar issues in future sprints.

Real-Life Example: Collaboration Over Conflict

In one of my projects, we introduced automation in regression testing. Initially, developers thought QA was adding unnecessary work. But when they saw regression time drop from 8 hours to just 20 minutes, they realized QA wasn’t slowing them down — we were helping them deliver faster and safer. That’s the power of partnership.

How Developers and QA Can Work as True Partners

Communicate Early:
Involve QA from the requirement stage. Shift-left testing helps both sides catch issues before coding even starts.
Respect Each Role:
Developers should see QA feedback as guidance, not criticism. QA should respect the creativity and effort of developers.
Share Knowledge:
QA can learn basic coding to understand development constraints, while developers can learn testing principles to anticipate edge cases.
Celebrate Together:
Success is not just when code is written, but when it passes QA and reaches the user bug-free. Celebrate as one team.

Final Thoughts

Developers build the foundation of software, and QA ensures that foundation is strong, stable, and user-ready. Instead of being seen as opponents, QA and developers should act as partners in quality.

At the end of the day, the user doesn’t care whether a developer or QA missed something. They only see the product. And when the product works flawlessly, it’s the result of teamwork between developers and QA.

So remember: QA is not the enemy. QA is the partner who helps you succeed.

Myth: QA Slows Down the Release

✅ Reality: QA Saves the Release

In many development circles, there’s a lingering belief that Quality Assurance (QA) is a blocker. Teams race toward deadlines, and as release day nears, the murmurs begin:

“QA is holding us back.”
“Why can’t we just release it and fix bugs later?”

This mindset is dangerous. It not only undermines the QA role but also jeopardizes the quality, stability, and reputation of your product.

Let’s dig deeper and debunk this myth, once and for all.

🔍 What QA Actually Does (And Why It’s Vital)

🧠 1. QA Doesn’t Just Test — It Thinks Ahead

Quality Assurance is not a button you press at the end of development.
It’s a strategic process that starts before the first line of code is written. Involving QA early means:

Asking “what if” questions before assumptions turn into bugs
Analyzing acceptance criteria and business flows to ensure clarity
Thinking like the user and identifying gaps developers may miss

QA minds are wired to think in systems, edge cases, and user journeys. When you involve QA early, you are designing with foresight.

⏰ 2. QA Doesn’t Delay — It Detects Risk Early

Here’s the irony: skipping QA to “move faster” often slows everything down.

Bugs found late in the release cycle are exponentially more expensive and time-consuming to fix
Minor issues missed in staging may cause major incidents in production
Reactive hotfixes eat up development time, hurt team morale, and damage trust

QA helps prevent fire-fighting by detecting risk upfront. A few days of proper testing can save weeks of rework and reputation repair.

💣 3. QA Isn’t the Blocker — It’s the Bomb Diffuser

Picture this: your app is about to go live. You’re confident in the features, the build is stable, and stakeholders are excited.

But without QA, you might be launching a ticking time bomb.

QA is the team asking:

“What happens if the user skips a field?”
“What if the API goes down mid-transaction?”
“What if the input causes a security vulnerability?”

They don’t block the release — they defuse the risks you didn’t know existed.

📌 Common Misconceptions That Hurt Product Quality

Misconception	Reality
QA just runs test cases	QA validates business logic, verifies assumptions, and ensures usability
QA can be added at the end	QA must be involved from the beginning to shape testable and stable features
Fast development means skipping QA	Faster ≠ better if it leads to more post-release bugs and firefights
Developers can test their own code	They should — but QA offers a different lens (user-focused, edge-case-oriented)

👥 A Better Way to Work: Shift-Left QA

“Did we involve QA from the beginning?”

This is the golden question.
Shift-Left Testing encourages teams to embed QA at the planning stage — not just when coding is done.

Benefits of Shift-Left QA:

✅ Catch requirements issues early
✅ Design test cases as features are planned
✅ Improve collaboration between Dev, QA, and Product
✅ Minimize costly late-stage bugs
✅ Enable faster, safer, more confident releases

🎯 Real-World Example: When QA Was Left Out

A fintech startup released a new payment feature without end-to-end QA due to a tight deadline.
Within 3 hours of deployment, customers started reporting duplicate charges.
The root cause? A retry logic bug that QA would have easily caught with a simple simulation.
The outcome: 4 engineers pulled into a weekend war room, thousands in chargebacks, and weeks of customer recovery.

One critical question was asked too late:

“Why didn’t we involve QA from the beginning?”

🧠 Final Thought: QA is Your Competitive Advantage

Quality is everyone’s responsibility — but QA specialists are trained to own it. They ask the hard questions, think like users, and prevent issues that damage trust.

🚀 If you want to release with confidence…
🤝 If you care about user experience…
🛡️ If stability matters to your business…

Then don’t treat QA as the last line of defense.

Treat them as first responders in your product journey.

Where Was QA? The Silent Heroes Behind Every Smooth Release

If a bug is found after release → “Where was QA?” 😤
If the release goes smoothly → Silence. 😶

Sound familiar?

This common industry refrain perfectly captures the quiet, often overlooked role of Quality Assurance (QA) in software development. QA professionals are the safety net no one sees—until something slips. We are the last line of defense, but never the only line of responsibility.

Yet despite our critical role, recognition is rarely part of the job description.

The Misunderstood Role of QA

Many view QA as the team that just “finds bugs.” But in reality, QA is deeply involved in:

Writing comprehensive test cases
Conducting regression testing until the early hours
Analyzing edge cases that most ignore
Facilitating constant communication with developers, PMs, and stakeholders
Preventing issues, not just detecting them

A bug-free release isn’t magic—it’s meticulous work. And often, it’s the result of invisible efforts that begin the moment development starts and end well after the product is live.

Shared Responsibility, Not Scapegoating

When a post-release issue surfaces, it’s easy to point fingers at QA. But the truth is: quality is everyone’s job. From design and development to deployment, every team contributes to the final outcome.

If the only time QA is acknowledged is during failure, we miss an opportunity to foster a healthier, more accountable culture.

Celebrate Success, Don’t Just Blame Failure

So here’s a radical idea for your next smooth release:

✅ No bugs? Thank your QA team.
✅ Seamless user experience? Acknowledge the hours of testing that made it possible.
✅ Peaceful deployment? Appreciate the questions QA asked that no one else thought of.

QA might not always be visible, but our work is behind every stable, successful product you ship.

Final Thought

Next time you’re tempted to ask “Where was QA?”, also ask:
“Did I thank them when nothing went wrong?”

Because if you’re not blaming QA for the bugs, you should be thanking them when there are none.

Embracing Quality: A Deep Dive into Software Testing and Quality Assurance at Uttara University

As technology continues to evolve at a rapid pace, the demand for quality software has never been greater. In response to this need, I’m excited to announce that I will be leading a series of lectures on Quality Assurance (QA) and Software Testing at Uttara University under the EDGE project.

Why Quality Assurance Matters

Quality Assurance is more than just finding bugs; it’s about ensuring that software meets the highest standards of quality and reliability. With the increasing complexity of software applications, effective QA practices are essential for delivering products that not only meet user expectations but also perform well under real-world conditions.

Course Overview

Throughout this course, we will explore key concepts and methodologies in QA and software testing, including:

Introduction to Quality Assurance: Understanding the principles of QA, its importance in the software development lifecycle, and the role of QA professionals.
Testing Methodologies: Delving into various testing types such as unit testing, integration testing, system testing, and acceptance testing. We will also discuss manual vs. automated testing and when to use each approach.
Test Planning and Design: Learning how to create effective test plans, design test cases, and establish testing criteria that align with project requirements.
Defect Tracking and Reporting: Best practices for identifying, documenting, and communicating defects to ensure timely resolution.
Tools and Technologies: An overview of popular testing tools (like Selenium, JUnit, and Postman) and how they can enhance the testing process.
Real-World Applications: Case studies and practical exercises to apply the concepts learned and prepare students for real-world QA challenges.

Learning Outcomes

By the end of this course, students will be equipped with the knowledge and skills to:

Understand the critical role of QA in software development.
Develop comprehensive test plans and cases.
Utilize various testing tools effectively.
Analyze and report on testing outcomes to drive improvements.

Join the Journey

I am passionate about sharing my knowledge and experiences in QA and software testing. This course will not only provide theoretical insights but also hands-on experience that prepares students for careers in this vital field.

I look forward to engaging discussions, collaborative projects, and fostering a deeper understanding of quality assurance among aspiring software professionals.

Stay tuned for updates, and let’s embark on this journey towards achieving excellence in software quality together!

Database Testing Checklist

Database Testing

Synchronization between the database and the values displayed in our client/web.
Query results, views, stored procedures, indexers Etc.
Data manipulation (Update, Delete, insert Etc.).
Database performance.
Data maintenance.
Table’s structure.
Data recovery.
Data integrity.
Others

Clean database testing

Verify clean database testing.
Input 1st data

Database system-level tests

Validate the DB behavior of any case of service failures (recovery, error handling Etc.).
Validate that all indexes are created when it can increase the system performance.
Validate that appropriate events are created ad sent to the EventVwr/trace log.
Validate that DB tables are created with informative and reasonable names.
Try to work when the storage is ‘0’ and the e database is in running state.
Perform your tests on different versions (SQL 2005, 2008, 2012 etc.).
Validate the software security model (User roles, permissions etc.).
Validate the connection strings against SQL/Win authentications.
Validate data migrations (Different Database, Cluster, etc.).
Validate the behavior of the system against SQL injections.
Validate date to DB when the server is loaded.
Try to work when the database server is down.
Try to work with difference instance.
Validate restore and backup plans.

Database Integration Testing

Check that all columns are set with the relevant data type (Bigint, int, string Etc.)
Check that all data is logically organized in the relevant DB tables.
Check that each data item is located under the relevant column.
Is there any irrelevant data in the software dedicated tables?
Check that each table contains the relevant data.
Try to insert invalid database values.
Verify the data encryption (if any).

Data field tests

Validate that “Allow Null” condition is not allowed in a place that result a software failure.
Validate that all tables are created with logical structure (Primary, foreign keys.)
Validate that “Allow Null” condition is set when you need to allow it.
Validate that mandatory fields are created, this issue is very important when you work with multiple tables that depends on each other.

Procedure tests

Validate that the data the affected by the procedure is changed as expected.
Validate that all procedures are triggered when they supposed to run.
Validate that all the conditions receive an appropriate date inputs.
Validate that all procedures are created with the relevant code.
Is there an appropriate error handling for a failed procedure?
Validate that all the loops receive an appropriate date inputs.
Validate the procedure’s parameters (types, names, etc.).
Test the SP while executing the code manually.
Validate important code with SQL profiler.
Validate that all procedures names
Run tests with missing parameters.

Database and software integration (Client, web Etc.)

Validate that the user data is saved when the user “Apply” or “Submit” the changes.
Try to insert “NULL” values on fields that doesn’t supposed to receive it.
Validate that the user receives the current result when pulling data.
Validate that transaction the data type boundaries (Minima Etc.)
Validate that empty spaces are not committed to the database.
Validate that the values displayed based on the database data.
Try to insert UNICODE on Unicode character strings.
Try to insert values that exceed the field boundaries.
Validate that transactions the negative data values.
Insert invalid date format on Date and time fields.
Validate that the data integrity is not affected when the “Apply” or “Submit transactions are failing during the process.
Validate that the “Roll Back” option is available when the DB transaction is failed in the middle.

Data checking

Create Data from frontend and check by Query
Delete Data from frontend and check by Query