The chaos testing session aims at stressing the application by setting the world around it on fire, and observe the behaviour and maybe discover bugs.
The intention would be to chip away and replace the need for this with automated tests and other things. But for now we do this to help us feel confident in our releases.
Things to try:
[ ] Tampering with network connection while sending transaction.
Are the error messages good?
What is the user experience? Is it consistent ? How does the front-end react ? Is it lost in the void ? Is it in the transaction history ?
What happen when we reestablish the network connection ?
[ ] Close the application in the middle of an action (sending transaction, wallet creation).
Does it crash ? Does the apps receive proper feedback ?
When re-opened, what's left from the last session ?
Is the UX consistent ?
[ ] What happen when the user tamper with the wallet files ?
Are the error messages good ?
Does it crash ?
[ ] What happen when the user tamper with the network files ?
Are the error messages good ?
Does it crash ?
[ ] What happen when the user tamper with the app and service config files ?
Are the error messages good ?
Does it crash ?
[ ] What happen when another wallet service is running on the machine (CLI, or desktop) ?
[ ] What happen when the application cannot access the config folders when deleted? And when their access is restricted ?
[ ] What happen when the wallet files are deleted whil waiting for a review in the app ?
[ ] What happen when the screen resolution is super super low ? Can we still read all the text ? Can we still scroll everywhere to access content, or is the app "locked" ?
[ ] What happen when we spam-click buttons to create or import a wallet, switch network ? Does it correctly prevent multiple submissions ? Does it raise errors ?
[ ] What happen when we have 100 of wallets on screen ?
[ ] What happen when we have 100 of networks on screen ?
[ ] What happen when a wallet has 100 of keys on screen ?
The chaos testing session aims at stressing the application by setting the world around it on fire, and observe the behaviour and maybe discover bugs.
The intention would be to chip away and replace the need for this with automated tests and other things. But for now we do this to help us feel confident in our releases.
Things to try:
[ ] Tampering with network connection while sending transaction.
[ ] Close the application in the middle of an action (sending transaction, wallet creation).
[ ] What happen when the user tamper with the wallet files ?
[ ] What happen when the user tamper with the network files ?
[ ] What happen when the user tamper with the app and service config files ?
[ ] What happen when another wallet service is running on the machine (CLI, or desktop) ?
[ ] What happen when the application cannot access the config folders when deleted? And when their access is restricted ?
[ ] What happen when the wallet files are deleted whil waiting for a review in the app ?
[ ] What happen when the screen resolution is super super low ? Can we still read all the text ? Can we still scroll everywhere to access content, or is the app "locked" ?
[ ] What happen when we spam-click buttons to create or import a wallet, switch network ? Does it correctly prevent multiple submissions ? Does it raise errors ?
[ ] What happen when we have 100 of wallets on screen ?
[ ] What happen when we have 100 of networks on screen ?
[ ] What happen when a wallet has 100 of keys on screen ?