Which tests should be automated?

We should perform a careful analysis of the application when deciding which tests warrant automation and which should executed manually.

Here some examples of tests that could be automated.

• Tests that are executed more than once. By contrast, a test that is executed only once is often not worth automating.
  
  
• Tests that evaluate high-risk conditions. Low-risk factors may not be worth testing by automated means.
  
  
• Tests that are run on a regular basis. Example includes smoke (build verification) tests, regression tests, and test that include many simple and repetitive steps and must be conducted repeatedly.
  
  
• Tests that would be impossible, or prohibitively expensive, to perform manually. For example, during stress and performance testing, during memory leak detection, or path-coverage testing.
  
  
• Tests that have multiple data values for the same actions (data-driven tests).
  
  
• Baseline tests to be run on different configurations.
  
  
• Tests with predictable results.
  
  
• Tests on a system that is some what stable, with functionality, implementation that are not constantly changing.

Divide and Conquer in Software Testing

This is all about testing.

To break down the testing tasks, the following “what,” “when,” “how,” and “who” questions should be answered.

What Should be tested? During the test-planning phase, what to test and what not to test will have been determined as part of the scope of testing.

When should test procedure be developed? Test procedure be developed as soon as requirements are available. (unfortunately we don't have that Test Procedures). Once it has been determined what to test, the sequence of tests must be established. What needs to be tested first? The test planner should get to know the testing priorities, and should become familiar with the build and release schedule. Procedures for testing the high-priority items should be developed first.

How should test procedures be designed? No single testing solution can effectively cover all parts of a system. Test procedures for the different parts of the system must be designed in the manner most appropriate for effectively testing each of those specific parts.

In order to design the appropriate and most effective tests, it is necessary to consider the parts that make up the system and how they are integrated.

Who should develop the tests? Once it has been determined what must be tested, when it is to be tested, and how the test is to be accomplished, it will be easier to decide to whom the various testing tasks should be assigned.

Since user-interface, or black-box, testing does not exhibit all defects, gray-box testing must also be applied.

Keep in mind that black-box and gray-box testing combined are still not sufficient to procedure a quality product. Testing processes, procedures, inspections, and walk-through s, along with unit and integration testing, are all important parts of effective testing. Black-box and gray-box testing alone cannot identify all of the defects in a software program.

First post in my personal blog

I'm decided to write personal blog content from today. 

Privacy policy

         We do not share personal information with third-parties nor do we store information we collect about your visit to this blog for use other than to analyze content performance through the use of cookies, which you can turn off at anytime by modifying your Internet browser's settings. We are not responsible for the republishing of the content found on this blog on other Web sites or media without our permission. This privacy policy is subject to change without notice.

  In this blog I'm just posting some useful tips & code snippets on all open source technologies like Selenium, testNg, Junit which is useful for many of the people and also trying to post solutions for common problems.

If you have any questions feel free to contact me directly here: santoshsarma.jv@gmail.com