Important use cases are not tested

With a small change (styling, new fields) during the development lot of Use-Cases can crash. To avoid the high effort of the testing all the important cases, testing should be automated. Tools like Selenium provides an capture and replay mechanism. Build servers (Bamboo) can then be configured to start the test on if something gets merged into the master branch.

No logging of user behavior

When the application gets delivered to the client for the test production, there are usually exists bugs. The testing user creates BugTickets, with the necessary information‘s what was wrong during their test run. For lager workflows it‘s not possible to provide all the information‘s (selections, inputs) during their testing. It‘s necessary to provide a logging service to provide all the steps during the test. Kibana and Zipkin provides a tool to publish this huge amount of information.

No Updates after Switching View Many Times

A single-page web application was getting push updates via SSE. Each view used a different SSE resource from the same endpoint. After a certain amount of navigations via the main menu, no updates would be displayed anymore. This problem seemingly did not occur reliantly at first but as it turned out it would occur exactly after the seventh view changes (navigating 7 times via the menu). Every time a view is opened, its controller requests the respective SSE resource to get updates for the view. I was able to confirm this behavior on the API proxy which logged every request URL. But for any view change after the sixth view change, no request URL was logged which could only mean that there actually was no request coming in, despite the web application logging that it was requesting said SSE resource. Next I tried to replicate this behavior without the web application by just requesting the same SSE resource via Chrome multiple times. As it turned out, the seventh request never made it to the API proxy until I closed another open tab to the SSE resource. The reason was that Chrome only allowed 6 concurrent requests to the same endpoint and the actual web application never closed the connection for a SSE resource. Closing the connection when changing the view solved the problem.
Subscribe to angular