Your First Manual QA Testing Cycle

Run a full manual QA cycle on a real e-commerce app and file bugs in Jira.

Introduction

30 Second Summary

Every app you use has been tested by someone. When your banking app crashes mid-transfer or an online store charges you twice, that's a gap in testing.

In this project, you will complete a full manual testing cycle on a real e-commerce web application. You'll write professional test cases, execute them systematically, and file real bug reports in Jira.

What You'll Build

You'll pull up your test case spreadsheet showing Pass/Fail results, open your Jira board with properly filed defects, and demonstrate exactly how you work as a QA tester.

By the end of this project, you'll have:

A structured test plan covering Login, Product Catalog, Cart, and Checkout modules that you can walk through in an interview.
Professional test cases with preconditions, numbered steps, and expected vs actual results documented in Google Sheets.
Real bug reports filed in Jira with reproduction steps, screenshots, and severity/priority classifications that a developer could act on.
Secret Mission: Perform exploratory testing on a glitchy user account and deliver a test summary report with pass rate metrics and stakeholder recommendations.

Are there any prerequisites?

You'll need Google Chrome and a Google account (for Google Sheets). Basic familiarity with web browsers and spreadsheets is all that's required.

No coding experience is needed for this project. You'll sign up for a free Jira account during Step 1 with no credit card required.

Before We Start

Before we dive in, let's get clear on what you're about to do and why it matters. You'll complete a full manual testing cycle on a real e-commerce web application, following the same structured process QA testers use on their first day on the job.

Set Up Your Tools

Professional QA testers don't keep their findings in random notes or in their heads. They use dedicated tools to document test cases and track bugs in a way that developers can actually act on.

In this step, you'll set up three things: Jira for tracking bugs, Google Sheets for documenting test cases, and SauceDemo as the application you'll test.

In this step, get ready to:

Create a Jira project for tracking bug reports.
Set up a Google Sheets test case template with structured columns.
Confirm SauceDemo loads in your browser and displays test credentials.

Sign up for Jira Free and create your QA project

Jira is the industry-standard tool for tracking bugs and managing software projects. You'll use it to file professional bug reports that a developer could pick up and fix.

Open the Jira Free signup page in a new tab:

https://www.atlassian.com/try/cloud/signup?bundle=jira-software&edition=free

Click Sign up with Google (or use Microsoft, Apple, or Slack if you prefer). No credit card is required.
When prompted to name your site, enter something like yourname-qa (for example, jordan-qa). This becomes your Jira site URL.
Complete any onboarding questions Jira asks. These help tailor the interface but don't lock you into anything.

What is Jira?

Jira is a project management tool by Atlassian used by software teams worldwide. QA testers use it to file bug reports, track defects through their lifecycle (open, in progress, resolved, closed), and communicate with developers. It appears in virtually every entry-level QA job listing.

Once you're inside Jira, you need to create a project to hold your bug tickets.

In the left sidebar, hover over Spaces and click the + icon (or click Create space).
Browse the available templates and select either Scrum or Kanban. Both work for this project.
Click Use template.
Name your project SauceDemo QA.
Click Create.

Why does Jira say Spaces instead of Projects?

Atlassian recently renamed "Projects" to "Spaces" in the Jira interface. They function the same way. When you see "Spaces" in the sidebar, think "Projects." Throughout this project, we'll call it a project since that's the QA industry term.

You should now see an empty board (either a Scrum backlog or a Kanban board) with no tickets. This is where your bug reports will live.

Don't see the Create space option?

Make sure Spaces is visible in your left sidebar. If it's missing, click Customize navigation bar at the bottom of the sidebar and enable Spaces. Since you created the site, you are the admin and have full permissions.

help me find the Create space option in Jira

Create your test case template in Google Sheets

Test cases need a structured format so you can track what you tested, what should have happened, and what actually happened. A spreadsheet gives you that structure.

Open Google Sheets at sheets.google.com and create a new blank spreadsheet.
Rename the spreadsheet to SauceDemo Test Cases by clicking on "Untitled spreadsheet" in the top left.
In Row 1, add these column headers (one per cell, starting from A1):

Test Case ID | Module | Test Scenario | Preconditions | Test Steps | Expected Result | Actual Result | Status | Notes

What do these columns mean?

