QA communicates with RD and PM - problems encountered during the testing process

 During the testing process, we often encounter problems that need to be communicated with RD and PM.

  1. When writing a case, there are doubts about the content of the requirements document.

  Solution:

  1) First find the QA who participated in the requirement review before and ask;

  2) Ask the RD who developed the requirement: Check the RD schedule, whether the development has been started or is about to start. If the RD has not started development, they often do not know the content of the requirement very well.

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

  4) If it does not affect the writing of the case, you can mark it in the case and throw it out during the case review, please PM to answer.

  2. One day before starting the test, ask RD to confirm whether the test can be performed normally. Sometimes RD feedback cannot be properly detected.

  Solution:

  1) Be sure to confirm the reasons that affect the test. If the current schedule can be digested, you can communicate with other RDs and make adjustments during your schedule.

  2) Be sure to confirm the time point that can be tested. If the delay is caused by the server side, whether it is possible to let the RD on the terminal give an entry, and the mock data on the terminal to be tested first.

  3) If there is a delay on the terminal or server, be sure to inform the direct leader.

  4) Delays may lead to risks, so they must be thrown out in time. If you need to report a risk, you must inform RD, and you must report the risk in Jira in time.

  5) If the delay is serious, and the server or the terminal does not cooperate to solve it as soon as possible, you can invite the leader to join the WeChat group and urge everyone to complete it as soon as possible; if the problem is very serious, you can invite the leader of the leader to join the WeChat group (invitation with caution), urging everyone to complete it as soon as possible.

  3. During the testing process, we encountered bugs that RD could not solve, and there were not many bugs that could not be solved at the same time.

  Solution:

  1) Inform PM: bug details and RD feedback cannot be resolved.

  2) If the PM indicates that it is not to be modified, make a note on the corresponding bug on Jira and close the bug (the specific PM should be indicated in the note).

  3) If the PM expresses that he wants to modify it, pull the group on the enterprise WeChat: QA, RD, PM, inform the problem in the group, @RD and @PM , feedback the truth, let RD and PM discuss, and give the final result.

  4. During the test, if you encounter a bug that cannot be solved by RD, and QA feels that the problem affects the experience, you can inform the PM and reach an agreement with the PM, pull the WeChat group, @RD , feedback the bug, and let RD modify it.

  5. If QA feels that there is a problem with the requirement design, after reaching an agreement with RD, it can be fed back to PM together with RD.

  6. During the test, there were bugs that RD could not solve, and there were a lot of bugs that could not be solved at the same time.

  Solution:

  1) Count the problems one by one, and pull up the group on the enterprise WeChat: QA, RD, PM, and throw questions one by one in the group, @RD and @PM , feedback the truth, let RD and PM discuss, and give the final result.

  In case of special circumstances:

  1) Many bugs, RD feedback cannot be solved, PM feedback needs to be revised, but RD and PM are deadlocked and there is no result.

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

  3) The current demand cannot solve too many problems, which seriously affects the user experience.

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

  Solution:

  1) Inform immediate leaders of the current situation.

  2) Send an email: list the form, record each bug one by one, add the feedback from RD, and PM to decide whether to modify the current version, add the form to the email, before the end of the test, send an email with @RD and @ in the email PM to have it reply by a certain point to confirm the current situation. Copy the email to the direct supervisor and all QA staff.

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

  4) You can invite leaders to join the WeChat group and urge everyone to deal with the current problem as soon as possible; if the problem is very serious, you can invite the leader to join the WeChat group and urge everyone to deal with the current problem as soon as possible.

  7. Before participating in the requirements review, read the requirements document first . If you have any questions, you need to record them. You can directly comment on the doubtful places on the requirements document of the wiki and ask questions. When participating in the requirements review, ask the PM directly. .

  If there is undetermined content in the requirements review, on the checklist of the requirements review, fill in the column "failed", and note the reason for the failure and the undetermined content. After the requirement review, continue to follow up, urge the PM to answer the undecided content at the meeting, or open a second review. If there are changes, additions, or deletions in the requirements, urge the PM to make corresponding changes on the wiki.

  8. During the testing process, the PM should promptly urge the PM to update the wiki document when the requirements are changed or added.

  9. When asking RD about the reason for bug introduction (especially when there was no such bug before, and no modification was made to this part recently, but the bug was found in the test), some RDs did not cooperate with finding the cause of bug introduction.

  Communication method:

  1) Be patient and inform RD of the purpose of "finding the cause of bug introduction", so as not to cause misunderstanding.

  2) Be sure not to argue with RD.

  3) Starting from the common interests of RD and QA, tell us in detail the purpose of doing this, as well as our benefits, and the final desired effect.

  11. During the testing process, even if there is a small change in demand, the direct leader should be informed. As long as there is no schedule, it is not allowed to go online and test, and no modification is allowed without the schedule.

  12. It is up to QA to decide whether the modification made by RD in the code is exempt from testing:

  1) Some RDs will tell that there is no effect and no testing is required;

  2) Some PMs inform him that they have been accepted and do not need to be tested;

  Neither of the above two situations is acceptable, and it is up to QA to decide whether to exempt from the test.
​ If you have any questions, welcome to add QQ group test entry God 755431660 to learn together ~

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=325819264&siteId=291194637