[Transceiver onboarding] Add EEPROM, System and DOM test attributes in HLD by mihirpat1 · Pull Request #20359 · sonic-net/sonic-mgmt

mihirpat1 · 2025-08-21T21:17:38Z

Description of PR

We need to capture the required attributes for EEPROM, System and DOM tests for various transceivers in the HLD.
Also, we should create a child page for each of these test categories to capture the required attributes and the tests

This PR should be merged after the below PR is merged
#20230

Summary:
Fixes # (issue)

Type of change

Back port request

Approach

What is the motivation for this PR?

How did you do it?

How did you verify/test it?

Any platform specific information?

Supported testbed topology if it's a new test case?

Documentation

ADO - 34513966

mssonicbld · 2025-08-21T21:17:46Z

/azp run

azure-pipelines · 2025-08-21T21:17:54Z

Azure Pipelines could not run because the pipeline triggers exclude this branch/path.

mssonicbld · 2025-08-22T01:27:55Z

/azp run

azure-pipelines · 2025-08-22T01:28:03Z

Azure Pipelines could not run because the pipeline triggers exclude this branch/path.

Copilot

Pull Request Overview

This PR adds required EEPROM and System test attributes in the HLD by creating two new child pages that detail the test categories and their required attributes. The changes restructure the existing transceiver onboarding test plan to organize tests into separate categories.

Creates dedicated test plans for EEPROM and System testing with comprehensive attribute definitions
Reorganizes existing test content by moving system-level tests from the main HLD to a dedicated system test plan
Adds new CLI command documentation for read-eeprom and write-eeprom functionality

Reviewed Changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 4 comments.

File	Description
docs/testplan/transceiver_onboarding_test_plan.md	Reorganizes content by removing detailed system tests and adding new CLI command documentation
docs/testplan/transceiver/system_test_plan.md	New comprehensive system test plan with attributes table and detailed test cases
docs/testplan/transceiver/eeprom_test_plan.md	New EEPROM test plan with attributes table and test validation procedures

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

docs/testplan/transceiver/system_test_plan.md

docs/testplan/transceiver/eeprom_test_plan.md

docs/testplan/transceiver/system_test_plan.md

mssonicbld · 2025-08-22T01:31:26Z

/azp run

azure-pipelines · 2025-08-22T01:31:34Z

Azure Pipelines could not run because the pipeline triggers exclude this branch/path.

mssonicbld · 2025-08-22T01:33:40Z

/azp run

azure-pipelines · 2025-08-22T01:33:49Z

Azure Pipelines could not run because the pipeline triggers exclude this branch/path.

mssonicbld · 2025-08-22T01:34:37Z

/azp run

azure-pipelines · 2025-08-22T01:34:45Z

Azure Pipelines could not run because the pipeline triggers exclude this branch/path.

mssonicbld · 2025-08-22T23:08:54Z

/azp run

azure-pipelines · 2025-08-22T23:09:02Z

Azure Pipelines could not run because the pipeline triggers exclude this branch/path.

mihirpat1 · 2025-08-22T23:09:54Z

@az-pz @AnoopKamath, @bobby-nexthop @Junchao-Mellanox @roy-sror Can you please help in reviewing this PR?

mssonicbld · 2025-08-24T23:02:15Z

/azp run

azure-pipelines · 2025-08-24T23:02:22Z

Azure Pipelines could not run because the pipeline triggers exclude this branch/path.

az-pz · 2025-08-25T17:07:22Z

docs/testplan/transceiver/eeprom_test_plan.md

+
+1. Verify all transceivers are in original operational state
+2. Check system logs for any unexpected errors or kernel messages
+3. Verify xcvrd daemon uptime has not changed (no crashes/restarts)


Do you mean daemon process id here?

@az-pz Thanks for catching this. I have now corrected this.

az-pz · 2025-08-25T18:06:29Z

docs/testplan/transceiver/system_test_plan.md

+
+### Recommended Test Order
+
+The following execution order is recommended to minimize system disruption and ensure reliable test results:


Aren't the tests run serially on the dut? And shouldn't they be independent of each other? I am confused about why we need to specify the desired order of test execution.

@az-pz This is just a recommended test order and not mandatory.
I mentioned this to ensure that the system disruption is minimal.
However, if you think that this confusing, I can remove this.

mssonicbld · 2025-08-28T23:13:49Z

/azp run

