10 precautions for automated testing, a must-see for novices!

When you become an automated test engineer and start your testing work, it is normal for problems to occur. If you haven't studied Selenium's automated test scripts in depth, you are eager to automate website testing. This may also happen. Although learning from mistakes is a good thing, it is definitely better to prevent by learning from others.

When dealing with automated test projects, testers need to bear huge responsibilities. Your improper sign-off may result in production interruption and ultimately loss of customers and reputation. Therefore, as an automation tester, you need to learn from the experience of your predecessors to avoid such mistakes. The Zhuoma evaluation summarizes the following 10 points of attention that automation testers need to pay attention to, for reference.

1. Define the test scope

It is very necessary to define the scope of the test to be performed. When I was a novice in automated testing, I tried to test everything and automate each test. The problem is that although you can successfully automate all tests, it is actually neither practical nor feasible. There are many parts of the code that do not require frequent testing, but we may need to invest a lot of time to develop a framework or script to write these codes.

For example, when using Selenium to test a website, it is useless to automate every element of the website to run scripts on it, and it will only waste time and money. Secondly, automating all the work will increase the proportion of automation, which will make you think that you have done a very good job, but it does not. It may look good, but it is not necessary. Define and test the scope, and consider only feasible code that provides real valuable automated testing.

2. Choose your automated testing tools wisely

As an automated tester, another thing that needs special attention is to choose the correct automated testing tool. A test project contains many components that focus on different test goals. These goals should be divided into different tools to help achieve the goals more effectively. For example, if you want to test an API for your website, then Postman is undoubtedly your best choice, but if you want to ensure that your web application can be rendered perfectly between different browsers, then online Selenium Grid is for you. The best choice for automatic cross-browser testing.

In this case, the easiest way is not to jump directly to the test tool, and then solve the problem through the test tool. Instead, find the problem first, and then find the appropriate testing tool.
Insert picture description here

3. Coordinate well with other testers

There will be many people in a test team, and everyone has their own advantages. For example, some people are good at business testing, and some are good at functional testing. However, this is not a reason for not discussing task progress with them. Coordination is the key to accelerating product delivery, confirming who is doing what, what tools they use, and which programming language they use for test automation is the smoothest.

This can help you troubleshoot Selenium automated test scripts, so if there is a problem, you will know how to solve it and who can help you solve it.

Similarly, knowing your team can also help you get along better with other members. As discussed in the previous point, a project may require different tools to achieve the goal of the combination, you'd better let your testers use the tools he is familiar with.

4. Consider no-code automation as a basis

Although codeless automated testing tools have a unified learning method and are easy to learn, they cannot help you build the relevant skills required for automated tester profiles. As a beginner, although they are very helpful for you to get started, as your test automation career develops, you will realize that they are not as helpful as you expected.

Reliability is another big issue for this type of tool. At the end of the day, you need to learn the code in order to debug where the automated test suite execution went wrong. In addition, if you are dealing with a complex website, then you will not find codeless automated testing tools as flexible as you wish. So it is recommended not to escape the code, but to master it proficiently. Most importantly, it will become a highlight on your resume. So as an automation tester, we must pay attention to this problem.

5. Avoid false positive and false negative results

When the test result erroneously indicates that the test passed, but in fact the test failed, there will be a false positive result. False negatives are the opposite. Blindly believe that the test report is a very common error among testers, which can also be called non-verification of test elements. For example, suppose you are testing the login page with test scripts written in different test cases, and the test report shows that the login is passed. In this case, you need to verify whether the login is successful. As an automation tester, don't make this kind of mistakes just because you are alert for them.
Insert picture description here

6. Focus on the reusability of the code

The test case is not unique to the code it applies to. In a project, there will be many similar components that require similar test designs and test suites. For example, when using Selenium for cross-browser testing, we found that the four elements of the web page are all input fields, and similar test cases are required. Here, you can copy and paste the code by writing only the test of the first element. Although this will give the expected result, the problem is that the developer may change the element in some way in the future. Now, to change the test cases, you need to change the code in each test suite you write. All time will be wasted on finding and modifying these test codes.

To avoid this situation, you should always pay attention to the reusability of the code. You should construct a function with appropriate parameters and call this function on each element instead of pasting the code again and again. In this way, if there are any changes in the future, you only need to modify the function.

7. 100% automation is a myth

Don't believe this myth, because as an automation tester, this is a serious mistake. As a newbie in the field of test automation, you may be very excited about the introduction of automation into your project, and you may mistakenly believe that automated testing can completely replace the manual testing process. Over time, you will understand that this is impossible. Completely (100%) replacing manual testing with automated testing is a myth, which is unrealistic. As a beginner in this field, don't try to achieve such a goal. Only automate when necessary. It is reasonable to automate only those things that need to be automated.

8. Follow the top-down approach

When testing, you will encounter different types of problems. You will be asked to set goals and categorize these issues. A new approach is to start automated testing from smaller modules instead of larger modules.

As an automation tester, the biggest mistake is to start automation with larger and more complex modules. This means that you may lack an understanding of the inbound and outbound processes involved in each user interaction, and you may even lack the proficiency in handling difficult test cases, and you may waste a lot of time without any results. Therefore, starting small, starting from a basic method, and slowly increasing your automated test coverage is a practical method.

9. Including exploratory testing

Not including exploratory testing in your weekly routine is one of the common mistakes of automation testers. Exploratory testing is a great adventure, it helps to discover new test cases. When we enter the automation phase, exploratory testing is very important. Using only test scripts may ignore some unexpected important test cases in automated testing. As a beginner, we only want to rely on scripts and pre-written tests, which should be avoided.

Take time to do exploratory testing. You may never know what bugs you will find when doing exploratory testing!
Insert picture description here

10. Write test scripts that are not affected by the UI

Compared with the current version, the user interface of the software has undergone a lot of changes in the early version. Automated testing can help us repeat the test. In the early stages, as an automation tester, you may ignore these types of errors. Changes in the user interface force us to change the test script. Sometimes an element will change its position in future builds, and the script will use this position for further testing. The entire test will fail due to changes in the location on which the test depends. For example, during automated browser testing, if the location of an image changes, the Selenium automated test script will not be able to find the location, which will cause the entire test to fail. Such test scripts that depend on the user interface should be written as little as possible.

to sum up

Automated testing is a booming industry. From small Junit tests to large Selenium scripts, everyone is moving towards automation. You may encounter the same code with a small patch added and have to run the same test again. With the development of automation, the error rate of repetitive tasks will be reduced to zero, but this stage can only be achieved through certain practice and accumulation.

When you first try to automate, problems are normal, but they can be avoided. After all, problems mean losses and increase costs. Therefore, as a newbie in automated testing, I hope you can keep these precautions in mind and become an excellent automated testing engineer.

PS: Zhuoma Software Testing is a third-party software testing service organization that specializes in software testing [with CMA and CNAS dual qualifications]. It can provide various software testing services according to your needs and issue qualified and effective software testing reports. If you have test requirements, you can find Zhuoma Software for evaluation

Guess you like

Origin blog.csdn.net/wunian570/article/details/108462794