B2G/QA/Automation/UI/Strategy/Increase End to end coverage: Difference between revisions

From MozillaWiki
< B2G‎ | QA‎ | Automation‎ | UI‎ | Strategy
Jump to navigation Jump to search
Line 17: Line 17:
=Timeline=
=Timeline=


Q2
Q2:


* Triage of new smoketests for JS UAT backlog [Proposed: Martijn]  
* Triage of new smoketests for JS UAT backlog [Proposed: Martijn]  

Revision as of 04:46, 11 February 2015

Objective

Increase the coverage of our UATs so we can more quickly and confidently accept builds and raise errors.

Challenges Addressed

  • Development and QA have different approaches and needs from UI testing

The Problem

As QA, we have to do a lot of manual regression testing to know that builds remain acceptable. This takes disproportionate amounts of time compared to the benefit of verifying the absence of bugs. By implementing more UAT automation, we can increase our impact and free up people for more fruitful exploratory testing.

The Solution

Add any tests that we plan to accept builds on. Don't consider appropriateness for CI.

Timeline

Q2:

  • Triage of new smoketests for JS UAT backlog [Proposed: Martijn]
  • Triage of dogfood tests for JS UAT backlog [Proposed: Naoki]
  • Establish JS suites for UATs (depends on passing gate)
  • Triage of additional areas for JS UAT backlog
  • Additions to JS suites for UATs

Risks

Given the impending move to JS and the need to stabilize the existing tests per the Streamlining plan, it doesn't make sense to continue to expand the Python suite.

That means we're gated on developing GaiaTest for JS. Its risks also apply here.