mardi 26 avril 2016

Software testing in time travel - importance of local time

As a software tester I came to an incident regarding testing on platforms with time travel. (the time can be set manually to past/future according to requirements of tests)

So the application time doesn't have to be same as my local time .... or should it be the same?

I found a bug that was caused by inconsistency between my local time and app time. Simple description: There are two validations. Validation #1 validates user input on client side (and is using local date for validation) and validation #2 validates user input on server side (and is using server date). Both validations are according to business rules that are specified in project specification. (it does not specify whether it should run locally or on server side) When there is inconsistency between those dates, it produces unexpected results.

However the bug was rejected by development that my test was wrong and that it's client's responsibility to synchronize those two dates.

Honestly I don't see reason what my local time has to do with application behaviour. There is lot of functionality and rules and for all of those is used server time as reference point. But because of that client side validation which is done by javascript the reference point is local time (because it's default behaviour, it's not intentional).

So I am just asking about your opinion. Do you think it's a bug or it's my bad understanding of importance of local time? How are you used to handle this things in your projects (as tester or developer)? This is not just issue of testing and server time travelling, but what about client "time travelling"? (eg. different time zones). Do you put any kind of efford to handle this things or just believe, that "bad local time = client problem" and that's not problem of development?

Aucun commentaire:

Enregistrer un commentaire