QA Plans for 1.0
Justin Obara
justin.obara at utoronto.ca
Wed Feb 25 16:51:05 UTC 2009
Hello,
My plans for 1.0 are largely around getting rid of as many bugs as
possible for the 1.0 release.
I had initially thought of doing a standard bug parade with a focus
fixed time to get rid of some of the other bugs some time in the
middle of the month. Now I'm thinking that with all of the component
developers hard at work on getting their features in, it may be better
to just have an extended bug parade.
Bug Parade:
Usually we have about a week for bug parade. This time I'm hoping to
have about two weeks for bug parade. The emphasis will be to get rid
of all critical and blocker bugs and then to move back to clearing
away as many of the other bugs as possible. Since this is such a big
release it would be good to have all hands on deck, meaning that all
progress on features should be halted (no sandbox / branch commits).
Testing:
Usually we do testing in a day or two, depending on how many
components have been touched. I'm thinking that it would be better to
ensure that all components (every html page that we include in the
release) are tested on all supported configurations. This means that
we will need more time to test, and a little bit of padding to knock
off any issues that we may find along the way. This would also likely
mean that we will need more people testing (possibly help from the
designers).
Future Plans and Other Considerations
-----------------------------------------------------
1) It would be helpful to have component contacts to verify the
priority of jiras (I think some have started on this already)
2) It would be good to have component contacts look through jira and
escalate the appropriate issues
3) Have sample pages created to demonstrate escalated issues. This
would help track these issues as well as being a reference point for
any user who comes across one.
4) Build an automated test framework and a nightly build system that
incorporates the running of unit tests at build time.
Possible Timeline for 1.0
----------------------------------
Bug Parade: March 10 - 23
Testing: March 24 - 27
Release: March 30 - 31
That would only leave 8 business days for getting features in, which
may not be realistic. I'm assuming that we want to release at the end
of the month. We could get a head start on the release process
depending on how fast the testing goes. I'd like to have the 4 days
just to be sure that if any bugs do crop up, we have time to fix and
retest. The Bug Parade, will be the likely place where we can cut
down, but I'd like to have as long as possible. Please let me know
if you have any ideas about this.
Thanks
Justin