preamble
Codes is China's first open source project management platform that redefines the SaaS model, supports cloud authentication, local deployment, all features are open, and is free for teams of up to 30 people. It simplifies test collaboration and makes agile testing easier to implement by integrating iteration, kanban, metrics and automation. It also provides low-cost agile testing solutions, such as synchronized online and offline test cases, process management of defects, automated testing of low-code interfaces and CI/CD, as well as iteration-based test management and costing of test time, to practice agile testing.
Codes Agile Testing Functional Architecture Diagram
1. Background
Agile development is becoming increasingly popular and Agile R&D has been effective, as evidenced by the figure below:
Agile Testing is an Inevitable Requirement for Agile Development
Continuous delivery reduces release risk, increases reliability, and enables the software to be continuously adjusted in response to user feedback, market changes, and changes in corporate strategy; Agile testing is a continuous, rapid, and effective testing process, and as an important part of the software delivery pipeline, Agile testing is a key way for organizations to improve and accelerate delivery.
Unfortunately, testing has become the biggest shortcoming in continuous delivery in agile development. There are 7 main reasons why testing becomes a bottleneck in agile development rapid delivery:
1）、Use case maintenance efficiency manual testing accounted for a large proportion of
2), test output is difficult to quantify
3), test the left and right shift difficult
4) Difficulty of efficient collaboration between test managers and test executives
5) Slow testing and fragmentation management
6）、Use case reuse is difficult or inconvenient to reuse
7), defects management is too rudimentary, mainly driven by people
In the VUCA era, the market requires enterprises to respond quickly to changes, enterprises need to focus on internal resources, continuous trial and error and rapid iteration, and be more flexible in responding to external changes; in the era of inventory, the requirements are getting higher and higher, how to test "agile" up?
2、What is the key to agile testing?
From the perspective of adapting to Agile development, the key to implementing Agile testing lies in the following 5 elements
Iteration as the implementation of the test organization; Kanban so that the various stages of R & D activities open and transparent, the test work transparent,; automation can improve the efficiency of the test; metrics so that the results of the test can be quantified; test left and right to make the test to follow the rhythm of development, and early testing, right shift a test can be independently maintained test environment, and two can ensure that the production environment of any wind blowing can be tested by the test to perceive.
The above 5 elements are also justified in terms of quality management hierarchy and quality categorization.
Quality management hierarchy:
Quality classification:
3、Agile testing is different from traditional testing
The process is the same as the figure below, the key lies in the different forms of test organization and management. For example: the timing of intervention, the use of some means of different, the entire organization of the test process is the biggest difference.
4、Codes Agile testing implementation
Codes allows iteration, kanban, metrics and automation to be integrated into test collaboration in a well-organized and coherent way; while at the same time, it easily helps test tests to move left and right, allowing agile testing to take place in a "silent" way.
Codes Organize tests in iterations
Codes Agile Testing Collaboration Diagram
1), test left-right shift is relatively more difficult, Codes has a good solution
CI/CD and interface automation for students who do not have the ability to code, is a difficult to cross the hurdle; left shift as long as there is a demand management related functions, you can demand stage on the intervention test and decomposition of demand as an example. Interface automation, CI/CD are all commonly used means to improve testing efficiency, but they also face a series of problems that are difficult to realize. See the following Codes to solve the problem.
The common technical problems of interface testing are shown in the figure:
Codes One by One Easily Solves Interface Testing
Below:
Drag-and-drop generation of assertions and drag-and-drop extraction of parameters
Make interface testing foolproof; innovative interface chaos test, instantly complete the interface robustness test (no exhaustive, just configure the chaos rules Codes to go since the permutation to execute); in addition, built-in more than 50 commonly used functions, to meet the needs of daily parameterization.
Automatic derivation of interface dependency topology maps
Let the interface relationship is no longer a black box, convenient interface call chain, so that interface testing can also be a luxury, using the advanced features of APM.
Drag-and-drop interface scene orchestration saves even glue code
Adopting the pair-oriented attribute naming, and then complex image, with the form of the expression of its attributes, readability, and very easy to configure in the excel data driver file, otherwise complex json image with Excel can not be expressed. For a complete solution on Interface Testing Codes, please refer to our team member's original post on testerhome.How Test Architects Interpret the Various Controversies of Testbeds.
Drag-and-drop CI/CD orchestration
CI/CD For most of the tests, you can only rely on the operation and maintenance colleagues, wait and wait, many times not good with the
Codes adopts innovative zero-code CI CD: drag-and-drop easy pipeline scheduling, shielding the complexity of the underlying platform, and easy pipeline scheduling as if you don't know how to write scripts; it helps testers move to the right with zero foundation, breaks through the barriers between testing and operation and maintenance, and improves testing efficiency.
Left shift can be a good solution to common requirements management problems
Test early intervention on the demand for testing can be in advance to avoid some of the problems around the demand to pull through all the R & D activities, complete closed loop, not afraid of being dumped. Brain map view is easy to sort out the business logic relationship between the requirements.
Under iteration from the beginning of requirements pull-through to testing, to release, all activities are traceable and all stakeholder information is aligned.
2), use case management Codes is also a unique innovation to solve the problem of poor reusability, maintainability bad problem
Codes Test Case Management Agile Solution
Product use case libraries and public use case libraries coexist.
The key lies in the product use case library. The use cases in the product use case library and the project can be synchronized in both directions, and when synchronized, the project requirements are also synchronized together. If there is any change, the historical version of the use case will be saved automatically.
Online and offline use cases can be not only imported but also synchronized to improve the maintenance efficiency of use cases.
After exporting the use cases to Excel, they can be modified offline, executed, and imported online synchronously after adding new use cases. This is also why Codes does not have a review function on the platform, because the review, whether online or offline, is a collective activity, the review is directly modified on the exported use cases, and then synchronized to the line after the modification is completed; the review on the platform is simply to walk down the process, just process compliance, no practical use.
If the module, type, priority, or label entered when importing a use case does not exist, it will be automatically created on the system.
Brainmap use cases keep the brainmap simple, no need to specify a special format, keep the original usage of the brainmap
The leaf nodes are the use cases, and the others are used as mod-fast. The brainmap is also maintained as a file, except that it is synchronized bi-directionally on both sides when converted to standard use cases.
Standard use cases can also be displayed as brain map views
Business Scenario Use Cases
The combination of multiple single use cases organized into business scenarios is another way for Codes to reuse use cases and manage them by business scenarios at a glance. In addition to a single functional use case, there are different business scenarios, especially process functional testing, there are scenarios are not afraid of missing, but also easy to manage.
3), iteration-centered to organize and carry out the test work
In reality, in a certain round of testing, different people must execute different use cases, and then the test manager can need to know the overall test progress and the test progress of each person. The traditional test plan has a big disadvantage: only use cases are assigned under the plan, and there is no way to specify the executors. The executors may be agreed verbally and passed on by word of mouth, or different people may build different test plans, which increases the workload and makes it impossible to check the overall progress.
Divided into four steps: first assign use cases, assign executors, execute use cases, view execution results
As shown in the figure below, the first step assigns the use case first, the second step assigns the executor, and the third step executes the use case. It is also possible to switch between different views.
Step 4 You can view overall and individual implementation progress.
Multi-view switching
It is also possible to switch between performer, status, category, priority, requirement and brain view. The figure below shows the brain map view.
Fast execution of use cases
If it is regression testing or test cases are very familiar with, you can batch fast execution, as shown in the figure below, the tree on the left shows the current executor of the assigned use cases corresponding to the requirements, and the number of cases under each requirement and the number of executions, such as the execution will be a tick. Of course, you can also export the offline execution and then synchronized to the line.
Go back and look at assigning use cases to iterations
That is, which use cases are to be executed. When decomposing requirements into use cases under an iteration, the decomposed use cases are automatically assigned to the current iteration, while other use cases need to be assigned manually. This is shown in the figure below:
In the above figure, "Assign" means to assign the checked use cases to the iteration, which can be selected across the page; "Assign All" means to assign all the use cases of the current query to the iteration; the last button means to assign the use cases under the requirements checked in the left requirement tree to the The last button means to assign the use cases under the requirements checked in the left requirement tree to the current iteration.
How Test Cases Calculate Execution Hours
In addition, only Codes has a solution on how to calculate the execution time of test cases. Each use case has execution cost, that is, execution time, through the execution cost can be counted to the execution of the use case time, the number of cases does not represent the execution of the use case workload.
Going back to assigning use case executors
That is, the division of labor among the people executing the use cases. The tree on the left shows the requirements corresponding to all the use cases under the current iteration, and each node in the tree shows the number of use cases and the number of use cases that have been assigned to an executor, and a checkmark will be shown if they have already been distributed. When assigning executives, you can manually check the use cases one by one and then assign them to executives, or you can directly check the requirements in the tree on the left and then assign the use cases under the requirements to an executor.
Routine execution of use cases
In addition to the quick execution above, let's look at the regular execution of the use case
Routine execution will be a pop-up window to display the details of the use case, the left shows the current implementation of the person assigned to the use case corresponding to the requirements, and the number of use cases under the requirements and the number of executions, such as the execution of the end of the display of a check mark. As shown in the figure below:
Brain mapping use case execution
If you only use brainmap cases, you can directly divide the brainmap file into one or more iterations, and then execute the cases directly in the brainmap, just switching to which iteration you want to execute them in before executing them, which is accessed from Brainmap Maintenance in the Use Case Management Center. You can import into Xmind or write the brain map directly on the web.
4）、Process-driven defect management
Defects are also incorporated to be handled under iteration
Traditional defect management has problems as shown in Fig:
Foolproof defect management process configuration
Codes adopts an innovative process-driven approach, which is able to "adapt to local conditions", leaving behind one-size-fits-all, and adjusting the testing process in real time to reflect different control purposes; different processes correspond to different bug statuses, which is more reflective of the project's realities and drives the evolution of bug statuses according to the process.
Configuration workflow is too complex. Codes uses a simplified configuration, what process to enable and select the process nodes on the processor, as shown in the figure below, a complete process from 1 to submit the problem, 2 to test the cross, 3 to analyze the problem, 4 to assign the problem, 5 to modify the problem, 6 to the development of the mutual verification, 7 to the arbitration of disagreements, 8 test confirmation. This process can be said to be the most complete network of a defect flow process, the figure starred for the mandatory process, the other optional, the process can be modified in real time. See
Codes R&D Management Platform - An Innovative Implementation of Process-Driven Defect Management.
Defect flow
Relevant personnel to deal with defects, do not care how many kinds of defects state, defect control engine will automatically according to the test process, the current state of the defects and the processor in the project test process in the process node automatically calculated, the current can be converted to what state as well as selected a different state after who as the next processor. In the defect management list, click on the status of a defect to enter the defect flow processing. Here are a few examples to illustrate.
The above figure shows an example of the statuses that can evolve when a developer handles a defect on the modification issue node: if it is set to "puzzled/need more information" or "not wrong" it will automatically go back to the testers, if it is set to "pending/not scheduled for modification" or "pending/next version modification" it will flow to the arbiter, and the test confirmation session will flow to the test confirmer. " pending/next version modification " will flow to the arbiter, if set to " changed " or " changed/synchronized to the test environment ", it will flow to the test confirmation session, and the test confirmation will be closed after closing. and then closed.
Example of a test submitting a defect
If the next process after the test submission is to modify the problem, then the newly submitted problem is "to be modified" status; the next process is the allocation process on the "allocation" status and transfer to the allocator to deal with; the next process is the analysis process is "analyze" status and transfer to the analyzer to deal with; and the next process is the test mutual verification, is "to be placed" status and transfer to the mutual verification person to deal with; and if the mutual verification person thinks that the defect "to be placed", describes the defect, and transfer to the mutual verification person to deal with. Analyze" status and transfer to the analyzer to deal with; the next process for the test mutual inspection, is "pending" status and transfer to the mutual inspection person to deal with, and if the mutual inspection person that "pending" defects, description of the problem, can be set to The next process for testing mutual inspection is "pending" status and transferring to analyzer for processing, and if the mutual inspector thinks "pending" defects and descriptions are problematic, it can be set as "corrected/inadequate descriptions" or directly "withdrawn".
Defect flow history and time spent
Before going live, defects generally require a daily resolution, and we want to be able to view information about the time spent on each session. codes records the time spent on each node, as shown in the following figure:
related parties
Defects can be associated with requirements, so you can view the details of requirements at any time; defects can also be associated with use cases; and defects can be automatically associated with gitlab commits via webhook.
5）、Statistical analysis and metrics
Quality Large Screen
In addition to the quality dashboard there are a range of statistics such as defects timeline, with test overview, and more than 20 other statistics.
Test Overview
Interface Overview
Network-wide Unique Defects 6 Trend Chart
Exclusive to the entire network:*Submit | Open | Pending | Modify | Close * Defect 6 Trend chart that shows who is slow in the testing and development teams.
Deficiency trend analysis
A total of 5 deficiencies were analyzed for trends as follows
Defect-related statistics
There are also 11 defect-related statistics, all of which are available by version, either a particular version or all versions, and some of which can be grouped by person or not.
Analysis of defective statute of limitations
Before going live, the defects can be managed well, and important defects will not be delayed due to the risks associated with these important defects. And the number of defects achieved in the chart below can also be drilled down to show the breakdown.
Test workload analysis
Compare and contrast the work of each tester, and each item can be expanded to see the details, as shown in the figure below:
Tester Briefing
As shown in the figure below:
Daily execution use case trends and breakdown
Can be grouped and ungrouped by person, ungrouped is the general trend.
Test Project Briefing
Project Activity Breakdown
Development workload analysis
Writing Use Cases Use Case Trends
Can be grouped by person or not grouped, not grouped to show the overall trend
Iteration report -- overview
Iteration report - use case breakdown
There are also a series of other statistics, which will not be listed, but only part of the statistical analysis related to the test samples.
6）、Generative global kanban, no longer need to manually create kanban
Generate Kanban in a reverse way, that is, by defining query conditions. Everyone shares a global Kanban board and customizes their respective Kanban boards. For more details, see Detailed
Codes R&D Management Platform - An Innovative Implementation of Generative Global Kanban.
(7), in addition to the tool platform there are two other issues that need to be resolved on their own
1) Continuous team building
Team topology, collaboration patterns, technical routes, and polishing the team's communication style.
The architecture of a team influences the patterns of communication and collaboration of the team, which is reflected in the products developed by the team and reflects the effectiveness of the team's research and development. Teams generate architecture based on their communication structure, which is stated in Conway's Law. Team topology is the network structure and relationships between members in a team. It describes the interaction patterns and communication between members of a team, including information transfer, collaboration, and decision-making processes. For more information on this, check out The High Performance Team Model.
(2), the construction of process standardization
Create process specifications as appropriate. The following two figures show the process specifications that have been built into the Codes:
8) and finally
Due to space constraints, we can't go through all of them, this article is just a selection of points for the introduction of walking style, but you can still see that we are as innovative as ever. More cool test management related, defect management related features to Codes to slowly taste, Codes agile testing is like a pot of tea, the more you drink the more fragrant, and "Codes unlimited local installation, 30 people for free" is enough for general companies, and 0 configuration installation, 2G memory is enough, go try it! It's better to retreat and use Code. Finally, we end this article with the overall functional architecture of Codes, so that you can understand the Codes "panorama"!