I shared some of my thoughts and goals during the meeting today, so please do check it out:
https://wiki.ubuntu.com/QATeam/Meetings/QA/20120523 Despite still tying up some lose ends on planning testing for the cycle, I wanted to share with all of you what thoughts on how we can improve and expand on the types of testing we do as part of QA. ISOTesting My goal is to help ensure things are smooth before milestones, and before isotesting events. Before we spin an iso, we want to feel good about what's going on that iso. And we as a community can help make that happen. Overall, I want each individual to have a lighter workload than last cycle, despite having a similar amount of overall work we need to achieve. To do this I'd like to help enable more people to be testing, and to expand the 'adopt an iso' program so that folks can focus on testing things they like and are able to test without becoming overwhelmed or burnt out. Additionally, respins will be a continuous focus and communication of what has changed and what needs tested will be a priority. As a community we want to avoid doing re-work/extra work and dedicate ourselves to performing quality testing, not merely having a large quantity of testing. Application Testing Last cycle we utilized checkbox to deliver manual application tests. During UDS, we spoke of expanding the isotracker to do our testcase management, and thus consolidate our application testing by using the same tool used for the isotracker to create an application tracker. This work is on-going, but should be finished at some point during the cycle so we can adopt it and use it. In the interim period will be continue utilizing checkbox or doing manual testing via blogs or mailing lists, etc. SRU Verification SRU verification is currently a manual process with a high learning curve and little visibility for many people. During the cycle, we hope to help change that but also utilizing a new tracker to do SRU testing. This testing will involve running the stable version (currently precise) of ubuntu, but testing fixes to individual packages. This makes it a good fit for those who aren't living on the bleeding edge but wish to help. When this process is ironed out (sometime during the cycle) I will contact everyone again with information on howto get involved. General Testing (eg, Day-to-Day running of the development version) Some good feedback was given on how to help make this better. There are a few things we would like to do to help improve this process. First, day to day changes should be able to be followed easier with some proposed changes to update-manager to better display changelogs for updated packages. I'll be detailing some information about how 'whoopsie' works and what it means to you. In addition, keeping the development release stable at all times will continue to be a priority for the development teams. Calls for testing (specific feature or new features of critical package or focused testing on a specific package) Last cycle this typically involved me posting and laying out a basic testplan on my blog with instructions on how to help test. This cycle, again we hope to consolidate this onto a tracker where the tests and results can be recorded. I will still be utilizing my blog, the @ubuntutesting twitter account, this mailing list and our IRC meeting to publicize events like this for people to get involved and contribute. It's always fun to see new features before they come to everyone else, and the feedback loop with the developers was welcome on both sides. QATracker Development With these changes to the qatracker, there is room for some folks who know python and django to get involved and help improve the qatracker codebase to make testing and reporting easier :-) Contact me, or simply have a look at the code on launchpad and start hacking. lp:~ubuntu-qa-website-devel/ubuntu-qa-website/drupal7-rewrite lp:~ubuntu-qa-website-devel/ubuntu-qa-website/drupal7-rewrite-testcase-management lp:~ubuntu-qa-website-devel/ubuntu-qa-website/python-qatracker lp:~ubuntu-qa-website-devel/ubuntu-qa-website/python-qatracker-testcase-management Hardware Database The idea for having a hardware database for testing is not a new one, but work has begun anew. This is work that will go beyond this cycle, but ideas are being explored at using ubuntu friendly and other tools to make this a reality. Testcases As a testcase management system will soon be in place (hurray!), we'll be migrating all of the testcases over to this system. That means will have much better visibility and ease of maintenance for all of our testcases. Cleanup and expansion of the number of testcases is definitely a goal for the cycle, and expect to hear more about getting involved in this area. Whew, that's a wall of text, but I hope it helps outline what the plans are for the cycle. Feedback appreciated and encouraged :-) Happy Testing! Nicholas -- Ubuntu-qa mailing list Ubuntu-qa@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-qa