Overview
This Knowledge Base article provides a comprehensive guide for testing a NetSuite Suitelet page that supports a scheduled SuiteScript customization designed to update the Current Expected Receipt Date for Purchase Order (PO) lines based on internal NetSuite logic (e.g., vendor lead times, transaction dates, or custom business rules). The Suitelet page serves as a user interface to display updated PO data, allow manual script triggers, filter PO records, or view execution status, enhancing user interaction within NetSuite. This guide details the scope of Suitelet page testing, outlines testing types and techniques, and provides verification steps to ensure functionality, usability, security, performance, and regression testing, addressing test cases TC_001 to TC_010.
Scope of Suitelet Page Testing
The scope of testing the Suitelet page includes:
- Functional Validation: Ensure the Suitelet accurately displays updated PO data, reflects SuiteScript execution results, and supports manual script triggers (if applicable).
- Usability: Confirm the page is intuitive, with clear navigation, filters, and visual cues for procurement users managing POs with various statuses.
- Security: Verify restricted access to authorized roles, secure handling of PO data, and protection against input vulnerabilities.
- Performance: Validate efficient loading and data handling for high-line-count POs and concurrent user access.
- Regression: Ensure existing functionality remains intact after SuiteScript updates or NetSuite releases.
- Test Case Coverage: Address TC_001 to TC_010 to validate SuiteScript behavior and its reflection on the Suitelet page, including correct updates, skipped updates, and handling of mixed statuses.
- Exclusions: Testing does not cover external API integrations, as the SuiteScript relies solely on internal NetSuite data and logic.
The Suitelet page operates within NetSuite, interacting with the SuiteScript and PO records, and is tested in a sandbox environment to simulate real-world procurement scenarios.
Test Cases
Test Case ID Description
TC_001 Verify the scheduled SuiteScript is created to update Current Expected Receipt Date for PO lines not yet received.
TC_002 Verify the Current Expected Receipt Date updates in POs upon running the script.
TC_003 Verify the Current Expected Receipt Date is not updated for lines with received quantity > 0.
TC_004 Verify the Current Expected Receipt Date is not updated for closed lines.
TC_005 Verify the customization works for POs with a “Partially Received” status.
TC_006 Verify the customization works for POs with both open and closed lines.
TC_007 Verify the customization works for POs with both received and closed lines.
TC_008 Verify the Current Expected Receipt Date is not updated if the PO is closed via the “Close” button.
TC_009 Verify the Current Expected Receipt Date is populated correctly for POs with more than 10 lines.
TC_010 Verify the Current Expected Receipt Date is populated for all eligible lines in a PO.
Testing Types, Techniques, and Verification Steps
1. Functional Testing
Purpose: Validate that the Suitelet page correctly displays PO data, reflects SuiteScript execution, and supports user interactions (TC_001, TC_002, TC_009, TC_010).
Steps:
- TC_001: Confirm the SuiteScript is deployed and accessible via the Suitelet. Navigate to Setup > Customization > Scripts in the sandbox and check the script’s deployment status (e.g., scheduled daily). Access the Suitelet page to verify it loads and displays script status (e.g., “Last Run: 2025-05-30 09:00 AM”).
- TC_002: Create a PO with open lines, run the SuiteScript to update the Current Expected Receipt Date, and access the Suitelet page. Verify the updated dates are displayed accurately.
- TC_009: Create a PO with 15 lines, run the SuiteScript, and check the Suitelet page to ensure all eligible lines’ dates are displayed correctly, with pagination or scrolling functional.
- TC_010: For a multi-line PO, confirm the Suitelet page shows updates for all eligible lines without omissions.
- Manual Trigger: If the Suitelet allows manual script execution, test triggering the script and verify immediate data refresh on the page. Verification Steps:
- Use a Transaction Line Fields search to cross-check Suitelet-displayed dates against NetSuite backend data.
- Confirm pagination handles 15+ lines by scrolling through all records and checking for missing data.
- For manual triggers, verify the script execution log (Customization > Scripting > Script Executions) shows a successful run post-trigger.
- Validate UI elements (e.g., buttons, filters) respond within 2 seconds using browser developer tools. Tools: NetSuite UI, Saved Search, SuiteCloud CLI, browser developer tools. Best Practice: Automate functional tests using testRigor to validate data display and script triggers after updates.
2. Usability Testing
Purpose: Ensure the Suitelet page is intuitive and user-friendly for procurement teams (TC_005, TC_006, TC_008).
Steps:
- TC_005: Create a “Partially Received” PO, run the SuiteScript, and have end-users access the Suitelet page. Check if open and received lines are clearly distinguished (e.g., via status labels or filters).
- TC_006: Test a PO with open and closed lines. Verify the Suitelet uses visual cues (e.g., color-coded rows) to differentiate updated and non-updated lines.
- TC_008: Close a PO using the “Close” button, run the SuiteScript, and confirm the Suitelet displays a clear message (e.g., “PO Closed, No Updates”). Verification Steps:
- Collect user feedback via surveys, ensuring >80% of users rate the UI as “easy to use” (4/5 or higher).
- Verify filters (e.g., by PO status) return correct results by comparing with a Saved Search.
- Confirm visual cues (e.g., green for updated lines, gray for closed) are consistent across all tested POs.
- Check page load time for filtered results is <3 seconds using SuiteAnalytics. Tools: NetSuite Custom Dashboards, Zephyr for feedback, SuiteAnalytics. Best Practice: Conduct usability sessions with 3-5 procurement users, using click-tracking tools to analyze navigation patterns.
3. Security Testing
Purpose: Ensure the Suitelet page restricts access and protects PO data (TC_001).
Steps:
- TC_001: Deploy the Suitelet with access restricted to the Procurement Manager role. Test with unauthorized roles (e.g., Viewer, Accountant) to confirm access is denied.
- Data Security: Verify the Suitelet only displays necessary PO fields (e.g., excludes sensitive vendor notes) to authorized users.
- Input Validation: Test input fields (e.g., PO ID search) for vulnerabilities like SQL or script injection using invalid inputs (e.g., <script>alert(1)</script>). Verification Steps:
- Check NetSuite’s Role Permissions setup to confirm only authorized roles access the Suitelet (Setup > Users/Roles > Manage Roles).
- Use a Saved Search to verify displayed PO data excludes restricted fields.
- Confirm injection attempts are blocked, with errors logged in the Script Execution Log or UI feedback (e.g., “Invalid Input”).
- Validate session timeout after 30 minutes of inactivity for security compliance. Tools: NetSuite Role Permissions, Burp Suite, Script Execution Log. Best Practice: Enable NetSuite’s Two-Factor Authentication (2FA) for Suitelet users and audit permissions monthly.
4. Performance Testing
Purpose: Validate the Suitelet page’s performance for high-line-count POs and concurrent users (TC_009).
Steps:
- TC_009: Create a PO with 20 lines, run the SuiteScript, and load the Suitelet page with 10 concurrent users via JMeter. Measure page load time and data rendering.
- Test pagination, lazy loading, or search filters to ensure smooth handling of large datasets. Verification Steps:
- Confirm page load time is <5 seconds for 20-line POs using JMeter reports.
- Verify all 20 lines display correctly without truncation, cross-checking with Saved Search.
- Check SuiteAnalytics for resource usage (e.g., CPU <70% during peak load).
- Ensure filters or sorting complete in <3 seconds for 50+ line POs. Tools: JMeter, SuiteAnalytics, Saved Search. Best Practice: Optimize Suitelet queries with SuiteQL or efficient Saved Searches and retest performance after optimizations.
5. Regression Testing
Purpose: Ensure Suitelet functionality remains intact after SuiteScript or NetSuite updates (TC_003, TC_004, TC_005, TC_006, TC_007, TC_008).
Steps:
- TC_003: Create a PO with received lines (>0 quantity), run the SuiteScript, and verify the Suitelet shows no updates for these lines.
- TC_004: Test a PO with closed lines, confirming the Suitelet displays no updates.
- TC_005: For a “Partially Received” PO, verify the Suitelet shows updates only for open lines.
- TC_006: Test a PO with open and closed lines, ensuring selective updates are displayed.
- TC_007: For a PO with received and closed lines, confirm no updates are shown.
- TC_008: Close a PO using the “Close” button and verify the Suitelet indicates no updates. Verification Steps:
- Use Transaction Line Fields search to confirm Suitelet data matches backend records.
- Check audit logs to verify SuiteScript skip logic is reflected on the Suitelet.
- Run automated regression tests to validate all scenarios, ensuring 100% pass rate.
- Confirm no new defects in Jira post-update compared to baseline tests. Tools: testRigor, Jira, NetSuite Audit Trail. Best Practice: Maintain a regression test suite in Zephyr, re-running tests after every NetSuite release or script update.
Getting Started
- Prepare Sandbox: Populate with POs reflecting open, partially received, closed, and high-line-count (10+ lines) scenarios.
- Deploy Suitelet: Deploy via Customization > Scripts > New, ensuring correct permissions and SuiteScript linkage.
- Engage Users: Train procurement teams on Suitelet features (e.g., filtering, triggering scripts) for effective usability testing.
- Automate Tests: Use testRigor or Selenium with NetSuite’s REST API to automate functional, regression, and performance tests.
- Document Results: Log test outcomes, defects, and feedback in Jira or Zephyr, categorizing by test case and severity.
Best Practices
- UI Design: Use SuiteScript 2.x ServerWidget to create responsive, filterable displays with sortable columns and status indicators.
- Security: Restrict Suitelet access to authorized roles and sanitize all inputs to prevent injection attacks.
- Performance: Optimize data retrieval with SuiteQL or Saved Searches, testing with concurrent users for scalability.
- Usability: Incorporate user feedback to refine UI elements, ensuring clear visual cues for PO statuses.
- Regression Testing: Automate test suites to ensure stability post-updates, scheduling tests after NetSuite’s biannual releases.
Conclusion
Testing the Suitelet page for the NetSuite SuiteScript customization ensures a secure, efficient, and user-friendly interface for managing PO updates. By defining a clear testing scope and applying rigorous verification steps across functional, usability, security, performance, and regression testing, teams can deliver a reliable tool that enhances procurement workflows. This approach ensures the Suitelet meets business needs and performs robustly in NetSuite’s dynamic environment.