validateOTP, which takes otpcode and validates it.
validateB, which takes B and validates it.
validateA, which takes A.value (that requires a call to a remote server to fetch the data)
validateC, which takes C and validates it.
Finally,
if everything done successfully, we should get "Success"
else
we should get "failure".
The problem is that in some devices, the step 4 is getting skipped totally. i.e user isn' getting frontend to enter "A.value". It's directly asking user to enter C.
What's being observed
The issue is independent of the operating system(android or ios).
The user/A being tested is the same, only devices are changing.
If once "success" comes in a device, it'll keep coming success no matter how many times I repeat the experiment.
If once "failure" comes in a device, it'll keep coming failure no matter how many times I repeat the experiment.
Why's that 1 step being skipped? Please give me answers and where to look, I've already took a look at logs but unable to decode anything out of it.
Disclaimer: I am not the developer, and this is not a part of my job. I just want to understand about the other department work as well. So just guide me towards the possibilities.
speak with the developer(s) in the first instance.
there are any number of reasons for unexpected behaviours, especially after problems are encountered, in no particlular order (or assumption of completeness) some of :
review state transition diagrams/logic, code reviews (particularly around 'edge/asynch/threading') etc ....
transition between states may be unsafe - edge/conflicting/untested/ conditions not handled.
is the machine 'properly' initialized , especially important after issues - any/all caches need to be cleared, particularly if interacting with external resources.
are there asynch events/interrupts/signals that could interfere and throw logic processing out of sync
is there sufficient error/exception trapping/handling/logging logic - you say you've looked at logs and nothing found, maybe more (fine grained) logging is needed
if the app is multi-threaded/concurrent - poor synchronisation of events are well known to cause 'unexpected' behaviour, test coverage should cater for these.
check boundary conditions and be sure edge/ boundary scenarios are catered for
has there been adequate testing/test-cases/coverage - including error scenarios that recreate skipped steps
and more
do you have colleagues ? if yes, then get in conversation with them around stuff like this. discussing with teammates is a great way of gaining and sharing knowledge.
in addition to @munkeHoller's detailed suggestions, the problem could be also network/netfilter related:
It's noticeable that (according to your description) step 4 is the only one that requires a remote/external call. Which port is needed for this? This outgoing port may be blocked by a packet filter/firewall somewhere along the way (e.g. hotels often block all ports other than https/tcp/443) to the target server. Or a deny list of source IP addresses (i.e. the adresss of the last NAT-Gateway (Network address translation - Wikipedia) resp. Router in between) is checked on the target server. Or ...
But apart from that, IMHO it's a bug that the whole process won't fail if step 4 fails and/or its return code/value resp its call isn't checked correctly (i.e. step 5 should automatically fail in that case. Or maybe did I have misunderstood something).
yes we've discussed all possibilities with colleagues. I'm just trying to understand the things you said here Thank you. I'm learning something called "system design" by alex xu and these distributed computing concepts come handy.
Thank you. I'm learning something called "system design" by alex xu and these distributed computing concepts come handy..jpg){kind=link}