Typically, there is no interaction between innovation and product conceptualization in software delivery. Nevertheless, with the increasing demand for new functionality for products and the shortening of the corresponding product lifecycle, even business models have made it necessary to put continuous design and continuous delivery in the same cycle to achieve full delivery. Because of the lack of a good name, we are called this article for the innovation cycle, the cycle of each phase is as follows:
Choose an idea
To refine the idea into a measurable hypothesis.
Choose the features you need to complete the idea
Develop and test these features
Develop and test those metrics to verify that the hypothesis is feasible
Publish ideas to a production environment
Measure the success or failure of the idea
Repeat this cycle.
Not surprisingly, supporting this approach requires the application to innovate in the following areas: metrics and analysis, infrastructure, testing, pilot design, continuous design, and support for continuous delivery processes and tools. In this article, we will describe the important innovations required to maintain this cycle. Each of the following topics can be written independently or read more, please use this questionnaire as a primer to motivate people to learn more about these topics.
Measurement and analysis
Metrics are risky, and they can be counterproductive and encourage bad behavior. However, the metric is one of the main aspects of the cycle described above. The concept of concrete content in software system is defined not only by the specific behavior of the software, but also by how to know the concept. We can refer to a specific example: some people in the marketing department think that if they change their online shopping process, their online turnover will increase by 20%. The idea of this example is to change the process, and the assumption of testability is that users who use the new process will have more than 20% of the previous process tend to buy. In this case, the metrics are simple, and we need to measure the purchase results of each process customer. We can randomly assign a user to a different process and then assess whether the process achieves its goal. To complete this metric, we want to make sure we record the usage and sales results of each process user. In the final stages of the test, we will know whether the marketing idea is good or bad.
Test Type Design
Sometimes, what is the right measure or what type of analysis is needed to assess the value of an idea is not obvious. For example, the idea of trying to improve productivity may be hard to measure. Providing feedback to system owners on the success of their ideas is critical to prioritizing new requirements and guiding system improvements.
The design of testability assumes an effective way to design a series of tests to verify that the new functionality delivers the expected results. Therefore, we determine the expected result of the new function and its impact on the system behavior. The key to the design test is to ensure that the real impact of the new function is measured. With the above example of changing the purchase process, it is more effective to measure and compare users to use the old and new processes than to view historical data unilaterally.
Evolving infrastructure
In order for the loop to execute effectively, it is partly a requirement to quickly adjust the system to try new ideas. In an ideal world, we can anticipate all the changes that the system might want. In reality, all changes are unpredictable. User expectations, business environment, competitor situations, rules and regulations are outside the purview of an organization. So whether or not the change is predictable, we need to be able to adapt. Evolving infrastructure and emergent design are the ways Agile software development takes to make unpredictable changes as simple and secure as possible.
Tests that support evolving infrastructure and emergent design will be covered in the next chapter. Emergent design focuses on maintaining code maintainability and cleanliness by identifying the refactoring opportunities created by the new features of the system. In contrast, evolving infrastructures focus on the architectural factors of the system, including technology selection and interface design between different architectural elements.
In this case, the goal of the evolving architecture includes the ability to independently develop different parts of the system, even if they need to interact with each other. We implement this by means of a reasonable encapsulation of functions, together with the impact of each system recorded in the contract test on the behavior of other systems. Providing such tests for each development team allows them to realize from the outset that incompatibilities will inevitably arise as the system develops. Another purpose of the evolving architecture is to target data modification, information modification, and the exchange of a component for other components.
Test
In the evolving Architecture section, we describe the test style that is important to support this change cycle. However, many other testing methods are critical to support the cycle. Thorough and effective unit testing is essential to support evolutionary design, and it also gives you more confidence in adding new features without affecting the current functionality. Similarly, a thorough regression test set provides the same protection at different levels of granularity.
A complete test strategy for the system involved in the innovation cycle ensures the normal use of the new functionality without affecting the old function. The test should include technical tests (pressure, environment, etc.) other than functional testing. Equally important, the ability to test this capability to measure support for the concept should also be included in the test strategy. To ensure that the cycle is carried out, automated testing is critical. Manual test loops are generally very long, and manual testing should focus on the core areas and be more exploratory in nature.