azure-pipelines · 2025-08-28T23:13:57Z

Azure Pipelines could not run because the pipeline triggers exclude this branch/path.

mssonicbld · 2025-09-03T22:48:26Z

/azp run

azure-pipelines · 2025-09-03T22:48:34Z

Azure Pipelines could not run because the pipeline triggers exclude this branch/path.

yishuzh · 2026-02-26T20:04:18Z

docs/testplan/transceiver/system_test_plan.md

+
+### Diagnostic Test Cases
+
+| TC No. | Test | Steps | Expected Results |


Loopback validation should be a scenario test

yishuzh · 2026-02-26T23:16:38Z

docs/testplan/transceiver/system_test_plan.md

+
+| TC No. | Test | Steps | Expected Results |
+|------|------|------|------------------|
+| 1 | C-CMIS frequency adjustment validation | 1. Skip test if `frequency_values` is empty or not defined.<br>2. Execute **State Preservation and Restoration** (capture phase).<br>3. Capture current frequency configuration from CONFIG_DB and STATE_DB.<br>4. For each frequency value in `frequency_values` (starting from index 1, skipping default):<br>   a. Apply frequency using `config interface transceiver frequency <port> <frequency>`.<br>   b. Wait for `port_startup_wait_sec`.<br>   c. Verify frequency is set correctly in CONFIG_DB and STATE_DB.<br>   d. Execute **Standard Port Recovery and Verification Procedure**.<br>5. Restore original frequency (first value in `frequency_values`).<br>6. Wait for `port_startup_wait_sec` and verify restoration.<br>7. Execute **Standard Port Recovery and Verification Procedure**.<br>8. Execute **State Preservation and Restoration** (restoration phase). | Ensure C-CMIS transceiver frequency can be adjusted to supported values and restored to original frequency. Port should remain stable throughout frequency changes with all verification checks passing. |


The frequency adjustment validation and Tx power adjustment validation need to be included in the higher level test - You need to confirm that the frequency adjustment and Tx power adjustment actually works, and that will be read from the remote side optics.

yishuzh · 2026-02-26T23:27:05Z

docs/testplan/transceiver/test_plan.md

Please separate the word "test plan" to different meanings:

Scenario of your test, such as shut/noshut, reset, etc.

Attributes to check, like DOM, VDM, etc.

This file is more like modular test design rather than transceiver onboarding test plan.

@yishuzh I have addressed this now.
Overall, I plan to create a separate PR in the future to capture details on the scenario based testing.
For now, I will keep the current PR to be modular test design.

docs/testplan/transceiver/test_plan.md

yishuzh · 2026-02-26T23:30:09Z

docs/testplan/transceiver/test_plan.md

 - `eeprom.json` (EEPROM tests)
 - `system.json` (System tests)  
 - `physical_oir.json` (Physical OIR)
 - `remote_reseat.json` (remote reseat)


physical_oir and remote_reseat should be scenarios, not the same level of attribute checks as system/eeprom,

yishuzh · 2026-02-26T23:30:32Z

docs/testplan/transceiver/test_plan.md

 - `cdb_fw_upgrade.json` (CDB FW Upgrade tests)
 - `dom.json` (DOM)
 - `vdm.json` (VDM)
 - `pm.json` (PM)


Please add the TP5 check and the VDM flag checks.

@yishuzh We haven't created a testplan for VDM and PM validation yet. Will add the details while creating the corresponding testplan

mssonicbld · 2026-03-05T01:01:56Z

/azp run

azure-pipelines · 2026-03-05T01:02:04Z

Azure Pipelines could not run because the pipeline triggers exclude this branch/path.

…d tests Signed-off-by: Mihir Patel <patelmi@microsoft.com>

mssonicbld · 2026-03-05T01:04:31Z

/azp run

azure-pipelines · 2026-03-05T01:04:39Z

Azure Pipelines could not run because the pipeline triggers exclude this branch/path.

Signed-off-by: Mihir Patel <patelmi@microsoft.com>

mssonicbld · 2026-03-05T01:41:54Z

/azp run

azure-pipelines · 2026-03-05T01:42:02Z

Azure Pipelines could not run because the pipeline triggers exclude this branch/path.

bfoo-msft · 2026-03-07T00:31:15Z

docs/testplan/transceiver/dom_test_plan.md

