¶ In this lesson you will
- Submit a change request to QA
- Review it as a QA reviewer: log issues, send back or approve
- Fix and resubmit as a service manager
¶ Submit to QA
When every step is saved and your tests pass, open the last step (7. Translation), save, and click Submit to QA. The change request moves to IN_QA and becomes read-only for you. There is no confirmation dialog: check everything before you click.
The last step: Translation, then Submit to QA
-
- Translation: final configuration step
- Language list: choose the language to translate
- Translation field: type the text for this key
- Save & Close: save progress and exit
- Submit to QA: send the change request for review
Submit to QA is enabled once the step is saved
- Toast: confirms your changes were saved
- Submit to QA: now enabled, click to submit
-
- Translation: current step
- Save & Close: save and exit instead
In QA: the service manager can only View Configuration now
- Toast: submission to QA succeeded
- In QA tab: filter requests under review
- Status In QA: the request is with the QA Reviewer
- View Configuration: read-only view while in QA
¶ The QA reviewer's side
The QA reviewer assigned by the organization sees the change request in the In QA tab of the same Service Management Portal and clicks Review. The review walks the same steps (Overview, Form, Pricing, Workflow Config, Translation). Each step shows the JSON and, for an improvement, the diff against the live version.
QA reviewer: In QA tab, Review
- In QA tab: requests waiting for your review
- Course Demo row: the service to review
- Status In QA: ready for review
- Review: open the change request for review
Review page: one section at a time, with the JSON diff and an issue form
- Overview: first section to review
- JSON diff: compare new configuration with previous
- Issue Title: name an issue if you find one
- Issue Description: describe the required change
- Next: go to the next section
- Hide JSON Changes: toggle the diff view
Log an issue: short title, what must change
- Issue Title: 'Phone number hint missing'
- Issue Description: what the Service Manager must fix
- Save: record this review issue
- Pending tab: where saved issues appear
The issue is listed under Pending
- Saved issue: listed under Pending
- New badge: issue not yet addressed
- ... menu: more actions on the issue
- Next: continue to the next section
Check the pricing: type, amount, currency, scenarios
- Pricing: current review section
- Pricing JSON: check fee, type and currency
- Issue Title: log a pricing issue if needed
- Next: move to Workflow Config
Check the workflow: states, transitions, roles, actions
- Workflow Config: current review section
- Workflow JSON: check states and transitions
- Issue Title: log a workflow issue if needed
- Next: move to Translation
Preview & Submit: with open issues, the only choice is Submit for changes
- Preview & Submit: final review step
- Issue row: summary of logged issues
- Submit for changes: return the request to the Service Manager
Sent back: the change request is In Development again
- Toast: request sent back for changes
- Status In Development: back with the Service Manager
- Course Demo row: the returned service
¶ Fix and resubmit
The service manager finds the change request back in In Development. The reviewer's issues appear in the step they were logged on, under Pending. Fix each one, save, and submit to QA again. The reviewer re-reviews, marks each issue Resolved, and when no pending issue remains, approves.
Back with the service manager
- Search for service: find Course Demo
- Status In Development: returned by QA
- Configure: reopen the service to fix issues
The QA issue, shown on the step it concerns
-
- Overview: step with the feedback
- Pending tab: open QA issues
- QA issue: what the reviewer asked you to fix
- Solved tab: issues already resolved
- Submit to QA: resubmit once fixed
Reviewer: ⋯ menu → Resolve
- ... menu: issue actions
- Resolve: mark the issue as fixed
- Pending badge: issue still open
- Pending tab: open issues
No pending review issues
- Toast: issue marked resolved
- Resolved tab: see the resolved issue
- No pending Review Issues
- Next: continue to Preview & Submit
Preview & Submit with every issue resolved: Approve Change Request Configurations
Approved: the change request is Ready To Go Live
- Submit to QA — IN_DEVELOPMENT → IN_QA (Service manager)
- Review — Log issues per step (QA reviewer)
- Send back — IN_QA → IN_REDEVELOPMENT (shown as In Development) (QA reviewer)
- Fix, resubmit — Issues on each step (Service manager)
- Approve — IN_QA → LIVE_READY (QA reviewer)
↻ The loop repeats until no pending issue remains.
Tip · what a good QA reviewer checks
Apply once per pricing scenario and per branch (pay, reject, request for action, bill expiry). Open the certificate in every language. Search each test application in Kibana for ERROR lines. Read the next-steps conditions: free text instead of JavaScript hides the steps silently (lesson D4).
¶ Check yourself
The QA reviewer logged two issues and clicked Submit for changes. Where is the change request and who acts?
- A. In QA, the reviewer fixes the issues
- B. Ready To Go Live, the organization decides
- C. Rejected, a new change request is needed
- D. In Development, the service manager fixes the issues and resubmits
Show the answer
D. Sending back returns the change request to IN_REDEVELOPMENT (labelled In Development) with the issues attached to the steps.
← C4 · Assignment 3: CanalBox subscription renewal · D2 · Sign-off, publishing portals and admin approval →