Test Case ID is a unique identifier like TC_001.
Module groups tests by feature area (Login, Cart, Checkout).
Preconditions lists what must be true before the test starts (e.g., "User is logged in").
Expected Result is what should happen if the app works correctly.
Actual Result is what you observe when you run the test.
Status is PASS or FAIL based on whether actual matches expected.

Your spreadsheet should now have nine column headers across Row 1 with no data rows yet. This is your test case template ready to fill in.

Not sure if your headers are right?

Double-check you have exactly 9 columns starting from A1. Each header should be in its own cell (don't paste them all into one cell with pipe characters). The pipe symbols above are just separators showing you the column order.

help me set up my test case spreadsheet columns correctly

Confirm SauceDemo loads in Chrome

SauceDemo is a demo e-commerce application built by Sauce Labs specifically for testing practice. It has intentional bugs for you to find.

Open a new Chrome tab and navigate to:

https://www.saucedemo.com/

Before you look at the page, what do you expect a login page for a testing demo to show?

Confirm you see the login form with a Username field, a Password field, and a Login button.
Below the form, confirm you see a list of accepted usernames: standard_user, locked_out_user, problem_user, and others.
Confirm you see the shared password displayed: secret_sauce.

Why are credentials displayed on the page?

SauceDemo is a purpose-built testing sandbox. The credentials are shown publicly so anyone can practice testing without needing to create an account. Each username triggers different app behavior. For example, problem_user causes broken images and glitchy sorting.

Your workspace is ready. You have a bug tracker, a test case template, and a test target. Next up, you'll explore SauceDemo like a real user and identify exactly what needs to be tested.

Explore SauceDemo and Identify Test Scenarios

Your testing workspace is ready. You have a Jira board waiting for bugs, a spreadsheet with column headers, and SauceDemo loaded in your browser.

Before writing test cases, you need to understand what the application actually does. Systematic exploration reveals all the modules and features you need to cover, so you can write test scenarios that leave no area untouched.

In this step, get ready to:

Navigate through every page of SauceDemo as a standard user.
Document test scenarios grouped by module in a new spreadsheet tab.
Label each scenario as a positive or negative test.

Log in and explore every page of SauceDemo

A QA tester's first job on any new application is to walk through it like a user would. This mental map of pages, buttons, and form fields becomes the foundation for your test scenarios.

Switch to the SauceDemo tab in Chrome (still on the login page from Step 1).
Enter standard_user in the Username field.
Enter secret_sauce in the Password field.
Click the Login button.

You should now see the inventory page titled Swag Labs showing a grid of product cards with images, names, descriptions, prices, and Add to cart buttons.

What is Swag Labs?

Swag Labs is the name of the fictional e-commerce store that SauceDemo simulates. It sells backpacks, bike lights, t-shirts, and other swag items.

Sauce Labs (the real company) built it specifically for QA testers to practice on. It has intentional bugs baked in for exactly this purpose.

Now walk through the rest of the application to visit every major page.

Click on any product name or image to open a product detail page. Notice the larger image, full description, price, and the Add to cart button.
Click Add to cart on that product, then click the shopping cart icon in the top right corner to open the cart page.
On the cart page, click Checkout to reach checkout step one (the Your Information form with First Name, Last Name, and Zip/Postal Code fields).
Fill in Test for First Name, User for Last Name, and 12345 for Zip/Postal Code.
Click Continue to reach checkout step two (the order overview with item totals and tax).
Click Finish to reach the order confirmation page.

You should see a "Thank you for your order!" message confirming you have reached the final page.

Click the hamburger menu (three horizontal lines) in the top left corner.
Select Reset App State to clear your cart.
Select All Items to return to the inventory page with a clean slate.

What interactive elements did you spot?

As you explored, you should have noticed buttons (Login, Add to cart, Remove, Checkout, Continue, Finish), form fields (username, password, first name, last name, zip code), a sort dropdown on the inventory page, and navigation links (product names, cart icon, hamburger menu).

Each of these is a potential place where something could go wrong. Every button could fail to respond, every form could accept invalid data, and every dropdown could sort incorrectly.

Create a Test Scenarios tab and document scenarios by module

Now that you have a mental map of the application, you need to organize what you found into testable scenarios. Grouping by module keeps your testing systematic and prevents you from missing entire areas.

Switch to your SauceDemo Test Cases spreadsheet in Google Sheets.
Click the + icon at the bottom left (next to your existing sheet tab) to add a new tab.
Double-click the new tab name and rename it to Test Scenarios.

You should see a fresh blank sheet with the tab labeled Test Scenarios at the bottom of your spreadsheet.

Now populate this tab with the test scenarios you identified during your exploration:

In Row 1, add these column headers: Module, Test Scenario, and Type.
Starting in Row 2, add scenarios for the Login module: valid credentials, empty fields, wrong password, locked_out_user.
Add scenarios for the Inventory module: view products, sort by name, sort by price, view product detail.
Add scenarios for the Cart module: add single item, add multiple items, remove item.
Add scenarios for the Checkout module: complete purchase, submit empty form fields, checkout with no items in cart.

Why group by module?

Modules are functional areas of the application that handle one responsibility. Login handles authentication. Inventory handles product display. Cart handles item management. Checkout handles the purchase flow.

Grouping by module ensures complete coverage. If you listed scenarios randomly, you might write six Login tests and forget to test the Cart entirely. Module grouping makes gaps obvious at a glance.

Label each scenario as positive or negative

Every test scenario falls into one of two categories. A positive test checks the happy path where the user does everything correctly and the app should succeed.

A negative test checks error paths where the user does something wrong and the app should handle it gracefully.

In your Type column, label each scenario as either Positive or Negative.
For Login: "valid credentials" is Positive. "Empty fields", "wrong password", and "locked_out_user" are all Negative.
For Inventory: "view products", "sort by name", "sort by price", and "view product detail" are all Positive (standard user actions that should succeed).
For Cart: "add single item", "add multiple items", and "remove item" are all Positive.
For Checkout: "complete purchase" is Positive. "Submit empty form fields" and "checkout with no items in cart" are Negative.

Why do you need both positive and negative tests?

Positive tests confirm the app works when used correctly. Negative tests confirm the app does not break or expose confusing behavior when misused.

A login form that accepts any password is a critical bug, even if it works perfectly with the right password. Professional QA teams aim for a mix of both because testing only the happy path leaves dangerous blind spots.

Before you move on, count up your scenarios. How many do you have in total across all four modules?

You should have at least 8-10 test scenarios. If you followed the lists above, you have 14: 4 Login, 4 Inventory, 3 Cart, and 3 Checkout. You should also have at least 4 Positive and at least 4 Negative labels in your Type column.

Fewer than 8 scenarios?

Make sure you have covered all four modules. Each module should have at least 2 scenarios. If you are missing a module, switch back to SauceDemo and explore that area again to identify what could be tested there.

Help me identify more test scenarios.

You have mapped the terrain. You know what the application does, what its modules are, and exactly what scenarios you need to test. Next up, you will turn these high-level scenarios into structured, executable test cases and run them against SauceDemo to find real bugs.

Write and Execute Test Cases

You have a map of the application and a list of test scenarios. Now it is time to turn those scenarios into structured, repeatable test cases and run them against the live app.

Structured test cases ensure you test systematically. When you execute them, the gap between what should happen and what actually happens is where bugs live.

In this step, get ready to:

Write 10-12 professional test cases in your Google Sheet covering Login, Cart, and Checkout.
Execute each test case on SauceDemo and record Pass/Fail results.
Discover additional bugs using the sort dropdown and the problem_user account.

Write your test cases in Google Sheets

Your Test Scenarios tab gives you the what to test. Now you need the how: precise steps a stranger could follow to reproduce the exact same test.

Switch back to Tab 1 of your SauceDemo Test Cases spreadsheet (the one with the column headers you created earlier).
Starting in Row 2, write your first test case using these columns:

Test Case ID: a unique identifier like TC_001.
Module: which feature area this tests (Login, Cart, or Checkout).
Test Scenario: a clear name like "Valid login with standard_user".
Preconditions: what must be true before the test starts (e.g., "User is on saucedemo.com login page").
Test Steps: numbered actions (e.g., "1. Open saucedemo.com 2. Enter username: standard_user 3. Enter password: secret_sauce 4. Click Login").
Expected Result: what should happen if the feature works correctly (e.g., "User is redirected to the inventory page").

Write 10-12 test cases total, covering these modules:
Login (4 cases): valid login, empty username field, wrong password, locked_out_user login attempt.
Cart (3 cases): add a single item to cart, add multiple items, remove an item from cart.
Checkout (3-4 cases): complete a purchase end-to-end, submit the checkout form with empty fields, attempt checkout with an empty cart.
Leave the Actual Result, Status, and Notes columns blank for now. You will fill those in during execution.

What makes a good test case?

A good test case is one a stranger could pick up and execute without asking you a single question. Every step must be specific enough that two different people would perform the exact same actions.

"Log in" is too vague. "Enter username: standard_user in the Username field, enter password: secret_sauce in the Password field, click the Login button" leaves no room for interpretation.

Verify that your spreadsheet now has 10-12 rows of test cases with the first six columns filled in (Test Case ID through Expected Result).

Not sure what to write for Preconditions?

Think about what state the app needs to be in before you start the test steps. For a Cart test, the precondition might be "User is logged in as standard_user" because you cannot access the cart without logging in first.

For a Login test, the precondition is simpler: "User is on the saucedemo.com login page."

help me write preconditions for my test cases

Execute your test cases on SauceDemo

Now you will act as the tester. Follow each test case step-by-step on the live application, record exactly what happens, and mark whether it passed or failed.

Return to SauceDemo in your browser at https://www.saucedemo.com/.
Start with your first test case (TC_001). Read your Test Steps column and perform each action exactly as written on the live site.
After completing the steps, observe what actually happened and type it into the Actual Result column.
Compare the Actual Result to your Expected Result. If they match, type PASS in the Status column. If they do not match, type FAIL.
For any FAIL result, write a brief note in the Notes column describing what went wrong (e.g., "Error message not displayed" or "Page did not redirect").
Repeat this process for every test case in your spreadsheet, one by one.

Why follow the steps exactly as written?

You are testing your test cases just as much as you are testing the application. If you improvise during execution, you are no longer running the documented test. Discipline here is what separates professional QA from casual poking around.

If you notice your steps are unclear while executing them, that is valuable feedback. Go back and rewrite the steps to be more precise.

After executing all test cases, review your Status column. You should see a mix of PASS and FAIL results. SauceDemo has intentional bugs, so finding failures means you are doing your job correctly.

Keep each execution clean

Before each test case that requires a fresh login, log out first using the sidebar menu. This prevents leftover state (like items in the cart) from interfering with your next test.

All your tests are passing?

If every single test case passes, double-check your negative tests. Make sure your locked_out_user test uses that exact username, not standard_user. Verify your empty-fields checkout test actually submits the form without typing anything.

help me find bugs in SauceDemo - all my tests are passing

Test the sort dropdown and problem_user account

Your scripted test cases cover the main flows. Now you will push the app further by testing the sort feature and a different user account that is known to exhibit strange behavior.

Log in as standard_user and navigate to the inventory page (product list).
Click the sort dropdown in the top-right area of the product list.
Test each sort option one at a time: Name (A to Z), Name (Z to A), Price (low to high), Price (high to low).
For each option, check whether the products actually reorder correctly. Note any cases where the order does not match what you selected.
Log out using the sidebar menu, then log back in as problem_user with password secret_sauce.
Browse the inventory page. Look at the product images. Try adding items to your cart. Try using the sort dropdown.
Note any bugs you observe in your spreadsheet's Notes column or at the bottom of your test case list. Add new rows if you discover failures not covered by your original test cases.

What kind of bugs will you find?

The problem_user account is intentionally broken. You may notice incorrect product images, sorting that does not work, buttons that do not respond, or form fields that behave strangely. These are all real bugs planted by the developers for testing practice.

You should find at least 2-3 genuine bugs across sorting, images, or form behavior.

Verify that you have documented at least 2-3 additional failures from your sort dropdown and problem_user testing.

Not finding any bugs with problem_user?

Make sure you logged in with problem_user (not standard_user). Look carefully at the product images on the inventory page. Try clicking Add to cart on several different products and watch whether the cart badge number changes.

help me find bugs on SauceDemo with the problem_user account

Before you review your final results, take a moment to predict: what do you think your overall pass/fail ratio looks like across all your test cases and additional observations?

Count the total PASS and FAIL entries in your Status column. You should see at least 2-3 FAIL results across your test cases and additional observations.

Your spreadsheet now contains a complete executed test suite with real results. The FAIL entries prove you found genuine defects in the application.

You have real evidence of defects now. But look at your FAIL notes. Could a developer pick up one of those notes and fix the bug without asking you a single follow-up question? Next up, you will learn to write bug reports that are truly actionable.

Report Bugs Professionally in Jira

In the previous step, you executed your test cases and found real bugs in SauceDemo. Your spreadsheet has FAIL entries with short notes like "items in wrong order" or "image not loading."

Those notes tell you something is broken, but a developer cannot fix a bug from "it didn't work." They need exact reproduction steps, environment details, and visual evidence. In this step, you will write professional bug reports in Jira that give a developer everything they need to reproduce and fix the issue.

In this step, get ready to:

Create your first bug report in Jira with a structured description.
Attach screenshots and environment details to each ticket.
Set priority and severity classifications on each defect.

Create your first bug report in Jira

A professional bug report answers five questions a developer will ask: What happened? What should have happened? How do I reproduce it? What environment were you in? Can you show me?

Switch back to your SauceDemo QA project in Jira.
Click the Create button in the top navigation bar.
In the Issue Type dropdown, select Bug.

Don't see Bug as an issue type?

Bug may not be included in your project by default. Select Task instead and continue with the same structure below.

If you want to enable it: go to Project settings > Issues > Types and add the Bug issue type to your project.

Help me enable the Bug issue type in my Jira project

In the Summary field, write a clear one-line title that names the specific problem. For example: Product sort by Price (low to high) displays items in wrong order.
In the Description field, write the following sections, each on its own line:

Structure your description with these four sections:

Environment: Your Chrome version, your operating system, and the test account you used (e.g. standard_user).
Steps to Reproduce: A numbered list a developer can follow exactly. Start from the login page. For example: 1. Open saucedemo.com, 2. Log in as standard_user / secret_sauce, 3. Click the Sort dropdown, 4. Select Price (low to high), 5. Observe the product order.
Expected Result: What should happen if the feature worked correctly.
Actual Result: What actually happened when you tested it.

Click Create at the bottom of the form to save your first bug ticket.

You should see the new ticket appear on your project board with the title you just wrote.

What makes a good bug title?

A good bug title is specific enough that a developer knows the problem without opening the ticket. It names the feature, the action, and the failure.

Compare: "Sort doesn't work" (vague) vs "Product sort by Price (low to high) displays items in wrong order" (specific). The second tells the developer exactly where to look.

Ticket not appearing on your board?

Check that you selected the correct project (SauceDemo QA) in the Create dialog. Also confirm you clicked the final Create button and not just closed the dialog.

My Jira ticket didn't appear after I clicked Create

Attach screenshots and file remaining bugs

Screenshots turn a written description into visual proof. They also help the developer confirm they are looking at the same bug you found.

First, find your Chrome version by typing chrome://version into Chrome's address bar and pressing Enter.
Note the version number at the top of the page. You will include this in the Environment section of each bug ticket.

Now reproduce the bug in SauceDemo so you can capture it on screen.

Open your SauceDemo tab and navigate to the page where the bug occurs.
Capture a screenshot of the bug using one of these methods:

macOS: Press Cmd+Shift+4 and drag to select the area showing the bug.
Windows: Press Win+Shift+S to open the Snipping Tool and drag to select the area.
Cross-platform alternative: Open Chrome DevTools (Cmd+Shift+P on macOS or Ctrl+Shift+P on Windows), type screenshot, and select Capture full size screenshot.

Return to your Jira ticket and click on it to open it.
Drag and drop your screenshot into the Description field or use the attachment area at the bottom of the ticket.
Confirm the screenshot appears as an attachment on the ticket.

You should see the image filename listed under the ticket's attachments section.

Now repeat this process for each FAIL result in your spreadsheet. Create a new Jira ticket for each bug, following the same structure: Summary, Description (Environment with your Chrome version, Steps to Reproduce, Expected Result, Actual Result), and at least one screenshot.
You should end up with at least 2 bug tickets total on your board.

One bug per ticket

Never combine multiple bugs into a single ticket. Each defect gets its own ticket so it can be assigned, tracked, and closed independently.

Screenshot not attaching?

Make sure the file is an image format (PNG or JPG). Jira Free has a 2 GB storage limit, but individual screenshots are tiny. If drag-and-drop does not work, click the paperclip icon in the ticket's toolbar to browse for the file.

Help me attach a screenshot to my Jira ticket

Set priority and add severity classifications

Every bug has two dimensions: how bad it is technically (severity) and how urgently the business needs it fixed (priority). These are not the same thing.

What is the difference between severity and priority?

Severity measures technical impact. A crash is Critical severity. A misspelled label is Minor severity.

Priority measures business urgency. A typo on the homepage that the CEO noticed becomes High priority despite its low severity. A crash in a feature nobody uses might be Low priority despite its Critical severity.

As a QA tester, you set Priority (which Jira tracks as a field) and note your Severity assessment in a comment so the team has both signals.

Open your first bug ticket in Jira.
Find the Priority field (it appears in the details panel on the right side or in the ticket's fields section).
Select a priority level: Highest, High, Medium, Low, or Lowest. Choose based on how urgently a user would need this fixed.

Now add your severity assessment as a comment.

Scroll down to the Comments section of the ticket.
Click Add a comment.
Write a comment noting the severity level and your reasoning. For example: "Severity: Medium. The sort feature returns incorrect results, which could mislead a customer comparing prices, but does not block completing a purchase."
Click Save to post the comment.

You should see your comment appear below the ticket description with your name and a timestamp.

Repeat for each bug ticket: set the Priority field and add a Severity comment with reasoning.

Why put severity in a comment instead of a field?

Jira Free does not include a built-in Severity field by default. Professional QA teams often add a custom field, but on the Free plan, a comment is the clearest way to communicate your assessment. The important thing is that the information exists on the ticket for the developer to read.

Before you check your final result, what do you expect to see when you look at your Jira board now?

Return to your SauceDemo QA project board.
Confirm you see at least 2 bug tickets, each with a specific title visible on the board.
Click into one ticket and verify it has: a Description with Environment, Steps to Reproduce, Expected Result, and Actual Result. A Priority set. At least one screenshot attached. A comment with your Severity assessment.

Each ticket should have all five elements. This is the structure that hiring managers look for when they ask to see your QA work.

Your Jira board now holds professional bug reports that a developer could pick up and start fixing immediately. Next up, you will go beyond scripted test cases with exploratory testing and deliver a test summary report with real metrics.

Secret mission

Exploratory Testing and Test Summary Report

You've proven you can execute structured test cases. Now it's time to go off-script. Log in as a glitchy user account, use your judgment to hunt bugs without a test case guiding you, and deliver a professional test summary report with metrics that a stakeholder can act on.

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project runs entirely on free tools with no ongoing costs, so there is no financial impact to leaving things as they are.

Resources you used:

Jira Free site with your "SauceDemo QA" project and bug tickets.
Google Sheets spreadsheet "SauceDemo Test Cases" with three tabs (test cases, scenarios, and test summary report).
SauceDemo website (public demo app, no account or stored data to clean up).

Keep everything running

No action needed. Choose this if you plan to continue building your QA portfolio or want to reference your test cases and bug reports in job interviews.

Your Jira Free site stays active indefinitely at no cost, though Atlassian may deactivate it after prolonged inactivity.
Your Google Sheet remains in your Google Drive with no storage concerns.
SauceDemo is a public website with no account to maintain.

Pause - I'll come back to this later

Free up mental clutter while keeping your work accessible. Since everything here is free, pausing is the same as keeping. Just close your browser tabs.

Bookmark your Jira project URL so you can return to it easily later.
Star your Google Sheet in Google Drive so it stays visible at the top of your files.
Close all SauceDemo browser tabs.

Delete - I don't want to use this again

Remove all project resources and start fresh. Follow these steps to delete everything you created.

Delete your Jira project: In Jira, click the gear icon (Settings) in the top navigation, then select Spaces. Find your "SauceDemo QA" project, click the three-dot menu (•••) next to it, and select Move to trash. Then select Trash from the sidebar, find your project, click the three-dot menu again, and select Delete permanently.
Delete your Atlassian account (optional): Go to id.atlassian.com/manage-profile/account-preferences and follow the account deletion steps. This removes your entire Atlassian identity.
Delete your Google Sheet: Open Google Drive, right-click the "SauceDemo Test Cases" spreadsheet, and select Move to trash. Then open Trash in Drive and click Empty trash to permanently remove it.

Nice Work!

Nice work! You've just completed a full manual testing cycle on a real e-commerce web application. You now have a professional set of QA artifacts that prove you can do the job.

Here's what you learned:

Designed and executed professional test cases with preconditions, numbered steps, and expected vs actual results across Login, Inventory, Cart, and Checkout modules.
Filed real bug reports in Jira with reproduction steps, screenshots, and severity/priority classifications that a developer could act on.
Ran a structured manual testing cycle from scenario identification through test execution and defect reporting, producing portfolio-ready QA artifacts.
Secret Mission: Performed unscripted exploratory testing and delivered a test summary report with pass rate metrics and stakeholder recommendations.

Ready to quiz yourself?