From Punjab to Production Releases
The story of how persistence turned a non-technical degree into a decade-long career in software quality.
Chapter 1
The Beginning
I earned my Bachelor of Arts from the University of Punjab, which gave me a solid foundation in critical thinking and communication. Not computer science, not engineering. When I moved to America, the tech industry wasn't exactly rolling out a welcome mat for someone with my background.
I found work in the Black Car industry in New York. It kept my family afloat, a wife and two kids in a brand new country with little real direction. But my passion for technology never faded. The desire to break into tech stayed with me through every shift, every long night behind the wheel.
The challenge was real. People were skeptical that someone without a CS or engineering degree could make it in a technical role. But I refused to let that define my path.
Chapter 2
Breaking In
I took matters into my own hands. I enrolled in short courses focused on QA testing methodology, learning the fundamentals of software quality assurance from the ground up. I connected with professionals in the field, attended meetups, and sought out mentors who could help me understand the landscape.
I practiced interviewing relentlessly, familiarizing myself with what employers expected from QA candidates. Every rejection was a lesson. Every conversation brought me closer.
In 2008, it all paid off. I cleared an interview at Medco Health Solutions, one of the country's largest pharmacy benefit managers. It was my first job in tech, and it changed everything. I discovered PBM, a complex domain where attention to detail and analytical thinking mattered more than what degree you held.
Chapter 3
The Contract Years
From 2008 to 2014, I worked contract roles across three of the country's biggest PBM organizations. Each contract deepened my expertise, and each gap between them tested my resolve.
Medco Health Solutions (2008-2009) My first deep dive into Medicare Part D testing, PEGA workflows, and back-end validation with Teradata and DB2. I was testing systems that processed prescriptions for over 60 million members.
CDPHP (2012-2013) I authored the Master Test Plan for a full PBM implementation with CVS Caremark, built QTP automation scripts, and ran performance tests with LoadRunner.
Express Scripts (2013-2014) Working through the post-Medco merger integration, testing claims and eligibility on mainframes for 80 million+ members. Coordinating across teams in the US, India, and the Philippines.
Between each contract, there was uncertainty. Months without work, wondering when the next opportunity would come. I went back to driving, back to whatever kept my family stable while I searched for the next role. But every contract sharpened my skills further, and every gap reminded me why I couldn't afford to stop pushing. The PBM domain was becoming second nature to me, and I knew that expertise would eventually be my way in for good.
Chapter 4
Finding Home
In 2019, I joined RxSense as a contract QA engineer. The company was building a cloud-based PBM platform from scratch, and they were hiring their very first QA team. I was there from day one.
There were no existing test plans, no established workflows, no regression suite. Everything had to be created. I helped build the QA process from the ground up, defining how we'd test claims adjudication, eligibility, network pricing, and clinical authorizations on a platform that was being built in real time.
For the first time in my career, I wasn't counting down the months until a contract ended. In 2020, they converted me to full-time. After years of uncertainty, of never knowing whether the next paycheck was guaranteed, I finally had stability. I could focus entirely on the work instead of worrying about what came next. And the work was the most meaningful I'd ever done, building something from nothing alongside a team that trusted me to get it right.
Chapter 5
Rising
Over five years at RxSense, I grew from the new contract hire into the QA Lead responsible for every production release. I became the subject matter expert across five squads: Accumulators & Copay, Eligibility & Claims, Clinical Authorization, Network & Pricing, and Member Experience.
In 2024, I was promoted to QA Lead. I managed an 11-person team, 7 onshore and 4 offshore, and owned the end-to-end test strategy. I authored Master Test Plans, ran daily stand-ups, mentored over 20 QA engineers, and served as the final quality gate for roughly two production releases every month.
I also embraced AI-assisted testing early, using TouchStone AI (built into Jira) to generate test cases from acceptance criteria, then reviewing and refining them for full coverage before stakeholder sign-off.
Leading a team taught me something no certification ever could. Quality isn't just about test cases and defect counts. It's about people. It's about coaching a junior engineer through their first production release and watching them gain confidence. It's about earning the trust of developers and product managers so that when you flag a risk, they listen. I mentored over 20 engineers during my time there, and the thing I'm most proud of isn't any single release. It's knowing that the QA culture we built together outlasted any individual sprint.
Chapter 6
The Shift
In 2026, the company made a strategic decision: eliminate the QA team entirely. The plan was to have developers test their own code and automate tests using AI. After seven years, the longest I'd ever been at one company, I was laid off.
It was a blow. But it wasn't the first time I'd had to start over, and this time I had something I didn't have before: deep domain expertise, leadership experience, and the determination to evolve with the industry rather than be left behind by it.
I understand why companies are rethinking QA. The economics of software development are changing, and AI is accelerating that change. But I also know, from a decade of experience, that the hardest part of quality assurance was never the execution. It was knowing what to look for. Automated tools can run tests faster than any human. But someone still needs to know which tests matter, which edge cases hide in the requirements, and which failures will cost the business real money. That knowledge doesn't get automated away. It gets more valuable.
Chapter 7
What's Next
I'm not waiting for the industry to decide what happens to QA. I'm shaping my own answer. I'm building a PBM Claims QA Automation Framework using Python and Pytest, applying everything I learned in six years of manual PBM testing to automated test design.
I'm also learning to use Claude AI to accelerate my understanding of QA automation concepts and tooling. Not to replace expertise, but to amplify it, the same way I used TouchStone AI to generate test cases that I then refined with domain knowledge.
The companies that understand quality know that QA isn't just about running tests. It's about knowing what to test, why it matters, and what breaks when you get it wrong. That knowledge doesn't come from a tool. It comes from a decade in the trenches.
I'm looking for a team that values that experience. A place where domain knowledge and automation skills work together, not against each other. Whether that's as a QA Lead guiding test strategy, or as a QA Automation Engineer building the frameworks that encode years of hard-won expertise into repeatable, reliable tests. I came to this country with nothing but determination. That hasn't changed. What's changed is what I can bring to the table.