Take-Home Assignments

Step 1: understand the assignment

Read the email and any attached brief twice, and write down:

• Scope: which product, which features or pages? “The ordering flow” means search, menu, cart, checkout and confirmation, not the blog.
• Deliverables: bug reports only, or test cases too? A test plan? A summary?
• Format: a document, a spreadsheet, a Jira project they invite you to, a specific template? Use it exactly.
• Environment: a stagingStagingA pre-release environment that mirrors production as closely as possible.Open in glossary → link, a test build through TestFlightTestFlightApple's service for distributing beta builds of iOS apps to testers before App Store release.Open in glossary →, an APK? Any test accounts or test cardsTest cardA card number published by a payment provider to simulate payments in test mode.Open in glossary →?
• Deadline and effort: “48 hours” is the deadline; “about four hours” is the effort they expect. These are different.

Step 2: plan your time

A realistic plan for “about four hours of work”:

Two things people forget: writing takes as long as testing, and a short break before the final read-through catches embarrassing mistakes.

Should you work longer than they ask? A little extra polish is fine. Spending thirty hours on a four-hour task can backfire: it sets an expectation you can’t keep on the job, and reviewers may wonder whether you can scope work. If you do more, say so honestly in the summary (“I spent about six hours”).

Step 3: write a short test approach

Half a page, before you start testing. It keeps you focused and becomes part of your submission. It’s a mini test plan.

## Test approach
Scope (in): search, restaurant menu, cart, coupon, checkout, order confirmation.
Scope (out): account settings, blog, careers page (not in the brief);
  load and security testing (not allowed on a shared environment).
Priorities (by risk): 1. paying and placing an order  2. cart totals and coupons
  3. search and menu  4. mobile layout  5. visual details.
Environment: Chrome 130 and Safari 18 on macOS; iPhone 15 Safari; Android Chrome
  (Pixel emulator); viewport 360 px.
Techniques: main happy paths first, then negative and boundary cases on inputs
  (quantity, coupon, address); a 45-minute exploratory session on checkout.
Data: test account from the brief, test card 4242 4242 4242 4242 (from the brief).

The test card number above stands in for whatever the brief gives you. Never use a real card.

Step 4: test, risk first

Start with the main flow a customer takes from start to finish. If that breaks, nothing else matters. Then go deeper on the riskiest areas:

• Money: totals, discounts, taxes, delivery fees, double submissions, refunds.
• Data: forms that save addresses or profiles, what happens on refresh or Back.
• Access: login, logout, sessions, other users’ data.
• Inputs: empty, too long, special characters, boundariesBoundary value analysisTesting values at and just around the edges of valid ranges, where bugs love to hide.Open in glossary → like 0, 1, max and max + 1.
• Mobile and responsive: small screens, rotation, slow network.

Use the techniques you know: equivalence partitioningEquivalence partitioningSplitting inputs into groups that should behave the same, then testing one value from each group.Open in glossary →, boundary values, exploratory testingExploratory testingLearning, designing and running tests at the same time, guided by curiosity and a goal.Open in glossary → with a charter, error guessingError guessingChoosing tests based on experience of typical mistakes developers make.Open in glossary →. Take notes as you go; screenshots and short screen recordings save you from “how did I get here?” later.

Step 5: choose and order your bugs

You’ll usually find more than you have time to write up. Decide what goes in and how:

• Full report for anything Critical, Major or Minor that a developer needs to act on. Rate severitySeverityHow much damage a bug does to the product or the user.Open in glossary → honestly; see Severity vs Priority.
• One-liners in an “Other observations” list for trivial issues: typos, small alignment problems, inconsistent colors.
• Questions for things that might be intended: “Coupons don’t combine. Is that by design?”
• Leave out anything you got by stepping outside the rules (see Ethics below).

Then sort by severity, most serious first. The reviewer should see your best finding in the first ten seconds.

Step 6: write clean bug reports

Each full report follows the format from How to Write a Bug Report. For a take-home, make sure every one has:

• A title that says where, what and when: “Checkout: retrying after ‘Payment failed’ charges the card twice”.
• Environment: browser or device, OS, viewport, build or URL, test account.
• Numbered steps someone else can follow without you.
• Expected and actual result, separately.
• Severity (and priority if they ask), with one line of reasoning for anything Critical.
• Evidence: a screenshot or short recording; console errors or network responses from DevToolsDevToolsDeveloper tools built into browsers for inspecting pages, network traffic and errors.Open in glossary → if relevant.
• How often: “3 of 3 tries” or “1 of 5”.

If they asked for test cases, write a handful of strong ones for the main flows, in the format from How to Write Test Cases, rather than a hundred thin ones.

Step 7: present the results

Put a short summary at the top of your submission. A reviewer who reads only this should know what you did and what you found.

## Summary
I tested the ordering flow (search to order confirmation) for about 4.5 hours
on desktop Chrome/Safari, iPhone Safari and Android Chrome.

Most important findings:
1. CRITICAL: retrying after "Payment failed" charges the card twice (3/3 tries).
2. MAJOR: search is case-sensitive; "pizza" finds 0 results, "Pizza" finds 6.
3. MAJOR: on phones (360 px) the cookie banner hides "Place order" and can't be closed.

In total: 1 critical, 3 major, 4 minor bugs (full reports below),
plus 6 trivial observations (list at the end).

Not tested, and why:
- Account settings, blog, careers page: outside the scope of the brief.
- Load and security testing: not appropriate on a shared environment.
- Older browsers and tablets: no devices available; would be next.

Questions and assumptions:
- I assumed coupons are not meant to combine. Is that correct?
- The brief didn't mention German, but the site offers it, so I did a short check.

The “Not tested, and why” section is what separates a professional from a beginner. It shows you know testing is never complete and that you made choices on purpose.

Mistakes that fail candidates

Ethics: what you must not do

You’ve been given access to someone else’s system. Behave as you would on the job, where breaking these rules could get you fired or worse.

If the assignment points you at a live website (productionProductionThe live environment that real users use.Open in glossary →), be extra careful: real customers and real businesses use it. Don’t place real orders or send messages to real people; describe what you would test instead. If you’re unsure whether something is allowed, ask before you do it.

Worked example: a FoodDash take-home

Imagine the Capstone brief arrived as a take-home: “Here’s FoodDash 2.0, build 412. Please test the release and send bug reports, a few test cases for checkout, and your recommendation. About four hours.” The Capstone is built exactly like this, so it’s the best practice you can get. Here’s what a strong submission could look like.

After you finish the Capstone, you’ll have your own version of this: plan, test cases, bug reports and a summary you can show (in your own words) in a portfolio.

A template you can copy

# <Company> take-home: <product>, <build or URL>
Candidate: <name> · Time spent: <hours> · Date: <date>

## 1. Summary
<What you tested, on what, for how long. Top 3 findings. Recommendation if asked.>

## 2. Scope and approach
In: <...>   Out: <...> (why)
Priorities: <risk order>
Techniques: <happy paths, boundaries, exploratory charter...>

## 3. Environment and data
<devices, OS, browsers, viewport, build, accounts, test cards>

## 4. Bug reports (most severe first)
### BUG-1 <Area>: <what happens> when <condition>
Severity: <Critical/Major/Minor> · Reproducible: <3/3>
Environment: <...>
Steps: 1. ... 2. ... 3. ...
Expected: <...>
Actual: <...>
Evidence: <screenshot/video link>

## 5. Test cases (if requested)

## 6. Not tested, and why

## 7. Questions and assumptions

## 8. Other observations (trivial, one line each)