Quality Analyst Intern
Before moving into Project Management, I spent three months as a Quality Analyst Intern at Vistaar Digital my first corporate experience. I performed manual testing on Enablr, a live production SaaS product, and identified and tracked 400+ issues across functional, UI, usability, and accessibility categories.
Overview
I joined Vistaar Digital as a QA Intern and was assigned to Enablr, a live, in-production application already being used by real customers. My work centered on manual testing: functional testing, UI testing, usability testing, CMS testing, regression testing, and accessibility testing, done across multiple devices and reported through Excel and Asana.
What made the role distinct was scope. Enablr had several types of users, each interacting with the product differently, and evaluating it properly meant testing it from each of those perspectives rather than treating it as a single, uniform interface. Over the three months, I identified and tracked more than 400 issues, worked closely with developers and project stakeholders to get them resolved, and regression-tested fixes to confirm they held. That process gave me a practical, first-hand understanding of how requirements, users, testing, and delivery connect inside a real software product the same connections I now manage directly as a Project Manager.
The Product I Worked On
Enablr was the product I tested during my time at Vistaar Digital: a live, production SaaS application already in active use, not a prototype or an internal tool. Testing it meant validating real production workflows, not isolated screens or components.
The product served multiple types of stakeholders, and different stakeholders interacted with different parts of the system. That meant a single workflow could be tested correctly for one type of user and still fail for another, depending on which part of the product they touched and how they used it. Understanding that structure, before diving into test execution, was the first real lesson of the internship: you cannot test a product well until you understand who is using it and why.
My Responsibilities at the Time
Manual Testing
Validating that features worked as intended and complete user journeys held up end to end rather than testing isolated screens in isolation. Scenario-based testing was a big part of this: walking through workflows the way an actual user would, not just checking whether a button technically fired an action.
Cross-Device Testing
Enablr was tested across iPad, tablet, mobile, and desktop. This mattered directly to the stakeholder structure of the product: different stakeholders relied on different devices to do their work. Testing across form factors surfaced issues that single-device testing would have missed entirely.
CMS Testing
Part of the product involved CMS-based workflows, used by admins and managers to manage and track data. I tested these workflows from that admin perspective, separately from the end-user-facing parts of the application.
Regression Testing
Once a developer fixed a reported issue, I retested it to confirm the fix actually resolved the problem and did not introduce a new one elsewhere. Regression testing was a constant part of the cycle.
Accessibility Testing
I ran accessibility testing against WCAG standards, since Enablr served a US-based product context. Accessibility was treated as a functional requirement to test against, not an afterthought.
Bug Reporting
Every issue I found was documented with enough detail for someone else to understand and reproduce it: description, steps to reproduce, expected versus actual behavior, and relevant device or environment information.
Testing the Product From Multiple Perspectives
This is the part of the role that shaped how I think about product quality the most. Enablr had a layered stakeholder structure: Product Owner → Pharma Company Management → CMS/Admin → MR. Each of these groups interacted with the product differently, and each cared about different things.
The product owner was concerned with whether the product met its intended requirements. The pharma company's management cared about whether the product supported their teams' work at scale. CMS and admin users interacted primarily with data and management workflows. The MR needed the product to be fast, clear, and reliable in real, day-to-day use.
A workflow that satisfied the product owner's requirements could still create friction for the MR using it in the field, or fail to give management the operational visibility they needed. Testing Enablr properly meant holding all of these perspectives at once. That is the core insight this role gave me: a product cannot be evaluated properly from a single user's perspective.
From QA to Project Management
Testing Enablr changed the kinds of questions I asked. It started with does this work? and moved toward why does it work this way?, then who is using it?, then what are they trying to accomplish?, and eventually what could prevent this problem earlier, before it ever reaches QA?
That progression connected directly to UX, requirements, stakeholder needs, prioritization, and the kinds of decisions that shape a product before a single test case is written. I didn't move into Project Management because of this internship alone, but it built the foundation for it: testing a product from every stakeholder's perspective is, in practice, close to how a project manager has to think about the same product. Today, as a Project Manager, that habit of holding multiple stakeholder perspectives at once is something I apply on every project I run.
The Thinking Shift
400+ Issues Identified
Over three months, I identified and tracked 400+ issues on Enablr, spanning functional, UI, usability, and accessibility categories.
The value of this work was never the raw count. Testing at this scale, across multiple devices and multiple stakeholder-facing workflows, made it possible to spot patterns: the same underlying issue surfacing on a different screen, a different device, or a different user scenario. Recognizing those patterns mattered more than logging any single issue, since it pointed to root causes rather than isolated symptoms.
My Bug Reporting Process
I followed a consistent process for every issue: Identify → Reproduce → Document → Report → Track → Retest.
A bug report is only useful if someone else can understand and reproduce the problem without needing to ask five follow-up questions. That single principle shaped how I documented every issue I logged, and it's the same principle I now apply to how I write requirements and status updates as a PM.
- Go to Dashboard
- Apply Filter
- No results displayed
Testing Across Devices
Enablr was tested across iPad, tablet, mobile, and desktop, because the product's different stakeholders relied on different devices to do their work.
The same workflow could behave differently depending on screen size, device, and interface context. A layout that worked cleanly on desktop could break down on tablet. An interaction that felt natural on mobile could be awkward on iPad. Testing across form factors, rather than assuming desktop behavior would hold everywhere, was necessary to catch issues that a single-device approach would have missed.
Accessibility Testing
Accessibility testing was part of the core QA process on Enablr, not a separate or theoretical exercise layered on top of it. I tested against WCAG standards, given that Enablr served a US-based product context, treating accessibility as a functional requirement the same way I treated any other feature requirement: something to test against directly, log issues on, and verify once fixed. This built my awareness of accessibility as a genuine dimension of product quality rather than an afterthought.
Working Within the SDLC
Vistaar Digital gave me direct exposure to how a real software product moves through its lifecycle: Development → QA → Fix → Regression → Release → Production.
Before this, concepts like environments, branches, and pull requests were abstract. Working inside the QA stage of a live product made them concrete: I saw how a fix moved from a developer's branch through testing and regression before it reached production, and how each stage depended on the one before it. I didn't own these stages my role sat inside QA. But working within that process gave me a practical understanding of how development, testing, and release connect, something college coursework doesn't really teach, and something I now oversee end-to-end as a PM.
Process & Learning
This role built a set of practical skills I didn't get from coursework: structured testing, defect reproduction, clear documentation, issue prioritization, and pattern recognition across a large volume of reported issues. I also developed a better sense of how to read requirements, since most quality issues traced back to unclear requirements rather than bad code. Regular collaboration with developers strengthened how I communicated technical problems, and running accessibility testing consistently built a working awareness of inclusive product design as part of quality, not separate from it.
Collaboration With Developers
Reporting an issue was only the first step. I worked directly with developers to clarify problems when a report needed more context, communicated issues clearly enough that they could be reproduced without back-and-forth, and verified fixes once they were made. This also meant understanding priority: not every issue was equally urgent, and part of the job was recognizing which problems needed immediate attention and which could wait. Maintaining accurate QA documentation throughout the cycle kept this collaboration grounded and traceable a habit that now shows up in how I keep client and developer communication aligned on my current projects.
What I Learned About Product Quality
A few things became clear through this work: requirements matter, because unclear requirements are where most quality issues start. Users matter, because the same feature can succeed or fail depending on who is using it and how. Context matters, because a workflow that works on one device or for one stakeholder can break down for another. Functionality is only one part of quality: a feature can technically work and still create a poor experience. Accessibility is part of quality, not a separate checklist. And defect patterns, once you start noticing them, often reveal a broader product problem rather than a one-off mistake.
From Functional Testing to User Experience
A feature can pass every functional check and still create a poor experience for the person using it. That distinction became clear early in the internship, and it changed how I approached testing.
Beyond checking whether something worked, I paid attention to UI consistency, points of friction in a workflow, how clear a process was to someone using it for the first time, and how a journey held up across devices. None of this made me a UX designer. But testing exposed me directly to UX problems, because a workflow that technically passed could still be confusing, inconsistent, or slow for the actual user relying on it. QA became the entry point through which I started noticing these gaps even though resolving them wasn't my role back then.
Key Takeaways
Quality is bigger than bug-free software
A product can pass every functional test and still fail its users.
Testing requires understanding the user
You cannot evaluate a workflow properly without knowing who relies on it and why.
Different stakeholders experience differently
A product owner, an admin, and a field user can each have a completely different experience of the same feature.
Good bug reporting is effective collaboration
A report is only useful if someone else can reproduce the problem from it.
QA gave me a strong view into product quality and software delivery
Sitting inside the QA stage of a live product is one of the clearest ways to see how requirements, development, testing, and release actually connect.
Impact & Takeaways
Looking back, the work I did at Vistaar Digital contributed directly to product quality: identifying functional, UI, usability, and accessibility issues before they reached production, supporting the resolution of those issues through clear reporting, and validating fixes through regression testing to confirm the product stayed reliable as it changed. Beyond the 400+ issues logged, the broader impact was in supporting a more consistent, more accessible, and more reliable experience for Enablr's users across every device and stakeholder group.
"Quality is not simply the absence of bugs. It is whether the product behaves correctly, supports its users, and meets the intended requirements."
Frequently Asked Questions
What did you do as a Quality Analyst Intern at Vistaar Digital?
I performed manual testing on Enablr, a live production SaaS product, covering functional, UI, usability, and accessibility testing across multiple devices, and worked with developers and stakeholders to report, track, and verify fixes. This was a past internship — I now work as a Project Manager.
What product did you work on at Vistaar Digital?
Enablr, a live, in-production application with multiple types of stakeholders, including a product owner, pharma company management, CMS/admin users, and field-based MRs.
How many issues did you identify during your internship?
I identified and tracked 400+ issues over approximately three months, spanning functional, UI, usability, and accessibility categories.
What types of testing did you perform?
Manual functional testing, UI testing, usability testing, CMS testing, regression testing, cross-device testing, and accessibility testing.
Did you perform accessibility testing?
Yes. I tested Enablr against WCAG standards, since it served a US-based product context, treating accessibility as a core part of the QA process rather than a separate consideration.
Do you currently work at Vistaar Digital or as a QA?
No. This was a three-month internship (Dec 2025 – Mar 2026) that's now part of my past experience. I currently work as a Project Manager.
Conclusion
Vistaar Digital was my first corporate experience, and the Quality Analyst Intern role on Enablr gave me practical exposure to what product quality actually requires. Beyond logging 400+ issues across functional, UI, usability, and accessibility categories, the work meant testing across four device categories, running accessibility checks for a US-based product, and evaluating the product through the lens of every stakeholder who used it. It gave me a first-hand understanding of not just whether software works, but how quality is shaped by requirements, users, stakeholders, testing, collaboration, and delivery and it built the foundation for the project management work I do now.
