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 story 1¶

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 story 2¶

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 story 3¶

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 story 4¶

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: 4. „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 story 5¶

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 story 6¶

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, because I want to identify major breakage before integration to the products and provide fast feedback back to the development.“

Thoughts about categorizing test results, issues, states within openQA¶

by okurz

When reviewing test results it is important to distinguish between different causes of "failed tests"

Nomenclature¶

Test status categories¶

A common definition about the status of a test regarding the product it tests: "false|true positive|negative" as described on https://en.wikipedia.org/wiki/False_positives_and_false_negatives. "positive|negative" describes the outcome of a test ("positive": PASSED; "negative": FAILED) whereas "false|true" describes the conclusion of the test regarding the presence of issues in the SUT or product in our case ("true": correct reporting; "false": incorrect reporting), e.g. "true negative", test successful, no issues detected and there are no issues, product is working as expected by customer. Another example: Think of testing as of a fire alarm. An alarm (event detector) should only go off (be "positive") if there is a fire (event to detect) --> "true positive" whereas if there is no fire there should be no alarm --> "true negative".

Another common but potentially ambiguous categorization:

• broken: the test is not behaving as expected (Ambiguity: "as expected" by whom?) --> commonly a "false positive", can also be "false negative" but hard to detect
• failing: the test is behaving as expected, but the test output is a fail --> "true positive"
• working: the test is behaving as expected (with no comment regarding the result, though some might ambiguously imply 'result is negative')
• passing: the test is behaving as expected, but the result is a success --> "true negative"

If in doubt declare a test as "broken". We should review the test and examine if it is behaving as expected.

Be careful about "positive/negative" as some might also use "positive" to incorrectly denote a passing test (and "negative" for failing test) as an indicator of "working product" not an indicator about "issue present". If you argue what is "used in common speech" think about how "false positive" is used as in "false alarm" --> "positive" == "alarm raised", also see https://narainko.wordpress.com/2012/08/26/understanding-false-positive-and-false-negative/

Priorization of work regarding categories¶

In this sense development+QA want to accomplish a "true negative" state whenever possible (no issues present, therefore none detected). As QA and test developers we want to prevent "false positives" ("false alarms" declaring a product as broken when it is not but the test failed for other reasons), also known as "type I error" and "false negatives" (a product issue is not catched by tests and might "slip through" QA and at worst is only found by an external outside customer) also known as "type II error". Also see https://en.wikipedia.org/wiki/Type_I_and_type_II_errors. In the context of openQA and system testing paired with screen matching a "false positive" is much more likely as the tests are very susceptible to subtle variations and changes even if they should be accepted. So when in doubt, create an issue in progress, look at it again, and find that it was a false alarm, rather than wasting more peoples time with INVALID bug reports by believing the product to be broken when it isn't. To quote Richard Brown: "I […] believe this is the route to ongoing improvement - if we have tests which produce such false alarms, then that is a clear indicator that the test needs to be reworked to be less ambiguous, and that IS our job as openQA developers to deal with".

Further categorization of statuses, issues and such in testing, especially automatic tests¶

By okurz

This categorization scheme is meant to help in communication in either written or spoken discussions being simple, concise, easy to remember while unambiguous in every case.
While used for naming it should also be used as a decision tree and can be followed from the top following each branch.

Categorization scheme¶

To keep it simple I will try to go in steps of deciding if a potential issue is of one of two categories in every step (maybe three) and go further down from there. The degree of further detailing is not limited, i.e. it can be further extended. Naming scheme should follow arabic number (for two levels just 1 and 2) counting schemes added from the right for every additional level of decision step and detail without any separation between the digits, e.g. "1111" for the first type in every level of detail up to level four. Also, I am thinking of giving the fully written form phonetic name to unambiguously identify each on every level as long as not more individual levels are necessary. The alphabet should be reserved for higher levels and higher priority types.
Every leaf of the tree must have an action assigned to it.

1 failed (ZULU)
11 new (passed->failed) (YANKEE)
111 product issue ("true positive") (WHISKEY)
1111 unfiled issue (SIERRA)
11111 hard issue (KILO)
111121 critical / potential ship stopper (INDIA) --> immediately file bug report with "ship_stopper?" flag; opt. inform RM directly
111122 non-critical hard issue (HOTEL) --> file bug report
11112 soft issue (JULIETT) --> file bug report
1112 bugzilla bug exists (ROMEO)
11121 bug was known to openqa / openqa developer --> cross-reference (bug->test, test->bug) AND raise review process issue, improve openqa process
11122 bug was filed by other sources (e.g. beta-tester) --> cross-reference (bug->test, test->bug)
112 test issue ("false positive") (VICTOR)
1121 progress issue exists (QUEBEC) --> cross-reference (issue->test, test->issue)
1122 unfiled test issue (PAPA)
11221 easy to do w/o progress issue
112211 need needles update --> re-needle if sure, TODO how to notify?
112212 pot. flaky, timeout
1122121 retrigger yields PASS --> comment in progress about flaky issue fixed
1122122 reproducible on retrigger --> file progress issue
11222 needs progress issue filed --> file progress issue
12 existing / still failing (failed->failed) (XRAY)
121 product issue (UNIFORM)
1211 unfiled issue (OSCAR) --> file bug report AND raise review process issue (why has it not been found and filed?)
1212 bugzilla bug exists (NOVEMBER) --> ensure cross-reference, also see rules for 1112 ROMEO
122 test issue (TANGO)
1221 progress issue exists (MIKE) --> monitor, if persisting reprioritize test development work
1222 needs progress issue filed (LIMA) --> file progress issue AND raise review process issue, see 1211 OSCAR
2 passed (ALFA)
21 stable (passed->passed) (BRAVO)
211 existing "true negative" (DELTA) --> monitor, maybe can be made stricter
212 existing "false negative" (ECHO) --> needs test improvement
22 fixed (failed->passed) (CHARLIE)
222 fixed "true negative" (FOXTROTT) --> TODO split monitor, see 211 DELTA
2221 was test issue --> close progress issue
2222 was product issue
22221 no bug report exists --> raise review process issue (why was it not filed?)
22222 bug report exists
222221 was marked as RESOLVED FIXED
221 fixed but "false negative" (GOLF) --> potentially revert test fix, also see 212 ECHO

Priority from high to low: INDIA->OSCAR->HOTEL->JULIETT->…

Further decision steps working on test issues¶

Test issues could be one of the following sources

• "accepted product changes"

  • product changed slightly but in an acceptable way without the need for communication with DEV+RM --> adapt test
  • product changed slightly but in an acceptable way found after feedback from RM --> adapt test
  • product changed significantly --> after approval by RM adapt test

• changes in test setup, e.g. our test hardware equipment behaves different or the network

• changes in test infrastructure software, e.g. os-autoinst, openQA

• changes in test management configuration, e.g. openQA database settings

• changes in the test software itself

Old content¶

Sprints¶

Sprint 01
Sprint 02
Sprint 03