Dashboard > 5th Sakai Conference, Vancouver, BC, Canada 30 May - 2 June 2006 (Community Source Week) > Sakai QA Roundtable Discussion
  5th Sakai Conference, Vancouver, BC, Canada 30 May - 2 June 2006 (Community Source Week) Log In | Signup View a printable version of the current page.  
  Sakai QA Roundtable Discussion
Added by Mary Miles, last edited by Megan May on Jun 02, 2006  (view change)
Labels: 
(None)

Sakai QA Roundtable Discussion

Megan May with QA WG members
Seth Theriault
Clay Fenalson
Stephan Marquard
Kim Gausepohl
Kevin Brokamp
Peter Knoop

Wednesday
8:30 am - 10:00 am
Room: Grand A

Session Abstract

Roundtable discussion of overall Sakai QA process.

Presentation Materials

Podcasts

  • Session was not recorded

Session Notes

please feel free to comment on or add to these notes

05/31 8:30 AM QA Roundtable Discussion Notes

2.1.1 Release:

¿ Most fixes applied to T&S tool
¿ 100% Jira verification (verified bug fixes and/or reopened issues)

2.1.2 Release:

¿ Assignments/Gradebook integration
¿ 85% Jira verification
¿ Expanded testing platforms
¿ Plan to do qa on clean installs and servers with retained data

Changes since Austin:

¿ QA server network
¿ Dropped HSQL as a platform
¿ Tried to communicate better

2.2 Release:

¿ Testing is ongoing
¿ Framework reorg
¿ Assignments & Schedule are group aware
¿ New skin

Clay Fenlason
¿ Writing installation documentation

Peter Knoop
¿ Coordinate Jira

Seth Theriault
¿ Involved with deployment of builds
¿ Hosts qa2

Stephen Marquard
¿ Recently put Sakai in production
¿ Attempts to time local releases with Sakai releases to contribute best to QA
¿ Involved in 2.2 QA process
¿ Set up a QA server
¿ The more variety of QA builds, the better the process

Kim Gausepohl
¿ Testing for Sakai and OSP

Kevin Brokamp
¿ Involved in QA
¿ Tries to catch issues early on

2.2 Performance Testing:

Linda: 2.2 Framework change is troublesome, will be doing a lot of performance testing once 2.2 is released, will try to get information about current processes on Confluence.

Unisys is working on performance testing, creating basic scripts in loadrunner, Berkeley is working load testing as well as Virginia.

Hoping to do more user profile type activities in the future

Watch the board for a BOF

Megan: We need people to write test scripts for Samigo and to volunteer to test Samigo

Seth: We deployed Samigo and because it is a large and powerful application, users were overwhelmed.

Some users can't live without this tool.

Stephen Marquard: Deployed Samigo at a small scale. Have experienced a few deadlock problems that they are working through with Stanford.

Planning to deploy Samigo to production soon and will be testing heavily. Will work on a good testing plan to ensure Samigo's reliability.

Ari: How many developer resources do we have to write unit testing and performance testing here today?

Megan: We need volunteers.

Ari: I see a lot of tool development, but when will we begin focusing on thorough testing?

Linda: I can commit load testing resources, but I need to know where to focus the load testing, which needs to come from the QA team.

Daisy: If you can tell us what information you need, we can get you the information.

Linda: We cannot do load testing for 2.2, but after 2.2 we can do load testing.

Lesson learned: test against production data.

Linda: Patterned usage allows you to do proper load testing

Seth: Rutgers rolled out a large pilot on MySQL, this was good for the community because Rutgers found and fixed a lot of issues

One of the issues with QA is people power. How much commitment can you make? These are local managerial decisions.

Peter: We need more people to commit to load testing

Stephen Marquard: We need to put more realistic data into the QA servers. I think we can do this with WebServices.

Issues with reading tool logs and some tools don't log

Site statistics is a huge need

There is an area on Confluence where developers/QA testers can contribute scripts

Adding JMeter scripts to Subversion would make it easier for system administrators to check them out and run them on their Sakai instance

Pseudoscripts would be useful as well

We need a chart that pulls together those institutions that are needing to run a tool in production and the qa schedule.

Provide indicators that people can use to decide what to put into production/pilot or not to deploy.

We need to share our experiences with the community, including issues and fixes.

We need to give administrators and university players an easy way to get information to the community. Perhaps we can provide scripts to get the information that we need, taking the pressure off of the individual university.

  • Participants and Session Leaders are encouraged to post Comments (see Comment form below) or create additional Pages as needed to facilitate collaboration (see Add Page link near top-right.) )
    • Child Pages for this session (Added Pages will automatically appear in this list)

Site running on a free Atlassian Confluence Open Source Project License granted to Sakai Foundation. Evaluate Confluence today.
Powered by Atlassian Confluence, the Enterprise Wiki. (Version: 2.5.5 Build:#811 Jul 25, 2007) - Bug/feature request - Contact Administrators