Automated testing

Way of Working Improvement

Summary

Integrate automated testing in development process SURF Access.

Problem: What is the pain point?
Testing is only done manually at the moment.

Value: Why should we build this?
Support testing and improve testing outcomes with automated testing.

Proposed Solution

With every new feature being developed for SURF Access, if it is large enough to include a GUI component as well, a Playwright test is written as well, to prove that the new feature works as expected.

Playwright is optimized for ease-of-use, so making a new test should be little extra work for the developer working on the feature (Playwright includes a recorder as well, with which you can click through your application while Playwright generates JS code). Also, this should make it more easy to check and approve PR's as well, because as a (T)PM you should be able to read the Playwright script and verify that there was no ambiguity between what you meant when creating the issue, and what the developer has delivered.

The context in which to run the Playwright script is something to consider. You could run it on the isolated frontend, while mocking all the API endpoints, but you can also use it to test integration with other components, for instance with the API, database, test IdP's, a mailserver, etc. The more realistic the tested environment is, the more useful, but the more time and complexity (i.e. TPM effort) it will probably take up.