-
-
Save justinpotts/7f309fd6386671243b44 to your computer and use it in GitHub Desktop.
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 | |
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.
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.
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.