Test cases Strategy

[FONT="Palatino Linotype"][COLOR="DeepSkyBlue"]Hi

Its a simple question regarding the testcase
What should be the strategy followed for writing the testcases??
a.Writing all the functionalities...possibilities..scenarios we can think of...all cosmetic things(labels,taborder,,,)making the coverage 100%??

or

b.Following a general pattern which just covers the major functionality and then go about writing the testcases when we find bugs during bughunting

I wont ur opinion...On which is a better strategy??
on things like
1.which one saves time
2.Which one is fruitful??

Thanks in advance [/COLOR][/FONT]

Different companies choose different approaches depending on their policies, strategies and more importantly their budgets.:D

My vote goes to ‘A’ as 100% quality is more important than anything else (cost/time). :cool:

[COLOR="DarkOrchid"]When workin against deadlines..we definitely needs to save time...
A is the approach i am following right now...But what made me think was
"If we can find bugs at the blink of an eye(blink testing by James bach)why should we waste our time in documenting so many testcases written for GUI specific things??".

We can better concentrate on N number of scenarios affecting our functionality of the application....So could upls explain to me..Which one is good...Or I need to go in both the ways??[/COLOR]

See Test case strategy means how u r going to test the application , first u can plan it and test it based on the test case before the plan, this is some companies follows different different ways, depending on the client.

Thanks
srinivasulu.chittoor

I vote for A.

but while we implement we would initially list all the possible test factors in the test strategy document. then during planning we would even consider the factors like time and cost and implement the related testing techiniques.

Tester should write testcase according to HLS and LLS.
This is the best approach and followed by MNC's.
It's also a metric to count the tester efficiency.

I would agree with Vani as she sounds to be absolutely correct

[QUOTE=sutnarcha;4156]Different companies choose different approaches depending on their policies, strategies and more importantly their budgets.:D

My vote goes to ‘A’ as 100% quality is more important than anything else (cost/time). :cool:[/QUOTE]

I always go with A. As it gives u 100% testing of the product.

But as told by Sutnarcha, it is always the companies discussion which we have to follow.

Regards,
Narin Kamuni

hi,
May i want test case template as Excel format,please send me my mail id.

[QUOTE=kishanganji;53082]hi,
May i want test case template as Excel format,please send me my mail id.[/QUOTE]

Will you please let us know precisely what you are looking far.

Thanks,
Deepa

[QUOTE=rose;4158][COLOR="DarkOrchid"]When workin against deadlines..we definitely needs to save time...
A is the approach i am following right now...But what made me think was
"If we can find bugs at the blink of an eye(blink testing by James bach)why should we waste our time in documenting so many testcases written for GUI specific things??".

We can better concentrate on N number of scenarios affecting our functionality of the application....So could upls explain to me..Which one is good...Or I need to go in both the ways??[/COLOR][/QUOTE]

Hey Rose,

As per your words, What I can infer is the GUI stuff you are validating does not depend on the functionality. In that case, You can very well go ahead with the blink testing just by writing the test conditions(text, labels and other UI Stuff you want to verify) and validating the conditions when you are on the actual screen which saves you lot of effort.

however, you may want to write up the end to end flow if the GUI stuff depends on the selections you are making on the previous screens, just to cover all the permutations and combinations.

I suggest using an automation tool(QTP) for UI validations which will definitely save lot of time and efficient too. (Ofcourse, there is one time license purchase cost of the tool. But in the long run, if you compare the metrics it will surely pay off).

Hi , U can go for "A" only.