Arguably the most important aspect of system development is testing. That's why for years we have embedded testers right in the middle of our development teams. They work shoulder-to-shoulder alongside developers, providing a QA focus on user stories even before they are built.
Just testing the user interface
In our experience of building complex user interfaces we have found that testing the user interface away from real back end services is extremely valuable. If you have ever tried to test against a real test environment with real services, you will know that it is fraught with difficulty. Test environments by their nature are fluid and inherently unreliable.
Some of the most important tests you can perform are testing during failure conditions. What happens if the service you are talking to crashes or disconnects? What happens if messages arrive in a different order? What happens if messages arrive slowly? Or not at all? These kind of test cases are very difficult to test reliably in an integrated test environment.
Our experience has shown that simulating the service layer and providing a test API that controls the failure conditions is a really good way of ensuring that the user interface works in all scenarios. Test conditions can be set up in the simulator which can then be tested against using the UI tests.
During the lifecycle of an application's development, it needs to be tested thousands of times. Automating your testing provides a high return on investment. We have found that using tools such as Cypress with a cucumber style test language and a simulator that allows the server side failure cases to be controlled is a great way to test your user interface.
We use BDD statements which are understandable to the business. Some of these statements are designed to describe certain failure cases, which can be sent to the simulator to set up the right conditions for the test. We then test that the UI behaviour is correct in this situation (showing an appropriate error message for example).
We then use some of these tests as an automated check out after each release. The business are no longer required to login to check out the environment - if the tests pass then the release is good.
Automated visual testing
We have also found that automated visual testing can be useful. By taking a screenshot and comparing it to a known good image it is possible to ensure that the visual design of the UI remains as expected when changes are made to the application.
If you would like help with your UI testing approach, we can help you. Please contact us to talk about your project.