Introduction: why write
Ah Sei's industry life is not long, but it also has its own plans. In this diversified technological era, Ah Sei knows that personal technical ability is very weak. The management mode also understood and experienced the corresponding pain points according to the communication, so I made corresponding learning supplements. In this general description, I just talk about my personal experience, and also use this to communicate with you. If there is any mistake, please correct me, I am willing to Accept and learn.
Write at the top:
In various companies or positions, there are three kinds of people: following the rules, seeing the rules, and building the rules
Most people are in compliance with the rules , that is, executives, regardless of development, testing and other positions, are familiar with, adapt to and execute according to the current management system;
A small number of people have seen various rules , which depends on the scale of different companies. The reason why most companies like talents with big factory backgrounds is that they have seen a perfect system, fast learning ability, and high quality of personnel;
In the end, very few people are building the rules . Of course, those who build the rules must have a premise - they have seen the rules;
Every company has its own system and process. The copy and paste is not completely able to run. There will be various problems in the middle, which will eventually lead to fault problems. To run better, let's start with this article to understand why system construction is important.
1. Common R&D management system construction
Let's first understand what common management systems are and what we need to do in them.
1. Based on CMMI
CMMI system practice is actually more suitable for project development and product development mode dominated by waterfall development
It has two representation methods: staged, continuous
The difference between the two representations is:
Staged : Several process areas in CMMI are divided into 5 maturity levels, and organizations that help implement CMMI suggest a process improvement development path that is easier to achieve (as shown in the figure below)
Continuous : The 22 process areas in CMMI are divided into four categories for coverage: process management, project management, engineering, and support . For the process areas within each broad category, they are further divided into basic and advanced (as shown below)
In this way, when implementing CMMI in accordance with the continuous representation method, an organization can always best practice project management or some other kind of practice , and other aspects of the process area can be completely ignored.
CMMI is expressed in different ways, but its essence is exactly the same. It is two different ways of expressing the same method. No matter what kind of evaluation an enterprise needs to do, the benefits obtained by the enterprise should be little different. The specific requirements for continuous evaluation or staged evaluation depend on the specific requirements of the enterprise for the grade evaluation certificate.
Ah Sei's company is certified by CMMI4, but in actual work, we do not fully follow CMM4. It is actually very difficult to fully implement the CMMI certification, so most of them have adopted bidding qualifications, which is beneficial for extra points . To B companies are actually more suitable.
In the system management model of CMMI , Ah Sei participated in the system construction of the quality control part of the work and the testing process specification:
In terms of quality , it includes: product quality design management , test specification process construction and improvement , quality control and implementation
From the test , it includes: the beginning , the process and the end of the waterfall
Combined with quality control and weight shift in the testing department : a better way to say is that the testing department is completely independent and responsible for software quality (SQA department pays more attention to the process), the testing work is more specific, and the testing process is more stringent, I published in the previous article After a full-flow explanation of the test (if you are interested, you can click to see: a picture to understand the whole process of the test_ah Sei's blog-CSDN blog ), he more fully explained the requirements of the beginning, process and end of the test system, The input and output are specified more specifically, and the proportion of the rights of the testing department is also divided into essence, (the relevant specification documents will be summarized and released later), the key point of the whole diagram is to distinguish between steps and carry out Control, analyze the results, and emphasize standardization and practicality in each step to emphasize the end of the product or project.
This may not be detailed enough, so let's take a look at the relationship between SQA and testing :
SQA : SQA is not the same as QA. Its activities are mainly in the process area, that is, process management and improvement (QA is defined from the ISO9000 family, and QA is the key link of SQA). The establishment of SQA is necessary, but not suitable Yes, for three reasons :
1) SQA is born out of the software service industry, and its main function is to control the software development process and quality according to CMMI . Most of the processes are terminated after the project is delivered, and they know nothing about product operation and maintenance and services ;
2) Internet companies are more product-service-oriented, with product R&D and operation being the core , and it can even be said that they focus more on operation, because revenue basically comes from product operation, and product R&D needs to be more agile and faster. Iteratively responds, and CMMI's overly strict control will lead to certain delays and losses (willing to sacrifice 50% of the possible risks of efficiency preservation, SQA is reasonable);
3) Now the product research and development within Internet companies is also tending to the project system , rather than the earlier departmental operation with a relatively large gap. The establishment of SQA is equivalent to extracting and independent of the supervisory functions within the department, and doing overall control , which can reduce the considerable management burden of product managers and technical managers, because their professional management capabilities in this area are still quite lacking.
The direction of the above questions---- SQA needs to be pragmatic and practical under the big topic of quality assurance, otherwise it will be empty talk . And Sei's point of view is that quality assurance needs people to do it, but who does it varies from team to team, so in addition to the boss, the head of the development department, there are also the following project managers, engineers, etc. , otherwise it will be difficult to implement, and will be hostile and marginalized.
Through the above understanding, we can't help but think of one thing - what is the relationship between SQA and testing ? You can see the corresponding instructions in Ah Sei's previous articles: SQA in CMM/CMMI---what is it, and how is it related to testing - Ah Sei's blog - CSDN Blog
In layman's terms, CMMI is a set of guidelines, a general way of doing things, and a frame of reference for improving quality. We refer to the methods it provides to achieve the purpose of improving software quality by controlling our project management process.
2. Based on agile
There are many predecessors who have experienced the CMM tide in 2000. The various situations that gradually emerged after the tide have to make us look at agile. Now most companies (foreign enterprises, start-ups, and small and medium-sized companies) are moving towards agile mode. The core of agile mode is people-oriented. , embrace change , under this core, every company in this model has begun to blossom (there is no doubt that agile has achieved great success, but the word agile has also become a joke for a small number of people/companies --- small workshop the last fig leaf)
The agile model is really a love-hate relationship. Most of the project work Sei participates in is actually using the agile model, but the agile model is not fixed. It can be said that every project team has its own A set of agile methods, a variety of methods have caused a hundred flowers to bloom, so let's not talk about nonsense, so let's first understand what agile is:
Summary from successes and failures---------Agile is the way, not the end.
Agile is a research and development management system implemented by many Internet companies and small and medium-sized enterprises. Agile software development methods have achieved great success in practical practice and are favored by countless software development enthusiasts and software industry managers.
The main concepts are agile iteration, small steps, rapid improvement, embracing changes, user participation , etc. It is a human-centered, iterative, and step-by-step development method. The core values of the Agile Manifesto are : " Individuals and interactions are better than processes and tools; working software is better than detailed documentation; customer collaboration is better than contract negotiation; responding to change is better than following a plan "
Software project management in agile mode can readily face changes, accept changes, and welcome changes. The purpose of agile is to make the software development process a process of constantly adapting to changes, and even to control and adapt to changes by changing itself. Therefore, On the other hand, the principles of agile software development are not universal. Its development philosophy is only suitable for short-cycle iterations, lightweight products and projects, and organizations and teams that dare to embrace change and value customer value.
However, agile development method is not a specific development method or development process, it is a general term for a set of lightweight development methods, each of which includes different specific development processes:
(1) Extreme programming : Extreme programming is one of the fastest software development methods. The team fully communicates with on-site customers and obtains quick feedback through continuous testing methods and special planning methods to maximize the value of the team;
(2) Agile modeling : Agile modeling describes a modeling style. In an agile environment, it can effectively improve the development speed and product quality, while it can avoid excessive simplification in design and unrealistic expectations of requirements;
(3) Adaptive software development : Adaptive development replaces the traditional waterfall model with a series of cyclical assumptions, cooperation and learning cycles. This dynamic cycle provides programs in emergencies with the ability to continuously learn and adapt. Characteristics of adaptive software development methods include task-focused, feature-based, iterative, time-windowed, risk-driven, and welcoming of change;
(4) Crystal method : The crystal method strives to balance production efficiency and ease of use by reducing discipline constraints. In short, although the crystal method is not as efficient as extreme programming, it is easier to implement;
(5) Feature-driven development : Feature-driven development is a model-driven, short-term traversal process. It does not have the lengthy design process in traditional engineering, but iteratively improves through the form of design and development, so it is very suitable for rapid development of small projects.
(6) Test-driven development : Test-driven development emphasizes that the realization of any function originates from testing, the test code is the technical embodiment of the real business requirements, and the developers write the realization of the function according to the test code.
(7) Scrum : The Scrum method includes a series of specific practices and predefined roles. The Scrum method adopts an iterative method to develop step by step. It is the most widely used and the most effective one in a series of agile development methods. In the article of ah Sei, the Scrum method is introduced in detail according to the example.
Although the specific names, processes, and philosophies of these agile methods vary, they all aim to deliver high-quality software products quickly to meet customer needs.
We have a general understanding of the concept of agile, let's take a look at the value and development of agile testers:
In the agile mode, the test work is also agile, but the work content is scattered. The 2-4 week iteration cycle shortens the test work time, so you don't need to write a lot of documents, then this Then you have two options:
(1) Top-to-bottom: generate a one-page test plan, refine test points, and write test cases. The granularity of this test case will be very large, so more exploratory tests will be used when the top-down process is carried out.
(2) Bottom-up: Refining test points, writing more detailed test cases to cover, and writing test plans based on these test cases, this method is actually more quality assurance, but it is undoubtedly a challenge for periodic work
Agile functional testing = manual testing of new features + automated testing of existing features
It is undoubtedly difficult to adopt automation and performance testing in agile, and it is difficult to ensure the successful implementation of these testing methods with rapid iteration. The project adopts agile methods. To be successful, everyone in the project team has a strong sense of quality and has a quality ownership, especially the developers, reminding themselves every moment - "quality is built", and Customers or product designers communicate well and adhere to highly consistent quality standards.
Agile testing is to continuously revise quality indicators, correctly establish test strategies, confirm that the effective requirements of customers are satisfactorily realized and ensure the safe and timely release of final products throughout the software development process. Therefore, agile testers need to pay attention to product requirements in activities. Product design, interpretation of source code; while completing various test plans and test execution independently, agile testers need to participate in almost all team discussions and team decisions. At the same time, he also pointed out that as an excellent agile tester, he also needs to complete more test preparation and execution within a limited time, and has a strong sense of responsibility and leadership. More importantly, good testers need to be able to expand to do more work that may not be related to testing, but is directly related to the team's shared goals.
He will help other members of the team to solve problems, help achieve their desired goals, and promote a high level of collaboration to help the team's ultimate success. It should be pointed out that a high degree of team collaboration requires not only the courage of team members, but also the active cooperation and help of team members.
Second, according to the two common test team models to explain their advantages and disadvantages:
1. Independent testing team - this is the team that is famous for fighting with development.
• benefit
An independent team can still guarantee a certain degree of "fairness". For example, at the end of the test, someone can not submit to the requirements of the program team to conceal the product quality, but will indeed evaluate the quality objectively.
• There are often several misunderstandings:
1) The program team is used to develop functions, and the test team is used to find defects . With this familiarity, it is not difficult for the two to fight.
2), more testers = higher quality
Many companies have an amazing ratio of testers, and the program and test can basically reach 1:1, which is close to the level of building the space shuttle, but the program team does not care much about the quality, because someone is responsible for the test later, and there are bugs leaked. You still have to take responsibility for it, so you just write code according to your own interests, and more and more defects are left, and naturally more testers are needed to solve them.
2. Decentralized test team
• benefit
Each team has testers, and natural testing activities will be treated as a matter of home, and there is an opportunity to start testing activities at an early stage; since there are no follow-up testing activities, and no one can argue, so the group The effect of the test activities within the system will be better.
• The disadvantages are often the following misunderstandings:
1) Personnel cannot be shared, and there are insufficient testers
The basic starting point is that these testers are here to help solve the defect problem, so they are very likely to become local garbage pickers. Since you can only call your own testers, of course, gradually a few people are not enough, and more testers are needed.
2) Lack of gatekeepers for overall quality
Since all testers are regarded as the quality-responsible people of the group, when all the modules of the product are finally integrated, who is responsible for the quality becomes a problem; how to verify the overall business (not technology) after integration is also a problem question.
Through the above understanding, we have already made a certain comparison, so let's discuss the quality and ability of agile testers
- Defining Quality: This should be the basic responsibility of a software tester. Agile methods encourage testers to communicate directly with customers during sprint planning, and from their own experience, jointly develop quality requirements for product features.
- Communication Deficiencies: Agile processes emphasize communication within the team. Developers often focus on important and novel features, and testers should grasp the details and look for "missing doors" in the design; in addition, developers use unit testing to ensure the basic quality of the product, and testers can use Acceptance testing. Test) to identify inconsistencies between customer requirements and actual results.
- Timely feedback: Agile processes emphasize simplicity and efficiency. Testers need to timely feedback the current quality problems of the product. That way, the team can get to work right away. Whereas the traditional process is to summarize status once a week, an agile process requires a daily summary of quality issues. In our project, the internal test report will be displayed on the internal site as a web page. Every team member can get it at any time. In addition, our testing framework provides --- self-service testing: by clicking on a specific use case in the test case list, the developer can reproduce the defect without interrupting the work of the tester.
3. So what is the difference between agile and traditional testing? We can sort it out according to the following list:
In general, there are three things to pay attention to in agile testing:
1) Clear acceptance requirements: When product requirements are clarified and refined into projects, the acceptance requirements of each user story should be clarified.
2) Track and deal with defects: break it into pieces, access as soon as possible, and carry out unit testing and interface testing according to testing requirements. (with code reading and detection ability)
3) , timely communication and feedback: strengthen communication and timely feedback.
3. Several misunderstandings about agile
Here is an explanation based on personal experience and access to relevant materials, thanks to the papers and articles of Feixiang Xiong , Xu Kang, and Wu Gang for reference:
Myth 1: Agile is very demanding of people
Agile has really high requirements for team members, but it is not a ceiling or even outrageous. More and more companies have been saying that we want to optimize the current model, but the capabilities of team members cannot reach a high level. What should we do? In some companies, there is a model of one person with multiple positions, to comprehensively exercise the comprehensive ability - you are still the test manager in the previous project, and the next project becomes the demand. This does exercise your breadth of knowledge, but it is broad but not precise;
Dedicated people to do special tasks, and specific positions to specific responsibilities. The high requirements of agile personnel are not reflected in breadth, but in precision. To quote Mr. Xiong from Flying: Aside from technology, who will find the project development clearly Is it easy for developers (including designers) who know the work content, scope of responsibility, output of each project member, and know the project goals, requirements, and user needs?
Myth #2: Agile doesn’t need documentation and doesn’t do design
This misunderstanding has not stopped since XP, which encourages "no documentation unless it is necessary and significant"
Ah, the most common sentence Sei hears is: "Programs are bigger than documents, why do I write documents?", I am very curious, product projects that lasted for many years and only a few months did not have any content other than prototype drawings. ? ! Whether the document is written or not may have nothing to do with agile development. Agile development emphasizes "adaptability rather than predictability" and does not have any hard and fast rules. But there is also a sentence "available software is more important than detailed documents", what does that mean? It tells you that the document is not not written, but the form of the document is different. From demand analysis, business modeling, technical architecture design, to boilerplate code, there is a need for output, and key role people are always involved in decision-making, acceptance, and feedback.
As long as it is convenient to consult the design data, the organizational form and scope are determined according to the value. It is just that how to use the software normally is the most important, not the document type because it is less important than the software. It is necessary to organize the document class, but the form is selected according to the input-output ratio of the team.
Myth 3: Agile is good, other methods are bad
Some people shout good when they mention agile, as long as it is agile practice, everything is good, but when it comes to methods such as CMMI, they shout badly, no matter what it is, as long as it is attached to it, it is not good anywhere. It seems that agile and other methods are not good. is completely opposite. Agile also draws on the advantages of other methodologies. Agile still maintains many time-honored practices and principles. Choosing a method or process is not based on whether it is agile, but on whether it is suitable. And to know if something is suitable, you have to try it before you know it, anything that has not been tested in practice is not credible
Here you can take a look at Xu Kang and Mr. Wu Gang's papers and journals "Research on Software Project Management Method under Agile Mode", "Research on Improvement Method of Software Quality Management Process Based on Agile Mode", "Agile Manifesto" has passed since its publication in 2001. For more than 20 years, in this era of diversification, various models are being improved and optimized. Those who are interested can check in the journal to find a more suitable direction for their own improvement.
4. Understand the problems and roles of test management
1. Let's take a look at the work of test management first.
1), the establishment and improvement of the test workflow; the relevant company system involving the department;
2) The judgment and resource allocation of the test project, the allocation of resources, including human resources and some software and hardware resources;
3) If the company does not have a separate quality management team, then the relative test manager needs to play the role of QA;
4), the last and more important point is to be responsible for the management coordination and communication with various departments;
2. Difficult to build test system
Software testing is an industry that has emerged in China in recent years. The ISO9000 family, CMM and other systems have also clarified the necessity of software quality management in the engineering team. The software test level also includes the intermediate title of the evaluator. All situations reflect the professionalism of the testing industry. sex and importance.
However, there is still a big gap between Chinese software companies and international standards in software testing, and each company has its own opinion :
1), in terms of understanding, focusing on development and ignoring testing, not realizing that the completion of software projects on schedule depends not only on developers, but also on testers;
2) The management is random and simple, and an effective and standardized software testing management system has not been established;
3), lack of the support of automation tools, most companies do not use software test management systems in software testing. Therefore, for domestic software companies, it is necessary not only to improve the understanding of software testing, but also to establish a sound software testing management system to make software testing standardized.
3. Problems to be solved in test management
1), the test correlation is complex
The increasing scale, high concentration, complex architecture, and enhanced coupling of the system make the business and technical complexity higher and higher, the test design and implementation are difficult, and the pressure on system quality assurance continues to increase.
2), the test cycle is getting shorter and shorter
The period from business requirement presentation to implementation is getting shorter and shorter, and the time reserved for testing is getting shorter and shorter. In the face of complex system testing, how to compress the test cycle and improve the test efficiency has higher and higher requirements on the management ability and implementation efficiency of the test department.
3) Difficulty in test organization and coordination
The growing scale of testing and the stronger correlation make testing organization and coordination difficult, especially after the introduction of testing outsourcing, how to effectively manage and control, and maintain "big but not chaotic" to promote the testing process efficiently and with high quality , to ensure that the test project was successful.
4), testers have a low sense of achievement
The testers are temporarily transferred, the team is temporarily formed, there is no sense of belonging and the sense of achievement is poor; the test team is under great pressure, busy all day but with poor results.
5) It is difficult to unify the test quality standards
Different departments and roles have inconsistent understanding of test standards, and different operational procedures and methods are used. The quality of test delivery is unstable, and the risk of test delivery is still uncontrollable.
4. According to the role of quality control test management
1) Quality Guard : Responsible for the quality of the overall software system, this is the basic role of the tester. But the quality is not only free of bugs, but also includes a good user experience, system stability, good performance, etc.
2) Process facilitator : A strong enterprise or team must have a process formed through experience and continuous optimization. The same construction of a good software system also needs to have an efficient process as a guarantee. Software quality assurance work runs through every link in the overall software life cycle. Therefore, testers take on the role of building and promoting efficient processes.
3) Quality culture evangelist : Quality is a matter for testers, but it is not enough for testers to pay attention to quality. An excellent product requires the participants at each stage to be responsible for its quality, which requires testers to shoulder this role, spread the concept of quality to each participant in the project, and make the quality culture in-depth product, development, Testing makes everyone have a sense of "quality" and work together to build high-quality software products.
----------------------
This article is the beginning of a general understanding. In the follow-up articles, Sei will discuss with you from the perspective of a test manager, the working experience of CMM and agile mode, and the articles and other articles are cited in the article. If there are any intellectual property issues involved, please contact me and it will be dealt with immediately.
Future articles will be gradually synchronized to the personal public account, welcome to support Sei~Thank you~
