Quality Management Under the Agile Development Model

A few days ago, I talked with a friend engaged in quality assurance at an Internet company. As the person in charge of Internet product quality and testing, he recently encountered many difficulties in quality management. It mainly includes:

• The value of test teams in an agile development model is very limited；
• Developers only write their code without any documentation, and testers have no way to start；
• Testers have very limited time to test due to the progress, and many problems appear after going online；
• The turnover rate is very high because the development team does not recognize testers；
• The quality department cannot collect data and conduct quality measurements；
• The test team also has a group of automated test experts, but it is not useful...

Many development teams may encounter these problems. To sum up, they are mainly in the following aspects：

• More and more companies want to adopt quality management. However, they are not sure if it is available；
• Accustomed to the traditional waterfall product development process no longer meets the needs of rapid development, but large-scale changes are not realistic；
• Lack of agile software development experts and talents；
• Technical personnel need to change their mindset and develop methods；
• Lack of appropriate quality control methods；
• Development teams need frequent and timely quality metrics, testing, and decision-making；
• Automated testing is not implemented, and daily builds are still paper-talking.

In the current industry, the demand changes too fast. No matter how hard we try to do it, we still cannot meet customers' needs. No matter how detailed we make the requirements, there are always problems like this when delivering products to customers. At this time, we have to modify our software. This is a challenge faced by many enterprises, especially Internet companies. So how to solve this problem?

I have worked in the software quality department of Huawei and Alibaba successively. Recently, I studied some materials on Tencent's agile development platform TAPD (Tencent Agile Product Development) and IGD (Integrated Game Development). I have many unique insights into the quality management of agile projects. Combined with the company's many years of project experience, and the summary is as follows:

1. Change of QA Role

QA needs to change from the role of a police officer to the role of a coach. In the past, when the team implemented CMM, QA was more of a police officer. He went around the team with a checklist and reported all day to see if you were okay and what you should do if you weren't okay. He spent all day doing this work. But after the introduction of agile, QA felt a little lost. For agile, I even don't know how to start.

Image Source: Logo wine

In the famous communication enterprise, Huawei's approach is to change the QA, and QA will act more as a coach and Scrum Master. He guides the project team on how to hold this standing meeting, how to do iterative planning, and other guiding work so that QA also feels good and can participate in different teams. The role of QA is more inclined to guide agile activities in the whole process to improve the efficiency and quality of product development. QA can also get some data in this process, such as code defect rate, version defect rate, number of online legacy issues, team member cooperation, etc.

2. Ensure Full Participation of Agile Teams

QA and testers are also part of the Agile team. As an agile coach, QA should provide support and training to the test team to adapt to the fast pace of development. For example, if you are a tester in an agile team, and you are not invited to the planning meeting and design discussion, or the business user is independently defining stories and requirements, you should take the initiative to communicate with other members of the team and try "three-part cooperation," that is, testers, developers and business experts.

Image Source: Wikimedia

Tencent calls business experts BA, namely Bussiness Analyst. BA, developer DE and tester TE form an agile development team. These members are not only busy with the final delivery, but also willing to collect and share information, cooperate with customers or product leaders to help them fully display their needs to get the functions they need, and provide feedback on project progress to everyone.

3. Automated Regression Testing

Will agile teams succeed without automation?

Image Source: Perfecto

It may also succeed, but the successful teams we know all rely on automated regression testing, such as the Selenium framework at Tencent and Alipay and the QTP framework at Alibaba and Taobao. According to Higet Consulting Company, agile development uses tests to guide development and to write code that tests pass, and tests need to be run quickly and easily. Without a short-term feedback cycle and safe regression test, the team will soon fall into technical debt, defects will increase, and the speed will become slower and slower.

4. Provide and Get Feedback

Feedback is the core value of Agile. Agile short iterations can provide continuous feedback to help the team function properly. The testers help provide support in the form of automated test results, the discovery of exploratory tests, and observation results of actual system users. Such as:

• How do you know that the customer has the correct example of expected behavior?
• How do you know that the test cases you write correctly reflect these examples?
• Can developers understand what code should be written by viewing test cases?

QA and testers should ask whether developers have received enough information to understand requirements and guide coding and whether customers understand quality standards. They should spend time in iteration planning meetings and review meetings to discuss these issues and propose improvement plans.

5. Construct Core Agile Practice

