The web application I’m working on writing automated tests for is basically a platform that allows a lot of user configurability.
You can think of something like Salesforce.
Essentially a no code platform.
This means in a lot of test cases there is a lot of dependent state that needs to be setup and in place to actually execute the test case then of course that state needs to be cleaned up after the case runs.
For example if I want to be able to test that a user can make a field in an app private by role I’ll need to create the role, create the app, create the field in the app, and then actually execute the steps for the test then clean it all up.
Does anyone have any experiencing writing a test suite for this type of app and have any advice to offer about the best way to approach something like this?
Or maybe just lessons learned they’d be willing to share?
This thread is trying to answer question "Does anyone have any experience writing a test suite for a highly user-configurable platform and have any advice to offer about the best way to approach something like this?"
An experienced QA colleague of mine once mentioned that testers often don't apply 'test design' when thinking of automated tests.
I think this is a case where you need good 'test design'. Using test design techniques to reduce the number of scenarios but still achieving good coverage and confidence.
You could have a limited number of scenarios, each fully setting up a different 'app', and each testing a different combination of features that you need to cover. Like 'whether some field is only visible for a certain role'.
Also don't forget the other types of testing, like unit tests, integration tests, service tests, component tests, API tests, etc. The whole dev team (QA included) is responsible for test coverage. The end-to-end tests should only be the tip of the iceberg.
Rayrun is a community for QA engineers. I am constantly looking for new ways to add value to people learning Playwright and other browser automation frameworks. If you have feedback, email [email protected].