7. Testing
Navigation
Throughout the project, functional testing was performed to ensure the app was running properly and adhered to the standards set at the start of the development process. In terms of appearance, the website maintained consistent branding elements across all pages. This involved checking the logo placement, font styles, color schemes, and overall visual identity to create a cohesive user experience. The layout of each page was carefully examined to ensure proper alignment and spacing of elements. This involved checking for any misaligned text, overlapping components and uneven spacing across all pages.
The PWA was an essential selling point for potential clients, so it was vital to test it on different screen sizes and multiple OS’. Members of the group were assigned tasks to test on multiple devices and OS' which aided in identifying and remedying elements that were distorted on different screen sizes. An important difference discovered between MacOS and Windows specifically was that several HTML default elements would render differently depending on the OS. This meant that several classes in HTML, such as the scrollbar, were redesigned to maintain the same aesthetic.
The application is intrinsically linked to user interaction and as such, the implementation of robust error handling mechanisms was imperative to address instances of non-parsable data entry by users. To achieve this, error handling was executed using strategically placed <p> tags, which would render in cases of a incorrectly formatted input, serving the purpose of communicating instructions to the user. Alternatively, exceptional scenarios were managed via the generation of specific exceptions when encountering connectivity issues with the Graph API.
The application was tested across multiple web browsers to ascertain consistent performance and visual presentation. This comprehensive testing regiment played a pivotal role in identifying and rectifying potential JavaScript errors and functional disparities. Additionally, it ensured that the application responded uniformly when subjected to alterations in screen size, thus ensuring a consistent user experience across diverse devices.
Functions were tested independently prior to their integration with the corresponding page. By decoupling UI development and functions, parallel development was possible which streamlined development. It was beneficial to perform unit testing as it assisted in identifying exactly where the issues were in the code, hence minimizing the debugging effort. Then integration testing was performed to ensure the UI interacted correctly with the functions and the page was rendered accordingly.
| Metric | Definition |
|---|---|
| FPS (Frames Per Second) | It measures the speed in ms at which the browser is able to recalculate, layout, and paint the display. |
| Loading | This measures the time it takes for the complete web page to show on the screen. |
| Scripting | Measures how long it took for the client-side scripts to execute on the page. |
| Rendering | Rendering & How long till the page loads so that the user can begin interacting with it. |
| Painting | Painting & The time from where the page starts to load to when any part of the screen is rendered. |
| Idle | How long it is until the page is ready for user input. |
- The dashboard page FPS can be calculated by dividng 1 second by the average millisecond frame response time obtained from the frame section. This comes to
17.99 FPS}. The idle time represents time where the GPU is waiting for a response from Graph and does not compute anything. - The overview page FPS is calculated to be
28.82 FPS. - The calendar page FPS is calculated to be
28.82 FPS. - The Application Tracker page FPS is calculated to be
76.92 FPS.
- However, the application tracker also had several dropped frames. This most likely due to the page requesting information from the back-end and pausing temporarily to display this data on the from end.
- The SmartScribe page FPS is calculated to be
20.75 FPS.
As shown in Figure 8, a significant section of the loading time is idle. This is because the website is waiting for the response to the graph request and as such cannot load anything until the response is received. A similar test was done on the website running on localhost and the scripting time was significantly lower and the FPS response time was significant higher, reaching over 100 FPS consistently. The latency from the Azure host most likely contributes to this discrepancy.
Figure 8 (a) to (e): Performance metrics for all hosted pages. Dashboard, Overview, Calendar, App Tracker and SmartScribe