Question a tester should ask to himself?

Hi friends!

I think it is a gr8 question to ask that

[b]What are the Questions a tester should ask to himself, when testing a software?[/b]:)

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

[QUOTE=jainbrijesh;13381]Hi friends!

I think it is a gr8 question to ask that

[b]What are the Questions a tester should ask to himself, when testing a software?[/b]:)[/QUOTE]

Great question jain 1 He should know what kind of application it is
2 how the functions are functionning
3 How much Big it is
4 which module should concentrated more
5 Can he able to complete with in the time

"How much do I doubt the application that I can break the hell out of it?"

[QUOTE=Anshoo_Arora;24482]"How much do I doubt the application that I can break the hell out of it?"[/QUOTE]

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

[QUOTE=kumsan060;24486]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[/QUOTE]

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

[QUOTE]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.
[/QUOTE]
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?

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?

[QUOTE]Example-- logic u should know thw logic how it behaves u should also know on which condition it is not working [/QUOTE]
I pretty much lost you here.

[QUOTE=sridharrganesan;24488]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[/QUOTE]

You are absolutely right but its not happening in all the company.
And if you really want to break the system just test the application with different validation of data

[QUOTE=kumsan060;24523]You are absolutely right but its not happening in all the company.
And if you really want to break the system just test the application with different validation of data[/QUOTE]

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