Build a Manual QA Portfolio

Test Swag Labs and publish a risk-based manual QA case study on GitHub.

Introduction

30 Second Summary

A hiring reviewer cannot see how you test from a line on your CV. They need a clear example that shows what you checked and how you reached your decision.

In this project, you will test the checkout journey in the public Swag Labs sample application. You will publish a complete manual QA case study on GitHub for a recruiter to review.

What You'll Build

Picture opening your public GitHub repository for a recruiter to review an evidence-backed account of how you tested the Swag Labs checkout journey.

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

A public QA case study that explains your checkout scope through a risk-based test strategy.
A set of six executed test cases covering authentication, cart behavior, validation, and checkout.
An evidence-backed defect report connected to requirements and results through a traceability matrix. A recruiter can follow the evidence behind your release recommendation.
Secret Mission: Add an authentication decision table and verify four distinct error-handling paths.

Are there any prerequisites?

You'll need a Windows device, a GitHub account, and basic manual testing knowledge.

Step 1 helps you verify Microsoft Edge and Snipping Tool before testing begins. You do not need Node.js or a local Git installation.

Before We Start

This opening checkpoint turns your work into one clear portfolio story before any hands-on testing begins. You are testing the Swag Labs checkout journey to demonstrate risk-based manual testing and clear defect communication.

Prepare Your Test Environment and Repository

Your portfolio story now has a clear purpose. A reviewer still needs evidence tied to a named test environment.

You will verify your Windows test tools before opening Swag Labs. A public GitHub repository gives your evidence a durable home.

In this step, get ready to:

Verify Microsoft Edge and record its displayed version.
Capture the Swag Labs login page with Snipping Tool.
Create a public repository with a rendered README and screenshot evidence.

Verify your Windows tools

A named browser version makes your test results easier to reproduce. Microsoft Edge provides that environment for this case study.

Press the Windows key to open Windows search.
Type Microsoft Edge into the search field.
Press Enter to open Microsoft Edge.

✔️ Microsoft Edge opens

Microsoft Edge is ready for your test environment check.

ⓧ Microsoft Edge is missing

Installing the browser gives every test in this case study the same named environment.

Open the official Microsoft Edge download page in your current browser.
Install Microsoft Edge by following the instructions on the download page.
Press the Windows key after the installation finishes.
Type Microsoft Edge into the search field.
Press Enter to open Microsoft Edge.

Having trouble installing Edge?

Confirm that you used the official Microsoft download page. A work-managed Windows device may require administrator approval.

Ask for help if the installer stops before Edge opens: help me troubleshoot the Microsoft Edge installation on Windows.

Select the Microsoft Edge address bar.
Enter edge://settings/help to open the browser version page.
Record the version shown on the page here: your displayed Edge version.

Your browser version now anchors future results to a specific environment. Next, verify the tool that captures visual evidence.

Snipping Tool creates focused screenshots of the behavior you observe. A focused capture helps another tester compare your written result with the interface.

Press Windows logo key + Shift + S to start a screen capture.

✔️ The capture overlay appears

The capture overlay confirms that Snipping Tool is ready.

Press Esc to close the overlay for now.

ⓧ The capture overlay is missing

Installing Snipping Tool gives you the evidence capture method used throughout this case study.

Open the official Snipping Tool listing in Microsoft Edge.
Install Snipping Tool from the Microsoft Store listing.
Press Windows logo key + Shift + S after the installation finishes.

Still missing the capture overlay?

Confirm that the Snipping Tool installation completed before trying the shortcut again. A work-managed Windows device may block Microsoft Store installations.

Ask for help with your Windows setup: help me get the Snipping Tool capture overlay working.

You now have a recorded browser version and a working capture overlay. Those details make your later results easier to review.

Capture the Swag Labs test object

A test object is the application or feature being tested. Your test object is the Swag Labs login-to-checkout journey in Microsoft Edge.

Switch back to Microsoft Edge.
Enter https://www.saucedemo.com/ in the address bar.
Confirm that the browser tab title shows Swag Labs.
Confirm that the login page lists accepted usernames.

What does this check prove?

The page title confirms that you opened the intended application. The accepted usernames confirm that the login test data is available on the page.

Close any unrelated browser tabs before capturing evidence.
Dismiss any personal notifications visible on the screen.
Press Windows logo key + Shift + S to open the capture overlay.
Drag the capture area around the Swag Labs login page.

What should your evidence show?

The capture should show the Swag Labs login form and the accepted usernames. Excluding unrelated tabs or notifications keeps private information out of your portfolio.

Press Ctrl + S in Snipping Tool to open the save window.
Select your Desktop in the save window.
Select the folder-creation control in the save toolbar.
Name the new folder evidence.
Open the evidence folder.
Enter environment-login.png in the file name field.
Select Save.

You should now have evidence/environment-login.png on your Desktop. The image should contain only the focused Swag Labs login page.

Can't find the saved screenshot?

Open the evidence folder on your Desktop. Confirm that the file name ends with .png.

