Functional test automation: what it is and how it can be useful

    That software testing is necessary, fortunately, no one doubts. But since the testing industry itself is quite young, generally accepted methodologies and rules have not yet been formed in it, as in the software development industry. As usual, functional testing of applications, systems, etc. The process can be divided into the following stages:
    1. Collection of requirements (valid for “external testing”)
    2. Creating a test model (what and how to test)
    3. Testing
    4. Test report (defects, problems, etc.)

    Each stage includes exclusively manual labor. And for each new version of the application, it is necessary to conduct regression testing - repeat the following stages:
    1. Test Model Addition
    2. Testing
    3. Report
    Moreover, the stage of "Testing" includes testing the entire scope of functionality - both old and new. Thus, it turns out that with the growth of functionality the volume of manual testing also grows, and testing of the "old" functionality quite rightly causes the tester to reject it - "I already watched it 10 times." Consequently, the quality of testing (decrease in attention) and the speed of conducting full testing of the system fall. Regression testing leads to regression of testers. Automation is designed to speed up the testing process and avoid degradation of testers.

    Consider a test scenario consisting of entering data into a form of 10 fields and controlling the result - a table of 20+ rows, in which we are interested in one row containing the data we just entered. We calculate and compare the time spent on running an autotest and a manual test.

    Manual Testing:
    1. Data entry, ~ 10 * 5 seconds = 50 seconds
    2. Table display - 2 seconds
    3. Search for the desired line - 5-15 seconds
    4. Checking the correspondence of the entered data and line - 10 * 3 = 30 seconds
    Total for one run - 87-102 seconds
    1. Data entry - ~ 10 * 0.1 = 1 second
    2. Table display - 2 seconds
    3. Search for the desired line - 0.5 seconds
    4. Validation of the entered data - 0.5 seconds
    Total for one run - 4 seconds.

    Thus, temporary savings on launches is 83 seconds or 25 times (autotests work almost at the server response speed). And this is the simplest one-step test case. And if we have 100 test cases with 10-15 steps each? Then man-months turn into one calendar day. Impressive? And the point here is not only saving money, but also what is never enough - time.

    But there are pitfalls. It is not by chance that I focus on saving on startups - the autotest itself must also be written. Usually this is the main reason for the reluctance to implement test automation. The arguments are as follows: “Now I have 10 testers of low qualification for n-money, and automation will require two, but for n * 4. There is practically no saving, but there are many problems with implementation. ” But if the product grows, then after some time it will be necessary to have not 10, but 15-20-30 testers, and the number of automation companies, if it grows, is insignificant. Autotests, however, do not need to rewrite everything, you only need to create new ones and keep up to date existing ones in case of a change in the functionality covered by them. And saving will no longer be so ephemeral,

    The most difficult period in test automation is its implementation, since it takes a very short time to write a very large volume of autotests, and at this stage, unfortunately, most of the aspirations to implement automation stumble. But if you apply test automation in the early stages of the project, then this problem can be avoided.

    Let's take a classic example for “I am PR”, a startup. The property of such projects is a very rapid development. If, when introducing new features, those that were originally set up and are, in fact, the highlight of the project begin to fail, then users will leave. If you test new features and existing highlights, it will take a significant amount of time and users will leave. And in this case, automation can act as a magic wand.

    Test automation is not a scary and expensive something that is available only to the elite, but a real way to reduce entropy :)

    PS I can recommend as automation tools:

    Also popular now: