How can entrepreneurial teams implement agile testing to improve quality and efficiency?丨 Voice Network Developer Entrepreneurship Lecture Vol.03

foreword

Lao Niu is a senior test expert and technical architect. He has many years of experience in Internet companies and more than ten years of first-line R&D experience. He is also a practitioner of DevOps, and has also served as the management of the quality team in recent years. Among them, a technology platform in charge has been running stably for more than two years, and the cumulative call volume has exceeded 280 billion times.

This article is based on the reorganization of the content shared by Lao Niu in the " Soundnet Developer Entrepreneurship Lecture • Phase III丨How to Ensure Product Quality in the Early Stage of Entrepreneurship ". Follow the official account "Shengwang Developer " and reply to the keyword " JT0611 " to download PPT materials related to the event.

With the development and popularization of microservice architecture, cloud computing, and container technology, DevOps has gradually become a consensus among developers and has become a mainstream development model. However, in the rapid iteration of DevOps, testing has become a major shortcoming of rapid delivery, and agile testing is about to emerge. A lot of people talk about agile testing, but few talk about how to implement agile testing.

Taking agile testing catalysts as an introduction, this article expounds the four elements of agile testing and its organizational management forms, shares the testing dilemma of small and medium-sized companies, how start-ups can successfully implement agile testing, and the future development trends and prospects of agile testing.

01 Agile Testing Catalyst

1. Background

Like stock trading, software development includes both fundamentals and technicals. From a fundamental point of view, with the development of software engineering technology, software architecture and infrastructure, software engineering culture, and the competitive situation of products together form the basis of software development. With the development of the mobile Internet, everyone has begun to follow the idea of "fast but not broken" and compete for speed. The software engineering culture has also changed from waterfall before to now agile, scrum, kanban, etc. Only after these infrastructures and related basic levels reach a certain level, can the business be implemented.

Figure 1 is a description of the fundamentals. With the popularity of DevOps, the development of agile development/CICD, microservices/container technology/cloud computing, mobile Internet, and built-in quality have promoted the development of agile testing. The touch on the development side is It is very big, which improves the speed of development. In the process of rapid iteration, there are many pain points in the test, which is why I study the test from the architecture, that is, I hope to solve the short board of the test.

■Figure 1

2. DevOps expectations for testing

At present, testing has become a major shortcoming of rapid delivery. Many companies may release a version every week or perform an iteration every two weeks (or a month). With the increase of microservices, after the development of rapid delivery, if the testing is still used as before method, it is difficult to meet the demand, this barrel effect has a great impact on the entire team.

DevOps requires fast and effective testing and improved ways to accelerate delivery. As technologies such as microservices and cloud computing mature, we can conduct dynamic real-time quality monitoring, continuous feedback mechanisms, preventive assessments, and more. In addition, it is necessary to have the ability to manage the pipeline environment, because if the deployment environment depends on development or operation and maintenance, and if there is a pause at this time, then the work cannot continue. In fact, the testers can perform CICD by themselves, so that there is no need to Waiting.

For non-functional quality assurance, after going to the cloud, in addition to functionality, there are cloud-related multi-tenancy, stateless, elastic expansion, service statelessness, service governance, etc., testers also need Understand, otherwise it cannot meet the needs of agile development. Finally, the entire team also needs to have agile genes. I think to do agile testing, you should first understand what agile development is.

02 Try how to be agile

1. Four elements of agile testing

From the testing process, it may be the same, the order is plan-prepare-execute-report-release-online. The essence of the agile process has not changed, but its organizational process has changed, that is, its organizational model. Agile development includes scrum, kanban, limits, etc. I think that iteration and kanban can also be put into testing.

First, iteration is a form of organization; second, Kanban is to facilitate supervision and make work more transparent; and then automation is required, such as releasing a new version to do regression, the workload of manual regression for large systems is too large, and automation is needed at this time. To assist, this is to improve the efficiency of regression; finally, the output of testing needs to be measured. Therefore, if you want to implement agile testing, I think you must have these four elements: iteration, Kanban, measurement, automation.

