Inspiring Thoughts by Ms. V Madhunika - Quality Assurance Engineer:

Thanks a lot for your timely response.I am a frequent visitor of your site softwaretestinggenius.com.I recently cleared my ISTQB foundation course .My main source of help was your Database of Questions posted on your site. I will go through the links of HP ALM 11.0 certification exam sent by you and will surely reply to you. Best Regards, Madhunika.

Published with the Consent of Ms. Madhunika v.madhunika@gmail.com
******************************************************************************

"Full Study Material For ISTQB - Foundation and All 3 Advanced Level Certification Exams" ******************************************************************************
Best Strategies on Automation & Manual Testing Practiced by Software Testing Experts

The management team reviews different strategies and identifies few of them that would yield highest payoff in terms of improving the testing and achieving the targeted objectives.

The software testing managers burn a lot of midnight oil in working out different pros & cons of deploying ‘Automation Testing’ or ‘Manual Testing’ to evaluate their software under test. Following strategies on automation & manual testing are carefully examined prior to arriving at some useful conclusion.

Strategies for Automation Testing:

A) Based upon viability of executing automated test scripts:
It has been seen that generally the ‘Return on Investment’ (ROI) for automation works out when any test case has to be executed more than thirteen times. After around thirteen executions, automation works out to be cheaper than manual testing.

For example, suppose for any test case that the total effort in writing the test case comes in at fifteen minutes and manual execution needs fifteen minutes. So the total time required for executing this test case thirteen times is 6.5 hours. Now automation requires around 6 hours of work. Automated script for the test case runs in less than three minutes. So the time required for writing the test case, automating the test case, and running it thirteen times is around 6 hours and 54 minutes.

Following six core principles of testing are prescribed by Great Testing Gurus, & out of them each one carries significant importance for the practitioners as well as the testing managers. These principles help us to better understand what testing is all about and serve to provide a foundation for the methods and techniques used by the software testing engineers.

Six key software-testing principles are:

1) Complete testing is not possible.
2) Testing is creative and difficult.
3) An important reason for testing is to prevent errors.
4) Testing is risk-based.
5) Testing must be planned.
6) Testing requires independence.

The principles, being described here are nothing but an accepted or professed truth that provide us an insight about the software testing discipline.

Testing Principle - 1: Complete Testing is Not Possible
Many programmers believe that they can and do test their programs "thoroughly." When asking about testing practices, we generally come across statements like the following:

"I will stop testing when I am sure it works";
"We will implement the system as soon as all the errors are corrected."

Such statements assume that testing can be "finished," & that one can be certain that all defects are removed, or that one can become totally confident of success. This is an incorrect view. We cannot hope to achieve complete testing, and, as we shall see, the reasons are both practical limitations and theoretical impossibility.

After spending several hours on perfecting our test case designs, a big question arises that is
“Which testing technique should we use?”

The best answer to that is: It depends!

There is no established consensus on which technique is the most effective. The choice depends on the circumstances, including the testers’ experience and the nature of the object under testing.

With regard to the software testing engineer’s experience it is evident that a test case design technique that we as software testing engineers know well and have used many times on similar occasions is a good choice. All things being equal there is no need to throw old techniques overboard.

Despite the general feeling that everything is changing fast, techniques do not usually change overnight. On the other hand, we need to be aware of new research and new techniques, both in development and testing becoming available from time to time.

A little more external to the software testing engineers direct choice is the choice guided by risk analysis. Certain techniques are sufficient for low-risk products, whereas other techniques should be used for products or areas with a higher risk exposure. This is especially the case when we are selecting between structural or white-box techniques.