Whenever a software testing is planned and test cases are prepared, one would always have identified certain number of test cases which need to be executed in order to ensure that the functionality is working fine without many bugs. We generally term these test cases as regression test cases.
Whenever there is a new release in a tester’s hand, with some bugs fixed in the code, there certainly is a large chance of the fix affecting another related functionality of the software. This generally is due to the fact that usually coding is based on utilizing reusable functions to a maximum, so that code complexity as well as the size of code could be reduced. This certainly is a boon to the Software Testing industry, and in particular to the Software Test Engineers. This keeps our department busy in the industry, and thereby keeps its position sustained and important in the life of the Software. So Regression testing could be put across in this way – While a bug gets fixed, there are chances that some related functionalities get affected. In order to test this, while planning the tests, we identify a set of test cases that confirm the functionality of the various features and mark them as regression test cases. Regression Testing is testing the software to make sure that the software functionalities are not affected in a new release”. Regression test cases are usually Positive functionality test cases.
So regression test cases are some set of test cases which need to be executed at every test cycle probably, apart from small releases. This makes it repeating tests. While repeating the execution of test cases again and again, there is a high chance and risk of human errors. There can be missing steps in test execution that can lead to major issues getting exposed to the customers. I have seen a situation when a tester passed a test case just quoting that the functionality was working fine in the previous release, and there was a situation when it turned out to be not working when client tried the same. So a manual test execution has a chance of missing test steps. But considering the test case being automated, there is no chance of any step getting missed.
Not only the human errors are the reason in choosing automation against manual, but the efforts required in Manual Testing is too high when compared to Automation for a long term. The charges of automation is a onetime cost, they would well be redeemed, when the same automated tests are executed over a long period, say a year or so. Thereby, it reduces the cost involved in testing.
There are quite a lot of other uses in choosing automation other than the above mentioned, like Automation makes test execution
- Faster
- Reliable
- Reusable
- Cost Effective
- More Accurate
- Maintainable
- And so on.
But even with automation, the manual efforts could not be completely excluded at any point of time. Automation Scripts are just a number of steps performed in sequence, nothing else. So at any time in testing, Manual efforts can never be completely replaced by Automation. But certainly, the efforts of manual intervention in repeatable things could be reduced to a very high level with test automation.
No comments:
Post a Comment