2. Agile testing logic model

■Figure 2

Figure 2 shows the model for agile testing, with Kanban and metrics on the left and CICD on the far right. The sprint backlog corresponds to the sprint case, and the product backlog corresponds to the pro case library. The bottom layer is process-driven, and the above is the bug library. For this bug library, it contains To do and regression fixed bugs, as well as other To do (interface automation tests, smoke caseUI automation tests, and other activities). Each iteration is a repetition of these.

At present, many test management tools on the market do not have the concept of iteration, and basically use testlink, but it is no longer suitable for agile mode.

Let's look at the limitations of the organizational form of testlink testing. Because there is no iteration, this abstraction layer is particularly inconvenient for the process management of test execution. A plan (the process of building a plan is also very tedious) is a set of test cases (or a test task) to be tested, and 10 people are required to perform different tasks. For testing tasks, 10 plans must be built. From the management level, it is impossible to know how many test tasks there are in a certain iteration, and how the overall progress is.

In addition, it is better when there are fewer team members. If there are 10 people, the process management of testlink is quite inconvenient. There is no overall perspective to assign test tasks and follow up on the progress of these tasks. And use case reuse is not to mention. There is no product example library that can synchronize project use cases in both directions, and there are no convenient functions such as brain map use cases. Statistical analysis is also weak, and test management is not only about use case writing and use case execution. There are other tasks related to moving forward and backward.

3. Continuous improvement of agile testing

Following the PDCA principles in project management, including four elements of planning, implementation, inspection and action, corresponding to agile testing is the process of execution-assessment-improvement, as shown in Figure 3.

■Figure 3

Only with these process elements can agile testing work truly be implemented. Our work is performed on Kanban boards for transparency. Then assess asset quality risk through metrics, including process monitoring, result analysis, and team evaluation, and finally provide continuous feedback and iterate around this process. This leads to the question, does your test tool itself support management in an iterative manner? This is a question worth thinking about.

4. Agile testing metrics

In addition to regular statistical analysis, a large quality screen is worth having, which is very helpful in promoting quality awareness.

Figure 4 shows the monitoring of agile testing, which includes the situation of the use case, the situation of the accident, the situation of CICD, the execution of the use case, the cost of the execution of the use case, etc. This is just an example.

■Figure 4

03 The Dilemma of Corporate (Agile) Testing

1. Small and medium-sized companies test chaos

There are many chaos in the test of small and medium-sized companies. I have summarized several aspects as shown in Figure 5:

■Figure 5

Many companies do not have version planning, which leads to the development of requirements testing and development, and bugs cannot be converged at all; with the continuous change of requirements, the testing time has been compressed, and the testers are blamed for not producing direct value; the project does not have effective project management Mechanism, especially for small and medium-sized companies (large companies are very sound and standardized), basically, the completion of the project depends on people, and normal companies should rely on systems rather than people; projects do not have a good quality management system, only through mechanical In fact, I think that tools are only used to help the implementation, and tools should be used or adapted through the concept of management. Management must be systematic and standardized, including process specification, process monitoring, continuous Iteration and feedback; no training mechanism, information transfer between teams is just word of mouth, etc.

2. Common problems encountered by front-line testers and test managers in small and medium-sized companies

I summarize the common problems encountered by front-line testers and test managers in small and medium-sized companies, as shown in Figure 6.

■Figure 6