Ask for help if the image was saved elsewhere: help me locate my saved Snipping Tool screenshot on Windows.

Create and initialize the repository

A public repository lets another person inspect your test work from a browser. Initializing it with a README gives the case study a visible front page from the first commit.

Your GitHub credentials stay on GitHub. This project never asks you to paste them into a test artifact.

Switch back to Microsoft Edge.
Open GitHub in the browser.
Sign in to your GitHub account.
Select New repository.
Enter swag-labs-manual-qa as the repository name.
Choose Public for the repository visibility.
Toggle Add README to On.
Select Create repository.

That's a solid start. Your new repository gives the case study a public home with README.md displayed on its front page.

Repository name already taken?

Check your GitHub profile for an existing repository named swag-labs-manual-qa. Delete that unused repository only if you are certain you no longer need it.

Ask for help before changing the required repository name: help me resolve the GitHub repository name conflict.

The opening sentence tells a reviewer what the case study covers. Keep the first version concise so later sections can add verified results.

Select README.md from the repository file list.
Select the file-editing control in the upper-right corner.
Replace the current README contents with the text below:

Manual QA case study of the Swag Labs checkout journey, covering risk-based test design, execution evidence, defect reporting, and traceability.

Why this opening works

The sentence names the application journey being tested. It also previews the test design and communication evidence that the repository will contain.

Select Preview above the editor.
Confirm that the opening sentence renders as one paragraph.
Select Commit changes....
Keep the option to commit directly to the main branch.
Select Commit changes to save the README.

The repository front page should now render the exact opening sentence from README.md.

README sentence missing?

Open README.md from the file list. Confirm that the sentence appears in the file history after your commit.

Ask for help if the old content still appears: help me check why my GitHub README edit was not committed.

✔️ Awesome, I've got everything!

Great. Confirm that your committed README.md displays the opening sentence before uploading the evidence folder.

ⓧ I'd like to double check the full code

Here is the complete README.md content at this point. Compare it with your committed file:

Manual QA case study of the Swag Labs checkout journey, covering risk-based test design, execution evidence, defect reporting, and traceability.

What should match

Your README should contain this exact opening sentence. Matching punctuation keeps the portfolio introduction consistent with the planned case study.

The README introduces the project. The focused login image gives the repository its first piece of execution evidence.

Return to the swag-labs-manual-qa repository front page.
Select Add file above the file list.
Select Upload files.
Drag the evidence folder from your Desktop onto the upload area.
Choose the option to commit directly to the main branch.
Select Commit changes to publish the screenshot.

You should see an evidence folder in the repository. Opening it should reveal environment-login.png.

Evidence folder missing?

Confirm that you dragged the entire evidence folder into the upload area. Dragging only the image places it on the repository front page.

Ask for help if the upload does not preserve the folder: help me upload my evidence folder to GitHub with the correct path.

Before the final check, which repository signals do you expect to prove that another person can review your starting evidence?

Return to the repository front page.
Confirm that the repository header shows Public.
Confirm that the opening sentence from README.md is rendered on the page.
Open the evidence folder.
Select environment-login.png.

You should see the focused Swag Labs login page with no unrelated tabs or private information. Your repository now has a public introduction and durable environment evidence.

Your test environment and public evidence space are ready. Next, you will run a vague checkout requirement and discover why a one-line result cannot support reliable retesting.

Run the Baseline Checkout

Your public GitHub repository now gives your manual QA work a reviewable home. The opening README establishes the checkout journey you are testing.

A manual QA result earns trust when another tester can repeat it. This step gives a one-line test basis a fair trial by running it exactly as written.

In this step, get ready to:

Create a brief baseline record for the checkout claim.
Execute the baseline checkout in Swag Labs.
Audit whether the record supports a repeatable result.

Create the baseline record

A baseline record preserves the claim being tested at a specific point in time. Keep this first record brief so you can evaluate its usefulness after the run.

Switch back to the swag-labs-manual-qa repository from the previous step.
Select Add file above the repository file list.
Select Create new file.
Enter docs/baseline-run.md in the filename field.

The file editor now places your baseline record inside the repository's docs folder.

Enter Baseline Run as the page heading.
Add Initial test basis: A shopper can purchase one available product. as the first record.
Select Preview above the editor.

You should see the heading plus the single checkout claim rendered as Markdown.

What is a test basis?

A test basis is the information used to decide what should be tested. This one-line basis describes a desired shopping outcome without prescribing how to reach it.

Return to the file editor.
Add an environment section containing the test date plus your recorded Microsoft Edge version.
Add a result field with no value.
Select Preview.
Select Commit changes....
Confirm the commit in the dialog.

Good progress. Your repository now preserves the baseline claim plus the environment where you are about to test it.

Can't find the new baseline file?

Check that the filename is exactly docs/baseline-run.md. The forward slash tells GitHub to place the file inside the docs folder.

Confirm that you completed the commit dialog. An uncommitted file does not appear in the repository file list.