There is jargon in the software industry that software quality is designed. The same is true for agile development. Without some basic practical activities, high-quality software cannot be produced.

1）Continuous Integration

Continuous integration (CI) is a software development practice in which team members frequently integrate their work, usually at least once a day per person. Each integration is completed through automated builds. Continuous integration allows defects to be discovered and resolved the day they are introduced, reducing defect modification costs; spreading integration efforts over peacetime. They can avoid many problems when the product is finally integrated by generating deployable software daily.

2）Gray Release

Gray Release is a characteristic of Internet products, simply, it is a process of gradual release to users, and the team is not required to release the product package as early as possible; that is, the team is not required to release it to all users immediately but will be released in batches, such as by number or first experience within the company.

There are also strategies for the release, such as how to release the volume, what kind of experiments for users, how to do some back-end switches technically, how to follow up operationally, how to ensure 4 hours of staff stay, how to collect user feedback after the release, etc. There are some unified rules. For example, multiple versions can be simultaneous if a WEB product is released in a lab. The 1.1 version may have 100% of users using it, and the 1.2 version may have only 1% of users using it. They are a cross-upgrade process, and Tencent currently adopts the activity.

3）Daily Meeting

Each team will spend about 15-30 minutes every day reviewing what they did yesterday, what problems they had yesterday, and what they planned to do today (feature: standing meeting). When I worked at Alibaba, I experienced daily morning meetings. Generally, members of the Agile team take turns as moderators. At this time, I can understand the problems that occur every day.

4）Pair Programming

Two programmers work in front of a computer. One is responsible for typing code, and the other checks each line of code in real-time; The programmer who operates the keyboard and mouse is called the "driver," and the programmer who is responsible for real-time review and assistance is called the "navigator"; During the inspection, the navigator must also be responsible for considering the next work direction, such as possible problems and improvements.

Image Source: ZenTao

Pair programming helps improve code design quality; Research shows that the productivity of pair programming is 15% lower than the sum of two individuals, but the number of defects is 15% less. Considering that the workload and time for defect modification are several times larger than the initial programming, the overall efficiency of pair programming is higher. At the same time, pair programming can greatly promote the team's ability and knowledge dissemination.

5）User Stories

User stories are a way to describe requirements from the user's point of view; each user story must have a corresponding acceptance test case; user stories are hierarchical and graded and are gradually broken down and refined during use; a typical description sentence is: as a XXX customer role, I need XXX features that bring XXX benefits.

The benefits of user stories are:

• User stories are easy to communicate with customers from their point of view and accurately describe their requirements；
• User stories can be delivered as independent units and are small in scale, which makes them suitable for iterative development to obtain quick feedback from users；
• User stories emphasize the preparation of acceptance test cases as acceptance criteria, enabling demand analysts to accurately grasp the requirements and leading developers to avoid excessive design.

6）Iteration Retrospective Meeting

The iteration retrospective meeting is held at the end of each iteration to share good experiences and identify improvement points to facilitate the team's continuous progress.

The iteration retrospective meeting revolves around the following three questions:

• What did we do well in this iteration?
• What can we do better in this iteration?
• What are the areas we will improve in the next iteration?

The meeting should be attended by all the team members, with a relaxed and free atmosphere to brainstorm and find problems and analyze the root causes together; the meeting should focus on the priorities of the team and focus on the most needed areas (focusing on a few improvements is enough); the meeting conclusions should be tracked and closed loop.

Each project needs to be supported by practical activities, but this is not fixed. For example, some teams have fewer resources and cannot yet pair programming, or some projects have short grogram cycles and do not need daily builds, etc. The agile development team decides on these activities after a meeting. Before the project kickoff meeting, everyone sits down together, settles on the hands-on activities needed, puts them into action, and then retrospects them.

At the end

Image Source: Triad

In short, testing and quality are the responsibility of the entire agile team. Everyone in the team should focus on a task or story at hand. Quality management under the agile model is more challenging compared with the traditional waterfall model, and it has obvious advantages in responding to changes in demand, improving product quality, speeding up demand response, shortening delivery cycles, exposing risks in advance, motivating employees promptly, and balancing the use of human resources. The focus of agile is to deliver valuable software until customers are satisfied. In this era of "fast fish eats slow fish", if you want to deliver good and fast products, you can try to use the agile model.