Everyone is talking about migrating to the cloud. The focus is usually on the technical aspects of the move and on streamlining existing data and mapping previous processes 1:1 or in an improved form in the cloud. However, the unloved stepchild of these projects is testing. But how do you test the Atlassian Cloud?
There are four key points that need to be tested before migration:
- User experience - Is the default view sufficient or do I need to customize the UI?
- Core processes - Can core processes be implemented identically or with minor modifications in the cloud?
- User administration - How does the cloud's multi-tenant user administration work compared to the Server or Data Center Edition?
- Third-party system integration - Will my third-party systems connected to Jira and Confluence continue to work?
For our blog post, we have picked out a core process to run through the test procedure as an example. The process is based on the previous server version of Jira Software.
Example Process - Tender Management
An order has been put out to tender and it is now time to check internally whether the company will participate. To do this, an employee (the creator) creates an issue in Jira including the most important key data such as the title, URL and unique ID of the tender. Jira immediately uses the unique tender ID to check whether this is a duplicate and prevents the issue from being created if necessary.
The processor checks the tender documents for feasibility. If necessary, he adjusts individual characteristics and then decides whether the company should take part in the tender or not. Once the decision to participate has been made, the tender is processed and the status is changed to "Submission completed". Once the tendering body has made its decision, the status changes to "Award received" or "Award not received".
There are therefore two people going through the process here. A third person is added for the test, namely the Jira administrator. This person makes any adjustments to the Atlassian software.
People
- Creator
- Editor
- Jira administrator
The test runs in two steps; here is the first.
Test run #1 (in the non-productive cloud system)
As a prerequisite, the following migration steps must already have been completed:
- Cloud site with free plan has been created and the domain verified
- Data has been exported from the legacy system to the cloud site
We are now in step 3: Announce the migration in the legacy system via a message and test the migrated processes and data. The aim here is to determine whether the processes are working properly and, ideally, exactly as in the server version. By the way, you can find the complete list of steps in our white paper Migration to the cloud.
Test process in the cloud:
- The creator enters the most important key data such as the title, URL and unique ID of the alert in the issue creation screen and presses "Create".
When doing so, the creator makes sure that the unique alert ID has not yet been used by another issue.
- The creator calls up the issue and fills in the other data as usual using the "Add data" workflow step.
- The processor validates quickly (without checking the documents, as it is only a test) and tries to move the issue to "no participation" -> works ✅
- The processor deletes the created issue.
- The creator repeats steps 1-3.
- The editor now moves the issue to "Participation" -> works ✅
- The editor then moves the issue to "Submission completed" -> works ✅
- The editor then moves the issue to "Awarded" -> works ✅
- The creator repeats the whole process again to deliberately create a duplicate for further testing purposes.
- The processor moves the issue to "Participation" -> "Submission completed" -> "Award not received" -> works ✅
This tests the regular process flow with all eventualities (no participation, award received, award not received). In the following, the behavior of duplicates will be tested.
- The creator enters the most important key data such as the title, URL and unique ID of the tender in the issue creation screen and presses "Create".
The creator makes sure that the unique tender ID has been used from AT LEAST ONE OTHER issue (it is best to use the ID from the previous/first run in the cloud).
- The creator does not receive an error message and the issue can be created without a duplicate warning.
- The creator informs the Jira administrator.
- The Jira administrator checks how duplicate detection was previously implemented with the server version of Jira. They discover that the app required for this is not compatible with the cloud.
- The Jira administrator evaluates two alternatives as to how the duplicate check can be implemented without the app:
- Jira automation rule
- Webhook
- The Jira administrator opts for the webhook, as this provides the greatest possible flexibility and customization options - for example, to query or insert information from third-party systems.
- The Jira administrator develops a webhook that is triggered for the "Issue created" event.A JQL search is then performed in the webhook code in Jira with the parameter "TenderID = <ID of current issue>".
If results are found, an issue link is created that refers to the original issue. The current issue is set to "no participation" by the webhook and thus closed. In this way, users immediately recognize that the issue is a duplicate and that no further data needs to be entered.
- The creator repeats the process.
The creator ensures that the unique tender ID is used by at least one other issue.
- The creator calls up the issue and sees that the issue has been closed automatically -> works ✅
This process is of course only an example of the various tests that you carry out during a migration. If you would like to know more about this or have any questions, please feel free to contact me.