Test Data Management Causes Test Pollution in Parallel Runs
Your Appium test suite for a mobile banking app uses a shared test database. Tests create accounts, transfer funds, and check balances. When run sequentially, tests pass. When run in parallel on 3 devices, tests fail because they interfere with each other: one test's account creation affects another test's balance check. The test suite has 100 tests, and each test assumes a clean state. The database is reset before the suite starts, but not between tests. You have a limited number of test accounts (10) and cannot create new ones on the fly due to backend restrictions. The tests run on a CI pipeline that triggers on every commit. You need to ensure tests are independent and reliable.
1. What strategies would you use to isolate test data in parallel execution?
Read the worked answer
To isolate test data, each test should use its own set of data. Since you have only 10 test accounts, you can partition them: assign each parallel worker a unique subset of accounts. For example, with 3 devices, assign accounts 1-3 to device 1, 4-6 to device 2, and 7-9 to device 3, leaving account 10 as a spare. Ensure each test within a worker uses a different account from its subset, or reset the account state before each test. Alternatively, use a data generator that creates unique identifiers (e.g., random account numbers) within the allowed range, but since backend restrictions prevent new accounts, you can use virtual accounts or mock the backend for tests that don't require real transactions. Another approach is to run tests that modify data in a separate suite that runs sequentially, while read-only tests run in parallel. Use a test data management tool or a database snapshot/restore mechanism to reset the database to a known state before each test, but that may be slow. For the banking app, consider using a sandbox environment where you can create accounts freely. Also, implement a locking mechanism: tests acquire a lock on a specific account before using it, and release it after. Use a distributed lock (e.g., Redis) to coordinate across devices. Finally, design tests to be idempotent and independent of pre-existing data.
2. How would you modify the test suite to handle the limited number of accounts and ensure reliability?
Read the worked answer
Modify the test suite to use a data provider that assigns a unique account to each test based on the worker ID and test ID. For example, use a formula: accountIndex = (workerId * testsPerWorker + testId) % 10. This ensures each test gets a deterministic account. Before each test, reset the account state by calling a backend API or using a database query to set balance and clear transactions. If resetting is not possible, design tests to be additive: each test records its starting balance and verifies relative changes rather than absolute values. Use a setup method that logs in with the assigned account and a teardown that logs out and optionally resets. For parallel execution, configure the test runner to pass the worker ID to the tests. Use a test data service that manages account allocation and reset. Also, consider running tests that mutate data in a separate sequential job, and run read-only tests in parallel. Finally, add retries for tests that fail due to data conflicts, but only as a last resort.