Devrims #TechTalk 074: Krupa Nanda Interview

Ever wonder what goes into making a WordPress site run smoothly behind the scenes? Meet Krupa, a quality assurance expert who didn’t just stumble into the QA world, she embraced it with purpose and passion.

In this interview, Krupa shares her journey from discovering WordPress as a simple blogging tool to becoming a key player in testing complex, high-stakes projects. Along the way, she’s worn many hats from QA to support to project coordination, and it’s given her a unique, well-rounded view of how great products come to life.

She opens up about real-world challenges like CDN conflicts, what makes WordPress VIP projects special, and why being a great QA is about more than just finding bugs—it’s about understanding people. Krupa’s story is full of insights, laughs, and thoughtful lessons for anyone who wants to build better digital experiences.

Devrims: Hey Krupa, thanks for your time and support. What inspired you to pursue a career in Quality Assurance, especially in the WordPress ecosystem?

Krupa: I started my journey as Quality Assurance in 2015 when I joined my first company, rtCamp. Back then, I only knew WordPress as a tool for blogging. However, through my role as QA, I discovered how powerful it is as a full CMS. Seeing how flexible and community-driven WordPress is has made me want to learn more about QA and best practices. I became passionate about ensuring users have smooth experiences, and being part of a community that values collaboration and innovation has been truly inspiring.

Devrims: Can you describe your experience with testing WordPress VIP projects? What standards or challenges stand out?

Krupa: QA responsibilities on WordPress VIP projects are largely similar to non-VIP projects in terms of functional, cross-browser, accessibility and content workflow testing. However, what sets VIP projects apart are the strict coding standards, robust performance profiling, and heightened security expectations. While the core testing approach remains the same, ensuring compliance with VIP’s guidelines adds an extra layer of diligence. It requires attention to detail, proactive communication, and close collaboration with developers to deliver stable, high-quality releases that are ready for production.

Devrims: What does your typical test plan look like for a newly developed plugin or add-on?

Krupa: Usually, I start test planning by understanding how the plugin or add-on is expected to work in real-world use. I prepare test cases to validate functional checks and identify potential edge cases. As a QA, I believe our role is not just to find bugs, but to prevent them from reaching production. I also ensure compatibility testing across different WordPress versions, browsers, and environments to catch issues that may arise from varied setups. To make testing more efficient for future regression cycles, I automate test cases that are stable and repetitive, when there is bandwidth available to do so.

Devrims: How do you manage both white box and black box testing in a WordPress environment?

Krupa: When it comes to white box and black box testing in WordPress, I lean more towards black box testing. My role revolves around manually testing everything to automate the scenarios for the end-to-end process, which we call e2e flow, testing the full user journey. I don’t usually get into the code or write the unit tests (which is usually done by devs), but I do work closely with the developers to ensure I understand how features are implemented. That way, I can design automated test scripts that cover everything from front-end to back-end functionality. 

Devrims: What’s your understanding of how WordPress hosting environments (like managed vs shared hosting) impact QA?

Krupa: In QA, the hosting environment can have a significant impact on testing, especially when considering performance and security. Managed WordPress hosting environments usually offer specialised server configurations, security features, and optimised performance, which make tests more reliable and less prone to external variables. 

For example, when testing a site with a high volume of media content, a managed hosting environment will likely provide faster load times and more stable performance during testing. 

On the other hand, shared hosting environments can lead to less predictable performance since server resources are shared with other websites. For example, if I were testing a media-heavy site on shared hosting, I might notice slower load times or even timeouts during high traffic periods. As a result, testing on shared hosting may require additional attention to performance bottlenecks, speed issues, or potential conflicts with other hosted sites.

Devrims: Do you test for server-level issues (e.g., caching, CDN conflicts, PHP version compatibility)?

Krupa: Server-level issues like caching, CDN conflicts, or PHP version mismatches are things I’ve learned to watch out for after I encountered a real scenario once. One real example that stands out was when a UI related bug fix was deployed to production. The fix worked perfectly on local and staging environments, but in production, the UI was still broken. After some investigation, we discovered that the CDN was serving an old cached version of the CSS file, even though the code had been updated. The browser continued to load the stale asset, so users never saw the fix.

It was a classic case of the code being correct but causing the issue in production. That experience reinforced the importance of checking how assets are served in production and making sure cache purging or versioning is part of the deployment process.

It’s not always about what’s broken in the code, but it’s often about how the code is delivered and experienced by the user.

Devrims: How do you handle testing in staging vs production environments?

Krupa: For a tester, testing in staging is all about risk prevention. The staging environment is almost a replica of production. It’s the space where QA can validate new features, bug fixes, and integrations without impacting real users.

But QA’s job is not completed once things are green in staging. Once we go live, there is a checklist to run on production too after a deployment is done, which we call smoke testing. QA also needs to keep an eye on the production environment for errors(browser console) , real-time alerts, or performance issues. 

There have been cases where everything passed in staging, but something as simple as a browser-specific rendering issue or a caching rule in production created a hiccup. Job of QA is not just to validate, but to safeguard the user experience at every step.

Devrims: Let’s do a quick, rapid-fire round.

Mountain or Beaches	Mountains
Books or Movies	Books
Tea or Coffee	Always tea (with milk and ginger 😋)

Devrims: As a Project Coordinator or Release Manager, how do you ensure communication flows effectively between teams?

Krupa: Honestly, wearing multiple hats as QA, support, and project coordination really gave me a 360° view of the product and how each decision impacted both the team and the end users. I wasn’t just testing features and/or fixing in isolation; I was also the one interacting with customers directly, replying to support tickets, and understanding the real pain points people were facing in day-to-day use.

This direct exposure helped me bring a lot of user empathy into the QA process. The thought process was not limited to, ‘Does this feature work?’ but more like, ‘Is this solving the user’s actual problem? Is UX intuitive?’ That mindset changed the way I wrote test cases and how I approached regression testing.

So, from a coordination standpoint, whenever users reported issues or asked for enhancements, I’d evaluate whether the request made sense as a feature and discuss it with the product team. Sometimes it led to quick fixes, and other times it helped shape future roadmap plans. Since I was already testing the builds and coordinating between teams, I could follow a request all the way from initial support query till the deployment.

Of course, managing all three roles meant I had to be structured. I made sure communication didn’t fall through any cracks and kept support feedback documented, setting clear timelines for releases, and constantly aligning with the dev team for priorities. But doing all of this also gave me a much deeper appreciation for the product lifecycle and helped me advocate for both the user and the team in a more balanced way.

Devrims: Could you share a picture of your current work desk or setup? We’d love to see where the QA magic happens!

Krupa: Sure, here it is:

Devrims: What advice would you give to someone preparing for the QA role in the WordPress space?

Krupa: If someone is preparing for a QA role in the WordPress space, my advice is to go beyond just clicking through the UI. Learn how to break things with purpose and in a constructive way.

Stay curious and keep learning. Familiarise yourself with how WordPress core works and consider contributing back if you can. Engaging with the WordPress community through forums, Slack channels, and WordCamps can give you valuable insights, real-world perspectives, and will offer you the best networking opportunities! 

Also, embrace both manual and automation testing. And above all, always test with the end-user in mind because that’s what separates good QA from great QA.

Devrims: What kind of professionals or roles would you like to see interviewed next?

Krupa: WordPress ecosystem consists of so many amazing people that it is hard to name one single person, but if I have to, then here I nominate – 

• Michelle Frechette 
• HariShaker
• Makarand Mane
• Mumtahina Faguni 

They are doing a wonderful job and helping the community at every single step!