For testers, the common problems encountered include the lack of a particularly easy-to-use platform, which affects work efficiency; it is difficult to ensure the implementation of the quality control process (although the company may have relevant regulations, but how to ensure that the process is in accordance with the regulations? From the tester's point of view, as long as you follow the regulations, you don't need to understand too many management issues, but if you can't implement an effective method, you may be returned to other departments); test tasks It is inconvenient to follow up; it is difficult to reflect the workload and work quality with data, which is a common problem encountered in many companies.

For test managers, the common problems encountered include the single dimension of the reported data, the insufficient analysis of the test process (if the analysis is not sufficient, the potential risks cannot be found or improved); the lack of project baseline management, Process management such as version iteration management and test task management, follow-up and optimization of the test process are difficult.

3. The testing dilemma of small and medium-sized companies

Regarding the testing dilemma of small and medium-sized companies, I summarize five aspects, as shown in Figure 7.

■Figure 7

4. The crux of testing trouble

Summarizing the above phenomena from the outside to the inside, the essence of the problem is that there is no quality management system, lack of quality control means, and weak infrastructure (infrastructure includes test environment, operation and maintenance environment, etc.) / results are difficult to measure, these are the main crux.

04 Sharing of agile testing landing cases

Three cases are listed here. The first one is a real case, why should it be highlighted in the first case? Because I think big factories are generally more standardized, so how can these specifications be implemented and practiced in small factories? I think this is an example that everyone should learn from. The second case is a start-up company, which does not have many standardized processes and resources. Here is an introduction to how they gradually landed with tools, and summed up their own processes and management norms. The third case introduces start-up companies. These companies may only have 11 or 2 people, including the boss. They do not have professional QA but need to achieve high-frequency release.

1. Common goals

Whether it is doing agile testing or other testing, I think our common goal is to create professional testing, improve testing efficiency, build an integrated tool chain, and improve the quality awareness of all staff. A further extension is the built-in quality, including system-people-target-efficiency.

2. From large factories to small factories, practice agile testing with top-level design

(1) Differences between large and small factories

The difference between large factories and small factories is shown in Figure 8. Large factories have a lot of precipitation, the system is relatively sound, and the troops are strong, but the department walls are thicker, the communication cost is relatively high, the system is rigid and inflexible, there are many wheels of repeated invention, and the infrastructure is relatively Perfect, the team management cost is high. Small factories are basically in the state of pioneering, there is not much precipitation, the system is not perfect, the quality awareness is not strong, the quality test management is relatively weak, the software and hardware are uneven, and they have certain environmental management capabilities, but there are few platform tools or If it does not get through, the overall technology of the team is slightly weaker, and it has a certain ability to test and open. The advantages are flexibility, speed, and relatively low management costs.

■Figure 8

As shown in Figure 9, the differences have been analyzed before. When implementing agile testing, it is necessary to conduct a thorough investigation. First, understand the current situation, understand the current situation, and then understand the demands of front-line personnel and managers, and identify outstanding problems. . For example, if the version is released randomly, if the version is released randomly and the changes are frequent, then everyone will be exhausted.

■Figure 9

According to the results of the investigation, preliminary conclusions are drawn: the specifications of large factories are not applicable in small factories, and there is a need for trade-offs; what problems need to be resolved in agile transformation; in pursuit of quality and efficiency, lightweight teams can quickly iterate; use The agile test management platform can shorten cross-departmental communication and solve the problem that the traditional tool chain is fragmented and not connected.

(2) Top-level design: test life cycle and organizational process

According to the conclusion, it is possible to continuously iterate different versions from the top-level overall test life cycle, from the review of requirements to the production verification after version release and then to the online process. There are even multiple versions in parallel. The specific process As shown in Figure 10, it includes test plan, test preparation (the most important of which is access and exit conditions), test execution (including defect analysis, access judgment, etc.), test report, and release online. In the process of testing, through reasonable, scientific and standard testing steps to standardize the testing process, the results can be guaranteed.

■Figure 10

Figure 11 shows the entire testing process:

■Figure 11

(3) Agile testing landing process: infrastructure construction

After the top-level planning is divided into 5 aspects, the first is to establish a system in terms of infrastructure, as shown in Figure 12, including the release process, the test organization process, the management of the life cycle of the bug, the circulation mechanism of the bug, and the specification of the bug. , as well as custom maintenance of dictionaries, specification of use case writing, output of reports, etc.

■Figure 12

(4) Agile testing landing process: team building

The construction of the team is shown in Figure 13, including the construction of the echelon. After the investigation, the team leader can be promoted, the core members can be identified for training, and new employees can be trained (department functions and profiles, business scope, work mechanism, annual planning) etc.); quality awareness, after establishing the norm, it is necessary to carry out education and training, so that everyone must understand the quality norm, especially the team leader, because he is the smallest management unit for implementation, he must have a deep understanding of the quality management system. Content; formulate a one-year or one-and-a-half-year technical development route, set a tone for team technology, and let everyone learn or improve around this direction without deviating; build a learning team.

