Nimbus Workshops

My bookings

-

Exam brief

You are the QA team for Nimbus Workshops, a portal where people browse training workshops and book seats. It goes live tomorrow. Test it end to end and tell us whether it is ready.

Everything you need is on this page. The Catalog and My Bookings tabs are the product. This tab has the reference material and your API tasks. The Request Log tab shows the API calls you make from Postman.

1 · Write a test plan first

Before you touch the app - about half a page:

• Scope - what you will and will not test
• Approach - how you'll test each area, and the data you'll use
• Risks - what worries you most about this going live
• Environment & tools

2 · Test the application

Cover all of these:

• UI / visual - layout, alignment, spacing, consistency, hover and selected states, empty states
• Responsive - check desktop, tablet and mobile widths (use the browser's device toolbar). Something may look fine at one width and break at another, including the tablet range specifically, and inside dialogs.
• Copy - wording, labels, spelling
• Accessibility - keyboard-only navigation, focus behaviour in dialogs, form labels, colour contrast, heading structure
• Functionality, end to end:
  • Catalog: search, the category / level / max-price filters, the "hide sold out" toggle, sorting, and the "showing X of Y" count
  • Booking: seat quantity, the per-attendee name fields, per-seat price, discount codes, VAT, total, input validation, the confirmation
  • Workshop details - click a workshop title to open its dialog
  • My Bookings: the booking details dialog (click a row), change seats, cancel, the All / Confirmed / Cancelled filter, sorting, and the summary line
  Check the numbers, and check that lists stay in sync after an action.

3 · Test the API with Postman

Work through every task below in order. Part A is reads, Part B is writes and error cases, Part C is an ordered chain - run it exactly as written, then read GET /api/exam/summary and record the signature and perWorkshop values for your report.

4 · Log every defect in Jira

One ticket per defect:

• A clear, specific title
• Numbered steps to reproduce
• Expected result vs actual result
• Severity, with a reason
• A screenshot where it helps; note the browser and screen width

"The site is broken" is not a bug report. Duplicates don't count. Log bugs as you find them - don't save them for the end.

Also log feature requests, not just bugs. Not everything worth flagging is broken - some things work exactly as built but are still a bad experience. That's a feature request / UX improvement suggestion, not a defect: same ticket discipline (clear title, why it matters, what you'd change), just no "steps to reproduce a failure" because nothing failed.

Example: clicking a workshop's title opens its details dialog, but that's easy to miss - nothing about the rest of the card looks clickable. A feature request for this: "Make the entire workshop card open the details dialog, not just the title text, so the interaction is easier to discover." Log a few of these alongside your bugs - real client work is full of them.

5 · Deliver a test summary report

One page at the end:

• What you tested, and what you didn't get to
• Defects grouped by severity
• Your API Part C result (the signature and perWorkshop)
• Your recommendation: go or no-go for tomorrow's release, with reasons

Templates

Never written one of these before? Open a template, copy it, paste it into your own doc, and fill in the blanks. This is the same shape a real client engagement expects.

Rules

• Work on your own.
• If the data gets into a confusing state, tell your trainer - they can reset it.
• You are graded on: defects found, quality of your bug reports, the API tasks, your test plan, and your final report and recommendation.

Reference

Currently advertised discount codes - enter them in the Promo code field on the booking screen:

• NIMBUS20 - 20% off your booking
• WELCOME10 - 10% off your first booking
• EARLYBIRD - 15% off (early-bird promotion; it has ended)

VAT is 9%, applied after any discount. Prices shown are per seat. A booking reference looks like REF-5xxxx. Seats per booking: 1-10.

Saving a value between requests (copy-paste, no scripting needed)

A few tasks below ask you to reuse the id from one response inside a later request's URL. You don't need to understand how - just follow these steps and copy the box below exactly as it is:

1. First, make sure you have a Postman Environment selected - look at the dropdown near the top-right of the window (it says "No Environment" if you don't have one yet). If it says that, click it, choose Add, give it any name (e.g. "Exam 1"), save, then pick it from that same dropdown so it's the active one. You only need to do this once, ever - every request from here on can use it.
2. Send the request that creates the thing (a POST) once, so you can see it worked.
3. In that same request, look at the row of tabs under the URL bar (Params, Authorization, Headers, Body...) and click Scripts (older Postman: Tests).
4. You'll see two boxes, Pre-request and Post-response. Click into the Post-response box (the bottom one) and paste this:

5. Click Send again. Postman now remembers that id under the name myId - you'll see nothing change on screen, that's normal.
6. In any later request, type {{myId}} anywhere you'd normally type that number - e.g. the URL becomes /api/exam/bookings/{{myId}}. Postman fills in the real number for you automatically.

Need to remember more than one id at the same time (the Part C chain does)? Use a different name each time - change the word myId in the script (both places it appears) to chainA, then chainB, then chainC for the three things you create in that task - then use {{chainA}} etc. to match whichever one you need.

API reference - base /api/exam

API tasks

Exam API request log /api/exam/* - your Postman / curl calls (the page's own calls are hidden)