It became much quicker but, we were scratching our heads on whether we could tick off our weekly manual release testing task altogether:
- manually testing repeated scenarios is not efficient (we have not spotted any Stripe bugs lately)
- none of us recalls ever having spotted a Paypal bug during release testing
- VCR coverage does not consider browser interactions
- We’d need to test Stripe on the browser level to assure our code deals with Stripe errors correctly
How to improve test specifications on PRs? Sometimes, specifications are absent or incomplete which makes testing less time efficient.
Should we have a change of process? And include a review step from a tester, when new issues/features are created?
Also, the (previous) discussions on:
- having an test acceptance framework. How could this improve the situation? How would it affect our build speed?
- improving/extending seed data. One of the last significant changes was this PR. We still have not changed the names of our users! We should open tech-debt issues on scenarios we’d wish to bring onto staging, so we don’t have to repeatedly set them up. Some examples: invoices, vouchers, subscriptions…
Still on the looking at 2024 topic, how would this fit in the goals for that year? What’s the first task to be addressed? Also here, the question was raised on how to set up smaller goals so we’re able to tick them off.