Curated interview practice questions with answers. These are practice scenarios, not a verified list of past interview questions.
About Workday hiring for Software Testing roles
Workday is an enterprise cloud software company that provides applications for human resources, finance, planning and payroll. Large organisations use its platform to manage employees, hiring, financial accounting and analytics. It has a growing India presence that hires software engineers, quality engineers, data engineers and support roles, and many organisations also hire Workday functional and technical consultants.
For Software Testing roles, this Workday practice set focuses most on Agile, SQL and API Testing (9), Test Case Design (7), Testing Types (5), Performance and Security Basics (4). It has 2 easy, 33 medium, 5 hard questions, so you can start easy and work up to the harder ones.
Company type
Product
Headquarters
Pleasanton, California, USA
Main India offices
Pune
Workday Software Testing interview process
Online coding assessment
Technical round 1 (DSA)
Technical round 2 (design or domain)
Hiring manager and behavioural round
Typical pattern based on public candidate experiences. Rounds vary by role, team and year.
Solved for WorkdayStart practicing
3 QUESTIONS FREESign up to unlock the full question bank and track your progress.Unlock every question and answer, then continue practising company-wise and package-wise.
✓ 3 questions free • Unlock the rest in seconds
01
A page loads slowly only for some users. How do you investigate as a manual tester?
Collect details from affected users: location, device, browser, network and time. Try to reproduce with similar conditions using browser network throttling. Use the browser developer tools network tab to find slow requests, large files or failing calls, and compare with a fast user. Check whether those users have more data, like a long order history. Share the slow request, timing and conditions in the bug for the developers.
Moves to the chosen floor, doors open and close, door sensor stops closing on obstruction, overload alarm, emergency button, behaviour in a power cut, max capacity and the floor display.
03
What is normalization and why should a tester understand it?
Normalization organises tables to reduce duplicate data, for example storing the customer address once in a customers table instead of repeating it in every order. Testers should understand it because it explains where data lives and which joins are needed to verify a screen. It also shows risk: in a denormalized report table, the same value is copied in many places, so updates must be tested to confirm every copy changes.
Check that buttons and icons are large enough to tap without hitting neighbours: Android guidance is 48 by 48 dp and iOS is 44 by 44 points. Test with large font settings and one-handed use. Any action using complex gestures, such as swipe to delete or pinch, must have a simple tap alternative. Then turn on TalkBack and VoiceOver and confirm each control can be focused, named and activated.
08
What is a sprint planning meeting and what does QA contribute?
Installation testing checks that software installs correctly on supported systems: fresh install, custom paths, low disk space, missing prerequisites and clean uninstall. Upgrade testing checks moving from an older version to the new one: user data and settings must be kept, database migrations must run, and the app must work after the upgrade. Also test skipping versions, such as 1.2 to 1.5, and what happens if the upgrade is interrupted.
12
A manager says the app has 50,000 daily users, so the load test must run 50,000 virtual users at once. How do you respond?
Explain that daily users are not concurrent users. Of 50,000 users a day, only a fraction are active at the same moment, and even they pause between actions because of think time. Use analytics to find the real peak concurrency and request rate, for example 1,500 concurrent users at peak hour, and model that with a safety margin. Running 50,000 users clicking at once tests a load that never happens and wastes effort.
13
How do you reduce the number of defects slipping into production?
Reopen the bug when the same issue, with the same steps and expected result, still fails after the fix. Log a new bug when the fix works but a different problem appears, even in the same screen, or when the original bug has already been closed in a past release. Link the new bug to the old one. Mixing different problems in one reopened ticket confuses tracking and metrics.
15
A developer changed a shared header component used on every page. What testing do you plan?
Retest the change itself, then run a focused regression on every page type that uses the header: home, listing, detail, checkout and account. Check navigation links, search, login and logout state, cart count and the mobile menu. Do cross-browser and responsive checks because layout changes affect all sizes. A quick visual comparison against the previous build helps spot alignment issues across many pages.
Find the documented limit, for example 100 requests per minute per key. Send requests just below and above the limit and check that extra requests get 429 Too Many Requests with a Retry-After header. Verify the counter resets after the window and that limits apply per key or per IP as designed. Check that one user hitting the limit does not block others, and that normal traffic is not throttled.
Model answer: Situation: a new leave management module had passed all scripted cases. Task: I had a one-hour exploratory session. Action: I applied leave, then changed my manager in the profile while the request was pending. Result: the request disappeared for both managers and could never be approved. It was fixed before release, and the team added role-change scenarios to the regression suite.
Trigger the email from each event, such as signup or order placed, and verify it arrives at the right address within the expected time. Check subject, sender name, personalised fields, amounts and links. Click every link and confirm it opens the right page. Check the layout on desktop and mobile mail apps, the unsubscribe option where required, and that no email is sent for failed or cancelled actions. Use a test mailbox tool in QA.
21
Write a simple Playwright test in TypeScript that logs in and checks the dashboard heading.
Use the platform's sandbox or test accounts so no real money is charged. Test a successful purchase, cancellation, payment failure, pending payment, refund and restoring purchases on a new device. For subscriptions, test free trial, renewal, upgrade, downgrade, expiry and grace period, often with shortened test durations. Verify the server records the purchase and unlocks features, and that killing the app mid-purchase does not lose it.
23
How do you test an application with no documentation?
Talk to developers and users, explore the product, review similar systems, create notes and mind maps, confirm assumptions and write test cases as you learn.
24
Notifications arrive late, and some screens look broken, only on certain Android phone brands. Why can this happen and what do you test?
Android phone makers ship their own skins and settings on top of Android, so the same app can behave differently. Common problems are aggressive battery savers that kill background tasks and delay notifications, different permission screens, custom fonts and display scaling, camera differences and modified WebViews. Pick devices from the brands most used by your audience and test background work, notifications, camera and layout on each.
25
What is the OWASP Top 10 and why should testers know it?
The OWASP Top 10 is a widely used list of the most critical web application security risks, published by an open community project. It includes broken access control, cryptographic failures, injection, insecure design, security misconfiguration, vulnerable components and authentication failures. Testers use it as a checklist to include basic security checks in their testing and to speak the same language as security teams.
A memory leak happens when an application keeps holding memory it no longer needs, so usage grows the longer it runs. A manual tester may notice the app getting slower over a long session, a browser tab using more and more memory in Task Manager or the browser's memory panel, or a mobile app crashing after repeatedly opening and closing a screen. Report the steps, duration and memory readings over time.
Verify each status change appears in order: placed, accepted, preparing, picked up and delivered. Check the rider's location updates on the map at the expected interval. Test the estimated time updates when there is a delay. Verify notifications for each status. Check behaviour when the network drops and recovers, when the app is reopened, and when the order is cancelled midway. Confirm tracking stops after delivery and the rating screen appears.
30
SQL: verify that row counts and totals match between a source table and a target table after a data load.
-- Compare counts and sums side by side; both columns must match
SELECT
(SELECT COUNT(*) FROM staging_orders) AS src_count,
(SELECT COUNT(*) FROM dw_orders) AS tgt_count,
(SELECT SUM(amount) FROM staging_orders) AS src_amount,
(SELECT SUM(amount) FROM dw_orders) AS tgt_amount;
List conditions and actions in a table and cover every combination of conditions (rules) — ideal for business rules like loan approval: salary > X AND credit score > Y → approve.
Model answer: To me quality means the product does what users need, reliably, and is easy to use, not just that test cases pass. In my final-year project I tested a library app; all features worked, but students struggled to find the search option. I reported it as a usability issue and the team moved search to the home screen. That taught me to test from the user's point of view as well.
Won't Fix means the bug is acknowledged as real, but the team decides not to fix it, usually because the impact is very low, the feature is being retired or the cost of fixing is higher than the benefit. The decision is made by the product owner, often in triage with dev and QA leads. The tester should make sure the reason is recorded and, if user-facing, documented as a known issue.
Yes, very likely. An index lets the database find rows quickly, like the index of a book. With a small QA table, a full table scan is still fast, but with millions of production rows it becomes slow. Compare indexes on the searched columns in both environments and ask a developer to check the query plan. Test key queries on production-size data in staging, and include data volume in future performance checks.
Enable developer options and USB debugging, connect the phone and confirm it is visible with adb devices. Clear old logs with adb logcat -c, reproduce the bug, then save logs with adb logcat -d > crash_log.txt, filtering by the app package or error level if needed. For a crash, search for FATAL EXCEPTION. Attach the log, device model, OS version, app version and a screen recording to the bug.
Tips to crack the Workday Software Testing interview
Practise DSA problems and object-oriented design, and be ready to explain your reasoning clearly while coding live.
Learn basic HR and finance business processes, which helps you understand how Workday applications are used by customers.
Prepare behavioural stories showing collaboration and customer focus, since Workday highlights its people-first culture and core values.
Keep a one-minute story ready for every project on your CV: problem, your part, tools, result.
Practise the hard questions on this page aloud; Workday interviewers usually ask follow-ups on your first answer.
Frequently asked questions
How many rounds are there in the Workday Software Testing interview?
Candidates usually go through 4 stages: Online coding assessment; Technical round 1 (DSA); Technical round 2 (design or domain); Hiring manager and behavioural round. The exact rounds change with the role, team, location and your experience, so confirm the process with the recruiter.
Which topics should I prepare for the Workday Software Testing interview?
This practice set leans on Agile, SQL and API Testing (9), Test Case Design (7), Testing Types (5), Performance and Security Basics (4). Revise those first, then practise explaining one or two of your own projects end to end, because most Workday interviewers ask you to walk through real work.
Are these the exact questions asked at Workday?
No. These are curated practice questions that match the skills and difficulty usually tested in product interviews like Workday's. They are not a leaked or verified list of past questions.
Where does Workday hire Software Testing professionals in India?
Workday has large teams in Pune. Openings and locations change often, so check the Workday careers page and filter by city and experience.