Answers: <p>The guidance that we've always followed in my various scrum teams is developers should get what they've got into testing as soon as possible. It may mean a little rework later on down the line if there are issues found in code reviews or developers haven't completely finished coding, but the earlier developers get feedback on what's been done, the earlier they can fix any issues, and take account of this feedback in any further coding. </p>
  
  <p>You should make testers aware when they aren't getting completely finished output, but if they've been encouraged to think about the benefits of preventing bugs as well as just finding them, they should hopefully be keen to adopt this process. </p>
  
  <p>It isn't always practicable - for example, if you don't have deployment tools that are flexible in which branches they deploy from, but when it is practicable, it's what Scrum and agile are all about - get feedback and get it early. </p>
  
Answers: CC BY-SA 3.0
Answers: 2017-12-12T00:31:16.837Z
Answers: Thanks for your answer. Totally valid points. I guess my argument against is the disjointed communication. When a PR is opened, a developer can review the code, but they can't _merge_ it until the testing has completed. Now, how does the developer know it's been tested? a) does someone tell them? b) do they need to keep asking, c) does a tool tell them? Right now we are in option b), which is slightly frustrating and slows down the process for deployment. What approach do you take to solve this problem?
Answers: RPM1984
Answers: CC BY-SA 3.0
Answers: 2017-12-12T16:19:03.587Z
Answers: Does the tool allow the tester to add comments to say that the testing has been completed, so that the developer knows?
Answers: Jo Silverton
Answers: CC BY-SA 3.0
Answers: 2017-12-19T22:12:23.913Z
Answers: They do, but this isn't fed back into the reviewer. To be specific: we use Trello for Kanban, and GitHub for PR/code reviews. So when the tester marks the card as 'tested', this status isn't communicated to the code reviewer. I guess this can be solved by a better tool or the code creator to just mark in the PR that testing has passed. To sum up: i agree with **"developers should get what they've got into testing as soon as possible"**, but struggling with _communication_ between tester/developer/reviewer, but i guess it's a problem with the tool.
Answers: RPM1984
Answers: CC BY-SA 3.0
Answers: 2017-12-11T14:20:04.343Z
Answers: 2017-12-11T20:41:38.663Z
Answers: 2017-12-11T20:41:38.663Z
Answers: Jo Silverton
Answers: <blockquote>
    <p>Open the PR, even if it's not ready. Basically, allow the QA testing &amp; code reviews to operate in parallel. Pros: code review and testing can operate in parallel. Cons: if issues are found in testing, the code needs to change, even though it has already been reviewed.</p>
  </blockquote>
  
  <p>When code review prompts changes, testing has to be redone.  This encourages the building of automated tests over manual tests, as then this can happen automatically without any human involvement.</p>
  
  <p>When testing prompts changes, code review has to be redone.  Code review is ideally primarily about a 10,000-foot view of how to approach the problem, but it certainly does cover implementation specifics as well.  But this is a problem mostly solved by review tools - they'll show you the changes <em>since you last reviewed</em> so you don't have to review everything all over again.  Some tools handle this well with rebasing, but if you're using one that doesn't, stick to adding new commits as you work, and then squash them all together at the end if that's what you want.</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-12-19T22:09:40.130Z
