Commit 383953

2026-08-26 13:41:28 lisa: sd: add C09 beta testing study pages (18 pages via the shared port script); hub link Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011wnT73o2z6piKdyVNGHhx2

/dev/null .. sd/C09/Beta Test Execution.md
@@ 0,0 1,79 @@
+	<!-- Generated from applied-computing-au vic/unit3-4/sat/C09-2026 by port-reference-godot-to-wiki.py — do not hand-edit; re-run the port. -->
+	# 9-2 Beta Test Execution
+
+	## Running Your Beta Test Session
+
+	You've planned your beta test (C9-1) and chosen your data collection methods. Now it's time to actually run the testing sessions with your users.
+
+	---
+
+	## Before the Session
+
+	Prepare a consistent setup for every tester:
+
+	1. **Environment** — Have the solution installed/accessible and ready to go. Remove any debug screens or developer tools visible to the user.
+	2. **Materials** — Print or share your survey, observation sheet, and interview questions before the session starts.
+	3. **Briefing script** — Write a short intro you'll read to every tester so they all receive the same information. Include what the software does, what you'd like them to try, and that honest feedback is welcome.
+
+	> **Tip:** Do a quick dry run with a classmate first. This catches setup issues before your real testers arrive.
+
+	---
+
+	## During the Session
+
+	| Do | Don't |
+	|---|---|
+	| Let the user explore naturally | Jump in and fix things for them |
+	| Take notes on what you observe | Only rely on what the user tells you |
+	| Use your planned test scenarios | Make up tasks on the spot |
+	| Record the session (with permission) | Forget to ask for consent first |
+	| Stay neutral — "Tell me more about that" | Lead with "Isn't this feature great?" |
+
+	### Collecting Data As You Go
+
+	For each tester, you should be gathering evidence across your chosen methods simultaneously:
+
+	- **Observation** — Note task completion times, errors, hesitations and navigation paths as they happen.
+	- **Survey** — Hand this to the user immediately after they finish the test scenarios, while the experience is fresh.
+	- **Interview** — If using interviews, conduct these after the survey. Follow up on anything interesting you observed.
+
+	---
+
+	## After Each Session
+
+	Before your next tester arrives:
+
+	1. Label all data with the tester's identifier (e.g. "User A", "User B" — not real names in your submission).
+	2. Save any screen recordings or photos.
+	3. Jot down your own reflections while they're fresh — anything that surprised you or that you'd adjust for the next session.
+
+	---
+
+	## Scaling Up: What the Criteria Expect
+
+	| Level | What's Expected |
+	|---|---|
+	| C9-2-1 | Conduct beta testing with **one** potential user |
+	| C9-2-3 | Conduct beta testing and list results using **one** data collection method |
+	| C9-2-5 | Conduct beta testing and collect results using **two** data collection methods |
+	| C9-2-7 | Conduct beta testing with **multiple** users and collect results using **three or more** data collection methods |
+	| C9-2-9 | Prepare the data collected for documenting the results |
+
+	To aim high, you need **multiple users** and **three or more methods** (e.g. survey + observation + interview). You also need to organise your raw data so it's ready for your results report in C9-3.
+
+	---
+
+	## Quick Evidence Checklist
+
+	- [ ] Briefing script used consistently across testers
+	- [ ] Test scenarios followed as planned in C9-1
+	- [ ] Observation notes taken during each session
+	- [ ] Survey completed by each tester
+	- [ ] Interview responses recorded (if applicable)
+	- [ ] Screen recordings or photos saved (if applicable)
+	- [ ] All data labelled and organised by tester
+	- [ ] Raw data prepared and ready for C9-3 documentation
+
+	---
+
+	_This activity connects directly to your C9-1 beta testing plan. The evidence you gather here feeds into your C9-3 results report and C9-4 recommendations._
/dev/null .. sd/C09/Beta Testing Case Study Pocket Prep.md
@@ 0,0 1,100 @@
+	<!-- Generated from applied-computing-au vic/unit3-4/sat/C09-2026 by port-reference-godot-to-wiki.py — do not hand-edit; re-run the port. -->
+	# 9-0 Beta Testing Case Study: Pocket Prep
+
+	_A real company example for high school software development students_
+
+	---
+
+	## About Pocket Prep (Real Company)
+
+	**Pocket Prep** is a real educational technology company that creates exam preparation apps. They help tens of thousands of people prepare for professional certification exams in nursing, IT, medical, skilled trades, and other industries.
+
+	**Company Details:** _(Source: Pocket Prep website + Usersnap case study)_
+
+	- **Team Size**: 5 developers + 13 other staff members
+	- **Products**: Mobile and web apps for exam preparation across multiple professional fields
+	- **Users**: Students, professionals, and educators preparing for certifications
+	- **Business Model**: Monthly subscriptions ($15-$20) with free basic version
+
+	---
+
+	## Their Beta Testing Approach _(Source: Usersnap case study)_
+
+	### Who Tests Their Apps?
+
+	Beta-tested with ~50 known users from a dozen client schools. _(Pocket Prep β-test case study, Usersnap)_
+
+	### How Do They Collect Feedback?
+
+	**Method 1: Regular Meetings** Business development managers meet with customers for face-to-face discussions
+
+	**Method 2: In-App Feedback Tool** Simple feedback button where users can send screenshots with comments. _(Pocket Prep β-test case study, Usersnap)_ This approach "takes one minute to send feedback compared to writing an extensive email or filling out a technical bug report that takes more than 10 minutes every time."
+
+	### How Long Does Beta Testing Take?
+
+	**2-3 quarters (6-9 months)** - _(Pocket Prep β-test case study, Usersnap)_ "We are keen on doing it right the first time. If we ship fast but not great, it will only upset our users. And this is also how we've built strong customer relationships." - Colin Ulin, Senior Software Engineer
+
+	---
+
+	## Types of Feedback They Get _(Source: Usersnap case study)_
+
+	### Real Examples from Their Testing:
+
+	_(Pocket Prep β-test case study, Usersnap)_ "We get feedback from beta users about what they think is broken, when in fact it's just the feature not working as they expected. This helps us understand that the feature is not ready yet." - Colin Ulin
+
+	**Categories identified:**
+
+	- **Bug Reports**: Technical problems and crashes
+	- **Feature Requests**: Missing functionality users want
+	- **User Experience Issues**: Features that work but confuse users
+
+	---
+
+	## Real Results from Their Beta Testing _(Multiple sources)_
+
+	### Verified Success Metrics:
+
+	- **Tens of thousands of active users** across their platform
+	- **Award-winning app** recognition _(Pocket Prep β-test case study, Usersnap)_
+	- **Strong customer relationships** built through feedback process
+
+	### Their Approach Results:
+
+	_(Pocket Prep β-test case study, Usersnap)_ "Listening to feedback and building smart solutions to those pain points takes time. But in return, your product can harvest memorable UX and customer loyalty."
+
+	---
+
+	## How They Know Beta Testing Is Complete _(Pocket Prep β-test case study, Usersnap)_
+
+	**Model Exit-Criteria Example for Students:**
+
+	"If after some iterations, they get positive feedback or stop receiving complaints, then it's champagne time. But if similar feedback continues, then they would know the solution(s) did not work."
+
+	**Key Success Criterion**: No exact cutoff point exists, but use the amount and type of user feedback as references for completion.
+
+	---
+
+	## Lessons for Student Projects _(Practical Applications)_
+
+	### What Pocket Prep's Success Shows:
+
+	✅ **Small teams can do professional beta testing** (5 developers managed it)
+	✅ **Real users find different problems** than internal testing
+	✅ **Simple feedback tools work better** than complex processes
+	✅ **Quality over speed** leads to better long-term success
+
+	### Adaptations for Student SATs:
+
+	- **Scale down**: 10-15 testers instead of 50
+	- **Shorter timeline**: 4-6 weeks instead of 6-9 months
+	- **Simple tools**: Google Forms + direct observation
+	- **Same principles**: Real users, multiple methods, iterate based on feedback
+
+	---
+
+	## References
+
+	1. **Pocket Prep Website**: https://www.pocketprep.com/ _(accessed for company background)_
+	2. **Usersnap Case Study**: "How to beta test, a robust example from award-winning learning app Pocket Prep" _(provided document - source of quotes and process details)_
+
+	**Note**: Specific satisfaction scores and percentages in original version were illustrative examples, not actual Pocket Prep data. This revised version only includes verified information from the provided sources.
\	No newline at end of file
/dev/null .. sd/C09/Beta Testing Plan Example Godot Tetris.md
@@ 0,0 1,194 @@
+	<!-- Generated from applied-computing-au vic/unit3-4/sat/C09-2026 by port-reference-godot-to-wiki.py — do not hand-edit; re-run the port. -->
+	# 9-1 Beta Testing Plan — Worked Example (Godot Tetris)
+
+	> **How to use this:** this is a *completed* plan at the scale your SAT expects — 3 testers, 3+ collection methods, a testing window of half a week plus a weekend. Read it beside `C091-Beta-Testing-Plan-Template.md` (same sections, filled in), then write the same kind of plan for **your** solution against **your** SRS. The 💡 boxes explain what each section is doing for the score — leave them out of your own plan.
+
+	---
+
+	## Beta Testing Plan For:
+
+	**Software Solution Name:** Godot Tetris — a modern falling-blocks game (solo + two-player LAN versus), built in Godot 4.7
+
+	**Target Users:** students aged 12–18 who play casual games on school laptops; two players sharing a LAN for versus mode
+
+	---
+
+	## 1. Objective
+
+	**Primary Goal:** Confirm that the finished game is playable, understandable and stable in the hands of real players — the interface reads clearly, the modern mechanics (hold, ghost piece, hard drop, wall kicks) behave as players expect, and a two-player LAN match runs start-to-finish without failure.
+
+	**Testing Focus:**
+
+	- [x] **Appearance** (interface design, visual consistency)
+	- [x] **Functionality** (core features working correctly)
+	- [x] **User Experience** (ease of use, workflow efficiency)
+	- [x] **Performance** (speed, reliability, compatibility)
+
+	> 💡 *The objective names the actual solution and what "working" means for it — not "test the game to find bugs". It targets appearance AND functionality AND requirements: that's the 3–4, 5–6 and 7–8 band behaviours in one sentence each.*
+
+	---
+
+	## 2. Test Scenarios
+
+	### Scenario 1 — Appearance Testing: "Can you read the board?"
+
+	*Targets SRS non-functional requirements: usability (visual clarity), consistency of the interface.*
+
+	Testers judge whether the play field, next-piece preview, hold slot, ghost piece, score and level display communicate without explanation.
+
+	**Detailed User Steps:**
+
+	- **Step 1 — Preparation:** open the game on a school laptop; do not explain anything.
+	- **Step 2 — Starting Activity:** tester starts a solo game from the menu unaided.
+	- **Step 3 — During Activity:** after two minutes, tester points at each on-screen element and says what they think it shows (score, level, next piece, hold slot, ghost outline).
+	- **Step 4 — Ending Activity:** tester plays until game over and describes what the game-over screen tells them.
+	- **Step 5 — Post-Activity Review:** short survey items on visual clarity (1–5 scales).
+
+	**Specific Feedback Points:** Was the ghost piece understood without being told? Is the hold slot's "once per piece" state visible? Does the score/level area draw attention when a level-up happens?
+
+	### Scenario 2 — Functionality Testing: "Do the mechanics do what players expect?"
+
+	*Targets SRS functional requirements: rotation with wall kicks (FR-3), hold (FR-5), hard/soft drop and scoring (FR-7), line clears and levelling (FR-8).*
+
+	**Detailed User Steps:**
+
+	- **Step 1 — Preparation:** hand the tester the one-page controls card (←/→ move, ↓ soft drop, ↑/X and Z rotate, Space hard drop, C/Shift hold).
+	- **Step 2 — Starting Activity:** tester attempts each control once in their first game.
+	- **Step 3 — During Activity:** set tasks — rotate a piece flush against the wall (wall kick), hold a piece and retrieve it, clear two lines with one drop, reach level 2.
+	- **Step 4 — Ending Activity:** observer checks the final score against the scoring table (100/300/500/800 × level, +1 per soft-drop cell, +2 per hard-drop cell).
+	- **Step 5 — Post-Activity Review:** tester reports anything that "felt wrong" (a rotation that refused, a piece that locked too early, a hold that didn't respond).
+
+	**Specific Feedback Points:** Did any rotation near the wall surprise the tester? Did the 0.5 s lock delay feel fair or frustrating at speed? Did the displayed score match the events observed?
+
+	### Scenario 3 — User Experience Testing: "A full versus match, cold"
+
+	*Targets UX characteristics: learnability, efficiency, error tolerance. Targets SRS reliability requirement: a LAN session survives a complete match.*
+
+	**Detailed User Steps:**
+
+	- **Step 1 — Preparation:** two testers, two laptops, same LAN; neither has played versus mode.
+	- **Step 2 — Starting Activity:** testers follow the lobby screen to connect to each other unaided (host + join).
+	- **Step 3 — During Activity:** play one full match; observer logs any confusion, disconnection, or garbage-row event the players don't understand.
+	- **Step 4 — Ending Activity:** the match ends; testers state who won and how they know.
+	- **Step 5 — Post-Activity Review:** paired interview — what nearly stopped you, what would you change?
+
+	**Specific Feedback Points:** Time from "open game" to "match running" without help; whether incoming garbage rows read as an attack; whether the win/lose screen is unambiguous.
+
+	> 💡 *Scenarios are real tasks with steps a stranger could run, not "click each button". Each names the FR/NFRs it exercises — that's the 7–8 band — and Scenario 3 targets UX characteristics by name, which is the 9–10 band behaviour.*
+
+	---
+
+	## 3. Potential Users
+
+	| User | Who are they? | Why selected? | Available when? |
+	|------|---------------|---------------|-----------------|
+	| **User 1** | Year 8 student, plays mobile puzzle games, has never played Tetris | Reads the interface with fresh eyes — the learnability test can't be faked with an experienced player | Lunchtimes this week |
+	| **User 2** | Year 11 student, experienced Tetris player (plays online guideline Tetris) | Knows how hold, ghost and wall kicks *should* behave, so deviations from expectations surface immediately | After school Thu/Fri |
+	| **User 3** | Parent, plays no games, uses a laptop daily for work | Extreme-novice check on menus, controls card and game-over flow; also my weekend tester | Saturday |
+
+	**Why these users represent your target audience:** the target users are casual players on school laptops — Users 1 and 2 bracket that range (novice → expert), and User 3 tests whether the interface survives someone outside it. Users 1+2 together also form the LAN pair for Scenario 3.
+
+	> 💡 *Each tester has a reason tied to what they reveal — that's "explains why potential users have been selected" (5–6 band). Role descriptions are fine; full names are not required.*
+
+	---
+
+	## 4. Methodology
+
+	### User Recruitment:
+
+	Ask in person this week; confirm each session time by message the day before. Consent forms handed out and **signed before any session is recorded** — no consent form, no session video.
+
+	### Data Collection Methods:
+
+	- [x] **Direct observation** (watch users during testing)
+	- [x] **Interviews** (verbal feedback sessions)
+	- [x] **Surveys/questionnaires** (structured feedback forms)
+	- [x] **Error logging** (track problems encountered)
+
+	### How Results Will Be Collected:
+
+	**Method 1:** Observation sheet (printed, one per session) — one row per event: time, what happened, tester reaction.
+
+	**Method 2:** Post-session survey (Google Form, 10 items: 1–5 scales on clarity/controls/fun + two open questions) — link sent as the session ends.
+
+	**Method 3:** Recorded interview (audio) using the six-question interview sheet; ~5 minutes per tester.
+
+	**Method 4:** Error log (spreadsheet) — every crash, disconnect, or "that's wrong" moment with steps to reproduce.
+
+	### Data Validation Methods:
+
+	**Comparison Method:** survey answers cross-checked against what the observation sheet actually recorded — a tester who rates controls 5/5 but fumbled hold for three pieces gets a follow-up question in the interview.
+
+	**Known Benchmarks:** final scores checked against the scoring table; gravity/level progression checked against the level formula (level = 1 + lines ÷ 10).
+
+	**External Validation:** User 2's expectations from mainstream guideline Tetris act as the reference for "standard" mechanic behaviour.
+
+	> 💡 *Four methods, and every method names its instrument — a survey that exists beats a "survey" that doesn't. Instruments must be ready before the first session: that's what the simulation checks.*
+
+	---
+
+	## 5. Timeline
+
+	| Phase | Duration | Activities |
+	|-------|----------|------------|
+	| **Setup** | ½ day | Print observation sheets + controls cards, build the survey form, collect signed consent forms, test the LAN pairing on two school laptops |
+	| **Active Testing** | 3 days (two weekdays + Saturday) | Users 1 & 2 individually (Scenarios 1–2), Users 1+2 paired (Scenario 3), User 3 on Saturday (Scenarios 1–2) |
+	| **Results & Feedback** | 1 day | File raw data into the evidence folder, complete the error log, write the deviation note |
+
+	> 💡 *Total: half a week plus a weekend — the scale the assessment expects. Three testers, four sessions. A 6-week 12-tester plan (like the EasyRetail commercial exemplar) would fail the "realistic for the window" check.*
+
+	---
+
+	## 6. Resources
+
+	### Hardware/Software Requirements:
+
+	Two school laptops on the same LAN (versus needs both); the exported game build installed on each; any keyboard works — controls use physical key positions, not letters.
+
+	### Support Materials for Users:
+
+	One-page controls card; consent form; the tester never sees the code or the plan.
+
+	---
+
+	## 7. Success Criteria
+
+	### Primary Success Measures:
+
+	- Every tester starts a solo game unaided in under 1 minute (learnability).
+	- All set mechanic tasks (wall-kick rotation, hold, double line clear, reach level 2) completed by Users 1 and 2.
+	- One full LAN versus match completes with no disconnection and an unambiguous result.
+	- Displayed scores match the scoring table in every observed session.
+
+	### User Satisfaction Targets:
+
+	- Visual clarity and controls both average ≥ 4/5 on the survey.
+	- No tester abandons a session.
+
+	### Decision Framework:
+
+	**What results would indicate success?** All primary measures met and the error log holds only minor items → proceed to recommendations with priorities from the survey's open questions.
+
+	**What results would require major changes?** Any crash or LAN failure, a mechanic that confused both novice testers, or scores that don't match the table → these become the top recommended modifications in the C9-3/C9-4 report.
+
+	> 💡 *Success criteria are countable afterwards — "≥ 4/5", "under 1 minute", "no disconnection" — so the report can say* whether *the test passed, not just how it felt.*
+
+	---
+
+	## Quality Checklist
+
+	**C9-1 Assessment Criteria:**
+
+	- [x] **C9-1-1:** Components clearly identified for testing
+	- [x] **C9-1-3:** Plan targets software appearance AND outlines potential users
+	- [x] **C9-1-5:** Plan targets functionality AND explains why users were selected
+	- [x] **C9-1-7:** Plan targets functional AND non-functional requirements AND documents how results will be collected
+	- [x] **C9-1-9:** Test scenarios target user experience characteristics AND documentation is clear and concise
+
+	**Professional Standards:**
+
+	- [x] All user selections include clear rationale (**"why selected"**)
+	- [x] Multiple data collection methods documented (**"how collected"**)
+	- [x] Test scenarios focus on relevant characteristics of your software solution
+	- [x] Timeline is realistic for user coordination and testing
+	- [x] All sections completed with clear, professional information
/dev/null .. sd/C09/Beta Testing Plan Template.md
@@ 0,0 1,222 @@
+	<!-- Generated from applied-computing-au vic/unit3-4/sat/C09-2026 by port-reference-godot-to-wiki.py — do not hand-edit; re-run the port. -->
+	<!--
+	Source: Beta Testing Plan Template.qmd (acsddev/25-SAT/SAT-9/)
+	Converted from .qmd by hand
+	-->
+
+	## Beta Testing Plan For:
+
+	**Software Solution Name:**
+	_____________________________________________________________________
+
+	**Target Users:**
+	_____________________________________________________________________
+
+	---
+
+	## 1. Objective
+
+	*What are the main goals of this beta testing?*
+
+	**Primary Goal:**
+
+	&nbsp;
+
+	**Testing Focus:** *(Tick all that apply)*
+
+	- [ ] **Appearance** (interface design, visual consistency)
+	- [ ] **Functionality** (core features working correctly)
+	- [ ] **User Experience** (ease of use, workflow efficiency)
+	- [ ] **Performance** (speed, reliability, compatibility)
+
+	---
+
+	## 2. Test Scenarios
+
+	*What functionality will be tested?*
+
+	### Scenario 1 - Appearance Testing:
+	*What will users test about the interface/design?*
+
+	&nbsp;
+
+	**Detailed User Steps:**
+
+	- **Step 1 - Preparation:** _________________________________
+	- **Step 2 - Starting Activity:** ____________________________
+	- **Step 3 - During Activity:** _____________________________
+	- **Step 4 - Ending Activity:** ______________________________
+	- **Step 5 - Post-Activity Review:** __________________________
+
+	**Specific Feedback Points:**
+
+	&nbsp;
+
+	### Scenario 2 - Functionality Testing:
+	*What core features will users test?*
+
+	&nbsp;
+
+	**Detailed User Steps:**
+
+	- **Step 1 - Preparation:** _________________________________
+	- **Step 2 - Starting Activity:** ____________________________
+	- **Step 3 - During Activity:** _____________________________
+	- **Step 4 - Ending Activity:** ______________________________
+	- **Step 5 - Post-Activity Review:** __________________________
+
+	**Specific Feedback Points:**
+
+	&nbsp;
+
+	### Scenario 3 - User Experience Testing:
+	*What user workflows/tasks will be tested?*
+
+	&nbsp;
+
+	**Detailed User Steps:**
+
+	- **Step 1 - Preparation:** _________________________________
+	- **Step 2 - Starting Activity:** ____________________________
+	- **Step 3 - During Activity:** _____________________________
+	- **Step 4 - Ending Activity:** ______________________________
+	- **Step 5 - Post-Activity Review:** __________________________
+
+	**Specific Feedback Points:**
+
+	&nbsp;
+
+	---
+
+	## 3. Potential Users
+
+	*Who will do the beta testing?*
+
+	| User | Who are they? | Why selected? | Available when? |
+	|------|---------------|---------------|-----------------|
+	| **User 1** | | | |
+	| **User 2** | | | |
+	| **User 3** *(Optional)* | | | |
+
+	**Why these users represent your target audience:**
+
+	&nbsp;
+
+	---
+
+	## 4. Methodology
+
+	*How will users be recruited and provide feedback?*
+
+	### User Recruitment:
+	*How will you contact and invite your beta testers?*
+
+	&nbsp;
+
+	### Data Collection Methods:
+	*Select 3+ methods you will use to collect feedback*
+
+	- [ ] **Direct observation** (watch users during testing)
+	- [ ] **Interviews** (verbal feedback sessions)
+	- [ ] **Surveys/questionnaires** (structured feedback forms)
+	- [ ] **Screen recording** (capture user interactions)
+	- [ ] **Task completion tracking** (measure success rates)
+	- [ ] **Error logging** (track problems encountered)
+	- [ ] **Other:** ____________________________________
+
+	### How Results Will Be Collected:
+
+	**Method 1:** ___________________________________________________
+
+	**Method 2:** ___________________________________________________
+
+	**Method 3:** ___________________________________________________
+
+	### Data Validation Methods:
+	*How will you verify the accuracy of your testing results?*
+
+	**Comparison Method:** ______________________________________
+
+	**Known Benchmarks:** ______________________________________
+
+	**External Validation:** ___________________________________
+
+	---
+
+	## 5. Timeline
+
+	*Consider setup, testing and final feedback time*
+
+	| Phase | Duration | Activities |
+	|-------|----------|------------|
+	| **Setup** | _____ days | |
+	| **Active Testing** | _____ days | |
+	| **Results & Feedback** | _____ days | |
+
+	---
+
+	## 6. Resources
+
+	*What do the users need to proceed?*
+
+	### Hardware/Software Requirements:
+
+	&nbsp;
+
+	### Support Materials for Users:
+
+	&nbsp;
+
+	---
+
+	## 7. Success Criteria
+
+	*How will you measure if beta testing was successful?*
+
+	### Primary Success Measures:
+
+	&nbsp;
+
+	### User Satisfaction Targets:
+
+	&nbsp;
+
+	### Decision Framework:
+
+	**What results would indicate success?**
+
+	&nbsp;
+
+	**What results would require major changes?**
+
+	&nbsp;
+
+	---
+
+	## Quality Checklist
+
+	*Complete before submission*
+
+	**C9-1 Assessment Criteria:**
+
+	- [ ] **C9-1-1:** Components clearly identified for testing
+	- [ ] **C9-1-3:** Plan targets software appearance AND outlines potential users
+	- [ ] **C9-1-5:** Plan targets functionality AND explains why users were selected
+	- [ ] **C9-1-7:** Plan targets functional AND non-functional requirements AND documents how results will be collected
+	- [ ] **C9-1-9:** Test scenarios target user experience characteristics AND documentation is clear and concise
+
+	**Professional Standards:**
+
+	- [ ] All user selections include clear rationale (**"why selected"**)
+	- [ ] Multiple data collection methods documented (**"how collected"**)
+	- [ ] Test scenarios focus on relevant characteristics of your software solution
+	- [ ] Timeline is realistic for user coordination and testing
+	- [ ] All sections completed with clear, professional information
+
+	---
+
+	## Next Steps After Planning:
+
+	**✅ Complete this plan thoroughly** → **Recruit users** → **Conduct testing** → **Document results** → **Recommend improvements**
+
+	> **Remember:** Excellent planning makes everything else flow smoothly!
/dev/null .. sd/C09/Beta Testing Plan Three Levels.md
@@ 0,0 1,225 @@
+	<!-- Generated from applied-computing-au vic/unit3-4/sat/C09-2026 by port-reference-godot-to-wiki.py — do not hand-edit; re-run the port. -->
+
+	# 9-1 Beta Testing Plan - Three Levels
+
+	### **Learning Focus:** *Creating professional beta testing plans at your skill level*
+
+	**Your Mission:** Complete a beta testing plan for EasyRetail using **one of three approaches** based on your confidence and experience.
+
+	---
+
+	## Quick Start Guide: Choose Your Path
+
+	### 🎯 **What Am I Doing?**
+
+	Creating a beta testing plan for EasyRetail Point-of-Sale System v4.0
+
+	### 📋 **Which Level Should I Choose?**
+
+	#### 🟢 **Level 1: Simplified Plan** _(20-30 minutes)_
+
+	**Choose this if:**
+
+	- This is your first time creating a beta testing plan
+	- You want a structured template to guide you
+	- You prefer tick-boxes and fill-in-the-blanks
+
+	**You'll do:** Complete a simple table with guided prompts
+
+	---
+
+	#### 🟡 **Level 2: Analyse an Expert Plan** _(40-50 minutes)_
+
+	**Choose this if:**
+
+	- You want to understand professional standards
+	- You learn well by studying examples
+	- You're preparing for assessment but need guidance
+
+	**You'll do:** Study a professional plan, then answer analysis questions
+
+	---
+
+	#### 🔴 **Level 3: Create Professional Plan** _(50+ minutes)_
+
+	**Choose this if:**
+
+	- You're confident with beta testing concepts
+	- You're preparing for VCE assessment
+	- You want to create portfolio-quality work
+
+	**You'll do:** Write a complete professional plan from scratch
+
+	---
+
+	#### 🚀 **Ready to Start?**
+
+	Jump to your chosen level below!
+
+	---
+
+	### 🟢 Level 1: Simplified Beta Testing Plan
+
+	*(Recommended for first-time beta testing planners)*
+
+	**Your Task:** Complete this **simplified table** for EasyRetail beta testing
+
+	| **Section** | **Your Response** | |
+	| ---------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --- |
+	| **Beta testing plan for:** | EasyRetail Point-of-Sale System v4.0 | |
+	| **Main Goal:** | *What is the most important thing to test?* <br><br>`____________________________________________` | |
+	| **What will be tested:** | *Pick the 3 most important things to test:* <br>☐ Barcode scanning ☐ Sales recording ☐ Till operations <br>☐ EFTPOS transactions ☐ Integration with accounting systems <br>☐ Interface design ☐ System speed and reliability | |
+	| **Who will test:** | *Name 2-3 types of shops that should test:* <br><br>1. `_________________________________________` <br>2. `_________________________________________` <br>3. `_________________________________________` | |
+	| **How to collect feedback:** | *Choose 2 methods:* <br>☐ Phone interviews ☐ Email surveys ☐ In-person visits <br>☐ Screen recording ☐ Error logs ☐ Weekly check-ins | |
+	| **Timeline:** | *How long should testing take?* <br><br>Setup: `_____` weeks, Testing: `_____` weeks, Feedback: `_____` weeks | |
+	| **Success means:** | *How will you know testing worked?* <br><br>`____________________________________________` | |
+
+	---
+
+	### 🟡 Level 2: Exemplar Analysis
+
+	*(Recommended for students wanting to understand professional standards)*
+
+	**Your Task:** Study the **expert-level beta testing plan** below, then complete the analysis questions.
+
+	#### Expert Beta Testing Plan for EasyRetail:
+
+	| **Section** | **Expert Response** |
+	|-------------|---------------------|
+	| **Beta testing plan for:** | **EasyRetail Point-of-Sale System v4.0** - Major release supporting new lightweight operating systems |
+	| **Objective:** | **Primary:** Validate that rewritten EasyRetail v4.0 maintains functionality, reliability, and user experience standards on new operating systems<br><br>**Secondary:** Identify integration issues with existing accounting/stock management systems and gather feedback for final refinements |
+	| **Test scenarios:** | **Scenario 1 - Core Transaction Processing:** Complete sales transactions including barcode scanning, manual price entry, multiple payment methods, receipt printing, and till reconciliation<br><br>**Scenario 2 - System Integration:** Test integration with existing accounting systems (MYOB, Xero), stock management systems, and data export/import functionality<br><br>**Scenario 3 - User Interface & Workflow:** Evaluate interface responsiveness, appearance consistency, ease of navigation during busy periods, and workflow efficiency |
+	| **Methodology:** | **User Recruitment:** Invite 10 existing EasyRetail customers (small, medium, large retail businesses) plus 2 new potential customers for fresh perspective. Target diverse business types and geographic spread.<br><br>**Feedback Collection:** Weekly structured interviews, daily incident reporting via online portal, end-of-testing comprehensive survey, optional screen recording for complex workflows |
+	| **Timeline:** | **Phase 1 - Setup (Week 1):** User recruitment, installation, training<br>**Phase 2 - Active Testing (Weeks 2-5):** Daily use in live business environment with weekly check-ins<br>**Phase 3 - Final Feedback (Week 6):** Comprehensive interviews, survey completion, data compilation |
+	| **Resources:** | **Hardware:** Compatible point-of-sale terminals, barcode scanners, receipt printers, EFTPOS terminals, backup hardware<br>**Software:** EasyRetail v4.0 beta, integration with existing systems, remote support access<br>**Support:** User manual, video tutorials, 24/7 technical support, incident reporting portal, data backup procedures |
+	| **Success criteria:** | **Primary:** 95% of transactions complete successfully, performance matches previous version, integration maintains data integrity, user satisfaction 8/10+<br>**Secondary:** Training time under 2 hours, support tickets within limits, no business-critical failures, positive workflow feedback |
+
+	#### **Analysis Questions:** *(Answer all questions)*
+
+	1. **Purpose Analysis:** Why does each section exist in a professional beta testing plan?
+	- **Objective section purpose:** `________________________________`
+	- **Test scenarios purpose:** `________________________________`
+	- **Methodology section purpose:** ______________________________
+	- **Success criteria purpose:** `________________________________`
+
+	2. **Decision Analysis:** Why did the expert make these specific choices?
+	- **Why invite existing customers + new users:** ________________
+	- **Why use multiple feedback collection methods:** `______________`
+	- **Why set specific success percentages (95%, 8/10):** `_________`
+	- **Why include 24/7 support during testing:** `_________________`
+
+	3. **Quality Analysis:** What makes this plan "professional standard"?
+	- **Evidence of systematic planning:** `__________________________`
+	- **Evidence of business understanding:** _______________________
+	- **Evidence of user focus:** `___________________________________`
+	- **Evidence of measurable outcomes:** `_________________________`
+
+	4. **Application Analysis:** How could you adapt this approach for a school project?
+	- **What would you keep the same:** `____________________________`
+	- **What would you simplify:** `________________________________`
+	- **What would you change completely:** ________________________
+
+	---
+
+	### 🔴 Level 3: Independent Professional Plan
+
+	*(Recommended for advanced students or assessment preparation)*
+
+	**Your Task:** Create a **complete professional beta testing plan** for EasyRetail using the full template structure.
+
+	**Requirements:**
+	- **Address all template sections** comprehensively
+	- **Justify all decisions** with reference to the EasyRetail case study
+	- **Demonstrate professional standards** throughout your plan
+	- **Show systematic methodology** and evidence-based thinking
+
+	**Use the template structure:**
+
+	| **Section** | **Your Professional Response** | |
+	| -------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | --- |
+	| **Beta testing plan for:** | `____________________________________________` | |
+	| **Objective:** | `____________________________________________` | |
+	| **Test scenarios:** | **Scenario 1:** `____________________________`<br><br>**Scenario 2:** `____________________________`<br><br>**Scenario 3:** `____________________________` | |
+	| **Methodology:** | **User Recruitment:** `_______________________`<br><br>**Feedback Collection:** `____________________` | |
+	| **Timeline:** | **Phase 1:** `_______________________________`<br><br>**Phase 2:** `_______________________________`<br><br>**Phase 3:** `_______________________________` | |
+	| **Resources:** | **Hardware:** `______________________________`<br><br>**Software:** `_____________________________`<br><br>**Support:** `______________________________` | |
+	| **Success criteria:** | **Primary:** `_______________________________`<br><br>**Secondary:** `_____________________________` | |
+
+	**Quality Expectations:**
+	- **Business context awareness** throughout your plan
+	- **Specific, measurable success criteria** not vague goals
+	- **Multiple data collection methods** with clear rationale
+	- **Realistic timeline and resource planning**
+	- **Professional language and structure**
+
+	---
+
+	## Learning Reflection Questions
+
+	### After completing your beta testing plan:
+
+	1. **What makes beta testing different from regular software testing?**
+
+	2. **Why is user selection so important for beta testing success?**
+
+	3. **How would you adapt this plan for a smaller software project?**
+
+	4. **What challenges might Abbie face that your plan should address?**
+
+	5. **How does this beta testing plan connect to real business needs?**
+
+	---
+
+	## Differentiated Assessment Options
+
+	### 🟢 Foundation Achievement:
+	- **Complete basic framework** with teacher support
+	- **Demonstrate understanding** of beta testing concepts
+	- **Show awareness** of user needs and business context
+
+	### 🟡 Developing Achievement:
+	- **Complete comprehensive plan** with minimal support
+	- **Justify decisions** with reference to case study
+	- **Show systematic thinking** about testing methodology
+
+	### 🔴 Advanced Achievement:
+	- **Create professional-quality plan** that exceeds template requirements
+	- **Demonstrate deep understanding** of business and technical considerations
+	- **Show innovation** in testing approaches and success criteria
+
+	---
+
+	## Key Knowledge Development
+
+	### By Priority:
+
+	**Essential (All students must demonstrate):**
+	- **Prerequisites understanding** (alpha before beta)
+	- **User selection rationale** (why certain testers)
+	- **Basic planning structure** (objectives, scenarios, methodology)
+
+	**Important (Most students should achieve):**
+	- **Business context awareness** (risk, customer relationships)
+	- **Systematic methodology** (structured data collection)
+	- **Professional communication** (clear, justified decisions)
+
+	**Advanced (Extension for ready students):**
+	- **Risk management** integration
+	- **Competitive analysis** considerations
+	- **Innovation** in testing approaches
+
+	---
+
+	## Success Indicators
+
+	### Students demonstrate learning when they:
+	- **Choose invited-only testing** with business-focused rationale
+	- **Identify alpha testing prerequisites** before beta testing
+	- **Create realistic test scenarios** based on EasyRetail's functions
+	- **Justify user selection** with reference to target audience
+	- **Plan systematic data collection** with multiple methods
+	- **Connect decisions** to case study context throughout
+
+	---
+
+	*This learning-focused approach develops C9 skills systematically while maintaining high academic standards appropriate for VCE Software Development.*
\	No newline at end of file
/dev/null .. sd/C09/Beta Testing Report Examples.md
@@ 0,0 1,170 @@
+	<!-- Generated from applied-computing-au vic/unit3-4/sat/C09-2026 by port-reference-godot-to-wiki.py — do not hand-edit; re-run the port. -->
+	# 9-3 Beta Testing Report Examples
+
+	## Understanding Beta Testing Results
+
+	Source: https://www.linkedin.com/pulse/strategies-analyzing-beta-testing-results-akinyomi-oluwatosin-kzffe
+
+
+	1. Bug Reports: Reports of technical issues, glitches, or errors encountered by beta testers while using the product.
+	2. Feature Requests: Suggestions for new features, improvements to existing features, or changes to user interface/interaction.
+	3. Usability Feedback: Feedback on the overall user experience, including ease of use, navigation, and intuitiveness of the product.
+	4. Performance Metrics: Quantitative data on product performance, such as load times, response times, and system resource usage.
+	5. User Feedback: Qualitative feedback from beta testers, including comments, suggestions, and testimonials about their experience with the product.
+
+	## Beta Test Results Framework
+
+	_5 Essential Categories for Documenting Your Findings_
+
+	---
+
+	## 1. **🪲 Bug Reports**
+
+	**What to Include:**
+
+	- **Simple bug table** with: Bug ID, Description, How Many Users Affected, Priority
+	- **Pattern identification**: Which bugs happened most often?
+
+	**Example Table:**
+
+	|Bug ID|Description|Users Affected|Priority|
+	|---|---|---|---|
+	|B001|Login button doesn't work on mobile|7 out of 10 testers (70%)|High|
+	|B002|App crashes when uploading images|3 out of 10 testers (30%)|Medium|
+	|B003|Spelling error on welcome screen|1 out of 10 testers (10%)|Low|
+
+	**Student Tip**: Focus on bugs that affect multiple users - these show real problems, not one-off issues.
+
+	---
+
+	## 2. **💡 Feature Requests**
+
+	**What to Include:**
+
+	- **Top 3-5 requested features** with how many testers mentioned each
+	- **Simple priority ranking** based on user demand
+
+	**Example Format:**
+
+	```
+	Most Requested Features:
+	1. "Add save progress button" - mentioned by 8/10 testers
+	2. "Include help tutorial" - mentioned by 6/10 testers
+	3. "Add dark mode option" - mentioned by 4/10 testers
+	4. "Enable sharing with friends" - mentioned by 2/10 testers
+	```
+
+	**Student Tip**: Count how many testers asked for each feature - this shows which ones users actually want.
+
+	---
+
+	## 3. **🔍 Usability Feedback**
+
+	**What to Include:**
+
+	- **Common themes** from user comments
+	- **Task success rates**: How many users completed key tasks?
+	- **Real user quotes** showing specific problems
+
+	**Example Analysis:**
+
+	```
+	Navigation Issues (Most Common Theme):
+	• 8 out of 10 testers had trouble finding the settings menu
+	• Average time to find settings: 2.5 minutes (target: 30 seconds)
+	• User quote: "I clicked around for ages before finding the settings"
+
+	Task Completion Results:
+	• Login successfully: 10/10 testers (100%)
+	• Complete main workflow: 6/10 testers (60%)
+	• Find help section: 3/10 testers (30%)
+	```
+
+	**Student Tip**: Look for patterns - if multiple users have the same problem, it's a design issue, not user error.
+
+	---
+
+	## 4. **⚡ Performance Issues**
+
+	**What to Include:**
+
+	- **Loading times**: How fast does your software run?
+	- **Crash frequency**: How often did it break?
+	- **Simple performance data** that students can actually measure
+
+	**Example Measurements:**
+
+	```
+	Performance Results:
+	• App startup time: Average 4.5 seconds (target: under 3 seconds)
+	• Page loading: Most pages loaded in 1-2 seconds ✓
+	• Crashes reported: 2 crashes out of 50 test sessions (4% crash rate)
+	• System freezes: 1 user experienced freezing during file upload
+	```
+
+	**Student Tip**: Focus on simple metrics you can actually measure - startup time, loading speed, crashes.
+
+	---
+
+	## 5. **💬 User Satisfaction**
+
+	**What to Include:**
+
+	- **Overall satisfaction rating** from your survey
+	- **Mix of positive and negative quotes**
+	- **Key insights** about user experience
+
+	**Example Summary:**
+
+	```
+	User Satisfaction Results:
+	• Overall rating: 7.2/10 (target: 8+)
+	• Would recommend to others: 6 out of 10 testers said yes
+	• Easiest feature: "Login was simple and fast"
+	• Biggest frustration: "Couldn't figure out how to save my work"
+	• Most positive comment: "Really useful once I learned how to use it"
+	• Key improvement needed: "Make it more obvious how to navigate"
+	```
+
+	**Student Tip**: Include both positive and negative feedback to show balanced analysis.
+
+	---
+
+	## **Priority Ranking for Modifications**
+
+	**High Priority**: Bugs affecting 50%+ of testers, core functions that don't work
+	**Medium Priority**: Popular feature requests, usability issues
+	**Low Priority**: Minor bugs, visual improvements
+
+	---
+
+	## **Student Template for Each Category**
+
+	```
+	Category: [Bug Reports / Feature Requests / Usability / Performance / Satisfaction]
+
+	Key Findings:
+	• [Most important result with numbers]
+	• [Second most important result with numbers]
+	• [Third most important result with numbers]
+
+	Evidence:
+	• "User quote showing the problem"
+	• Data: X out of Y testers experienced this
+	• Impact: How this affects user experience
+
+	Recommendations:
+	• What needs to be changed to fix this
+	```
+
+	---
+
+	## **Remember for Your SAT:**
+
+	✅ **Use real data** from your actual beta testing
+	✅ **Show patterns** - problems mentioned by multiple users are more important
+	✅ **Include user quotes** - actual tester feedback strengthens your evidence
+	✅ **Balance positive and negative** - show what worked AND what didn't
+	✅ **Connect to modifications** - this data should lead to your C9-4 recommendations
+
+	_This framework helps you organise your beta test results into clear categories that directly support your software modification recommendations._
\	No newline at end of file
/dev/null .. sd/C09/Beta Testing Report Guide.md
@@ 0,0 1,203 @@
+	<!-- Generated from applied-computing-au vic/unit3-4/sat/C09-2026 by port-reference-godot-to-wiki.py — do not hand-edit; re-run the port. -->
+	# 9-3 Basic Beta Testing Report Guide
+
+	**C9-3 Assessment Preparation** - Skills in conducting beta testing: Documents the results of the beta tests
+
+	---
+
+	## 📋 How to Use This Guide
+
+	**Follow each section below. Use your testing data to fill in the blanks. If you don't have something, leave it out or write 'not found.'**
+
+	---
+
+	## The 5-Category Results Framework
+
+	### Use Only the Categories Relevant to Your Testing
+
+	**Choose the categories that match what you actually tested:**
+
+	1. **🪲 Bug Reports** - Technical issues and errors
+	2. **💡 Feature Requests** - User suggestions for improvements
+	3. **🔍 Usability Feedback** - User experience insights
+	4. **⚡ Performance Issues** - Speed, efficiency, and reliability
+	5. **💬 User Satisfaction** - Overall experience and ratings
+
+	**You don't need all 5 categories - only include sections where you have actual data from your testing.**
+
+	---
+
+	## Basic Report Template
+
+	### **Beta Test Results for: [Your Software Name]**
+
+	**Testing Details:**
+
+	- **Testing Period:** [Start Date] to [End Date]
+	- **Number of Testers:** [X] users
+	- **Testing Methods:** [Survey, Observation, Interview]
+	- **Main Testing Goal:** [What you wanted to find out]
+
+	---
+
+	### **🪲 Bug Reports**
+
+	**Total Bugs Found:** [Number]
+
+	**Most Important Problems:**
+
+	**Problem 1:** [What went wrong?]
+
+	- How many testers had this problem: ___ out of ___ testers
+	- What they said: "[Quote from user]"
+	- Why it matters: [How this affected their experience]
+
+	**Problem 2:** [What went wrong?]
+
+	- How many testers had this problem: ___ out of ___ testers
+	- What they said: "[Quote from user]"
+	- Why it matters: [How this affected their experience]
+
+	**Other Problems:**
+
+	- [List any other bugs you found]
+
+	---
+
+	### **💡 Feature Requests**
+
+	**What Users Want Added:**
+
+	**Request 1:** [What they want]
+
+	- How many asked for this: ___ testers
+	- Why they want it: "[What users said]"
+
+	**Request 2:** [What they want]
+
+	- How many asked for this: ___ testers
+	- Why they want it: "[What users said]"
+
+	**Request 3:** [What they want]
+
+	- How many asked for this: ___ testers
+	- Why they want it: "[What users said]"
+
+	---
+
+	### **🔍 Usability Results**
+
+	**How Well Users Could Use Your Software:**
+
+	**Task Success:**
+
+	- Could complete main task: ___ out of ___ testers
+	- Could find important features: ___ out of ___ testers
+	- Overall ease of use rating: ___/10 average
+
+	**What Users Struggled With:**
+
+	- **Struggle 1:** [What was hard] - mentioned by ___ testers
+	- **Struggle 2:** [What was hard] - mentioned by ___ testers
+
+	**What Users Found Easy:**
+
+	- **Easy thing 1:** [What worked well] - praised by ___ testers
+	- **Easy thing 2:** [What worked well] - praised by ___ testers
+
+	---
+
+	### **⚡ Performance Results**
+
+	**Speed and Reliability:**
+
+	- How long to load: ___ seconds
+	- App crashed: ___ times during testing
+	- App froze: ___ times during testing
+
+	**What Users Said About Speed:**
+
+	- "[Quote about how fast/slow it felt]"
+	- Rating for speed: ___/10 average
+
+	---
+
+	### **💬 User Satisfaction Summary**
+
+	**Overall Ratings:**
+
+	- Average satisfaction score: ___/10
+	- Would recommend to others:
+	- 🟩 Yes – ___ testers
+	- 🟥 No – ___ testers
+	- Would keep using it:
+	- 🟩 Yes – ___ testers
+	- 🟥 No – ___ testers
+
+	**What Users Said:**
+
+	**Best Things About Your Software:**
+
+	- "[Positive quote 1]"
+	- "[Positive quote 2]"
+
+	**Main Ideas to Make It Better:**
+
+	- "[Improvement suggestion 1]"
+	- "[Improvement suggestion 2]"
+
+	---
+
+	### **Summary of Key Findings**
+
+	**Main Strengths:**
+
+	1. [Top thing that worked well + how many users agreed]
+	2. [Second thing that worked well + how many users agreed]
+
+	**Main Issues to Fix:**
+
+	1. [Most important problem + how it affected users]
+	2. [Second important problem + how it affected users]
+
+	**Overall Assessment:** [Write 1-2 sentences: Is your software ready to use, or what needs to be fixed first?]
+
+	---
+
+	## 🧾 Evidence Reminder
+
+	**Always include:**
+
+	- How many testers?
+	- What did they say?
+	- What does it mean?
+
+	---
+
+	## Success Checklist
+
+	### **Before You Submit:**
+
+	✅ I included the categories that match my testing
+	✅ I wrote numbers for how many testers said things
+	✅ I used real quotes from my testers
+	✅ I said what needs fixing or improving
+	✅ I checked my spelling and grammar
+
+	---
+
+	## Good vs. Poor Examples
+
+	### ✅ **Good Example:**
+
+	> **Bug:** Login button doesn't work on phones - Affected 6 out of 8 testers
+	> _What they said:_ "I tapped the login button but nothing happened"
+	> _Why it matters:_ Users couldn't get into the app to use it
+
+	### ❌ **Poor Example:**
+
+	> **Bug:** Login was broken
+	> _What they said:_ "It didn't work"
+	> _Why it matters:_ Users were frustrated
+
+	---
/dev/null .. sd/C09/C09-home.md
@@ 0,0 1,46 @@
+	<!-- Generated from applied-computing-au vic/unit3-4/sat/C09-2026 by port-reference-godot-to-wiki.py — do not hand-edit; re-run the port. -->
+	# C09 — Skills in Conducting Beta Testing
+
+	The Hamilton and Alexandra College · Year 12 · 2026
+
+	Beta testing puts your software in front of **real potential users** and turns what they do into evidence-backed recommendations. C9 runs as a cycle: **plan** it, rehearse it in the simulation, **conduct** it and keep the raw evidence, present that evidence, **analyse** it into findings, and **recommend** modifications you defend live.
+
+	## How C9 runs
+
+	| Indicator | Checkpoint | Validation |
+	|-----------|-----------|------------|
+	| **C9-1** Beta Testing Plan | Draft plan (feedback loop) | Beta Testing Simulation 🔒📱⏰ |
+	| **C9-2** Conducting Beta Testing | — | Raw data pack + Raw Data Presentation 🔒📱⏰ |
+	| **C9-3** Beta Testing Results | Draft Results & Analysis — §2 (feedback loop) | via C9-4's viva |
+	| **C9-4** Recommended Modifications | Portfolio — §3 + mockups + traceability map (feedback loop) | Beta Recommendations Viva voce 🔒📱⏰ |
+
+	Recordings (audio + video) and signed consent forms live on your **school OneDrive**; your GitHub repo keeps instruments, exports, the deviation note and the pack index. The full specifications are the two assessment packages in your `S-C09` folder.
+
+	## Foundations
+
+	- [Essential Terms](/sd/C09/Essential%20Terms)
+	- [The Four-Step Beta Testing Journey](/sd/C09/The%20Four-Step%20Beta%20Testing%20Journey)
+	- [Priority Matrix](/sd/C09/Priority%20Matrix)
+	- [Timeline and Resource Considerations](/sd/C09/Timeline%20and%20Resource%20Considerations)
+	- [Beta Testing Case Study: Pocket Prep](/sd/C09/Beta%20Testing%20Case%20Study%20Pocket%20Prep)
+
+	## Stage 1 — Plan (C9-1)
+
+	- [Beta Testing Plan — Three Levels](/sd/C09/Beta%20Testing%20Plan%20Three%20Levels)
+	- [Beta Testing Plan Template](/sd/C09/Beta%20Testing%20Plan%20Template)
+	- [Beta Testing Plan Example — Godot Tetris](/sd/C09/Beta%20Testing%20Plan%20Example%20Godot%20Tetris)
+	- [Test Scenario Template](/sd/C09/Test%20Scenario%20Template)
+	- [Test Scenario — FitTrack](/sd/C09/Test%20Scenario%20FitTrack)
+
+	## Stage 2 — Conduct (C9-2)
+
+	- [Data Collection Methods](/sd/C09/Data%20Collection%20Methods)
+	- [Data Collection Examples](/sd/C09/Data%20Collection%20Examples)
+	- [Data Collection Template](/sd/C09/Data%20Collection%20Template)
+	- [Beta Test Execution](/sd/C09/Beta%20Test%20Execution)
+
+	## Stages 3 & 4 — Analyse and Recommend (C9-3, C9-4)
+
+	- [Beta Testing Report Guide](/sd/C09/Beta%20Testing%20Report%20Guide)
+	- [Beta Testing Report Examples](/sd/C09/Beta%20Testing%20Report%20Examples)
+	- [Software Modifications Mindmap](/sd/C09/Software%20Modifications%20Mindmap)
/dev/null .. sd/C09/Data Collection Examples.md
@@ 0,0 1,29 @@
+	<!-- Generated from applied-computing-au vic/unit3-4/sat/C09-2026 by port-reference-godot-to-wiki.py — do not hand-edit; re-run the port. -->
+	# 9-2 Data Collection - Examples
+
+	### CodeCenter
+
+	[CenterCode Beta Testing Feedback Forms](https://docs.google.com/document/d/18QtAqc5EPMLt_lyWhwCNUrUJLYTiYFCXiqxHYrCOlKs/edit?usp=sharing)
+
+	- **Surveys** (rating scales for usability, satisfaction)
+	- **Observation** (watching users complete tasks, recording their interactions)
+	- **Interviews** (follow-up conversations about their testing experience)
+
+
+	### Formuiz
+
+	[Formuiz Beta testing feedback form](https://docs.google.com/forms/d/1FIYY_5KcbK6qeeAO_fb5Xrse02riL7_-JNK2vXJMBas/edit)
+
+
+	This is a **Survey/Questionnaire** that combines:
+
+	- **Quantitative data** (5-point rating scales)
+	- **Qualitative data** (open-ended text responses)
+	- **Categorical data** (multiple choice selections)
+
+
+	## Zonka
+
+	https://www.zonkafeedback.com/templates/beta-testing-survey-template?utm_source=chatgpt.com
+
+	Use this Beta Testing Survey Template to get feedback from beta users on your new features or product before a major release. Improve customer experience by measuring feedback on interface, features, usability, possible bugs, and more.
\	No newline at end of file
/dev/null .. sd/C09/Data Collection Methods.md
@@ 0,0 1,151 @@
+	<!-- Generated from applied-computing-au vic/unit3-4/sat/C09-2026 by port-reference-godot-to-wiki.py — do not hand-edit; re-run the port. -->
+	# 9-2 Beta Testing Data Collection Methods
+
+	## Understanding Data Types for Beta Testing
+
+	Before selecting collection methods, understand what type of data you need:
+
+	**Quantitative Data (Measurable)**
+
+	- Likert scale ratings (1-5 satisfaction scores)
+	- Yes/No responses
+	- Task completion times
+	- Error counts
+	- Success/failure rates
+
+	**Qualitative Data (Descriptive)**
+
+	- User opinions and experiences
+	- Explanations of problems encountered
+	- Suggestions for improvements
+	- Behavioral observations
+
+	## Four Main Data Collection Methods
+
+	### 1. **Surveys/Questionnaires**
+
+	**Purpose**: Collect standardised, quantifiable feedback from multiple testers simultaneously
+
+	**When to Use**: When you need measurable data to compare across users and identify trends
+
+	**Types of Questions**:
+
+	**Closed Questions (Quantitative)**
+
+	- _Rating Scale_: "Rate the user interface design: Very Poor (1) to Excellent (5)"
+	- _Multiple Choice_: "Which feature was most difficult to use? A) Login process B) Main navigation C) Search function D) Settings menu"
+	- _Yes/No_: "Were you able to complete the task without assistance?"
+
+	**Open Questions (Qualitative)**
+
+	- _Experience-based_: "Describe any moment when the interface caused you to pause or feel uncertain"
+	- _Problem-focused_: "What was the most challenging aspect of using this software?"
+	- _Improvement-focused_: "What changes would make this software easier to use?"
+
+	**Advantages**: Efficient for large groups, standardized responses, easy to analyze statistically
+	**Best For**: Measuring satisfaction, ease of use, feature preferences
+
+	---
+
+	### 2. **Observation**
+
+	**Purpose**: Record actual user behavior without relying on self-reported data
+
+	**When to Use**: When you need objective evidence of how users actually interact with your software
+
+	**Observation Techniques**:
+
+	- **Screen recording** during testing sessions
+	- **Task completion monitoring** (time-on-task measurements)
+	- **Error frequency tracking** and navigation patterns
+	- **Behavioral notes** (hesitation, confusion, workarounds)
+
+	**Example Observation Tasks**:
+
+	- Record how long it takes users to complete core workflows
+	- Observe navigation patterns and identify common user pathways
+	- Note frequency and types of errors made during typical tasks
+	- Document where users pause or show confusion
+
+	**Advantages**: Objective data, reveals actual vs. reported behavior, identifies usability issues
+	**Best For**: Workflow efficiency, interface design problems, actual vs. perceived performance
+
+	---
+
+	### 3. **Interviews**
+
+	**Purpose**: Explore the "why" behind user behaviors and gather detailed feedback
+
+	**When to Use**: When you need to understand user motivations, clarify survey responses, or explore unexpected findings
+
+	**Interview Structure**:
+
+	**Structured Questions**
+
+	- "Walk me through how you typically use this software"
+	- "What was your initial reaction to the main interface?"
+	- "Describe your experience with the most important features"
+
+	**Follow-up Probes**
+
+	- "Can you tell me more about that challenge?"
+	- "How did that make you feel as a user?"
+	- "What would have made that process easier?"
+	- "Why do you think that happened?"
+
+	**Advantages**: Rich detailed feedback, clarifies confusing survey responses, uncovers unexpected issues
+	**Best For**: Understanding user emotions, complex workflows, training and support needs
+
+	---
+
+	### 4. **Reports/Documentation**
+
+	**Purpose**: Systematically compile and analyse all collected data into actionable insights
+
+	**When to Use**: To synthesise findings from multiple methods and present recommendations
+
+	**Key Components**: Combine quantitative data (scores, statistics) with qualitative insights (themes, quotes) to create comprehensive findings and prioritized recommendations.
+
+	**Advantages**: Provides comprehensive overview, supports decision-making, documents test outcomes
+	**Best For**: Final assessment, stakeholder communication, future development planning
+
+	## Data Analysis Strategy
+
+	**For Closed Survey Questions**:
+
+	- Calculate average scores and percentages
+	- Create charts showing satisfaction trends
+	- Identify lowest-scoring areas for improvement focus
+
+	**For Open Survey Responses and Interview Data**:
+
+	- Use thematic analysis to identify common issues
+	- Code responses into categories (usability, functionality, performance)
+	- Extract representative quotes for reporting
+
+	**For Observation Data**:
+
+	- Compile task completion statistics
+	- Map common error patterns
+	- Document workflow efficiency metrics
+
+	## Mixing Methods for Comprehensive Results
+
+	**Best Practice**: Use multiple methods to triangulate findings
+
+	**Recommended Combination Approach**:
+
+	1. **Survey** to measure overall satisfaction and identify problem areas
+	2. **Observation** to objectively measure task performance in those problem areas
+	3. **Interview** to understand why those problems occur and how users work around them
+	4. **Report** to synthesize quantitative metrics with qualitative insights
+
+	This approach ensures you capture both the "what" (quantitative metrics) and the "why" (qualitative insights) of user experience.
+
+
+	---
+
+	_Remember: Your beta testing plan should specify which methods you'll use for each test scenario, ensuring alignment between your testing objectives and your data collection approach._
+
+
+	
\	No newline at end of file
/dev/null .. sd/C09/Data Collection Methods/planning-box.svg
@@ 0,0 1,4 @@
+	<svg width="1024" height="800" xmlns="http://www.w3.org/2000/svg">
+	<rect x="2" y="2" width="98%" height="760" rx="5" ry="5" fill="none" stroke="black" stroke-width="2" />
+	<text x="10" y="25" font-family="sans-serif" font-size="16" fill="black">Planning Area:</text>
+	</svg>
/dev/null .. sd/C09/Data Collection Template.md
@@ 0,0 1,178 @@
+	<!-- Generated from applied-computing-au vic/unit3-4/sat/C09-2026 by port-reference-godot-to-wiki.py — do not hand-edit; re-run the port. -->
+	# 9-2 Data Collection - Template
+
+	_PDF format available_
+
+	# Beta Testing Feedback Forms
+
+	## 1. Bugs / Issues / Problems
+
+	### Summary
+
+	_A short summary of the issue being submitted_
+
+	---
+
+	### Which feature are you experiencing an issue with?
+
+	**Select from dropdown:**
+
+	- [ ] Feature 1
+	- [ ] Feature 2
+	- [ ] Feature 3
+	- [ ] Other: ___________
+
+	---
+
+	### Steps to Reproduce
+
+	**Tell us what happened:**
+
+	---
+
+	### Issue Related Files
+
+	_Please include any associated files (screenshots, videos, etc.) to help illustrate your issue._
+
+	**Attachments:** [Upload files here]
+
+	---
+
+	### Severity
+
+	**Select severity level:**
+
+	- [ ] Critical - Application crashes/unusable
+	- [ ] High - Major feature broken
+	- [ ] Medium - Minor feature issue
+	- [ ] Low - Cosmetic/minor annoyance
+
+	---
+
+	### Status _(For internal use - not filled by testers)_
+
+	- [ ] New
+	- [ ] In Progress
+	- [ ] Resolved
+	- [ ] Closed
+
+	---
+
+	### Is this issue stopping you from testing this feature?
+
+	- [ ] Yes
+	- [ ] No
+
+	---
+
+	## 2. Ideas / Feature Requests
+
+	### Summary
+
+	_A short summary of the idea being submitted_
+
+	---
+
+	### Which feature is this idea related to?
+
+	**Select from dropdown:**
+
+	- [ ] Feature 1
+	- [ ] Feature 2
+	- [ ] Feature 3
+	- [ ] General Application
+	- [ ] Other: ___________
+
+	---
+
+	### Description
+
+	_Where applicable, include examples of products that have implemented your idea or provide examples of use cases_
+
+	---
+
+	### Priority
+
+	**Select priority level:**
+
+	- [ ] Nice to Have
+	- [ ] Should Have
+	- [ ] Must Have
+
+	---
+
+	### Related Files
+
+	_Please include any associated files (screenshots, videos, etc.) to help illustrate your idea._
+
+	**Attachments:** [Upload files here]
+
+	---
+
+	### Status _(For internal use - not filled by testers)_
+
+	- [ ] New
+	- [ ] Under Review
+	- [ ] Approved
+	- [ ] Rejected
+	- [ ] Implemented
+
+	---
+
+	## 3. Praise
+
+	### Summary
+
+	_A short summary of the praise being submitted_
+
+	---
+
+	### Which feature is this idea related to?
+
+	**Select from dropdown:**
+
+	- [ ] Feature 1
+	- [ ] Feature 2
+	- [ ] Feature 3
+	- [ ] Overall Application
+	- [ ] Other: ___________
+
+	---
+
+	### Tell us about the specific experience you feel is praise-worthy
+
+	---
+
+	### Praise Significance
+
+	**Select significance level:**
+
+	- [ ] Pleasantly Surprised
+	- [ ] Exceeded Expectations
+	- [ ] Greatly Exceeded Expectations
+
+	---
+
+	### Status _(For internal use - not filled by testers)_
+
+	- [ ] New
+	- [ ] Acknowledged
+	- [ ] Shared with Team
+
+	---
+
+	## Beta Tester Information
+
+	**Name:** ___________
+
+	**Date:** ___________
+
+	**Testing Session:** ___________
+
+	**Device/Platform Used:** ___________
+
+	**Additional Comments:**
+
+	---
+
+	_Thank you for participating in our beta testing program. Your feedback is invaluable in helping us improve the software solution._
\	No newline at end of file
/dev/null .. sd/C09/Essential Terms.md
@@ 0,0 1,57 @@
+	<!-- Generated from applied-computing-au vic/unit3-4/sat/C09-2026 by port-reference-godot-to-wiki.py — do not hand-edit; re-run the port. -->
+	## Topics:
+	- Beta Testing
+	- Test Scenarios
+	- Data Collection from Beta Testers
+	- Reporting Results
+	- Modifications Based on Feedback
+	- Personas
+
+
+	> [!note]- Beta testing
+	> The phase of software testing where a sample of the intended audience tests the software in a real environment.
+
+	> [!note]- Test scenario
+	> A specific situation or workflow that a beta tester is asked to perform in order to evaluate the functionality, usability or reliability of the software.
+
+	> [!note]- Test plan
+	> A document that outlines the objectives, scope, schedule and approach for beta testing, including which features to test and what data to collect.
+
+	> [!note]- Personas
+	> Fictional characters created based on user research to represent the different user types that might use a service, application, product, site or brand.
+
+	> [!note]- Data collection
+	> The systematic gathering of feedback, observations and measurements from beta testers during and after testing sessions.
+
+	> [!note]- Observation (beta testing)
+	> Watching beta testers interact with the software to identify usability issues, confusion points or unexpected behaviours.
+
+	> [!note]- Survey
+	> A structured set of questions given to beta testers to collect quantitative and qualitative feedback about their experience with the software.
+
+	> [!note]- Bug report
+	> A documented record of an error or defect found during beta testing, typically including steps to reproduce, expected behaviour and actual behaviour.
+
+	> [!note]- Reporting results
+	> The process of compiling and presenting beta testing findings, including issues discovered, tester feedback and recommendations for improvement.
+
+	> [!note]- Modifications
+	> Changes made to the software based on feedback and issues identified during beta testing, aimed at improving functionality, usability or performance.
+
+	> [!note]- Functionality
+	> The range of operations that can be performed by a software system as defined by its requirements.
+
+	> [!note]- Usability
+	> The ease with which a user can interact with a software system to achieve their goals efficiently and satisfactorily.
+
+	> [!note]- Evaluation criteria
+	> Performance criteria made from the expectations and specification, used to judge whether the software meets its intended purpose.
+
+	> [!note]- Testing table
+	> A commonly used way to record evidence of functionality testing, documenting test cases, expected results and actual results.
+
+	> [!note]- Feedback
+	> Information provided by beta testers about their experience, including issues encountered, suggestions for improvement and overall satisfaction.
+
+	> [!note]- Priority (bug classification)
+	> A ranking assigned to an issue found during beta testing that indicates how urgently it needs to be addressed before release.
/dev/null .. sd/C09/Priority Matrix.md
@@ 0,0 1,137 @@
+	<!-- Generated from applied-computing-au vic/unit3-4/sat/C09-2026 by port-reference-godot-to-wiki.py — do not hand-edit; re-run the port. -->
+	# 9-0 Priority Matrix (C-9: Beta Testing)
+
+	## **📊 Performance Level Matrix**
+
+	|**Topic**|**🟡 Developing (3-4)**|**🟠 Proficient (5-6)**|**🔵 Advanced (7-8)**|**🟢 Excellence (9-10)**|
+	|---|---|---|---|---|
+	|**C-9-1**<br>_Beta Testing Plan_|• Components listed<br>• Basic plan targeting appearance|• Plan targets functionality<br>• User selection explained|• Targets functional/non-functional requirements<br>• Data collection documented|• Test scenarios target user experience<br>• Clear and concise planning|
+	|**C-9-2**<br>_Testing Execution_|• One user tested<br>• Single data collection method|• Two data collection methods<br>• Results listed systematically|• Multiple users engaged<br>• Three+ data collection methods|• Data prepared for analysis<br>• Professional user coordination|
+	|**C-9-3**<br>_Results Documentation_|• Basic results listed<br>• Simple outline of findings|• Results described in brief<br>• Organized presentation|• Comprehensive report format<br>• Detailed documentation|• Complete result set explained<br>• Clear and concise reporting|
+	|**C-9-4**<br>_Recommendations_|• Minor modifications identified<br>• Basic change suggestions|• Modifications outlined clearly<br>• Documented improvements|• Purpose of modifications explained<br>• Rationale provided|• Modifications evaluated against results<br>• Evidence-based analysis|
+
+	## **📈 Beta Testing Progression Pathway**
+
+	**Single User** → **Multiple Data Methods** → **Multiple Users** → **Professional Coordination** → **Evidence-Based Evaluation**
+
+	## **📅 Sequential Focus Strategy**
+
+	|**Phase 1**|**Focus: C-9-1 Planning + Early User Recruitment**|
+	|---|---|
+	|**Priority 1**|**URGENT:** Identify and contact potential users immediately (aim for Level 7-8)|
+	|**Priority 2**|Identify components and create beta testing plan (aim for Level 5-6)|
+	|**Priority 3**|Design test scenarios targeting functionality and user experience (aim for Level 7-8)|
+	|**Priority 4**|Document rationale and data collection methods (aim for Level 9-10)|
+	|**Milestone**|User recruitment complete and participants confirmed|
+
+	|**Phase 2**|**Focus: C-9-2 Intensive Testing Execution**|
+	|---|---|
+	|**Priority 1**|Prepare testing environment and coordinate user scheduling|
+	|**Priority 2**|Conduct pilot test with one user to validate process|
+	|**Priority 3**|**Intensive Period:** Execute multiple beta testing sessions|
+	|**Priority 4**|Use 3+ data collection methods systematically across all users|
+	|**Milestone**|All testing sessions complete, data compiled and organized|
+
+	|**Phase 3**|**Focus: C-9-3 Documentation + C-9-4 Recommendations**|
+	|---|---|
+	|**Priority 1**|Analyze testing results systematically across all data sources|
+	|**Priority 2**|Create comprehensive, clear and concise results documentation|
+	|**Priority 3**|Identify and explain purpose of evidence-based modifications|
+	|**Priority 4**|Evaluate modifications against beta testing results|
+	|**Milestone**|Complete portfolio ready for assessment submission|
+
+	<div style="page-break-after: always;"></div>
+
+	## **✅ Evidence Checklist by Topic**
+
+	### **C-9-1 (Beta Testing Plan)**
+
+	- [ ] Software components identified for testing scope
+	- [ ] Test scenarios target appearance, functionality, and user experience
+	- [ ] Potential users identified with clear selection rationale
+	- [ ] Data collection methods documented (aim for 3+ methods)
+	- [ ] Plan addresses functional and non-functional requirements
+	- [ ] Clear and concise presentation of testing strategy
+
+	### **C-9-2 (Testing Execution)**
+
+	- [ ] Multiple potential users engaged (minimum 2, ideally 3-5)
+	- [ ] Three or more data collection methods implemented
+	- [ ] Systematic data collection process followed
+	- [ ] Professional user coordination and scheduling
+	- [ ] All testing sessions completed successfully
+	- [ ] Data prepared and organized for analysis
+
+	### **C-9-3 (Results Documentation)**
+
+	- [ ] Complete set of beta testing results compiled
+	- [ ] Results organized in professional report format
+	- [ ] Clear and concise documentation standards met
+	- [ ] Evidence from all data collection methods included
+	- [ ] Systematic presentation of findings across all users
+	- [ ] Visual and written evidence properly integrated
+
+	### **C-9-4 (Recommendations)**
+
+	- [ ] Modifications clearly linked to specific beta testing evidence
+	- [ ] Purpose and rationale explained for each recommendation
+	- [ ] Modifications evaluated against testing results
+	- [ ] Evidence-based analysis of proposed changes
+	- [ ] Priority ranking of recommendations provided
+	- [ ] Implementation feasibility considered
+
+	## **🎯 User Engagement Strategy**
+
+	### **User Selection Criteria:**
+
+	- [ ] Representative of target audience
+	- [ ] Diverse perspectives and experience levels
+	- [ ] Available for testing timeframe
+	- [ ] Willing to provide detailed feedback
+
+	### **Data Collection Methods (Choose 3+):**
+
+	- [ ] Structured interviews
+	- [ ] Observation during testing
+	- [ ] Questionnaires/surveys
+	- [ ] Screen recording
+	- [ ] Task completion tracking
+	- [ ] User journey documentation
+	- [ ] Error/issue logging
+	- [ ] Performance metrics
+
+	## **📋 Flexible Checkpoint Questions**
+
+	### **End of Phase 1:**
+
+	- **✅ CRITICAL:** Have I successfully recruited and confirmed multiple beta testers?
+	- Is my beta testing plan comprehensive enough to target user experience characteristics?
+	- Do I have 3+ data collection methods ready to implement?
+	- Are my test scenarios designed to address both functional and non-functional requirements?
+
+	### **End of Phase 2:**
+
+	- Have I completed testing sessions with multiple users using diverse methods?
+	- Is all my testing data compiled and organized for comprehensive analysis?
+	- Am I ready to begin systematic results documentation?
+	- Did I maintain professional standards throughout user coordination?
+
+	### **End of Phase 3:**
+
+	- Can I show evidence-based recommendations linked to specific testing results?
+	- Have I evaluated the effectiveness of proposed modifications?
+	- Is my complete portfolio clear, concise, and ready for assessment submission?
+	- Do my recommendations demonstrate critical analysis of beta testing outcomes?
+
+
+	## **🔄 Risk Mitigation Strategies**
+
+	**User Unavailability:** Have backup testers identified and contacted
+
+	**Technical Issues:** Test recording equipment and software before sessions
+
+	**Data Loss:** Back up all testing data immediately after collection
+
+	**Time Constraints:** Prioritise core functionality testing over nice-to-have features
+
+	**Poor Feedback Quality:** Prepare structured questions and prompts for users
\	No newline at end of file
/dev/null .. sd/C09/Software Modifications Mindmap.md
@@ 0,0 1,63 @@
+	<!-- Generated from applied-computing-au vic/unit3-4/sat/C09-2026 by port-reference-godot-to-wiki.py — do not hand-edit; re-run the port. -->
+	## 9-4 Software Modifications Mindmap
+
+	This mindmap shows you how to document software changes based on your beta testing results. Each branch represents a different assessment level.
+
+	How to use this mindmap:
+
+	1. Start with your beta test results (user feedback, bug reports, observations)
+	2. Follow the progression: IDENTIFY → OUTLINE → RECOMMEND → EXPLAIN → EVALUATE
+	3. Use the 5 categories (🪲 Bugs, 💡 Features, 🔍 Usability, ⚡ Performance, 💬 Satisfaction) to organise your findings
+	4. Each level builds on the previous - aim for the highest level you can achieve
+
+	Remember: Every modification you suggest must be backed by evidence from your beta testing!
+
+	```plantuml
+	@startmindmap
+	* C9-4 Software Modifications
+
+	** C9-4-1 IDENTIFY
+	*** Bug Reports
+	**** List issues found
+	**** Count affected users
+	*** Feature Requests
+	**** Top 3-5 requests
+	**** User demand level
+
+	** C9-4-3 OUTLINE
+	*** Organize by Category
+	**** 🪲 Bugs
+	**** 💡 Features
+	**** 🔍 Usability
+	**** ⚡ Performance
+	**** 💬 Satisfaction
+	*** Set Priorities
+	**** High/Medium/Low
+
+	** C9-4-5 RECOMMEND
+	*** Link to Evidence
+	**** "X out of Y testers..."
+	**** User quotes
+	*** Formal Suggestions
+	**** Specific changes
+	**** Expected outcomes
+
+	** C9-4-7 EXPLAIN
+	*** WHY Needed
+	**** Solve user problems
+	**** Improve experience
+	*** Purpose & Impact
+	**** Expected benefits
+	**** Success measures
+
+	** C9-4-9 EVALUATE
+	*** Critical Analysis
+	**** Will it actually work?
+	**** Any implementation risks?
+	*** Success Criteria
+	**** How to measure improvement
+	**** Follow-up testing needed
+
+	@endmindmap
+	```
+
/dev/null .. sd/C09/Test Scenario FitTrack.md
@@ 0,0 1,432 @@
+	<!-- Generated from applied-computing-au vic/unit3-4/sat/C09-2026 by port-reference-godot-to-wiki.py — do not hand-edit; re-run the port. -->
+	# Case Study: FitTrack
+
+	## Fitness App Beta Testing Scenario
+
+	**C9 Skills Development - Complete Beta Testing Example**
+
+	---
+
+	## Background Context
+
+	### The FitTrack Pro App
+
+	**Company:** HealthTech Solutions
+	**Product:** FitTrack Pro - Mobile fitness tracking application
+	**Version:** 3.0 Beta (major update with new GPS algorithms)
+	**Platform:** iOS and Android smartphones + Apple Watch/Wear OS integration
+
+	### Recent Development
+
+	FitTrack Pro has undergone significant updates to improve GPS accuracy and battery efficiency. The development team has completed alpha testing and is ready for beta testing with real users in authentic exercise environments.
+
+	### Target Users
+
+	- **Primary:** Recreational joggers and runners (ages 25-45)
+	- **Secondary:** Fitness enthusiasts tracking multiple activities
+	- **Tertiary:** Personal trainers monitoring client progress
+
+	---
+
+	## Beta Testing Plan Overview
+
+	### Objective
+
+	Evaluate the app's performance in **real-world jogging scenarios** to validate GPS tracking accuracy, user interface effectiveness, and overall user experience during active exercise.
+
+	### Key Features to Test
+
+	- **GPS tracking accuracy** for distance and route mapping
+	- **Real-time data display** during exercise
+	- **Battery performance** during extended tracking
+	- **User interface usability** while exercising
+	- **Data synchronisation** with wearable devices
+	- **Post-exercise data analysis** and presentation
+
+	---
+
+	## Test Scenario: Tracking a Morning Jog
+
+	### Pre-Test Setup
+
+	**Participant Profile:**
+
+	- **Name:** Sarah, 32, Marketing Manager
+	- **Experience:** Regular jogger (3x per week, 5km average)
+	- **Technology:** iPhone 14, Apple Watch Series 8
+	- **Previous app experience:** Used Strava and Nike Run Club
+
+	**Environment:**
+
+	- **Location:** Local park with mixed terrain (paths, grass, hills)
+	- **Distance:** Planned 5km route (known distance for accuracy comparison)
+	- **Weather:** Clear morning, 18°C, light breeze
+	- **Time:** 7:00 AM (peak usage time for target demographic)
+
+	### Phase 1: Preparation
+
+	**Duration:** 5 minutes
+
+	**User Actions:**
+
+	1. **App installation** completed the previous evening
+	2. **Account setup** and basic profile information entered
+	3. **Device connectivity** - iPhone paired with Apple Watch
+	4. **GPS and permissions** verified and activated
+	5. **Pre-jog warm-up** while reviewing app interface
+
+	**Observer Notes:**
+
+	- Monitor ease of initial setup and configuration
+	- Document any confusion with interface elements
+	- Note time taken for GPS signal acquisition
+	- Record any pre-exercise user questions or concerns
+
+	**Success Criteria:**
+
+	- App ready for tracking within 2 minutes
+	- GPS signal acquired and stable
+	- User feels confident to begin tracking
+
+	### Phase 2: Starting the Activity
+
+	**Duration:** 2 minutes
+
+	**User Actions:**
+
+	1. **Open FitTrack Pro** and navigate to "Start Workout"
+	2. **Select activity type** - "Outdoor Running"
+	3. **Configure settings** - audio feedback, display preferences
+	4. **Wait for GPS lock** - app indicates when ready
+	5. **Press "Start"** to begin tracking
+	6. **Begin jogging** at comfortable pace
+
+	**Data Collection Focus:**
+
+	- **Interface responsiveness** during activity initiation
+	- **GPS acquisition time** and accuracy indicators
+	- **Audio/visual feedback** clarity and usefulness
+	- **User confidence** in starting the tracking process
+
+	**Observation Points:**
+
+	- Time from opening app to successful tracking start
+	- User interaction difficulties while preparing to exercise
+	- GPS signal strength and initial accuracy readings
+	- Any hesitation or confusion during startup process
+
+	### Phase 3: During the Jog
+
+	**Duration:** 30 minutes (5km route)
+
+	**User Actions:**
+
+	1. **Maintain comfortable jogging pace** (approximately 6:00 min/km)
+	2. **Periodically check app display** for distance, pace, time
+	3. **Navigate through different terrains** - paved paths, grass, slight hills
+	4. **Test audio feedback** - distance milestones and pace updates
+	5. **Pause/resume functionality** - brief water break at 2.5km mark
+	6. **Monitor device battery** and app performance
+
+	**Systematic Data Collection:**
+
+	**Every 1km checkpoint:**
+
+	- **Distance accuracy** (compare to known route markers)
+	- **Pace consistency** with perceived effort
+	- **Route mapping** visual verification on app
+	- **User interface visibility** in morning sunlight
+	- **Audio feedback quality** and timing
+
+	**Environmental challenges:**
+
+	- **Tree cover areas** (potential GPS interference)
+	- **Hill sections** (elevation tracking accuracy)
+	- **Path intersections** (route accuracy maintenance)
+	- **Crowded areas** (app performance under stress)
+
+	**User experience monitoring:**
+
+	- **Ease of checking stats** while jogging
+	- **Screen readability** during movement
+	- **Audio volume** and clarity over ambient noise
+	- **Overall distraction level** from exercise focus
+
+	### Phase 4: Ending the Activity
+
+	**Duration:** 3 minutes
+
+	**User Actions:**
+
+	1. **Complete 5km route** and return to starting point
+	2. **Stop tracking** using app interface
+	3. **Save workout** with optional name/notes
+	4. **Review immediate summary** - time, distance, pace, route
+	5. **Check data synchronisation** with Apple Watch
+	6. **Export/share** workout data (optional)
+
+	**Critical Assessment Points:**
+
+	- **Ease of stopping** tracking while tired/sweaty
+	- **Data accuracy** compared to known 5km route
+	- **Summary presentation** - clarity and completeness
+	- **Synchronisation success** across devices
+	- **User satisfaction** with immediate results
+
+	### Phase 5: Post-Exercise Review
+
+	**Duration:** 10 minutes (after cool-down)
+
+	**Detailed Analysis Tasks:**
+
+	1. **Compare total distance** with known 5km route measurement
+	2. **Review route map** for accuracy and detail
+	3. **Analyse pace data** for consistency and accuracy
+	4. **Check elevation profile** against known terrain
+	5. **Examine battery usage** on both devices
+	6. **Test data export** functionality
+	7. **Compare results** with previous tracking apps
+
+	**Data Verification Methods:**
+
+	- **Manual route measurement** using Google Maps
+	- **GPS watch comparison** (if available)
+	- **Known distance markers** verification
+	- **Previous workout comparison** for consistency
+	- **Battery usage analysis** vs. competing apps
+
+	---
+
+	## Expected Outcomes
+
+	### Quantitative Success Measures
+
+	- **Distance accuracy:** Within 2% of known 5km route (4.9-5.1km)
+	- **GPS tracking:** Continuous signal with <5% data loss
+	- **Battery efficiency:** <15% battery drain on smartphone
+	- **Route accuracy:** 95% overlap with actual path taken
+	- **Interface responsiveness:** All user inputs <2 second response
+
+	### Qualitative Success Measures
+
+	- **User interface:** Easy to read and navigate while exercising
+	- **Audio feedback:** Clear, timely, and helpful pace/distance updates
+	- **Overall experience:** Positive user feeling about app reliability
+	- **Workflow efficiency:** Intuitive start/stop/save process
+	- **Data presentation:** Clear, comprehensive post-exercise summary
+
+	### User Experience Targets
+
+	- **Confidence level:** User feels app accurately tracked their workout
+	- **Satisfaction rating:** 8/10 or higher for overall experience
+	- **Recommendation likelihood:** User would recommend to other joggers
+	- **Continued use intention:** User plans to use for future workouts
+
+	---
+
+	## Feedback Collection Framework
+
+	### Real-Time Feedback (During Exercise)
+
+	**Method:** Verbal observations recorded by test observer
+
+	- **Audio clarity** and usefulness ratings
+	- **Interface visibility** in various lighting conditions
+	- **Ease of interaction** while maintaining exercise rhythm
+	- **Distraction level** from primary exercise focus
+
+	### Immediate Post-Exercise Feedback (5 minutes post)
+
+	**Method:** Structured interview while experience is fresh
+
+	- **Overall satisfaction** with tracking accuracy
+	- **User interface** effectiveness during exercise
+	- **Comparison** with previous app experiences
+	- **Immediate improvement** suggestions
+
+	### Detailed Analysis Feedback (15 minutes post)
+
+	**Method:** Comprehensive questionnaire + data review
+
+	- **Accuracy assessment** of all tracked metrics
+	- **Feature usefulness** evaluation (GPS, audio, interface)
+	- **Battery performance** satisfaction
+	- **Data export/sharing** functionality review
+	- **Long-term usage** likelihood and recommendations
+
+	### Follow-Up Feedback (24 hours later)
+
+	**Method:** Email survey
+
+	- **Data retention** and app stability
+	- **Motivation impact** from tracked workout data
+	- **Sharing experience** with social features
+	- **Overall app ecosystem** integration satisfaction
+
+	---
+
+	## Critical Evaluation Points
+
+	### Technical Performance
+
+	- **GPS accuracy** in various environmental conditions
+	- **Battery optimization** compared to competing apps
+	- **Device integration** seamless functionality
+	- **App stability** during extended use
+	- **Data synchronisation** reliability
+
+	### User Experience Quality
+
+	- **Interface usability** while exercising
+	- **Information hierarchy** - most important data prominent
+	- **Accessibility** for users with different needs
+	- **Learning curve** for new app features
+	- **Error recovery** when problems occur
+
+	### Competitive Analysis
+
+	- **Feature comparison** with established apps (Strava, Nike Run Club)
+	- **Performance benchmarking** against industry standards
+	- **User migration** ease from other platforms
+	- **Unique value proposition** identification
+	- **Market positioning** effectiveness
+
+	---
+
+	## Risk Factors and Mitigation
+
+	### Environmental Risks
+
+	- **Weather changes** during testing
+	- **GPS interference** in certain locations
+	- **Safety concerns** while monitoring app during exercise
+	- **Device security** during outdoor exercise
+
+	### Technical Risks
+
+	- **App crashes** during critical tracking
+	- **Battery failure** mid-exercise
+	- **GPS signal loss** in problematic areas
+	- **Data corruption** or loss during save
+
+	### User Experience Risks
+
+	- **Participant fatigue** affecting feedback quality
+	- **Observer interference** with natural usage
+	- **Pressure to provide positive feedback**
+	- **Learning curve** masking true usability
+
+	---
+
+	## Success Indicators for Beta Testing
+
+	### Immediate Success (Test Day)
+
+	- **Successful completion** of full 5km tracking
+	- **Positive user feedback** on core functionality
+	- **Technical performance** meeting minimum benchmarks
+	- **No critical bugs** or app failures during use
+
+	### Short-Term Success (1 week)
+
+	- **Continued app usage** by beta tester
+	- **Positive word-of-mouth** to other potential users
+	- **Feature utilisation** beyond basic tracking
+	- **Integration success** with user's fitness routine
+
+	### Long-Term Success (1 month)
+
+	- **Regular usage pattern** established
+	- **User retention** and engagement maintained
+	- **Feature evolution** based on beta feedback
+	- **Market readiness** for broader release
+
+	---
+
+	## Learning Applications for Students
+
+	### C9-1 Planning Skills
+
+	**This case study demonstrates:**
+
+	- **Comprehensive test scenario** development
+	- **Multiple data collection methods** integration
+	- **User selection rationale** based on target demographics
+	- **Success criteria** definition with measurable outcomes
+
+	### C9-2 Execution Skills
+
+	**Students can analyse:**
+
+	- **Systematic approach** to user coordination
+	- **Professional observation** techniques
+	- **Real-time data collection** strategies
+	- **Environmental variable** management
+
+	### C9-3 Documentation Skills
+
+	**Documentation framework shows:**
+
+	- **Structured results** organisation
+	- **Multiple data types** integration (quantitative/qualitative)
+	- **Clear reporting** standards
+	- **Evidence-based analysis** methodologies
+
+	### C9-4 Recommendation Skills
+
+	**Students learn to develop:**
+
+	- **Evidence-linked modifications** from specific feedback
+	- **Prioritised improvements** based on user impact
+	- **Technical feasibility** assessment
+	- **User experience enhancement** strategies
+
+	---
+
+	## Extended Activities for Students
+
+	### Activity 1: Scenario Adaptation
+
+	**Task:** Adapt this jogging scenario for testing a different fitness app feature (cycling, weightlifting, yoga) **Skills:** Planning modification, target user adjustment, success criteria development
+
+	### Activity 2: Data Collection Design
+
+	**Task:** Design 3 additional data collection methods for this scenario **Skills:** Methodology development, systematic data capture, professional feedback collection
+
+	### Activity 3: User Selection Rationale
+
+	**Task:** Justify why Sarah was selected as a beta tester and identify 2 additional user types **Skills:** User representation analysis, diversity consideration, target audience understanding
+
+	### Activity 4: Modification Recommendations
+
+	**Task:** Based on provided sample feedback, recommend 5 specific app improvements **Skills:** Evidence-based analysis, prioritisation, user-centred design thinking
+
+	---
+
+	## Assessment Connections
+
+	### C9-1 Preparation Excellence
+
+	This case study exemplifies **comprehensive beta testing planning** that targets:
+
+	- **Appearance** (interface visibility during exercise)
+	- **Functionality** (GPS tracking, data recording)
+	- **User experience** (workout workflow, motivation impact)
+	- **Requirements** (functional performance + non-functional usability)
+
+	### Professional Standards
+
+	Demonstrates **industry-quality beta testing** with:
+
+	- **Clear objectives** and measurable outcomes
+	- **Systematic methodology** with multiple data collection approaches
+	- **Risk awareness** and mitigation planning
+	- **User-centred focus** throughout testing process
+
+	### Real-World Application
+
+	Shows students **authentic software development** practices used by professional teams for **user experience validation** and **product improvement**.
+
+	---
+
+	_This case study provides a complete example of professional beta testing methodology that students can analyse, learn from, and adapt for their own C9 assessment preparation._
\	No newline at end of file
/dev/null .. sd/C09/Test Scenario Template.md
@@ 0,0 1,263 @@
+	<!-- Generated from applied-computing-au vic/unit3-4/sat/C09-2026 by port-reference-godot-to-wiki.py — do not hand-edit; re-run the port. -->
+	<!--
+	Source: Test Scenario Template.qmd (acsddev/25-SAT/SAT-9/)
+	Imported: 2026-04-06
+	-->
+
+	*Use this template to create detailed, professional test scenarios for your beta testing plan*
+
+	---
+
+	## Scenario Information
+
+	**Scenario Name:** ______________________________________________
+
+	**Scenario Type:** *(Select one)*
+
+	- [ ] **Appearance Testing** (interface design, visual consistency)
+	- [ ] **Functionality Testing** (core features, system operations)
+	- [ ] **User Experience Testing** (workflow, usability, satisfaction)
+	- [ ] **Performance Testing** (speed, reliability, compatibility)
+
+	**Related Software Features:**
+	________________________________________________________________
+
+	---
+
+	## Scenario Objective
+
+	### Primary Goal:
+	*What specific aspect of your software will this scenario evaluate?*
+
+	**To evaluate:** _______________________________________________
+
+	**Focus Area:** _______________________________________________
+
+	**Success Definition:** ________________________________________
+
+	---
+
+	## User Context
+
+	### Beta Tester Profile:
+	**Who is testing:** __________________________________________
+
+	**User Experience Level:** ___________________________________
+
+	**Relevant Background:** _____________________________________
+
+	**Testing Environment:** _____________________________________
+
+	### Pre-Scenario Setup:
+	*What needs to be prepared before testing begins?*
+
+	**Required Hardware/Software:** ______________________________
+
+	**Data/Content Needed:** ____________________________________
+
+	**Environmental Conditions:** ________________________________
+
+	---
+
+	## Detailed User Journey
+
+	### Step 1: Preparation Phase
+	**Duration:** _______ minutes
+
+	**User Actions:**
+
+	&nbsp;
+
+	&nbsp;
+
+	&nbsp;
+
+	**Expected Outcome:** ______________________________________
+
+	**Observer Notes:** _______________________________________
+
+	### Step 2: Starting Activity
+	**Duration:** _______ minutes
+
+	**User Actions:**
+
+	&nbsp;
+
+	&nbsp;
+
+	&nbsp;
+
+	**Expected Outcome:** ______________________________________
+
+	**Observer Notes:** _______________________________________
+
+	### Step 3: During Activity
+	**Duration:** _______ minutes
+
+	**User Actions:**
+
+	&nbsp;
+
+	&nbsp;
+
+	&nbsp;
+
+	**Expected Outcome:** ______________________________________
+
+	**Observer Notes:** _______________________________________
+
+	### Step 4: Ending Activity
+	**Duration:** _______ minutes
+
+	**User Actions:**
+
+	&nbsp;
+
+	&nbsp;
+
+	&nbsp;
+
+	**Expected Outcome:** ______________________________________
+
+	**Observer Notes:** _______________________________________
+
+	### Step 5: Post-Activity Review
+	**Duration:** _______ minutes
+
+	**User Actions:**
+
+	&nbsp;
+
+	&nbsp;
+
+	&nbsp;
+
+	**Expected Outcome:** ______________________________________
+
+	**Observer Notes:** _______________________________________
+
+	---
+
+	## Data Collection Plan
+
+	### Real-Time Data Collection:
+	*What will you observe/record during the scenario?*
+
+	**During Step 1:** __________________________________________
+
+	**During Step 2:** __________________________________________
+
+	**During Step 3:** __________________________________________
+
+	**During Step 4:** __________________________________________
+
+	**During Step 5:** __________________________________________
+
+	### Post-Scenario Data Collection:
+	*What will you analyse after the scenario is complete?*
+
+	**Quantitative Measures:**
+
+	&nbsp;
+
+	&nbsp;
+
+	&nbsp;
+
+	**Qualitative Feedback:**
+
+	&nbsp;
+
+	&nbsp;
+
+	&nbsp;
+
+	---
+
+	## Specific Feedback Questions
+
+	### Targeted Questions for This Scenario:
+	*What specific questions will you ask about this scenario?*
+
+	**Question 1:** _______________________________________________
+
+	**Question 2:** _______________________________________________
+
+	**Question 3:** _______________________________________________
+
+	**Question 4:** _______________________________________________
+
+	**Question 5:** _______________________________________________
+
+	### Comparison/Validation Methods:
+	*How will you verify the accuracy of results?*
+
+	**Benchmark Comparison:** __________________________________
+
+	**External Validation:** __________________________________
+
+	**Known Standards:** ______________________________________
+
+	---
+
+	## Success Criteria
+
+	### Scenario Success Indicators:
+	**Primary Success:** ______________________________________
+
+	**Secondary Success:** ___________________________________
+
+	**Minimum Acceptable:** __________________________________
+
+	### Failure Indicators:
+	**Critical Failure:** ___________________________________
+
+	**Major Issues:** _______________________________________
+
+	**Minor Problems:** _____________________________________
+
+	---
+
+	## Expected Outcomes
+
+	### What Should Happen:
+	**Ideal User Experience:**
+
+	&nbsp;
+
+	**Expected Performance:**
+
+	&nbsp;
+
+	**Anticipated Results:**
+
+	&nbsp;
+
+	### Potential Issues:
+	**Known Risks:** ________________________________________
+
+	**Likely Challenges:** __________________________________
+
+	**Contingency Plans:** __________________________________
+
+	---
+
+	## Integration with Main Beta Testing Plan
+
+	### Connection to Overall Testing:
+	**This scenario supports objective:** ___________________________
+
+	**Links to other scenarios:** _______________________________
+
+	**Contributes to C9 criteria:** ____________________________
+
+	### Documentation Integration:
+	**Results will feed into:** _________________________________
+
+	**Recommendations will address:** ___________________________
+
+	**Evidence will support:** __________________________________
+
+	---
+
+	*Complete one template for each test scenario in your beta testing plan*
/dev/null .. sd/C09/The Four-Step Beta Testing Journey.md
@@ 0,0 1,100 @@
+	<!-- Generated from applied-computing-au vic/unit3-4/sat/C09-2026 by port-reference-godot-to-wiki.py — do not hand-edit; re-run the port. -->
+	## 9-0 The Four-Step Beta Testing Journey
+
+	### STEP 1: Planning and Preparation
+
+	**Core Action:** **Prepare** comprehensive beta testing strategy
+
+	**Essential Elements:**
+
+	- **Beta testing plan** targeting solution **appearance**, **functionality**, and **requirements**
+	- **Test scenarios** focusing on **user experience characteristics**
+	- **Potential user selection** with clear **rationale** for choices
+	- **Data collection methodology** planning
+	- **Component identification** for testing scope
+
+	**Key Planning Words:** Prepares, Outlines, Explains, Documents, Includes, Targets
+
+	### STEP 2: Conducting Beta Testing
+
+	**Core Action:** **Execute** beta testing with real users
+
+	**Essential Elements:**
+
+	- **Multiple potential users** (minimum 2 for unit requirements)
+	- **Multiple data collection methods** (aim for 3+ different approaches)
+	- **Systematic data capture** during testing sessions
+	- **Consistent testing conditions** across all users
+	- **Professional user engagement** and coordination
+
+	**Key Execution Words:** Conducts, Collects, Uses, Prepares (data for analysis)
+
+	### STEP 3: Results Documentation
+
+	**Core Action:** **Document** comprehensive testing outcomes
+
+	**Essential Elements:**
+
+	- **Complete set of results** from all testing sessions
+	- **Detailed reporting** of user feedback and observations
+	- **Clear and concise** presentation of findings
+	- **Evidence-based analysis** of user experiences
+	- **Professional documentation standards**
+
+	**Key Documentation Words:** Lists, Outlines, Describes, Documents, Explains
+
+	### STEP 4: Recommendations and Evaluation
+
+	**Core Action:** **Recommend** solution improvements **based on results**
+
+	**Essential Elements:**
+
+	- **Evidence-linked modifications** to the software solution
+	- **Clear rationale** for recommended changes
+	- **Evaluation** of proposed modifications against beta testing findings
+	- **Purposeful improvements** targeting identified issues
+	- **Comprehensive assessment** of testing outcomes
+
+	**Key Recommendation Words:** Identifies, Outlines, Recommends, Explains, Evaluates
+
+	
+
+	## External User Engagement Strategy
+
+	### User Selection and Recruitment:
+
+	- **Target audience representatives** (actual intended users)
+	- **Diverse user perspectives** (different backgrounds, needs, experience levels)
+	- **Available and willing participants** (realistic about time commitments)
+	- **Other students as proxy users** (acceptable for educational context)
+	- **Community members** relevant to solution purpose
+
+	### Engagement Approaches:
+
+	- **Direct recruitment** through personal networks
+	- **Organised testing sessions** with scheduled appointments
+	- **Remote testing options** for accessibility
+	- **Professional communication** with clear expectations
+	- **Ethical considerations** (consent, privacy, respect for time)
+
+	### Data Collection Methods (Multiple Required):
+
+	1. **Direct observation** during testing sessions
+	2. **Structured interviews** for detailed feedback
+	3. **Questionnaires/surveys** for consistent data
+	4. **Screen recording** of user interactions
+	5. **Task completion tracking** for usability metrics
+	6. **User journey documentation** for experience mapping
+	7. **Error logging** for problem identification
+
+	## Critical Success Factors
+
+	### Organisation and Planning:
+
+	- **Early user recruitment** (start 2-3 weeks before testing needed)
+	- **Flexible scheduling** to accommodate multiple users
+	- **Backup plans** for user unavailability or technical issues
+	- **Clear testing protocols** for consistency
+	- **Professional materials** (instructions, consent forms, feedback tools)
+
+	
\	No newline at end of file
/dev/null .. sd/C09/The Four-Step Beta Testing Journey/planning-box.svg
@@ 0,0 1,4 @@
+	<svg width="1024" height="800" xmlns="http://www.w3.org/2000/svg">
+	<rect x="2" y="2" width="98%" height="760" rx="5" ry="5" fill="none" stroke="black" stroke-width="2" />
+	<text x="10" y="25" font-family="sans-serif" font-size="16" fill="black">Planning Area:</text>
+	</svg>
/dev/null .. sd/C09/Timeline and Resource Considerations.md
@@ 0,0 1,43 @@
+	<!-- Generated from applied-computing-au vic/unit3-4/sat/C09-2026 by port-reference-godot-to-wiki.py — do not hand-edit; re-run the port. -->
+	## 9-0 Timeline and Resource Considerations
+
+	### Pre-Testing Phase (2-3 weeks):
+
+	- User identification and contact
+	- Schedule coordination across multiple participants
+	- Testing environment and materials preparation
+	- Data collection tools setup
+	- Contingency planning for common issues
+
+	### Testing Phase (1-2 weeks):
+
+	- Multiple testing sessions with different users
+	- Consistent data capture across all sessions
+	- Real-time problem solving and adaptation
+	- Professional user management and communication
+
+	### Post-Testing Phase (1 week):
+
+	- Data compilation and analysis
+	- Results documentation and reporting
+	- Evidence-based recommendation development
+	- Final documentation preparation
+
+	## Key Progression Indicators
+
+	**Students achieving higher levels will demonstrate:**
+
+	- More sophisticated **planning** with comprehensive test scenarios
+	- **Multiple users** and **diverse data collection methods**
+	- **Detailed, professional documentation** of all phases
+	- **Thorough evaluation** of recommendations against testing evidence
+	- **Clear, evidence-based justification** for all decisions
+
+	**All students must demonstrate:**
+
+	- **Systematic approach** to beta testing process
+	- **External user engagement** (minimum 2 users)
+	- **Professional documentation** of results
+	- **Evidence-linked recommendations** for solution improvement
+
+	**Success depends on:** Early planning, professional user engagement, systematic data collection, and evidence-based analysis leading to justified recommendations for solution enhancement.
\	No newline at end of file
sd/VCE Software Development Hub.md ..
@@ 27,6 27,7 @@
	- [C06 — Skills in Using the Features of the Programming Language](/sd/C06/C06-home)
	- [C07 — Skills in Developing the Software Solution](/sd/C07/C07-home)
	- [C08 — Skills in Debugging and Alpha Testing the Software Solution](/sd/C08/C08-home)
+	- [C09 — Skills in Conducting Beta Testing](/sd/C09/C09-home)
	## Tools