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

Screen Shot 2018-10-17 at 5.44.35 PM

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.