Advance medicine

The reading time of this article is about 10-30 minutes. I suggest you browse the general outline first. Many of the details may not be universal, but I want to guide you on why you do it, rather than set a template.

The content is that all the test students and the boss participate in the integration, which has been recognized by various functions of the company. At present, we have been preaching and piloting to some teams, and will constantly optimize the whole process, hoping to form a good team cooperation mode.

From the point of view of content, it is a large and complete output. It is suggested that different students use it flexibly and develop appropriate processes and norms according to different teams.

preface

With the rapid development of the Internet, enterprises in order to compete for the market and rapid iteration, followed by agile, testing, automation and a series of standardized birth, in order to ensure that the project in high-speed iteration can still maintain good quality and team cooperation;

Once there is delay in the upstream, the project will compress the test time without delay, resulting in bug writing in the morning and release in the afternoon, which is more and more common.

In this environment, the tester is under great pressure, even out of breath, and once the bug is released, the problem will be attributed to the test did not find the problem, leading to more and more tired in the mind of the staff, in other words, the staff do not feel happy;

And this situation, often in small companies will be more obvious, because the process is not clear, all kinds of non-standard, product inserts demand and so on, unfortunately, JB also encountered, as said above, disorderly priority, delay is common, the boss looked, what, delay again? What the hell! Don’t test, iterate quickly, and then blame the test, how so many problems, etc.;

As a spring, being pressed for a long time, it loses its elasticity. Accustomed to it is a terrible word. Once accustomed to it, it is numb, and people gradually lose their passion.

In order to change this situation, the test team and the boss (technical director) also want to change this situation, so there is the following content, mainly to develop a series of project process specifications, reach consensus with each function, strict and orderly;

What to do?

Since the boss is in favor of doing this, why don’t you think about what to do?

A common project flow would look like this:

• Requirements document;
• Review;
• Workload assessment;
• To formulate project plans and approve projects;
• Development;
• Measurement;
• Test;
• Delay & requirement change;
• Acceptance;
• Online;
• Post-project;
• Online problem follow-up;

It seems, roughly, that’s the process, nothing wrong with it;

But is it enough? But think about it from a project perspective;

After a brain burst, there are many details, such as:

• Responsibilities;
• Meeting efficiency;
• Mail;
• Ask for leave.
• Team spirit;
• Office naming;

Anything else? There must be, just did not think of it, but after all, you are not a professional project manager, that first think to fix first;

According to the above, there will be several pieces:

Project iteration process, division of responsibilities (for projects and products), team consciousness, meeting, email, leave, communication tools (such as a nail, a letter);

sum

Project Iteration process

1. Product manager establishes confluence version directory; New projects build new space first; All documents are stored in accordance with document organization specifications; 2. The product manager collects the requirements of all parties (operation, customer service, etc.) and writes a demand summary table, including a demand overview (one to two sentences) and priorities; 3. Requirement documents: in accordance with the order of the general table of requirements, each requirement should have the same level of detail and priority; During the writing of requirements, designers do the preliminary design simultaneously; 4. Responsible person review: feasibility and resource availability (manpower, server, etc.) will be reviewed by the r&d and testing supervisors; Simple needs don’t necessarily require meetings; 5. Designer’s first draft: the first draft should be made before the overall review due to client or front-end participation requirements. During which the designer has the opportunity to first address defects in the product documentation; 6. General evaluation: all students who actually participate in the project will participate. Find defects as early as possible; 7. Workload assessment: time length and dependency of each function shall be given and summarized to the project manager for scheduling; 8. Scheduling and project approval: The project manager sends an email containing all the information; The designer annotates the cut diagram; 9. Development and design review (generally not required for requirements less than 10 working days, the specific judgment by the R&D supervisor); 10. Test case review (generally not required for requirements less than 10 working days, specific judgment by the test supervisor); 11. Development and test; 12. Testing: Prepare smoke test cases for development. Write test report for each round of test; Anyone can report a bug; 13. Delays and requirements changes; 14. Work overtime; 15. Acceptance and launch: after the release, the operation and test will be followed by a round of smoke test or continuous monitoring, and the launch will be completed only when the standard of high volume is reached; 16. Conclusion: data analysis, review, project manager summary and email; 17. Online fault;

Special version process

A special version is characterized by an independent version of the project, not following the requirements of the version iteration; Create a folder in the root directory of the project space to store project-related content. Once you have determined which version is available, you can move all documents to that version’s directory.

The specific process specifications should be as consistent as possible with the version iteration process.

Division of duties

The product manager is responsible for the results, the project manager is responsible for the transmission of information, and the functional leaders are responsible for the process.

The core role of the project manager is the information hub, and the main responsibilities are:

• Develop and optimize project process specifications;
• Collect workload assessment, schedule, confirm milestone time, hold project approval meeting if necessary, and finally send project approval email;
• Presiding over the closing meeting;
• Resolve team resource conflicts, prioritize projects and coordinate human resources;
• Identify areas where teamwork can improve productivity and promote solutions. For example, building axure preview space for products;
• Send out weekly mail;
• Supervise, summarize and provide solutions to the team’s problems;

Product Manager:

• Ensure that the requirements pass the review, be confirmed by all parties, and announce the project;
• Collect requirements from operation, business and customer service, make requirements documents and arrange them into version iteration;
• After receiving the feedback from customer service, the bugs will be transferred to the test for follow-up, and the product suggestions will be replied uniformly. If necessary, they will be dealt with and inserted into the iteration plan of each version.
• The final decider of the release, even if there is a problem, can release only if the product agrees;

Team consciousness

1. Goal-oriented, not doing tasks for task’s sake; 2. All rules are not dead. What is needed and what is not should be judged in detail. 3. Prioritize everything. If you don’t know, ask your boss, right up to the boss. 4. Timely feedback, and inform the people who should know; 5. Teamwork: 60 out of 100 if you wait for others to improve; 6. Once the project arrangement is settled, it is a commitment, and whether it can be fulfilled is the embodiment of professional quality;

The meeting

1. The host should do a good job of time control, try to finish the discussion within an hour; 2. To state the objectives and agenda of the meeting; 3. Write notes as required: contents and conclusions of discussion, problems to be followed up and responsible persons; 4. Attend the meeting on time, and inform the host to ask for leave if he/she cannot come or is late; 5. On the premise that there is a notice 2 hours in advance and the red envelope will be given to those who arrive late without asking for leave, the meeting host can ask those who arrive late without asking for leave to give a red envelope, the total amount is X yuan per participant;

mail

1. When to send: matters needing follow-up and follow-up review; 2. It is recommended to use Foxmail as the client, or directly use Dingding; 3. The subject line of the email should be concise and to the point. If urgent, write [Urgent], [Project Weekly report], [Test Weekly report], and so on; 4. Address: Write clearly to whom it is addressed, “Dear All” to All; 5. Have a signature line, or at least your name; 6. Cc: your boss and the boss of the person involved (up to the department level);

nailing

1. Set up a group for each project, involving all the actual participants and supervisors at all levels; 2. Don’t set up small groups to discuss projects. Don’t be afraid to disturb others as long as it’s business. Only for non-work discussions, such as afternoon tea groups.

Ask for leave

Make sure your boss knows. If you have important tasks on you, let the project team know.

Morning session

When the project is rapidly iterated, morning meetings are required to quickly synchronize information and understand the progress. If there are problems, they will be raised in time so that the corresponding person in charge can promote them and avoid all risks of delay.

In the morning meeting feedback, skills are needed, which cannot be: XX function progress is normal, according to the original plan;

We need feedback on what we have done, the progress of the work, and when it will be completed. This is not a project, but the smallest function should be broken down, such as:

Yesterday, we did the upgrade function, and the interface and interface joint adjustment has been completed, with 60% progress. Today, we will carry out the development of anti-hijacking function and self-test, and the development will be completed within today.Copy the code

summary

See here, do you feel very tedious? You want to do all this stuff? Yes, the most seemingly trivial things are often the most important. In the Internet age, everything is about efficiency and user experience.

Let’s go through each of the dots in the project iteration process.

Document organization specification

The general

All files are managed by the Confluence (cf for short). Items inconvenient for CF are stored in the SVN only.

The project team’s nail bulletin board only places cf links on the version page and the test record of the current version.

CF specification

Each project has a space created by the product manager or project manager.

The catalog specification is as follows:

• The home page
• • General documents, including third-party documents, global glossary, and global information (test server address, SVN address), are not associated with the specific version.
• • Special documents, cross-version requirements coordination, operation activity requirements unrelated to version;
• • X.X.X (version number, divided by specific version)
• • • Demand summary table;
• • • 2. It can not be a separate document, only exist in the mail or pin bulletin board, or reply on the requirements summary document;
• • • Each requirement document is named after the requirement name. If using Axure, fill in the SVN address here, and also include the URL address of the preview space;
• • • Test documents, named after the function, mainly use cases, can be SVN. The test report only exists in the mail, and if you don’t mind, you can reply to the document in the requirements summary table.
• • • Post-project. This has to be, it can’t just be in the mail;
• • Trash can (move discarded requirements, no longer used third party documents, etc.)

SVN specification

The catalog specification is as follows:

• The root directory

• • Small program (divided by product form or specific business, you can choose)
• • • A project
• • • • Design document
• • • • Interface documentation
• • • • Testing tools
• • • • X.X.X (version number)
• • • • • Requirements documents (Axure source files and exported HTML folders, Word for each requirement, named after the requirement name);
• • • • • Design document
• • • • • • Ps source files, design draft, notes, cut drawings
• • • • • Test documentation
• • • • • • Xmind, Excel use case sorting
• • • B project…

Table showing the demand

Table format

Name of demand	priority	product	UI	The front end	The back-end	test	operations
A demand	The core	JXX, BXX	JAX	BAX	JBAX	JXX	BXX
B demand	high	AXX, CXX	EAX	DAX	FAX	EXX	IXX
A demand	The core	JXX, BXX		BAX	JBAX	Free test	BXX

Column to fill in

• “Requirement Name” and “Priority” are filled in by the product.
• Requirement name: 1 sentence only. If this is not possible, the requirement is not clear;
• Sort by priority. Priority description: core: must do, do first, can not cut, not finished will not release a new version. Can form a separate round of lifting test. Gaew: Must do. If conditions do not allow, you can lower the priority to medium. Can form a separate round of lifting test. If there are multiple high priorities, the product continues to be segmented; Chinese: If time permits, will do; Low: can not do; Priority can also be expressed by scores, such as core 100, high is 99-90, so as to fully reflect the needs of the higher priority in each high priority;
• The list of personnel in each function shall be decided by the corresponding supervisor and can be filled in by anyone. If there aren’t many people, it’s better to write it off the table;

Execute instructions

• The product should write the general table first and then write the requirements document. The perfection degree of the requirements document is consistent with the priority of the general table. The requirements with low priority can also be improved in the process of core requirements development.
• What is a need? (Become a row in a table)
• • Not associated with other requirements;
• • Where multiple people can be developed in parallel with other requirements, there is no crossover;
• • With the same priority and belonging to the same module, merging is allowed.
• • Important bugs can be listed as requirements;
• • Operation and maintenance work is independently calculated as requirements;
• The whole project team works on priorities. Core and high priority can be completed and tested one by one;

The requirements document

Front that

The title of the document is 1 sentence, as in the requirements summary.

• Basic requirements of requirement description: clear, logical, professional words, standard format, easy to read, key words and sentences marked in red;
• During the overall review, the requirements document should be the design draft, not the prototype drawing, to avoid a large number of inconsistencies between the design draft and the prototype drawing during actual development/testing;
• If it is a complement to an old requirement, copy the old requirement to the new version, add the revision record and mark the changes.

Writing ideas and the design principle of this template

Please refer to www.woshipm.com/pmd/1579154… This article is the company boss in everyone is a product manager published in the article, has been recognized by the product manager;

The actual example, you can refer to www.woshipm.com/evaluating/… But please pay attention to flexible use, this article is from everyone is a product manager article, is a relatively comprehensive article;

Revision history

version	The date of	Revised one	Revise the content
V1.0	18.9.27	jb	).
V1.2	18.9.29	jb	Requirements review, modify XX function
V1.3	18.10.28	jb	Requirements changed because the original functionality could not be implemented
V1.4	18.11.01	jb	1. Add XX functions and 2. Modify XX copywriting

The target

Including but not limited to the following:

• What problems and pain points to solve;
• How much utilization and conversion rate the demand itself achieves;
• How much can this demand increase PV, UV, transaction volume, etc. (Desensitization is required to write percentage, not absolute value);

The main purpose is to prevent brainless, head demands, everything should be driven by data, rational, so that the team knows the purpose of doing this, but also to avoid wasting resources without good results;

The glossary

The term	instructions
Automatic payment	.

What should be listed in the glossary?

• No title of the page, area, how to unify the internal name;
• The name of the new feature;
• A special name or code;
• Abbreviations for some processes;

Before when I was in charge of SEO project, it happened that the same function, product, front end, test, UI have different names, resulting in communication costs;

The resources

(Put the associated requirements and third-party documentation here, there is no need for this part)

Product structure drawing

Tentative new projects must need this chapter, the reason is product structure takes time, in the case of product iteration so fast, may function are changing each version, considering the human cost, make each product version also impossible to maintain, because first requires a new project need, iteration of the project, act accordingly, can have is the best;

Prototype and specification

• If you use Axure, don’t post the axure screenshot. Here you can directly put the SVN path to export the web page. You can also put a link in the HTTP space, so that you can read it online and avoid looking for documents.
• If the whole requirement can be explained in simple graphics, don’t use Axure and write it in CF.
• It is not mandatory to draw flow charts and state tables, as long as they can be expressed clearly and completely, any form is ok;
• Requirements for a mix of front-end and client side should be marked as which side is implemented;

Nonfunctional requirements

• performance
• statistical
• security
• Compatibility: system (iOS8, Android4.4), resolution & size (4.7-inch, aspect ratio > 19:7 screen), browser (Chrome, Internet explorer, firefox)

Requirements review and workload assessment

Two rounds of review

Process:

• Pre-review: 2 hours in advance of the product notice and the first draft (no need to perfect the details, can only be the prototype), convene the supervisor or person in charge of pre-review; It doesn’t have to be a meeting, as long as everyone can make sure there’s no big problem with demand.
• All review: product notification and demand link will be sent one day in advance (the designer has finished the preliminary design drawing), and all staff will attend; Most issues should be examined before the session, not after; The meeting is just to check and fill gaps;
• Operations-related requirements should be reviewed by operations prior to general review;
• After the product manager revises the problem, contact the responsible person one by one for confirmation.
• After all pass, send a notice notice;
• The project manager collects workload assessment for scheduling, and sends project approval emails after confirmation by all parties;

Requirements:

• All reviews should not be carried out before the launch of the last version, and enough time and energy should be given to participants to do a good review;
• If there are too many problems, another requirements review should be held.

pre-trial

The core role is to say hello to development, to know what to do, and to arrange human resources. So the product documentation doesn’t have to be perfect, but it does have to be clear about the goals and core function points.

Call in the development test supervisor or person in charge for a brief review, mainly to review the feasibility.

Conditions that do not require prequalification (drive-by test) :

• The development workload is less than 5 working days;
• UI based, no difficulty;

What will the review be about?

What everyone has to comment on:

• Whether the goal is clear; Whether the design of requirements is reasonable for the target;
• For demand: imperfect place, scope of influence, user experience; Try to identify requirements before writing code;
• Specific workload;
• Time arrangement: limited time line cut demand, not limited time by everyone to decide the release time;
• Risk points: all possibilities leading to inaccurate assessment and project delay;

With particular attention:

• The feasibility of the technology should be evaluated, and the difficulties affecting the development time should be pre-studied;
• Testing evaluates the adequacy of test resources (such as test equipment) and the feasibility of automated testing;
• Operation and maintenance to evaluate the adequacy of server resources;

Workload assessment

Each function is evaluated on a need-to-need basis.

The minimum unit is 0.5 man-days.

A measure of combat effectiveness:

List all the people involved in the project. For the sake of description, let's call the most competent or efficient person A. The amount of work A can accomplish in A day (excluding overtime and nap time) is defined as one man-day, and A's combat effectiveness is set at 1.0. This demand will take several days to complete according to A's standard, so its workload can be quantified as how many man-days. Then compare other personnel with A one by one for evaluation. If B can finish 70% of A's workload in A day, B's combat effectiveness is set as 0.7. If C still has combat effectiveness 0.5, the team's total combat effectiveness is 1.0+0.7+0.5=2.2. If a requirement is 11 man-days, the best case scenario is that the team needs 11÷2.2=5 days to complete it. The more people you have on a team, the more time you spend communicating. In addition to the possibility of inaccurate assessment, departmental meetings, temporary leave, when estimating the time required by the whole body, should be multiplied by a coefficient, such as 1.2, as the final time. In the preceding example, 5×1.2=6 days. Similarly, if we want 996, we can multiply it by a coefficient less than 1, which could be 0.85. In practice, not all team members work full time on the project, and it is common to work on multiple projects at once. If A only invests half of the time in this project, the total combat effectiveness of the team should be calculated as 1.0×0.5+0.7+0.5=1.7.Copy the code

Designer process specification

Front that

• Only the norms that affect cooperation are concerned here. The standards related to “good looks” are the professional norms within designers and are not involved here.
• Programmers expect designers ability, may refer to https://www.zcool.com.cn/article/ZODIyODM2.html

Design specification

The goal of pre-review is to allow the owner to evaluate the feasibility of the design by focusing on the location, shape and interaction of the style, regardless of whether it is a prototype or a design draft.

The goal of the overall review is to allow the development to accurately assess the workload. Things that have minimal impact on the amount of work can be non-final, such as color values, font sizes, spacing.

The final draft can be determined before the actual code writing of each requirement, allowing fine tuning without test regression in the acceptance stage, and the need to remember the synchronization back to the design draft for face to face debugging.

Cut the figure specification

• Designers maintain all the pictures themselves, every time is to develop all the cut images (including new and discarded), and the same picture or a small change but in the original picture file name unchanged, they know which pictures are not needed in this version;
• All source components are not uploaded to the SVN in split versions, and all the things currently used are saved under each version.
• The cut diagram file is named according to the specification, all lowercase English, underlined;
• The width and height should be even;

Whether or not transparent margins should be applied to some components in the cut diagram and the corresponding annotation should be uniform.

Mark specification

• It is better to have global specifications;
• The font size for Web projects should be no less than 12px and for APP projects no less than 10px.
• All sizes are even;
• If the mark is not easy to explain, text explanation should be used;

Naming conventions

For naming conventions of UI files, please refer to the following:

Scheduling and project approval

terms

• A significant time point, such as a test or release. From milestone. Risk point: any items that may cause project delay shall be approved: after core and high-priority review of all requirements, the project manager shall collect the workload, risks and required resources of each function, negotiate the milestone time and send an email.
• Each round of lifting test is called T1, T2, T3, t = test;
• The modification submitted in each round of test is called patch;
• The third tag in the second round is t2P3.
• Fully functional test: all requirements to be online in this version are done, and the UI can be accepted in advance;

For launch, many large companies are called RC1, which stands for Release Candidate. This stage is mostly used to integrate the post-beta version.

Generally, different processes are named as follows:

Beta, RC, Trial, Release, Patch, hotfixCopy the code

Project scheduling

Schedule objectives:

• Functional dependencies and timelines for each requirement, such as front-end dependencies on THE UI and back-end, and when the dependents will finish;
• It can be divided into several rounds of test. The time point, test content, “core” and “high” priority requirements of each round can form a round of test.
• Release time;
• Risk points;

Example milestone scheduling:

• T1:11.2, requirements A and B. UI is provided before 11.1, and the back-end interface is prepared before 11.1.
• T2 (full function) : 11.5;
• T3:11.7;
• Released: 11.8;

Possible risk points:

• Participants are not familiar with business;
• Long vacation before and after, low work efficiency;
• Staff leave;
• Third party services or policy factors;

Version management

Version number format: X.X.X.

• I have a new demand, position 2 +1, position 3 0
• Big revision, the first position +1, the second, the third position 0
• Minor bug change, +1 for 3rd position

Project email

Recipient: Project team Nail Group

Title: [Project Approval Notice] XXX (project) Y.Y.Y (version), for example [Project approval Notice] XXXX product 3.2.4

Body:

Dear All, this project consists of 5 core and high-priority requirements, and 3 middle-low priority requirements. Twelve people are involved in the actual work. Please refer to the general table of Requirements [URL] for details. Project period: October 4th to October 18th, a total of 10 working days Milestone: 1. T1: October 12th (Wednesday). Propose and test requirements A and B. UI given by 10.10, back-end interface ready by 10.11 2. T2: Oct 13 (Thursday) 3. T3 (full feature) : Oct 18 (Tuesday) 4. Released: October 20 (Thursday) Risks: 1. New students join requirement A and are not familiar with business, which may prolong bug solving time 2. Requirement B requires technical pre-study, so the reserved time may not be accurate. Please report the progress at any time. The third party partner XXX will conduct data migration in the middle of the month, which will affect our connectionCopy the code

How to do version planning

Demand pool, correlation degree combing, disassembly, priority assessment, iteration cycle, special;

Purpose of version planning

In modern society, with the rapid change of market and demand, product managers make product planning with short iteration cycle, and timely adjust the demand function and product form of the next iteration according to the feedback of the market to meet the company’s strategy and business needs;

Demand pool

Before product design, product managers will create a demand pool to collect all kinds of requirements, avoid missing requirements and facilitate the sorting of requirements. Managed and maintained by product manager, supplemented by project related personnel; Regardless of whether the requirements are feasible or not, project related personnel can fill the requirements into the requirements pool, and there is no limit on the number; In the process of demand sorting, product manager can analyze and select from the demand pool; There are two ways to create requirements pools: document forms and OA systems. The form may contain the following:

• Requirement Name (Mandatory) :
• Requirement Description (Mandatory), which describes requirements in detail and is classified as follows:
• • User requirements: features that users want;
• • Business requirements: money-making features;
• Requirement type (optional), including the following categories: New features, feature optimization, Bug fixes, and experience optimization;
• Sources (optional), including the following categories: strategic planning, competitive product analysis, user needs, operational market feedback;

Need to comb

