Learn more about me

As a QA engineer working on IQOS, VEEV, and ZYN websites, I often find myself using gray box testing. Why? Because I need to understand not only how the user interacts with the front end but also how the backend systems like SAP Hybris or AEM integrate with each other.

For example:

• When testing the checkout flow, I know how the backend APIs handle promotions or calculate discounts for multi-buy offers. This allows me to create tests that verify not only if the correct discount is displayed but also whether the data in the backend (e.g., the database or API response) matches the expected values.
• If a promotion like “ZYN 15% Off” isn’t appearing correctly on the website, I’ll use my knowledge of the database structure or API calls to debug whether it’s a frontend display issue or a backend data issue.

This partial insight into the system’s workings allows me to bridge the gap between functional and technical testing, identifying integration issues that might not be obvious from the user’s perspective alone.

Exploratory testing is a big part of my job because IQOS, VEEV, and ZYN websites often roll out new features quickly. The requirements might not always cover edge cases, so I use exploratory testing to uncover issues that formal test cases might miss.

For example:

• When testing a new loyalty program feature for IQOS, I’d explore the entire process as a first-time user. I might register multiple accounts with borderline-valid data (like a very long email address) to see if the form validation breaks or try invalid coupon codes to test error handling.
• On the ZYN website, I’d test adding a multi-buy promotion (like “Buy 3 ZYN cans, get 1 free”) by randomly combining eligible and ineligible products, applying and removing promotions repeatedly, and checking if the calculations stay consistent across different scenarios.

This method is incredibly helpful in identifying bugs that aren’t strictly tied to formal user stories, like visual glitches or errors that only occur when multiple user actions are performed in a specific sequence.

Static testing is where I start my QA work, especially when dealing with content-heavy platforms like IQOS, VEEV, and ZYN websites that involve integrations with tools like AEM and Syndigo.

For example:

• Before new content components are deployed in AEM, I review the requirements document and design mockups to ensure the layouts are consistent with brand guidelines. During this phase, I might catch mismatched font sizes, incorrect alt text usage for images, or accessibility issues like missing ARIA roles.
• When testing the promotion logic in SAP Hybris, I often review the code snippets or API contracts provided by the development team. For example, if the API is supposed to return a discount value in a specific format, I can flag inconsistencies or potential edge cases (like null values) before the code is even deployed.

By catching these issues early, I help the team avoid costly fixes later in the pipeline and ensure a smoother user experience when updates go live.

When testing the ZYN checkout page, I ensure all interactive elements like buttons, forms, and dropdowns are accessible via keyboard navigation alone (no mouse required). I test if the “Place Order” button is reachable with the Tab key and verify if screen readers like NVDA or JAWS can announce the button’s function clearly.

On the IQOS homepage, I check that the color contrast ratio meets WCAG guidelines (e.g., text over images or banners is readable for users with visual impairments). This means testing if white text on a blue background is distinguishable for someone with color blindness or low vision.

Form Validation: On the VEEV website, when a user enters incorrect information in a registration form, I verify that:

• The error messages are linked to their respective form fields using aria-describedby.
• Error messages (like “Invalid email format”) are not only visible but also announced by screen readers.