What do SD, SE, QA and RD mean in software development?

SE； Software development engineer

QA； QA is also the abbreviation of English QUALITYASSURANCE, which means quality assurance in Chinese.

RD: That means research and development.

In the process of testing, we often encounter problems that need to communicate with RD and PM.

1. When writing a case, I have questions about the content of the requirements document.

Solution:

1) Ask who participated in the requirements review before QA;

2) Ask the R&D personnel who need development: Check the R&D schedule to see if the development has started or is about to start. If RD hasn't started developing yet, many times, they don't know much about the requirements.

3) If it affects the writing of the case, you can ask PM directly on the enterprise WeChat. If you have many questions, you can ask PM directly in person.

4) If it does not affect the case writing, it can be marked in the case and thrown away during the case review. Please answer PM.

2. On the day before starting the test, ask RD to confirm whether the test can be carried out normally. Sometimes RD feedback cannot be measured normally.

Solution:

1) Be sure to confirm the reasons that affect the measurement. If you can digest it in the current schedule, you can communicate with other RDs and make adjustments in your own schedule.

2) Be sure to confirm the time point when the test can be carried out. If the delay is caused by the server, can you let RD on the server give an entrance and test the simulated data on the server first?

3) If the server or server is delayed, be sure to inform the direct leader.

4) Delay may lead to risks and must be thrown out in time. If risks need to be reported, the R&D department must be informed, and risks must be raised in Gila in time.

5) If the delay is serious and the server or terminal does not cooperate to solve it as soon as possible, you can invite leaders to join the WeChat group and urge everyone to complete it as soon as possible; If the problem is serious, you can invite the leaders to join the WeChat group (cautious invitation) and urge everyone to complete it as soon as possible.

3. During the testing process, we encountered bugs that RD could not solve, and the number of bugs that RD could not solve was very small.

Solution:

1) tells PM that bug details and RD feedback cannot be solved.

2) If PM indicates that it will not be modified, note the corresponding bug on Jila and close the bug (the specific PM should be noted in the remarks).

3) If PM indicates that it needs to be modified, pull the group: QA, RD, PM on the enterprise WeChat, inform the questions in the group, @RD and @PM, feedback the truth, let RD and PM discuss and give the final result.

4. In the test, if you encounter a bug that RD can't solve, QA thinks that the problem will affect the experience, and you can inform PM. After reaching an agreement with PM, pull WeChat group, @RD, and feedback the bug for RD to modify.

5. If QA feels that there is something wrong with the requirement design, it can reach an agreement with RD, and then feed it back to PM together with RD.

6. There are many bugs in the test that RD can't solve.

Solution:

1) Statistic questions one by one, pull groups on enterprise WeChat: QA, RD, PM, talk about questions one by one in the group, @RD and @PM, feed back the truth, let RD and PM discuss, and give the final result.

In case of special circumstances:

1) Many bugs can't be solved by RD feedback, and PM feedback needs to be modified, but RD and PM are deadlocked and there is no result.

2) For some bugs, QA feels that the experience is seriously affected, but RD feedback cannot be solved, and the current version of PM feedback will not be modified.

3) There are too many problems that cannot be solved by current requirements, which seriously affects the user experience.

4) If the delay is serious and the server or terminal does not cooperate, solve it as soon as possible.

Solution:

1) Inform the immediate leader of the current situation.

2) E-mail: List bugs one by one, add the feedback from RD and PM to decide whether to modify the current version, add the form to the e-mail, and send an e-mail with @RD and @PM before the end of the test, so that it can reply to confirm the current situation before a certain point in time. The email is copied to the direct leader and all QA personnel.

3) If the problem is serious: it seriously affects the user experience, inform the direct leader of the current situation and find out the current situation.

4) Invite leaders to join the WeChat group and urge everyone to deal with the current problems as soon as possible; If the problem is serious, you can invite leaders to join the WeChat group and urge everyone to deal with the current problem as soon as possible.

7. Please read the requirements document before attending the requirements review. If there is a problem, it needs to be recorded. You can ask questions directly on the wiki requirements document. When participating in the requirements review, you can ask questions directly and ask PM.

If there are undetermined contents in the requirements review, fill in "Failed" in the requirements review checklist, and indicate the reasons for failure and the undetermined contents. Continue to follow up after the demand review, and urge PM to answer the uncertain content at the meeting, or hold a second review. If there are changes, additions and deletions in the requirements, PM is urged to make corresponding changes on the wiki.

8. During the testing process, the project manager should be urged to update the wiki document in time to cope with the change and increase of requirements made by the project manager.

9. When asking RD about the reason for bug introduction (especially when there was no such bug before and this part was not modified recently, but a bug was found in the test), some RD did not cooperate to find out the reason for bug introduction.

Communication mode: