Confirmed users
9,511
edits
QA/Execution/Web Testing/Goals/2016/Q2: Difference between revisions
QA/Execution/Web Testing/Goals/2016/Q2 (view source)
Revision as of 22:05, 28 June 2016
, 28 June 2016no edit summary
(→Dave) |
No edit summary |
||
| (11 intermediate revisions by 5 users not shown) | |||
| Line 12: | Line 12: | ||
== Individual Goals == | == Individual Goals == | ||
===Krupa=== | ===Krupa=== | ||
# | # Work with devs and ops to review and improve AMO's release process | ||
# Work on Webextensions release for 48 to ensure cross-platform coverage | |||
## Check if there are opportunities to engage with Chrome webextensions before the 48 release. Need to discuss with Amy and Dan before confirming on this. | |||
===Stephen=== | ===Stephen=== | ||
# | # Get a Dockererized OWASP ZAP ([https://github.com/Grunny/zap-cli CLI]) instance up and running against a staged instance of one of our key sites: either AMO, Mozilla.org, or MDN, in Web QA's Jenkins, on either/both a cronjob or on-demand, as goal | ||
#* Document (i.e. blogpost[s]) the goals, the process, the progress, to try to help increase awareness | |||
## DONE: https://blog.mozilla.org/webqa/2016/06/28/dockerized-owasp-zap-security-scanning-in-jenkins-part-two/ & http://159.203.196.21:8080/job/docker-zap-cli/22/console | |||
===Dave=== | ===Dave=== | ||
# | # Set up UI functional tests for the add-ons website to run against pull requests | ||
#* The UI functional tests currently live in https://github.com/mozilla/Addon-Tests and are run against deployed instances of the add-ons website. This deliverable will mean that UI functional tests will be run whenever a contributor submits a patch for consideration against an instance of the application including the change. This will reduce the feedback loop for failures, and will prevent regressions from being introduced. | #* The UI functional tests currently live in https://github.com/mozilla/Addon-Tests and are run against deployed instances of the add-ons website. This deliverable will mean that UI functional tests will be run whenever a contributor submits a patch for consideration against an instance of the application including the change. This will reduce the feedback loop for failures, and will prevent regressions from being introduced. | ||
===Rebecca=== | ===Rebecca=== | ||
# Ramp up and own Shavar deployments | # Ramp up and own Shavar deployments | ||
# Learn and implement Docker container | # Learn and implement Docker container locally, assist with One and Done Docker-ization | ||
===Matt=== | ===Matt=== | ||
# | # Dockerize One and Done | ||
# MDN - Create a community oriented test plan | |||
==Open-ended Questions for Q2== | ==Open-ended Questions for Q2== | ||
# How can we increase community contribution? | # How can we increase community contribution? | ||
## OneandDone goodfirstbugs import | |||
## [http://www.joshmatthews.net/bugsahoy/ Bugsahoy] | |||
## Creating Outreachy tasks for evaluating candidates | |||
## Clean up backlog of test automation bugs dashboard (and github issues) | |||
# How can we improve GitHub issue and review discovery? | # How can we improve GitHub issue and review discovery? | ||
## Gaia has a history around this, might help to talk with them | |||
## Bugzilla as much as possible just for history and discoverability | |||
## Our dashboard could have bugzilla component tracking as well as GitHub Issues to try to combine | |||
## Justin Potts had a [https://github.com/justinpotts/mozwebqa-dashboard redesign] that might help | |||
## Testrail test plans could generate manual and automated | |||