this might sounds crazy but sometimes when im trying to troubleshoot some issues, in the middle of finding the actual root cause of my initial issue, i found out there are many other issue. while this is fine as we can solve the issue on the spot. what if there are those unknown issue? what do u all think of creating a bug or issue just for documentation and testing purposes? is there any good recommendation to learn on how to perform a solid/reliable quality test job?
thanks and cheers,
eddykuan
you mean you will purposefully introduce a bug into the system, just so you can observe its behaviour? hmm...
http://devpinoy.org/blogs/cruizer
I believe that that is why test plans and test cases are being documented and tests are carried for the sole purposes of weeding out bugs. While test plans may not be perfect, they should be even more "perfected" by adding whatever is or may be an issue, so that there will be no issue at all.
Perhaps it al boils down to input and output. Tests on input have to be sure that the system what should be allowed is allowed, and what should be disallowed is not allowed. And that whatever is the expected output should be the only output. Testing is an entire topic by itself and there are professionals who had dedicated their entire life towards this topic. Head on to the library and you may find more information there.
Personally, weeding out bugs should be even before testing or development has ever begun - in the design phase. My two cents.
>Personally, weeding out bugs should be even before testing or development has ever begun - in the design phase. My two cents.
This will be weeding out design flaws, not bugs. :)
Bugs, for me will never surface unless proper testing is done. To introduce bugs, is like purposely planting a bug inside, which to me is wrong. Rather, I would rather discover bugs, but making my test plans as comprehensive as possible... Possibly getting testers outside the dev team
Best Regards, Kit Kai, MVP (SharePoint Portal Server)