The Quality Assurance phase will usually be done after the dashboard development is done and the data is validated, and before the User Acceptance Test (UAT).
For more information about these phases please see the following:
In this part of the project, the developer will test the functionality of the dashboard and make sure all key functionality works as expected in both the system higher level and on the dashboard level.
Following is a list of suggestions to test and assure the quality of the solution developed.
On the system level, the following should be addressed:
- Access to the environment - The users have access to the environment using a login email and password or via SSO - They are able to log in and see the dashboards shared with them.
Tip: To better understand the user experience of the dashboard, logging in as different users from different roles, and see how they are viewing and interacting the dashboards.
-
Active Directory - Login from different AD users to make sure access is possible and that the right permissions are given to each user (Sisense role, Data Security, etc.)
-
System configuration - Go over the definitions and make sure they are updated with the appropriate selections
- Emails - Test the different scenarios where you expect and do not expect to receive an email. For example, create a new user and share a dashboard with them. Check that the relevant emails are received in the correct format (if it was white-labeled for example)
-
Pulse - set test Pulse alerts to make sure the threshold is set appropriately and that the triggers are sent successfully via email / Slack / Zapier or other platforms.
- PDF reports - For dashboards that are meant to be shared in a PDF format, test the PDF export, and make sure all the widgets are well organized and visible in the report.
- Mobile - When relevant, test the mobile access to the dashboards. Test login process and dashboard look and feel. Make sure all plugins are working as expected.
Tip: Dashboards that are meant to be shared as PDF reports or for mobile may some times need to be organized differently then dashboards that are meant for dynamic interaction by the end-users within the platform. For that reason, it is recommended to have designated dashboards, that are designed specifically for PDF reports or for the mobile, that are separate then the ones you expect users to be login directly from the platform.
On the dashboard level:
- Make sure drillable dashboards that are used in plugins like Jump to Dashboard and Accordion are also shared with the end-users that are supposed to be able to access them
-
Drill hierarchies are set as expected with relevant fields to drill into, and disabled wherever not needed
-
Filters behaving as expected - For example:
- Single Select VS Multi-Select
- No unexpected numbers or spikes when using the filters (that can suggest a Many-to-Many caused by the filter, or an RI issue in the data)
- Cascading Filters are properly defined and working as expected
The feedback from the QA testing should be transferred to the dashboard developers or system admins according to the area in the product that was tested for further review and correction wherever needed.
