Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Feature Branch Exit Criteria

The following criteria must be met before considering landing the feature branch into master.

Exit Criteria

Status/Notes

Test automation and CI is 100% complete with “required for version”

/wiki/spaces/DC/pages/11144036353

No defects with high/critical exposure or “required for version”

key summary assignee priority status
Refresh

No new daily or weekly regression test failures (failures not already on master branch)

  • Need to perform weekly regression test on feature branch

Initial merge will have scrubbing disabled by default, so felt full daily/weekly not necessary in favor of feature specific testing.

All PR tests passed on latest version with checksum Features specified.

All tests are passing for feature in weekly and daily regression tests

  • Need to perform weekly regression test on feature branch

Performance and scale testing executed according to test plan/required requirements. Results are reviewed and approved

  • Need to perform performance testing

I’ve done some initial performance testing with some local changes. No noticeable performance impact with “lazy” mode. After these changes have landed need to do more official performance testing.

Should have no impact with when disabled.

SDL Code scans are competed (Coverity, Bandit, Checkmarx, Snyk). For all scans, all issues have been dispositioned, and the issues that are required per SDL rules have been fixed.

  • Need to run coverity on feature branch.

- There’s not currently a way to run Coverity on feature branches, but David Quigley (Deactivated) said that he can do what sounds like an ad hoc scan.

SAFE review executed if required

SAFE review is not needed.

Any new dependencies identified and Oked by ESAD OSPDT owner

No new dependencies

Does not regress endurance testing from current master baseline with feature enabled

  • Perform SOAK testing

Does not regress scale testing from current master baseline with feature enabled

  • Create a ticket with relevant information (commit/branch to test and any special considerations) and assign to Dalton.

Manual test plans and “out-of-box experience” testing are 100% executed with “required for version”. Manual test results are recorded

All tests should be automated

Feature branch is up to date with master

  • Merge with master … again

Feature Completion Criteria

The following criteria must be met before considering the feature is complete

Exit Criteria

Status/Notes

Requirements are defined in SRS Jira Project

SRS-371 - Getting issue details... STATUS

Design document is complete, reviewed, and approved utilizing the team template

/wiki/spaces/DAOS/pages/11052974081 has been reviewed.

Test plan for feature is complete, reviewed, and approved utilizing the team template. Security validate plan is also updated if applicable.

/wiki/spaces/DC/pages/2175829848

Planned software feature is 100% implemented with “required for version”

key summary assignee reporter status resolution
Refresh

All user documentation updated and reviewed (e.g., admin guide, user guide)

Code coverage results have been reviewed to identify gaps in testing, and test plan has been updated and executed accordingly. Functional and branch coverage each are equivalent or better than master

Usability is evaluated and results are reviewed

Not sure what the process is for evaluating “usability”

  • No labels