shame to my tester or me?
-
I start a project in 2nd april, i finished it 8th april, the tester tested the project and pass 9th april and client get happy on that, suddenly in 13 april my project stop sending data, which is one of its main functionality. i was wonder why why my code works only 5 days, what happens, there is nothing changed why data was not sending now. suddenly i discovered what was the fault, because from 1st may it again start to work and i am confident it will work until 12th may, and then it will again stop :-O :-O :-O . i think u already get the hint, problem was date time format in server and client side. mm-dd-yy and dd-mm-yy , for that it will only work 1st 12 days of a month, not bad :D
Shame on you, and your tester too. We should follow the system when using date and time. The display format is only for presentation. If your code is going to send data all over the world, what is the right format?
-
I start a project in 2nd april, i finished it 8th april, the tester tested the project and pass 9th april and client get happy on that, suddenly in 13 april my project stop sending data, which is one of its main functionality. i was wonder why why my code works only 5 days, what happens, there is nothing changed why data was not sending now. suddenly i discovered what was the fault, because from 1st may it again start to work and i am confident it will work until 12th may, and then it will again stop :-O :-O :-O . i think u already get the hint, problem was date time format in server and client side. mm-dd-yy and dd-mm-yy , for that it will only work 1st 12 days of a month, not bad :D
First shame on you. When transfer any data over the wire, you should it do it in a system independent format. When for some reason it is impossible to do that, you should take system differences in account. That is: verify what differences there are and (unit)test you're code against the whole valid range and handle invalid data. Shame on the tester to, he also should be aware of difficulties in the domain he is testing. But most of all shame on you. A developer never can hide behind the the tester (or even the architect). He has it's own responsibility to make the software work, without errors.
-
I start a project in 2nd april, i finished it 8th april, the tester tested the project and pass 9th april and client get happy on that, suddenly in 13 april my project stop sending data, which is one of its main functionality. i was wonder why why my code works only 5 days, what happens, there is nothing changed why data was not sending now. suddenly i discovered what was the fault, because from 1st may it again start to work and i am confident it will work until 12th may, and then it will again stop :-O :-O :-O . i think u already get the hint, problem was date time format in server and client side. mm-dd-yy and dd-mm-yy , for that it will only work 1st 12 days of a month, not bad :D
My vote is for the tester. You're a programmer, you're expected to screw up. :laugh: The tester passed your code in one day. You might have 100 more bugs lurking in your code. (Which could still be true after 100 days of testing.) Just think about sending yy-mm-dd, your code could still be humming along fine for 19 years. (I'm guessing someone might eventually notice the dates don't match/make sense.)
-
Shame on you, and your tester too. We should follow the system when using date and time. The display format is only for presentation. If your code is going to send data all over the world, what is the right format?
Eugene Peng wrote:
what is the right format?
For an established receiver of data, the right format is the receiver's format. Shame on the receiver if they didn't supply the format to begin with. Testers exist because it is a known problem that coders write bugs. It is the tester's responsibility to assume the programmer screwed up and find out where (s)he did. The fact the test period was only one day puts nearly all the fault at the tester's feet. (s)he didn't even have time to build a valid case model for testing. You as a coder have a right to slap your own head, say "What an idiot", and fix the bug. Reminds me of a bug I created. Wrote an app to clean up a table by truncating it when it is a week old. Supposed to run 5 minutes before midnight. So I scheduled it to do so. Forgot the date was UTC. Should have scheduled the job to run at 3:55 PM and coded the logic to sleep until the UTC time was reached. (UTC is 7 to 8 hours ahead of my local time.) The tester caught it on my last day of work. Over a year later, I'm reading proposed changes another group was making. My former group. They were adjusting job schedules to be based on UTC time and offsetting the start time based the former time setting because the app was moving to a different time zone. I had to explain to the head SQL person there is a bug written against the app, he needed to set the UTC time to run at 22:55 UTC instead of 07:55 UTC, it will run 5 minutes to 2 hours early depending on when the scheduling job code runs and the code needs to be modified to wait until 5 minutes before UTC Midnight to run. Everyone makes mistakes. Checking for valid date information being passed is 101 testing. (It is the programmer's job to do 101 testing as well as the tester's job to not believe (s)he did anything right.)
-
Oh, that's definitely true. And it sounds like it was a relatively low tariff place to make the mistake (easy to notice, easy to find the cause and fix, not a critical system), so all's good in the end. But it is more a tester mistake than a dev mistake, in my opinion.
IMO it's a beginner programmer's mistake - anybody who has ever done a web app has learnt this lesson the same way. It isn't often that testers find this type of error - usually programmers, or whatever library or framework they use take care of this.