11. How would you prevent test data from one test affecting another?

I would make tests independent.

Possible approaches include:

For example, Test B should not depend on Test A creating a customer successfully.


12. How would you handle different users with different permissions?

I would create separate test data or authentication states for different roles.

For example:

Admin
Manager
Regular User
Read-only User

Then I would validate what each role can and cannot access.

The important part is not just testing positive permissions.

I would also test:

“Can a regular user access an admin-only page?”

That is where many real-world authorization defects are found.


13. How would you test the same feature with multiple sets of data?

I would use data-driven testing.

For example:

const users = [
  { role: 'admin', expected: true },
  { role: 'manager', expected: true },
  { role: 'viewer', expected: false }
];

Then I can execute the same scenario against different inputs.

This reduces duplicate test code.


14. How would you handle a login flow that is expensive to execute before every test?

I would investigate whether Playwright’s authentication-state approach can be used.

Instead of performing the complete UI login repeatedly, an authenticated state can be prepared and reused when appropriate.

This can significantly reduce execution time.

Important

I would still keep dedicated login tests because the login feature itself needs to be tested.


15. What would you do if your application has OTP or CAPTCHA?

I would not try to bypass security controls in an unsafe way.

For test environments, I would work with developers to provide a controlled testing mechanism, such as:

For CAPTCHA, the best solution is usually a controlled test-environment strategy rather than attempting to automate a real CAPTCHA.


16. How would you validate that a downloaded file is correct?

I would validate more than just the download event.

I could check:

For example, Playwright can capture the download and save it for further validation.

The business requirement determines how deeply I validate the file.


17. How would you test file upload when the file picker is not visible?

I can use Playwright’s file upload capability directly.

For example:

await page.getByLabel('Upload document')
  .setInputFiles('test-data/sample.pdf');

This avoids manually interacting with the operating system’s file picker.


18. How would you automate a newly opened tab?

I would wait for the new page while performing the action that opens it.

Conceptually:

const newPagePromise = page.waitForEvent('popup');

await page.getByRole('link', { name: 'Open Report' }).click();

const newPage = await newPagePromise;

Then I can interact with newPage.

The key is to wait for the popup before performing the action that creates it.


19. How would you handle a popup that appears only sometimes?

I would first understand what triggers it.

If it is genuinely optional, I would design the test to detect it rather than blindly waiting for it.

For example, a promotional popup might appear only for some sessions.

The test should still be able to continue when the popup is absent.


20. How would you test a confirmation dialog?

I would register the dialog handler before performing the action that triggers it.

For example:

page.on('dialog', async dialog => {
  await dialog.accept();
});

For a negative scenario:

page.on('dialog', async dialog => {
  await dialog.dismiss();
});

I would also verify the resulting application behavior.


Pages: 1 2 3 4 5 6

Leave a Reply

Your email address will not be published. Required fields are marked *