About automated testing, agile, and teams

The new pad was jailbroken for the first time and started to download and install apps that were previously hard to afford. It is estimated that it will take quite some time to adapt to these office apps.

The members of the team have gradually adapted to the article I shared with you. After reading the article, you can integrate your own ideas and write down your blog. In agile transformation, each member is driven to think independently and have the willingness to improve. This is probably the most important part. Especially in a test team, the desire for automation is especially urgent after everyone has a deep understanding of agile. I independently developed the first generation of automation tools for the project, covering about 100 cases, however, because coding is fast, stability and running speed are not ideal. Now that the team understands the power of automation and attitudes towards it in Agile processes, I decided to restructure the first generation of automation tools and gradually expand to a framework.

In the new Framework Design and underlying architecture, I have to remind myself of the following points:

1.
Focus on one thing at a time: The company also has many project teams working on their own automation, as well as dedicated automation groups. Although everyone works very hard, they fully understand how our project should be tested, what is automation we need most? We are the only one who knows the most clearly. I have recorded the analysis of the team one by one and only focused on one of them at a time, until everyone can use it with satisfaction. I personally think this is particularly important. In general, an automation framework, based on WEB projects, may include everything, PAGE Identification, Disk File Installation operations, case design, data result analysis, detailed test reports ...... And so on. If we want everything, and everything can be quickly completed and released, we will find that each piece has a lot of defects in the end, and along with technological innovation and product upgrades, the vulnerability is constantly maintained and the automatic framework is updated. Therefore, we need to select the most important item and use agile in the same way to continuously and quickly iterate to ensure that stable and valuable functions can be used.

2.Allow full participation: Because the team is basically aware of agile, I don't want to use personal development just like the first generation of tools, but to involve all the team members. To allow all the team members who do not have programming skills to participate, I carefully designed the underlying code structure and inheritance relationships, and controlled the exposed APIs to be clear and understandable. If you do not understand the Java code, you may complete the coding of many Java methods. Here I will take a piece of code as an example: (this code executes a series of page operation procedures, covers a certain functional point of the system, and basically avoids many tedious syntaxes and appearances of Java)

page.home("Administration").go("Manage Device Groups");grid.locate("Device Groups").toolbar("New Subgroup");dialog.radio("Staging");dialog.to("Next").form("Group Name=testGrp1", "Description=testGrp description");dialog.click("Not specified");dialog.popup().check("operator");dialog.popup().click("OK");dialog.to("Finish").process();

3.L3 Architecture: I read an article a few days ago to analyze the design idea of the automation framework. The traditional automation idea is called the original type: Mainly interface recording playback, which exposes various drawbacks such: difficult to reuse, environment dependency instability, rigid steps, difficult to expand and insert judgment outside the interface ...... The main idea of current automation is already different. The main emphasis is that the interface should not wait dumbly but be able to continue to do some things in the background during the running process, in order to reuse and expand the separation of test data and scripts elegantly, the whole automation has tends to develop the commonly used MVC model: presentation layer, data layer, and logic layer. Page identification and tracking operations are subordinate to the presentation layer, while page scheduling and data selection and analysis, and even matching checks of background functions are affiliated to the logic layer, the test data that is truly separated and managed is affiliated to the data layer. The framework is responsible for coordination and management between the three layers. In the end, even if major updates are encountered, they can be simplified and moved only to some components in the middle of a certain layer.

4.Complete Core: The core of the test is the test case. In the future, we hope that every step can be made practical, so even if you have a lot of good ideas at the beginning, I recorded them one by one, but warned that I could not want anything. We already have a complete idea on the definition of the core component testcase. Here I just leave a sketch and an idea. In our opinion, A testcase should include the following parts:

• Pre-condition: Pre-condition, independent from the uncertainty of the interface, directly checks in the background
• UI-Process: Complete the operation process of system behavior or design scenario
• After-Condition: Post-condition. To eliminate or mitigate the impact on subsequent cases, you must perform restoration and other operations on the interface and background.
• Checkpoint: Compares verification on the interface with background data, and analyzes logs and even process data.
• Case config: The configuration of the test scenario, the browser required, and the estimated time
• Meta data: Metadata of the test case, including the system function points, descriptions, and versions of the testing object system.
• Dependency: To cover more complex scenarios, cases can be freely combined and set up dependencies as needed 【Optional]

Finally, I keep telling myself and my team: Proceed with cautionIn the long term, we will never give up on updating or abandoning outdated ideas that will change with the industry. Most importantly, automated testing is always impossible to replace manual exploratory testing. However, if automated testing cannot really deliver valuable results, manual work will never be truly liberated. To put it simply Automation case failed: 80% ~ More than 90% of the vulnerabilities must be bugs.In this case, the value of automation cannot be discussed. Therefore, in the early stage, we can change our thinking to allow automation and human tedious operations to free up the labor and time required for manual operations to further explore the valuable production of automated cases if we judge and guarantee them, continuous iteration and improvement.