[64] 11 common problems of Testing Technology

1. Why should we try not to allow wealthy employees to perform some tests?

On the surface, this reflects the efficiency and flexibility of management, but it also reflects the contempt of managers for testing. Testing is closely related to testing people. The testing staff should be diligent and patient, be good at learning, thinking, and discovering problems, be careful and organized, and summarize the problems. If they have such advantages, they will also be excellent in doing other work, therefore, another requirement is that you like to test the job. If he is a full-time employee, he must be more experienced and confident. Young people in China seem to like to do it.ProgramPersonnel, the two work in different nature, different treatment, different status, and different understandings of the value of self-realization, which is a problem to be improved in the industry. If you are satisfied with the task just to complete the task or find a few problems, this will not work in any other job.

2. Is it possible to fully test the program?

Software testing beginners may think that after obtaining the software, they need to perform a full test, find all Software defects, and release the software "Zero defects. In fact, full testing is impossible. There are mainly the following reasons:

Full tests are time-consuming and are not allowed in time;
Full testing usually means a large amount of resource investment, which is often not feasible in reality;
The input is too large to be tested one by one;
Too many output results, which can only be classified for verification;
There are too many ways to implement software;
There are no objective standards in the software product documentation. from different perspectives, the standards for Software defects are different;
Therefore, the test degree should be determined based on the actual situation.

3. What are the main risks of software testing?

We did not perform a full test on the software, but we chose the risk because there are very likely no tests for the defects. For example, for the convenience of programmers, some prompt boxes will pop up during program debugging, and these prompts will only pop up under certain conditions, which happen before the program is releasedCodeSome of them are not commented out. The test engineer did not perform the test during the test. If the customer encounters it, it will be a costly defect because it is discovered by the customer only after delivery.

Therefore, we should try our best to select the most appropriate test volume to minimize the risk.

4. Is the more defects found, the more Software defects?

This is a common phenomenon. The test engineer will have a hard time thinking before finding a defect. However, after finding a defect, the test engineer will discover many defects one after another, with a sense of accomplishment. The main reasons are as follows:

Code reuse and code copy make it easy for programmers to make the same mistake. The inheritance of classes causes all subclasses to contain errors of the base classes. Copying the same code repeatedly may also cause defects.
Programmers are tired and may cause many functional defects in some continuous writing. Overtime is a common phenomenon for programmers, so it is easy to write programs with many defects because of their physical strength. These continuous latent defects are exactly where the test engineers show their talents.
"One defect is connected to one" is not an objective law, but a common phenomenon. This is not common if the software is well written. Testers only need to seriously test the program.

5. Can All Software defects be repaired? Should all Software defects be repaired?

Technically, all Software defects can be repaired, but there is no need to fix all Software defects. What testers need to do is to correctly determine when they cannot pursue software perfection. For the entire project team, we need to make a trade-off between each software defect and decide which defects should be repaired based on the risk. The main reasons for this phenomenon are as follows:

There is not enough time resources. In any project, developers and testers are usually not enough, and there is no budget for adequate regression testing time in the project, in addition, the modification of defects may introduce new defects, so under the pressure of a strong delivery period, you must discard the modification of some defects.
Some defects only occur under special circumstances. They are in commercial interests and can be repaired in future upgrades.
It is not a defect. We often encounter some functional problems that are treated as defects. Such problems can be considered for further processing in the future.
Finally, it is up to the software testers, project managers, and programmers to discuss whether to modify the defects and determine whether to fix them. The personnel of different roles should consider the defects from different perspectives, to make the right decision.

6. Is the software tester QA?

Software testers are responsible for identifying Software defects as early as possible to ensure repair. QA personnel are primarily responsible for creating or developing standards and methods to improve software development capabilities and reduce Software defects. The main work of testers is testing. The daily work of Quality Assurance personnel is inspection and review. The testing work is also the work of the testers.

Software testing and quality are complementary and work to improve software quality.

7. How can we reduce the loss caused by tester job hopping?

In the IT industry, job-hopping is already a common phenomenon, and job-hopping can cause losses to companies and individuals. The test team will undoubtedly face the threat of job-hopping. As a test Manager, the test team can minimize losses only from the beginning of daily work. We recommend that you 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 the process of mutual knowledge transfer. On this basis, personal technologies can be accumulated in the form of knowledge, which completes the conversion of tacit knowledge to explicit knowledge.
Generally, when an enterprise provides enough space for its employees to develop, employees will not take the initiative to leave the enterprise unless the treatment is particularly low. Therefore, if we want to retain employees, managers should associate the personal growth of employees with the development of enterprises, and set reasonable development plans for employees and put them into practice. However, this requirement requires a good corporate culture.
8. What is the difference between a test product and a test project?

Traditionally, after the development is completed, the software that can be sold to the user can become a software product, that is, the software that can be sold as copies can be bought, for example, Windows 2000. Software projects are usually software projects developed for one or more specific users. software projects are a personalized product and can be re-developed according to user requirements, you can also modify existing software products to meet specific user needs. Different features of the project and product determine that there are still many differences between the product and test project:

Different quality requirements. Generally, the quality of the product is higher. After the product is released, the cost of fixing defects is higher, which may even bring many negative effects. A project is usually intended for a user. Although the higher the quality, the better the project quality.
The test resource investment varies. Software products are usually developed by the R & D center, with less progress pressure. At the same time, due to high quality requirements, a large amount of human and material resources will be invested.
At the end of the project, we need to test the project with the user. This is not characteristic of the product test.
In addition, the test product and the test project are very different in defect management and test policy formulation. The test Manager should work properly according to the specific environment.

9. What are precautions for Joint Testing with users (UAT testing?

Before software products are put into operation, user acceptance tests are usually conducted. If the user's acceptance test fails, the direct result is that there is no "money", and the indirect impact is damage to the company's image, while the latter has more serious impact. Based on the author's experience, the user acceptance test must satisfy the user.

In fact, on-site testing tends to be a demonstration. Without deceiving users, we will show users the advantages of our software, and finally let the "God" satisfied and happy to pull out the "Silver" is our goal. Therefore, pay attention to the following items during user testing:

(1) it is impossible for the user to test all functions in the field test. Therefore, the core functions should be tested. This requires preparation in advance. These core functions must be tested in advance to prove that there is no problem before they can be tested with users. The purpose of the test core module is to build users' confidence in the software. Of course, if there are many problems with these modules, they should not be demonstrated.

(2) If some modules do have problems, we can demonstrate other important business function modules.

The user makes a reasonable explanation. Modify the defects in time to make up for the competition.

(3) never cheat users and pass the customs. The principle is very simple, because the software is intended for users, and problems will be exposed sooner or later, unless you can modify them immediately.

In testing with users, we should also pay attention to various communication skills, so as not only to satisfy short-term interests, but also to lay a solid foundation for future cooperation.

10. How do I compile a test report submitted to the user?

With the increasing importance of testing, it is inevitable for the development team to provide testing documents to customers. Many people will ask: "Can we provide the test report at work to the customer ?" The answer is no. Providing internal test reports may cause customers to lose confidence or even deny the project.

Test reports are generally divided into internal test reports and external test reports. The internal report is a project document in our testing work. It reflects the implementation of the testing work. We have not discussed it here. You can refer to the relevant content in Chapter 9th. This article mainly discusses the writing of the external test report. Generally, the external test report must meet the following requirements:

Compile according to the internal test report, which can be excerpted;
Critical defects cannot be reported to the customer. Even modified defects do not need to be known to the customer;
Some defects can be listed in the report, but must be intermediate and must be repaired;
The content above the report should be as authentic and reliable as possible;
The entire test report should be carefully reviewed, so as not to bring negative effects to the project, especially the performance test report.
In short, the external test report should be carefully written.

11. How do developers always make some low-level mistakes?

This phenomenon is particularly common in teams with irregular development processes, especially in some "Workshop-style" teams. To solve this problem, we generally start from two aspects:

On the one hand, start with development management, that is, to solve the problem from the root. A standard development process can be developed, or even a punishment system can be developed, and a planning and design can be completed before software development.

On the other hand, it is better to strengthen testing. The specific practice is to strengthen testing by developers and eliminate these problems in the development stage, readers can refer to section 13.1.2 repeated defects and who is responsible for the case study in Chapter 13th. 13.1.2 discusses the methods for such problems.

In addition, developers can also be controlled through standardized defect management. For example, the testing department can sort out common defects so that developers can check them by themselves, to reduce the occurrence of such low-level errors.

It is normal for developers to make mistakes. As testers, they must not complain. It is best to solve the problem seriously.

12. What is the role of a testing tool in testing?

Many domestic test engineers are very infatuated with testing tools, especially some new users, and even expect testing tools to replace manual testing. Testing tools play an auxiliary role in testing and are generally used to improve testing efficiency. Automated Testing makes up for the shortcomings of manual testing and reduces the workload. In fact, testing tools cannot replace most manual tests, and some automated tests such as performance tests cannot be completed manually.

Automatic Testing Technology should be treated separately based on different software situations, in general, automatic technology will be applied in places that cause a lot of repetitive work, pressure points of the system, and any place suitable for using programs to solve large volumes of input data. Then find the appropriate automatic test tool or develop the test program by yourself. Do not use the test tool.

Reposted from: www.51testing.com