Hi friends!
I think it is a gr8 question to ask that
What are the Questions a tester should ask to himself, when testing a software?
Hi friends!
I think it is a gr8 question to ask that
What are the Questions a tester should ask to himself, when testing a software?
Last edited by jainbrijesh; 06-18-2007 at 05:34 AM.
Regards,
Brijesh Jain
---------------------------------------------------------
Connect with me on Skype: jainbrijesh
Google Plus : jainbrijeshji
ya friend that is a great question to ask ....
please clarify when a tester should ask this question to himself
during office
or after the office
"How much do I doubt the application that I can break the hell out of it?"
Anshoo,its depends on you when you have understand the application how exactly it should behave then you started breaking that apllication without knowing that u cant do that.
Example-- logic u should know thw logic how it behaves u should also know on which condition it is not working
thank you
sandeep
Hi Sandeep,
A tester can start testing or validating the Application or Module which he is alloted only after he understands the logic, requirements, functionalites of the application. Without having full knowledge of the requirements no body can test the application, doing this will mislead to a difficult circumstances.
So, there is nothing wrong for a tester to question himself "How to Break the Software". The primary role of a tester is to break the application out of error.
Regards,
Ganesan
Right, and that knowledge comes from doubting each and every functionality that I, as a tester work on. I cannot blindly believe the application in regards to learning it. If I have had ample time writing test cases, spending hours bottling down the requirements, I must have some knowledge of the application before-hand. Just the GAP Analysis and a few words with the developers draw a rough picture even before the application is in development. Well, why would I ask that question personally?Anshoo,its depends on you when you have understand the application how exactly it should behave then you started breaking that apllication without knowing that u cant do that.
That is because in my experience I have seen show-stoppers merely because of a minor miscommunication. This caused days to pin-point what happened and days to get the new build to begin testing. If the testers didn't doubt the application, chances are that this defect would seem minor, and would just be treated as a low Severity/Priority defect. Some applications are so complex that you as a Tester cannot understand the logic that goes behind the application, let alone a single module. That is not in my job function either. Having a good application knowledge is important, knowing it inside-out is your utmost responsibility. So, I cannot find defects in an application if I don't know how it behaves? Ofcourse I can. That is because you have the Business Rules with you, the Functional Reqs. and other QC standards the client has asked you to maintain every time a new build has come out.
What if there is not enough time due to deadlines to test the application? Wouldn't a simple walkthrough or an ad-hoc test be sufficient to understand what a functionality does and what it is supposed to do after having a past of writing, correcting and maintaining test cases, reading and remembering business rules?
I pretty much lost you here.Example-- logic u should know thw logic how it behaves u should also know on which condition it is not working
Hi Sandheep,
That is what I have also mentioned. But to test the application with different type of data the tester should have the good knowledge of the applicaiton. Because an Input data or the Test data plays the vital role in validating the application. Also, it may not be happenning in small companies but it is the process which is occurring in the CMMI level 5 companies.
Regards,
Ganesan.
What I said was a response to the general question asked in the very first post. It doesn't matter at what phase of Testing you are, you have to be doubtful enough to find the defects that might be found during the UAT or even worse, post-production. Application knowledge is important, but there are tons of other things that are involved while testing any software product but as testers, we are not supposed to overlook an error or consider it a "feature" which the developer might very well imply.
He should checkout the capabitly the he has on Break-Down attitude on the project he is dealing with