Client Testing Process

To achieve below objectives, I defined the testing process for my team as below screeshot,

• Objective – I wanted to test my feature ASAP
  • Use development branch – dev can check in code into development branch any time directly without code review
  • QA can update or request dev to modify configuration or code in development branch any time for testing convenient
  • Dev environment / or Dev client-apk/ipa is supposed to be unstable
  • We conduct/focus on new feature / bug fixes on Dev branch
  • Limited regression testing will be conducted on Dev branch only
  • Jump into the code review / Merge Request (MR) / commits to improve test efficient
• Objective – I wanted to build this or that into the next .apk / deploy this or that to QA/Staging environment
  • Become the admin of Jenkins
  • Make Jenkins build friendly to QA
  • Jump into Git to control the code change scope
  • Don’t do this way, ‘hey developer can you help me build a new apk’ – this is anti-pattern

A typical User Case:

• Step 1 – dev creates a new branch ‘my-mom-cooks-dinner-for-me-every-day’
• Step 2 – dev wants to involve QA for testing before raising MR. He merges to pre-dev branch directly
• Step 3 – Jenkins builds an apk
• Step 4 – QA gets the apk and test quickly
• Step 5 – QA feedbacks quickly
  • if test pass, ask dev to rasie MR and tell the reviewer test passed
  • else, ask dev to fix
  • QA can also review the code changes to improve test coverage and test productivity
• Step 6 – QA gives a GO, reviewer reviews code, merge code to development branch
• Step 7 – development branch triggers Jenkins to build .apk automatically
• Step 8 – QA verifies the build when s/he has time
• Step 9 – QA verifies test result
• Step 10
  • if test passed, QA merge the code to master branch directly
  • else, inform dev to fix
• Step 11 – master branch triggers Jenkins to build .apk automatically – If QA has time continue to test
• Step 12 – QA gets the master branch .apk and test
• Step 14
  •  If test passes, QA can trigger Jenkins to build a public version manually
  • else feedbacks to dev immediately

Concerns

• We have several feature branches and some of them may not be released in next public release. Should I still merge to pre-dev branch? — Yes! Integrate as soon as you think it is ready for testing. You can even raise MRs for it and just do the merge when it becomes a release candidate
• I have done my work on feature branch but I am a bit worried the implementation is not quite stable, can I merge to pre-dev branch? — Yes! Just merge it. If it is fragile then do it frequent to make it strong. QA welcomes it!
• So Dev will not do the merge from development branch to master branch, true? — Yes! QA will do it and do it every day and will only involve Dev’s attention for code conflicts.