Revert a test scenario of kyc-match to the original one

[ToshiWakayama-KDDI]

Problem description

During the final phase of the Fall25 meta-release in last Autumn, one of the test scenarios included in the test scenario of kyc-match .feature, i.e. @KYC_Match_6_success_multiple_optional_parameter_combinations, was modified with simplified expressions, in order to avoid some errors/warnings that the linting rules had detected.

For details, please refer to PR #28 and the meeting minutes for 2025-09-02 (https://lf-camaraproject.atlassian.net/wiki/spaces/CAM/pages/221675597/2025-09-02+KYC+Match+Fill-in+Age+Veri+Tenure+Number+Rec+Sub+Status+Minutes#KYC-Match%2F-Fill-in-APIs--Repo--Match-New-Repo-Fill-in-New-Repo)

Now the linting rules have been modified in the Commonalities WG, so, we could revert the expressions of the test scenario back to the original one, because the original one explains the test process clearly.

Possible evolution

• Current test scenario - Fall25

@KYC_Match_6_success_multiple_optional_parameter_combinations
Scenario: Validate success response when providing different optional parameter combinations
Given a valid testing phone number supported by the service, identified by the access token or provided in the request body
And the request body contains valid required properties
And the request body contains a random combination of valid optional parameters, including, but not limited to, idDocument, name, givenName, address, country, birthdate, email fields
When the request "KYC_Match" is sent
Then the response status code is 200
And the response header "x-correlator" has same value as the request header "x-correlator"
And the response header "Content-Type" is "application/json"
And the response body complies with the OAS schema at "/components/schemas/KYC_MatchResponse"

• Proposed test scenario (the same as before Fall25)

@KYC_Match_6_success_multiple_optional_parameter_combinations
Scenario: Validate success response when providing different optional parameter combinations
Given a valid testing phone number supported by the service, identified by the access token or provided in the request body
And the request body property "$.idDocument" is set to a valid identity document
And the request body property "$.name" is set to a valid name
And the request body property "$.givenName" is set to a valid given name
And the request body property "$.familyName" is set to a valid family name
And the request body property "$.nameKanaHankaku" is set to a valid name
And the request body property "$.nameKanaZenkaku" is set to a valid name
And the request body property "$.middleNames" is set to a valid middle names
And the request body property "$.familyNameAtBirth" is set to a valid family name at birth
And the request body property "$.address" is set to a valid address
And the request body property "$.streetName" is set to a valid street name of the address
And the request body property "$.streetNumber" is set to a valid street number of the address
And the request body property "$.postalCode" is set to a valid postal code of the address
And the request body property "$.region" is set to a valid region of the address
And the request body property "$.locality" is set to a valid locality of the address
And the request body property "$.country" is set to the country of the address value that complies with the ISO 3166-1 alpha-2 format
And the request body property "$.houseNumberExtension" is set to a valid house number extension of the address
And the request body property "$.birthdate" is set to a birthdate value that complies with the ISO 8601 calendar date format "YYYY-MM-DD"
And the request body property "$.email" is set to a email value that complies with the RFC format "{local-part}@{domain}"
And the request body property "$.gender" is set to a valid gender value that belongs to the enumeration ("MALE", "FEMALE", "OTHER")
And the request body property "$.nationality" is set to the country for the nationality and complies with the ISO 3166-1 alpha-2 format
And the given request body is populated with any random combination of afore mention optional parameters
When the request "KYC_Match" is sent
Then the response status code is 200
And the response header "x-correlator" has same value as the request header "x-correlator"
And the response header "Content-Type" is "application/json"
And the response body complies with the OAS schema at "/components/schemas/KYC_MatchResponse"

Alternative solution

No change

[GillesInnov35]

thanks @ToshiWakayama-KDDI , LGTM

[ToshiWakayama-KDDI]

Thanks, @GillesInnov35 . I will create a corresponding PR, but later, sometime before M4, I am thinking.