2018-08-21 UI Testing Team Meeting Notes

2018-08-21 UI Testing Team Meeting Notes

Date

Aug 21, 2018

Attendees

  • @Anton Emelianov (Deactivated)

  • @Jeffrey Cherewaty

  • @Magda Zacharska

  • @Oleksii Popov

  • @Zak_Burke

  • @John Malconian

  • @John Coburn

  • @Mike Taylor

Away

  • @Matt Jones

  • @Charles Ledvina

Goals

  • Discuss PR process for UI modules and propose required steps prior to accepting PR.

  • Discuss SonarQube Quality Gate required configuration and enforcement.

 

Helpful information to review prior to meeting:

Discussion items

Time

Item

Who

Notes

Time

Item

Who

Notes

5 min

Open tasks housekeeping

Anton

 

30 min

PR process for UI modules

The Team

Please see note for this line item below.

 

20 min

QualityGate

The Team

 

UI Testing team agreed to start using default SonarQube Quality Gate configuration. It will be tuned as required in the future.

5 min

Next steps for BigTest implementation

The Team

 

 

 PR process for UI modules

 

New Code

Old Code

IDE

  • Install

  • Lint

  • BigTest

  • Local Coverage Report (Istanbul)

  • Lint

Feature Branch Build

  • Install

  • Lint

  • BigTest

  • Pact (after implemented)

  • Jenkins Coverage Report (Istanbul)

  • Code review complete

  • Lint

  •  

  •  

  •  

  •  

  • Code review complete

Master Branch Build

  • Install

  • Lint

  • BigTest

  • Pact (after implemented)

  • SonarCloud Quality Gate (Passive initially: Reporting & Not enforcing )

  • Lint

  • Nightmare module specific tests

It may take multiple merges and build to Master for a module manually promoted for the nightly integration testing.

 

PR approval requirements

The team agreed not to make PA approval as a mandatory requirement for the merge to Master.

However, while the rule is not being physically enforced, UI Testing Team strongly suggest the following:

  1. The fact that code review is not enforced via GitHub doesn’t mean it is not required.

  2. Contributors who consistently merging to Master without code review will be not appreciated.

  3. Developers should be actively seeking code review unless it is a real emergency change.

  4. Code review step is included into DoD for a user story. Product owners shouldn’t accept stories that are missing code review.

  5. Developer should plan PR timing to ensure that code review can be completed.

  6. Avoid commits to Master on Friday.

 

Action items