Step 1
Open the Laravel app and verify it runs
Concept
Before a pre-flight inspection begins, the first step is to power on the aircraft and confirm the instrument panel lights up. No point checking individual systems if the aircraft has no power. Similarly, before testing your app, you need to confirm it starts and loads in the browser. You will run php artisan serve (the command you used in Module 2) and open your browser to localhost:8000. The maintenance logs index page should load -- it might show entries you created during Module 2, or it might be empty if you did not add test data. Either way is fine. What matters is that the page loads without errors.
Apply
Open your terminal, navigate to your Laravel project folder, and run php artisan serve. Then open your browser and go to localhost:8000. Use Gemini to help troubleshoot if the app does not load.
Prompt
I built a Laravel web application in my previous module. It is an Aircraft Maintenance Log app with CRUD operations for maintenance_logs. I need to start the app for testing. Please write the exact terminal commands I need:
1. Navigate to my Laravel project folder (assume it is called "aircraft-maintenance-log")
2. Start the Laravel development server
3. What URL should I open in my browser to see the maintenance logs index page?
Keep it simple -- just the commands and the URL.
Expected Result
The Laravel development server should start (you see "Starting Laravel development server" in the terminal). When you open localhost:8000 in your browser, the maintenance logs index page loads. It may show existing log entries or an empty state -- either is correct. The page should not show any error messages. Record this as Test TC-001 in your test case table: Pass if the page loads, Fail if it shows an error.
Troubleshooting
-
• If "php artisan serve" gives an error, make sure you are in the correct project folder. Run "ls" or "dir" to check for artisan file. If artisan is not there, you are in the wrong folder.
-
• If the page shows a database error, you may need to run "php artisan migrate" again to set up the SQLite database. This was covered in Module 2.
Step 2
Test the Create log entry flow
Concept
When an aviation maintenance technician installs a new component, they verify it works correctly before signing off. Testing the Create flow is like that installation verification: you fill in the form with test data, submit it, and confirm the new entry appears correctly. Use realistic aviation test data: tail number like "PK-ABC", description like "Engine oil change -- replaced filter and added 5 quarts of Shell W100", and status "Pending." Check that every field saves correctly and the new entry shows up on the index page.
Apply
In your browser, navigate to the Create form and fill it in with test data. Submit the form and check the result. Record Pass/Fail in your test case table.
Prompt
I am testing the Create feature of my Aircraft Maintenance Log Laravel app. I need test data for 2 test cases:
1. Valid data: All fields filled with correct values (tail number, date, description, status, technician name)
2. Invalid data: Required fields left empty to test validation
For test case 1, please generate realistic aviation maintenance test data:
- Tail number: use a realistic format (e.g., PK-ABC)
- Date: use today's date
- Description: write a realistic maintenance description (e.g., engine oil change, tire inspection, brake pad replacement)
- Status: Pending
- Technician name: use a generic name
Format each test case as: "Fill in [field] with [value]" for each field, then "Click Submit."
Expected Result
For the valid test case: after filling in all fields and clicking Submit, the new maintenance log entry should appear on the index page with all the correct data (tail number, date, description, status). For the invalid test case (empty required fields): the form should reject the submission and display an error message asking you to fill in the required fields. Record both results in your test case table.
Troubleshooting
-
• If the form accepts empty fields without showing an error, that is a bug. Record it in your bug report template with the steps to reproduce.
-
• If the new entry does not appear on the index page after submission, check if the data actually saved. Try refreshing the page. If still missing, record this as a bug.
Step 3
Test Read/View operations and check summary counts
Concept
During a pre-flight inspection, the pilot checks each instrument reading against the expected values: fuel gauge shows full, altimeter reads field elevation, engine RPM within range. Testing the Read/View feature is like checking instrument readings: you open a specific maintenance log entry and verify that every field displays the correct data. You also check the index page summary counts -- if you have 3 Pending entries, 2 In Progress, and 1 Completed, the summary should show those exact numbers. Every detail must match.
Apply
Click on a maintenance log entry to view its detail page. Check every field. Then go back to the index page and check if any summary counts are displayed. Record Pass/Fail.
Prompt
I am testing the Read/View feature of my Aircraft Maintenance Log app. I need a checklist of things to verify when viewing a maintenance log entry detail page. Please create a simple checklist I can follow:
1. What fields should I check on the detail page? (list all fields that should be visible)
2. How do I verify the data matches what I entered during the Create test?
3. What summary counts should I check on the index page? (e.g., Pending, In Progress, Completed)
Format as a simple numbered checklist.
Expected Result
On the detail page, every field should display the exact data you entered during the Create test: tail number, date, description, status, and technician name should all match. On the index page, summary counts (if your app shows them) should match the actual number of entries in each status category. If counts are wrong or fields show incorrect data, record a bug.
Troubleshooting
-
• If the detail page shows "N/A" or blank fields, the data may not have saved correctly. Go back and create another entry, then check again.
-
• Summary counts on the index page may not exist if your PRD did not specify them. That is fine -- just check that the index page shows your entries correctly.
Step 4
Test Update and Delete flows
Concept
In aviation maintenance, when a technician corrects a log entry (Update) or removes an erroneous one (Delete), they follow strict procedures to ensure the change is handled properly and nothing else is affected. Testing Update and Delete works the same way. For Update: you edit an existing maintenance log entry, change some fields (like the description and status), save, and verify the changes appear correctly. For Delete: you remove one entry and confirm it no longer appears on the index page, while all other entries remain intact. These are critical operations -- you want to be sure data can be changed and removed without side effects.
Apply
Edit an existing log entry to change its description and status. Then delete a different entry. Verify both operations worked correctly. Record Pass/Fail for each.
Prompt
I am testing the Update and Delete features of my Aircraft Maintenance Log Laravel app. Please give me specific test data and steps for 3 test cases:
Test case 1 (Update description): Edit an existing log entry and change the description to "Hydraulic system inspection -- all lines checked, no leaks found." What should I verify after saving?
Test case 2 (Update status): Edit the same or another entry and change its status from "Pending" to "In Progress" or "Completed." What should I verify after saving?
Test case 3 (Delete): Delete one maintenance log entry. What should I verify to make sure the delete worked correctly and other entries are not affected?
Format each test case as numbered steps.
Expected Result
For Update tests: after editing and saving, the entry should show the new description and/or new status. The old data should be replaced, not duplicated. For Delete test: the deleted entry should no longer appear on the index page. All other entries should remain untouched -- their data should be exactly the same as before. Record Pass for each test if the result matches expectations, or Fail with a bug report if not.
Troubleshooting
-
• If the edit form shows old data after saving, the update may not have worked. Check if there is a confirmation message or if the data actually changed on the index page.
-
• If deleting an entry causes other entries to disappear, that is a serious bug. Record it with High severity in your bug report.
Step 5
Test validation and edge cases
Concept
Aviation systems are stress-tested to ensure they handle abnormal conditions safely. An engine is tested at maximum RPM, landing gear is tested under maximum load, and instruments are tested in extreme temperatures. In software testing, edge cases are your stress tests: what happens when you try to submit an empty form? What happens when you enter extremely long text? What about special characters in the description? These abnormal inputs should not break your app -- they should be handled gracefully with clear error messages. Testing edge cases is how you find out if your app is robust or fragile.
Apply
Try submitting forms with empty fields, invalid data, and very long text. Check that the app rejects bad input and shows error messages. Record Pass/Fail for each test.
Prompt
I am testing edge cases and validation for my Aircraft Maintenance Log Laravel app. Please give me specific test cases for validation and edge case testing:
Test case 1: Submit the create form with ALL fields left empty. What should happen?
Test case 2: Submit the create form with very long text (200+ characters) in the description field. What should happen?
Test case 3: Try to change the status of a log entry and immediately go back without saving. What should happen?
For each test case, tell me: (a) what to do, (b) what I should expect to see, (c) whether it is Pass or Fail.
Keep it simple -- I am testing manually in the browser.
Expected Result
Empty form submission should show validation error messages indicating which fields are required. Very long text should either be accepted (if your app allows it) or show a maximum length error. Changing status and navigating away without saving should not save the change. None of these edge cases should cause the app to crash or show a server error page. Record results in your test case table.
Troubleshooting
-
• If submitting an empty form causes a server error (a white page with technical text), that is a bug with High severity. The app should show a friendly error message, not crash.
-
• If very long text causes the app to break, record it as a bug. In a real application, you would add character limits to prevent this.
Step 6
Generate the UAT summary report
Concept
After completing a maintenance inspection, the quality inspector writes a Maintenance Release Certificate -- an official document that summarizes the inspection results: what was checked, what passed, what failed, what needs fixing, and the overall airworthiness determination. Your UAT summary report is like that certificate. It documents the total number of tests run, how many passed, how many failed, what bugs were found, and your overall assessment: is the app Ready or Not Ready for release? You will also do two final checks: verify the app displays correctly on a mobile-sized screen, and confirm all aviation terminology in the app is correct and appropriate.
Apply
Use Gemini to help create a Markdown summary report documenting all your test results. Include the mobile readability check and aviation terminology check.
Prompt
I have finished testing my Aircraft Maintenance Log Laravel app. I ran 10+ test cases covering all CRUD operations (Create, Read, Update, Delete), form validation, and status changes. I need to write a UAT summary report. Please create a Markdown template for:
## UAT Summary Report
### Aircraft Maintenance Log Application
1. Test Summary (total tests, passed, failed)
2. Test Results Table (copy from my test case table with filled-in Actual Result and Pass/Fail)
3. Bugs Found (list each bug with severity)
4. Mobile Readability Check (does the app display correctly on a phone-sized screen?)
5. Aviation Terminology Check (are terms like "maintenance log", "tail number", "status" used correctly?)
6. Overall Assessment (Ready / Not Ready for release -- and why)
7. Recommendations (what should be fixed before the app is considered complete)
Leave placeholder text in brackets [like this] where I need to fill in my actual results.
Expected Result
You should have a complete UAT summary report in Markdown format covering all 7 sections: test summary, results table, bugs found, mobile readability check, aviation terminology check, overall assessment, and recommendations. Fill in the placeholder text with your actual test results. This report is your final deliverable for Module 3. Congratulations -- you have completed the full development lifecycle: planned your app in Module 1 (PRD), built your app in Module 2 (Laravel), and tested your app in Module 3 (UAT).
Troubleshooting
-
• For the mobile readability check, resize your browser window to a narrow width (like a phone screen) or use your browser's responsive design mode. Check that text is readable and buttons are clickable.
-
• For the aviation terminology check, look at all the text displayed in your app: page titles, button labels, form labels, and status values. Terms like "maintenance log," "tail number," and "technician" should be used correctly and consistently.