QA: Perform and document manual feature tests for Flexible Scan Execution Policy Trigger Condition

Overview

This issue covers manual testing of the new flexible trigger conditions for Scan Execution Policies that allow users to optimize pipeline execution by targeting branches that will be merged into default or protected branches, rather than running on all branches.

Feature Background

The feature introduces new trigger conditions:

• Branches targeting the default branch - Runs scans on merge request pipelines where the source branch targets the default branch
• Branches targeting protected branches - Runs scans on merge request pipelines where the source branch targets any protected branch

Test Focus

Scanner Type: Container Scanning only (to keep testing scope manageable) Focus Area: Trigger mechanism functionality rather than scanner-specific behavior

Test Scenarios

1. UI/UX Testing

• Verify new branch type options appear in the policy editor dropdown
• Test the "Choose condition type" interface with new trigger options
• Validate that the policy editor clearly explains what each option does
• Ensure backward compatibility with existing policies

2. Functional Testing - Branches Targeting Default Branch

• Create a scan execution policy with "branches targeting default branch" condition for container scanning
• Create an MR from feature branch targeting the default branch
• Verify container scanning jobs are injected into the MR pipeline
• Verify container scanning jobs also run on the default branch pipeline This should not occur unless the scan execution policy also has the condition triggers every time a pipeline runs for all default branches
• Test with different pipeline sources (merge_request_event, push, etc.): there was an issue with this; see Update pipeline sources for branches targeting (!197049 - merged) and Implement all pipeline sources for branches tar... (#554272 - closed) for more information

3. Functional Testing - Branches Targeting Protected Branches

• Create a scan execution policy with "branches targeting protected branches" condition for container scanning
• Create MRs targeting various protected branches
• Verify container scans run appropriately based on target branch protection status
• Test edge cases with branch protection rule changes

4. Integration with MR Approval Policies

• Set up MR approval policy requiring container scan results
• Configure scan execution policy with new trigger conditions
• Verify MR approval evaluation works correctly with artifacts from both source and target branches
• Test the complete workflow from scan execution to MR approval (https://staging.gitlab.com/govern-team-test/alexander-test-group/rails-application/-/merge_requests/7, MR blocked because of secret detection)

5. YAML Configuration Testing

• Test YAML configuration with branch_type: target_default
• Test YAML configuration with branch_type: target_protected
• Verify pipeline_sources filtering works correctly
• Test policy import/export functionality: not relavent

6. Edge Cases and Trigger Logic

• Verify behavior when target branch changes during MR lifecycle
• Test with complex branching strategies (gitflow, etc.) This is not applicable
• Validate behavior with closed/merged MRs This does not make sense as a test case
• Test scenarios where MR targets change from protected to non-protected branches

7. Completed Feature Testing

• Verify feature works correctly in its final implementation
• Test all documented functionality without feature flag dependencies
• Confirm stable behavior across different project configurations

Expected Outcomes

• Scan execution policies should provide more granular control over when container scans run
• Infrastructure costs should be reduced by avoiding unnecessary scan executions on irrelevant branches
• MR approval policies should work seamlessly with the new trigger conditions
• The user experience should be intuitive and well-documented

Test Environment Requirements

• GitLab instance with the completed feature
• Projects with various branching strategies
• Container scanning configured
• MR approval policies configured
• Different pipeline sources available for testing

Documentation Validation

Add documentation for pipeline sources (!196762 - merged)

• Verify user documentation covers new trigger conditions
• Ensure YAML reference is updated with new branch_type options
• Confirm examples demonstrate common use cases
• Validate troubleshooting guides address potential issues

Success Criteria

• All trigger conditions work as documented
• Container scanning jobs are properly injected based on branch targeting rules
• MR approval policies evaluate correctly with new trigger conditions
• No regressions in existing scan execution policy functionality
• Clear documentation supports user adoption