3+ Years of Experience in QA Automation by Vaibhav Singh

3+ Years of Experience in QA Automation

#QA #selenium #automation

Posted by TechElliptica at 23 Jun 2025 ( Day(s) Before)

Company : Patym

Difficulty Level : Medium

Duration : 45 min

Location : Bangalore

Years of Experience : 3+ years of QA Automation

Interview Type : L1

Position : QA Automation

We have 2 lists below, which showing the 2023 Stock price and the 2024 Stock price.
stockPrice_2023 = [5, 4, 6, 2, 3] (present)
stockPrice_2024 = [8, 5, 4, 3, 5] (future)

You have your budget as 10 in the start of 2023

What is the maximum profit you can make?

To solve this problem, we want to maximize profit by selecting a subset of stocks such that:

The total purchase cost (from present) ≤ budget
The total profit (future price - present price) is maximized

This is a variation of the 0/1 Knapsack problem, where:

Each stock is an item
present[i] is the cost
future[i] - present[i] is the profit/value
The budget is the maximum capacity

Input:

present = [5, 4, 6, 2, 3]

future = [8, 5, 4, 3, 5]

budget = 10

Profit Array:

profit = [3, 1, -2, 1, 2]

Approach:

We find combinations of stocks where total cost ≤ 10 and total profit is maximized.

Try all valid combinations manually:

1) Stocks [0, 3, 4]

Cost: 5 + 2 + 3 = 10

Future: 8 + 3 + 5 = 16

Profit: 16 - 10 = 6

2) Stocks [1, 3, 4]

Cost: 4 + 2 + 3 = 9

Future: 5 + 3 + 5 = 13

Profit: 13 - 9 = 4

3) Stocks [0, 1]

Cost: 5 + 4 = 9

Profit: (8 + 5) - (5 + 4) = 13 - 9 = 4

4) Stocks [3, 4]

Cost: 2 + 3 = 5

Profit: (3 + 5) - (2 + 3) = 8 - 5 = 3

Best Combination: [0, 3, 4] → Profit = 6

For the array [1, 2, 3, 4, 5],

If you rotate it to the right by 3 positions, what will the new array look like?

If you rotate the array [1, 2, 3, 4, 5] to the right by 3 positions, the elements shift 3 places to the right, wrapping around the end.

Step-by-step:

Original: [1, 2, 3, 4, 5]
Rotate right by 1: [5, 1, 2, 3, 4]
Rotate right by 2: [4, 5, 1, 2, 3]
Rotate right by 3: [3, 4, 5, 1, 2]

Final result:[3, 4, 5, 1, 2]

import java.util.Arrays;