help me create docs/baseline-run.md through the GitHub web interface

Execute the one-line checkout

The baseline run follows the shortest obvious shopping path through Swag Labs. You will use one product plus distinct checkout names so the result comes from a concrete journey.

Return to the Swag Labs tab from the previous step.
Confirm that the accepted usernames are visible on the login page.
Enter standard_user in the username field.
Enter secret_sauce in the password field.
Submit the sign-in form.

You should see the product inventory. This confirms that the baseline starts from a successful shopper login.

Locate Sauce Labs Bike Light in the inventory.
Select Add to cart for that product.
Open the shopping cart.
Confirm that Sauce Labs Bike Light is listed in the cart.
Use the cart's checkout control to reach the checkout information form.

The checkout form asks for customer information before it shows the order overview.

Enter Jamie in the first-name field.
Enter Rivers in the last-name field.
Continue to the order overview.

Before you complete the order, what outcome does the one-line test basis lead you to expect?

Use the final checkout control to finish the order.

You should see Thank you for your order! on the completion page.

That is your first executed result. The successful order now gives your baseline a real observed outcome.

Don't see the completion message?

Confirm that you signed in with standard_user. A different accepted account can behave differently.

Check that the cart contained Sauce Labs Bike Light before you entered the checkout information.

help me trace my Swag Labs baseline checkout

A focused screenshot preserves the visible outcome without exposing unrelated browser content. Use Snipping Tool to capture only the completed checkout page.

Press Windows logo key + Shift + S.
Drag the capture area around the checkout completion page.
Select the capture notification to view the snip.
Press Ctrl + S to save the snip.
Save the image in your Downloads folder as baseline-checkout-success.png.

Switch back to docs/baseline-run.md in your GitHub repository.
Select the pencil-shaped edit control.
Enter only Pass in the blank result field.
Select Preview.
Select Commit changes....
Confirm the commit in the dialog.

The rendered baseline now records the observed result as Pass.

Return to the repository file list.
Select the existing evidence folder.
Select Add file.
Choose the upload option.
Upload baseline-checkout-success.png from your Downloads folder.
Commit the uploaded image.

You should see baseline-checkout-success.png listed beside environment-login.png in the evidence folder.

Audit the result for reproducibility

Reproducibility means another tester can use the written record to perform the same test. Act as that second tester with access to the rendered baseline note only.

Before you try to repeat the run, do you think the note preserves enough detail to produce the same result?

Switch to the rendered preview of docs/baseline-run.md.
Limit your audit to the text shown in the note.
Identify the required preconditions from the note.
Identify the exact execution steps from the note.
Identify the test data from the note.
Identify the expected result from the note.
Identify the individual checkpoints from the note.
Identify an evidence link from the note.

You cannot identify every input or checkpoint from the record. This planned shortfall shows why the one-line result cannot support a repeatable run.

You have exposed the exact weakness this exercise was built to reveal. The word Pass reports an outcome without preserving the path that produced it.

Select the pencil-shaped edit control for docs/baseline-run.md.
Add Reproducibility Gaps as a new heading.
Add a six-item gap list covering these weaknesses: preconditions / exact steps / test data / expected results / individual checkpoints / evidence links.
Select Preview.

The rendered preview should show the test date plus the recorded Edge version. It should also show the Pass result plus all six reproducibility gaps.

Select Commit changes....
Confirm the commit in the dialog.
Open the rendered preview of docs/baseline-run.md.

Before the final check, can the original one-line basis tell you every input plus each checkpoint from the completed run?

Read only A shopper can purchase one available product. in the rendered preview.
Try to reconstruct the baseline inputs from that sentence.
Try to reconstruct the baseline checkpoints from that sentence.

You should still be unable to identify every input or checkpoint from the one-line basis. The rendered gap list now documents exactly why that result is insufficient.

Your baseline now captures both a successful checkout and the limits of one-line test documentation. Next, you will turn those gaps into risk-based cases another tester can follow.

Design and Execute Risk-Based Tests

The Swag Labs baseline you committed to GitHub proves one checkout can finish. Its one-line result leaves another tester without enough detail to repeat it.

Risk-based testing replaces that weak note with a focused plan. You will connect each case to a requirement or product risk before you execute it.

In this step, get ready to:

Create a test strategy that prioritizes the checkout journey by product risk.
Write six reproducible test cases with complete execution fields.
Execute every case from a reset state with linked screenshot evidence.

Build the risk-based test strategy

A test basis states what the product is expected to do. A product risk describes a failure that could harm the shopper experience.

Your strategy connects both ideas to the Swag Labs login-to-checkout journey in Microsoft Edge. This keeps the first portfolio project focused on the failures that matter most.

Why prioritize by risk?

Risk-based prioritization uses likelihood plus impact to decide where testing effort goes first. A likely failure with serious consequences deserves earlier attention.

The priority belongs to the test effort. The impact describes what the product failure could do to the shopper.

Test Basis to Preserve

