Several issues restricting the development of testing (from the China Software Testing Forum)

Several problems restricting the development of testing

Relative to the maturity of software development theory, the testing theory is still very immature. (Of course, compared with the industrial development theory, the software development theory is also very immature .) The rise of the testing industry will depend largely on the maturity of the testing theory.

There are still some questions about the current tests (Technology and Management), which are also the questions I have been thinking about (maybe some of these problems have been solved, and some of them are not uncommon ), the following is a summary of these questions, hoping that they will be answered later.

1. Where is the test end point?
As an engineering process, it is terrible to clearly define the ending rules of an activity, just like a ship sailing in the sea without its own destination. The test is such a ship with no targets.

The most appropriate criterion for the end of the test should be that the number of defects is controlled within an acceptable range. However, in the actual process, the number of undiscovered defects is never known. Although there are methods to estimate the number of unknown defects, however, its accuracy and cost make it less feasible. Therefore, although this criterion is most suitable, it is not practical.

Another test termination criterion is measured by process. The corresponding steps are completed according to the test process, and the work is completed, even if the test is completed. This test termination criterion is no different from the non-criterion and does not achieve the purpose of acceptance. In other words, there is an assumption that the defined test process is fully valid. In this case, this criterion can be used to end the test activity. Therefore, although this criterion is not very accurate, it is the most common criterion for testing termination.

Another common criterion is the timeline termination criterion. When it comes to dead line, no matter what, it will end. This kind of rule will often be encountered in some non-standard companies. I personally think that this criterion is the most harmful to the test. If we end the test with this criterion in the organization, the quality of the test can only be blessed by God.

To sum up, if we can define a test termination criterion that can be used as an objective evaluation criterion and is easier to implement, it will have a profound impact on the maturity of the test theory.

2. How to evaluate the tester's advantages and disadvantages

As the behavior subject of the test activity, the advantages and disadvantages of the tester directly affect the advantages and disadvantages of the test activity. But how can we evaluate the tester's advantages and disadvantages?

The tester's level cannot be measured by the number of detected defects. In this way, the test can only be directed to activities focusing on the discovery of surface defects.
The number of documents that cannot be written is more time than to measure the tester's level.
The tester's level cannot be measured by the number of accepted Defects

Excellent testers can be informed;
Excellent testers have unique ways of thinking and can continuously innovate test methods;
Excellent testers can clearly describe defects and persuade developers to correct them;
Excellent testers can obtain the greatest understanding of the system from the smallest information;
Excellent testers need flexible thinking and comprehensive knowledge.

These are both qualitative analyses and there are a lot of subjective factors in them. If there is a way to link these with results and quantify them, this will be of great help to human resource management in testing.

3. How to embody the value of testing

As a service department for development, testing can reflect its own values. This will be an important factor in the future development of testing.
There are many difficulties in reflecting the value of testing. I will explain them one by one:
1. The results of tests are mostly intangible assets, which are hard to be measured. Product Quality and corporate image can be said to be the most direct result of testing, but such assets will be difficult. The second type of results produced by testing is to improve the development capability, which is also difficult to measure.
2. The identified test results are easily ignored as the value of the test. When it comes to excellent software, many people first think of superb programming, skillful programming skills, and mature software processes. Few people think of it as being strictly and comprehensively tested. Testing always lives in this forgotten corner.
3. Too much embodiment of the value of testing will lead to the confrontation between development and testing. The most intuitive result of the test is the defect, which exactly proves the lack of development (although it is true that it is not the right person, but who can see their own programs being criticized, what should I do if I still use the results as my work result to ensure that I am not very enthusiastic ?) Too much emphasis on the value of testing will lead to the growth of hostility. Therefore, Wise product managers tend to weaken the effectiveness of testing and tend to establish a balance.

Therefore, the embodiment of the current test value is often determined by the leader's attitude towards the test. The value of the test can only be reflected in his mind. This situation cannot be widely recognized by most people and is obviously not conducive to establishing the authority of testing and other personnel's support for testing activities. Finding an appropriate way to reflect the value of testing is a big problem that troubles test managers and product managers who have a good understanding of testing.

4. Thoughts on the Test Mode

The idea of the test mode stems entirely from the design mode. Since the complex architecture design can be abstracted and summarized into such a set of things, why can't we look at the test activities as well?

Currently, I do not have a deep understanding of the mode and do not have much test experience. So far, I have to abstract it into a mode and name it include)

Module A references Module B as the sub-function of module A. In this case, the test method is to test module B first, and then use any path in Module B as part of module A to test module, at this time, any path in Module B has been assimilated into an equivalence class (although they may not belong to the same equivalence class in the test of Module B)

(This is just a kind of thinking concept, hoping to improve the system)

5. Relationship between testing and development
What is the relationship between the test and the development?

The test department is independent of the Development Department. This model may be due to the separation of QC and production departments in the traditional manufacturing industry. The objective is to ensure the objectivity and effectiveness of the test process and results. This mode is equivalent to dividing testing and development into two distinct activities, without too much consideration for mutual benefits between the two activities. In this mode, it is likely to evolve into a confrontation between testing and development, or increase communication costs between testing and development.

Test and develop simultaneously. This is the lightweight development process of XP, and the current test-driven development theory is in line with this model. Design and Test are adopted before development. When the developed software passes all tests, the software is completed. In fact, this method does not avoid the limitations caused by testing your code. It only changes the sequence of thinking and reduces the impact of the mindset on software development defects.

The test department belongs to the R & D center, but is independent of the project team. This mode ensures the consistency of the final goal (high-quality software products) between the test and the project team, effectively reduces the communication cost, and ensures the independence of the test personnel, it will not be overly controlled by the product manager to avoid testing failure. However, in this case, the test results may not be valued by the project team because they are independent from the two departments. In this case, frequent coordination is required to handle defects in a timely manner.