1. What is software testing and the purpose of software testing?
Reference answer:
What is software testing:
·Software testing is the process of operating a system or an application program under controlled conditions and evaluating the results of the operation. The so-called control conditions should include normal conditions and abnormal conditions.
·The process of software testing should deliberately promote the occurrence of errors, that is, things should not appear when they should appear or should not appear when they should appear. In essence, software testing is "detection", and software defects are found in "detection".
·Software testing runs through the entire cycle of software definition and development. Software requirements specifications, structural design and programming* are all objects of software testing.
·Software testing includes white-box testing and black-box testing. White-box testing is a test for the correctness of program code. Black-box testing is independent of program code. From the perspective of users, certain test steps and test cases are passed , to verify whether the software function, performance and other indicators can meet the actual application requirements.
Purpose of software testing:
The purpose of software testing is to ensure the final quality of software products, and to control the quality of software products during the software development process. Generally speaking, software testing should be carried out by an independent product evaluation center. In strict accordance with the software testing process, test plans, test schemes, and test specifications are formulated, tests are implemented, test records are analyzed, and test reports are written according to the regression test situation. The purpose of testing is to prove that the program is wrong, but it cannot guarantee that the program is bug-free.
2. Where are the main risks of software testing?
Reference answer:
By not fully testing the software, we are actually choosing risk, because it is very likely that defects will exist in parts that have not been tested. For example, for the convenience of the programmer, some prompt information boxes will pop up when debugging the program, and these prompts will only pop up under certain conditions. It happens that some of these codes have not been commented out before the program is released. When testing, the test engineer did not test it. If the customer came across it, it would be a costly defect because it was not discovered by the customer until after delivery.
Therefore, we should try our best to choose the most appropriate test volume to minimize the risk.
Mobile terminal testing series for senior software testing experts
3. What is the status of testing tools in testing work?
Reference answer:
Many test engineers in China are quite obsessed with testing tools, especially some novices, and even expect that testing tools can replace manual testing. Test tools play an auxiliary role in the test work and are generally used to improve test efficiency. Automated testing makes up for the shortcomings of manual testing and reduces a certain amount of work. In fact, testing tools cannot replace most manual tests, and some automated tests such as performance tests cannot be done manually.
For automatic testing technology, it should be treated separately according to different situations of the software. Generally, automatic technology will be applied to places that cause a lot of repetitive work, pressure points of the system, and any places that are suitable for using programs to solve large quantities of input data. Then look for a suitable automatic testing tool, or develop a test program yourself. Must not be used for testing purposes.
4. The more defects found, does it mean that there are more software defects?
Reference answer:
This is a relatively common phenomenon. Test engineers will rack their brains before finding a defect, but after finding one, they will find many defects one after another, which gives them a sense of personal accomplishment. The main reasons are as follows:
-Generation* reuse, copying generation* makes programmers prone to make the same mistakes. Class inheritance causes all subclasses to contain errors from the base class, and repeated copying of the same generation* means that bugs may also be copied.
-Programmers are more tired, which can lead to more functional defects in some continuous programming. It is a common phenomenon for programmers to work overtime, so it is easy to write programs with more defects when the physical strength is not enough. And these continuous latent defects are exactly where the test engineer comes into play.
"Defects one after another" is not an objective law, but a common phenomenon. If the software is better written, this phenomenon is less common. Testers only need to seriously test the program.
5. Can all software defects be fixed? Will all software defects be fixed?
Reference answer:
Technically, all software defects can be repaired, but it is not necessary to fix all software defects. What testers have to do is to be able to correctly judge when they cannot pursue the perfection of the software. For the entire project team, what has to be done is to make trade-offs for each software defect, and decide which defects need to be repaired according to the risk. The main reasons for this phenomenon are as follows:
- Insufficient time resources. In any project, there are usually not enough developers and testers, and there is not enough regression testing time budgeted in the project. In addition, modifying defects may introduce new defects, so the strong pressure on delivery deadlines In this case, certain deficiencies must be waived.
- Some bugs only appear in special cases. This kind of bug is considered in commercial interests and can be repaired in future upgrades.
-Not a defect of a defect. We often encounter some functional issues that are treated as defects, which can be considered and dealt with later when there is time.
The last thing to say is that software testers, project managers, and programmers should discuss whether to fix the defect or not. People with different roles think from different angles to make the right decision.
6. Are software testers QA?
Reference answer:
The responsibility of software testers is to find software defects as early as possible and ensure that they can be repaired. The main responsibility of quality assurance personnel (QA) is to create or formulate standards and methods, improve the ability to promote software development and reduce software defects. The main work of the testers is testing, and the important content of the daily work of the quality assurance personnel is inspection and review, and the testing work is also the work object of the test assurance personnel.
Software testing and quality are complementary to each other, and both work to improve software quality.
7. How to reduce the losses caused by testers’ job-hopping?
Reference answer:
Job-hopping in the IT industry is already a common phenomenon, and job-hopping will bring certain losses to both the company and the individual. The test team will undoubtedly face the threat of job-hopping. As a test manager, only starting from the daily work can minimize the loss to the greatest extent. It is suggested that we start from the following two aspects:
-Strengthen mutual learning among employees in the department. Mutual learning is the basic requirement for establishing a learning organization and a process of knowledge transfer. On this basis, the technology owned by individuals can be deposited in the form of knowledge, and the transformation from tacit knowledge to explicit knowledge can be completed.
-Usually, when an enterprise can provide employees with enough room for development, employees will not voluntarily leave the enterprise if the salary is not particularly low. Therefore, if we want to retain employees, managers should link the personal growth of employees with the development of the enterprise, set reasonable development plans for employees and implement them. However, this requirement should be compared with a relatively good corporate culture.
8. What is the difference between test product and test project?
Reference answer:
It is customary to commercialize software after development and sell it to users with almost no modification * as a software product, that is, software that can be bought and "sold copies", such as Windows2000. Usually, software developed for one or several specific users is called a software project. A software project is a personalized product, which can be completely redeveloped according to user requirements, or existing software products can be modified to meet specific needs. User needs. The different characteristics of projects and products determine that there are still many differences between our test products and test projects:
- Different quality requirements. Usually the quality of the product is higher, and the cost of repairing the defects of the released product is higher, and even brings many negative effects. However, projects are usually aimed at a certain user. Although the higher the quality, the better, generally it is enough to meet the user's requirements.
- How much different testing resources are invested. Software products are usually developed by the R&D center, and the schedule pressure is less. At the same time, due to high quality requirements, more manpower and material resources will be invested.
-At the end of the project, you need to jointly accept the acceptance test with the user, which is a feature that product testing does not have.
In addition, test products and test projects will be very different in terms of defect management and test strategy formulation. Test managers should combine the specific environment to complete the work appropriately.
9. What are the points for attention in joint testing with users (UAT testing)?
Reference answer:
Before software products are put into production, user acceptance testing is usually carried out. If the user acceptance test fails, the direct result is that it will not be "Money", and the indirect effect is damage to the company's image, which is often more serious. According to the author's experience, user acceptance testing must make users happy.
In fact, user field testing tends to be more of a demonstration. On the premise of not deceiving users, we show users the advantages of our software, and finally satisfying "God" and willingly taking out "money" is our goal. Therefore, user testing should pay attention to the following items:
(1) It is impossible to test all functions in the user site test, so the core functions should be tested. This needs to be prepared in advance. These core functions must be tested in advance to prove that there are no problems before they can be tested together with users. The purpose of testing core modules is to build user confidence in the software. Of course, if these modules have many problems, they should not be demonstrated.
(2) If some modules do have problems, we can demonstrate other important business function modules, and make reasonable explanations to users when necessary. After gaining time, modify the defects in time to make up for them.
(3) Users can never be deceived and get away with it. The reason is very simple, because the software is for users, and the problem will be exposed sooner or later, unless you can modify it immediately.
When testing with users, we must also pay attention to various communication skills, so as not only to meet short-term interests, but also to lay a solid foundation for future cooperation.
10. How to write the test report submitted to the user?
Reference answer:
As testing gets more and more attention, it is inevitable for the development team to provide test documents to customers. Many people will ask: "Can we provide the test report in the work to the customer?" The answer is no. Because providing internal test reports may make customers lose confidence and even deny the project.
Test reports are generally divided into internal test reports and external test reports. The internal report is our project document in the test work, which reflects the implementation of the test work. It will not be discussed here. Readers can refer to relevant textbooks. Here we mainly discuss how to write external test reports. Generally, external test reports must meet the following requirements:
- Prepared based on internal test reports, which can generally be excerpted;
- It is not possible to report serious defects to customers. Even if the defects have been modified, there is no need to let customers know about the defects in development;
- Some defects can be listed on the report, but they must be medium-level defects, and these defects must be repaired;
- The content of the report should be as true and reliable as possible;
- The entire test report should be carefully reviewed, and strive not to bring negative effects to the project, especially the performance test report.
Mobile terminal testing series for senior software testing experts