Detailed test plan for QoS Booking by jlurien · Pull Request #70 · camaraproject/QoSBooking

jlurien · 2025-10-28T12:04:42Z

What type of PR is this?

enhancement/feature
tests

What this PR does / why we need it:

Creates a new version of the test plan, substituting the single file that we had in the last meta, with a level of detail similar to what we have in other CAMARA APIs and aligned with the guidelines.

There is a separate file per operation, covering all expected responses. Comments are included when issues with the current spec are detected, which may be treated separately.

Which issue(s) this PR fixes:

Fixes #69

Special notes for reviewers:

Once merged, this test plan should evolve and be aligned with the API spec towards the next version.

Changelog input

- Enhanced test plan for QoS Booking API

github-actions · 2025-10-28T13:47:37Z

🦙 MegaLinter status: ✅ SUCCESS

Descriptor	Linter	Files	Errors	Elapsed time
✅ ACTION	actionlint	2	0	0.01s
✅ API	spectral	2	0	3.85s
✅ GHERKIN	gherkin-lint	5	0	1.81s
✅ REPOSITORY	git_diff	yes	no	0.01s
✅ REPOSITORY	secretlint	yes	no	0.61s
✅ YAML	yamllint	2	0	1.07s

See detailed report in MegaLinter reports

MegaLinter is graciously provided by

Masa8106

Thank you for creating this PR.
Overall, it seems good. As there is several open questions, let us discuss them (Please find my comments.). Thank you.

Masa8106 · 2025-11-13T12:03:39Z

+      | $.sink                   | exists only if provided in the request body and with the same value                                       |
+
+    # Open questions:
+    # serviceArea has to have same value as in the request body or implementations can make adjustments


Could you elaborate what you assume "implementations can make adjustments" is? Is there possibility that different serviceArea value with in the request body may be responded?

It's whether the value in the response has to be strictly the same as in the request or implementation may adjust the serviceArea to facilitate the implementation. I assume that it should be the same, but it would be good to make it more clear in the spec.

I understood what you pointed out. In my opinion, the same value would be better. But I became to recognise that implemantation may response different serviceArea value through breakout session. Therefore, it seems to be ok that there is no $.serviceArea in examples of the scenario outline.

How should we handle this?
(1) We assume it should be the same: Write it out in the spec and adding $.serviceArea as example.
(2) We allow implementation adjust the serviceArea: (Write "should be the same" our in the spec, and approve this as it is).
My preference is (2). What do you think?

Maybe it is more problematic to allow implementations to modify the requested area in 2xx responses, because customers may complain that the booked session is not what they asked for. I guess that a very minimal adjustment would not be a problem, but if we allow implementations to adjust the serviceArea in general, it willl be difficult to specify how much they can adjust it.

I think it will be more pragmatic to return exactly the requested area, even if internally the implementations may perform those necessary adjustments, as long as the perceived service is not noticeably affected.

It is fine with me to return exactly the requested area.

CQM Meeting Feb 6th: Proposal to return same data agreed in meeting; @jlurien will adapt API spec as well

@jlurien, please let me suggest adding this proposal into line#50 and removing this note.

Suggested change

# serviceArea has to have same value as in the request body or implementations can make adjustments

Masa8106 · 2025-11-13T12:27:41Z

+    # startTime has to have same value as in the request body or implementations can make adjustments, to be returned when status = UNAVAILABLE?
+    # duration to be returned when when status = UNAVAILABLE?
+    # bookingId to be returned when when status = UNAVAILABLE?
+    # statusInfo should have another value when status = UNAVAILABLE after creation, e.g. BOOKING_CANNOT_BE_FULFILLED or open string


We can discuss on this. There is status diagram I assume so far here.

I commented about this above. In the diagram that you link there is no status for a booking request that has been declined, but the v0.1 spec says that the status for a booking declined during creation is UNAVAILABLE. That is something that we need to decide upon.

See the above comment.

We can update the diagram

@Masa8106 would you take it?

@jlurien, please let me present you an updated diagram.
Changing points are the following:

The status for a booking declined during creation is specified as "Terminated". In my opinion, it is ok for me not to create resourse for declined booking instead of "Terminated", depending on implementation.

The status "Available" and "Unavailable" are updated to "Activated (Avaiable)" and "Activated (Unavaiable)". What I am thinking is to distinguish status for booking with status for connectivity. For example, "Activated (Avaiable)" means that the booking is activated after start time is passed and the connectivity to network is fine. Though we can specify two status parameter in yaml file, so far I would like to express them in one existing status parameter.

@jlurien, @hdamker
Based on our discussion in the last meeting, I have updated the status diagram.
We can discuss on options "separate states of booking and QoS Session (Connectivity) (more complex?) vs combined state".
Let's discuss on it first in breakout session today.

I opened Issue #83 for diagram discussion.
Let's keep discussion there from now and onwards.

Please refer to Issue#83.
I would like to suggest removing this note.

Suggested change

# statusInfo should have another value when status = UNAVAILABLE after creation, e.g. BOOKING_CANNOT_BE_FULFILLED or open string

Masa8106 · 2025-11-13T12:32:20Z

+    # duration to be returned when when status = UNAVAILABLE?
+    # bookingId to be returned when when status = UNAVAILABLE?
+    # statusInfo should have another value when status = UNAVAILABLE after creation, e.g. BOOKING_CANNOT_BE_FULFILLED or open string
+    # sinkCredential may be returned in the response in any case or it should be removed for security


I think it is good way to align with other QoD APIs on how sinkCredential is returned.

Agree. Even more, it should be aligned at Commonalities across all CAMARA APis

As far as I see QoD API and QoS Provisioning, sinkCrediential in the response is not specified, I think, due to security reason. I prefer to keep as it is (I mean no sinkCredential should be returned).

I would like to suggest removing this note.

Suggested change

# sinkCredential may be returned in the response in any case or it should be removed for security

Masa8106 · 2025-11-13T12:34:11Z

+
+  # This step is optional, for cases when the implementation did not grant the booking synchronously and later rejects the booking
+  # or when it was granted (SCHEDULED) but implementation decides to revoke it before the start
+  # TBD if a better status or statusInfo is specified for this use case, e.g. status = "REJECTED" or status = "UNAVAILABLE" + statusInfo = "NOT_SCHEDULED" or "REVOKED"


We can discuss on this. There is status diagram I assume so far camaraproject/QualityOnDemand#337.

as commented above the v0.1 is not aligned with that diagram, so we have to work towards v0.2 on a better definition of statuses in the spec, which is what prevails.

Please refer to Issue#83.
I would like to suggest removing this note.

Suggested change

# TBD if a better status or statusInfo is specified for this use case, e.g. status = "REJECTED" or status = "UNAVAILABLE" + statusInfo = "NOT_SCHEDULED" or "REVOKED"

Masa8106 · 2026-04-24T14:46:02Z

+
+  # This step is optional, for cases when the implementation did not grant the booking synchronously and later rejects the booking
+  # or when it was granted (SCHEDULED) but implementation decides to revoke it before the start
+  # TBD if a better status or statusInfo is specified for this use case, e.g. status = "REJECTED" or status = "UNAVAILABLE" + statusInfo = "NOT_SCHEDULED" or "REVOKED"


Please refer to Issue#83.
I would like to suggest removing this note.

Suggested change

# TBD if a better status or statusInfo is specified for this use case, e.g. status = "REJECTED" or status = "UNAVAILABLE" + statusInfo = "NOT_SCHEDULED" or "REVOKED"

Masa8106 · 2026-04-24T14:48:54Z

+    # startTime has to have same value as in the request body or implementations can make adjustments, to be returned when status = UNAVAILABLE?
+    # duration to be returned when when status = UNAVAILABLE?
+    # bookingId to be returned when when status = UNAVAILABLE?
+    # statusInfo should have another value when status = UNAVAILABLE after creation, e.g. BOOKING_CANNOT_BE_FULFILLED or open string


Please refer to Issue#83.
I would like to suggest removing this note.

Suggested change

# statusInfo should have another value when status = UNAVAILABLE after creation, e.g. BOOKING_CANNOT_BE_FULFILLED or open string

Masa8106 · 2026-04-24T14:50:01Z

+    # duration to be returned when when status = UNAVAILABLE?
+    # bookingId to be returned when when status = UNAVAILABLE?
+    # statusInfo should have another value when status = UNAVAILABLE after creation, e.g. BOOKING_CANNOT_BE_FULFILLED or open string
+    # sinkCredential may be returned in the response in any case or it should be removed for security


I would like to suggest removing this note.

Suggested change

# sinkCredential may be returned in the response in any case or it should be removed for security

Masa8106 · 2026-04-24T15:01:44Z

+      | $.device                 | exists only if provided in the request body and contains only one of the identifier values in the request |
+      | $.qosProfile             | same value as in the request body                                                                         |
+      | $.startTime              | is in the future                                                                                          |
+      | $.status                 | is "REQUESTED", "SCHEDULED" or "UNAVAILABLE"                                                              |


Masa8106 · 2026-04-24T15:03:28Z

+      | $.sink                   | exists only if provided in the request body and with the same value                                       |
+
+    # Open questions:
+    # serviceArea has to have same value as in the request body or implementations can make adjustments


@jlurien, please let me suggest adding this proposal into line#50 and removing this note.

Suggested change

# serviceArea has to have same value as in the request body or implementations can make adjustments

camara-validation · 2026-06-18T11:16:19Z

CAMARA Validation — PASS (with warnings)

0 errors, 41 warnings, 18 hints | Profile: standard

View full results

Rename `status` property to `bookingStatus` and update status enum values throughout all four feature files: AVAILABLE -> ACTIVATED, UNAVAILABLE -> TERMINATED, and event data field `$.data.status` -> `$.data.bookingStatus`. Resolve all open questions and TBDs: - Add `$.serviceArea` equality assertion (agreed in CQM meeting 2026-02-06) - Assert `$.sinkCredential` absent in all responses (security, aligned with QoD) - Remove resolved open questions for startTime/duration/bookingId (required fields) - Replace TBD on revoked booking with BOOKING_REVOKED statusInfo - Add new scenario for synchronous booking decline (TERMINATED + BOOKING_DECLINED) Fix deleteBooking async/sync split: 202 applies to REQUESTED/SCHEDULED/ACTIVATED; 204 applies to TERMINATED (not REQUESTED/UNAVAILABLE as previously stated). Fix qos-booking-getBookingById scenario _02: replace non-existent property `$.qosStatus` with correct `$.bookingStatus` = "TERMINATED".

jlurien · 2026-06-18T12:06:57Z

@Masa8106 this PR updated after PR #88 merged. Changes in the last commit:

Align test plan with PR #88 status model changes
Rename status property to bookingStatus and update status enum values
throughout all four feature files: AVAILABLE -> ACTIVATED, UNAVAILABLE ->
TERMINATED, and event data field $.data.status -> $.data.bookingStatus.

Resolve all open questions and TBDs:

Add $.serviceArea equality assertion (agreed in CQM meeting 2026-02-06)

Assert $.sinkCredential absent in all responses (security, aligned with QoD)

Remove resolved open questions for startTime/duration/bookingId (required fields)

Replace TBD on revoked booking with BOOKING_REVOKED statusInfo

Add new scenario for synchronous booking decline (TERMINATED + BOOKING_DECLINED)

Fix deleteBooking async/sync split: 202 applies to REQUESTED/SCHEDULED/ACTIVATED;
204 applies to TERMINATED (not REQUESTED/UNAVAILABLE as previously stated).

Fix qos-booking-getBookingById scenario _02: replace non-existent property
$.qosStatus with correct $.bookingStatus = "TERMINATED".

I have updated also the TBD/TBC comments and align the test plan with the PR discussions

Masa8106

@jlurien, thanks for the update. LGTM.
Will you merge this PR? or I will do it tomorrow or onwards.
Thank you.

hdamker

A very few inconsistencies found by agent, see below.

Co-authored-by: Herbert Damker <herbert.damker@telekom.de>

Masa8106 · 2026-06-19T10:24:44Z

@hdamker, thank you for poiting them out.

@jlurien, please find my suggestion. If you are ok, please apply them.

Masa8106 · 2026-06-22T08:05:16Z

@jlurien, I am glad if you can have time to review this PR and a related one, #104. After that, we will tackle commonalities alignment PRs in order to complete M3 by this weekend. Thank you for your cooperation.

Co-authored-by: Masaharu Hattori <112887632+Masa8106@users.noreply.github.com> Co-authored-by: Herbert Damker <herbert.damker@telekom.de> Co-authored-by: Jose Luis Urien <jlurien@gmail.com>

jlurien · 2026-06-26T12:31:46Z

Thanks for the review @Masa8106 , @hdamker . Suggestions applied. #104 approved so error here is kept

Masa8106

LGTM

Masa8106 · 2026-06-30T06:34:13Z

Hi @hdamker, as we discussed at the last CQM meeting, may I ask you a final review in order to include this PR into M3 RC release. Thank you for your corporation.

hdamker · 2026-07-01T06:59:48Z

Hi @hdamker, as we discussed at the last CQM meeting, may I ask you a final review in order to include this PR into M3 RC release. Thank you for your corporation.

@Masa8106 shortly looked (I'm on vacation). LGTM, my comments are all addressed. You might want to trim the comment "## Code QOS_BOOKING.QOS_PROFILE_NOT_APPLICABLE to be added in next version" as it is already in main after #104 (createBooking.feature:582).

hdamker

LGTM, see previous comment.

jlurien · 2026-07-01T07:16:48Z

Hi @hdamker, as we discussed at the last CQM meeting, may I ask you a final review in order to include this PR into M3 RC release. Thank you for your corporation.

@Masa8106 shortly looked (I'm on vacation). LGTM, my comments are all addressed. You might want to trim the comment "## Code QOS_BOOKING.QOS_PROFILE_NOT_APPLICABLE to be added in next version" as it is already in main after #104 (createBooking.feature:582).

Thanks @hdamker, I have removed the comment.

jlurien · 2026-07-01T07:18:46Z

@Masa8106 you can formally approve again, as the previous approvals were dismissed after I removed the comment. Then we can finally merge.

Masa8106

I confirmed the removal of the comment. Thank you @hdamker and @jlurien .
Please merge this PR.

- qos-booking.yaml: auto-merged cleanly (Commonalities r4.3 constraints from PR camaraproject#97 combined with CloudEvent alignment from PRs camaraproject#98 and camaraproject#102) - qos-booking.feature (monolithic): deleted, superseded by split files introduced in PR camaraproject#70; $.device assertion updated in qos-booking-getBookingById.feature and qos-booking-retrieveBookingByDevice.feature to match PR camaraproject#97 intent

Detailed test plan for QoS Booking

bb79f93

jlurien requested a review from Masa8106 as a code owner October 28, 2025 12:04

Merge branch 'main' into qos-booking-testplan-evolution

4286176

jlurien added 2 commits October 29, 2025 09:58

Linting error fixtures

cd6859e

Reduce long scenarios size

ae4df5b

Masa8106 reviewed Nov 13, 2025

View reviewed changes

hdamker requested a review from Masa8106 December 12, 2025 12:36

Masa8106 mentioned this pull request Feb 27, 2026

QoS B: Update the status diagram #83

Closed

Masa8106 reviewed Apr 24, 2026

View reviewed changes

Masa8106 mentioned this pull request Jun 17, 2026

QoS B: Update the booking status #88

Merged

Merge branch 'main' into qos-booking-testplan-evolution

9de1d01

jlurien requested review from Masa8106 and hdamker June 18, 2026 12:03

jlurien mentioned this pull request Jun 18, 2026

QoS B: Alignment with Commonalities r4.3 #97

Merged

Masa8106 previously approved these changes Jun 18, 2026

View reviewed changes

hdamker reviewed Jun 18, 2026

View reviewed changes

Update code/Test_definitions/qos-booking-createBooking.feature

7ae7e83

Co-authored-by: Herbert Damker <herbert.damker@telekom.de>

Masa8106 dismissed their stale review via 7ae7e83 June 19, 2026 06:39

Masa8106 requested changes Jun 19, 2026

View reviewed changes

Comment thread code/Test_definitions/qos-booking-createBooking.feature Outdated

Update code/Test_definitions/qos-booking-createBooking.feature

390c057

Merge branch 'main' into qos-booking-testplan-evolution

202f607

jlurien commented Jun 26, 2026

View reviewed changes

Comment thread code/Test_definitions/qos-booking-createBooking.feature Outdated

Apply suggestions from code review

6109bb6

Co-authored-by: Masaharu Hattori <112887632+Masa8106@users.noreply.github.com> Co-authored-by: Herbert Damker <herbert.damker@telekom.de> Co-authored-by: Jose Luis Urien <jlurien@gmail.com>

jlurien requested review from Masa8106 and hdamker June 26, 2026 12:32

Masa8106 previously approved these changes Jun 26, 2026

View reviewed changes

hdamker previously approved these changes Jul 1, 2026

View reviewed changes

jlurien commented Jul 1, 2026

View reviewed changes

Comment thread code/Test_definitions/qos-booking-createBooking.feature Outdated

Apply suggestion from @jlurien

757c37a

jlurien dismissed stale reviews from hdamker and Masa8106 via 757c37a July 1, 2026 07:14

jlurien commented Jul 1, 2026

View reviewed changes

Comment thread code/Test_definitions/qos-booking-createBooking.feature Outdated

Apply suggestion from @jlurien

720b4ff

jlurien requested a review from Masa8106 July 1, 2026 07:17

Masa8106 approved these changes Jul 1, 2026

View reviewed changes

jlurien merged commit 4d49633 into main Jul 1, 2026
3 checks passed

	\| $.status \| is "REQUESTED", "SCHEDULED" or "UNAVAILABLE" \|
	\| $.serviceArea \| same value as in the request body \|
	\| $.status \| is "REQUESTED", "SCHEDULED" or "TERMINATED" \|

Uh oh!

Conversation

jlurien commented Oct 28, 2025

What type of PR is this?

What this PR does / why we need it:

Which issue(s) this PR fixes:

Special notes for reviewers:

Changelog input

Uh oh!

github-actions Bot commented Oct 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🦙 MegaLinter status: ✅ SUCCESS

Uh oh!

Masa8106 left a comment

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!

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!

Choose a reason for hiding this comment

Uh oh!

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!

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!

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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jlurien Nov 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

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!

Choose a reason for hiding this comment

Uh oh!

camara-validation Bot commented Jun 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

github-actions Bot commented Oct 28, 2025 •

edited

Loading

jlurien Nov 13, 2025 •

edited

Loading

camara-validation Bot commented Jun 18, 2026 •

edited

Loading