Use REQ-01 A valid shopper can reach inventory.
Use REQ-02 A selected product remains available in the cart.
Use REQ-03 A shopper with complete checkout information can finish an order.

Return to the swag-labs-manual-qa repository in the GitHub tab from earlier.
Select Add file above the repository file list.
Select Create new file.
Enter docs/test-strategy.md as the file path.

You should see the new path above an empty editor. GitHub places the file inside the existing docs folder.

Add a Test Object section that names the Swag Labs login-to-checkout journey in Microsoft Edge.
Populate a Test Basis section with the three items from the callout.
Select Preview above the editor.

You should see the test object followed by three separate requirement entries. This gives every later test a stable source to reference.

How to Prioritize the Risks

Record authentication failure with Medium likelihood. Give it High impact. Set the test priority to High.
Record lost cart contents with Medium likelihood. Give it High impact. Set the test priority to High.
Record incorrect validation with Medium likelihood. Give it Medium impact. Set the test priority to Medium.
Record failed order completion with Medium likelihood. Give it High impact. Set the test priority to High.

Return to the file editor.
Add a Product Risks table with columns for Risk, Likelihood, Impact, and Test Priority.
Populate the table with the four risk assessments from the callout.
Add an Out of Scope section that excludes security testing.
Add performance testing to the Out of Scope section.
Add cross-browser testing to the Out of Scope section.
Select Preview to inspect the complete strategy.

You should see the three requirements above a four-row risk table. The final section should set a clear boundary around this first project.

Select Commit changes....
Enter Add risk-based test strategy as the commit summary.
Confirm the commit in the dialog.
Open the rendered preview of docs/test-strategy.md.

Your strategy now explains what you are testing. It also shows why the highest-impact paths receive the most attention.

Missing a Strategy Section?

Return to the editor if the preview omits a requirement or risk. Compare the rendered file with the two callouts above before committing another change.

If the table is difficult to format, use GitHub's table controls to rebuild it with four columns.

help me check my risk-based test strategy

Write six reproducible test cases

A test case preserves the conditions plus actions needed to check one behavior. Traceability connects that behavior to its requirement or product risk.

Each case also separates the expected result from the observed result. That separation prevents a tester from rewriting the expectation after seeing what the application does.

Fields Every Case Needs

Use the same field order in every case. A consistent layout makes the six results easier to compare.

A unique test case ID.
A requirement or product-risk link.
The preconditions needed before execution.
A test priority.
The exact test data.
Numbered execution steps.
The expected result.
The observed actual result.
A status of Pass, Fail, or Blocked.
A relative evidence link.

Case Designs to Use

Link TC-01 to REQ-01. Give it High priority. Use standard_user with secret_sauce. Expect the inventory to be displayed after the login form is submitted.
Link TC-02 to authentication failure. Give it High priority. Use locked_out_user with secret_sauce. Expect Sorry, this user has been locked out. to appear.
Link TC-03 to REQ-02 plus lost cart contents. Give it High priority. Add Sauce Labs Bike Light with Add to cart. Expect the same product to be present after the cart is opened.
Link TC-04 to REQ-02 plus lost cart contents. Give it Medium priority. Add Sauce Labs Bike Light before selecting Remove. Expect the product to be absent from the cart.
Link TC-05 to incorrect validation. Give it Medium priority. Reach checkout with an item. Leave the first-name field empty. Use Tester as the last name. Use 12345 as the postal code. Expect First Name is required to appear.
Link TC-06 to REQ-03 plus failed order completion. Give it High priority. Use standard_user with Alex, Tester, and 12345 as checkout data. Expect Thank you for your order! to appear.

Return to the repository front page.
Select Add file above the file list.
Select Create new file.
Enter docs/test-cases.md as the file path.

You should see a new empty editor inside the docs folder. This file becomes the repeatable execution record that the baseline lacked.

Add TC-01 through TC-03 using the shared field order.
Write each procedure as numbered steps from its reset login precondition to its expected checkpoint.
Select Preview.

You should see three distinct cases with scannable fields. Another tester should be able to identify the credentials plus the final checkpoint without reading the baseline file.

Return to the editor.
Add TC-04 through TC-06 using the same field order.
Leave the execution fields empty until you observe each result.
Select Preview.
Confirm the rendered file lists TC-01 through TC-06 in order.
Select Commit changes....
Enter Add six risk-based test cases as the commit summary.
Confirm the commit in the dialog.

That is the weak baseline replaced with six executable checks. The cases now preserve the inputs plus the checkpoints needed for retesting.

A Case Is Missing a Field?

Compare the incomplete case with the Fields Every Case Needs callout. Keep the same labels in the same order across all six cases.

Check that every procedure starts from a reset login state. A leftover cart item can change the outcome of later cases.

help me make my test cases reproducible

Execute the cases and link evidence

Execution compares expected versus actual results without changing the expectation. Evidence capture gives a reviewer a focused image of the checkpoint you observed.

