Page Comparison

Performed by IQX Business Analyst and Business User or BA

Functional requirements define what the system does or must not do.

Target devices (laptop / desktop / 2-in-1s / Pad / phone)
Theming / Colours / Logos

Assumptions

Expected Volume
User experience (restrictions / guidelines / client needs)

Non-functional requirements specify how the system should do it. These includes the following:
Target UI5 version
Target browsers
Deployed to cloud / on-premise
Fiori LaunchPad or FAB LaunchPad
Scanners to be used?
OCR to be used?

Performed by IQX Business Analyst or Test Specialist

High-level scenarios that answers “What do we need to test?”

Performed by IQX Business Analyst or Test Specialist

Test Cases are the set of positive, negative and exceptional executable steps of a test scenario which contains the following:

Pre-conditions, Test data, Expected result, Post-conditions and Actual results.

Performed by Business User

Test Data that covers all positive and negative Test Cases.

Performed by IQX Business Analyst or Business User

Complete flow, including all variations / paths.
Identify possible system tasks where the user that does the approval does not have the rights / auths to execute the next step.

Performed by IQX Developer and IQX Business Analyst
Do not use a generic OData service for multiple tasks.
Rather create specific services, each of which can be secured with its own role(s).
Separate functionality by role
For example: Create 2 services for ‘Create’ and ‘Approve’ if they are likely to be executed by 2 different roles
Consider redefining the IQX FAB service so that a separate role can be created specifically for the app.

See documentation Redefine FAB OData Services for Security Reasons.

Performed by IQX Developer

This should be limited to ‘cosmetic’ checks, like:

Validity of e-mail address (includes an @ and <period>, etc.)
Regex or other checks for fields that need to satisfy a specific pattern
Type and content validation (integers, numbers, string length, and etc.
(Note that this will likely be validated again on the back-end)

Performed by IQX Developer

All authorization checks
All business rules/validations
All checks for data correctness (before passing to a BAPI or persisting in a table)

Performed by IQX Developer

Storing any sensitive data in the Data Model is not advisable.
If sensitive data has to be stored in the Data model, the developer has the option to use methods inherited from the FAB Base Class to:
1. Encrypt the data before sending to the front-end.
2. Decrypt the data before using it in the back-end.

The developer can tick the ‘Encrypt Data’ checkbox on the Project Properties page to prevent sensitive data from being persisted in the FAB tables.

Performed by IQX Developer

When calling a FAB Action, limit the amount of data being sent.

Performed by IQX Developer

For example: //# sourceURL=journal_upload.js
This line of code has to be deleted before it is moved to production, as it gives a developer the ability to change the code during run-time.

Performed by IQX Developer

Local Storage in browser inherently insecure and possibly shared with other apps.

Performed by IQX Developer

Avoid doing SELECTS with no consideration of the data that might be retrieved.

Alternatively strategies might include:
1. Using BAPI’s or other standard SAP-provided mechanisms to retrieve data. Auths are checked in BAPI’s already.
2. Checking a user’s access or performing manual authorization checks and using the results to filter the data.
3. Do not extract all the data and apply a filter but rather build a Range (or set of Ranges) of acceptable values. Use the SELECT statement to retrieve only valid values.

Performed by IQX Developer

Avoid using Standard Search Helps and use OData service instead where you can control the data that is returned (auth checks, business rules, etc.) and secure the OData service with authorizations.

Performed by IQX Developer

Read and follow the SAPUI5 Securing Apps Guidelines.