Fall 25 Feature Files to provide schema context

[PedroDiez]

What type of PR is this?

• enhancement
• documentation
• tests

What this PR does / why we need it:

This PR manages the topic raised in Issue #481, which indicates the lack of establising an schema context as indicated in PR #470 for event notification transversal gherkin template.

In this way, this PR proposes the following:

• Update C01-device-errors.feature and C02-phoneNumber-errors.feature artifacts to provide such schema context and align with PR Add event-notification feature file template #470

• Update API-Testing-Guidelines.md guide to document the feature context already being used across Feature files also referencing to the schema context

Which issue(s) this PR fixes:

Fixes #481

Does this PR introduce a breaking change?

• Yes
• No

Special notes for reviewers:

Changelog input

 Setting a feature context

Additional documentation

N/A

[Kevsy]

Can you give some examples of how this template would be filled? Otherwise a .feature author may not be sure what to put in each section.

We should also decide whether the template always needs to be filled out , in case that is not necessary for certain .feature files (e.g. all the info could have been given in the Background assertions for certain APIs)

[PedroDiez]

Some examples @Kevsy (I can add it one in the PR). Good point to add an example

Reference: https://github.com/camaraproject/QualityOnDemand/blob/main/code/Test_definitions/quality-on-demand-createSession.feature

    # Input to be provided by the implementation to the tester
    #
    # Implementation indications:
    # * apiRoot: API root of the server URL
    # * List of device identifier types which are not supported, among: phoneNumber, ipv4Address, ipv6Address.
    #   For this version, CAMARA does not allow the use of networkAccessIdentifier, so it is considered by default as not supported.
    # * List of application server IP formats which are not supported, among ipv4 and ipv6.
    #
    # Testing assets:
    # * A device object applicable for Quality On Demand service.
    # * A device object identifying a device commercialized by the implementation for which the service is not applicable, if any.
    #

    # References to OAS spec schemas refer to schemas specifies in quality-on-demand.yaml

Reference: https://github.com/camaraproject/DeviceLocation/blob/main/code/Test_definitions/location-retrieval.feature

  # Input to be provided by the implementation to the tester
  #
  # Implementation indications:
  # * List of device identifier types which are not supported, among: phoneNumber, networkAccessIdentifier, ipv4Address, ipv6Address
  #
  # Testing assets:
  # * A device object which location is known by the network when connected. 2 distinct device are required for some scenario.
  # * A device object identifying a device commercialized by the implementation for which the service is not applicable
  # * A device object which location cannot be provided during test by the network.
  #
  # References to OAS spec schemas refer to schemas specifies in location-retrieval.yaml

I can also add a sentence to reflect that:
We should also decide whether the template always needs to be filled out , in case that is not necessary for certain .feature files (e.g. all the info could have been given in the Background assertions for certain APIs)

[jlurien]

As the API version is already indicated at the top of the Feature file, I would not add it again here, as it creates additional maintenance work when creating releases (vX.Y.Z -> vwip -> v....)

[PedroDiez]

Yes, good point @jlurien, that is already stated within Feature tag so better to avoid duplication and additional maintenance work

[Kevsy]

LGTM

[patrice-conil]

LGTM

[rartych]

LGTM