Use the verified Snipping Tool for each checkpoint. Keep unrelated tabs plus personal notifications outside the captured area.

How to Choose a Status

Use Pass when the observed result matches the expected result.
Use Fail when the observed behavior differs from the expected result.
Use Blocked when a prerequisite or environment problem prevents execution.

Return to the rendered docs/test-cases.md file.
Select the pencil icon above the rendered file.
Keep the editor available while you switch between GitHub and Swag Labs.
Switch back to the Swag Labs tab.
Open the application menu from the completed baseline session.
Select Reset App State.
Select Logout.

You should see the login page with an empty cart state. This is the shared starting point recorded in your cases.

Execute TC-01 using its recorded credentials plus numbered steps.

You should see the inventory after submitting the valid login. That visible inventory is the checkpoint for REQ-01.

Capture the inventory checkpoint with Windows logo key + Shift + S.
Save the capture as tc-01-inventory.png.
Switch back to the test-case editor.
Write the observed result in the Actual Result field for TC-01.
Set the TC-01 status using the observation.
Set its evidence link to ../evidence/tc-01-inventory.png.

Your first case now preserves the behavior plus the visual checkpoint. Clean the session before the negative login case.

Return to the Swag Labs tab.
Select Reset App State from the application menu.
Select Logout.
Execute TC-02 using its recorded credentials plus numbered steps.

You should see Sorry, this user has been locked out. on the login page. A negative test passes when the application rejects the account as expected.

Capture the locked-out message with Windows logo key + Shift + S.
Save the capture as tc-02-locked-out.png.
Switch back to the test-case editor.
Write the observed result in the Actual Result field for TC-02.
Set the TC-02 status using the observation.
Set its evidence link to ../evidence/tc-02-locked-out.png.

The authentication pair now demonstrates both accepted access plus expected rejection. Continue with the cart-retention behavior.

Switch back to the Swag Labs login page.
Execute TC-03 using its recorded credentials plus numbered steps.

You should see Sauce Labs Bike Light in the cart after adding it from inventory. This confirms that the selected product survives the move to the cart.

Capture the cart checkpoint with Windows logo key + Shift + S.
Save the capture as tc-03-cart-bike-light.png.
Switch back to the test-case editor.
Write the observed result in the Actual Result field for TC-03.
Set the TC-03 status using the observation.
Set its evidence link to ../evidence/tc-03-cart-bike-light.png.

Return to the Swag Labs tab.
Select Reset App State from the application menu.
Select Logout.
Execute TC-04 using its recorded credentials plus numbered steps.

You should see that Sauce Labs Bike Light is absent after removal. The empty cart view is useful evidence because it captures the state after the action.

Capture the cart after removal with Windows logo key + Shift + S.
Save the capture as tc-04-cart-item-removed.png.
Switch back to the test-case editor.
Write the observed result in the Actual Result field for TC-04.
Set the TC-04 status using the observation.
Set its evidence link to ../evidence/tc-04-cart-item-removed.png.

Both cart cases now cover a different state transition. Reset once more before checking the required-field validation.

Return to the Swag Labs tab.
Select Reset App State from the application menu.
Select Logout.
Execute TC-05 using its recorded checkout data plus numbered steps.

You should see First Name is required after submitting the incomplete checkout information. This is expected negative behavior.

Capture the validation message with Windows logo key + Shift + S.
Save the capture as tc-05-first-name-required.png.
Switch back to the test-case editor.
Write the observed result in the Actual Result field for TC-05.
Set the TC-05 status using the observation.
Set its evidence link to ../evidence/tc-05-first-name-required.png.

Return to the Swag Labs tab.
Select Reset App State from the application menu.
Select Logout.
Execute TC-06 using its recorded checkout data plus numbered steps.

You should see Thank you for your order! after completing checkout. This is the end-to-end checkpoint for REQ-03.

Capture the completion message with Windows logo key + Shift + S.
Save the capture as tc-06-order-complete.png.
Switch back to the test-case editor.
Write the observed result in the Actual Result field for TC-06.
Set the TC-06 status using the observation.
Set its evidence link to ../evidence/tc-06-order-complete.png.

All six cases now have observed outcomes. The records distinguish expected rejection from an application failure.

Select Preview above the test-case editor.
Check every Actual Result field for a recorded observation.
Check every Status field for Pass, Fail, or Blocked.
Check every Evidence field for its matching relative path.
Select Commit changes....
Enter Record risk-based test execution as the commit summary.
Confirm the commit in the dialog.

Return to the repository's existing evidence folder.
Select Add file.
Choose the option for uploading files.
Select the six screenshots named in your test cases.
Complete the upload with the repository commit controls.

You should see six new test-case screenshots beside the baseline evidence. Each relative link in docs/test-cases.md now has a file to open.

An Evidence Link Does Not Open?

Check that the screenshot filename matches the path in the case. Capitalization plus hyphens must match the uploaded file.

Confirm the link starts from the docs folder before pointing into evidence.

help me fix a relative evidence link

