I recall that I was assigned to the automation team when I first joined the company, so I used tools (RFT) directly before I started without manual testing. Because I had the basic knowledge of coding, I was relatively quick to get started. Six months into the job, you go back and learn the business from the use cases you’ve already written.
It was depressing at that time, because I found myself just an automatic executer: writing use cases, executing, debugging and outputting reports. Those testing theories seemed to be seldom used in practical work, and I thought I would take on more tasks in the future.
1. The use case design is too traditional, and it is executed according to the most common operation path. The efficiency of problem discovery is not as high as manual test. Manual testing is performed according to the environment preparation and operation steps in the test case, but problems can be found in very strange ways due to slight differences in the specific execution mode of people (such as randomly clicking on another button). There may be few opportunities even for users to do this, but that doesn’t mean such cases can be completely ruled out. Once in a website written by others to do a test, point to point out the Bug, we certainly do not want users to use the product in the process of any problems, the real quality of confidence in the product should be delivered to the user at the same time with a sentence: just point, play not bad.
2. The degree of automation is not high. This may vary from company to company, but at least in my current work environment, automation relies heavily on RFT as a testing tool and frameworks are developed on top of it. Then I read a report about QSIC, at least I think this is the convergence of software testing branch is relatively front-end technology. Test data, test design, test execution, a key set up test environment, test evaluation, or even can automate the testing standard, then think about your job is more intelligent than manual test in the test execution this section, and it is in a large number of cases to perform the advantage is obvious. Sometimes I have some ideas, but I always seem to be constrained by the tools instead of breaking the shackles. When others are already considering low-cost, the level they stay in is really worth reflecting on. (If software testing, interface testing, automated testing, interview experience exchange. If you are interested, you can add software test exchange: 1085991341, and there will be technical exchanges with peers.
3. Too much repetitive work that is inefficient. That time is spent writing use cases, which means writing automated scripts. The first few write ok, but to the back of the found in doing just repetitive work, the in the mind have resistance. I understand that testing does require a lot of repetitive work, but what makes me frustrated is that such repetitive work can be avoided by improving tools. There must be tools to solve this problem, but I still need Ctrl+V for one use case at a time. These can be changed by writing their own tools, and I will try my best to break away from the restrictions of automatic tools and achieve higher efficiency.
I can only think of these points for the time being. I believe I will have a lot of experience with the deepening of my work when I just touch automation for half a year. We also welcome you to exchange more experience with our counterparts in automated testing. The above content hopes to be helpful to you, have been helped to the friends welcome to praise, comment.