Proposal For MeeGo 1.2. This plan is under review. actively revising and updating
This is overall test plan for MeeGo Core of MeeGo open source project, which defines test scope, test strategy, test configurations as well as test execution cycle for MeeGo Core. It will give readers an overview of validation activities for MeeGo Core of MeeGo open source releases. A series of component test plans will also be linked in this overall test plan to cover the detailed test approaches and test design for ingredients of MeeGo Core stack. It will be the joint effort from MeeGo community.
This plan describes MeeGo Core OS QA for MeeGo 1.2 and onwards. Test plan is revised for each MeeGo Release and thus this test plan should be considered as evolving document. New testing methods, practicalities and approaches are described in revisions.
Objectives in MeeGo Core OS QA is to validate the functionality of entire MeeGo Core OS software delivery by performing hourly, daily and weekly testing for weekly releases. More information about testing cycle and test types can be found later in this document. Target is to ensure that:
For these activities MeeGo Core OS QA follows iteration cycle and process described in Release Engineering’s release timeline at: http://wiki.meego.com/Release_Engineering/Process
As addition to fast cycle testing more thorough testing (Full Pass) is done for MeeGo Releases. Full Pass testing is massive test execution for entire test asset available at the moment. With full pass all features are re-verified and regression is measured. This activity is taking place after MeeGo Release Feature Complete. Target is to ensure that:
For these activities MeeGo Core OS QA follows release cycle described in Release Engineering’s release timeline at: http://wiki.meego.com/Release_Engineering/Release_Timeline
Overall the MeeGo Core Testing will cover the MeeGo OS Middlewares layer and MeeGo OS Base layer in MeeGo Architecture:
Specific features to be tested will be aligned with the features under MeeGo Core OS Features product in MeeGo Featurezilla
Following feature category won't be covered in MeeGo Core validation for MeeGo open source releases.
In order to use resources efficiently and control risk level on component maturity. Testing is done in different levels as follows:
Go to MeeGo Core Test Suite for details
MeeGo Core will be tested from the following different test execution levels.
It's for Trunk:Testing. It will run a portion of fully automated test cases for core components and aims to provide quick acceptance testing to support incremental packages integration. It will be conducted under OTS (Open Test System).
It's for Trunk. It will run all fully automated test cases for core components and aims to identify the regressions as early as possible. It will be conducted under OTS (Open Test System).
Weekly Testing is a test cycle against the weekly images released from distribution team. Usually the test frequency is twice a week, which aligns with distribution's weekly image release cadence.
It's an incremental testing and includes two parts in general: test the basic distribution health to report out regression, test new features when they are ready for testing. We will also do bug verification and regression test which is set of tests to verify that changes from the last build (code enhancements, bug fixes) don't introduce new issues to the previous working code. The purpose of weekly testing is to early test the new features, to track critical/major issues got fixed in timely fashion, and to report out the overall quality status of the whole image so that people could understand where we are.
In the formal test cycle for milestone test, after a new build passed the BAT test, test team will start the full validation testing for it, following test will be involved:
This is a set of tests to verify that changes from the last build (code enhancements, bug fixes) don’t introduce new issues to the previous working code as well as new features work as expected. This cycle include the tests for previous major bug fixes and areas of the code that will be affected by new implementation.
The regression test will be taken in following test cycle: