Aviation Web Learning Lab
EN / ID
Theme

Module 3 - Day 1 of 2

Gemini Web Chat

Day 1: Test Planning

Welcome to Day 1 of Manual UAT! Before any aircraft is released for flight, a quality inspector performs a pre-flight inspection -- checking every system, one at a time, using a written checklist. Today you will learn User Acceptance Testing (UAT), which is exactly like that pre-flight inspection but for software. You built your Aircraft Maintenance Log app in Module 2, and you wrote the PRD for it in Module 1. Now it is time to test that app systematically to make sure everything works correctly. Today is all about planning: you will identify what features to test from your PRD, create test scenarios, build a test case table, and prepare a bug report template. You will use Gemini Web Chat to help you generate these UAT documents. No coding today -- just planning. By the end of the day, you will have a complete test plan ready for Day 2 execution. This project is for learning software development only. It is not a real aircraft maintenance or aviation safety system.

Step 1

Understand what User Acceptance Testing (UAT) is

Concept

Before a pilot flies a newly maintained aircraft, a quality inspector walks around the aircraft checking every system -- engines, controls, instruments, landing gear. Each system is tested individually against a written standard. If everything passes, the aircraft is released for flight. If something fails, it goes back for repair. User Acceptance Testing (UAT) works the same way for software: before releasing an application to users, you test every feature systematically against the requirements from your PRD. You check each feature one at a time, write down what you expect to happen, and record whether it actually happened. Pass or Fail -- like serviceable or non-serviceable in aviation maintenance.

Apply

Open Gemini Web Chat in your browser. Ask Gemini to explain what UAT is using the pre-flight inspection analogy, and describe why systematic testing matters before releasing software.

Prompt

I am a complete beginner learning about software testing. Please explain what User Acceptance Testing (UAT) is. Use an aviation analogy: compare UAT to a pre-flight inspection where an inspector checks every system before an aircraft is released for flight. Include: 1. What is UAT? (2-3 simple sentences with the aviation analogy) 2. Why is systematic testing important before releasing software? (1-2 sentences) 3. What are the basic steps of UAT? (bullet list, max 5 items) Keep it simple. I have never done testing before.

Expected Result

You should understand that UAT is a systematic process of testing every feature in your application before it is considered ready -- just like a pre-flight inspection checks every aircraft system before a flight. You do not need to memorize anything yet. Just understand the basic idea: test each feature, record what happens, pass or fail.

Troubleshooting

  • • If Gemini gives a very technical answer with testing frameworks or automation tools, ask it again: "Please simplify. I only need to understand the basic concept of manual testing, no tools or frameworks."
  • • UAT is manual testing done by a person (you), not automated testing done by code. You click buttons, fill forms, and check if the app does what the PRD says it should do.
Step 2

Identify features to test from your PRD

Concept

Before a quality inspector begins a pre-flight inspection, they review the aircraft's maintenance schedule to know which systems need checking. In UAT, you review your PRD to identify every feature that needs testing. Your PRD from Module 1 described exactly what the Aircraft Maintenance Log app should do: Create log entries, Read/view them, Update existing entries, and Delete entries -- the four CRUD operations. You also need to test form validation and the ability to change the status of a maintenance log. Go back to your PRD now and find every feature it describes.

Apply

Open your PRD document from Module 1. Then ask Gemini to help you list all the features described in your PRD that need testing.

Prompt

I wrote a PRD for a simple Aircraft Maintenance Log web application. The app has exactly 1 database table (maintenance_logs) and performs CRUD operations (Create, Read, Update, Delete). Please list all the features from my PRD that need testing. Include: 1. The 4 basic CRUD operations (Create, Read, Update, Delete) 2. Form validation (preventing empty or invalid input) 3. Status changes for maintenance log entries For each feature, write a one-sentence description of what it does. Format as a numbered list.

Expected Result

You should have a numbered list of at least 6 features to test: Create a log entry, Read/view log entries, Update an existing entry, Delete an entry, Validate form input, and Change a log entry status. This list comes directly from your PRD.