Before you inspect the finished file, could another tester repeat one case without asking you for missing details?

Open the rendered docs/test-cases.md file.
Choose one case from TC-01 through TC-06.
Follow it from its requirement or risk link through its expected result.
Confirm it includes preconditions.
Confirm it includes priority.
Confirm it includes test data.
Confirm it includes numbered steps.
Open its relative evidence link.

You should see the matching checkpoint screenshot. The selected case should also show its actual result plus its observed status.

Your case study now shows planned coverage plus repeatable execution evidence. Next, you will use that structure to reproduce a checkout data defect with neutral reporting.

Reproduce and Report the Checkout Defect

Your six executed cases turned the product risks into observable results. You now have enough structure to investigate a checkout failure without losing the conditions that produced it.

Your next goal is to reproduce the behavior twice. You will turn that observation into a neutral defect report that another tester can follow in your public GitHub repository.

In this step, get ready to:

Reproduce the checkout data-entry issue from a clean state.
Prove reproducibility with focused screenshot evidence.
Publish a factual report with impact reasoning plus a working evidence link.

Reproduce the issue from a clean state

A clean state removes leftover cart contents or session data from the result. You will use the Swag Labs application in Microsoft Edge from earlier.

Switch back to the Swag Labs tab in Microsoft Edge.
Open the application menu using the menu icon.
Select Reset App State.
Select Logout.
Enter problem_user in the username field.
Enter secret_sauce in the password field.
Submit the sign-in form using the control below the password field.
Select Add to cart for Sauce Labs Bike Light.

The reset gives this run a known starting point. The account now has one selected product ready for checkout.

Open the cart using the cart icon.
Proceed through the checkout controls until you reach the checkout information form.
Enter Alex in the first-name field.

Before you enter the second value, what do you expect each name field to show?

Enter Tester in the last-name field.

You should see the first-name field change from Alex to Tester. The last-name field remains empty.

What did this run prove?

You have reproduced a data-entry failure from a clean state. The observed values give your report a specific result that another tester can check.

Capture and confirm the evidence

Focused evidence preserves the failed state without distracting details. The Snipping Tool lets you capture only the two affected fields.

Press Windows logo key + Shift + S to open the capture overlay.
Drag the capture area around the first-name field plus the last-name field.
Press Ctrl + S to save the capture.
Save the image to your Desktop as BUG-001-checkout-name-fields.png.

One screenshot records the behavior. A second clean run establishes that the result is reproducible.

Return to the Swag Labs tab from the first run.
Repeat the clean-state reproduction sequence from the previous substep once.

You should observe the same field change during the second run. The first-name field shows Tester while the last-name field stays empty.

Switch back to the swag-labs-manual-qa repository from earlier.
Open the evidence folder from the repository file list.
Select Add file in the repository toolbar.
Choose the file-upload option.
Select BUG-001-checkout-name-fields.png from your Desktop.
Commit the upload by selecting Commit changes....
Open evidence/BUG-001-checkout-name-fields.png from the repository file list.

You should see a focused image of the two checkout fields. The image shows the overwritten first-name value plus the empty last-name field.

Evidence file missing?

Check that you uploaded the image while the evidence folder was open. The repository path should read evidence/BUG-001-checkout-name-fields.png.

Confirm that the filename uses the same capital letters plus hyphens shown above.

Ask for help with the upload path.

Publish the defect report

The screenshot proves what the interface displayed. The report adds the conditions plus the reasoning needed for someone else to reproduce the result.

What makes a useful defect report?

A useful report stays objective. It records the interface behavior plus its effect on the checkout journey.

The report separates severity from priority. Severity describes the effect of the failure. Priority describes how urgently the team should address it.

Return to the front page of the swag-labs-manual-qa repository.
Select Add file in the repository toolbar.
Select Create new file.
Enter docs/defect-report.md in the filename field.
Set the defect ID to BUG-001.
Set the title to Entering a last name overwrites the first-name field for problem_user.
Complete the environment section with your recorded Microsoft Edge version plus Swag Labs.
Record the reset application state plus the logged-out session as preconditions.

Your report now identifies where the issue occurred. The next details make the observation repeatable.

Link the report to TC-05 as the closest checkout validation case.
Write the clean-state reproduction steps in the order you followed them.
Record Alex as the first-name test data plus Tester as the last-name test data.
Document the expected result as two separate fields containing their entered values.
Document the actual result as Tester overwriting the first-name field while the last-name field remains empty.
Record that the behavior occurred during both clean-state runs.

Keep the reasoning factual

Choose severity based on the effect on checkout data entry. Choose priority based on the observed impact plus the affected account scope.

Avoid guessing how many users are affected. Your evidence supports the behavior you reproduced with problem_user.

Add a severity rationale focused on the checkout data-entry effect.
Add a priority rationale grounded in the observed impact plus account scope.
Add a relative evidence link targeting ../evidence/BUG-001-checkout-name-fields.png.
Select Preview above the editor.
Confirm that each report section renders as readable Markdown.
Commit the report by selecting Commit changes....
Open the rendered docs/defect-report.md file.

