Continuous Testing | Improving the efficiency of the testing process: Practice continuous testing within iterations in CODING

Author of this article: Cheng Shengcong-CODING Product Manager

Changes brought about by continuous testing

Continuous testing (or agile testing) requires testing as a basic activity throughout the entire process of software delivery. Compared with the traditional test model that was in trouble in the DevOps era, continuous testing first changes the "post-testing" situation. emphasizes the pre-testing, by defining testing as early as possible, paralleling testing and development, and maintaining close collaboration in the process. So as to achieve the purpose of rapid feedback of business risks . The practice change of continuous testing is about the overall engineering of people, processes and technologies: it requires technical support, such as the basic capabilities of continuous integration and continuous deployment, as well as the improvement of personnel's ability to automate code. At the same time, process improvement is also indispensable. An indispensable link.

Just as the four core values proposed at the beginning of the Agile Manifesto, the team should focus on the behaviors and results that bring value to customers, rather than the traditional step-by-step completion of the items and production process deliverables of the established project. This also requires testing:

1. Individuals and interactions are higher than processes and tools;
2. Working software is higher than detailed documentation;
3. Customer cooperation is higher than contract negotiation;
4. Responding to change is higher than following the plan.

However, for the literal understanding of the "four higher than" in the above declaration, everyone is often confused: collaboration is very important, so is it that processes, documents, and plans are no longer needed? In fact, it is not. After all, the inherent complexity of the software is still there, so the planning and documentation for better delivery of the software still has important value. It's just that we need to change the original bloated processes, documents, and plans so that they no longer become the constraints of the team's rapid response goals. Therefore, "light process", "appropriate granularity", "plan as soon as possible" is the appropriate change we should make. If automated testing and precision testing are to improve efficiency at a single point of test execution, then iterative testing is to improve testing efficiency in the overall process.

How to practice continuous testing within iterations

The testing process generally includes planning, designing use cases, and execution. The following figure shows the classic workflow of the test perspective in the iteration of the agile model. Let us start from the classic workflow of the testing perspective in agile mode and discuss how to practice continuous testing in an iteration.

Based on the above scenarios, we can carry out testing activities according to the following steps to achieve the goal of synchronizing with the development work and broadening the testing time window:

First, in the iterative planning meeting, the product manager interprets, analyzes, and evaluates the workload with the team on the demand story. When the task is claimed, development and testing (or another development in this role) are paired to be responsible for a certain demand story. When the iteration plan is completed, you can actually create a test plan corresponding to the iteration. The plan should include a list of iteration stories and the corresponding acceptance criteria (Acceptance Criteria, AC).

Then, in the iterative process, the demand story representing the business value should be delivered as a whole. In other words, paired development and testing should deal with a certain demand story with the same priority, and after the end-to-end delivery of the story is achieved as quickly as possible, then the next demand story should be processed. Therefore, while developing and implementing the code, the test should also write the test case of the story at the same time- most cases, it is the detailed expansion of the AC and the completion of the . When the use case is written, review it in time, and even realize the coding of the interface automation test when the interface contract is guaranteed. In this way, each story is tested and passed immediately after the development is completed, and is in a deliverable state.

Finally, after the iteration is completed, the test case set corresponding to the demand story covering the current iteration can even be executed once, and the overall test situation reflected in the test report is reviewed for continuous improvement.

How does coding contribute to continuous testing in practice iterations

Based on the scenarios mentioned above, CODING takes the [test plan as the main body of the test activity] as the concept, designs and polishes products, and strives to bring users an "immersive" test experience . Next, I will demonstrate how to carry out a complete iterative test activity in CODING test management:

1. At the iteration planning meeting:

First, start with the planned iteration in the project collaboration, view/create the team's test plan, and associate the corresponding iteration.

Then after the team test plan is created, the iterative demand story will be displayed in the plan. Then create the corresponding functional use cases for the demand story. The content may just bring the acceptance criteria (AC) agreed in the planning meeting, and assign the relevant use case tasks to the corresponding test students, forming an iteration from the perspective of the Kanban . These operations can be completed at the planning meeting or within a short period of time after the meeting. The test plan includes a list of iteration stories and the corresponding use cases with AC as the content, which is called the "test plan alpha version" for the time being.

2. Iteration in progress:

While developing the students to realize the coding, the test students synchronously write the test cases of the story. The test plans are gradually supplemented by the use cases, which can be called the "test plan beta version". After the use case is written, review it in time, and even realize the coding of the automatic interface test when the interface contract is guaranteed. This rhythm also achieves the synchronization of testing and development work.

After the requirement story is tested, execute the test case and verify whether the function is normal according to the steps of the use case. In such a "small step and quick walk" mode, the iteration can deliver demand stories with business value at the end of the iteration, rather than a batch of "semi-finished products". In this way, through the close collaboration of development and testing, is gradually approaching the continuous delivery reflects business value.

3. When publishing:

After all the required stories are completed at the end of the iteration, we can get the "test plan official version" that contains the complete test case content. From this, a test report is generated, and it is judged whether it can be released to the next environment (such as STG) according to the pass rate and the risk reflected in the report.

to sum up

CODING The core concept of the testing workflow from the iterative perspective is to guide the advancement of testing, which enhances the collaboration and feedback between testing and other roles in the process . The purpose is to help the team solidify good practices through product capabilities, so as to achieve efficient testing:

First, plan the test as early as possible. Starting from the demand planning meeting, after fully understanding the requirements and claiming the tasks, we can delineate the scope of the test, and generate a simple version of the test plan from this, and quickly formulate acceptance criteria and complete the preparation of preliminary use cases.

Secondly, by establishing the relationship between requirements and use cases, the required tests for high-priority (business value) requirements are clear at a glance, laying the foundation for a risk-based testing strategy (Risk-based Testing).

Thirdly, the parallel development of testing and development work is realized during the iterative process. While the development engineer is implementing the business code, the test engineer can further refine and complete the test cases, and even realize the automated code implementation of the test. through close coordination and "small steps" , each delivery is a "finished product" with complete business value.

Finally, the operation and the data generated during the testing process are recorded and can be quickly fed back to the team, and these precipitated data will become the guide for continuous improvement of engineering practice.