Troubleshooting

  • • If you cannot find your PRD from Module 1, use the feature list above. The important thing is to identify all features before writing test cases.
  • • Do not add features that are not in your PRD. If your PRD does not mention search, filters, or user login, you do not need to test those. Stay within scope.
Step 3

Generate UAT test scenarios for each feature

Concept

An inspection checklist does not just say "check the engine." It says "check engine oil level," "check engine temperature gauge," "check for unusual sounds at idle RPM." Each check is specific and testable. In UAT, your test scenarios work the same way. Instead of "test the Create feature," you write specific scenarios like "create a log entry with all valid fields" or "try to create a log entry with empty required fields." Each scenario tests one specific thing about one feature. This is your inspection checklist -- the more specific your scenarios, the better your testing will be.

Apply

Use Gemini to generate test scenarios for each CRUD operation in your app. Ask for specific, testable scenarios -- one thing per scenario.

Prompt

I need to create UAT test scenarios for my Aircraft Maintenance Log web application. It is a simple Laravel app with 1 table (maintenance_logs) and CRUD operations. Please generate test scenarios for these features: 1. Create a new maintenance log entry 2. View/read a maintenance log entry 3. Update an existing maintenance log entry 4. Delete a maintenance log entry 5. Form validation (reject empty or invalid input) 6. Change the status of a maintenance log entry (e.g., Pending to In Progress to Completed) For each feature, write 2 specific test scenarios. Each scenario should describe ONE specific thing to test. Format: ## Test Scenarios ### [Feature Name] 1. [Specific scenario] 2. [Specific scenario]

Expected Result

You should have 12 test scenarios (2 per feature, 6 features). Each scenario describes one specific thing to test, like "Create a log entry with all valid fields: aircraft tail number, date, description, and status" or "Try to submit the create form with all fields left empty." Save these scenarios in a Markdown file.

Troubleshooting

  • • If your scenarios are too vague (like "test the app"), rewrite them to be specific: what exactly will you do, and what exactly should happen?
  • • Each scenario should test only ONE thing. "Create a log entry and then delete it" is two scenarios, not one. Keep them separate so you can record Pass/Fail for each.
Step 4

Create a test case table with proper columns

Concept

Aviation maintenance technicians use structured log sheets with specific columns: Date, ATA Chapter, Work Performed, Technician Name, and Signature. Every entry follows the same format so anyone can read it. Your test case table works the same way. It has fixed columns so every test case is recorded consistently: Test ID (like TC-001), Feature (which part of the app), Test Steps (what you will do), Expected Result (what should happen), Actual Result (what actually happened -- filled in during testing), and Pass/Fail (your verdict). This structure ensures nothing is missed and anyone can understand your testing results.

Apply

Use Gemini to create a Markdown test case table based on the test scenarios from Step 3. Copy the result into your UAT document.

Prompt

I need to create a test case table for my Aircraft Maintenance Log UAT. Please create a Markdown table with these 6 columns: Test ID, Feature, Test Steps, Expected Result, Actual Result, Pass/Fail. Fill in at least 10 test cases covering: - Opening the app and loading the index page (1 test) - Creating a new maintenance log entry (2 tests: valid data and invalid data) - Viewing a log entry detail page (1 test) - Editing an existing log entry (2 tests: change description and change status) - Deleting a log entry (1 test) - Form validation (2 tests: empty fields and invalid data) - Checking summary counts on the index page (1 test) Leave the "Actual Result" and "Pass/Fail" columns empty -- those will be filled during testing on Day 2. Format as a Markdown table.

Expected Result

Your test case table should have 6 columns (Test ID, Feature, Test Steps, Expected Result, Actual Result, Pass/Fail) and at least 10 rows covering all CRUD operations plus validation. The Actual Result and Pass/Fail columns are empty -- you will fill them in during Day 2. Save this table in your UAT Markdown file.

