Closed pennyandrews closed 1 year ago
So before I can properly pin down anything for this individually, it would be good to have a walk through of the release process we have at the moment? Is there anyone that fancies showing me or pointing me to some docs? I do have some general high level thoughts here though which are...
All automated tests for the release must be green, I think our tests are small enough to all be run at the moment, is that correct? In future if it gets incredibly large then maybe we can filter, but ideally we keep things efficient enough to run them all.
Exploratory tests as mentioned, I think over time we should look to be sufficiently covered by automation so that it is only edge cases we are trying here, the kind of test cases that we cannot automate or do not believe should be automated. I think in general we want to be in a position where if our test runs are green, we are 99% sure wallet is OK, exploratory testing is really just trying to find weird and wonderful ways to break our software.
Further to point 2, I think we could target our exploratory tests based on areas of impact over the last sprint if we are in a situation where we need to be swift (if we are indeed releasing once per sprint)
Do we have any slack integration for releases? Would be good to send out a notification when a release goes out with a link. I know that kind of thing is doable if it is not in place already
Regarding the spike, I am assuming that in wallet we could probably mock something pretending to be the network with an update and check the wallet gets the notification if I have understood correctly.
Largely I think the points for core are pretty applicable regarding release notes, linking releases etc. Sorry, I appreciate this is not a nailed down list!
Tasks
@smoke
tests@regression
tests@slow
testsrelease/[network]
to tagged commit