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