Shulou(Shulou.com)05/31 Report--

Shift Left Testing and software quality assurance thinking is what, I believe that many inexperienced people are helpless about this, this article summarizes the causes of the problem and solutions, through this article I hope you can solve this problem.

In agile development, teams need to be able to deliver consistently fast. So how do you guarantee product quality during continuous delivery? The answer may be automated testing.

But are automated tests adequate and effective, and even if adequate and effective, can they demonstrate good product quality? The test result is just an indicator, which represents only the running results of existing test cases in the current test environment, and is the lower limit of our guaranteed quality.

Software quality is not tested, but built up during development. Controlling quality during development helps to raise the upper limit of product quality.

Shift Left Testing is commonly understood as bringing forward testing that is located at the last stage of the traditional software development process. Which step was mentioned? Development? Design? Demand? My personal understanding is that the more forward the better. This means continuous testing throughout the development cycle and a constant focus on quality, all in order to raise the upper limit of quality.

What good would that do?

1. Reduce test and development costs and increase ROI(Return On Investment)

The earlier a problem is discovered throughout the software development process, the less expensive it is to fix it.

Imagine discovering a bug during the so-called integration testing phase, spending time deploying the test environment, preparing the test data, executing the test, reproducing the bug, communicating with the developer, and assigning the bug to the developer. He or she may need to redeploy the development environment, redevelop, redo the code review, and finally go through the test process again. How much time would it save if the bug could have been caught during code review or unit testing?

2. improve test efficiency

If bugs can be found and prevented at the requirements and design stages, a lot of iterations in the development life cycle can be saved. At the same time, testing can be carried out on the basis of understanding requirements and code, and business-oriented and risk-oriented testing can be more focused and targeted, without falling into test details, effectively improving test efficiency.

3. improve quality

Ensure and optimize the quality of requirements and requirements delivery at the requirements level, ensure the flexibility of design at the code level, keep the code clean, control the quality during the development process, and improve the internal quality of the product.

Shift Left Testing is something that needs to be followed by the entire agile development team as a whole. So in an agile development team, how does a QE work with the team throughout the product development lifecycle?

1. QE, as a member of an agile development team, can do anything that helps the team improve quality, without boundaries, in order to help the team identify problems, solve problems, and improve product delivery quality.

To be able to provide quality assurance without boundaries, QE needs to make two important changes:

(1)Improve your skills in all aspects

Without relevant skills, such as business competence and certain coding skills, it is difficult to imagine QE effectively participating in discussions at various development stages, let alone giving advice and opinions. Of course, this doesn't mean QE has to be a full-stack engineer. QE needs to find the balance of learning. Some skills may not be necessary, but if you have them, you will make QE do things in a more efficient way.

(2)Dive into all aspects of the software development life cycle and keep pace with the team's development rhythm

If you don't go deep into all aspects of development, the root cause of some quality problems can't be found, so there is no way to prevent bugs in advance. You can't go deep with your ears on. He needed to think and think from a quality perspective. However, if the skill gap was too great, it would be good if he could barely keep up with the rhythm. Therefore, each link in the software development cycle needs the support of QE's own skills.

At the same time, QE needs to grasp the balance in the process of participation, be able to find problems, and also need to enable each role of the team to perform their own responsibilities and maintain a healthy team working mode.

2. QE requires training teams so they have testing skills and a sense of quality and are able to solve problems themselves while continuously improving quality.

Product quality is guaranteed by agile development teams, and colleagues are often heard to say,"Our QE is quite strong, and many problems have been detected." In an agile development team, there is only one QE, relying on one person's heroism, testing so many problems, what if QE is on vacation? Can you trust the quality of your team?

QE's sense of accomplishment is not "how important I am and how many important bugs have been detected," but "without me, the team's output is still of high quality." To achieve this goal, the task of QE is to mine the quality requirements of the team, train the team, make QE more and more "redundant", and make the team a "de-QE" agile team.

These two points seem contradictory, but the first point (helping the team find the problem) is to support the second point (how to train the team to solve the problem itself). As the team matures, these two points slowly become less and less.

So is the higher the quality, the better? Quality comes at a price, and costs and outputs need to be controlled. As an example, Weinberg mentioned MiniCozy's word-processing software, when typesetting an entire book, made a word-missing error, and that error did happen on a writer's debut. But MiniCozy's response is that out of hundreds of thousands of users, there may not be ten people who would organize such a large-scale task into a single file, and correcting this error may take a lot of time and cost, and it may also lead to larger errors that affect hundreds or even thousands of users. MiniCozy thinks their trade-off is correct. So quality does not mean flawless, but relative.

Below I list the things QE can do in each part of the software development lifecycle, but QE does not necessarily need to participate, the purpose of participation is to find problems, and ultimately training is needed to enable the team to have the knowledge and thinking related to quality and testing, and to improve the process and behavior so that the team can ensure quality and continuous improvement.

Depending on the maturity and QE skills of each group, things may vary.

To simplify the diagram, only the things themselves are listed, and below are a brief explanation of the purpose of doing these things.

Before coding -Before development begins

1. Involve requirement discussion early

Before we do product development, we should understand the reasons behind the requirements, what problems the customer has, and what problems we can help the customer solve. We test not just product functionality, but business value. Participating in requirements discussions early on can be extremely helpful in determining the focus and priority of testing and avoiding getting bogged down in painstaking testing details. In this way, we can effectively use Pareto's 20/80 principle to improve testing efficiency.

2. Ask negative questions

Everyone can be influenced by inertia, and we can optimize functional and non-functional requirements testing by asking negative questions, such as product standards and GDPR(General Data Protection Regulation).

3. Collaborate with testable and executable acceptance criteria

Acceptance criteria focus primarily on business value, establish the functional scope of user stories, and guide development. By listing acceptance criteria through collaborative discussions among various roles, misunderstandings about the scope of requirements can be avoided, and everyone involved can clearly know what to test and how to test.

4. Work out test plan in sprint

Within each sprint of agile development, we also need to develop a test plan based on sprint goals, including which features need to be tested manually, which features need to be tested automatically, which features need regression testing, whether performance testing/safety testing needs to be done, etc. You also need to plan maintenance on previous tests. This test plan affects the breakdown of tasks and time estimates for sprint planning meetings.

5. Join estimation proactively

In sprint planning meetings, actively participate in task decomposition and time estimation, including development, maintenance and execution time of related tests, based on the developed test plan.

6. Design and prepare test points with good test data including automation test

These are actually the test-related expertise required by the traditional waterfall development model, and the same applies to agile development. Through the use of various methodologies, test points are designed to guide and optimize test execution and improve test efficiency. In agile development mode, QE requires that all members have this test design skill.

7. Define KPI/Dashboard

The team needs to define how to measure quality. KPI(Key Performance Indicator) measurement value can directly feed back the external quality of the team, and can help the team understand and solve problems through root cause analysis.

During coding -during development

1. Join or familiar with design

Although agile development patterns do not have a dedicated software design phase like waterfall development patterns, small function point designs do exist at each sprint. Different designs have different test considerations, such as triggering the order process through events or triggering the order process through background operations. The points to be verified by the test must be different. If background job mode is adopted, it is also necessary to verify whether the job information and scheduled execution time are correct, etc.

We also need to consider testability in design. Software testability refers to the ability of software to find faults, isolate and locate faults, and the ability to design and execute tests under certain time and cost. James Bach describes testability this way: Software testability is how easily a computer program can be tested.

For example, in order to test the methods of a class, we first need to create an instance of the class, referencing the necessary internal dependencies, and isolating the external dependencies. In some scenarios, this is not so simple, because developers tend to limit themselves to considering the specific technical implementation of the function they are responsible for and ignore the testability of the design, and QE participation in functional design can increase developers 'awareness of ensuring the testability of their design.

2. Guide/coach/pair to develop testable code and effective test code

Testable code is a prerequisite for writing test code. The role of test code is not only to meet the test coverage, test code needs to test the software function based on test design and test data, so QE needs to work with developers to ensure the effectiveness of test code. Once a bug is found, in addition to fixing the bug itself, it is also necessary to evaluate whether existing test code needs to be improved to cover the bug.

3. Go through code for both functional code and testing code

Checking code from a QE perspective, such as whether requirements match, whether SAP product standards are considered, etc., from this perspective can help find problems and improve test efficiency. For example, if the code adds a new method to get the current time, is the time and format localized? Is this new method called? If none of them match, do you still need to continue functional testing? There is of course no need for functional testing until these defects are remedied. Later we will trace why this happened.

4. Safeguard DoD compliance

Because we are building a product, a user story is only complete if it meets the DoD(Definition of Done). We have to be strict so we can keep delivering and avoid technical debt.

5. Utilize continuous integration environments

By integrating various code scanning tools, continuous integration is used to discover problems and provide rapid feedback on quality.

6. Test an uncompleted user story

Usually a user story is neither too big nor too small, and QE still needs to test the user story when the team is not mature enough. In order not to have a test "surprise" at the end of the sprint and a large number of test tasks, we can discuss with the development to discuss which parts of the function can be developed first. After this part of the functionality is developed, you can start testing, even if the user story is not yet complete.

7. Provide fast feedback

In addition to continuous integration, QE needs to provide timely and rapid feedback on development bugs because developers are familiar with the business and code and can solve problems relatively quickly. On the other hand, this can also be considered as part of on-job training on how to improve quality.

After coding -after development

1. Test user story based on business value and risk

In the case that the team is not mature enough, QE also needs to test the user story based on business value and risk, and the granularity and scope of the test can be adjusted according to the specific situation of the team.

2. Hold another bug hunt or other manual exploratory testing session

Based on the KPI, importance, and risk level of the user story, we need to decide if we need another round of testing.

3. As problem solver to analyze issue and find how to resolve issue

QE finds bugs and reports them to developers. Is QE's mission complete? QE can analyze problems through phenomena, logs, etc., locate problems, and improve the efficiency of problem solving.

4. Reflect AC/DoD/Test plan/test case/test data

After reading the above content, do you have a grasp of Shift Left Testing and software quality assurance thinking? If you still want to learn more skills or want to know more related content, welcome to pay attention to the industry information channel, thank you for reading!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.