Before you follow the evidence link, do you expect the relative path to open the image from the repository's evidence folder?

Open the BUG-001-checkout-name-fields.png evidence link from the rendered report.

You should see the focused screenshot from your reproduced failure. The report should record Alex plus Tester as the intended inputs.

Compare the screenshot's field state with the actual result in docs/defect-report.md.

The screenshot plus the report should agree that the first-name field changed to Tester while the last-name field remained empty. That alignment makes BUG-001 reviewable without rerunning the test.

Evidence link not opening?

Confirm that the link begins with ../evidence/. The two dots move the link out of the docs folder before GitHub looks inside evidence.

Check that BUG-001-checkout-name-fields.png matches the uploaded filename character for character.

Ask for help fixing the relative link.

You have turned a checkout observation into a reproducible defect report with working evidence. Next, you will connect the case study into a concise story that a hiring reviewer can follow.

Publish Your QA Portfolio Story

Your evidence-backed defect report now shows how BUG-001 behaves in Swag Labs. A hiring reviewer still has to piece together your coverage, results, and release judgment from separate files.

A traceability matrix will connect each test basis item or product risk to its supporting work. You will make README.md the front door of your GitHub repository.

In this step, get ready to:

Map every requirement or product risk to its test cases, latest results, evidence, and applicable defect.
Expand README.md with the objective, scope, risks, artifacts, execution summary, and release recommendation.
Verify the completed case study from its public repository front page.

Create the traceability matrix

A traceability matrix gives each requirement or risk a visible path to the work that tested it. This path helps a reviewer evaluate your coverage without guessing.

Return to docs/test-cases.md in the repository.
Record the number of Pass statuses as your Pass total.
Record the number of Fail statuses as your Fail total.
Record the number of Blocked statuses as your Blocked total.
Confirm the three totals add up to 6.

A total of 6 proves every executed test contributes to the portfolio summary.

Map the coverage

REQ-01 includes TC-01 for valid shopper access to inventory.
REQ-02 includes TC-03 and TC-04 for cart contents.
REQ-03 includes TC-06 for completed checkout.
The authentication risk includes TC-01 and TC-02.
The cart risk includes TC-03 and TC-04.
The validation risk includes TC-05.
The order-completion risk includes TC-06.

Return to the repository front page.
Select Add file above the file list.
Select Create new file.
Enter docs/traceability.md as the file name.

Add table columns for the requirement or risk, test cases, latest result, evidence, and defect.
Add seven rows for REQ-01, REQ-02, REQ-03, authentication, cart, validation, and order completion.
Select Preview.

You should see one header row followed by seven coverage rows.

Return to the editing view.
Use the recorded requirement or risk link for each test case to fill the test-case column.
Copy each latest status from docs/test-cases.md into the matching row.
Select Preview.

Each row should now identify the tests that cover it. The latest-result cells should match the executed cases.

Relative links can feel fiddly because their starting point depends on the current file. From docs/traceability.md, screenshot paths begin with ../evidence/.

Return to the editing view.
Add the relevant relative evidence link to each row.
Link BUG-001 from the row that matches the requirement or risk identified in docs/defect-report.md.
Select Preview.

The rendered table should connect every requirement or risk to results that a reviewer can inspect.

Confirm every test case from TC-01 through TC-06 appears in at least one row.
Select Commit changes....
Complete the commit dialog to save docs/traceability.md.

That audit trail is now in place. A reviewer can trace your coverage claims back to recorded results, screenshots, and BUG-001.

Turn README into the review path

Your README is the first artifact a reviewer sees. It needs to summarize your judgment before directing the reviewer to the detailed evidence.

Return to README.md on the repository front page.
Select the edit control above the rendered file.
Place the cursor after the existing opening sentence.
Add a project objective section that explains the risk-based testing goal for the Swag Labs checkout journey.
Add a QA role section that describes your responsibility for planning, execution, evidence capture, defect reporting, traceability, and release communication.
Select Preview.

The rendered README should retain its opening sentence. The objective and QA role should appear directly below it.

Return to the editing view.
Add a test-environment section that names the recorded Microsoft Edge version and the public Swag Labs application.
Add a scope section that lists login-to-checkout testing as in scope.
List security, performance, and cross-browser testing as out of scope.
Select Preview.

The environment should match the details already recorded in your artifacts. The scope should set clear boundaries around your conclusions.

Return to the editing view.
Add a key product-risks section covering authentication failure, lost cart contents, incorrect validation, and failed order completion.
Add an artifact-links section with relative links to docs/baseline-run.md, docs/test-strategy.md, docs/test-cases.md, docs/defect-report.md, and docs/traceability.md.
Select Preview.

Each artifact link should appear as clickable text. Together, the links form a clear route from planning to reporting.

Return to the editing view.
Add an evidence-links section with a relative link to every file in the evidence folder.
Add an execution summary that reports your Pass total as passed, your Fail total as failed, and your Blocked total as blocked.
Select Preview.

The README should now expose the objective, role, environment, scope, risks, artifacts, evidence, and execution totals from one page.

Keep every claim auditable

Use only the statuses recorded in docs/test-cases.md. Unsupported percentages or time-saving claims would weaken the portfolio story.

Your strongest claims are the ones a reviewer can verify by following a link.

Make the release recommendation

A release recommendation turns your observations into a decision. The recommendation must reflect your recorded results and the demonstrated effect of BUG-001.

Choose from the evidence

Go supports release when the observed results reveal no issue that changes the decision.
Go with known risk supports release while explicitly accepting a documented defect or limitation.
No-go recommends holding the release when an observed issue blocks an important user journey.

Review the current statuses in docs/test-cases.md.
Review the user effect documented in docs/defect-report.md.
Choose Go, Go with known risk, or No-go.
Return to the README.md editing view.
Add a release-recommendation section with your chosen decision.
Write two or three sentences that support the decision with specific test results and BUG-001.
Select Preview.

The rendered README should end with a clear decision. Its rationale should point back to evidence already present in the repository.

Open every relative document link from the README preview.
Open every relative screenshot link from the README preview.
Compare the execution summary with the six statuses in docs/test-cases.md.
Check every release claim against the linked artifacts.

Each link should open its intended artifact or screenshot. The execution totals should match the recorded statuses exactly.

Does a relative link open the wrong file?

Use paths beginning with docs/ for document links inside README.md.
Use paths beginning with evidence/ for screenshot links inside README.md.
Use paths beginning with ../evidence/ for screenshot links inside docs/traceability.md.
Help me fix a broken relative link in my QA portfolio.

Return to the README editing view after correcting any broken link.
Select Commit changes....
Complete the commit dialog to publish the finished portfolio story.

Strong finish. Your separate QA artifacts now read as one evidence-backed case study from the repository front page.

Before the final audit, do you expect every link to open the intended file on its first click?

Return to the repository front page.
Confirm the repository header shows Public.
Follow every relative document link in the rendered README.md.
Follow every relative screenshot link in the rendered README.md.
Compare the execution totals with the current statuses in docs/test-cases.md.
Confirm the release recommendation cites only recorded results and BUG-001.

Every artifact and screenshot should open from the public front page. The execution totals should match all six recorded test statuses.

Secret mission

Build an Authentication Decision Table

Four login errors can look similar until you map each credential condition to its expected outcome. Build and execute a four-row authentication decision table that proves your coverage is systematic.

Clean Up Your Resources

Choose whether to keep your portfolio public, make it private for a while, or delete it entirely. This project created no paid cloud resources or local servers, so there are no ongoing costs.

Resources you used:

One public GitHub repository named swag-labs-manual-qa, containing your Markdown test artifacts and screenshot evidence.

Keep everything running

No action needed. Choose this if you want your completed case study to remain publicly accessible.

Your swag-labs-manual-qa repository remains visible to anyone with its URL.
Your test strategy, executed test cases, defect report, traceability matrix, decision table, and evidence remain available.
Your recorded test date and Microsoft Edge environment details continue to show when the testing was performed.

Pause - I'll come back to this later

Making the repository private pauses public access while keeping every artifact in your account. You can make it public again when you are ready.

In the swag-labs-manual-qa repository from earlier, select Settings.
Scroll to Danger Zone.
Select Change repository visibility.
Select Make this repository private.
Confirm the visibility change when GitHub asks.

Your repository is now private. Its files remain available to you while public access is paused.

Delete - I don't want to use this again

This option removes the public case study and its permissions. GitHub may allow restoration in some cases, so you should still treat the deletion as permanent.

Delete the repository

In the swag-labs-manual-qa repository from earlier, select Settings.
Scroll to Danger Zone.
Select Delete this repository.
Select I want to delete this repository.
Review the deletion warnings.
Select I have read and understand these effects.
Enter swag-labs-manual-qa when GitHub asks you to confirm the repository name.
Select Delete this repository to finish the deletion.

After GitHub completes the deletion, you should no longer see the public repository in your account.

Nice Work!

You made it! You built a public manual QA case study on GitHub that carries a reviewer from risk-based test design to an evidence-backed release recommendation.

You've learned how to:

Turn a vague Swag Labs checkout requirement into a risk-based test strategy. You designed six reproducible test cases with priorities, data, steps, expected results, actual results, statuses, and evidence links.
Execute browser tests across authentication, cart behavior, checkout validation, and order completion. You distinguished expected negative behavior from the data-entry defect shown by problem_user.
Write an evidence-backed defect report for BUG-001 using neutral reproduction steps. You linked requirements, risks, test cases, results, and defects through a traceability matrix. You used the evidence trail to support a release recommendation.
Secret Mission: Extended authentication coverage with a four-row decision table. You verified four distinct validation paths against their expected messages.

Ready to quiz yourself?