Table of contents
Trap 1: Automated testing tools are omnipotent!
Trap 2: One tool fits all projects
Pitfall 5: Automation tools are easy to use
Pitfall 6: All tests can be automated
Pitfall 7: Automation can provide 100% test coverage
Pitfall 8: Test automation is record and playback
Trap 9: Automated software testing is the same process as manual software testing
Trap 10: Forgetting the ultimate goal of testing: finding bugs
In automated testing, some noobs or people who are just interested in automation will fall into the trap of automated testing. This article will summarize those automated testing traps that people step on frequently.
Trap 1: Automated testing tools are omnipotent!
So far, there is no commercial testing tool that can support automation from test planning, to test design, to test execution.
You often see speakers show the benefits and advantages of testing tools at product promotion meetings and demonstrations of certain testing tools, which makes you excited about automated testing; but they often don't tell you about the difficulties of automated testing. The complexity of implementing automated testing and how much investment is required.
Trap 2: One tool fits all projects
So far, there is no single tool that supports all operating system environments.
You may be asked by the project manager to find a test tool that can support all real-time embedded system tests, and your applications need to run on various operating system environments, including VxWorks, Integrity, mainframe, Linux and WindowsXP, and programming languages include Java and C++.
Python automated testing video tutorial: The latest collection of Python automated testing development framework in 2023 [full stack/actual combat/tutorial] collection of essence, annual salary of 40W+ after learning_哔哩哔哩_bilibili 
https://www.bilibili.com/video/BV1AF411T7qJ /?spm_id_from=333.999.0.0
Trap 3: The burden on testers is reduced immediately after the introduction of automated testing tools
After the introduction of automated testing tools, the testing burden will not be reduced immediately, in fact, it will often increase the burden at the beginning.
Project managers often want to reduce the testing burden by introducing automated testing tools. But experience shows that trying to implement and effectively apply automated testing in a new project often requires a learning curve. The burden of testing will not be reduced immediately, but the project manager hopes to see the power of automated testing immediately, and hopes to see the effect immediately.
In fact, at the beginning, it is likely to increase the burden of testing, because it takes a period of time for test engineers to familiarize themselves with and master the testing tools. At the same time, manual testing cannot be stopped for a moment, so the burden of testing has not been reduced, but instead aggregated.
In addition, automated testing requires careful analysis of the application being tested, which parts need and can be automated; and requires careful design and development of test scripts. These will undoubtedly increase the burden of testing, especially in the initial stage.
Trap 4: After the introduction of automated testing tools, the progress can be compressed immediately
After using the automated testing tool, the overall test progress will not be shortened immediately. On the contrary, in the initial stage, the progress will often be delayed to a certain extent.
Another misconception is that automated testing tools can immediately shorten the testing timetable. But since the burden of testing is increased in the initial stage, naturally, we cannot expect the schedule to be shortened. On the contrary, after introducing automated testing, we should reserve some time for the schedule in the initial stage. Once the entire automated testing process is established, we can expect automated testing to have a positive impact on our progress.
Pitfall 5: Automation tools are easy to use
Automated testing tools require testers to master new skills, often requiring additional training. There should be a training plan, investment of time and cost, and a learning curve.
Usually many tool vendors will exaggerate the ease of use of their products, and they will deny the so-called "learning curve". Tools salespeople often tout so-called "record/playback" that simply records the test engineer's keystrokes and mouse movements and then simply plays them back.
However, effective automated testing is much more than just "record/playback". The recorded script needs to be modified by hand to make it a little more reusable and maintainable, and a little more flexible, all of which require language and scripting knowledge. So they need training on the tools and the built-in scripting language.
Pitfall 6: All tests can be automated
Not all tests can be automated.
Automated testing is an enhancement of manual testing. It is unreasonable to expect 100% automation of the tests in a project. When first introducing automated testing, it's a good idea to verify that all objects and third-party controls are recognized by the tool. This is very important for GUI-based testing tools, because such tools often have difficulty in identifying some personalized controls, such as some calendar, spin, grid controls, and these controls are widely used in program interfaces, and these controls Often written by third parties, most test tool vendors have not been able to keep up with their development.
When encountering this situation, test engineers either abandon this part of the test automation that applies unrecognizable controls, or find some solutions.
In addition, there are some tests that are basically impossible to automate. For example, a test engineer can automate the process of sending a document to a printer, but check the printing effect (whether it is printed correctly, whether it is printed over the paper) line) this part must be done manually.
As for which test cases should be automated, you can refer to the following table to decide:
YESNO
Number of test executions:
Will the test be run multiple times?
Will the tests be run regularly?
For example reused often, as part of regression testing or daily build testing?
Criticality of the test:
Do the tests cover the path of the most critical parts of the software functionality?
Does the test cover the most complex parts? (Usually the most error-prone part)
The cost of testing:
Is it impossible or very difficult to perform manual testing, such as concurrency testing, persistence testing, performance testing, memory leak testing, etc.
Is testing time consuming? For example, hundreds or thousands of test result outputs need to be checked.
Type of test:
Does the test need to combine many inputs, but share a test step? For example, the same function is verified with many different inputs.
Does the test need to be performed on multiple hardware and software configurations?
Tested application or system:
Was the test performed on a stable application? For example, functional features have been basically completed.
Use compatible technologies and an open architecture
Pitfall 7: Automation can provide 100% test coverage
Not everything can be tested automatically. It is impossible to cover all possible inputs, all possible combinations and paths.
Automated testing can increase the breadth and depth of testing, but still cannot achieve 100% test coverage because there is not enough time or resources.
For example, a simple login interface test, suppose we need to test the correctness of its password verification function, the length of the password is between 6 and 8 characters, each character can be uppercase or lowercase, and at least one number is included, then the input may be Combinations will reach 2,684,483,063,360.
Even if we could create a test every minute, it would take 155 years to complete a full test. Therefore, it is impossible to exhaustively test all possible inputs.
Video Tutorial:
Pitfall 8: Test automation is record and playback
Merely recording is not a valid automation script.
Many project managers still equate test automation with using a recording and playback tool. In fact, the recorded scripts are usually non-reusable scripts, full of hard-coded values, these values should be parameterized, otherwise the script is only suitable for a test situation, and the script should also add conditional judgment, loop and other structures , in order to increase the flexibility of the test script.
Trap 9: Automated software testing is the same process as manual software testing
The skills required for automated testing are different from those required for manual testing.
Usually, your project manager will be confused by those test tool salesmen, thinking that automated software testing is simply pressing a record button to generate test scripts. In fact, it is not that simple.
It is important to distinguish the skills required for automated testing from those required for manual testing. Most importantly, automated test engineers need to master software development skills. Manual testers who have not received any training, or manual testers without programming background, will encounter many difficulties when implementing automated testing.
Trap 10: Forgetting the ultimate goal of testing: finding bugs
In automated testing, we should also pay attention to the application of techniques such as boundary value analysis, equivalence class analysis, risk-based testing methods, and selection of the most suitable test cases.
Usually in the process of automated testing, we are busy building automation frameworks and writing test scripts, but we often forget the original purpose of testing: to find bugs.
The project manager probably hired the best automation developers to build the framework, used the latest and greatest automation development techniques, and created thousands of automated test scripts. But if the bugs are still missed, those bugs that should have been caught by the automated test script, the result is not caught, then your automated test will still be considered a failure.
Thanks to everyone who read my article carefully! ! !
I personally sorted out some technical materials I have compiled in my software testing career in the past few years, including: e-books, resume modules, various job templates, interview books, self-study projects, etc. Welcome everyone to click on the business card below to get it for free, don't miss it.
Video Tutorial:
