Testing Error Handling and Logging for NetSuite SuiteScript PO Customization

Overview

This Knowledge Base article provides a comprehensive guide for testing the error handling and logging mechanisms of a NetSuite scheduled SuiteScript customization designed to automate the update of the Current Expected Receipt Date for Purchase Order (PO) lines using internal NetSuite logic (e.g., calculations based on vendor lead times, transaction dates, or custom business rules). The SuiteScript processes POs, updates eligible lines, skips ineligible lines, and generates detailed logs to track execution and errors. This guide details the scope of testing, outlines testing types and techniques focused on error handling and logging, and provides verification steps to ensure robust error management, log clarity, performance under error conditions, security of logs, and regression testing, addressing test cases TC_001 to TC_010 where applicable. Testing is conducted at 02:08 PM IST on June 30, 2025, in a NetSuite sandbox environment.

Scope of SuiteScript Testing

The scope of testing the SuiteScript’s error handling and logging includes:

  • Error Handling Validation: Ensure the SuiteScript gracefully handles errors (e.g., invalid PO data, missing vendor lead times, governance limits) without crashing and logs meaningful error messages.
  • Log Clarity and Accessibility: Confirm logs are clear, detailed, and accessible to authorized users via NetSuite’s Script Execution Log or custom records, aiding troubleshooting and auditing.
  • Performance Under Errors: Validate the script’s performance when encountering errors, ensuring efficient processing of large POs despite issues.
  • Security of Logs: Verify that logs do not expose sensitive data and are accessible only to authorized roles.
  • Regression Testing: Ensure error handling and logging remain consistent after script updates or NetSuite releases.
  • Test Case Coverage: Address TC_001 to TC_010 to validate error handling for various PO scenarios (e.g., open, closed, partially received, high-line-count POs).
  • Exclusions: Testing excludes external API integrations, as the SuiteScript relies solely on internal NetSuite data (e.g., PO status, vendor records, custom fields). Suitelet page testing is also excluded.
  • Environment: Tests are conducted in a NetSuite sandbox to simulate real-world procurement scenarios without impacting production.

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 Current Expected Receipt Date is not updated 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. Error Handling Testing

Purpose: Validate that the SuiteScript handles errors gracefully and logs them appropriately (TC_001, TC_002, TC_009).

