Shengcong Cheng – Product Manager of CODING
Continuous testing is transformative
Continuous testing (or agile testing) requires testing as an underlying activity throughout the software delivery process. In contrast to the traditional testing model that got bogged down in the DevOps era, continuous testing primarily changes the “post-test” situation, emphasizing pre-test, providing rapid feedback on business risks by defining tests early, testing in parallel with development, and working closely together during the process. The practical reform of continuous testing is a comprehensive engineering of people, process and technology: it requires both technical support, such as the basic ability of continuous integration and continuous deployment, as well as the improvement of personnel’s ability to automate code, and the improvement of process is also an indispensable part of it.
As with the four core values outlined at the beginning of the Agile Manifesto, teams should focus on actions and results that add value to the customer rather than the traditional step-by-step completion of a given project and production process deliverables, and this applies to testing as well:
- Individuality and interaction over processes and tools;
- Working software trumps detailed documentation;
- Customer cooperation over contract negotiation;
- Response changes are higher than compliance plans.
However, it’s easy to get confused about the literal interpretation of the “four higher than” in the manifesto: if collaboration is important, aren’t processes, documents, and plans no longer needed? No, the inherent complexity of software is still there, so the planning and documentation needed to deliver the software is still valuable. We just need to change the bloated processes, documents, and plans that are no longer tied to the team’s goal of quick response. So “process light”, “right granularity”, and “plan early” are the appropriate changes to make. If automated testing and precision testing are the improvement of efficiency at the single point of test execution, then iterative testing is the improvement of test efficiency in the overall process.
How do you practice continuous testing within iterations
The testing process typically includes planning, designing use cases, and executing. The following diagram shows a classic workflow from the testing perspective in an agile iteration. Let’s take a look at how to practice continuous testing in an iteration from the classic workflow of testing in Agile mode.
Based on the above scenario, we can carry out testing activities according to the following steps to achieve the goal of synchronizing with the development work and widening the testing time window:
First, at the iteration planning meeting, the product manager works with the team to interpret, analyze, and evaluate the requirements story. At task claim time, development and test (or another development person in this role) pair up for a requirements story. When the iteration plan is completed, a test plan corresponding to the iteration can be created, which should include a list of iteration stories and the corresponding Acceptance Criteria (AC).
Then, during the iteration, the requirements story that represents the business value should be delivered as a whole. That is, paired development and testing should work on one requirement story with equal priority, delivering the story end-to-end as quickly as possible before moving on to the next requirement story. So while the implementation code is being developed, the test should also be writing test cases for the story — in most cases expanding the AC in detail and completing the writing. When the use case is written, it should be reviewed in time, and even realize the code of interface automation test when the interface contract is guaranteed. This way every story is tested and ready for delivery as soon as it is developed.
Finally, after the iteration is complete, you can even execute a set of test cases that cover the requirements story of the current iteration and review the overall test situation as reflected in the test report for continuous improvement.
How does CODING contribute to continuous testing within practice iterations
Based on the scenarios mentioned above, CODING designs and refines products based on the concept of “test plan as the main body of testing activities” and strives to bring “immersive” testing experience to users. The following will demonstrate how to conduct a full iteration of testing activities in CODING test management:
- Iteration planning meeting:
First, review/create the team’s test plan and correlate the iterations, starting with the planned iterations in the project collaboration.
Then, after the team test plan is created, the requirements story for the iteration is presented in the plan. Then create the corresponding functional use cases for the requirements story, perhaps with the acceptance criteria (AC) agreed upon in the planning meeting, and assign the relevant use case tasks to the corresponding test students, forming an iterative kanban from the test team perspective. This can be done within a short time of a planning meeting or meeting, and the test plan consists of a list of iteration stories and corresponding USE cases for content, called “Test Plan Alpha.”
- Iteration in progress:
At the same time of developing the student implementation code, the test student simultaneously wrote the test case of the story, which gradually supplemented the complete test plan can be called “test plan beta version”. When the use cases are written, they are reviewed in time, and the code of interface automation tests is even realized when the interface contract is guaranteed. This rhythm allows testing and development to work in sync.
After the requirement story is tested, the test case is executed and the function is verified against the use case steps. In this “baby steps” model, iterations can be completed at any time to deliver a business value requirement story, rather than a batch of “half-finished products.” Working closely together through development and testing, we move closer to continuous delivery of business value.
- When released:
After the requirements stories are complete at the end of the iteration, we have a “test plan version” that contains the full test case content. This generates a test report and determines whether it can be published to the next environment (such as STG) based on the pass rate and the risks reflected in the report.
conclusion
The core idea of CODING iterative testing workflow is to lead testing to the front and enhance the collaboration and feedback between testing and other roles in the process. The goal is to help the team solidify good practices through product capabilities to achieve efficient testing:
First, plan your tests early. From the requirements planning meeting, once the requirements are well understood and the task is claimed, we can delineate the test scope, produce a simple version of the test plan, and quickly develop acceptance criteria and complete the writing of preliminary use cases.
Secondly, by establishing the relationship between requirements and use cases, the required tests of high-priority (business value) requirements can be clear at a glance, laying a foundation for risk-based Testing.
Thirdly, the parallel development of testing and development is realized in the process of iteration. At the same time that the development engineer carries on the business code realization, the test engineer can make further refinement to the test case supplement complete, even realizes the test automation code realization. Through close collaboration and “small steps”, each delivery is the “finished product” of complete business value.
Finally, the operation and data generated in the test process are recorded, which can be quickly fed back to the team, and these accumulated data will become a guide for the continuous improvement of engineering practice.