■Figure 13

Try to mention as little money as possible. It is difficult to do things that spend money. Overcome difficulties and use existing resources to get the best results. Once you have achieved performance, you can reach out to your boss for money in the future.

(5) Agile testing landing process: process management construction

The construction of process management is shown in Figure 14. The iteration was mentioned earlier. Here, it is necessary to define what kind of iteration is to be carried out (it is to iterate by version or by time period), as well as the task assignment and supervision of each iteration What is the mechanism? Process management can also be placed in the infrastructure, but I think it is better to separate the process management separately and focus more on process optimization.

For the process monitoring part, during the execution process, such as the process of reviewing the environment, what is the management process of the environment, and what is the response mechanism for online problems, these are the contents that need to be paid attention to in process monitoring; for the reporting part, in addition to testing In addition to the internal reporting, it also includes the mechanism, form and content of the quality reporting to the PMO. It is necessary to improve the process from the whole project management, and at the same time, there must be relevant measures for assessment (not self-interest, there is a big stick and a date), otherwise, it will be nothing in the end.

■Figure 14

(6) Agile testing landing process: platform construction

For small factories, it is necessary to build a platform. As shown in Figure 15, management tools should be used as an aid. Otherwise, if the team is trained according to the traditional cycle, the time will be very long. At this time, if a management platform that conforms to agile testing is imported, you can quickly improve various specifications and implementations through tools and tools in an unmanned manner, and then define the demands of agile testing management platforms, and make comparisons in selection accordingly. After the POC is completed, it will be benchmarked with the previously customized quality management system, and the results of the POC will be objectively evaluated for point-to-point, training, and promotion.

■Figure 15

(7) Requirements of agile test management platform

The requirements for an agile test management platform are shown in Figure 16. What kind of capabilities does it need? Including support for tracking the whole process of requirement production to implementation in terms of product and iteration; tracking the execution process of version test plan; designing, writing, reviewing, maintaining and managing test cases in terms of version; tracking and management of defects; version Statistical analysis of quality and testing process data, this part is the basic functional requirement.

Then there is the security issue of the platform, because it is necessary to emphasize security compliance, and security compliance cannot occur after the introduction of tools (such as interface testing, using an online platform, your token, encryption and decryption processes, etc. may cause security problems), data leaks, etc. Next is ease of use, where the requirements must be delivery friendly and have low learning costs. Finally, it is necessary to have secondary development capabilities.

To sum up, the daily workflow management of the testing department and the safe, stable, easy-to-use, and customizable testing process are also what the platform needs to have.

■Figure 16

When choosing a model, the most important thing is to see whether it is updated frequently, not advertisements, and whether it is safe and compliant. If it is free, but it is only free online, it is very inappropriate to use the interface test, it is free It's just a gimmick, and security compliance simply can't pass the test. If you want to use commercial products, you must have legitimate reasons to convince your boss to pay the bill. If you can’t reduce costs and increase efficiency, it is better to use commercial products that are free alternatives. If you don’t create value for the company, how can the boss pay the bill.

For example, the commercial interface test you choose has not lowered the threshold for use at all. Only the test can be played well. It is difficult to say that the cost can be reduced. Be sure to choose a PLG-oriented, that is, product-driven, Blue Lake is an example of PLG, she is very good, but how many Blue Lake advertisements have you seen!

(8) Function benchmarking of agile test management platform

As shown in Figure 17, I benchmarked the functions of the agile test management platform according to the previous model, including environment maintenance, test process settings, interface use cases, manual use cases, and different iterations.

■Figure 17

Among them, in each iteration, not only the execution of test cases, but also bugs and other transactions. Below the iterations are reports of various analyses. Once the required tools have been identified, after evaluating the tools, we can reversely promote the transformation of the team's agile thinking and make agile testing within reach.

Figure 18 shows a kanban board where bugs and use cases can be handled, and from a leadership perspective, a kanban board provides visibility and transparency into the progress of tasks.

■Figure 18

Figure 19 shows the iterative report, including use cases, interfaces, tasks, bugs, etc. After exporting, planning reports and various detailed data will be generated.

■Figure 19

In addition, the testing process can be set up, as shown in Figure 20, not only the usual familiar problem submission, development, verification and repair.

■Figure 20

If there are many novice testers, you can start the cross-testing process, so that after the newcomer submits the bug, it can be transferred to the hands of experienced testers for review, so as to guide the novice. He also preaches, for example, how to write a good bug.

Other processes include analyzing and modifying work hours, interactive testing between developers, and arbitration after disagreements. These testing processes can be changed in real time according to different stages of the project or different periods of the team. Different processes also correspond to the evolution of different states (the current process and the current handler can control the BUG state that can be converted by the current bug), so that fine-tuning can be performed as needed.

At present, the tools I see on the market are basically written to death, and the status is very simple. Many of them do not meet the needs of management at all. For example, "to be changed/continuous tracking" is used for occasional bugs. Through this state, you can directly see the current processing result of the bug. In addition, if the developer sets the bug status to "not wrong" and the tester does not agree, it may be set to "disagreement" and it will flow to the arbitrator. The status is "to be changed/delayed", after the arbitrator agrees, it will be changed to "to be changed/modified in the next version", if not, "to be changed" indicates that the current version must be modified.

Earlier we also talked about frequent changes. As shown in Figure 21, use cases can be maintained offline and then synchronized to the online. This is not the concept of import, but the export to perform offline modification offline.

■Figure 21

(9) Agile test landing process: measurement and automation

Through interface automation, it can be done: to supplement the shortcomings of development self-test; it is easy for junior personnel to get started; smoke quickly; regular inspection; ;Complete the tracking of the call chain and the topology of the interface; the key implementation of the test is opened, and the components are serviced.

As far as metrics are concerned, process monitoring, trend analysis, result analysis, workload analysis, bug handling timeliness, task progress tracking, and testing focus on multi-dimensional statistical analysis. As shown in Figure 22, the interface topology diagram (automatically derived) can be derived in interface automation, which is convenient for troubleshooting tasks. If there is an error, you can leave the service under test and see everything directly on the adjustment chain.

■Figure 22

As shown in Figure 23, an expression can be automatically generated by the assertion generated after dragging and dropping:

■Figure 23

Figure 24 shows the operation of dragging and dropping variables:

■Figure 24

Figure 25 is the topology diagram of the interface. There are dependencies between the interfaces. If the manual execution method is used, I think it is to strengthen the business logic in the mind. With the increase of the interface, it is easy to cause confusion.

■Figure 25

But the interface platform here is automatically derived, so when the interface is executed, the transaction chain can be automatically generated, as shown in Figure 26.

■Figure 26

When assembling the interface into a more complex scenario, the call chain might look like Figure 27:

■Figure 27

The parameters of the interface call are shown in Figure 28:

■Figure 28

In addition, interface chaos testing is also supported, see the post on testerhome listed at the end of the post for details.

In addition, there is a case of using an anti-pattern to achieve the coverage of the use case. For example, a case needs to be associated with a bug. If it is found that 5 of the 10 bug results are not associated with a use case, one case is that no use case has been written before, and 10% of the values are allowed to be explored. The ultimate goal is to calculate the bug and The ratio of use cases. This is not a requirement to write the use case from the beginning, the purpose of this is to avoid risk. In this way, as the project progresses, even if you complete the use case on the day the project goes live, from the perspective of the company, since the use case is so complete, the change of personnel will have much less impact on the project.

