QA: Difference between revisions

From Yocto Project
Jump to navigationJump to search
No edit summary
No edit summary
Line 1: Line 1:
==New QA Process==
Editing QA-wip
*[[New_QA_process]]
Bold textItalic textInternal linkExternal link (remember http:// prefix)Level 2 headlineEmbedded fileFile linkIgnore wiki formattingYour signature with timestampHorizontal line (use sparingly)
== QA Process==
=== Intro ===
Given the QA tooling (resulttool) available to manage QA test results and reporting, here is the QA process. First release to implement this process was 2.7_M3_RC1.


==Current Release QA Trackers==
This QA process consists below:
*Test Plan
Test Trigger
**[[Yocto Project 2.7_Release Test Plan]]
Test Planning
Test Execution
Test Result Store
Test Monitoring & Reporting
Release Decision


*Live Status
=== Test Trigger ===
**[[2.7 QA Status]]- no need
Each QA team will subscribe to QA notification email (request through Richard Purdie).  The list of notifications is maintained on config.json in the yocto- autobuilder-helper which has a branch per release.


*QA Execution History
=== Test Planning ===
**[[Yocto_Project_2.7_Release_Test_Plan#Live_Schedule_.26_Execution_History | 2.7 qa run history]]
Once received the QA notification email, each QA team (eg. intel, windriver, etc) will perform planning on what extra tests they plan to run and when they'll send the results back, then reply to the QA notification email with the planned extra tests and estimate of execution time to QA stakeholders (eg. Richard Purdie, Stephen Jolley), yocto mailing list and the lead QA team. Each QA team can refer to OEQA for automated and manual test cases for their planning. The lead QA team no longer need to setup Testopia and wiki page.


*Bugs that need to be implemented by QA Team
=== Test Execution ===
**[[2.7_QA_OWNED_BUGS | 2.7 QA Assigned Bugs]]
Each QA team will execute the planned extra tests. To make sure test result from the test execution could fully integrated to the new QA tooling (resulttool for test result management and reporting/regression), execute OEQA automated tests and OEQA manual tests through resulttool (refer https://wiki.yoctoproject.org/wiki/Resulttool#manualexecution).  


*Bugs that need to be verified by QA Team
=== Test Result Store ===
**[[2.7_QA_Bugs_To_Verify]]
Each QA team will store test result to the remote yocto-testresults-contrib git repository using resulttool (refer https://wiki.yoctoproject.org/wiki/Resulttool#store), then send the QA completion email (include new defects information) to both QA stakeholder and the lead QA team.
<!--
*Features to verify
**[[2.5 qa_owned features to verify]]


*Features to implement
=== Test Result Repo ===
**[[2.5 qa owned features]]
-->


*Old Bugs that need to be Verified
After testing is complete, lead QA team will upload test results and test report in yocto-testresults-contrib git repo (https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/log/?h=intel-yocto-testresults) and send QA release mail. This is a staging repo where test results and test report are kept for tests run by independent test teams.
**[[Old resolved bugs and features]]


*2.7 Test Run Templates
To access test results, clone the repo https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/ and checkout QA branch "intel-yocto-testresults"
**[[Yocto_Project_2.7_Release_Test_Plan#Test_Items | Test Run Templates]]
 
For tests run at Autobuilder, test results and reports can be find at https://autobuilder.yocto.io/pub/releases/ inside release version folder.
 
=== Test Monitoring & Reporting ===
QA stakeholder will monitor testing progress from remote yocto-testresults git repository using resulttool (refer https://wiki.yoctoproject.org/wiki/Resulttool#report).  Once every QA team completed the test execution, the lead QA team will create QA test report and regression using resulttool, then store the report and regression into https://wiki.yoctoproject.org/wiki/Main_Page. Send email report to QA stakeholder and public yocto mailing list.
 
=== Release Decision ===
QA stakeholder will make the final decision for release.
Once decision is taken to release a milestone, RE team will take test results from staging repo and put in https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults/ git repo under same commit id as poky.
 
==Current Release QA info==
 
Tracking info for current release
 
* For latest release info, go to https://autobuilder.yocto.io/pub/releases/
* For latest QA results, go to https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/log/?h=intel-yocto-testresults


==Current Release QA Test Plans==
==Current Release QA Test Plans==
* [[QA Master Test Plan]]
 
* [[Yocto Project 2.7_Release Test Plan]]
* [[Yocto Project 2.8_Release Test Plan]]  
* [[2.7 QA Status]]
* [https://wiki.yoctoproject.org/charts/perf_milestone_GDC/performance_test.html  Performance Charts ]
* [[Toaster testing plan]]
* [[Extensible SDK Test Plan (eSDK)]]
* [[Distro Testing Plan]]
* [[BSP Test Plan]]
* [[BSP Test Plan]]
* [https://lists.yoctoproject.org/pipermail/yocto-perf/  Performance Archives ]


==Current Release QA Test Cases==
==Test Execution==  
* [[Yocto 2.7 Test Cases]]
 
==Test Execution==
===Autobuilder===
===Autobuilder===


Line 83: Line 92:
==Reporting==
==Reporting==
*[[Bug reporting and Information levels]]
*[[Bug reporting and Information levels]]
*[[Testopia]], the test manager
*[[https://wiki.yoctoproject.org/wiki/Resulttool#report The Test Reporting Tool]]
*[[QA/Test_Reporting_Tool|The Test Reporting Tool]]
*[http://errors.yoctoproject.org/Errors/ error report web]  
*[http://errors.yoctoproject.org/Errors/ error report web]
*[[https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/ Test results report]]
*[[QA REPORT TEMPLATE | Wiki of QA Report Template]]


==Performance testing==
==Performance testing==
Line 92: Line 100:


==QA Resources==
==QA Resources==
*[[Rpm's Repository Setup for QA]]
*[[QA Master Test Plan]]
*[[Testopia]]
*[[Rpm's Repository Setup for QA]]  
*[[Testing Cycle]]
*[[Resulttool]]  
*[[qa-tools|qa-tools Git Repository]]
*[[Testing Cycle]]  
*[[https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib |qa results Git Repository]]


= Archive =
= Archive =
Line 132: Line 141:


[[Category:QA]]
[[Category:QA]]
Please note that all contributions to Yocto Project may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see Yocto Project:Copyrights for details). Do not submit copyrighted work without permission!
Summary:
This is a minor edit  Watch this page
  Cancel | Editing help (opens in new window)
page discussion edit history move watch
Sangeeta Jain talk preferences watchlist contributions log out
navigation
Main page
Recent changes
Random page
search
 
tools
What links here
Related changes
Upload file
Special pages
Powered by MediaWiki
Privacy policy About Yocto Project Disclaimers

Revision as of 05:33, 21 June 2019

Editing QA-wip Bold textItalic textInternal linkExternal link (remember http:// prefix)Level 2 headlineEmbedded fileFile linkIgnore wiki formattingYour signature with timestampHorizontal line (use sparingly)

QA Process

Intro

Given the QA tooling (resulttool) available to manage QA test results and reporting, here is the QA process. First release to implement this process was 2.7_M3_RC1.

This QA process consists below:

Test Trigger
Test Planning 
Test Execution
Test Result Store
Test Monitoring & Reporting
Release Decision

Test Trigger

Each QA team will subscribe to QA notification email (request through Richard Purdie). The list of notifications is maintained on config.json in the yocto- autobuilder-helper which has a branch per release.

Test Planning

Once received the QA notification email, each QA team (eg. intel, windriver, etc) will perform planning on what extra tests they plan to run and when they'll send the results back, then reply to the QA notification email with the planned extra tests and estimate of execution time to QA stakeholders (eg. Richard Purdie, Stephen Jolley), yocto mailing list and the lead QA team. Each QA team can refer to OEQA for automated and manual test cases for their planning. The lead QA team no longer need to setup Testopia and wiki page.

Test Execution

Each QA team will execute the planned extra tests. To make sure test result from the test execution could fully integrated to the new QA tooling (resulttool for test result management and reporting/regression), execute OEQA automated tests and OEQA manual tests through resulttool (refer https://wiki.yoctoproject.org/wiki/Resulttool#manualexecution).

Test Result Store

Each QA team will store test result to the remote yocto-testresults-contrib git repository using resulttool (refer https://wiki.yoctoproject.org/wiki/Resulttool#store), then send the QA completion email (include new defects information) to both QA stakeholder and the lead QA team.

Test Result Repo

After testing is complete, lead QA team will upload test results and test report in yocto-testresults-contrib git repo (https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/log/?h=intel-yocto-testresults) and send QA release mail. This is a staging repo where test results and test report are kept for tests run by independent test teams.

To access test results, clone the repo https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/ and checkout QA branch "intel-yocto-testresults"

For tests run at Autobuilder, test results and reports can be find at https://autobuilder.yocto.io/pub/releases/ inside release version folder.

Test Monitoring & Reporting

QA stakeholder will monitor testing progress from remote yocto-testresults git repository using resulttool (refer https://wiki.yoctoproject.org/wiki/Resulttool#report). Once every QA team completed the test execution, the lead QA team will create QA test report and regression using resulttool, then store the report and regression into https://wiki.yoctoproject.org/wiki/Main_Page. Send email report to QA stakeholder and public yocto mailing list.

Release Decision

QA stakeholder will make the final decision for release. Once decision is taken to release a milestone, RE team will take test results from staging repo and put in https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults/ git repo under same commit id as poky.

Current Release QA info

Tracking info for current release

Current Release QA Test Plans

Test Execution

Autobuilder

The AutoBuilder is Yocto Project's tool for non-manual test execution, it performs the following functions:

  • A scheduled nightly build and test execution that includes:
  • A service for on demand testing requests. (Partially working, feature in progress at request #9880)

Yocto Project QA heavily relies in the Autobuilder thanks to the aforementioned scheduled and on demand test execution features.

Image Testing

In order to execute tests in an image, it is necessary to boot it in either a virtual or a physical target.

Testing Images in Virtual Targets:

The execution in a virtual environment has a nice flow, documented in the Image Tests Enabling... section.

Testing Images in Physical Targets:

For executing tests in physical targets it would be required to:

  1. Boot the image in the target by following the building an image for hardware instructions.
  2. Run the image tests by following the image test or exporting tests instructions.

Setting up Targets with Devauto

Manual instructions for setting up the physical test targets appear in many parts of the Yocto Project documentation (i.e. here). It is easy to setup one target using those instructions but it becomes challenging for the cases where multiple targets have to be prepared or the case where it is required to serialize a changing setup over time, for one: testing on several images using the same target.

Devauto is the Python library and command line interface intended to manage the device automation assets that act upon the target's physical state. Refer to the Devauto documentation for more information about the hardware supported and the library and CLI functionality.

Creating and Adding New Tests

Tests for a given component can be automated in the AutoBuilder. With that purpose, follow the Adding Automated Tests to the Autobuilder Guide.

A list of tests that are automated can be seen here.

Reporting

Performance testing

Performance Test

QA Resources

Archive

You can find the previous QA work by release in the Yocto Project QA Archive.

Other Relevant Data

List of Automated Tests

Please note that all contributions to Yocto Project may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here. You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see Yocto Project:Copyrights for details). Do not submit copyrighted work without permission!

Summary:

This is a minor edit  Watch this page
  Cancel | Editing help (opens in new window)

page discussion edit history move watch Sangeeta Jain talk preferences watchlist contributions log out navigation Main page Recent changes Random page search

tools What links here Related changes Upload file Special pages Powered by MediaWiki Privacy policy About Yocto Project Disclaimers