Confirmed users
9,511
edits
No edit summary |
|||
(9 intermediate revisions by 4 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 (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 | # 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 | ## OneandDone goodfirstbugs import | ||
## Bugsahoy | ## [http://www.joshmatthews.net/bugsahoy/ Bugsahoy] | ||
## Creating Outreachy tasks for evaluating candidates | ## Creating Outreachy tasks for evaluating candidates | ||
## Clean up backlog of test automation bugs dashboard (and github issues) | ## Clean up backlog of test automation bugs dashboard (and github issues) | ||
Line 38: | Line 42: | ||
## Gaia has a history around this, might help to talk with them | ## Gaia has a history around this, might help to talk with them | ||
## Bugzilla as much as possible just for history and discoverability | ## Bugzilla as much as possible just for history and discoverability | ||
## Our dashboard could have bugzilla component tracking as well as | ## Our dashboard could have bugzilla component tracking as well as GitHub Issues to try to combine | ||
## Justin Potts had a redesign that might help | ## Justin Potts had a [https://github.com/justinpotts/mozwebqa-dashboard redesign] that might help | ||
## Testrail test plans could generate manual and automated | ## Testrail test plans could generate manual and automated |