Software Testing · A Day in QA
What Does a Software Tester Do on a Normal Work Day?
Quick summary — what a software tester does on a normal work day
On a normal work day, a software tester plans testing in the team stand-up, then tests new and changed features. The rest of the day goes to writing and running test cases, exploring for unexpected bugs, checking APIs and data, raising clear defect reports, verifying fixes, keeping automated regression healthy and telling the team what is risky before release.
In this guide you will learn:
- The hour-by-hour flow — from stand-up to end-of-day status.
- Core daily tasks — test design, execution, bug reports and retesting.
- How days differ — sprint start, mid-sprint and release day.
- Daily templates — a work log, a status note and a retest checklist.
- Interview questions — what interviewers ask about daily QA work.
SECTION 01A tester's day, hour by hour
Every company is different, but most testers in agile teams follow a similar rhythm. The day usually starts with a stand-up meeting of about fifteen minutes, where developers, testers and the product owner share what they did yesterday, what they will do today and what is blocking them. A tester uses this meeting to learn which stories are ready to test, which bug fixes have been deployed to the QA environment and whether anything urgent came in from production overnight.
After the stand-up comes focused testing time. The tester picks up the stories that are ready, reads the acceptance criteria again, runs the planned test cases and then explores beyond them. Afternoons often mix more testing with meetings — refinement sessions for upcoming work, a quick call to clarify a requirement, or pairing with a developer on a tricky defect. The day ends with updating the test management tool and the sprint board so everyone knows where quality stands.
| Time (typical) | Activity | What the tester produces | Who they work with |
|---|---|---|---|
| Start of day | Check overnight CI results and new bugs | List of failures to investigate | DevOps, developers |
| Morning stand-up | Share progress and blockers | Today's testing priorities | Whole scrum team |
| Late morning to afternoon | Execute and explore new features | Test results and defect reports | Developers, product owner |
| End of day | Retest fixes, update status | Test summary and board updates | QA lead, scrum master |
STAND-UP UPDATE (tester)
Yesterday:
- Finished testing STORY-412 (saved addresses): 18 cases, 2 bugs
- Retested BUG-2280, BUG-2284: both fixed and closed
Today:
- Test STORY-418 (coupon on checkout) once build 3.9.0 is on QA
- Add 3 regression cases for saved addresses
Blockers:
- QA environment payment sandbox returns 503 since 9 am
(raised with DevOps, ticket OPS-77)DAILY TEST LOG Date: __________ Build on QA: ________
Story / Bug Cases run Pass Fail Blocked New bugs
----------- --------- ---- ---- ------- --------
STORY-418 22 19 2 1 BUG-2301, BUG-2302
BUG-2295 3 3 0 0 -
Regression 40 39 1 0 BUG-2303
Notes:
- 1 case blocked: payment sandbox down (OPS-77)
- Exploratory session 45 min on coupon edge casesSECTION 02The core tasks inside a tester's day
Underneath the schedule are a handful of tasks that fill most of a tester's time. Test design means turning a requirement into test cases using techniques such as boundary value analysis, equivalence partitioning and decision tables. Test execution means running those cases and recording the results honestly — pass, fail or blocked. Exploratory testing means time-boxed, unscripted investigation where the tester follows their curiosity and tries the unexpected, which often finds the most interesting bugs.
Then come defect reporting and retesting. When something fails, the tester confirms it is reproducible, collects evidence such as screenshots, browser console errors or API responses, and raises a clear report. When the developer fixes it, the tester verifies the fix and checks nearby features for side effects. Many testers also check the database with SQL, call APIs directly in Postman and look after a set of automated regression tests.
| Task | What it involves | Common tools | Sign of doing it well |
|---|---|---|---|
| Test design | Writing cases from acceptance criteria | Test management tool, spreadsheets | Edge cases covered, not just happy path |
| Exploratory testing | Time-boxed sessions with a charter | Notes app, screen recorder | Finds bugs scripts would miss |
| Defect reporting | Steps, evidence, severity, environment | Jira or a similar tracker | Developers rarely need to ask questions |
| API and data checks | Calling endpoints and querying tables | Postman, SQL client, browser DevTools | Finds the layer where the bug lives |
EXPLORATORY TESTING CHARTER
Explore : Coupon field on the checkout page
With : Expired, lowercase, spaced and stacked coupons
To find : Wrong totals, unclear errors, coupons that should not apply
Time box: 45 minutes
Session notes:
- ' SAVE10 ' with spaces: accepted (good)
- 'save10' lowercase: rejected -> ask PO if expected
- Two coupons: second silently replaces first -> BUG-2302
- Expired coupon: error text says 'Server error' -> BUG-2301# Check the cart API directly while testing the UI
curl -s -X POST https://qa.example.test/api/cart/coupon \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $QA_TOKEN" \
-d '{"cartId": "c-1029", "code": "EXPIRED5"}' \
-w "\nHTTP status: %{http_code}\n"
# Expected: HTTP 422 with a clear message, for example
# {"error": "COUPON_EXPIRED", "message": "This coupon has expired"}
# Actual : HTTP 500 -> include this in BUG-2301SECTION 03How a tester's day changes across the sprint
Not every day looks the same. At the start of a sprint, testers spend more time in planning and refinement, asking questions about acceptance criteria and designing test cases before any code is ready. This early involvement — sometimes called shift-left testing — prevents defects instead of only finding them later. In the middle of the sprint, the day is mostly execution: new builds arrive, stories move to testing, and bugs go back and forth with developers.
Near release day, the focus shifts to regression, smoke tests and risk. The tester checks that the automated suite is green, runs any manual regression that is not automated, confirms critical fixes and writes a clear summary of what was tested, what was not and which known issues remain. After release, a quick smoke test in production and a look at monitoring or support tickets close the loop. Some days also include bug triage meetings or a sprint retrospective.
| Sprint phase | Main focus | Typical meetings | Key output |
|---|---|---|---|
| Sprint start | Understanding stories, designing tests | Planning, refinement | Test cases and open questions |
| Mid-sprint | Executing tests, raising and retesting bugs | Stand-up, quick dev syncs | Defects and test results |
| Pre-release | Regression, smoke tests, risk review | Bug triage, go/no-go | Test summary report |
| After release | Production smoke check, learning | Retrospective | Improvement actions |
RELEASE SMOKE TEST (15 minutes, production)
[ ] Home page loads, no console errors
[ ] Login and logout work
[ ] Search returns results
[ ] Add to cart, change quantity, remove item
[ ] Apply a valid coupon, total updates
[ ] Checkout reaches payment page (do not complete real payment
unless a test method is approved)
[ ] Order history page loads for test account
[ ] Version number in footer / health endpoint matches release# Run the automated regression suite before release
# Playwright (JavaScript/TypeScript project)
npx playwright test --grep @regression --reporter=html
npx playwright show-report
# Or a pytest-based suite (Python project)
pytest -m regression --maxfail=5 -q
# Or a Maven + TestNG Selenium suite (Java project)
mvn test -Dgroups=regressionSECTION 04Templates for a tester's daily work
These three templates mirror the documents testers actually write every day; practising them during training makes your first job feel familiar.
END-OF-DAY STATUS (post in team channel)
Build tested : ________
Stories : ________ done | ________ in progress
Cases run : ___ pass | ___ fail | ___ blocked
New bugs : ________ (critical: ___)
Retested : ________ (closed: ___ reopened: ___)
Risks : ______________________________
Tomorrow : ______________________________RETEST CHECKLIST (when a bug is marked fixed)
[ ] Fix is deployed to the environment I am testing
[ ] Build number matches the one in the bug ticket
[ ] Original steps no longer reproduce the bug
[ ] Tried 2-3 variations of the original steps
[ ] Checked nearby features for side effects
[ ] Added or updated a regression test case
[ ] Closed with a short comment, or reopened with new evidenceTEST SUMMARY (end of sprint or release)
Scope tested : ________________________
Not tested : ________________________ (and why)
Environments : ________________________
Results : ___ cases | ___% passed
Open defects : critical __ | major __ | minor __
Known issues : ________________________
Recommendation : Release / Release with risks / Do not release
Signed off by : ________ Date: ________SECTION 05Tips for handling a tester's day well
Good testers are recognised less for the number of bugs they find and more for how they work:
- Ask questions early — a ten-minute requirement clarification can save days of rework.
- Protect focus time — block an hour or two for deep testing between meetings.
- Write bugs for strangers — assume the reader has never seen the feature before.
- Report risk, not just numbers — say what you could not test and why it matters.
- Keep learning small skills — one SQL query or automation trick each week adds up.
SECTION 06Interview Q&A — a tester's daily work
Q1Walk me through your typical day as a tester.
I start by checking overnight automation results and new bugs, then join the stand-up to agree priorities. Most of the day goes to executing and exploring new stories, raising clear defects and retesting fixes. I finish by updating the test tool and posting a short status with risks.
Q2What do you do when a bug cannot be reproduced?
I recheck the environment, build, test data, browser and user role, then look at logs or API responses for clues. I note exact timestamps, try variations and, if still unclear, record it as intermittent with all evidence so the developer can investigate with the same details.
Q3How do you decide what to test when time is short?
I use risk-based prioritisation: core user journeys, recently changed code, areas with a history of defects and anything involving money or data. I tell the team clearly what I tested and what I skipped, so the release decision is informed rather than assumed.
Q4What is exploratory testing and when do you use it?
It is simultaneous learning, test design and execution within a time-boxed session guided by a charter. I use it for new features, after scripted cases pass, and around risky changes, because it finds issues that pre-written cases often miss.
Q5How do you handle a developer who says a bug is not a bug?
I go back to the requirement or acceptance criteria and share evidence calmly. If the requirement is unclear, I involve the product owner to decide expected behaviour. The goal is agreement on what the user should experience, not winning an argument.
SECTION 07Test yourself — a software tester's day
Five questions. No sign-up.
0 / 5Pick an answer to see why it is right or wrong.
SECTION 08Frequently asked questions
What does a software tester do all day?
A software tester joins planning meetings, reads requirements, designs and runs test cases, explores features for unexpected issues, raises defect reports with evidence, retests fixes, checks APIs and data, and shares status updates so the team knows the quality and risk before release.
Is software testing a boring job?
It can feel repetitive if it is only scripted clicking. Most modern QA roles mix exploration, problem-solving, API and data checks, automation and teamwork with developers and product owners, which keeps the work varied and intellectually demanding.
How many hours does a software tester work per day?
Testers usually work standard office hours for their company. Release periods or production issues can occasionally mean longer days, depending on the team. Ask about release practices and on-call expectations during interviews.
Do software testers write code every day?
Manual testers may write little code, though SQL queries are common. Automation testers and SDETs write and maintain test code regularly. Many roles today mix both, so basic programming skill helps almost every tester grow.
Do software testers work with developers directly?
Yes. Testers talk with developers daily to clarify behaviour, reproduce defects, verify fixes and plan testing for upcoming changes. Good working relationships and clear, respectful communication are a big part of being effective in QA.
SECTION 09Related reads
Classroom & online · Noida
Get ready for a real tester's work day
Our Software Testing Course covers test design, execution, defect reporting, SQL, API testing and automation basics through practical, job-style exercises in Noida, Delhi and live online.
Talk to a counsellor for current fees- Real test case & bug report practice
- API and SQL checks
- 1:1 mock interviews
- Weekday & weekend batches