The feature was supposed to switch between two screens, let’s call them “SCI” and “SCH”. I found 13 bugs not looking just for SCI / SCH, but going what I imagined as user flows, spontaneous ways and applying some of my experience.
- Icon for SCI screen was not updated
- Instruction text was not updated
- Invisible control: Interactions with input in bottom of SCI screen were not possible or possible only partially, because of overlapping invisible control. To catch this bug one had to add special settings for SCI.
- Too long time to the next screen from SCI for clients (because of merge error app was requesting all the type S data from organization instance)
- Empty SCI screen appeared after sending app to background and returning back
- Lock screen appeared if app got put to sleep after pressing power button (app should not be locked in SCI mode)
- After timeout exit on passage app returns to screen SL, not SCI
- (minor) After updating SCH data order of data with the same time may change in SCH.
- (crash) SCI with multi-source data -> SCH -> choosing the same client again -> cancelling -> crash
- Multi-source SCI does not result in successful passage if first source chosen has no SCI option set
- (minor) Timeout action cleaning data from SCI screen does not close dialog “Whoops!”, what may create confusion for the next client.
- After attempt to fix issue 10 app started to crash on Multi-source SCI screen for type of client
- Old issue for SCH screen display with specific test data
and there was 14th not found by me (found later by other tester):
14. If only one source selected in Choose multiple sources, the next screen does not start in the chosen mode
Nothing “cool” is meant in this story. The story is about how non-standard, non-“factory” methods reveal a lot of things “factory” methods don’t.