Summary
I have a side job (free, but the point is fate, after all, I don’t have enough time), and I happen to be instructing some graduated programmers to find jobs. I found that the difference in ability is reflected in the hard work acquired, and the gap in professional development is formed in cognition. At the same time, the latest software testing resources (video tutorials, PDF documents, interview questions) in the last two months are also organized.
Friends who need this information can add my public account [Sad Spicy Bar] to receive it.
When it comes to what constitutes an "appropriate implementation" of an automated test, you often focus on the tools you need, but that is only part of it. Bastigestra elaborated on the other four things you need to consider, how they contribute to the success of your automated testing, and the risk of not paying attention to any of them.
For organizations, it is an important part of the software development cycle to perform automated testing with the expectation of rapid delivery of quality. Test automation, however, can only succeed when properly implemented. Talking about what constitutes a "proper implementation" of test automation often focuses on what tools the task must use, or the best (if there is even such a thing) or the most efficient way to use specific tools for the given task.
In my opinion, though, the tools used are only part of the overall automated testing. The implementation of any successful automated test is composed of five unique parts.
In this article, we take a look at each of these sections, how they contribute to the success of your test automation implementation, and the risks associated with not being able to pay attention to any of them properly.
One, test automation tools
Although not the only factor that plays a role in a successful test automation implementation, tools clearly have an impact on the overall results of your automation efforts. Choosing a tool that is not compatible with the application you are testing, or a tool that does not fit the skills of your automation team, will lead to less than ideal results.
However, even more important than choosing a tool is to ask yourself what your automated tests want to cover, and then decide on a more efficient way to obtain that result. A typical example of a question to be asked is at what level a specific functional module or business logic needs to be confirmed.
Do you want to confirm that your users can open your online store, search for a specific product, then add to the shopping cart and pay for an order? You may want to use end-to-end user interface driver testing to check this. If you are about to confirm the correctness of a piece of logic to determine whether a user is allowed to purchase a specific item (for example due to national or national regulations), then you will probably write a test at a lower level and connect it Into your application, such as an application program interface or even simple code classification. This constitutes a different test scope and method, and therefore requires a different tool.
In short, make sure you first know what your automated tests need to verify before spending the time on how to achieve the expected results. Remember that there is a major risk in getting your tool to do things that it was not designed for.
2. Test data
Another important element of any serious test automation solution is the method of managing test data. The wider the scope of testing, the more important, and the more demanding, test data management is here.
When in unit testing you can stay away from simulating all the data that your test depends on, when you start working on integration or end-to-end testing, you will need to present specific data in your application under test. And, to make things more complicated, you will often require data from other systems in a specific country while you are in the experimental stage to interact with your connected applications.
There are some ways to handle test data in these test types:
- Create required test data at the beginning of the test
- Query the system for existing test data before starting the test
- Initialize your application database during the test phase before starting test execution
- Each of these methods has its potential dangers:
- Creating test data at the beginning of the test increases the test execution time, increases the risk of failure before the test itself or even starts, and leads to a lot of useless test data if there is no proper data cleaning program.
- When you query the system for existing test data before starting the test, you start the risk of accidentally using illegal test data, or there is no test data that appears in the system with appropriate priority.
- Initializing the database before test execution allows you to manage and maintain the latest database snapshots-that is, if you are allowed to perform a database recovery process first.
Note that there is no suitable test data processing method for integration and end-to-end testing. In any case, choosing the wrong program or failing to locate the test data problem at all may cause the automated test solution to become unreusable, unmaintainable, or unmeasured.
Three, test environment
Monolis is quickly repeating the mistakes of the dinosaurs. Modern information technology systems are composed of many interconnected components, services, and applications that work together to deliver business value. For testing purposes, this is usually not good news anyway: you must manage and rely on the availability of related items, especially those outside your control loop, which can cause a lot of overhead for your integration and end-to-end testing. Frustration, and delays in testing time. When you want to create and use automated testing as part of your testing methodology, reliability and manageable testing environments are still key.
One way to reduce the risk of failure or non-existent test environment is to use simulation techniques such as stubs, simulation, and service virtualization to replicate the critical and difficult-to-obtain independent behaviors in your test environment. Doing simulations that simulate real independent behaviors is enough to complete the test cases you want to execute, and it can greatly increase the speed of your automated testing-so also increase your development efforts.
In addition, when the virtual environment is properly created (for example, containerized through leverage), a new instance of the same test environment is rebuilt, completing the same test data and other features, making it possible to move from automation to real sustainability Testing, if you are adapting to continuous delivery, this becomes a prerequisite as a more flexible method and better response to market demand growth.
Four, report
Automated test execution as a result generated report should become an important part of any reliable test automation method. Creating good test results reports is often overlooked, however, saving tasks in any test automation project is a potential time (and life). A good report goes far beyond showing the number of test runs, passed, and failed, although it is better than nothing.
In order for a test execution report to be truly valuable, the tests that need to be executed (note that for any good report to clearly name your test and the unambiguous format is basic) is what visualization and not only what the results are ( Pass or fail), and in case the test fails, where is something causing the error, specify as precisely as possible.
This is different from providing information overload, just copy anything into your test report-this will unnecessarily delay the root cause of the test failure. A good report shows something wrong, where the test error occurred (at what step), what the error message is (depending on your report user, this is as simple as a stack trace, but in other cases you may Need to provide error information that can also be read by non-technical personnel), and the state of the application under test when it failed (for example, use a screenshot for the user interface drive test).
Note that a good reporting strategy may involve creating multiple reports each time the test runs. If your test is part of a sustainable integrated build pipeline, you may want to create a low-level report that can be interpreted by your build engine to decide whether to continue the build. But you may also want to create a readability report in HTML format, complete according to the original description of the test purpose, with human-readable information and screenshots in the case of a failed test. It all depends on the user.
Five, skills
Finally, the most important thing is that the hard problem designed to create a strong and effective test automation solution is the person responsible for implementing it. Without skilled automation consultants, architects, engineers, and developers paying attention to all the other aspects of test automation mentioned in this article, your testing may soon be over.
Your test automation team should be proficient in the testing field, so they can answer why test automation will be a suitable solution in the first place, and what tests should be automated; and are familiar with software development, which means they know how to go Create a test automation implementation that is both powerful and maintainable. This does not mean that every member of your test automation needs to be proficient in these two areas, but as a whole, your team needs to balance the two for software delivery.
Put it all together
A good test automation solution needs to focus on more than just tools that drive tests. In order for automation to be truly successful, you need to think of ways in your test data strategy, in how you manage your test environment, and in the way you inform your users about the results of your automated test execution. The most important thing is, anyway, it's about creating a team that knows how to do all of the above.
Finally: benefits
In the technology industry, you must improve your technical skills and enrich your practical experience in automation projects. This will be very helpful for your career planning in the next few years and the depth of your testing technology.
In the interview season of Golden 9th and Silver 10th, job-hopping season, organizing interview questions has become my habit for many years! The following is my collection and sorting in recent years, the whole is organized around [software testing], the main content includes: python automation test exclusive video, Python automation details, a full set of interview questions and other knowledge content.
Don't be ashamed of getting an 8k salary, don't be complacent just because you get a salary of more than 20k, don't be complacent just because you get a 30-45 salary. Life is not to earn that little salary, what you need is to open a career.
May you and I meet and you will find something! Welcome to follow the WeChat public account: [Sad Spicy Article] Receive a 216-page software test engineer interview book for free. And the corresponding video learning tutorials are free to share!
Good article recommendation:
Talking about starting from a small company to a big factory, what did I do right?
Does it make sense for ordinary people to learn Python automation?