Conformance testing
This section contains conformance tests, their stages, and accepted results.
Note that conformance testing is a regular process conducted entirely by Spotware. Passing conformance tests is an essential requirement for continued operations with our SSO (OAuth) flows.
info
When performing an API call as part of conformance testing and encountering an error, provide the error description to Spotware's Support Team.
info
When checking screen designs (the browser, screen-size, lang, theme, and multiple-parameter tests below), check the following screens.
- The login/signup screen.
- The deposit/withdrawal screen.
- The 'Open New Account' screen.
- The 'Change Password' screen.
- The 'Change Email' screen.
When testing how content is displayed by various SSO (OAuth) screens as part of the browser and screen-size design tests, make sure that the screens conform to the following requirements.
- The screens have responsive designs to match mobile and desktop layouts.
- None of the screens mentions 'cTrader ID'.
- None of the screens mentions other trading platforms except cTrader.
- The screens mention correct legal entities and do not mislead users (e.g., by referring to incorrect jurisdictions).
- No pop-up messages appear on any screen.
- The screens are neatly organised with no unnecessary UI elements (e.g., 'Chat' buttons or equivalent in the login/signup screen).
- The screen loading times are three seconds or less on any platform, hardware, and all common Internet connection speeds.
warning
Note that the majority of all tests described on this page are mandatory. They cover essential SSO (OAuth) operations, user flows, and API calls. Only some design tests are optional; these are marked as such in their titles.
API calls testing
The cTrader backend is authenticated (POST /oauth2/crmApiToken)
| Test steps | Expected results |
|---|---|
1. Send a POST request to authenticate the cTrader backend with a valid password. | 1. The broker's backend returns a response with code 200; the output contains crmApiToken. |
2. Send a POST request to authenticate the cTrader backend with an invalid password. | 2. The broker's backend returns a response with an error with code 403; the output does not contain crmApiToken. |
An OT token is checked, verified, and exchanged (POST /oauth2/onetime/authorize)
| Test steps | Expected results |
|---|---|
1. Send a POST request to verify and exchange a valid OT token with a valid crmApiToken. | 1. The broker's backend returns a response with code 200; the output contains accessToken and userId. |
2. Send a POST request to verify and exchange an invalid OT token with a valid crmApiToken. | 2. The broker's backend returns a response with an error with code 404. The output does not contain accessToken and userId. |
3. Send a POST request to verify an OT token with an invalid crmApiToken. | 3. The broker's backend sends a response with an error with code 403. The output does not contain accessToken and userId. |
A long-term access token is checked and verified (POST /oauth2/authorize)
| Test steps | Expected results |
|---|---|
1. Send a POST request to verify a long-term access token with a valid accessToken. | 1. The broker's backend returns a response with code 200; the output contains userId. |
2. Send a POST request to verify a long-term access token with an invalid accessToken. | 2. The broker's backend returns a response with an error with code 404; the output does not contain the userId. |
3. Send a POST request to verify a long-term token with an invalid crmApiToken. | 3. The broker's backend sends a response with an error with code 403. The output does not contain accessToken and userId. |
An OT token is generated for an in-app action (POST /oauth2/onetime/generate)
| Test steps | Expected results |
|---|---|
1. Send a POST request to generate an OT token with a valid userId. | 1. The broker's backend returns a response with code 200; the output contains an OT token. |
2. Send a POST request to generate an OT token with an invalid userId. | 2. The broker's backend returns a response with an error with code 404; the output does not contain an OT token. |
3. Send a POST request to generate an OT token with an invalid crmApiToken. | 3. The broker's backend sends a response with an error with code 403. The output does not contain accessToken and userId. |
The broker's backend generates a new OT token each time it is requested to do so
| Test steps | Expected results |
|---|---|
| 1. Log in under an existing user. | 1. The success page is opened after a successful login. |
| 2. Wait for the success page to appear. | 2. The broker's backend generates and returns an OT token. |
| 3. Log in under an existing user in incognito mode. | 3. The success page is opened after a successful login. |
| 4. Wait for the success page to appear. | 4. The broker's backend generates and returns an OT token; this token is different from the one generated during Step 2. |
Different OT tokens are generated for different users
| Test steps | Expected results |
|---|---|
1. Authorise the user with userId1 inside the broker's backend and generate an OT token for this user. | 1. A valid OT token is generated. |
2. Authorise the user with userId2 inside the broker's backend and generate an OT token for this user. | 2. A valid OT token is generated. It is different from the token generated during Step 1. |
OT tokens expire one minute after generation
| Test steps | Expected results |
|---|---|
1. Authorise a user inside the broker's backend, generate an OT token for the corresponding userId, and remember it. | 1. A valid OT token is generated. |
| 2. Wait one minute. | 2. A minute is expired. |
3. Send a request to exchange this token for an accessToken (POST /oauth2/onetime/authorize) with a valid crmApiToken. | 3. The broker's backend returns a request containing an error as the OT token has expired. |
All API calls use the https protocol
| Test steps | Expected results |
|---|---|
1. Send any request with valid parameters and a request body using the http protocol. | 1. The request is unsuccessful. |
2. Send any request with valid parameters and a request body using the https protocol. | 2. The request is successful. |
All servers have valid certificates
| Test steps | Expected results |
|---|---|
| 1. Check server certificates. | 1. All servers have valid certificates. |
Design testing
Check screen designs when using different browsers
note
Repeat this case for all major browsers including Chrome, Firefox, Safari and Edge. Use incognito tabs for each step. For examples of screens, see the login/signup screen examples.
| Test steps | Expected results |
|---|---|
| 1. Open an SSO (OAuth) screen through all of its stages. | 1. The screen contents are displayed correctly and satisfy key requirements (see above). |
Check screen designs when using different screen sizes.
note
Repeat this process for all common screen sizes and aspect ratios such as 4:3 and 16:9.
| Test steps | Expected results |
|---|---|
| 1. Open an SSO (OAuth) screen through all of its stages. | 1. The screen contents are displayed correctly and satisfy key requirements (see above). |
The screens support the lang parameter (optional test)
| Test steps | Expected results |
|---|---|
1. Open an SSO (OAuth) screen with lang equal to en. | 1. The opened iframe displays the correct screen and has lang=en. The screen is displayed in English. |
2. Open the same screen with lang equal to another valid Alpha-2 code that your brokerage supports. | 2. The opened iframe displays the correct screen and has lang = {other code}. The screen is displayed in the language matching the specified code. |
3. Open the same screen with lang equal to an Alpha-2 code that the broker's backend does not support. | 3. The opened iframe displays the correct screen and has lang = {unsupported code}. The screen is displayed using whatever language is specified as the default language by the broker's backend. |
The screens support the theme parameter (optional test)
| Test steps | Expected results |
|---|---|
1. Open an SSO (OAuth) screen with theme equal to light. | 1. The opened iframe displays the correct screen and has theme=light. The screen is displayed using the light UI theme. |
2. Open the same screen with theme equal to dark. | 2. The opened iframe displays the correct screen and has theme=dark. The screen is displayed using the dark UI theme. |
The screens support the firstLogin parameter (optional test)
| Test steps | Expected results |
|---|---|
1. Open the login/signup screen with firstLogin equal to true. | 1. The opened iframe displays the signup screen and has firstLogin=true. The screen displays suitable information for first-time user creation. |
2. Open the login/signup screen with firstLogin equal to false. | 2. The opened iframe displays the signup screen and has firstLogin=false. The screen displays suitable information for an existing user; the screen does not offer to create a first account. |
The screens support changing multiple parameters simultaneously (optional test).
| Test steps | Expected results |
|---|---|
1. Open an SSO (OAuth) screen with lang=en and theme=dark. | 1. The iframe displays the correct screen, its content is in English, and it has the dark UI theme. |
2. Change lang to a valid Alpha-2 code supported by your brokerage; change theme to light. | 2. The iframe displays the correct screen, its content is in the specified language, and it has the light UI theme. |
The login/signup screen contains the 'Reset Password' button or its equivalent.
| Test steps | Expected results |
|---|---|
1. Open the login/signup screen with firstLogin=false. | 1. The screen displays a 'Reset Password' button or its equivalent. This control can be interacted with. |
Functional testing
A new user is able to pass the user creation flow.
| Test steps | Expected results |
|---|---|
| 1. Open the login/signup screen. | 1. The login/signup screen is opened; accessToken is missing. |
| 2. Type valid data into all fields and complete the signup process. | 2. The broker's backend sends a request to create a new user (POST /oauth2/ctid/create) followed by a request for live trading account creation (POST /webserv/traders), and user-account linkage (POST /ctid/link). The cTrader backend creates a live trading account and links it to the correct cTID. The broker's backend receives a response with userId. The success URL is opened with a valid OT token. |
3. Wait while the cTrader backend sends a request to exchange the OT token for a long-term access token (POST /oauth2/onetime/authorize). | 3. The broker's backend verifies the OT token and returns a successful response containing userId and accessToken (POST /oauth2/onetime/authorize). The cTrader backend authorises the user and returns accessToken to the application. |
| 4. Wait until you are logged into the newly created account. | 4. The user is successfully authorised under the correct cTID; accessToken is saved. |
| 5. Close cTrader. | 5. cTrader is closed. |
| 6. Open cTrader. | 6. cTrader is opened. POST /oauth2/authorize is performed with the accessToken saved during Step 4. The broker's backend returns a correct userId. The user is authorised under the cTID from Step 3. |
A user is able to log in using valid credentials.
| Test steps | Expected results |
|---|---|
| 1. Open the login/signup screen. | 1. The login/signup screen is opened; accessToken is missing. |
| 2. Type a valid email and password and click on the 'Submit' button or its equivalent. | 2. The broker's backend finds the userId of the user and generates an OT token. |
| 3. Check the URL of the success page. | 3. The URL contains the OT token generated during Step 2. |
| 4. Wait until the current iframe is closed. | 4. The application sends a request to the cTrader backend with the OT token. The cTrader backend sends a request to exchange the OT token for a long-term access token (POST /oauth2/onetime/authorize). The broker's backend verifies the OT token and returns a successful response containing userId and accessToken (POST /oauth2/onetime/authorize). The cTrader backend authorises the user and returns accessToken to the application. |
| 5. Wait until you are logged in. | 5. The user is authorised successfully under the correct cTID; accessToken is saved. |
| 6. Close cTrader. | 6. cTrader is closed. |
| 7. Open cTrader. | 7. cTrader is opened. POST /oauth2/authorize is performed with the accessToken saved during Step 5. The broker's backend returns a correct userId. The user is authorised under the cTID from Step 5. |
Traders are attributed to correct partners via the partnerId parameter
| Test steps | Expected results |
|---|---|
| 1. Create a new user in the broker's client area. | 1. A new user is successfully created in the broker's client area. |
| 2. Register the new user as a partner in the broker's client area and receive a unique partner identifier. | 2. A valid partner identifier is generated either at the account or the user level. |
3. Open the login/signup screen in incognito mode with the value of the partnerId parameter equal to the identifier received during Step 2. | 3. The login/signup screen is opened; its URL contains the correct partnerId. |
| 4. Complete the signup flow while using a different set of credentials compared to the one used during Step 1. | 4. The user creation flow is passed successfully (as in the new-user creation test). The broker's client area attributes the new user to the user whose partner identifier matches the partnerId parameter from the login/signup screen URL. |
| 5. In the broker's client area, log in as the user from Step 1 and proceed to the list of attributed traders. | 5. The user sees a new trader in their list of attributed traders. This trader has the same details as the new user created during Step 4. |
An authorised user can make a deposit
| Test steps | Expected results |
|---|---|
| 1. Log into the trading platform. | 1. Login is successful under the correct cTID. |
| 2. Click on the 'Deposit' button. | 2. cTrader sends a request to the cTrader backend to attain an OT token. The cTrader backend sends a request to the broker's client area containing userId (POST /oauth2/onetime/generate). The broker's backend verifies userId, generates an OT token and returns it to the cTrader backend (POST /oauth2/onetime/generate). The cTrader backend returns the token to the application; the deposit/withdrawal screen is opened in an iframe containing the OT token as a query parameter. |
| 3. Fill out the form with correct data and submit it. | 3. The application sends a request to the broker's backend; the broker's backend sends a request to the cTrader backend to change the account balance (POST /webserv/traders/{login}/changebalance). The cTrader backend sends a response with balanceHistoryId to the broker's backend (POST /webserv/traders/{login}/changebalance). The broker's backend returns a response to the application. The user is redirected to the success page. |
An authorised trader can make a withdrawal.
| Test steps | Expected results |
|---|---|
| 1. Log into the trading platform. | 1. Login is successful under the correct cTID. |
| 2. Click on the 'Withdrawal' button. | 2. cTrader sends a request to the cTrader backend to attain an OT token. The cTrader backend sends a request to the broker's client area containing userId (POST /oauth2/onetime/generate). The broker's backend verifies userId, generates an OT token and returns it to the cTrader backend (POST /oauth2/onetime/generate). The cTrader backend returns the token to the application; the deposit/withdrawal screen is opened in an iframe containing the OT token as a query parameter. |
| 3. Fill out the form with correct data and submit it. | 3. The application sends a request to the broker's backend; the broker's backend sends a request to the cTrader backend to change the account balance (POST /webserv/traders/{login}/changebalance). The cTrader backend sends a response with balanceHistoryId to the broker's backend (POST /webserv/traders/{login}/changebalance). The broker's backend returns a response to the application. The user is redirected to the success page. |
An authorised user can create a new trading account
| Test steps | Expected results |
|---|---|
| 1. Open the 'Create New Account' form. | 1. The 'Create New Account' form is opened. The form URL has accessToken. |
| 2. Fill all required fields and submit the form. | 2. The broker's backend sends a request to create a new account. The cTrader backend returns a response with the account login (POST /webserv/traders). The broker's backend sends a request to link the new account (POST /ctid/link). The cTrader backend returns a confirmatory response with ctidTraderAccountId. The broker's backend has a record about the new account. |
| 3. The user sees the success page. The user is automatically switched to their new account after the success page is closed. |
The user is able to switch between login and signup on the login/signup screen
| Test steps | Expected results |
|---|---|
| 1. Open the login/signup screen. | 1. The login/signup screen is opened. |
| 2. Click on a link to proceed to the login form. | 2. The login form is opened. This form contains a link to the signup form. |
| 3. Click on a link to the signup form. | 3. The signup form is opened. This form contains a link to the login form. |
The user can open embedded cTrader Web from the broker's client area
| Test steps | Expected results |
|---|---|
| 1. Log into the broker's client area. | 1. The authorised user sees a means to open cTrader Web from the broker's client area. |
| 2. Access cTrader Web using either of the two possible options (in an iframe or via a link/button). | 2. The user accesses cTrader Web and is authorised inside the application. |
Traders can reset their password via the 'Reset Password' button (or equivalent) on the login screen.
| Test steps | Expected results |
|---|---|
| 1. Open the login/signup screen. | 1. The login/signup screen is opened; it displays suitable information for an existing user. |
| 2. Click on the 'Reset Password' button or equivalent. | 2. The button is clickable and a password reset is requested. |
| 3. Receive a new email containing a link to resetting your password. | 3. A valid email is received containing a password reset link. |
| 4. Follow the link and complete the password reset flow. | 4. When clicking on the link, the user is redirected to the platform. After seeing the confirmation message, the user is automatically authorised inside the platform. |
| 5. Open the login/signup screen. | 5. The login/signup screen is opened; it displays suitable information for an existing user. |
| 6. In the 'Password' field or equivalent type the password chosen during Step 2 and proceed with authorisation. | 6. The user is authorised inside the platform. |