Toaster testing plan: Difference between revisions
From Yocto Project
				
				
				Jump to navigationJump to search
				
				| Line 14: | Line 14: | ||
==== Functionality tests ====  | ==== Functionality tests ====  | ||
*  [[REST_API_Contracts | REST API]]  verification – create Django tests to detect API calls returning incomplete   | *  [[REST_API_Contracts | REST API]]  verification – create Django tests to detect API calls returning incomplete (fields having null values) or wrong data for a certain set of entries from each table - our goal is to have 90% data collected. The tests can be found [http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=andreeap/toaster-tests&id=7cfd179be5db2a5530d60093fd09d0240138c2fa here];  | ||
*  Calculation of the data collection rate - the ratio between the number of the variables having null values and the total number of variables collected (the data collection rate does not include wrong values);  | *  Calculation of the data collection rate - the ratio between the number of the variables having null values and the total number of variables collected (the data collection rate does not include wrong values);  | ||
*  Verify that all links in the simple UI are available;  | *  Verify that all links in the simple UI are available;  | ||
Revision as of 12:09, 15 January 2014
Introduction
This article is the test plan for Toaster.
Objectives
The test process focuses on:
- validating the data collected from the build process;
 - verifying the correct functioning of the Toaster GUI; TBD
 
Test Areas
Toaster consists of two big components, as follows:
Backend
Functionality tests
- REST API verification – create Django tests to detect API calls returning incomplete (fields having null values) or wrong data for a certain set of entries from each table - our goal is to have 90% data collected. The tests can be found here;
 - Calculation of the data collection rate - the ratio between the number of the variables having null values and the total number of variables collected (the data collection rate does not include wrong values);
 - Verify that all links in the simple UI are available;
 - Verify the quality of the data collected through the simple UI;
 - Verify the quality of the data collected by verifying most of the values from the database by connecting directly to the database - our immediate goal is to have 90% correct data collected;
 
Usability tests
- Verify the easy usage of Toaster (easy to install and start/stop the toaster server)
 
Frontend
Functionality tests
- Manual testing in the first stage;
 - Automate testing using Selenium, in the second stage;
 
Compatibility tests
- Verify the behavior of the GUI on different browsers and operating systems; TBD
 
Usability tests
- Verify if the GUI design is as described here: http://yoctoproject.org/webhob;
 - Friendly graphical user interface;
 
Performance tests
- Stress testing (e.g. display appropriate error messages when the system is under stress);
 
Test Cycle
| Test execution cycle | ||||
| #Weekly Test | #Full Pass Test | #Release Test | ||
| Build type | Weekly | Yes | Yes | |
| Release | Yes | Yes | Yes | |
| #Test Areas | #Backend | Yes | Yes | Yes | 
| #Frontend | Yes | Yes | Yes | |
| Target machine | qemuarm | Yes | Yes | |
| qemumips | Yes | |||
| qemuppc | Yes | |||
| qemux86 | Yes | Yes | Yes | |
| qemux86-64 | Yes | |||
| Target image | core-image-minimal | Yes | ||
| core-image-sato-sdk | Yes | Yes | ||
Weekly Test
- Scope
 
- Images built weekly and released through the distribution team.
 
- Objective
 
- Functionality test on most areas with minimum sets of tests;
 - Regression test with high probability to find bugs.
 
Full Pass Test
- Scope
 
- Images built as candidates for milestone or final release;
 - Passed #Weekly Test
 
- Objective
 
- Ensure functionality of Toaster component.
 
Release Test
- Scope
 
- Release candidates that pass #Full Pass Test
 
- Objective
 
- All scheduled features are covered, or rescheduled;
 - All relevant bugs are fixed and verified.