PLS-7A: Preparing Your Testing Environment – Housing.cloud

Overview

In this module, you'll prepare your sandbox environment for comprehensive cycle testing. You'll create test student profiles, configure your cycle with testing-friendly date ranges, apply appropriate tags, and verify all components are ready for testing.

What you'll learn:

How to create test student profiles in sandbox without needing login credentials
How to set cycle phase dates to present/active ranges for immediate testing
How to apply tags to test profiles to simulate different student populations
How to verify your forms, documents, and meal plans are ready for testing
How to create a testing plan with multiple scenarios

Time: 15 minutes

Sandbox-Only Testing: All PLS-7 activities happen in your sandbox environment. Test data you create stays in sandbox and does not migrate to production. This means you can create as many test profiles as needed, test freely, and experiment without any concern about affecting production data.

Why Test Environment Preparation Matters

Proper test setup is critical for catching real issues. If you skip creating diverse test profiles or don't configure phase dates correctly, you'll miss configuration problems that will surface when real students use your cycle.

Common testing mistakes:

Testing with only one student profile type (missing edge cases)
Not applying tags to test profiles (can't test applicability rules)
Phase dates set in the future (can't access phases to test)
Missing inventory tags (can't test visibility rules)
Only testing "happy path" (missing validation and error handling)

This module ensures you avoid these mistakes and set up comprehensive testing.

Step 1: Create Test Student Profiles

Test student profiles allow you to experience your cycle from the student perspective without needing actual student accounts or login credentials.

How to Create Test Profiles

Navigation: Admin › Profiles

Click Add Profile (typically top-right of the Profiles table)
Select Add Resident Profile from the dropdown menu
Enter test student information: • First Name: Use descriptive test names like "Johnny" or "Sarah" • Last Name: Use "Test" as the last name to clearly identify test accounts • Email: Use fake but valid-format emails like johnny.test@example.com or test1@yourschool.edu • Student ID: Use fake IDs like "TEST001", "TEST002", etc. • Class Year: Select the class year you want to test (e.g., First-Year, Sophomore)
Click Save to create the profile

No Login Required: You do NOT need to actually log in to these test accounts. Admins can access the resident portal view for any profile directly from the admin portal using impersonation or by viewing their resident portal page. Use fake names and emails—these are purely for testing purposes in sandbox.

How Many Test Profiles to Create

Create at least 3-4 test profiles to cover different scenarios:

Test Profile 1: "Johnny Test" (Happy Path Student)

Email: johnny.test@example.com
Student ID: TEST001
Class Year: First-Year
Tags: Will receive tags that MATCH your cycle's applicability requirements
Purpose: Tests the complete workflow when everything works correctly

Test Profile 2: "Sarah Test" (Roommate Partner)

Email: sarah.test@example.com
Student ID: TEST002
Class Year: First-Year
Tags: Similar to Johnny Test for roommate matching testing
Purpose: Tests roommate group formation and group room selection

Test Profile 3: "Alex Test" (Third Roommate for Group Testing)

Email: alex.test@example.com
Student ID: TEST003
Class Year: First-Year
Tags: Different preferences from Johnny/Sarah to test compatibility scoring
Purpose: Tests 3-person roommate groups and compatibility filters

Test Profile 4: "Morgan Test" (Ineligible Student)

Email: morgan.test@example.com
Student ID: TEST004
Class Year: Senior
Tags: DOES NOT match your cycle's applicability requirements (or has exclusion tags)
Purpose: Tests that ineligible students cannot see your cycle

Create Profiles Before Applying Tags: Always create the basic profile first, then apply tags in the next step. This mirrors how real student data flows into the system and ensures you're testing realistic scenarios.

Step 2: Apply Tags to Test Profiles

Tags control who can see your cycle and which rooms they can select. Applying tags to test profiles allows you to test these eligibility and visibility rules.

Applying Tags to Profiles

Navigate to Admin › Profiles
Click on a test student name (e.g., "Johnny Test") to open their profile detail page
Scroll to the Tags section
Click Add Tag or Manage Tags
Apply appropriate tags based on your cycle's applicability requirements
Click Save

Which Tags to Apply

Apply tags that match your testing scenarios:

For Johnny Test (Happy Path):

Class year tag: "First-Year" (if your cycle requires it via applicability tags)
Preference tags: "Early Riser", "Quiet Study Environment"
Any other tags required by your cycle's applicability settings (And tags)
Ensure this profile does NOT have any exclusion tags

For Sarah Test (Roommate Partner):

Same applicability tags as Johnny (so they're both eligible)
Similar preference tags: "Early Riser", "Quiet Study Environment"
Purpose: High compatibility match with Johnny for roommate testing

For Alex Test (Different Preferences):

Same applicability tags (eligible for the cycle)
Different preference tags: "Night Owl", "Background Noise OK"
Purpose: Lower compatibility with Johnny/Sarah to test scoring differences

For Morgan Test (Ineligible):

MISSING required applicability tags (e.g., don't tag as "First-Year" if your cycle requires it)
OR has exclusion tags (e.g., "Commuter" if your cycle excludes commuters)
Purpose: Should NOT be able to see your cycle in their portal

Tag Strategy Recap: Review your cycle's applicability tags from PLS-6A. Your test profiles should represent students who DO meet requirements (And/Or tags) and students who DON'T meet requirements (missing tags or have exclusion tags). This validates your eligibility rules work correctly.

Step 3: Apply Tags to Inventory for Visibility Testing

If your cycle uses tags to control which rooms students can see (configured in your ruleset or room selection settings), you need to tag inventory items for testing.

Why Tag Inventory

Room visibility rules use tags to show students only appropriate inventory. For example:

Students with "ADA Accommodation" tag only see rooms tagged "ADA Accessible"
Students with "Female" tag only see rooms tagged "Female Housing"
Students with "Graduate Student" tag only see graduate housing buildings

If you don't tag inventory, visibility rules can't be tested.

How to Tag Inventory

Navigate to Admin › Inventory › Buildings
Click a building name to open its detail page
Navigate to specific rooms (Building › Room)
In the Tags section of a room detail page, click Add Tag
Apply relevant tags based on your room characteristics: • "ADA Accessible" for accessible rooms • "Air Conditioning" for rooms with A/C • "Private Bathroom" for en-suite bathrooms • "Female Housing", "Male Housing" for gender-specific floors • Any other inventory tags your ruleset uses for visibility
Repeat for multiple rooms to test filtering

Tag a Variety of Rooms: Don't tag all rooms the same way. Tag some rooms with "ADA Accessible", some without. Tag some with "Air Conditioning", some without. This variety lets you test whether filtering and visibility rules work correctly.

Step 4: Configure Phase Dates for Testing

To test your cycle, all phases must be accessible RIGHT NOW. This means setting phase start dates to today's date or earlier.

Why Phase Dates Matter for Testing

If your application phase starts "March 1, 2025" but today is February 15, 2025, students won't be able to access the application. For testing purposes, you need to temporarily set phase dates so all phases are currently active.

How to Configure Testing-Friendly Dates

Navigate to Admin › Setup › Cycles
Click your cycle name to edit
Go through each phase tab and adjust dates:

Application Phase:

Start date: Today's date or yesterday
End date: 2 weeks from today (or later)

Roommate Phase:

Start date: Today's date or yesterday
End date: 2 weeks from today (or later)

Room Selection Phase:

Start date: Today's date or yesterday (unless testing lottery timing)
End date: 2 weeks from today (or later)

Meal Plan Phase (if applicable):

Start date: Today's date or yesterday
End date: 2 weeks from today

Move-In Groups:

Move-in dates: Set to a future date within the next 1-2 weeks
Scheduling window: Open NOW so students can select move-in times

Remember Active Cycle Rules: Setting phase dates to present or past will activate your cycle in sandbox. Once active, you can only edit phase dates and release dates—other configuration locks. If you need to make non-date configuration changes after testing reveals issues, you may need to copy the cycle or contact support. Test thoroughly before activating in production.

Testing Lottery Timing (If Applicable)

If your cycle uses lottery-based room selection, you have two testing approaches:

Option 1: Skip Lottery for Initial Testing

Set room selection start date to past/present (lottery window already passed)
All students can select rooms immediately
Easier for initial workflow testing
Test lottery-specific features separately in a second round

Option 2: Test Lottery Timing

Configure lottery with specific selection windows
Assign lottery times to your test students manually in admin
Test that students can only select during their assigned time
More realistic but requires more setup

Step 5: Verify All Components Are Ready

Before testing as a student, verify from the admin portal that all cycle components are properly configured and published.

Component Verification Checklist

Forms:

☐ Navigate to Admin › Setup › Forms
☐ Find YOUR application form and verify status is "Published"
☐ Find YOUR bio form and verify status is "Published"
☐ Preview each form to ensure questions display correctly

Documents:

☐ Navigate to Admin › Setup › Document Templates
☐ Find YOUR housing contract (or other documents)
☐ Verify merge fields are configured ({{firstName}}, {{roomNumber}}, etc.)
☐ Preview the document to check formatting

Meal Plans:

☐ Navigate to Admin › Setup › Meal Plans
☐ Verify YOUR meal plan options are created with correct pricing
☐ Verify external IDs match your SIS (if applicable)

Tags:

☐ Navigate to Admin › Setup › Tags
☐ Verify all tag categories and tags you need are created
☐ Verify visibility settings (public vs private) are correct
☐ Verify applicability settings (profiles, applications, inventory) are correct

Charge Codes:

☐ Navigate to Admin › Setup › Charge Codes
☐ Verify room pricing charge codes are created
☐ Verify meal plan charge codes exist (if applicable)
☐ Check that charge codes are assigned to inventory (buildings/rooms)

Cycle Configuration:

☐ Navigate to Admin › Setup › Cycles and click your cycle
☐ Review General tab: Verify applicability tags, residence dates, term code
☐ Review Application tab: Verify form assigned, ruleset assigned, phase dates
☐ Review Roommate tab: Verify bio form assigned, phase dates, group size limits
☐ Review Room Selection tab: Verify phase dates, lottery settings, visibility rules
☐ Review Move-In tab: Verify moving groups created with time slots
☐ Review Meal Plans tab: Verify meal plans assigned, phase dates (if self-selection)
☐ Review Documents tab: Verify documents assigned
☐ Review Phase Calendar: Verify no gaps or overlaps, all dates make sense

If Everything Checks Out: You're ready to proceed to PLS-7B and begin testing the application journey. If you found missing components or configuration errors, fix them now before testing.

Step 6: Create Your Testing Plan

Before you start testing, create a plan that outlines which scenarios you'll test and what you're validating at each step.

Sample Testing Plan Template

Scenario 1: Johnny Test (Happy Path - Individual Selection)

Workflow	What to Test	Expected Result
Application	Complete application, verify submission	Application created, tags applied, status = Submitted
Bio Form	Complete roommate questionnaire	Bio saved, visibility set to public
Room Selection	Browse rooms, select as individual	Room assigned, residency created
Documents	Sign housing contract	Document signed, status updated
Meal Plans	Select meal plan	Meal plan assigned to residency
Move-In	Schedule move-in time	Time slot reserved, QR code generated

Scenario 2: Sarah + Alex Test (Roommate Group Selection)

Workflow	What to Test	Expected Result
Applications	Both submit applications	Both applications created
Roommate Matching	Sarah sends request, Alex accepts	Roommate group formed
Group Selection	Group leader selects room for both	Both assigned to same room
Group Size Limits	Try to exceed max roommates	System blocks oversized groups

Scenario 3: Morgan Test (Ineligible Student)

Workflow	What to Test	Expected Result
Portal Access	Log in and view dashboard	Cycle SHOULD NOT appear in portal
Applicability	Verify tags don't match requirements	No "Apply for Housing" button for this cycle

Testing Plan Worksheet

Create a simple document or spreadsheet to track your testing:

Test Student	Tags Applied	Should See Cycle?	Workflow to Test	Issues Found	Status
Johnny Test	First-Year, Early Riser	Yes	Full application → room selection	(document during testing)	☐ Not Started
Sarah Test	First-Year, Early Riser	Yes	Roommate group with Johnny	(document during testing)	☐ Not Started
Alex Test	First-Year, Night Owl	Yes	Third roommate, compatibility	(document during testing)	☐ Not Started
Morgan Test	Senior, Commuter	No	Verify cycle invisible	(document during testing)	☐ Not Started

Step 7: How to Access the Resident Portal (Without Logging In)

You have two options for experiencing the student perspective:

Option 1: View Resident Portal Directly from Admin (Recommended)

In admin portal, navigate to Admin › Profiles
Click a test student name (e.g., "Johnny Test")
Look for a "View as Student" or "Student Portal" button/link
Click to open the resident portal view for that student
You'll see exactly what that student sees without needing to log in separately

Ask Your Implementation Team: The exact method for viewing the resident portal as a test student may vary. Ask your implementation specialist during the live PLS-7 session to show you the specific workflow in your sandbox environment.

Option 2: Log In Using Test Credentials (If Needed)

If your sandbox requires actual login credentials for test accounts:

When creating test profiles, use real email addresses you control (e.g., yourname+test1@yourschool.edu)
Set temporary passwords for test accounts
Navigate to your resident portal URL: yourschool.housing.cloud (without /admin)
Log in using test student credentials
Experience the portal as that student

Pre-Testing Final Checklist

Before proceeding to PLS-7B (Application Journey Testing), verify:

☐ 3-4 test student profiles created in sandbox with descriptive test names
☐ Tags applied to test profiles representing different scenarios (eligible and ineligible)
☐ Tags applied to inventory for visibility rule testing
☐ All cycle phase dates set to present/active ranges
☐ Application form published and assigned to cycle
☐ Bio form published and assigned to cycle
☐ Documents created and assigned to cycle (if using)
☐ Meal plans created and assigned to cycle (if required)
☐ Charge codes configured for room pricing
☐ Moving groups created with available time slots
☐ Testing plan created with scenarios documented
☐ Method for accessing resident portal confirmed (view as student or login)

Environment Ready: Your sandbox testing environment is now fully prepared. You have test students, active phase dates, proper tagging, and all components verified. You're ready to begin hands-on testing in PLS-7B.

Common Setup Issues

Issue	Cause	How to Fix
Can't create test profiles	Insufficient admin permissions	Verify you have admin role with profile creation permissions
Tags don't appear when trying to apply to profiles	Tags not created yet or wrong applicability	Go to Admin › Setup › Tags, create needed tags with "Profiles" applicability
Can't save phase dates	Date validation conflict or cycle already active	Check phase calendar for overlaps, verify dates are logical
Forms show "Draft" status	Forms not published	Edit form, click "Publish" button
Don't know how to access resident portal as test student	Unclear impersonation workflow	Ask your implementation specialist for the specific method in your system

Key Takeaways

Test profiles in sandbox should use fake names like "Johnny Test" and fake emails like test@example.com
You don't need login credentials for test profiles—admins can access their resident portal view directly
Apply tags to test profiles to simulate different student populations (eligible and ineligible)
Apply tags to inventory to test room visibility rules
Set all phase dates to present/active ranges so you can test all workflows immediately
Create at least 3-4 test profiles representing different scenarios (happy path, roommate groups, ineligible students)
All testing happens in sandbox—test data does not migrate to production
Verify all components (forms, documents, meal plans, tags, charge codes) before testing
Create a testing plan to track which scenarios you're validating

What's Next: PLS-7B

Now that your testing environment is prepared with test students, active phase dates, and verified components, you're ready to begin testing the application journey.

In PLS-7B: Testing the Application Journey, you'll:

Access the resident portal as a test student
Navigate to YOUR cycle
Complete YOUR application form
Verify submission creates an application record
Verify tags are applied correctly
Troubleshoot any issues discovered

Continue to PLS-7B →

Additional Resources

PLS-6: Creating YOUR Housing Cycle - Review cycle configuration
PLS-6A: Basic Cycle Settings & Applicability - Review applicability tag logic
PLS-6K: Phase Calendar & Understanding Active Cycles - Understanding active cycles
Product Learning Session Framework - Full PLS roadmap