After collecting product requirements, the product manager analyzes the requirements in the demand pool and sorts out the functional structure diagram of the requirements to provide direction for product iteration. During requirement analysis, you can perform the following operations:

• Requirements merge: Combine requirements of the same type.
• Requirement deletion: screen out unreasonable requirements that do not conform to product positioning.
• Requirement correlation: Sorting out the dependencies among requirements,
• Requirement disassembly: disassemble requirements into realizable functions one by one to form a structural diagram of requirements function, which can be expressed by brain diagram;

Requirements priority assessment

The assessment of requirement priority is that the product manager arranges the priority requirement functions with limited resources (time, manpower and hardware), so as to achieve the phased goal of the product and meet the value of the company.

Can be sorted by priority:

• Corporate strategy: core functions/business needs specified by corporate strategy that bring direct benefits to the company;
• Conducive to daily activity/new: can effectively commission user activity and user volume;
• Function optimization, Bug fixing and experience optimization: this category is mainly about user experience to improve product satisfaction;
• Improve operation and maintenance efficiency: reduce costs;

Iteration cycle planning

The iteration cycle is the time window from the beginning time to the end time of an iteration to complete the design, development, testing, online and other activities;

A fixed iteration cycle is a fixed time window, with the following benefits:

• Establish the team’s sense of rhythm: have the expected rhythm, easy to form the habit of the team, team production efficiency is more regular;
• Reduced collaborative costs: Ability to schedule planning, review, and other activities for multiple iterations in parallel. Everyone knows when these activities are taking place, reducing communication and collaboration costs;
• Simplify planning activities: fixed iteration cycle, fixed manpower and fixed output delivery are conducive to the rationality of product planning;

Short period: time window within 10 working days (two weeks); Long period: 10-20 working days (one month) time window;

According to the requirements priority and the actual situation of the team, the following factors should be considered in selecting the appropriate iteration cycle:

• Project cycle: short cycle iteration, quick feedback and improvement;
• Quantity of demand: the less demand, the shorter cycle;
• Uncertain factors: project team’s work efficiency, technical threshold, etc. The more uncertainty, the shorter cycle iteration should be used;
• Requirement priority change: frequently change priority and adopt long cycle iteration;
• Iterative system overhead: the time cost of each regression is high, and long cycle iteration is adopted.

special

A special project is a project that needs to be set up specially when it involves a large scope (multi-department cooperation, code reconstruction, and function optimization) and the time window exceeds a long period during project pre-review or requirement review.

The special project has the highest priority in all projects, and special personnel are assigned to take charge of the project, focusing on the current human resources to give priority to solving problems;

Special features:

• The UI/UX modification takes more than 10 working days.
• System code reconstruction;
• The time window is more than 20 working days;

How to do a good job:

• Adjust the priority of other projects appropriately, and assign human resources to participate in the project by the group leader;
• Special team members are only responsible for the current special work to ensure that the project is not interfered by other projects and completed on schedule;
• Project leader to promote regularly;

Product and UI collaboration specifications

When product managers describe a requirement function with multiple abnormal states, they highlight it in the product documentation with non-colored text or tables.

UI students in the drawing of hi-fi design draft, for different states to carry out the design;

It helps product managers to check and accept UI design draft for function points and various abnormal states.

Operational intervention requirements

Operation to confirm product requirements, functions and iterations in advance, to ensure that the current iteration is in line with the overall product planning, conducive to team synergy efficiency;

However, too many processes will cause the operation to fail to do its own work, so simplify the following processes:

• The product manager shall inform the operation department when formulating the product iteration plan. If the operation department has any objection, it can communicate with the operation department for timely adjustment.
• The product manager shall inform the iteration requirements of this version during the pre-review. If the operation has any objection, the product manager can communicate and make adjustments in time.
• During requirement review, product manager will inform project team members, including operation personnel, in advance to revise product documents, such as product documents, etc.

Development specification (to be combed)

The reason to be sorted out is that the development specification is the most internal at present and should have the lowest priority. Therefore, it is not considered for the time being and will roughly involve the following contents:

Code style specification API specification, data structure, documentation Git branch and log specification Review system External documentation specification design document: database structure, system design diagramCopy the code

Propose test process and test free standard

The rules

• The right front-end, client and back-end requirements are tested by the corresponding development;

process

• Develop self-test to ensure that the main path is ok. If the test group provides smoke test, it must pass the smoke test.
• Write down the tag and test focus of this test in the nail bulletin board, and update each version accumulative, do not cover the last content
• If the quality is not good, the test can be played back;

Sample test notification

(Refer to schedule and project approval for term explanation)

Front-end T1 2.3.3/1803031104 has been self-tested, automatic XX and UI revision front-end T2 2.3.3/1803041203 has not been self-tested, XX front-end T2P1 2.3.3/1803051404...... IOS T3 2.3.3/1803061203 has been self-tested, fully functional test back-end T1 1803061203 resolved XXX issueCopy the code

Patch submission frequency is in days. It is not recommended to test a patch to solve a bug. If it is really necessary, the development and testing students should complete the one-to-one verification, and then test the regression of multiple problems when issuing patch.

Front-end, back-end, applets, H5, etc., if there is no tag concept, use the current date;

Back to

Standard:

• The test environment is not well matched (the deployment documentation is not provided with the code for the deployment environment);
• The main path cannot run;
• Develop failed smoke test cases;
• The development does not indicate the test focus and the influence scope of the modified code;
• Failed to provide relevant database design documents and interface design documents;

Notice:

• Nail nail group @ all people to notice, explain the reason;

Avoid measurement standard

The premise of the no-test is to confirm that the test is known, and then the following conditions:

• Change only UI layout or copywriting, not interaction and business;
• Just change the background report statistics;

The test report

Writing principles

• The ultimate goal is not to deliberately find fault, but to let managers know which links have problems, can make timely adjustments;
• Reflect quality, not requirements or business;
• Quality problems should be specific to functions or people; There can be no ambiguity about who is responsible;
• Record the test means to find the basis for the missed test of on-line fault;

Mail template

Addressee: nailing group of the project team cc: test group of nailing group title: “test report” XXX project Y.Y.Y (version) [in the first round z | release], for example “test report” jb 1.2.1 t1 project

Body:

Dear All, 1

Results: [by | conditional by | back] failure; [Reason for conditional approval] : The product agrees that some bugs do not affect the release, and has known the risk of the problem and agrees to solve it next time;

(One or two sentence summary of project quality) For example: The development is significantly better than the last release, with fewer requirements changes, give everyone a thumbs up!

Number of remaining problems: X.

(If not, it will be listed directly below, with hyperlink to the URL of Zen Path)

2. Quality report

Quality indicators:

• Changes in demand: 10; increased workload: 20 person-days;
• Test case pass rate: 76%;
• Bugs total: 108;
• Performance indicators: average API interface response time: 400ms;
• Compatibility: No compatibility problems were found in the test equipment (see procedure record for list);
• The number of patches tested in each round;

Bug distribution: A series of pie charts, number and percentage. Dimensions: responsible person, person reporting the bug, error cause, severity, solution time, abnormal state (call back and reactivate);

After this round of test, the bugs in the unclosed state are distributed among the responsible persons:

3. Process records

Requirements and tester reference project documentation :(url)

Case Information:

• Unit: 76;
• Type coverage: functional testing, interface testing, interface automation, compatibility testing, performance testing;
• Automation case added 3 interface monitoring;

Test environment:

Mobile phone Model:

System Type and Version:

Browser type and version:

• Windows Chrome Version 69.0.3497.100 (Official Build) (64-bit)
• Mac Safari Version 12.0 (13606.2.11)
• IPhone 7, iOS 11.3.2 Safari
• Mi 6A, MIUI 10.2.2 system browser, UC browser V12.3.3.2342

Bug system usage specifications

A report specification

Assignment:

• Assign directly to the person you know, or test person first;

Module:

• Try to choose the right one, different modules may notify different person in charge;
• If you do not know, choose other, and then modify by the test leader;

Title:

• A word summary of the wrong location, phenomenon; Or suggested practices;
• Think about the keyword you’ll use to find the bug. This keyword should be in the title.
• The title can be used as [] to contain important content, such as [novel] novel module cannot be loaded;

Repeat steps:

• Explain what the phenomenon is and why this is a bug;
• You can add a description of what you want to fix, not to mention if it’s obvious;
• UI display problems or unclear text problems, screenshot description, if necessary into GIF or screen recording;
• Questions that are triggered only in specific circumstances and contain test data, for example:
• • Account password;
• • App project operation path, such as home page -> Information square -> click the first -> white screen;
• • The URL of the Web project;
• • If you think there may be a compatibility problem, write reproduce conditions, such as mobile version, system version;
• • Any other information that may assist in reproduction;

Severity classification criteria :(currently zen tao corresponds to 1, 2, 3 and 4)

• Critical: crash, blank screen, 404/500 error; Business errors, flow impassability, missing of major functions, data calculation errors, performance;
• General: minor function error, missing; Data length; Interface styles affect usage
• Minor: Interface style problem but does not affect use
• Optimization suggestions: Poor experience; Too slow

Priority classification standard, product manager has the highest decision on priority :(currently zen tao corresponds to 1, 2, 3, 4)

• Solve the problem immediately: The test cannot continue until the problem is solved.
• To be resolved in the next test: default;
• Solution before release: relatively independent, no impact on other functions;
• Solution in the next version: no serious impact on users, but difficult to solve, may cause project delay;

It should be noted that generally, serious problems are urgent, but the probability of occurrence and impact of the problem should be considered, so that there may be serious but not urgent, and emergency is not serious.

For example, if the logo on the startup page is wrong, although it is not serious, it will affect the company's reputation, so it is urgent; A function flashes back, but only in extreme cases. Considering the repair cost and impact, it may be serious but not urgent.Copy the code

Use standard

• When transferring to others, consider adding a note;
• Timely solution, product bugs added to the requirements pool or other places recorded as solved;

Matters needing attention

Never report a requirement as a Bug. Before reporting a Bug, understand the difference between a Bug and a requirement:

• A requirement is a description of a thing, what the user is, how he wants it, what the purpose or value of doing it is;
• Requirements You need to build user roles, describe usage scenarios, and define user issues.
• A Bug is a hidden or discovered functional defect or Bug in a program. Simply said is the use of software, error problems;
• Bugs need to describe the recurrence steps, environment, and other factors in order to locate the problem;

This is not to say that requirements cannot be expressed in the zen way, but hopefully they can be distinguished in a better way, such as heading [requirements], selecting corresponding modules and optimization suggestions, and assigning them to the product manager;

Delays and requirements changes

delay

In case of delay risk, the project manager shall be informed in time, and the project manager shall organize each person in charge to confirm whether to delay;

Finally, the project manager will send an email to list the reason for the delay, the revised milestone time, and synchronize the CF document.

Email title: [Project Delay] XXX Project Delay Description MMDD Dear All, the launch time of XXX project has been postponed from November 13 to November 14. The reasons for the delay are as follows: 1.Copy the code

Requirements change

Notification Rules:

• This must be reflected in the revision record of the requirements document;
• On the nail nail @ all notices. If the workload is more than 1 person per day, you must send email.
• Any changes that may lead to project delay must be confirmed by the product supervisor;

Contents of notice:

• How it used to be, what to change;
• Where the update document is;
• The specific workload affected;
• Project planning arrangement after impact;