Troubleshooting

  • • If the test steps are too vague (like "test create"), rewrite them to be specific: "Click 'Create New Log' button, fill in tail number ABC-123, date 2025-01-15, description 'Engine oil change', status Pending, click Submit."
  • • Make sure every expected result is something you can verify by looking at the screen. "It works" is not a good expected result. "The new entry appears on the index page with correct data" is specific and verifiable.
Step 5

Prepare a bug report template

Concept

When an aviation maintenance technician finds a problem during an inspection, they fill out a discrepancy report: what they found, where they found it, and how serious it is. In software testing, when you find something that does not work correctly, you write a bug report. A good bug report helps someone else understand exactly what went wrong and how to reproduce it. Your bug report template should have: Bug ID, Description (what went wrong), Steps to Reproduce (how to make it happen again), Expected Result (what should have happened), Actual Result (what actually happened), and Severity (how serious: High, Medium, or Low).

Apply

Use Gemini to create a Markdown bug report template that you can copy and fill in whenever you find a bug during testing.

Prompt

I need a bug report template for my UAT testing. Please create a Markdown template with these fields: - Bug ID (format: BUG-001, BUG-002, etc.) - Description (what went wrong) - Steps to Reproduce (numbered list of exactly what I did) - Expected Result (what should have happened) - Actual Result (what actually happened) - Severity (High / Medium / Low) Create the template with one example bug filled in so I can see how it looks. Use this example: trying to create a log entry without filling in the description field does not show an error message. Format as Markdown headings and lists.

Expected Result

You should have a Markdown bug report template with 6 fields (Bug ID, Description, Steps to Reproduce, Expected Result, Actual Result, Severity) and one filled-in example. Save this as a separate section in your UAT document. You will copy this template for each bug you find during testing.

Troubleshooting

  • • The most important part of a bug report is "Steps to Reproduce." If someone else cannot make the bug happen by following your steps, the bug report is not useful. Be very specific.
  • • Severity is not about how annoyed you are -- it is about how broken the feature is. High = data loss or app crash, Medium = feature does not work correctly but app still runs, Low = visual issue or minor inconvenience.
Step 6

Organize your test materials for Day 2

Concept

Before an aircraft inspection begins, the inspector lays out all tools and checklists on the workbench: inspection forms, a flashlight, a mirror, calibration certificates, and reference manuals. Everything is organized and within reach. Tomorrow you will execute your tests against the running Laravel app, so today you need to organize all your test materials. You should have: your test scenarios, your test case table, your bug report template, and your PRD for reference. Save everything in one Markdown file or folder so it is ready for Day 2.

Apply

Ask Gemini to help you create a summary document that organizes all your test materials into one structured Markdown file.

Prompt

I have completed my UAT test planning. I now have: 1. A list of features to test (from my PRD) 2. Test scenarios (12 scenarios covering all CRUD operations and validation) 3. A test case table (10+ test cases with Test ID, Feature, Test Steps, Expected Result, Actual Result, Pass/Fail columns) 4. A bug report template (Bug ID, Description, Steps to Reproduce, Expected Result, Actual Result, Severity) Please create a summary document in Markdown that organizes all of these into one file. Use this structure: # UAT Test Plan - Aircraft Maintenance Log ## 1. Features to Test ## 2. Test Scenarios ## 3. Test Case Table ## 4. Bug Report Template ## 5. Test Materials Checklist Under "Test Materials Checklist," list what I need ready for Day 2 (test plan document, running Laravel app, browser, pen for notes).

Expected Result

You should have one complete Markdown file containing your entire UAT test plan: features list, test scenarios, test case table, bug report template, and a Day 2 materials checklist. Save this file as "uat-test-plan.md" or similar. You will use this document tomorrow during test execution.

Troubleshooting

  • • If your test plan document is getting too long, that is fine. A thorough test plan is better than a short one. You will only fill in the Actual Result and Pass/Fail columns during Day 2.
  • • Make sure your test case table has empty "Actual Result" and "Pass/Fail" columns for Day 2. If those columns are already filled in, remove the content -- you have not tested yet.

Self-Check

Quiz