Project establishment and requirements review of software testing

  Matters related to project approval in practice

  • Introduce the project situation, the current project approval stage, project market forecast, project time discussion

  • Resource situation: need manpower, material resources, technology, tools, generally used development languages, tools, testing tools, tools needed in system operation

  • Departmental situation: Participating departments, main persons in charge, as long as the department has responsibilities, the main work content in the later stage

  • Documents related to the project: instruction documents, technical documents, project introduction documents, etc.

  • Project milestones: development start and end time, test start and end time, release time, details may have staging time, etc.

  2. Small program project establishment meeting

  • Project Introduction: Project Introduction Document

  • Test team personnel introduction: development manpower, how much, how much test manpower

  • Test Team Module Assignment: Modules are assigned to people

  • The test team prepares for testing related matters: tool preparation, equipment preparation, recruiters, etc.

  3. Project Rules

Make different rules according to different projects, such as:

  • 1. Mailbox configuration: It is convenient to communicate and record with different departments and colleagues at work

  • 2. How to deal with problems encountered in the project, such as what department to look for, introduction of the person in charge, and contact information of relevant development personnel

  • 3. Timing in the project

  • 4. Mailbox usage rules: such as the precautions for sending emails, titles, leave requests, attachment commands, etc.

  4. The tasks of the Songqin project testing team at this time

  1. Prepare test-related equipment, tools, and manpower arrangements;

  2. Familiarize yourself with the system when the product comes out, such as drawing a functional module diagram. If it is not out, study the project-related documentation, such as the project introduction;

  3. Complete the relevant tasks in the project, such as completing the mailbox configuration and confirming that the mailbox can be used normally. Including display name and sender name settings.

  1. Matters related to project evaluation in practice

1. Review concept

Requirements review is a review of product requirements documents. Requirements documents are abstracted and refined into product requirements based on the needs of users. It is also a relatively intuitive requirement document for our technicians. Through this document, technicians can understand what kind of product the user wants. It is a bridge for communication between users and technicians, so its review is very important.

From the perspective of the standardized process, any document submitted in the project must be reviewed, but in actual work, some documents will be used directly without review, and will be modified, updated, and maintained during use. The method used in the review is generally peer
review

2. Evaluation objectives:

First: The product requirements document can comprehensively and clearly describe the functions and performance of the product;

Second: The project team members have reached a consensus on the understanding of user needs;

Third: Form a final document that has a guiding role in research and development, and follow-up work must be carried out based on this document.

3. Review process

①.


②.


4. The objects of review include:

  • Concept Phase: Product Requirements Specification

  • Planning stage: system plan, project plan

  • Development stage: detailed design, unit test case (scheme), integration test case (scheme), code, database script, etc. Generally speaking, before starting coding, a detailed design review should be conducted to ensure the correctness of the program and reduce the adverse effects of subsequent modifications

  • Verification phase: system test plan, system test scheme, system test case

  • Release phase: installation documentation, usage documentation

5. Principles in the review:

  • Checklists are used during pre-audits to avoid situations where deficiencies are found without knowing where they are recorded.

  • Avoid over-reliance on checklists.

  • Review meetings should be limited to 2 hours to avoid lengthy discussions that diverge from the topic of the review meeting.

  • The object of the review is the product, not the producer (author), so personal attacks on the author himself should be avoided.

  • "Sharpening a knife does not cut firewood by mistake", it is necessary to provide enough pre-trial time for the reviewers, generally two days in advance is better.

  • Postpone the meeting if any attendee is not ready; reschedule/cancel the review if someone is really unavailable

  2. Small program project requirements review

  • Since the requirements document provided by the applet does not provide much content, only the provided requirements are reviewed

  • The pre-review mechanism is adopted, and the requirement document is issued first, and the testers study and fill in the review form

  • Conduct a review meeting to confirm and give feedback on the submitted issues. Including: check whether the submitted content is standardized, whether the submitted content is correct, whether it belongs to the problem of the requirement document, and after submission, the product or author should make corresponding treatment

  • After the end, arrange further familiarization with the system:

        ① When there is no product, refine modules and function points according to the requirements document

        ② When there are products and requirements documents, combine the two to extract modules and function points

        ③ When there is no requirement document and there is a product, refine the modules and function points according to the product embodiment

  3. Interview questions related to needs assessment

  • What is a needs assessment?

  • Why conduct a needs assessment?

  • Needs review participants?

  • What are the characteristics of a good requirements document?

  • How is your company's needs assessment carried out?

  • What should be paid attention to in the evaluation?

  • Did you encounter any problems from the start to the end of this review activity? How did you solve it?

  • How to improve efficiency in evaluation?

  • In today's rapid iteration, how to maintain requirements documents

  • Did you make a valid suggestion in the review? What was it?

  • How many times have you conducted a needs assessment?

  • How many versions are there in your requirements document?

  4. Tasks of the test team at this time

  1. Continue to prepare and test related equipment

  2. Familiar with testing related technologies, such as interface, automation, tool usage

  3. Conduct requirements review and confirm the content of requirements

  4. According to the requirements document, familiarize yourself with the system, refine the function module diagram and function points, and then refine it to the test point.

Note: At this stage, the task of the test team is to be familiar with the system, and the more familiar with the subsequent use cases, the better it will be covered.

Thanks to everyone who has read my article carefully. Seeing the fans’ growth and attention all the way, there is always a need for reciprocity. Although it is not a very valuable thing, you can take it away if you need it:

① More than 2,000 Python e-books (mainstream and classic books should be available)

② Python standard library information (the most complete Chinese version)

③ Project source code (forty or fifty interesting and classic hand-practice projects and source code)

④ Videos on basics of Python, crawlers, web development, and big data analysis (suitable for beginners)

 

  ⑤ Python Learning Roadmap (Farewell to Influential Learning) 

The information in the above picture is in my QQ technology exchange group (technical exchange and resource sharing, advertisements come in and break your legs)

The free information in the group is the essence of the author's more than ten years of testing career. There are also fellow masters to exchange technology together.

Guess you like

Origin blog.csdn.net/m0_59868866/article/details/123134686