- SAP Managed Tags:
Sometimes we wonder, if a common man who does not know our SAP software product would be able understand our product or not.
For this reason, we can try to give our product to a person who has never tested this particular product before, a random person who is not a native of our product or the application. This kind of testing can be named as “Non-native Usability Testing”.
This testing can be considered as a method of black box testing; where a “random person” or a “non-native” person is involved in the testing of a product, so that we understand the difficulties that may be faced by our end users.
This kind of testing would give us an insight on how a random person would see our software product; would he/she be able to understand what exactly should be done?
This kind of testing is applicable for testing mainly for Portal applications and Fiori apps.
Many of us are testing the SAP Fiori apps and portal applications, by gaining the functional knowledge from the topic experts. But what if an end user who tries to test these applications without any knowledge? How would he / she go about testing these applications?
Due to these reasons, we can ask our own testers who do not have any insight or an idea about the product, to try their hand at it. We can consider these testers as “non-native people” as they would not have any kind of knowledge about these applications. This test can be performed for a specific amount of time, say 1 hour. The main idea is to check how comfortable it is for the end users to work with our applications.
When a random person tests our application, we may find Usability Issues due to which the user may not understand how to proceed with the testing.
Another way to perform this test can be of a paired approach. We can have 2 testers sitting together, where in one person has knowledge about the application under test, and another person who has no knowledge about the application under test. Both can sit together and test the same application. The person who has knowledge can check for any functional issues that may occur, and the person without knowledge can check for usability issues.
Issues that we may find by using this approach of testing:
- We may find issues related to mandatory fields, which might not be highlighted in the fiori app or the portal. The end user who does not have knowledge of the mandatory fields may find it difficult to test if the mandatory fields are not highlighted in the app.
- In case of fiori app, “delete tiles” option may not be provided in the devices. This would result in N number of tiles getting created, and no option to delete them. The end user may get confused seeing so many tiles and would want to delete some of the unused tiles.
- Another issue that we may face is, when we ponder the mouse around a particular field, it may not display the field name. A person who knows the app will be able to understand what field that is, but a person without any knowledge about this app may wonder what the field is.
- If we are following the paired approach of testing, as specified above, we may also find functional issues, along with usability issues.
- When we get an error message on the status bar, the error message should provide us detailed information of the error, so that the end user will not assume that this issue is a bug.
- We may also find some unwanted empty spaces in our application and the end user may wonder why that empty space exists.
Steps to be followed:
- Enter the link for the application under test.
- It launches the log in page. Enter the user credentials.
- Missing delete button in the application.
- Click on any tile and ponder over any one of the fields. It should display the details as highlighted below.
- Test for error messages, and check that they provide the end user sufficient information to go about solving the error. In the below snapshot, the date field was not entered, hence the system should provide information to the end user to enter the date field.
Advantages of using this kind of testing include:
- Maintenance/support costs would be reduced, as the software will be self-descriptive and the end users may not come back to us with doubts.
- Knowledge transfer to the end users may reduce, as most of the fields are self- descriptive.
- Unnecessarily raising internal messages can be avoided if the error message provides us the detailed information about the error.
- If this kind of testing is done at the development phase itself, it may reduce the development costs, as the software would be developed accurately at once.
- By executing this test we can know the user expectation from our software.