Operation process

During the project execution, the project is expected to be delayed within 2 days, and a notice of delay will be issued after the evaluation with technical personnel; If the meeting exceeds 2 days or is postponed for 2 days, hold a meeting to discuss solutions and send an email to postpone the meeting;

For all postponements, specific and quantifiable reasons should be given;

Collective overtime system

Group overtime standards

• Timely launch can bring substantial revenue;
• External factors (government policy, third-party failure, etc.);
• Getting back on track when you’ve been delayed too long;

Group overtime shall be decided jointly by product and project, and shall be notified by email;

If the conditions are not met, it is not allowed to request the project team to work overtime at will, let alone the product or project to request overtime in private.

If an individual works overtime due to the fault of others, he/she shall decide whether to add overtime according to his/her own will. Not add is reasonable, project delay is in line with the process; If you choose to work overtime, it is the effort you have made for the success of the project, which is a strong basis for high performance. Make a conscious note of your contributions after working overtime, and list these positives when reporting.

notice

Email notification by project Manager, template:

Title: [Overtime Notice] XX Project MMDD Text: (Reasons for overtime, list of personnel, target)Copy the code

subsidies

For collective overtime work, the product or project can apply for funds to buy Saturday afternoon tea, which is about X yuan per person; If the leader agrees, it can be coordinated into a compensatory leave, different teams according to the actual situation, the afternoon tea subsidy must be there;

Acceptance, release and launch

Acceptance of the

Users of products, UI and background systems (operations, customer service, risk control, etc.);

Acceptance entry conditions

The next step at the end of the testing process is acceptance; The ideal criteria for entering acceptance is that all bugs are closed;

If time is tight, you can relax to meet both conditions:

• All bugs whose priority is “fix before next test” have been closed.
• No more than 2 bugs per person are fixed before release.

Test Environment Acceptance

• The test demonstrates the main process to the acceptance, in various forms, mainly to communicate clearly;
• The acceptor operates by himself, or allows the test to demonstrate more processes;
• UI check, mainly color value and pixel level size comparison you, naked eyes can see the difference, should be found in the test process;
• UX experience feedback;

Release and online acceptance

• The product manager announces that the test environment is approved, and the development is released to the production environment. The core personnel of each function are on standby to deal with the failure.
• After release, test and product go through the main process again, background system users should also do some operations to check or continue to observe the relevant data for a period of time is abnormal;
• The online acceptance standard should be released on Tuesday or Thursday morning as far as possible by the decision of each accepter, so that everyone has time and energy to repair immediately when problems occur.

online

After the production environment is accepted, it is confirmed that the volume can be increased, and the result is regarded as “online”;

Announced by the product manager, if there is no problem, the nail group can be said, if there is a risk, should send an email:

Recipient: Project team Title: [Online notification] XXX Project Y.Y.Y Body:... (Risk estimation) (Emergency plan)Copy the code

post-project

Post-project meeting

Time: three days after launch Host: Project manager or assistant Participant: All the people actually involved in the project, supervisor participate in the meeting as appropriate Preparation: Project to the host, prepare your own speech outline The meeting process is divided into two parts: Part one, summary of the results, speak in the following order:

• Project: briefly review the overall progress of the project, the amount of manpower consumed, the deviation and the reasons;
• Product: Online version related data (desensitization). The main purpose is to let people know the meaning of the fruits of labor;
• Test: briefly state the key points of the test report, highlighting the quality parts;

The second part, process summary, this part of the speech can be discussed:

Speak in the following order: Project -> Operations -> Product ->UI-> Back end -> Front end -> Client -> Test -> Operations;

Speech Content guidelines:

• The main purpose of things, not people, is to like and summarize how to do better next time.
• What improvements you or your partner have made and how the last problem was solved?
• What is wrong with yourself or your partner, and what solutions or suggestions do you have?
• Experience to improve work efficiency (communication style, working style, project arrangement, tool use, etc.);

Post-project mail

From: Project Manager or assistant Recipient: Project team Nail Group **, then the project weekly report can be sent ** title: [Final report] XXX (project) Y.Y.Y (version), such as [Final report] XX3.2.4 Text: Dear All, (There is no template at present, it is almost the meeting minutes of the closing meeting)Copy the code

Example:

The overall overview of XX small program vx. X is as follows: 1. The project plan of XX thunderbolt X.X is x.x-xx. XX, which is expected to consume X working days. The actual project was executed from X.x-XX.xx, which consumed XX working days in total and delayed XX working days. 2. After the launch of the mini program, a large number of people use the sharing unlocking and dynamic sharing functions. Subsequent products will further optimize the sharing function and explore users. 3. The total number of bug feedbacks in the test feedback of the whole project is XX, XX effective problems, X are not dealt with, X are postponed, and X are turned into requirements; Reasons for the delay: 1. The project was not developed until the middle of the project due to insufficient project staff; 2. After the requirement review, no technical feasibility analysis was conducted, leading to the difficulty of realizing some functions in the middle and later stages of the project; 3. Not having enough time to read the documentation carefully when reviewing requirements. There are many functional points hidden in the requirements, leading to inaccurate review time; 4. Failed to inform project members immediately when the product document was modified, which increased the communication cost; 5. During development, UI and requirement documents are not connected in series with back-end interface fields, which increases communication costs and R&D costs; 6. Large number of bugs, with 93 effective bugs and long repair time; 7. The message center function was adjusted in the later stage of the project, which took a long time to process; 8. There are problems in the coordination between the front end and the front end in the Bugfix phase, which need to be optimized; Solution: 1, XXXCopy the code

Form for

Online fault

The production environment is released and accepted. After confirming the volume, any bugs found are considered as online faults.

Reporting standards

