Views on Current System Tests

1. Test Plan
The test plan mentioned here refers to the test plan in the test phase, rather than the test in the whole project process.
Test Plan.

Status quo:
Currently, the test documentation mainly describes the test schedule. This Time Division is also very rough and has no basis. Why does it take so much time? Currently, the test time is determined based on personal intuition, experience, and other methods. Therefore, such test plans are too random and too coarse-grained to facilitate management. The current test is for testing and has no planning.

Personal Opinion:
Refine the test plan so that the test time can be quantified.

1) Change the test time division method and use the workday/person calculation method.
At present, when preparing a test plan, the plan start/End Time in the Test Progress is usually divided by a specific time such as 20050101-20051201. This causes the problem when the project plan is changed, the test plan time has to be adjusted at any time. Such changes may be frequent and trivial. The alternative method is to cancel this method, using the workload record method of 30 working days/2 people/2 people/month, in this way, you only need to track the specific start time in the Project Plan and do not have to change the test plan repeatedly.

2) Calculation of test time
It is difficult to calculate the test time, but mainly involves the following aspects:

A) Time for writing test cases
At present, there is no management and collection of test cases. Testing is mainly based on personal experience, which is unfavorable.
For management and accumulation. I think the test cases can be documented. Although it takes some time at the beginningCommunityTherefore, the reusability of test cases is very high. Personal suggestion: Create a test case template.

B) time when the system executes the test case

C) Time for submitting the test report

That is, the time when a bug is submitted in the Bug Management System.

D) Bug validation test time.

E) Bug fix time and system update time

F) other time

Calculate the test time based on the system function points, so that a function point can be calculated.
The time it takes to obtain the test time of a module or a work account, so as to obtain the workload required for the test plan. Where

E) Not the time spent by the tester, but not the workload of the tester.

2. Test Tools

The current testing methods are all manual tests. The efficiency of manual tests is closely related to the tester's experience.
System, requires some skill. Some Test types can be implemented using test tools.

For example, border testing, illegal testing, functional testing, and performance testing. However, automated testing does not replace manual testing. It is a supplement. Generally, test automation only accounts for about 30% of the total test process.

However, testers are not familiar with the testing tools. Currently, they can only perform manual tests first and continue to explore the operability of automated testing. (There is no automated testing tool at hand)
 
3. Test methods and types

The current testing method is mainly black box testing. From the actual situation, the black box test has been completed.
Very good, but also can meet the needs of the actual project.

Black box testing has the following advantages:

1) relatively simple, no need to knowProgramInternalCodeAnd implementation;
2) It has nothing to do with the internal implementation of the software;
3) from the user's perspective, it is easy to know what functions the user will use and what problems it will encounter;
4) based on the software development document, you can also know which functions are implemented in the document;
5) It is more convenient for automated software testing.

Black box testing has the following Disadvantages:

1) it is impossible to cover all the code. The coverage rate is low, and it can only reach 30% of the total code volume;
2) the reusability of automated testing is low.
 

Speaking of the test type, I think this is a link we ignore. For example, if a bug is found, after the developer modifies the bug, the tester may only consider whether the bug still exists and ignore other problems, which may cause other bugs. (This bug may cause a chain reaction of other functional modules while being modified, resulting in other bugs .) Then, the smoke test can solve such problems (although its coverage is still relatively low ).

Other Test types include functional test, security test, stress test, performance test, and regression test) and Setup/upgrade test (installation and upgrade test.

I think these testing skills can be trained or documented by testers.
 
4. Test Cases
The black box test cases are discussed here. For more information, see the black box test case design method.
 
5. test work assessment

The content of the work appraisal is just in its infancy in the company, and the appraisal of the testing work is also
Is more likely. Below I will list several assessment criteria for your reference only.
The test stages are divided into test plan, test design, and test execution according to the test cycle.
The test plan is the responsibility of the test Manager. Testers are mainly responsible for testing design and execution.

Assessment criteria:

1. The number of bugs is currently managed by the bug management system. Therefore, the system can be used to evaluate the number of defects detected by testers.
2. BUG Tracking: the bug detected by the tester, and whether to track the handling of the bug in a timely manner.
3. The number of test cases is the number of test cases designed by the tester. The relevant standards are functional points, that is, the number of test cases designed by a functional point.
4. The test progress is the gap between the planned time and the actual use time.
5. The critical defect rate is classified in the Bug management system according to the degree of urgency. The critical defect rate here refers to the degree of urgency in which testers discover bugs.