1. Git Repo Branch Setting Demo
2. Developing Workflow Demo
3. Testing Workflow Demo
4. Managing Workflow Demo

• In other words, after the pending branch fully tested by the testing team, they will make a pending -> main pull request
• since the product under testing must be online, we want to keep the pending branch published as Git Page during our developing period
• and we will publish the main branch instead after all the developing period

• Each person is responsible for backing up their newly created branch
• Each person should only make pull request to the pending branch, and do NOT make pull request to the main branch
• The manager will only approve the pull request from the pending branch made by testers,
• but the manager will never approve your direct pull request to main from other branches

EX. to solve the #3 issue sprint task : Expose - Party Horn
the assignees should create a new branch named party_horn

Everytime you start working on your local version of the branch
Make sure your local version is NOT BEHIND your Remote Github Branch

Otherwise, you make encounter the issue below :

• when you excute [git push origin], you many encounter error message as below :

error: failed to push some refs to ...
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

• this is because you had been working on an old version of your branch
• which is out of date comparing to your Remote Github Branch
• you can resolve it by excute [git pull origin]
• However, make sure you have staged all the local changes EX. using [git add .]
• Otherwise, [git pull origin] will discard all unstaged changes
• which means any work you have not applied [git add] on it will COMPLETELY GONE !!!

• make a pull request party_horn -> pending,
• and prefixing you pull request name with keywords Resolves #3 can (temporarily) close the #3 issue
  
  

• everything in the pending branch is fully tested and ready to merge and test new features

• the #3 issue will be reopen
• you need to fix the bug
• then make another pull request party_horn -> pending

• learn syntax how to verify data by using the javasript code supported by TestCafe
• since the TestCafe Studio auto generated JS code are ONLY able to mimic user actions but are NOT able to verify data

• Before accepting a pull request from branch named [x-x-x]
• create a corresponding pending branch pending_{x-x-x} (if not yet)
• set the pending_[x-x-x] branch as our published page for the testing purpose

• waiting the running Regression Test (with yellow spinning mark) to finish,
• check the testing result :
  • If passed (green check mark), go to next step
    • EX. when you approved a pull request from the party_horn branch if the new code pass the Regression Test, you will see somthing as below
  • Otherwise (red cross mark),
    • first make sure the error was not caused by our test suite
    • if lt was the test suite issue, update* the test suite code to accommodate tiny changes (such as renamed tages in the html)
    • Otherwise, we are sure the newly added code caused the priblem
      • find the error and provide error analysis to the pull request maker, and notify the pull request maker
      • remark the corresponding issue as open (if it has been marked as closed)
      • skip all the following steps and go back to step 0

• use TestCafe Studio to record our action, and the user actions will be auto translated to javascript code

  • Important :

    • Make sure old test cases always included to guarantee Regression Test

• if any bug found in this step

  • find the error and provide error analysis to the pull request maker, and notify the pull request maker
  • remark the corresponding issue as open (if it has been marked as closed)
  • skip all the following steps and go back to step 0

• keep working until all the new feature are Fully tested

• wait the running Regression Test (with yellow spinning mark) to finish,
• check the testing result :
• If passed (green check mark), go to next step
• otherwise, autotesting_demo.js not work as we expected
  • go back to step 4 to edite the JS code, if necessary start over from step 3

• Important :

  • The pending -> main pull request should only be made when both coditions are safisfied :
    • the newly added code passed the test
    • the testing suite has been fully updated by the testers

• 0. Archive the main branch frequently
• 1. Never accept any pull request from branches other than the pending branch
• 2. Conduct the testing team the pending->main to solve merging conflicts
• 3. Always confirm the testing team the pending->main pull request was not made accidently before accepting
  • "face to face" confirmation is more secure
  • so that testers could not destroy the main branch accidently
  • also, frequently archiving the main branch locally can conquer such risk