Use case coverage calculation formula: ((number of use cases - number of unrelated bugs) / number of use cases) can be +10%, and if a bug has no unrelated bugs at the beginning, it is also 0. At this time, it is 100% correct. Changed, if it is a negative number, it will be worse, in short, the smaller the value, the lower the coverage. If it is low 1, there may be no time to write use cases; 2 is written for time, but it is not written seriously. After calculating it, add a 10%, 10% exploration is reasonable, we do not force the tester to write all the use cases at the beginning, we encourage the test to enrich the use cases, the supplement is also counted as he wrote, subsequent versions, this use case There is, so that someone who leaves is not afraid of the use case; this is not a one-size-fits-all approach, it just guarantees a good result in the end.

Instead of just looking at the number of use cases, it is measured by the cost of execution. An example of the measurement can be seen in the screenshot of Case 29.

■Figure 29

(10) Agile testing landing process: problems encountered

The problems encountered during the landing process are shown in Figure 30 (the top is before the event, the middle is during the event, and the bottom is after the event).

■Figure 30

In the early stage, including the lack of cooperation during research (I think the testers should take the soft test for advanced items, not the PMP test, because I think the PMP can be passed by spending money, so the things that can be learned are limited, and the soft test is more focused on IT. After mastering this knowledge, you can conduct research from the perspective of project management, the vision will be different, and the most reasonable plan can be proposed when the vision is open), obtain the support of testing and R&D leaders, lack of resources, and objections. , Get the support of developers and PMs, and the project test and demonstration will not go back.

When promoting reform, one of the main reasons why it cannot be pushed forward is that there is no soft power, and no one will believe your words. When pushing for improvement, it must be pushed from the aspect of project management. It cannot be said that development is not good. Testing is affected. Of course, development is not happy. It is necessary to discuss process improvement from the overall situation. If you want to push from testing, those who push You must have the perspective of project management, otherwise, when you communicate with the above, it will be difficult to speak, and there is no high level. How can the above trust you, right? , The main thing is that I really need to learn something. Either I have worked in a big factory and have a foundation, or I have systematically studied it myself, and I slowly understand it in my own work, which is too slow.

In a word, soft power is based on the height of your conversation and the external manifestation of your cognition in the process of communication with the above. Test management is actually very false, but it is not that simple to do it. , I have been working for so many years, I have been learning and improving my management system. When I did the test, our team played the role of the firefighting team. When we needed to tackle tough problems, we would go out. Although there were many difficulties, we still did it. When we did it, we had the right to speak. It also indirectly improved our soft power. Let’s talk about the objective reasons first, as long as you do your best, don’t worry about anything else, the more you do, the faster you grow. If the boss is blind and can’t see your value, just vote with your feet.

In addition, testers should be curious about new technologies and new things, and have a growth plan every year. If there are any new technologies and new tools, they should learn more about them, try to POC as much as possible, and do not reject new things. Only in the follow-up can the seam source be left and right, and the proposed scheme can test all aspects.

As a tester, if I don’t know what the mtsc conference is about and don’t know testerhome, I don’t think it should be; if I have an interview, I have to test my learning ability and desire to learn. Such people must be self-motivated and worthy of focus. people with endless potential. Every year, I have to make a summary. In addition to my own work, I have any progress in technology, what I have gained and lost, what suggestions I have for the management system, what problems I have seen, etc. These are all worth summarizing. Every year is so-so, 5 years of work and 2 years of work, there is no progress, this is dangerous; also be willing to share, don’t be afraid that your big move will be learned, sharing is also self-summary. Slowly the soft power ice will improve, which is a slow growth process.

As mentioned above, the overall promotion of process improvement from the perspective of project management is mainly to form a common engineering awareness for everyone. Even if the technical level of the team is good, the technical staff's business awareness is also very good. If there is no engineering awareness, cooperate and communicate. Very troublesome.

The implementation process includes the impact of urgent needs and demand changes, which can be solved by establishing product planning, product iteration systems, and improving project management systems; development self-testing is insufficient, branch version management is messy, and development can build branch versions at any time, but in the process of mentioning. When testing, only the merged version is tested. In the later stage, it is necessary to analyze the generated problems through measurement, including progress analysis, quality analysis, and then solve the problem.

