Sometimes we scared too much or to cautious to log bugs. We spent times unnecessarily to investigate an issue to make sure its valid. And some teams even include validity of bugs as part of their deliverables. Haven't it occurs to them that it may backfire. Valid bugs are better than invalid bugs. However, nobody can deny that invalid bugs are much much better than escaped bugs.
And then after we logged bugs, we are told to document the steps to find it. And probably create test cases to make sure that the bug won't be escaped untested in the next release. They told us, if you don't document it, if anything happen to you, we know what to do. It's also useful to the person after you. When what do they meant actually is, if you don't document it, if you are fired or resigned, we know what to do. It's also useful to the oblivious newbie we hired after you left.
Good things about bugs that logged in detail, is that it provides way to understand the function they are related with. If you don't have enough time to study the feature, read the bugs logged about it. To understand a feature is to read the bugs logged about them.
Q: How many QA does it take to change a light bulb?
A: Five. One to write a plan, one to understand the requirement, one to actually change it, one to check that the bulb is changed properly, and one to manage all these people.
I still remember, a senior QA manager from Company M, once said, a QA is as good as he catches the bugs. If he's just running tests, might as well automate to a machine and fire him. Sounds cold, isn't it?
And then after we logged bugs, we are told to document the steps to find it. And probably create test cases to make sure that the bug won't be escaped untested in the next release. They told us, if you don't document it, if anything happen to you, we know what to do. It's also useful to the person after you. When what do they meant actually is, if you don't document it, if you are fired or resigned, we know what to do. It's also useful to the oblivious newbie we hired after you left.
Good things about bugs that logged in detail, is that it provides way to understand the function they are related with. If you don't have enough time to study the feature, read the bugs logged about it. To understand a feature is to read the bugs logged about them.
Q: How many QA does it take to change a light bulb?
A: Five. One to write a plan, one to understand the requirement, one to actually change it, one to check that the bulb is changed properly, and one to manage all these people.
I still remember, a senior QA manager from Company M, once said, a QA is as good as he catches the bugs. If he's just running tests, might as well automate to a machine and fire him. Sounds cold, isn't it?
No comments:
Post a Comment