In addition to Weibo, there is also WeChat
Please pay attention
WeChat public account
Shulou
2025-01-18 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Network Security >
Share
Shulou(Shulou.com)06/01 Report--
Abstract: in the actual project, regardless of the quality of product requirements, but as far as R & D quality assurance is concerned, testers find a large number of implementation-like bug in the testing phase, and pull developers to repair bug; every day or find a major problem when they are close to going online, resulting in insufficient repair verification time, but can only be "brazen" online. There may be a variety of ways to solve these problems, but let's talk about how to use R & D quality assurance front to avoid these problems as much as possible.
Key words: research and development quality, quality assurance front, early exposure of problems, online risk
Background
In practical projects, regardless of the quality of product requirements, testers often have to face a lot of headaches from time to time in terms of R & D quality assurance:
A newcomer came to the development team, which was not in great demand, but during the test, the testers found that they could not even run through the main process and could not go on.
This time, there is a large project starting from scratch, involving the interaction of multiple modules, but QA found that the implementation was not consistent with the requirements during the test, so he had to re-pull the product students and developers to re-demand.
A core requirement needs to be refactored. As a result, due to tight scheduling, not only many of the old functions have been broken, but also the new functions do not work.
Changed a very complex business of various interactive scenarios, because the development is time-consuming, the test cycle is already compressed, in addition, most of the scenario simulation and testing are very time-consuming, and the test is barely finished when it comes online, although it is not very confident. but because the project is urgent, we have to go online.
In order to change a business that is very complex to interact with third-party business, due to the need for third-party cooperation to cover the scene 100%, but due to environmental problems and third-party personnel time problems, the test has been lived by block for a long time.
No matter whether you have encountered all of these problems, or some of them, these problems may have more or less impact on the online quality, or even directly lead to online failures. These problems have one common feature: most of the exposure of the problems are concentrated in the testing phase. Here, put aside the problems of demand, and talk about the experience and experience of R & D quality assurance related to the realization of your own project experience.
What is the front of R & D quality assurance?
Quality assurance must be no stranger to everyone, that is, through various means to ensure product quality and quantity online, to put it bluntly, online failures as few as possible, it is best not to break down. R & D quality assurance refers to the code implementation quality. The bug corresponding to R & D quality is the implementation class bug, in other words, the bug caused by the non-compliance between the implementation and the requirements. The R & D quality assurance front refers to advance the exposure time of the implementation-like bug.
The exposure phases of the implementation class bug are usually: technical design, technical review, code implementation, smoke testing, testing phase, and online. The R & D quality assurance front is to make the implementation-like bug exposure earlier, which is best found in the technical design stage.
Several means of leading R & D quality Assurance
As mentioned earlier, there are different stages of implementation class bug exposure, but as far as technical design is concerned, it is still an absolutely developer-led stage, and it is extremely dependent on the developer's experience. For many practical projects currently exposed, there are few opportunities for testers to directly participate in the technical design phase, so the technical design quality will not be discussed too much here. Let's talk about some of our experiences in the remaining stages. You are welcome to add them.
First, confirm the implementation of various scenarios in the technical review
The technical review here recommends a developer-led review meeting attended by testers. From the tester's point of view, although the specific form of the review meeting is not limited, the following objectives should be achieved:
Various scenarios in the business requirements are covered
All the original businesses involved are covered.
The handling of various exception scenarios meets the requirements or product common handling.
Of course, the technical review itself requires testers to be very familiar with the product business and technical implementation, otherwise even if they participate in the review, I am afraid the effect will be minimal. In order for developers to actively cooperate with the technical review, the following practices can be considered:
Add the technical review to the project process, and the specific form can be determined according to the size of the project.
In order to encourage the enthusiasm of everyone to participate, you might as well think of some targeted encouragement methods.
For each review, you can summarize the optimization points, modify the points, and make it known to the team members to recognize the value of the review.
Second, encourage microservice testing in the code implementation phase
As we all know, unit testing is mainly to find problems from the underlying code more quickly, and try to avoid testing a large module directly, so troubleshooting problems can be time-consuming. I can't remember how many times a developer had to hit a breakpoint in order to troubleshoot a problem, and how many times did debug really locate the problem code. In addition to the incomplete log log, this problem is caused by the smaller modules assembled into modules and the lack of necessary key single tests for the methods. Of course, in actual projects, people's attitude towards unit testing is often: despite love, it is difficult to really act. For many of the projects they have worked on, developers may pass the log self-test, or simply run off the test for some method, and the team that treats unit testing as work has never been touched. As a result, in the actual project, by reaching a consensus with the developer, the self-test is tested against an independent service during the code implementation phase.
Businesses suitable for microservice testing generally have the following characteristics:
In addition to the API interface, the lower-level implementation of the business is built through a number of micro services
The logic of the micro-service involved is complex, and it is difficult to cover 100% of the integration test.
The microservices involved are frequently modified and need to be launched independently.
Microservice testing implementations are best implemented using automation. In the actual business, I have implemented the testing of micro-services completely through automation, and the maintenance of test cases is maintained by testers. When testing is needed, developers only need to click a button to execute. You can view the results directly in a few minutes. Of course, in addition to automation means, if a service is not 100% automated, you can consider whether there is an auxiliary solution according to your own business characteristics.
Third, do a good smoke test when taking the test.
Presumably, both developers and testers often have a similar experience when executing the results against the same test case: the developer did it carefully and found no problem, but the tester randomly tried it twice and found the problem. Of course, this excludes the fact that developers and testers have different perspectives when performing tests, which may be due to different understandings of the execution steps of the same test case.
Here are some of my own practical experiences:
QA assigns the core main process use case to specific developers to execute
QA personnel provide automated tools similar to one-click self-test for developers to execute
Complex use cases that need to create scenarios, and QA assists developers to execute them together
Which way, according to their respective business characteristics, needs, but keep in mind: smoke testing should not be treated as a process, implementation is just a formality.
Fourth, quickly find problems during testing
To find the problem quickly is to expose the problem in the first half of the test cycle as far as possible, avoiding the sudden discovery of many problems such as one day at the end of the test cycle, resulting in insufficient time for bug repair and regression verification. Therefore, the core goal of quickly finding the problem is to expose the problem as early as possible.
If you want to expose the problem in advance, of course, in addition to the completeness of the test solution, personnel experience and other factors, you can also do something to improve the test efficiency:
Automated coverage. This is a common technical means to improve efficiency, as long as the automation use case covers a comprehensive, plus one-click execution, the problem can be exposed in a few minutes.
Prepare everything you need for the test in advance. The "everything" here includes not only test data and test equipment, but also some things that need to be done when there is interaction with a third party, such as saying hello in advance, making an appointment, and so on. Strive not to delay test execution due to lack of preparation.
Get as many people as possible to participate in the test. When you see this, you may say: besides the testers, there are others who need to participate in the test, not to mention that others do not want to participate. Yes, there is indeed a problem in this respect. But here is to say that quality assurance involves all aspects of things, not the testers alone; and testers also have experience, perspective limitations, it is likely that the obvious problems have been missed. So testers might as well guide the rest of the team to participate in testing, such as product / developer participation in main function acceptance, designer participation in UI/UE proofreading, and so on. In their own actual projects, the deepest feeling is that the participation of team members can look at the product with the mentality of "novice users", so they are more likely to find some experience problems. and this is precisely because testers are exposed to products so much that they are easy to miss.
Write at the end
The quality assurance of R & D requires the concerted efforts of developers and testers, and both of them need to be cautious about quality assurance. Sometimes I think that if the code written by the developer does not implement the problem, then the tester's work can be greatly reduced, less time-consuming for troubleshooting, repair, and verification, and verification can be released online a few times. But this is obviously unlikely to be achieved in practical projects: with more and more complex product design, the speed of product iteration is getting faster and faster, and the demand for products is increasing.
After recognizing the various obstacles to R & D quality assurance, you might as well correct your mindset and do something seriously to advance R & D quality assurance so as to reduce the risk of product release as much as possible.
Welcome to join the 51 software testing family, where you will get [latest industry information], [free test tool installation package], [software testing technology], [job interview skills]. 51 learn and grow with you! Looking forward to your joining: QQ Group: 755431660
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.
Views: 231
*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.
Continue with the installation of the previous hadoop.First, install zookooper1. Decompress zookoope
"Every 5-10 years, there's a rare product, a really special, very unusual product that's the most un
© 2024 shulou.com SLNews company. All rights reserved.