当前位置:网站首页>How to improve development quality

How to improve development quality

2022-07-04 18:17:00 Uncle Guo

   When I was young, I went to a relatively high-end management position compared with mine at that time , At that time, my situation was , Relatively rich development experience , But management experience is still lacking . The other party was faced with a specific problem . 

  “ We have recently produced , There was a serious accident , When we come back to the table , Development spray test , Test spray development , They all think it's the other party's problem . Do you have any experience in solving and dealing with similar situations . How to improve software quality ”

   At that time, my answer to this question was relatively thin , Just say , Everyone should unite and cooperate , Development should strengthen self-test , The test should be considered comprehensively , A sense of responsibility . That's right , But only strategy, no tactics , There is no practical experience . Final , Obviously, the other party is not very satisfied , Missed this position .

   Now I am no longer the boy I used to be , Although those who miss have already missed , But the problem persists , It is said that people are at different stages , For the same question , There will be different answers , So uncle Guo answered again here ……

 

   

   Specifically, this matter , It is suggested to deal with it from three levels .  

  

   One 、 Take the matter on its merits

   This layer is relatively simple , Specific problems should be analyzed , To understand the cause of this problem , The type of attribution , Then we can clarify the responsibility . Let all production be consistent Bug It is unscientific to carry the pot by testing .

  • If the need is clear , Positive use cases should cover , Not detected , That obviously belongs to the full responsibility of the test . Further investigation is needed , Who wrote the use cases of this part , Is it missing , Has it been implemented , Why did you not detect .
  • If it belongs to some special data , Triggered under special process bug, We can't think it's all about testing , Development also needs to undertake some . You can analyze the code in detail , Whether it belongs to the kind that developers are easy to realize and “ Deliberately ignore ” The problem of . Students with rich practical development experience must be easy to understand , There are some bug yes , Development is easy and should be thought of , And the test is difficult to detect . for example “ Concurrent inventory reduction ” This kind of problem , It's difficult to detect only through functional testing , When developing the design , It should be considered .
  • There may also be development , The tests are all innocent , Need to carry the pot , What you make doesn't meet the actual needs of users . Or demand , Test the situation of carrying the pot together , The demand adjustment needs to be modified together , No adjustment , The test did not return to . For example, only new input verification is considered , The verification of editing existing data is not considered .

  

   Two 、 The lines

   The purpose of the second round is , It should not be mainly for accountability . But to optimize the process . After finding out the cause of what happened , Corresponding processes should be established , Mechanism , Avoid similar things happening again . for example , The execution of use cases should be traceable , Insufficient test and development capability , To train , Corresponding operation specifications should be prepared , Lack of review process to join the review .

 

   3、 ... and 、 To arrange as a whole

   If the company feels that this has exposed the inadequacy of software quality , Expect to improve the development quality , Then understand , Software quality control and software testing , It's actually a matter of different scope . The scope of quality improvement is much larger than software testing , This should be publicized and implemented in the team , Unified understanding .

   Improving software quality is not equal to improving test quality , Quality control is an activity throughout the development process , It requires the participation of all the roles of the team , Be jointly responsible for delivery quality .

  

 

   1、 product , The quality responsibility of the demander

  

       One responsibility that is easy to think of is —— Can't misunderstand the original needs of users , Otherwise, it will lead the whole team to the opposite direction , But this is actually just a basic requirement .

   In addition, another important responsibility is —— Communicate clearly , That is, demand comprehensive , accuracy Communicate to users .

  “ accuracy ” It can be understood as describing your requirements clearly , Well organized , Avoid ambiguity . There are many in practice bug The birth of , It's because developers have missed some detailed requirements . This kind of bug The situation of , Usually, the functions are more detailed , For example, check some details , The text of the tip , Small differences with similar functions . This kind of problem can be solved in the form of requirement writing , Use List them one by one , Focus on The way is better than writing all the requirements into a lump of words , Reduce the occurrence rate . The occurrence of ambiguity , Mostly because the language description is not rigorous , Not specifically caused , Can be conscious Use more logical descriptions , The proportion of practice is not high , Just pay proper attention to .

  “ comprehensive ” In fact, it is a very difficult requirement , The personnel in need should have high quality . Caused by such problems bug After many years of operation and maintenance , There are many exposures on the system of continuous iteration . In the abstract, it's Modified a function , Modify other functions in the system that depend on this function . For old systems , It's very difficult to be considerate . Simple examples are , To enhance account security , Increased the length of the registered user name , Special symbols are also allowed . People in need should think , The user name input box verification rules that affect the user registration page are modified here , It also needs to be modified , User name input rules of user login page , If there are other clients, such as mobile terminals , It also needs to be modified synchronously , If there is user management in the background , Search for , The user name search box allows you to enter content that may also need to be modified synchronously . Even demanding UI Interface , Because the length changes , May result in abnormal display , Also consider .

   And product architecture , Is a higher level requirement , Ask the demander to know the function of the product , Entity , Concept , Do the right abstraction , And have a certain forward-looking . Product architecture is actually the foundation of technical architecture , If the product does not have a framework for requirements , The technical framework cannot be properly proposed , Improvisation will become routine , Modification costs will increase , Stability will deteriorate .   

 

   2、 Developer

  

  ·    Developers mainly want Emphasize self-test , Be responsible for your own deliverables . In practice , Developers often say , We are not testing , We all tested what to test . Therefore, it does involve a problem of degree . One of the most basic requirements in practice is , Positive use cases corresponding to requirements should be self tested , Generally speaking, the function development self-test explicitly mentioned in the requirements should cover . for example “ New users , Click on the user name , Able to display user details ", Developers should at least ensure self-test , Add a new user , Click on its user name , Show details of this process . If there is no problem, it is passed . And testers have to think more . For example, editing users , Whether the imported user can display normally ? With special boundary input , If the optional items are not filled , Is the display normal .

   The situation is often not so simple , Modern systems usually have a detailed division of labor , A function is usually completed by several developers , They used to connect through interface definitions , That is, according to the agreed interface protocol , The function can be realized . In this case , In addition to the requirements of self-test according to the interface , Also ask , One of these people is designated to be responsible for the series test , Ensure correct function . because In practice, the interface is difficult to define in every detail . The interface here may be between the front and the back http Interface , It may also be an interface based on database tables ( A deposit , Take one ). For example, a developer responsible for user storage only verifies whether the user information is written into the database table . Another developer in charge of the presentation only verified , Manually fill in the data in the database , Can it be read and displayed on the page normally . If no one is responsible for the serial verification of this process , The interface connection link bug You can't find , for example , The accessed fields do not correspond , The representation of null values is inconsistent null And "" etc. .

   Developers' self-test can indeed find out earlier bug, Reduce bug Cost of modification , No need to go through ,“ The test mentioned ”," Development check "," Development and Reform "," Test " The process of . But Uncle Guo thinks this is only the smaller side of the development self-test income , The greater benefit lies in , Improve the quality awareness of developers , Even if the function is not written, it is developed . By combining other traceability mechanisms , Can drive developers , Use a more reasonable design , Active reconfiguration and optimization .

   

   3、 Testers

  

     Testers are in many people's minds , Is the natural person responsible for software delivery quality , Its quality responsibility is mainly to do “ OK, test ”. Do a good test , It all depends on , Solid theoretical foundation of software testing , And a full understanding of the system business . Testing theory is a general skill , You can only think through learning , Accumulate and improve . And a full understanding of the system business , There are certain requirements for the stability of testers . If the testers in your company share resources , We should try our best to make them serve ,1 One or several projects . Especially for long-term iterations , Long cycle projects , Personnel stability is very important , Switching costs are high .

   Quality control is a superset of testing work , Therefore, improve software quality , It also requires testers to undertake an additional part of quality analysis and statistics . because Bug It is directly recorded by the tester , It is more direct to carry out this kind of work . Common statistical indicators such as ,

   Use case passing rate , Reactivate Bug Count , Demand question Bug Count , No self-test Bug Count , Missed demand Bug Count , Production discovery Bug Count .

   Are the evaluation basis of development quality , It is the basic data of double disk optimization . The tester is in the test work , Or in the process of production environment support , stay bug Management tools , Answer bug type , Identify and classify , For future statistical analysis .

   It also requires , Testers should be objective and impartial , Real response quality data . Here, too , Personally, I don't agree with Bug Clearly linked to performance , Otherwise, it is easy to cause opposition between development and testing , Serious internal friction , Very annoying .-_-||.

 

   4、 Management

  

     Management , First of all, understand , Research and development has its own objective laws . Give technology time , There is always a test , The process of optimization , If you always pat your head casually , Reduce the R & D cycle of R & D evaluation , that , Because the function is obvious , Must be delivered , So the first thing compressed must be quality . For example, a system is planned to be developed for one month , Test for a month , The leader patted his head , The development test is compressed into one month , So actually , Maybe develop 3 Three weeks , Test for a week , All kinds of reviews in the middle were thrown away , How convenient is the development and design , Just walk away from the test, and the main functions can be used . In this way, the quality is not critical , It is equivalent to giving the test to the end user , For long-term iterative projects , It will also accumulate a lot of restructuring debt .

   Establish Review , The mechanism of reinstatement , It is the responsibility of senior managers . Important evaluation companies should also have , Such as Requirements review , Development design review , Test plan / Use case review . Repeat the same , Such as Close and repeat , Or take time as the cycle It's on the second day of the month , Quarterly resumption .

   Grassroots managers , When participating in the organizational review , It should be ensured that the review is not a mere formality . Such as requirements review , Is to reduce demand BUG An important part of , The system is big , Need the ability of personnel , It is also difficult to consider everything , Need to develop , Test common , Help think , The impact of new requirements on existing systems . The review process is also a good opportunity to convey quality values , stay “ Good change , Little work ” and “ standard , Long term maintainability ” Try to choose , Standard requirements design , Develop the design scheme . Be careful and reduce Bug It is a very technical and challenging thing , Not a troublesome thing , Let the development spend more energy on one time to be right .

   Double check is an important backtracking mechanism , Quality problems should be traceable to individuals , Who raised the demand , Who wrote it , Who measured it . It doesn't have to be linked to performance , But the way responsibility goes to people , It can really push everyone , Establish quality awareness , Comply with quality specifications . Reasons for modules with low use case passing rate ? demand Bug There are more of them , It reminds us to pay attention to requirements compilation , review , Improve the ability of requirement writers , No self-test bug many , Remind developers that they don't have a strong sense of responsibility , The production of Bug Many , To analyze , Is it a common problem , Test whether it should cover , If it is the daily operation of the user , But the return process is not included , We should consider more communication with users during testing , Understand user habits .   

  OK First come here. , The answer above is , How much do you give :-). 

  

  

   Once there was a sincere love in front of me , But I didn't cherish , I didn't regret it until I lost it , This is the most painful thing in the world ……o(* ̄︶ ̄*)o

 

原网站

版权声明
本文为[Uncle Guo]所创,转载请带上原文链接,感谢
https://yzsam.com/2022/185/202207041613075177.html