QA for Lifecycles
Once you've finished building your Lifecycle version, it's time to send it for QA.
As Lifecycle projects incorporate many components, it's never been more important to thoroughly check: the Entry Conditions, the structure of the Lifecycle and the set-up of each and every player engagement.
➡️ Sending a Lifecycle for QA
Open the Lifecycle version from In-Dev that you want to send for Quality Assurance and navigate to Define Activities view. Click Send to QA in the top right. The Lifecycle version will automatically be sent to the QA status, ready to be reviewed.
💡 How to QA a Lifecycle
From the QA status of the Lifecycle, select the Lifecycle version that you wish to Quality Assure for the QA window to open.
Just like when quality assuring an Activity, you need to check each component of the Activity slot and sign-off. Once the Activity slot has been signed off, the blue box will turn green to let you know that it has already been approved.
Tip: It is important to QA, not only the Activity slots but also: the structure of the Lifecycle, the Entry Conditions, the ending event(s) and the Trigger and Segment of each event.
Note: You will not be able to Approve the Lifecycle version until all of the Activity slots have been signed off and have turned green.
Once all the Activity slots for each event have been signed off, the event track will also change to green.
✅ When to Approve
Once you're satisfied with all the components of the Lifecycle version, you can approve it. This means that no further changes need to be made and the Lifecycle version is ready to go live.
By selecting Approve Now, the version will move to Ready status to wait to be launched into production.
Note: Players will not be able to enter the Lifecycle version when enabled and in Ready. Once approved, the version will wait to be launched before it is live.
For more information about how to prepare the Lifecycle version for launch, check here.
🚫 When to Reject
If you notice anything that needs fixing or changing inside the Lifecycle event, it should be rejected. Rejecting a Lifecycle version will send it back to In Dev status.
Good to Know: Any components of the Lifecycle version that have been signed-off as part of the QA process before being rejected, and that were not changed whilst In Dev, will retain their signed-off status when the Lifecycle is sent back to QA.
That means you won't have to repeat the QA process on parts of the Lifecycle that were already signed-off 👍
Last updated
Was this helpful?