As a test engineer, throughout his career, he will be involved in writing various types of documents, which generally include the following:
The corresponding document templates and document writing videos are as follows:
1. Necessary documents for testing positions
In a regular software testing process, it involves the writing of test plans, test plans, test cases, and test reports. These documents are also the types of documents that software testing positions must master.
1. Test plan
A test plan is a document at the organizational management level, which plans a test activity from the perspective of organizational management. Specify and constrain the testing scope, organization, resources, principles, etc. of the entire testing process, formulate task allocation and time schedule for each stage of the entire testing process, and propose assessment, risk analysis, and management requirements for each task.
Writing time and basis:
After the requirements analysis stage, and before carrying out specific testing activities, the test leader will prepare the test plan mainly with reference to the "Requirements Specification".
Purpose of writing test plan:
- Project managers and test bosses can better control project progress and allocate corresponding resources, etc.
- The members of the testing team know the entire project plan and the work content and time to be carried out in different stages.
- It makes it easier for other members to understand the work task arrangement of the test group and better collaborate with the team.
Test plan content:
- why—the purpose of writing, why the plan is to be made;
- what—test scope, what aspects are tested, and work content at different stages;
- when—task schedule, start and end time of the same task stage;
- where—corresponding documents, defect storage location, test environment, etc.;
- who—distribution of human and material resources, which testers are responsible for which testing work;
- how—testing methods and strategies, which testing tools to use
2. Test plan
The test plan is generally a further refinement and clarification of the test plan, and is a technical document. It describes the features that need to be tested, the testing method, the planning of the testing environment, the design and selection of testing tools, the design method of test cases, the design plan of the test code, etc.
Time and basis for writing the test plan:
It is generally written after the test plan is completed, and is mainly designed by experienced testers based on the "Requirements Specification" and "Outline Design Specification".
Purpose of writing test plan:
- Clarify specific test points and test methods for subsequent test execution work
- Clarify various test environments and other testing requirements required for testing;
- It facilitates project managers, software developers, software maintainers and testers to perform subsequent maintenance and provide a basis for finding the causes of defects.
The core content of the test plan:
- Define your testing strategy
- Detail the test characteristics, including the specific testing techniques and tools to be used
- Access and exit standards and technical methods during the testing phase
- Test case planning
- Test environment planning
- Design of automated testing framework
3. Test cases
A test case is a set of documents containing test inputs, execution conditions, and expected results compiled for project requirements to test whether a program meets customer requirements. Mainly in two forms: excel and mind map.
Test case writing time and basis:
It is generally written after the test plan and scheme are clear, and the design is carried out based on the "Requirements Specification", prototype drawings, "Outline Design Specification", etc.
Purpose of writing test cases:
- It is the guidance for testing work, the fundamental guarantee for the stability of software testing quality, and the benchmark for evaluating test results.
- Having a use case to guide test execution can serve as a traction when testers are tired.
- In the process of writing use cases, you can gain a deeper understanding of the system architecture or business by familiarizing yourself with the requirements.
- Avoid test scapegoating
Test case content:
- Use case number: uniqueness, general rules: product name_test phase (it st uat)_test item_number
- Test project: corresponds to a function or sub-function module
- Test title: A sentence summarizing the intent and purpose of the current test
- Importance level: high/medium/low
- Preset conditions: Some prerequisites need to be met, otherwise the use case cannot be executed
- Test input: The input information that needs to be processed must have guiding significance when combined with the steps.
- Operation steps: clearly give a description of each step, and the executive can complete the execution work according to the step
- Expected results: Compare the expected output with the actual results to determine whether the tested object meets the requirements.
- Actual result: The actual result after passing the test execution, which is empty when writing the use case.
4. Test report
The test report refers to writing the test process and results into documents, analyzing the problems and defects found, providing a basis for correcting the quality problems of the software, and laying the foundation for software acceptance and delivery.
Test report time and basis:
It is written after the test is completed, usually by the person in charge of testing, and is mainly designed based on requirements documents, test plans, test cases, and bug records.
Purpose of writing test report:
- Ensure whether the test plan is fully executed and whether the test coverage meets the predetermined requirements
- Important references and basis for project completion
- A summary of the work, giving project team members thoughts on development process specifications and quality.
Test report content:
- Writing purpose and scope: purpose, basis, test scope, test environment
- Testing process: test organization, test time and personnel tasks, use case coverage/execution rate/pass rate
- Defect statistics and analysis: defect summary, defect analysis, remaining defect statistics
- Test summary: risk analysis and suggestions, test conclusions
2. Documents related to interface testing & automated testing
1. Interface test cases
Writing time and basis: Back-end development defines the interface document and is written based on the interface definition document or outline design document
What’s included:
- Number, title, interface name
- Interface address, request method, request header, request parameters
- Response body information, database operations
2. Interface test report
Writing time and basis: The interface test has been completed, based on the test plan, interface definition document, interface use case, and bug record
What’s included:
- Test purpose and scope
- Testing tools and resources
- Test recording and result analysis
- Test conclusion
3. Automated testing plan
Writing time and basis: After the test plan (automated test tasks are clearly defined in the plan), it is written based on the product requirements and test plan
What’s included:
- Writing purpose, project situation, test scope, automation implementation tasks
- Automation technology selection, including related technologies and framework ideas adopted
- Test environment, including hardware environment and software environment
- Tester progress and task arrangement, deliverable management
3. Documents related to performance testing
1. Performance test plan
Writing time and basis: After the performance test requirements are clear; the source of performance requirements can be formed from requirements documents, technical design documents, and cooperation team communication.
What’s included:
- Writing purpose, performance indicators, test objects
- Performance test scenario design, performance test case design
- Test environment, test tools, tester arrangements
- Schedule, delivery list, risk assessment
2. Performance test cases
Writing time and basis: The test plan design has been completed; written based on the test plan
What’s included:
- Basic information: number, test module, performance scenario, preconditions
- Performance indicators: number of concurrent users, response time, TPS, transaction success rate, etc.
- Server resource utilization: CPU, memory, disk I/O, etc.
3. Performance test report
Writing time and basis: Performance test execution has been completed, not necessarily after development and tuning is completed.
What’s included:
- Purpose and scope of writing
- Testing tools and environment
- Test records and result analysis: must include chart data and corresponding conclusions generated during the performance test
- Overall conclusion of the test
4. Documents related to usability & security testing
1. Usability test
Concept: Whether it is easy for users to learn and use, reduce the memory burden, and the degree of satisfaction in use is relatively subjective. Generally, the ease of use can only be evaluated based on test feedback information from many users.
Including: easy to understand test, easy to learn test, easy to operate test, attractiveness test, easy to use compliance test
2. Security testing
Concept: Security testing is the process of inspecting the product during the life cycle of IT software products, especially from the basic completion of product development to the release stage, to verify that the product complies with the definition of security requirements and product quality standards. In layman's terms, check the system's ability to prevent illegal intrusions and penetrations.
Including: program, network, database security testing.
5. Documents related to project management
1. PERT estimation table
Concept: PERT (Program Evaluation and Review Technique) - Program review technique that improves the accuracy of activity duration estimates by taking into account uncertainty and risk in estimates.
Use three estimates to define approximate intervals for activity duration: most likely time, most optimistic time, and most pessimistic time
2. WBS task decomposition and estimation
Concept: WBS (Work Breakdown Structure)-work breakdown structure is an estimation method. The process of creating a WBS is the process of breaking down project deliverables and project work into smaller, more manageable components.
Function: 1. Facilitates early understanding of work scope 2. Facilitates delivery of expected results 3. Facilitates allocation and explanation of work 4. Provides baseline for scope change control 5. Improves communication and reaches consensus
3. Project work schedule
Evaluate the workload of the project work by stages, clarify the time and responsible person. It can be evaluated according to the WBS decomposition method.
4. Gantt chart
Concept: Also known as horizontal bar chart and bar chart. It uses a bar chart to display the internal relationships of projects, schedules, and other time-related system progress over time. Graphically represent the sequence and duration of a specific project through an activity list and time scale.
5. Test progress monitoring table
Concept: Test progress monitoring, especially test execution progress monitoring, is a key testing activity in the testing process. Monitor test execution progress, obtain and analyze the current test status and information during the test process, and continuously track and correct the effectiveness of response activities.
Mainly include: project progress, test execution, defect status, etc.
6. Risk tracking table
Concept: Record risk events that may occur or have occurred during the project development process, including risk description, impact, risk level, response strategy, risk status, responsible person, etc.
7. TPI test key areas
Concept: TPI (Test Process Improve)-Test process improvement is a reference model for test process improvement based on continuity representation. It is developed on the basis of software control, testing knowledge and past experience.
Role: The TPI model is used to support the improvement of the testing process, including a series of key domains, life cycles, organizations, infrastructure, tools and technologies, and can be used to understand the maturity of the testing process within the organization.
8. Quality metrics
Concept: Software quality measurement is a means of measuring software quality.
It is implemented from several dimensions: product completion, product quality, test completion, R&D process quality, plan deviation measurement, and product quality trends.
9. Defect data measurement analysis
Concept: Defect report produced in the form of quantitative analysis.
Content: defect arrival rate, defect removal rate, defect distribution rate, defect repair rate, defect repair round statistics, defect effectiveness rate, stage defect distribution, defect type distribution, and test activity defect rate.
10. Project quality monthly/weekly report
Monthly project quality report: summarize the project in monthly form. Including test completion, product completion, product quality, R&D process quality, task plan deviation, and quality trends.
Project quality weekly report: summarize the project in a weekly format. Including task progress, risk analysis, test resources, use case execution, requirement coverage, and defect summary.
11. Test engineer competency assessment form
Concept: Used to assess the ability of testers at the end of the year, ratings, promotions and salary increases, etc.
Assessment dimensions: professional ability, business ability, professional quality, and management ability.
12. Year-end report
Concept: At the end of the year, it is necessary to summarize and report on the overall work of the year.
Content: Project overview, work performance, highlights and shortcomings, and future prospects.
If you need information, leave a message and pick it up~