Return to Answer

I clarified an early point that previously required a reading of the comments to easily understand and added the word 'test' to a sentence where it appeared to be absent.

Source Link

edit approved Feb 16, 2012 at 0:18

user867

When you are assuring the quality of the product, the quality of your test script is as important. Hence, the automation should be very efficient. That (This is more of ana good attitude than a requirement.) In the real world, the automation should be as efficient as practically possible.

Some ways:

**Modularize the tests** - If the tests can run in entirety and independently, it allows you to execute what you need. A lots of parts of the application are never/not so frequently affected. With a good judgement, the need to run all the TCs all the time can be eliminated. We used to have a joke in our team, if a bridge I-5 near Fresno is reconstructed, no need to test the entire freeway from San Diego to Seattle.
**Smoke/Sanity Test** - Having an efficient smoke test which can run regularly instead of the full fledged test. A sanity test can be run regularly and more frequently than the full fledged test suite.
**Confidence level** (gray area) - It is extremely important for a QA team to determine confidence level in different modules of the application, so that the team can know which modules need to be tested more frequently than the others.
**Housekeeping** - As already mentioned, it is very important to 'maintain' the test suite and deprecate or remove the TCs that are no longer important. As the product gets matured, quite a few TCs can be eliminated, which will save a lot of time. e.g. If a module in the product calculates the formulas, once the product is matured and those formulas are not being changed, fewer TCs should suffice to sanity test that module rather than going through numerous combinations.

When you are assuring the quality of the product, the quality of your test script is as important. Hence, the automation should be very efficient. That is more of an attitude. In the real world, the automation should be as efficient as practically possible.

Some ways:

**Modularize the tests** - If the tests can run in entirety and independently, it allows you to execute what you need. A lots of parts of the application are never/not so frequently affected. With a good judgement, the need to run all the TCs all the time can be eliminated. We used to have a joke in our team, if a bridge I-5 near Fresno is reconstructed, no need to test the entire freeway from San Diego to Seattle.
**Smoke/Sanity Test** - Having an efficient smoke test which can run regularly instead of the full fledged test. A sanity can be run regularly and more frequently than the full fledged test suite.
**Confidence level** (gray area) - It is extremely important for a QA team to determine confidence level in different modules of the application, so that the team can know which modules need to be tested more frequently than the others.
**Housekeeping** - As already mentioned, it is very important to 'maintain' the test suite and deprecate or remove the TCs that are no longer important. As the product gets matured, quite a few TCs can be eliminated, which will save a lot of time. e.g. If a module in the product calculates the formulas, once the product is matured and those formulas are not being changed, fewer TCs should suffice to sanity test that module rather than going through numerous combinations.

When you are assuring the quality of the product, the quality of your test script is as important. Hence, the automation should be very efficient. (This is more of a good attitude than a requirement.) In the real world, the automation should be as efficient as practically possible.

Some ways:

**Modularize the tests** - If the tests can run in entirety and independently, it allows you to execute what you need. A lots of parts of the application are never/not so frequently affected. With a good judgement, the need to run all the TCs all the time can be eliminated. We used to have a joke in our team, if a bridge I-5 near Fresno is reconstructed, no need to test the entire freeway from San Diego to Seattle.
**Smoke/Sanity Test** - Having an efficient smoke test which can run regularly instead of the full fledged test. A sanity test can be run regularly and more frequently than the full fledged test suite.
**Confidence level** (gray area) - It is extremely important for a QA team to determine confidence level in different modules of the application, so that the team can know which modules need to be tested more frequently than the others.
**Housekeeping** - As already mentioned, it is very important to 'maintain' the test suite and deprecate or remove the TCs that are no longer important. As the product gets matured, quite a few TCs can be eliminated, which will save a lot of time. e.g. If a module in the product calculates the formulas, once the product is matured and those formulas are not being changed, fewer TCs should suffice to sanity test that module rather than going through numerous combinations.

Source Link

created May 31, 2011 at 21:15

Suchit Parikh

1.6k
1
10
22

Some ways:

**Modularize the tests** - If the tests can run in entirety and independently, it allows you to execute what you need. A lots of parts of the application are never/not so frequently affected. With a good judgement, the need to run all the TCs all the time can be eliminated. We used to have a joke in our team, if a bridge I-5 near Fresno is reconstructed, no need to test the entire freeway from San Diego to Seattle.
**Smoke/Sanity Test** - Having an efficient smoke test which can run regularly instead of the full fledged test. A sanity can be run regularly and more frequently than the full fledged test suite.
**Confidence level** (gray area) - It is extremely important for a QA team to determine confidence level in different modules of the application, so that the team can know which modules need to be tested more frequently than the others.
**Housekeeping** - As already mentioned, it is very important to 'maintain' the test suite and deprecate or remove the TCs that are no longer important. As the product gets matured, quite a few TCs can be eliminated, which will save a lot of time. e.g. If a module in the product calculates the formulas, once the product is matured and those formulas are not being changed, fewer TCs should suffice to sanity test that module rather than going through numerous combinations.