Answers: Yep, good answer. Valid points. +1
Answers: RPM1984
Answers: CC BY-SA 3.0
Answers: 2017-12-18T20:05:44.883Z
Answers: 2017-12-18T20:05:44.883Z
Answers: Xiong Chiamiov
Body: <p>First question here (i'm usually on StackOverflow)...not sure if the right place (if not, please vote to move where it belongs).</p>
  
  <p>If we have a dev process using traditional <a href="https://datasift.github.io/gitflow/IntroducingGitFlow.html" rel="nofollow noreferrer">GitFlow</a> approach, what criteria should be met before a Pull Request (PR) is opened? Specifically, if the work requires manual testing/QA signoff before being <em>merged</em> into <code>master</code>.</p>
  
  <p>There are two sides of the fence here:</p>
  
  <ol>
  <li><strong>PR's should <em>not</em> be opened until the work is "ready"</strong>. (ready = ready for production, pending any code reviews, which should just be based on code quality/standards). <em>Pros</em>: reviewer doesn't need to check if the work is 'ready to be merged'. It's defined by the process. <em>Cons</em>: longer time (e.g waiting for test signoff) before the code is reviewed. PR's are open longer.</li>
  <li><strong>Open the PR, even if it's not ready</strong>. Basically, allow the QA testing &amp; code reviews to operate in parallel. <em>Pros</em>: code review and testing can operate in parallel. <em>Cons</em>: if issues are found in testing, the code needs to change, even though it has already been reviewed. So reviewing could happen multiple times, and communication needs to be fed correctly between parties.</li>
  </ol>
  
  <p>Thoughts on either 2 approaches, or is there an option 3? What standards/advice is there in this process?</p>
  
Tags: <git><process><agile><github>
Title: If a piece of work requires manual testing/QA, do we need to wait until opening PR?
UserDisplayName: RPM1984
ThreadText: # If a piece of work requires manual testing/QA, do we need to wait until opening PR?
  
  (Asked by: username_0 on 2017-12-11)
  
  First question here (i'm usually on StackOverflow)...not sure if the right place (if not, please vote to move where it belongs).
  
  If we have a dev process using traditional [GitFlow](https://datasift.github.io/gitflow/IntroducingGitFlow.html) approach, what criteria should be met before a Pull Request (PR) is opened? Specifically, if the work requires manual testing/QA signoff before being *merged* into `master`.
  
  There are two sides of the fence here:
  
  1. **PR's should *not* be opened until the work is "ready"**. (ready = ready for production, pending any code reviews, which should just be based on code quality/standards). *Pros*: reviewer doesn't need to check if the work is 'ready to be merged'. It's defined by the process. *Cons*: longer time (e.g waiting for test signoff) before the code is reviewed. PR's are open longer.
  2. **Open the PR, even if it's not ready**. Basically, allow the QA testing & code reviews to operate in parallel. *Pros*: code review and testing can operate in parallel. *Cons*: if issues are found in testing, the code needs to change, even though it has already been reviewed. So reviewing could happen multiple times, and communication needs to be fed correctly between parties.
  
  Thoughts on either 2 approaches, or is there an option 3? What standards/advice is there in this process?
  
  **Tags:** git, process, agile, github
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_1 on 2017-12-11. Score: 5
  
  The guidance that we've always followed in my various scrum teams is developers should get what they've got into testing as soon as possible. It may mean a little rework later on down the line if there are issues found in code reviews or developers haven't completely finished coding, but the earlier developers get feedback on what's been done, the earlier they can fix any issues, and take account of this feedback in any further coding.
  
  You should make testers aware when they aren't getting completely finished output, but if they've been encouraged to think about the benefits of preventing bugs as well as just finding them, they should hopefully be keen to adopt this process.
  
  It isn't always practicable - for example, if you don't have deployment tools that are flexible in which branches they deploy from, but when it is practicable, it's what Scrum and agile are all about - get feedback and get it early.
  
  > **Comments:**
  > **username_0**: Thanks for your answer. Totally valid points. I guess my argument against is the disjointed communication. When a PR is opened, a developer can review the code, but they can't _merge_ it until the testing has completed. Now, how does the developer know it's been tested? a) does someone tell them? b) do they need to keep asking, c) does a tool tell them? Right now we are in option b), which is slightly frustrating and slows down the process for deployment. What approach do you take to solve this problem?  
  > **username_1**: Does the tool allow the tester to add comments to say that the testing has been completed, so that the developer knows?  
  > **username_0**: They do, but this isn't fed back into the reviewer. To be specific: we use Trello for Kanban, and GitHub for PR/code reviews. So when the tester marks the card as 'tested', this status isn't communicated to the code reviewer. I guess this can be solved by a better tool or the code creator to just mark in the PR that testing has passed. To sum up: i agree with **"developers should get what they've got into testing as soon as possible"**, but struggling with _communication_ between tester/developer/reviewer, but i guess it's a problem with the tool.  
  
  ---
  
  ### Answer by username_2 on 2017-12-18. Score: 4
  
  > Open the PR, even if it's not ready. Basically, allow the QA testing & code reviews to operate in parallel. Pros: code review and testing can operate in parallel. Cons: if issues are found in testing, the code needs to change, even though it has already been reviewed.
  
  When code review prompts changes, testing has to be redone. This encourages the building of automated tests over manual tests, as then this can happen automatically without any human involvement.
  
  When testing prompts changes, code review has to be redone. Code review is ideally primarily about a 10,000-foot view of how to approach the problem, but it certainly does cover implementation specifics as well. But this is a problem mostly solved by review tools - they'll show you the changes *since you last reviewed* so you don't have to review everything all over again. Some tools handle this well with rebasing, but if you're using one that doesn't, stick to adding new commits as you work, and then squash them all together at the end if that's what you want.
  
  > **Comments:**
  > **username_0**: Yep, good answer. Valid points. +1  
  
  ---
  
  