What if testing were like tasting soup, and most teams only taste it after serving customers?
Prachi Dahibhate has spent six years perfecting the art of "tasting early" in software development.
Her philosophy is simple.
Just as you adjust salt while cooking, rather than waiting until the meal is served, you catch bugs during development, rather than after release.
This approach has helped her spot security vulnerabilities before they reach production and create release strategies overnight.
Here's what we explored together:
Let’s dig in!
Currently, I work as a QA engineer with 6 years of experience.
My day usually starts with stand-up meetings, then I spend time reviewing new features with developers and product managers, writing test cases, or improving automated test scripts.
The part I enjoy most is exploratory testing, where I play around with the product as if I were a real user.
Once, while testing a food delivery app, I tried placing an order with my internet connection turned off midway. The app got stuck in a weird loop that would have annoyed real customers badly.
Catching such things gives me a strange joy; it feels like I saved someone from frustration. Sometimes, just having deep dives with the team to understand why a feature might break under unusual conditions.
Honestly, I didn’t start my career dreaming of becoming a software tester. I originally wanted to be a developer.
During my first job interview, after clearing the selection process, the HR representative mentioned that I’d be joining as a trainee QA. At first, I thought, “Okay, I’ll take this for now and maybe switch to development later.”
I still remember my first bug, it was a tiny mismatch in a UI button color that nobody else noticed. The developer laughed and said, “That’s so small, who cares?” But a week later, the client pointed it out in a demo. That day, I understood testing is about protecting value & seeing things others miss.
That “eye for detail” slowly became my superpower.
I follow a combination of early collaboration and curiosity.
Some practical ways I do this include attending requirement and design discussions early, encouraging peer reviews for test cases and code, and using risk-based testing to focus on the features that could cause the most damage if they fail.
Think of it like cooking; if you taste the food while cooking, you can adjust the salt early. But if you wait until serving, it’s too late. I apply the same principle in testing. I sit with developers even before they write code, asking questions like “What if the user cancels at this step?” or “What if the data comes late?” Doing this helps us think of possible risks early. I believe communication is key. Pair testing with developers is my favorite.
One story I like to share: During a project, I noticed the backend API wasn’t validating some inputs properly. If this had gone unnoticed, it could have caused a serious security issue. I brought it up before the development was complete, and it saved weeks of rework.
We also perform shift-left testing, which means testing begins at the requirements stage. If a requirement is unclear, I raise it right there instead of waiting for the code to be ready.
I balance this by automating repetitive checks so I can spend more time on creative exploratory testing.
Not everything needs the same level of testing. For critical features such as payments or security checks, I test deeply. For less critical ones, like cosmetic changes, I test more lightly, but still ensure that nothing is broken.
A simple rule I follow is “Prioritize critical functionality, Automate what’s repetitive, and Collaborate constantly. This way, the team can release faster without skipping quality.
Once, our team had to release a patch overnight. We couldn't test everything, so I created a risk-based checklist: focus on payments, login, and cart. We released on time, and it worked fine.
Quality doesn't mean testing everything; it means testing the right things at the right time.
Absolutely! AI has become like a smart assistant in my workflow.
I use it to:
But AI doesn't replace thinking; it enhances focus. It's like having an extra pair of eyes that handles the repetitive tasks while I focus on deeper testing strategies.
Tools: Jira, Postman, Selenium, and sometimes Figma for UI reviews.
Resources: Blogs like Ministry of Testing, community forums, LinkedIn learning, and QA podcasts. I encourage beginners to join communities, real conversations teach you things books don’t.
That's a wrap!
Thank you, Prachi, for sharing how accidental career paths can lead to passionate expertise. You can connect with Prachi on LinkedIn to discuss testing strategies and quality insights.
For more interviews with testers, make sure to subscribe to TestingPod and get it delivered to your inbox every Friday.