3. Start-up companies, guided by tool platforms, gradually practice agile testing

Figure 31 shows the demands of implementing agile testing step by step with the platform as the traction.

■Figure 31

Including the platform is simple and easy to use, can standardize and solidify the management process, manage use cases and bugs quickly, facilitate the PM to play the role of supervisor, deal with frequent demand changes, have more defect status, establish an effective execution management system, and gradually implement agile testing . The test leader of a small company may not know what a good process is, so the reverse method can be adopted, focusing more on process management and speed, integrating iteration, Kanban, measurement and automation into the testing process, and then finding tools And reverse its process, sum up the applicable formula process, such as the flow of testers, test managers, assigners, developers, and arbitrators, etc. shown in Figure 31.

The states shown in Figure 32 may be somewhat different from what is seen on the market, because they are organized through deep research and reverse engineering.

■ Figure 32

Documents organized in this form include testing process, smoke testing process, bug handling process, etc. It promotes the team's agile testing in reverse in the form of tool process. Through in-depth study of the tools, combined with the understanding of the company, you can sort out a specification system that suits you.

■ Figure 33

As shown in Figure 34, the release version here is also in offline form, and the real-time customization of the process, the processing of bugs, and the evolution status will not be repeated here.

■Figure 34

■Figure 35

■Figure 36

■Figure 37

■Figure 38

■Figure 39

4. The secret of starting a startup company without QA and high-frequency release every two weeks

Startup companies lack everything, even the founders are working, but the direction and business are very clear, with dreams and innovation, it is also an honor to join this kind of team. In this case, the intensity of the demand should be controlled, and each demand should be split as much as possible, and it is not allowed to spend two days to realize a demand, and force the product through the demand. In addition, each iteration needs to implement the review of the technical solution. The review requires a simple explanation of the idea. You can perform an iteration every two weeks. The unit and interface tests are performed on the Thursday of the first week, and the business is tested on the Wednesday of the second week. remain effective.

In terms of process management, I do not advocate overtime behavior. When I go to work, I only do work-related things, and manage them in a flat and transparent manner. In addition to sending the daily newspaper to the boss, it should also be sent to the work group so that everyone can see it. For start-up companies, if they are still in the MVP stage, the founders have high requirements for products, basically in the form of the founder serving as the chief product, but this is only a short-term transition, and ultimately a testing team is required.

05 Agile Testing Trends and Prospects

For the follow-up outlook, I agree with testOps, as shown in Figure 40.

■Figure 40

06 Q&A session

1. How to prepare a perfect test case in agile testing?

In our opinion, the use case is incomplete, mainly because there are no missing test points in the checklist. From the perspective of execution, attention should be paid to details, but from the perspective of leadership, a complete use case should first not miss test points. If you miss test points, it is useless to write in detail. When doing a use case review, I don't look at the details of the use case, but whether the test points are complete. So I think a good use case should have a complete use case test point. You can see what the use case is doing by looking at the title, so as to sort out whether the test point is complete, otherwise, no matter how much details are written, I think from the platform point of view, there is no way to spend it. time to see.

There is no omission, so how to ensure that the execution details are not wrong? This requires a business explanation first, and then an inspection. Through the business explanation, we can cover it well. Whether our testers really master the business, the business does not understand, and the test results are definitely not good, so don’t even look at it. his use case too.

2. What is the name of the tool or platform shared in the case, can you share it?

This platform is free, you can search it with the keyword "Open Source China Agile Test Management Platform" to search. You can also take a look at this post on testerhome with 122 likes and nearly 2 W views.

https://testerhome.com/topics/30495How test architects interpret the various controversies of test platforms or visit www.itest.work directly

Upcoming Events

On the afternoon of July 16th, the 4th session of Shengwang Developer Entrepreneurship Lecture will be titled " How can the entrepreneurial team ensure the safety and compliance of product business? " Everyone brings wonderful sharing.

It's better to take action, scan the QR code or click " read the original text " to sign up!