What kind of online failure needs to be reported?

• Have a great impact on the turnover, such as unable to open the page, unable to buy bids;
• It has a great impact on users’ reputation, for example, functions cannot be used;

What does not need to be reported?

• Simple user experience or pure UI issues

Processing flow

• Whoever finds it should first report it to the test student;
• After the test confirms the recurrence steps, the bug will be reported to the development for solution, and the product manager will decide whether to release the fix urgently.
• After repair, the test leader will summarize the report of each function and send an email;
• The impact of product reporting on operational data;
• The cause of the development report error and the scope of impact (at the code level);
• Reasons not detected by the test report;
• The test organization discusses how to prevent the recurrence of such a situation;

The report mail

Principle:

Identify who is responsible (or just which function) and the type of error (code, requirements, communication, etc.) and write it explicitly in the report. Pay attention to the matter rather than the person; Have a solution and a clear follow up person;Copy the code

Example:

Recipient: Project Team Nail Group CC: Test group Nail group Title: [online fault] XXX Project A Month B day YYY problem body: (underlined indicates the example part, the real email does not have) Dear All, the phenomenon of this fault: white screen appears on the hash detail page, and the box "abnormal data" is always displayed. Duration: It existed at 14:30 on October 3, and was repaired by the back end at 18:00 on October 3, and the fault lasted 3.5 hours. Time of discovery: Customer service received user feedback at 16:00 on October 3, and found the impact: Users could not view and purchase the hashtag cause: back end...... Solution: Solve the code error can not find the fault earlier cause: the backend before the online code change without notice of the test and prevention plan: the development of the need to consciously, the development director to strengthen the publicity. The best solution is to monitor all Git commits, but this is currently too weak to execute;Copy the code

Project weekly

The principle of

• Something played nothing back;
• The project manager can hold a station meeting on Monday morning to collect information, and the responsible persons of various functions should actively cooperate;
• Send emails by 3 p.m. Monday;

Mail template

Subject: [Project Weekly report] XXX (project) MMDD (month), for example, Zhengxin Communication 1018 body: Dear All, (1-3 sentences summary) (Current progress, whether there are risks. Explain the abnormal situation and reason, remind attention, request assistance. This week the project progress is normal, according to the plan, there is no special situation to report. Project plan reference project documentation; This week's progress is basically controllable, possible risks: XXX will ask for leave on Wednesday, which may cause delay. The UI draft of XXX has not been released yet, and the designer is busy with other projects, which may cause front-end delay. Version 1.3.2 was launched on Tuesday, October 4th. Requirements for 1.3.3 are under review. The project is confirmed to be delayed by one day and released on October 28th, for the following reasons: For details, please refer to the demand change document/email for XXX to ask for leave temporarily. Ali Cloud server is faulty, the situation is unknown. @XXX is dealing with the online fault XXX occurred on October 5th. Yyy this week operating data :(desensitization by the product manager, there is a better chart) PV change within 5%, UV decreased by 20% within a reasonable range, should be related to the National Day holiday bid data up 30%, the total amount of trading up 50%, online new functions are very useful! XXX's operational requirements, the conversion rate is 7.8%, the effect is very poor!Copy the code

example

Example 1:

Hi, all, the progress of each XXX project last week is as follows: XXXAPP: vx.X version: R&D side: 1) There are X bugs remaining in BugFix, and the development progress is about XX%; 2) The development of XX function was completed last week, and it is planned to conduct joint adjustment with the client on Tuesday and Wednesday, and carry out test on Thursday; 3) The docking work of XX is confirmed to be postponed. The docking can only be done after the launch of XX. The initial date is early XX month, and the product has been known; 4) Considering the possible risks of XX, we decide to postpone this function to X.X.X to avoid project delay or risk due to XX function; Test side: At present, T1 and T2 have been tested. Both tests have been completed and are in the bugFix acceptance stage. Vx.x version: this version is a small version, mainly experience optimization (specific optimization content); 1) Product side: Requirements have been reviewed with testing, back end and UI. The front end is still busy with the VX.x project, so I have not participated in it for the time being. 2) R&D side: back-end, except version compatibility, other functions can be developed within this week; 3) UI side: the design draft has been provided; Vx.x: This version is a major one, adding XX functions. 1) Product side: Requirements have been reviewed with testing, back end and UI. The front end is still busy with the VX.x project, so I have not participated in it for the time being. 2) R&D side: back-end, except version compatibility, other functions can be developed within this week; XXX: 1) R&D side: XX function has been tested last week, and the current development progress is XX%, the progress is normal, it is expected to be completed next Friday; 2) Test: During the test, the test progress was 10%. In the test of XX module, because the page content redirection was not fully realized, there was a amount of rework in the later stage, and there might be risks in the later stage; XXX project Vx. X: launched last week;Copy the code

Example 2:

Dear All, the progress of the main project has been released last week: modification of prepayment interest algorithm for online problems product: XXX development: XX test: XX Xuan in progress: 1. Easy investment part exit test stage products: CAI Jingjing Development: Huang Zhenting, Wu Dongdong (increased this week), CAI Xiaoping, Lin Bochun Test: Zhou Peixuan Risk: more failures, the main process is still unable to settle the failure, and the problem repeatedly. There are many defects in the early development (business) design. The original plan is to launch this week. 2.App optimization -XXX Functional test Progress Normal product: XXX Development: XXX Test: XXX 3.XXXX test progress Normal product: XXX development: XXX test: 5.XXX development and design stage product: XXX development and XXX test: XXXCopy the code

summary

The above content is the efforts of the whole team and everyone. It is not easy to finish such a thing. Although it takes a lot of time, it is really worth it.

All right, that’s it. If you have anything to add, please feel free to contribute. Thank you.