This pretty much summarizes how I feel about the latest enhancement I am involved in. Add new functionalities to an existing screen that had already been in use for a few months. Sounds simple, doesn't it? Afterall, somebody else had laid the foundation and since it has been in use without complaints so far, it must be rather stable. Not to forget, our layers of QC.
Developer -> QC tester -> UAT
Not when you have people doing like what Rambo is doing now, laying a trap.
After completing my enhancement with 100% confidence that there's no way I could have broken the existing functionalities, I performed my own testing and passed the buck to the QC tester. Found some bugs, fixed them, and proceeded to UAT.The users came back to us with a bug list. Some of my own doing, but there are also bugs that have slipped past the above QC process undetected the first time the screen was rolled out. More appalling is that the latter outnumbered the former.
And it's not some hard-to-encounter bug. They are so obvious that they should have been uncovered the last time. Previous developer sleeping, previous QC tester sleeping, and best of all, previous users sleeping during previous UAT, waiting to 陷害 the suay developer for this enhancement.
Unfortunately, the same logic could be applied to me. At the meeting to discuss the bugs (according to experience, the bugs can be real, data anomaly, or users simply forgot what they wanted), the QC tester, L (the same person who tried to sell me The Bio Disc) remarked that I should have done thorough testing. Well I did, on my part! I didn't think that I was expected to retest every single thing all over again, on top of mine. L didn't find the bugs herself too, didn't she? But with the meeting agenda in mind, I wasn't interested in pinpointing the sole responsible person and so wasn't the TL. We just want to identify the actual bugs and fix them fast. Don't know why she has to bring that up! We will all get hurt if she probed. Anyway, PM also not probing, so why was she doing so?
One of the issues was when copying multiple rows of values, I displayed the first row because
1) it's existing logic
2) it's not mentioned in the specifications that it should be changed
3) it's been in use since x months ago and nobody made any noise
4) there was only space for one
There's no reason for me to suspect it's a bug and raise for discussion.
So now the user felt it is a bug because it may result in data-entry error, which as for why, I wouldn't go into detail. I told L #1 and #2, but somehow she interpreted it as me accusing her specifications of being unclear (she wrote it). The part where the bug occurred is right at the last page of the specifications, so she decided that she needed to reexplain the WHOLE specifications to me ALL OVER AGAIN! Even the front part where no bugs were found! I protested, but she said she needed to make sure I understood the front too, since they are all interconnected. I gave my TL the "help me" look and he intervened, probably because he didn't want to sit there waiting for L to finish the unwarranted lecture. *Phew*
The conclusion was that L was to ask the user whether they wanted to retain the current behavior or change it. L did so and sent out an email saying we would change the behavior as discussed. Black and white! I made the change, which was only an addition of 2 lines of codes, very easy. The tough part was having to write an impact analysis document and unit test case document. So troublesome lor. And not even my fault $^&$%#$@. I sent the "bug" for deployment.
Later in the day, the slow-to-react users replied the email.
"I thought we had agreed to retain the current behavior?"
W...what?
L replied:
"Yes, we had agreed to retain the current behavior, but later I sat down and thought, what if this scenario happened... *blah blah*, therefore, I feel it is better to change it"
WHAT FUCKING CRAP! YOU DOCUMENTED WRONGLY, JUST ADMIT IT!
Commenting out the 2 lines of code is not difficult, nevermind. I'm ranting because now I have to write yet another set of impact analysis and unit test case for this reversal!
ARRRGHHHH!!!!
The user reported another bug about inconsistency in system behavior. The user keys in some setup data and specifies a date for the setup to take effect. She found that sometimes the date would be saved as 1 Jan 2000 instead. After investigations, I found that the team lead had patched all old data to start on 1 Jan 2000. Judging from the transaction dates, I concluded that the user had mistook the old data for the one she newly added.
I told L my conclusion. But L thought it wouldn't be possible since the user is a very careful person and has more experience in the system than all of us combined. People do make mistakes, don't they? I showed L the overwhelming evidence. It's up to her whether she wanted to tell the user the cruel truth or sugarcoat it.
L: I'm thinking if it's possible that the TL changed the date to 1 Jan 2000.
Me: He patched the data first, then the user tested right? So that date must have existed before the user did that. Moreover, look at the transaction date, this 1 Jan 2000 was added in 2007. Look at this other row with, the transaction date corresponds to that in the screenshot, so I think the user actually added this row. She see wrongly lah.
L: No, what if TL patched the date to 1 Jan 2000 after the user added?
Me: Why would he want to do that? Unless there's another round of data patching, but no need for that right?
L: *shrugs* How would I know him?
Me: o_O
This is what we call groundless accusation.
Anyway, we sugarcoated the findings by saying we were unable to simulate the bug and ask the user to look out for it again.
So, next time in enhancement project plans, must allocate time for "TEST EVERYTHING ALL OVER AGAIN".
No comments:
Post a Comment