Meet Fernway
Theory sticks when it has somewhere to live. For the rest of this book, you work at Fernway — a travel-booking service where every technique you learn will be applied to real screens, real rules, and real bugs. This page is your onboarding tour: the product, the people, and the handful of business rules that will carry hundreds of examples. No analogy needed here — this page is the concrete example.
The Product
Fernway lets travelers find and book places to stay. On the website or the mobile app, you search a destination, pick a check-in and check-out date, say how many guests are coming, browse the results, and book. Payment happens at checkout, and a confirmation email arrives a minute later. Travelers can view, change, or cancel their bookings from their account.
Two properties will appear in examples so often you'll feel like you've stayed at both: The Juniper Inn, a small mountain hotel, and Saltwater Lodge, a seaside one. When a page needs a concrete booking, it will be one of these — fixed names, so the examples accumulate instead of resetting.
The Team
Fernway's team is small enough to know everyone by name, and you will. Nadia is the engineering lead — she hired you after the double-discount weekend, and she's your mentor into the team. Omar builds the backend: the logic behind search, bookings, and payments. Lucy builds the frontend: everything you see and click. Petra is the product manager — she decides what gets built and writes the stories that describe it. And you are the company's first dedicated QA engineer. Until now, Fernway "tested by hoping": developers tried their own changes, and everyone hoped.
Being the first QA hire sounds intimidating and is actually one of the most common ways junior QA careers start — small companies add their first tester long after their first developer. It also means everything you introduce, from bug report habits to release checklists, will be the first of its kind there. This book is that first year, compressed.
The Rules You'll Test Against
Every booking product runs on business rules, and Fernway's are fixed for the whole book — the same numbers everywhere, so you can learn them once. A stay is 1 to 30 nights, for 1 to 8 guests. Cancellation is free until 48 hours before check-in; closer than that, only support can refund. The promo code SUMMER15 gives 15% off, works only on stays of 3 or more nights, and does not combine with the 10% member discount that logged-in members get automatically.
Read that paragraph again — slowly. Almost every rule in it has an edge (exactly 30 nights? exactly 48 hours?), and edges, you'll learn in Chapter 4, are where bugs live. That paragraph is the raw material for more test design than you'd believe.
Why a Booking App Is a Tester's Playground
Fernway wasn't chosen at random. A booking product contains, in one app, nearly every kind of testing challenge this book covers. Dates — with time zones, overnight boundaries, and daylight-saving traps. Money — prices, discounts, refunds, where every mistake has a dollar sign attached. Third parties — payments run through Paylane, a payment provider Fernway doesn't control, and emails through another outside service; the seams between systems are famous bug habitats. A mobile app with its own hostile physical world. And seasonal traffic spikes, when a summer sale brings ten thousand travelers in an hour. Each of these gets its chapter, and each chapter will have a natural Fernway example waiting.
Your Mission
Fernway has real users, real revenue, and — until you — no testing culture at all. Bugs are tracked in a shared tool as tickets numbered FW-something; you'll file many, and one of them, a sneaky date bug called FW-312, will follow us through half the book. Your mission for the chapters ahead: learn the craft, apply it to Fernway, and turn "testing by hoping" into testing on purpose. Next chapter: how software actually gets built — the process your new job lives inside.
- "I need to memorize all the Fernway rules now." You don't — every rule is restated wherever it's used. Learning them will happen by repetition, the same way you'd learn a real product on a real job.
- "This is a toy example, so the lessons won't transfer." Fernway's rules are modeled on real booking products — the ambiguities and edge cases are realistic on purpose. Swap the names and you've seen a real company's mess.
- "Being the first QA hire is an unusual, advanced situation." It's one of the most common junior realities: small companies add their first tester years into the product's life. The book prepares you for exactly that — and a team with existing QA is the easier version.
- Every example in the next eleven chapters stands on this page — the names, the rules, and the flow are the shared vocabulary between you and the book.
- The rules paragraph (1–30 nights, 1–8 guests, SUMMER15, the 48-hour cutoff) is the exact raw material Chapter 4 turns into professional test design — you'll watch plain sentences become dozens of precise checks.
- The first-QA-hire setup teaches the version of the job where you build the culture, not just join it — the strictly harder skill, and the more employable one.
Knowledge Check
Which of these is a correct statement of a Fernway booking rule?
- SUMMER15 gives 15% off any stay, regardless of length
- Cancellation is free until 48 hours before check-in
- The promo code and the member discount stack for members
- A stay can be any number of nights with no upper limit
Who owns deciding what gets built at Fernway?
- Nadia, the engineering lead
- Omar, the backend developer
- Petra, the product manager
- You, the QA engineer
Why is a booking app a particularly good product for learning testing?
- Because booking apps are simpler than other software
- It concentrates dates, money, third parties, mobile, and traffic spikes in one product
- Because Fernway is a real company whose bugs are public
- Because travel software rarely has bugs to find
What did "testing by hoping" mean at Fernway before you arrived?
- Developers tried their own changes, and nobody tested deliberately beyond that
- The team relied on a large suite of automated checks
- An external testing company checked each release
- Users were formally asked to test new features before release
You got correct