Introduction¶

This is the organisation wiki for the openQA Project.

Organisational¶

openQA calls¶

Currently there are two recurring openQA calls conducted at SUSE on http://jangouts.suse.de/. If there would be more interest from the outside the call could be made on a public platform.

Both meetings should target to finish in 15 minutes each. If more time is needed, propose to stay in the call with the required subset of attendees.

Standard rules of good "standup meetings" apply here, too, e.g.

• Be on time (be there at meeting start)
• Be concise (help keep the time limit)
• Be polite
• focus on
  • what you achieved
  • what you plan
  • where did you face problems where you could use help

"openQA backend coordination" call¶

objectives:

• Coordination on openQA backend development

execution: A regular daily call from Mon-Fri at 0900 UTC

"SUSE QA test coordination" call¶

objectives:

• Coordination on openQA based test development, especially SLE products
• Information about important development in openQA backend by backend responsibles

execution: Mon + Wed, at 0930 UTC

If somebody from SUSE QA team will do back-end development he can attend the first call as well, of course.

User stories¶

User: QA-Project Managment
primary actor: QA Project Manager, QA Team Leads
stakeholder: Directors, VP
trigger: product milestones, providing a daily status
user story: „As a QA project manager I want to check on a daily basis the „openQA Dashboard“ to get a summary/an overall status of the „reviewers results“ in order to take the right actions and prioritize tasks in QA accordingly.“

User: openQA-Admin
primary actor: Backend-Team
stakeholder: Qa-Prjmgr, QA-TL, openQA Tech-Lead
trigger: Bugs, features, new testcases
user story: „As an openQA admin I constantly check in the web-UI the system health and I manage its configuration to ensure smooth operation of the tool.“

User: QA-Reviewer
primary actor: QA-Team
stakeholder: QA-Prjmgr, Release-Mgmt, openQA-Admin
trigger: every new build
user story: „As an openQA-Reviewer at any point in time I review on the webpage of openQA the overall status of a build in order to track and find bugs, because I want to find bugs as early as possible and report them.“

User: Testcase-Contributor
primary actor: All development teams, Maintenance QA
stakeholder: QA-Reviewer, openQA-Admin, openQA Tech-Lead
trigger: features, new functionality, bugs, new product/package
user story: „As developer when there are new features, new functionality, bugs, new product/package in git I contribute my testcases because I want to ensure good quality submissions and smooth product integration.“

User: Release-Mgmt
primary actor: Release Manager
stakeholder: Directors, VP, PM, TAMs, Partners
trigger: Milestones
user story: „As a Release-Manager on a daily basis I check on a dashboard for the product health/build status in order to act early in case of failures and have concrete and current reports.“

User: Staging-Admin
primary actor: Staging-Manager for the products
stakeholder: Release-Mgmt, Build-Team
trigger: every single submission to projects
user story: „As a Staging-Manager I review the build status of packages with every staged submission to the „staging projects“ in the „staging dashboard“ and the test-status of the pre-integrated fixes, bacause I want to indentify major breakage before integration to the products and provide fast feedback back to the development.“

Old content¶

Sprints¶

Sprint 01
Sprint 02
Sprint 03