Steps:

  • TC_001: Deploy the SuiteScript and introduce an error by creating a PO with missing vendor lead time data. Run the script and verify it skips the invalid PO without crashing.
  • TC_002: Create a PO with open lines but corrupt date fields (e.g., invalid format). Run the SuiteScript and check if it logs the error and continues processing other lines.
  • TC_009: Create a PO with 20 lines, including one with invalid data (e.g., null quantity). Run the script and confirm it processes valid lines and logs errors for invalid ones. Verification Steps:
  • Check the Script Execution Log (Customization > Scripting > Script Executions) for specific error messages (e.g., “Missing lead time for PO #123, skipped”).
  • Use a Transaction Line Fields search to confirm valid lines are updated (e.g., 19/20 lines updated for TC_009).
  • Verify the script completes without exceeding NetSuite governance limits (<10,000 units), checked via SuiteAnalytics.
  • Confirm no PO records are corrupted, using Saved Search to validate data integrity. Tools: Script Execution Log, Saved Search, SuiteAnalytics, SuiteCloud CLI. Best Practice: Implement try-catch blocks in the SuiteScript to handle errors and log detailed messages with PO IDs and error types.

2. Log Clarity and Accessibility Testing

Purpose: Ensure logs are clear, detailed, and accessible to authorized users for troubleshooting (TC_005, TC_006, TC_008).

Steps:

  • TC_005: Create a “Partially Received” PO, run the SuiteScript, and verify logs indicate which lines were updated or skipped.
  • TC_006: Test a PO with open and closed lines. Confirm logs clearly differentiate updated (open) and skipped (closed) lines.
  • TC_008: Close a PO using the “Close” button, run the SuiteScript, and verify logs explicitly state “PO closed, no updates applied.” Verification Steps:
  • Check Script Execution Log for clear entries (e.g., “Updated 5 lines, skipped 3 closed lines in PO #123”).
  • Verify logs are accessible via Customization > Scripting > Script Executions for authorized roles (e.g., Administrator).
  • Confirm log messages are concise yet detailed, with PO and line IDs included, validated manually.
  • Ensure log retrieval time is <2 seconds using SuiteAnalytics. Tools: Script Execution Log, SuiteAnalytics, Zephyr for feedback. Best Practice: Use NetSuite’s log.debug and log.error methods to categorize log entries, ensuring clarity for procurement teams.

3. Security Testing for Logs

Purpose: Ensure logs are secure and accessible only to authorized roles (TC_001).

Steps:

  • TC_001: Deploy the SuiteScript with execution restricted to an Administrator role. Test with unauthorized roles (e.g., Viewer) to confirm they cannot access logs.
  • Data Security: Introduce an error (e.g., invalid PO data) and verify logs do not expose sensitive data (e.g., vendor payment terms). Verification Steps:
  • Confirm via Setup > Users/Roles > Manage Roles that only authorized roles access logs, with 0% unauthorized access success.
  • Use Script Execution Log to verify no sensitive data (e.g., vendor details) is logged, ensuring compliance with data privacy standards.
  • Check that log entries for errors are sanitized (e.g., “Invalid data in PO #123” instead of raw data).
  • Validate log access respects NetSuite permissions, tested via role-based login. Tools: NetSuite Role Permissions, Script Execution Log, SuiteCloud CLI. Best Practice: Restrict log access to specific roles and avoid logging sensitive fields in SuiteScript.

4. Performance Testing Under Error Conditions

Purpose: Validate the SuiteScript’s efficiency when handling errors in high-line-count POs (TC_009, TC_010).

Steps:

  • TC_009: Create a PO with 25 lines, including 5 with errors (e.g., missing lead times). Run the SuiteScript and measure processing time.
  • TC_010: Test a PO with 15 lines, ensuring all eligible lines are updated despite errors in 2-3 lines. Verification Steps:
  • Confirm execution time is <10 seconds for a 25-line PO, verified via Script Execution Log.
  • Use SuiteAnalytics to ensure resource usage (e.g., CPU <70%) during error handling.
  • Verify 20/25 lines are updated correctly for TC_009 via Saved Search, with errors logged for the 5 invalid lines.
  • Confirm all eligible lines (e.g., 12/15 for TC_010) are updated, cross-checked with Transaction Line Fields search. Tools: SuiteAnalytics, Saved Search, JMeter for load simulation. Best Practice: Optimize error handling to minimize performance impact, retesting after script optimizations.

5. Regression Testing

Purpose: Ensure error handling and logging remain consistent after updates or NetSuite releases (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 logs indicate no updates.
  • TC_004: Test a PO with closed lines, confirming logs show skips.
  • TC_005: For a “Partially Received” PO, verify logs indicate updates for open lines only.
  • TC_006: Test a PO with open and closed lines, ensuring logs reflect selective updates.
  • TC_007: For a PO with received and closed lines, confirm logs show no updates.
  • TC_008: Close a PO using the “Close” button and verify logs indicate no updates. Verification Steps:
  • Use Transaction Line Fields search to confirm no updates for ineligible lines, ensuring 100% accuracy.
  • Check Script Execution Log for consistent skip messages (e.g., “Skipped 5 closed lines”).
  • Run automated regression tests in testRigor, targeting 100% pass rate.
  • Log any new defects in Jira, ensuring no regression from baseline tests. Tools: testRigor, Jira, Script Execution Log. Best Practice: Maintain a regression test suite in Zephyr, re-running tests after NetSuite’s biannual releases.

Getting Started

  • Prepare Sandbox: Populate with POs reflecting open, partially received, closed, and high-line-count (10+ lines) scenarios via Customization > Transactions > Purchase Orders.
  • Deploy SuiteScript: Deploy via Customization > Scripts > New, ensuring error handling and logging are implemented (e.g., try-catch blocks, log.error).
  • Engage Users: Train procurement teams to review logs for usability validation, scheduling 1-hour feedback sessions.
  • Automate Tests: Use testRigor or Selenium with NetSuite’s REST API to automate error handling, logging, and regression tests, targeting 90% automation coverage.
  • Document Results: Log test outcomes, defects, and feedback in Jira or Zephyr, categorizing by test case and severity (e.g., critical for error crashes, minor for unclear logs).

Best Practices

  • Error Handling: Use try-catch blocks to manage errors and implement retry logic for transient issues (e.g., temporary data locks).
  • Logging: Log detailed messages with PO and line IDs, using log.debug for successes and log.error for failures to aid troubleshooting.
  • Security: Restrict log access to authorized roles and sanitize logs to exclude sensitive data.
  • Performance: Optimize error handling to avoid excessive governance unit consumption, testing with large datasets.
  • Regression Testing: Automate test suites to ensure error handling and logging stability post-updates.

Conclusion

Testing the error handling and logging of the NetSuite SuiteScript customization ensures robust performance, clear troubleshooting, and secure data management for PO updates. By defining a clear testing scope and applying rigorous verification steps across error handling, log clarity, security, performance, and regression testing, teams can deliver a reliable script that supports procurement workflows. This approach guarantees the SuiteScript operates effectively in NetSuite’s dynamic environment, minimizing disruptions and enhancing auditability.

Leave a comment

Your email address will not be published. Required fields are marked *