public class RotateArray {

public static void main(String[] args) {

int[] arr = {1, 2, 3, 4, 5};

int k = 3;

int n = arr.length;

k = k % n;

reverse(arr, 0, n - 1);

reverse(arr, 0, k - 1);

reverse(arr, k, n - 1);

System.out.println("Rotated Array: " + Arrays.toString(arr));

}

private static void reverse(int[] arr, int start, int end) {

while (start < end) {

int temp = arr[start];

arr[start] = arr[end];

arr[end] = temp;

start++;

end--;

}

Could you explain your approach to executing test cases across multiple browsers?

When executing test cases across multiple browsers, my approach focuses on ensuring cross-browser compatibility while maintaining efficiency. Here's how I typically handle it:

Test Planning and Prioritisation: I start by identifying critical test cases that must be validated on all target browsers — usually core functionalities and high-risk areas. This helps prioritise efforts where cross-browser issues would have the biggest impact.

Automation Framework Setup: I use automation tools like Selenium WebDriver, which support multiple browsers through drivers (ChromeDriver, GeckoDriver, etc.). I design the test scripts to be browser-agnostic by parameterising the browser type, allowing the same test to run on different browsers by just changing a configuration.

Browser Configuration and Environment Management: I set up local browser environments or leverage Selenium Grid for distributed and parallel test execution. For wider coverage and scalability, I use cloud-based platforms like BrowserStack or Sauce Labs, which provide access to many browser and OS combinations without managing infrastructure.

Parallel Execution: To save time, I implement parallel test execution so tests can run simultaneously across different browsers, reducing total test cycle duration.

Reporting and Analysis: I ensure detailed test reports include browser-specific results to quickly identify and debug browser-specific defects.

Continuous Integration: I integrate cross-browser tests into the CI/CD pipeline so that tests run automatically on code changes, providing early feedback.

Overall, this approach ensures comprehensive cross-browser testing with optimised time and resource use, leading to a consistent user experience across browsers.

Suppose you have a regression test pack of 100 test cases. and because of tight deadline and last min defect fix, you only have time to execute 20 test-cases. How will you plan this activity?

To execute 20 test cases per browser from a total of 100, I would start by prioritising and selecting the most critical test cases based on functionality, business impact, and risk. These could include smoke tests, high-priority scenarios, or tests covering core features that must work consistently across all browsers.

I would create test suites or groups to organise these 20 test cases, ensuring each suite runs on each target browser. Automation frameworks like TestNG or JUnit allow tagging or grouping tests to facilitate this.

Additionally, I would implement parallel execution on different browser instances using tools like Selenium Grid or cloud-based services (e.g., BrowserStack, Sauce Labs) to save time.

For the remaining test cases, I might run them selectively on specific browsers based on usage statistics or known compatibility issues to optimise test coverage without excessive execution time.

This approach balances comprehensive testing with efficient resource utilisation, ensuring that essential functionality is verified on all browsers while managing execution time

Suppose you are executing your framework, and you have some flaky testcases. How will you execute them in your TestNG Framework ?

RetryAnalyzer Interface Feature

This allows you to specify a retry logic class that will rerun failed tests a specified number of times before marking them as failed.

Implementation

create a class that implements the IRetryAnalyzer interface,
overriding the retry() method to control retry attempts.
associate this retry analyzer with your test methods using the @Test annotation

RetryAnalyzer interface class

public class RetryTestCase implements IRetryAnalyzer {

int maxRetry = 3;

int retryCounter = 0;

public boolean retry(ITestResult iTestResult) {

if(iTestResult.isSuccess() == false) {

retryCounter++;

if (retryCounter <= maxRetry) {

return true;

}

return false;

}

Test Implementation

@Test(retryAnalyzer = RetryTestCase.class)

public void testMethod() {

// test code

}

This way, if the test fails, TestNG automatically reruns it according to the logic you define (max 3 times), helping to reduce flaky test failures caused by transient issues.

testng-failed.xml Feature

Alternatively, TestNG also generates a testng-failed.xml file after execution, which can be used to rerun only the failed tests separately. However, retryAnalyzer supports rerunning within the same execution flow.

In my projects, I have used this feature to improve test stability and reduce manual reruns, especially for UI tests prone to intermittent failures.

Can you differentiate between white-box, black-box, and grey-box testing?

White-box testing, also known as clear-box or structural testing, involves testing the internal logic, code structure, and implementation of the software. Testers require knowledge of the source code to design test cases that cover specific code paths, branches, or conditions. It’s usually done by developers and focuses on unit and integration testing.

Black-box testing focuses on validating the software’s functionality without any knowledge of the internal code or system design. Testers verify input-output behaviour against requirements or specifications. It includes functional, boundary value, equivalence partitioning, and usability testing, typically performed by QA testers.

Grey-box testing is a hybrid approach where testers have partial knowledge of the internal workings of the system. It combines both black-box and white-box testing techniques to design more effective test cases. Grey-box testing is often used in integration or security testing, where some system knowledge can help identify vulnerabilities or defects.

In summary, white-box tests the inside of the application, black-box tests the outside, and grey-box tests with partial knowledge of the internals.

Tell us more about black-box testing.

Black-box testing is a testing approach where the tester evaluates the functionality of the software without any knowledge of its internal code or implementation. There are several types of black-box testing, including:

Functional Testing: Focuses on verifying that the software functions according to specified requirements. Test cases are based on input-output behavior.

Boundary Value Analysis (BVA): Tests the values at the edges of input domains (e.g., minimum, maximum, just inside/outside boundaries) to catch errors at boundaries.

Equivalence Partitioning: Divides input data into equivalence classes where test cases from each class are expected to behave similarly, reducing the total number of test cases.

Decision Table Testing: Uses tables to represent combinations of inputs and corresponding actions or outputs, ensuring all possible conditions are tested.

State Transition Testing: Tests the system's behavior when transitioning between different states based on events or inputs. Useful for workflows or state-driven applications.

Exploratory Testing: An informal testing type where testers actively explore the application to identify defects without predefined test cases.

Usability Testing: Assesses how user-friendly and intuitive the application is from an end-user perspective.

These types help ensure comprehensive coverage of the software’s functionality from an end-user standpoint without looking at the internal workings.

Course

Services