+| 1 | DOM data availability verification | 1. Access DOM data from `TRANSCEIVER_DOM_SENSOR` table in STATE_DB for each port.<br>2. Verify `last_update_time` is within `data_max_age_min` minutes of current time to ensure data freshness.<br>3. Dynamically determine expected DOM fields based on attributes present in `dom.json` using the [Dynamic Field Mapping Algorithm](#dynamic-field-mapping-algorithm).<br>4. Validate presence of all dynamically determined expected fields in STATE_DB.<br>5. Skip validation for fields whose corresponding attributes are absent from `dom.json`. | All DOM fields corresponding to configured attributes are present and accessible from STATE_DB. DOM data is successfully retrieved without errors for all attribute-driven fields. Lane-specific fields are automatically expanded for all available lanes (1 to N) based on the `LANE_NUM` placeholder. Field expectations are dynamically derived using the mapping algorithm. Data freshness is confirmed with recent `last_update_time` timestamp. |
+| 2 | DOM sensor operational range validation | 1. Retrieve DOM sensor data from STATE_DB.<br>2. Verify `last_update_time` is within `data_max_age_min` minutes of current time to ensure data freshness.<br>3. For each attribute ending with `_operational_range` present in `dom.json`, validate the corresponding field(s) in STATE_DB using the [Dynamic Field Mapping Algorithm](#dynamic-field-mapping-algorithm).<br>4. Check that sensor values fall within the configured operational range.<br>5. Fail the test case if any values fall outside their respective operational ranges.<br>6. Log detailed information about any out-of-range values including actual vs expected ranges.<br>7. Only validate fields derived from attributes present in `dom.json`. | All DOM sensor values fall within their respective operational ranges during normal operation (only for parameters with configured operational range attributes). Test case fails if any sensor values fall outside their configured operational ranges. Data freshness is confirmed before validation. Lane-specific validation automatically performed for all available lanes using the `LANE_NUM` placeholder expansion. Parameter validation is dynamically determined from attribute table. Detailed logging provided for any out-of-range conditions. |
+| 3 | DOM threshold validation | 1. Retrieve threshold data from `TRANSCEIVER_DOM_THRESHOLD` table in STATE_DB.<br>2. Dynamically determine expected threshold fields based on attributes ending with `_threshold_range` present in `dom.json` using the [Dynamic Field Mapping Algorithm](#dynamic-field-mapping-algorithm).<br>3. For each determined threshold field, validate threshold data completeness by checking for corresponding alarm and warning thresholds (highalarm, lowalarm, highwarning, lowwarning).<br>4. Compare configured threshold ranges via attributes with thresholds values from DB and validate logical hierarchy (lowalarm < lowwarning < highwarning < highalarm).<br>5. For parameters that have both operational and threshold range attributes, validate that operational ranges fall within warning thresholds (lowwarning < operational_min and operational_max < highwarning).<br>6. Only validate threshold fields derived from attributes present in `dom.json`. | All threshold values are present and follow logical hierarchy. EEPROM thresholds align with configured threshold ranges when present. Operational ranges are properly positioned within warning threshold boundaries to ensure appropriate alarm behavior. Threshold data integrity is maintained in STATE_DB. Threshold validation is performed at transceiver level (no lane-specific expansion). Threshold validation is dynamically determined from attribute table. |
+| 4 | DOM data consistency verification | 1. Read DOM data `consistency_check_poll_count` times with `max_update_time_sec` intervals between readings.<br>2. Verify data consistency between readings.<br>3. Check that `last_update_time` field is being updated correctly with each polling cycle.<br>4. Validate that sensor readings show expected behavior (e.g., temperature variations within reasonable limits). | DOM data shows consistent and reasonable variations between polling intervals over `consistency_check_poll_count` polling cycles. The `last_update_time` field is properly updated with each polling cycle. No erratic or impossible sensor value changes are observed during the monitoring period. Variation patterns indicate stable DOM monitoring system operation. |


Is there an attribute that defines a maximum percentage change for DOM data consistency? Or is this only defined by the initial attribute list?

@bfoo-msft This is only defined by the initial attribute list

bfoo-msft · 2026-03-07T01:34:57Z

docs/testplan/transceiver/system_test_plan.md

+
+- **State Preservation**: Before each test that modifies transceiver settings (e.g., loopback modes, low power mode, Tx disable), the original state should be captured
+- **State Reversion**: After each test completion (pass or fail), the transceiver should be reverted to its original operational state
+- **Cleanup on Failure**: If a test fails during execution, cleanup procedures should still attempt to restore the original state to prevent impact on subsequent tests


Is there any scope to add an 'abort on clean-up failure' state to prevent clean-up procedure failure from impacting subsequent tests? Or should that be addressed by the new test not starting in its expected state and so immediately throwing an error?

@bfoo-msft This should be addressed via
https://github.com/sonic-net/sonic-mgmt/blob/master/docs/testplan/transceiver/system_test_plan.md#test-cases

bfoo-msft · 2026-03-07T01:48:28Z

docs/testplan/transceiver/system_test_plan.md

+
+| TC No. | Test | Steps | Expected Results |
+|------|------|------|------------------|
+| 1 | Port shutdown validation | 1. For each transceiver port individually:<br>   a. Issue `config interface shutdown <port>`.<br>   b. Wait for `port_shutdown_wait_sec`.<br>   c. Verify port is operationally down.<br>2. Validate link status using CLI configuration. | Ensure that the link goes down within the configured timeout period for each port. |


Should we also confirm that the Redis DB state is in sync with the CLI output?

@bfoo-msft The CLI to check the interface status reads data from the redis-db. Do you still want to add a step to verify data from the redis-db too?

bfoo-msft · 2026-03-07T01:52:54Z

docs/testplan/transceiver/system_test_plan.md

+| TC No. | Test | Steps | Expected Results |
+|------|------|------|------------------|
+| 1 | xcvrd daemon restart impact | 1. Verify current link states to be up for all transceivers and record the link up time.<br>2. Restart xcvrd daemon.<br>3. Wait for `xcvrd_restart_settle_sec` before verification.<br>4. Execute **Standard Port Recovery and Verification Procedure** for all ports. | Confirm `xcvrd` restarts successfully without causing link flaps for the corresponding ports, and all verification checks pass. Also ensure that xcvrd is up for at least `xcvrd_restart_settle_sec` seconds. |
+| 2 | xcvrd restart with I2C errors | 1. Verify current link states to be up for all transceivers and record the link up time.<br>2. Induce I2C errors in the system.<br>3. Restart xcvrd daemon.<br>4. Monitor link behavior and system stability.<br>5. Wait for `xcvrd_restart_settle_sec` before verification.<br>6. Execute **Standard Port Recovery and Verification Procedure** for all ports. | Confirm `xcvrd` restarts successfully without causing link flaps for the corresponding ports, and all verification checks pass even with I2C errors present. |


Could you please clarify how you intend to induce I2C (or other management channel communication) errors into the system? Will this be a generic method, or will it be platform specific?

bfoo-msft · 2026-03-07T02:06:07Z

docs/testplan/transceiver/system_test_plan.md

+| 4 | Fast reboot link recovery | 1. Skip test if `fast_reboot_supported` is False.<br>2. Verify current link states to be up for all transceivers.<br>3. Perform fast reboot.<br>4. Wait for `fast_reboot_settle_sec` and monitor link establishment timing.<br>5. Execute **Standard Port Recovery and Verification Procedure** for all ports. | Confirm all ports link up again post-reboot and pass comprehensive verification checks. |
+| 5 | Power cycle link recovery | 1. Skip test if `power_cycle_supported` is False.<br>2. Verify current link states are up for all transceivers.<br>3. Perform a controlled chassis power cycle.<br>4. Wait for `power_cycle_settle_sec` and monitor link recovery after full boot.<br>5. Execute **Standard Port Recovery and Verification Procedure** for all ports. | Confirm all ports link up again post-power cycle and pass comprehensive verification checks (link status, LLDP, CMIS states, SI settings, application code if defined, docker and process stability). |
+
+### Transceiver Event Handling Test Cases


Most of the tests in this section should include telemetry collection when the link is in the 'down' state.

bfoo-msft · 2026-03-07T02:12:40Z

docs/testplan/transceiver/system_test_plan.md

+| 1 | C-CMIS frequency adjustment validation | 1. Skip test if `frequency_values` is empty or not defined.<br>2. Execute **State Preservation and Restoration** (capture phase).<br>3. Capture current frequency configuration from CONFIG_DB and STATE_DB.<br>4. For each frequency value in `frequency_values` (starting from index 1, skipping default):<br>   a. Apply frequency using `config interface transceiver frequency <port> <frequency>`.<br>   b. Wait for `port_startup_wait_sec`.<br>   c. Verify frequency is set correctly in CONFIG_DB and STATE_DB.<br>   d. Execute **Standard Port Recovery and Verification Procedure**.<br>5. Restore original frequency (first value in `frequency_values`).<br>6. Wait for `port_startup_wait_sec` and verify restoration.<br>7. Execute **Standard Port Recovery and Verification Procedure**.<br>8. Execute **State Preservation and Restoration** (restoration phase). | Ensure C-CMIS transceiver frequency can be adjusted to supported values and restored to original frequency. Port should remain stable throughout frequency changes with all verification checks passing. |
+| 2 | C-CMIS tx power adjustment validation | 1. Skip test if `tx_power_values` is empty or not defined.<br>2. Execute **State Preservation and Restoration** (capture phase).<br>3. Capture current tx power configuration from CONFIG_DB and STATE_DB.<br>4. For each tx power value in `tx_power_values` (starting from index 1, skipping default):<br>   a. Apply tx power using `config interface transceiver tx-power <port> <tx_power>`.<br>   b. Wait for `port_startup_wait_sec`.<br>   c. Verify tx power is set correctly in CONFIG_DB and STATE_DB.<br>   d. Execute **Standard Port Recovery and Verification Procedure**.<br>5. Restore original tx power (first value in `tx_power_values`).<br>6. Wait for `port_startup_wait_sec` and verify restoration.<br>7. Execute **Standard Port Recovery and Verification Procedure**.<br>8. Execute **State Preservation and Restoration** (restoration phase). | Ensure C-CMIS transceiver tx power can be adjusted to supported values and restored to original tx power. Port should remain stable throughout power changes with all verification checks passing. |
+
+### Stress and Load Test Cases


It is not sufficient to only check the link state during the stress test. You also need to perform data collection of relevant DOM and VDM parameters at each step, including when the link is 'down'

bfoo-msft · 2026-03-07T02:21:32Z

docs/testplan/transceiver/dom_test_plan.md

+
+| TC No. | Test | Steps | Expected Results |
+|------|------|------|------------------|
+| 1 | DOM data availability verification | 1. Access DOM data from `TRANSCEIVER_DOM_SENSOR` table in STATE_DB for each port.<br>2. Verify `last_update_time` is within `data_max_age_min` minutes of current time to ensure data freshness.<br>3. Dynamically determine expected DOM fields based on attributes present in `dom.json` using the [Dynamic Field Mapping Algorithm](#dynamic-field-mapping-algorithm).<br>4. Validate presence of all dynamically determined expected fields in STATE_DB.<br>5. Skip validation for fields whose corresponding attributes are absent from `dom.json`. | All DOM fields corresponding to configured attributes are present and accessible from STATE_DB. DOM data is successfully retrieved without errors for all attribute-driven fields. Lane-specific fields are automatically expanded for all available lanes (1 to N) based on the `LANE_NUM` placeholder. Field expectations are dynamically derived using the mapping algorithm. Data freshness is confirmed with recent `last_update_time` timestamp. |


Can we also add a 'performance' type test to characterize the statistics for DOM 'freshness'? Something like 'poll DOM every X seconds for Y minutes' and build a profile for how often the DOM (or any telemetry) are updated? We could ensure that all data are within 'data_max_age_min' as a 'barndoor' spec, but ensuring that telemetry polling times remain consistent between image releases (or at least quantifying any changes) would be useful

…n HLD (sonic-net#20359) * Add and Refine Transceiver EEPROM Test Plan Documentation Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Added system test plan Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Update docs/testplan/transceiver/system_test_plan.md Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Corrected loopback usage Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Signed-off-by: Mihir Patel <patelmi@microsoft.com> * read-eeprom typo correction Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Add more TCs for system test Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Corrected typo Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Added link stability test Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Added DOM test plan Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Enhanced EEPROM and DOM TCs Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Added an example of dom.json Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Added stress test for fast and warm reboot Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Addressed PR comments Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Added test case for power cycling the chassis Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Added Tx LOS verification during shut/no shut testing Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Enhanced DOM config related test Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Added TC for serial number validation, speed config validation and RS FEC validation Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Changed mandatory column terminology Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Removed unrelated files Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Fixed heading levels in test_plan.md and the corresponding section links Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Addressed PR comments Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Modified sections in test_plan.md to depcit modular and scenario based tests Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Added note for topology Signed-off-by: Mihir Patel <patelmi@microsoft.com> --------- Signed-off-by: Mihir Patel <patelmi@microsoft.com> Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

…n HLD (sonic-net#20359) * Add and Refine Transceiver EEPROM Test Plan Documentation Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Added system test plan Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Update docs/testplan/transceiver/system_test_plan.md Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Corrected loopback usage Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Signed-off-by: Mihir Patel <patelmi@microsoft.com> * read-eeprom typo correction Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Add more TCs for system test Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Corrected typo Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Added link stability test Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Added DOM test plan Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Enhanced EEPROM and DOM TCs Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Added an example of dom.json Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Added stress test for fast and warm reboot Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Addressed PR comments Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Added test case for power cycling the chassis Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Added Tx LOS verification during shut/no shut testing Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Enhanced DOM config related test Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Added TC for serial number validation, speed config validation and RS FEC validation Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Changed mandatory column terminology Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Removed unrelated files Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Fixed heading levels in test_plan.md and the corresponding section links Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Addressed PR comments Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Modified sections in test_plan.md to depcit modular and scenario based tests Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Added note for topology Signed-off-by: Mihir Patel <patelmi@microsoft.com> --------- Signed-off-by: Mihir Patel <patelmi@microsoft.com> Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Signed-off-by: Mihut Aronovici <aronovic@cisco.com>

…n HLD (sonic-net#20359) * Add and Refine Transceiver EEPROM Test Plan Documentation Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Added system test plan Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Update docs/testplan/transceiver/system_test_plan.md Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Corrected loopback usage Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Signed-off-by: Mihir Patel <patelmi@microsoft.com> * read-eeprom typo correction Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Add more TCs for system test Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Corrected typo Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Added link stability test Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Added DOM test plan Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Enhanced EEPROM and DOM TCs Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Added an example of dom.json Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Added stress test for fast and warm reboot Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Addressed PR comments Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Added test case for power cycling the chassis Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Added Tx LOS verification during shut/no shut testing Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Enhanced DOM config related test Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Added TC for serial number validation, speed config validation and RS FEC validation Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Changed mandatory column terminology Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Removed unrelated files Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Fixed heading levels in test_plan.md and the corresponding section links Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Addressed PR comments Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Modified sections in test_plan.md to depcit modular and scenario based tests Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Added note for topology Signed-off-by: Mihir Patel <patelmi@microsoft.com> --------- Signed-off-by: Mihir Patel <patelmi@microsoft.com> Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Signed-off-by: selldinesh <dinesh.sellappan@keysight.com>

…n HLD (sonic-net#20359) * Add and Refine Transceiver EEPROM Test Plan Documentation Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Added system test plan Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Update docs/testplan/transceiver/system_test_plan.md Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Corrected loopback usage Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Signed-off-by: Mihir Patel <patelmi@microsoft.com> * read-eeprom typo correction Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Add more TCs for system test Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Corrected typo Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Added link stability test Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Added DOM test plan Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Enhanced EEPROM and DOM TCs Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Added an example of dom.json Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Added stress test for fast and warm reboot Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Addressed PR comments Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Added test case for power cycling the chassis Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Added Tx LOS verification during shut/no shut testing Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Enhanced DOM config related test Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Added TC for serial number validation, speed config validation and RS FEC validation Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Changed mandatory column terminology Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Removed unrelated files Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Fixed heading levels in test_plan.md and the corresponding section links Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Addressed PR comments Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Modified sections in test_plan.md to depcit modular and scenario based tests Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Added note for topology Signed-off-by: Mihir Patel <patelmi@microsoft.com> --------- Signed-off-by: Mihir Patel <patelmi@microsoft.com> Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Signed-off-by: Abhishek <abhishek@nexthop.ai>

…n HLD (sonic-net#20359) * Add and Refine Transceiver EEPROM Test Plan Documentation Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Added system test plan Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Update docs/testplan/transceiver/system_test_plan.md Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Corrected loopback usage Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Signed-off-by: Mihir Patel <patelmi@microsoft.com> * read-eeprom typo correction Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Add more TCs for system test Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Corrected typo Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Added link stability test Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Added DOM test plan Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Enhanced EEPROM and DOM TCs Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Added an example of dom.json Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Added stress test for fast and warm reboot Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Addressed PR comments Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Added test case for power cycling the chassis Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Added Tx LOS verification during shut/no shut testing Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Enhanced DOM config related test Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Added TC for serial number validation, speed config validation and RS FEC validation Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Changed mandatory column terminology Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Removed unrelated files Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Fixed heading levels in test_plan.md and the corresponding section links Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Addressed PR comments Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Modified sections in test_plan.md to depcit modular and scenario based tests Signed-off-by: Mihir Patel <patelmi@microsoft.com> * Added note for topology Signed-off-by: Mihir Patel <patelmi@microsoft.com> --------- Signed-off-by: Mihir Patel <patelmi@microsoft.com> Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Signed-off-by: Venkata Gouri Rajesh Etla <vrajeshe@cisco.com>

mihirpat1 requested review from wangxin and yxieca as code owners August 21, 2025 21:17

mihirpat1 mentioned this pull request Aug 21, 2025

[sonic-mgmt] Update transceiver onboarding HLD to make parameters attribute based #20230

Merged

11 tasks

mihirpat1 requested a review from Copilot August 22, 2025 01:28

Copilot AI reviewed Aug 22, 2025

View reviewed changes

mihirpat1 requested a review from Copilot August 22, 2025 23:08

mihirpat1 requested review from Junchao-Mellanox and prgeor August 22, 2025 23:09

az-pz reviewed Aug 25, 2025

View reviewed changes

This comment was marked as outdated.

Sign in to view

mihirpat1 changed the title ~~[Transceiver onboarding] Add EEPROM and System test attributes in HLD~~ [Transceiver onboarding] Add EEPROM, System and DOM test attributes in HLD Sep 3, 2025

yishuzh reviewed Feb 26, 2026

View reviewed changes

docs/testplan/transceiver/test_plan.md Show resolved Hide resolved

yishuzh reviewed Feb 26, 2026

View reviewed changes

Modified sections in test_plan.md to depcit modular and scenario base…

2bcae4b

…d tests Signed-off-by: Mihir Patel <patelmi@microsoft.com>

mihirpat1 force-pushed the eeprom-and-system-test-plan-doc-update branch from f6d4b81 to 2bcae4b Compare March 5, 2026 01:04

Added note for topology

33d0db7

Signed-off-by: Mihir Patel <patelmi@microsoft.com>

bfoo-msft reviewed Mar 7, 2026

View reviewed changes

prgeor approved these changes Mar 7, 2026

View reviewed changes

prgeor merged commit 1ec82bb into sonic-net:master Mar 7, 2026
6 checks passed

bfoo-msft reviewed Mar 7, 2026

View reviewed changes


		### Recommended Test Order

		The following execution order is recommended to minimize system disruption and ensure reliable test results:


		### Diagnostic Test Cases

		\| TC No. \| Test \| Steps \| Expected Results \|

Conversation

mihirpat1 commented Aug 21, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description of PR

Type of change

Back port request

Approach

What is the motivation for this PR?

How did you do it?

How did you verify/test it?

Any platform specific information?

Supported testbed topology if it's a new test case?

Documentation

Uh oh!

mssonicbld commented Aug 21, 2025

Uh oh!

azure-pipelines bot commented Aug 21, 2025

Uh oh!

mssonicbld commented Aug 22, 2025

Uh oh!

azure-pipelines bot commented Aug 22, 2025

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull Request Overview

Reviewed Changes

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

mssonicbld commented Aug 22, 2025

Uh oh!

azure-pipelines bot commented Aug 22, 2025

Uh oh!

mssonicbld commented Aug 22, 2025

Uh oh!

azure-pipelines bot commented Aug 22, 2025

Uh oh!

mssonicbld commented Aug 22, 2025

Uh oh!

azure-pipelines bot commented Aug 22, 2025

Uh oh!

mssonicbld commented Aug 22, 2025

Uh oh!

azure-pipelines bot commented Aug 22, 2025

Uh oh!

mihirpat1 commented Aug 22, 2025

Uh oh!

mssonicbld commented Aug 24, 2025

Uh oh!

azure-pipelines bot commented Aug 24, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

This comment was marked as outdated.

Uh oh!

mssonicbld commented Aug 28, 2025

Uh oh!

azure-pipelines bot commented Aug 28, 2025

Uh oh!

mssonicbld commented Sep 3, 2025

Uh oh!

azure-pipelines bot commented Sep 3, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

mihirpat1 commented Aug 21, 2025 •

edited

Loading

bfoo-msft Mar 7, 2026 •

edited

Loading

bfoo-msft Mar 7, 2026 •

edited

Loading

bfoo-msft Mar 7, 2026 •

edited

Loading