Skip to content

Instantly share code, notes, and snippets.

What would you like to do?
Web QA Bootcamp Structure
Web QA Bootcamp Documentation
Welcome message
Joining IRC
Joining mailing list
Projects to choose from
List of projects...
GitHub account
Bugzilla account?
How to set up and run GitHub locally on machine
Branches (discuss separate branch for each activity)
Submitting a PR
Running tests
Test options
Interpreting test output
Writing tests (process)
How to write a test
Tutorial / walkthrough (kind of like FxOS has for create_contact_test)
(Link to GitHub docs with something like "If you've never used GitHub before, read this.")
Code Review
Manual Testing
Bugzilla account
Bug triaging
How to search for project bugs
Talk about unconfirmed, confirmed, new, resolved, fixed....
How to verify there's a problem
How to verify there's a solution
Filing a bug
Platform (OS should be n/a or all for Web QA)
Dev, staging, or production
Include browser, system settings...
Steps to reproduce
Expected result
Actual result
Include screenshots if necessary
Exploratory testing
Discuss risk analysis
Deciding which features to test
Copy link

davehunt commented Jul 15, 2015

List of projects...

I think we should avoid listing our projects, as this would increase the maintenance burden of the documentation. I think a lot of the documentation is project agnostic.

Copy link

davehunt commented Jul 15, 2015

How to set up and run GitHub locally on machine

I'd rename this to something like 'Git workflow' indicating that it's our chosen preferred workflow. I'd also suggest this being a single page, and leaning heavily on GitHub help and similar resources.

Copy link

davehunt commented Jul 15, 2015


It would be worth mentioning the mozwebqa-examples repository, which includes a webapp and tests written according to our best practices. As it's small, it's easier to keep up to date than any of our other repos.

Copy link

davehunt commented Jul 15, 2015

Looks good Justin! I think we could also include things like the style guide from our wiki, but what you have hear makes a great start. I am personally in favour of having a Web QA 'bootcamp' documentation as a readthedocs project. If the team agrees, let's create a webqa-bootcamp repository where we can start getting some of this done.

Copy link

stephendonner commented Aug 5, 2015

Looking good, and +1 to Dave's suggestion of getting this going, so we can iterate.


  • "Platform (OS should be n/a or all for Web QA)" - platform doesn't always matter, but often times it can, and does. For instance, many experiences/UI flows or behaviors are specific to the non-Firefox experience (or vice-versa), as well as (though less often than in the past) browser-version or rendering-engine specific issues.
  • I think it might make sense to explain our overall strategy of testing, which encompasses many approaches, tools, etc.
  • Along those lines, perhaps we should list the manual testing first, as that's where any great automation strategy (should) start(s).
  • Bugzilla-triage specific: It might be hard to abstract away enough of the project-specific workflows for projects, but we can also iterate on this, and for things like [fromAutomation] and -- if made known/available, [traceback] and others from shared lists e.g., too.
  • Also, it's perhaps a larger topic than this, but since it fits in with some of the suggestions, what should be doing with ?

Again, thanks for spearheading this -- looking forward to seeing it land somewhere it can be a living document :-) 👍

Copy link

AutomatedTester commented Aug 11, 2015

List of Projects

I agree with Dave. This is just a place where it will be out of date the minute you press save. Managers have other projects that are coming or going so unless it can be automatically updated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment