Web QA Bootcamp Structure

gistfile1.txt

Web QA Bootcamp Documentation

Structure:

Welcome message
  Joining IRC
  Joining mailing list
Projects to choose from
  List of projects...
    Automation
      GitHub account
      Bugzilla account?
      How to set up and run GitHub locally on machine
        Fork
        Clone
        Branches (discuss separate branch for each activity)
        Committing
        Pushing
        Submitting a PR
        Merging
      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
          Priority
          Platform (OS should be n/a or all for Web QA)
          Dev, staging, or production
          Title
          Description
            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
        

Automation

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.

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.

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

Thoughts:

• "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. https://wiki.mozilla.org/WebAppSec/Secure_Coding_QA_Checklist, 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 https://developer.mozilla.org/en-US/docs/Mozilla/QA ?

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

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.