Difference between revisions of "QAAutomation"
(→Test cycles (categorys)) |
|||
| Line 2: | Line 2: | ||
The OOo QA Automation Team has the main responsibility to assure stability and quality of the whole OOo/SUN Staroffice. The automated GUI testing provides a test framework with test scripts and an application (VCL TestTool) to test almost the whole office application automatically. The VCL TestTool scripts are written in BASIC with some additional functions especially for the office. The VCL TestTool communicates via TCP/IP with the office application. To start the GUI testing it is recommended to download the scripts (TestTool Environment) and the VCL TestTool application for the platform where you want to run the tests. | The OOo QA Automation Team has the main responsibility to assure stability and quality of the whole OOo/SUN Staroffice. The automated GUI testing provides a test framework with test scripts and an application (VCL TestTool) to test almost the whole office application automatically. The VCL TestTool scripts are written in BASIC with some additional functions especially for the office. The VCL TestTool communicates via TCP/IP with the office application. To start the GUI testing it is recommended to download the scripts (TestTool Environment) and the VCL TestTool application for the platform where you want to run the tests. | ||
| − | = Test cycles ( | + | = Test cycles (category's) = |
Meanwhile there are a lot of automated tests available. With this number of tests it would last nearly 1 week to test 1 build completely. After all automated tests passed the testers have to verify the results...this will take also some time. Because of this conditions the QA Automation Team decided to create a test cycle that covers a meaningful number of tests run on each build. | Meanwhile there are a lot of automated tests available. With this number of tests it would last nearly 1 week to test 1 build completely. After all automated tests passed the testers have to verify the results...this will take also some time. Because of this conditions the QA Automation Team decided to create a test cycle that covers a meaningful number of tests run on each build. | ||
| + | The outcome of this category's are 4 in numbers | ||
| − | [[Category:Quality Assurance] | + | 1 : Tests run on all builds and releases |
| + | 2 : Tests run on the first build (plus tests from category 1) | ||
| + | 3 : Tests run on the second build (plus tests from category 1) | ||
| + | 4 : Tests run on the third build (plus tests from category 1) | ||
| + | |||
| + | To make it easy for all involved the rules what type of test is included in what category is not strict documented. Except category 1 which holds all automated tests required for release testing (mostly resource or update-tests). For all other 3 category's it should be observed they have the approximate duration. This model shortens a test cycle for each build to a maximum of 2,5 days. | ||
| + | |||
| + | [[Category:Quality Assurance]] | ||
Revision as of 09:39, 29 June 2007
About QA Automation
The OOo QA Automation Team has the main responsibility to assure stability and quality of the whole OOo/SUN Staroffice. The automated GUI testing provides a test framework with test scripts and an application (VCL TestTool) to test almost the whole office application automatically. The VCL TestTool scripts are written in BASIC with some additional functions especially for the office. The VCL TestTool communicates via TCP/IP with the office application. To start the GUI testing it is recommended to download the scripts (TestTool Environment) and the VCL TestTool application for the platform where you want to run the tests.
Test cycles (category's)
Meanwhile there are a lot of automated tests available. With this number of tests it would last nearly 1 week to test 1 build completely. After all automated tests passed the testers have to verify the results...this will take also some time. Because of this conditions the QA Automation Team decided to create a test cycle that covers a meaningful number of tests run on each build. The outcome of this category's are 4 in numbers
1 : Tests run on all builds and releases 2 : Tests run on the first build (plus tests from category 1) 3 : Tests run on the second build (plus tests from category 1) 4 : Tests run on the third build (plus tests from category 1)
To make it easy for all involved the rules what type of test is included in what category is not strict documented. Except category 1 which holds all automated tests required for release testing (mostly resource or update-tests). For all other 3 category's it should be observed they have the approximate duration. This model shortens a test cycle for each build to a maximum of 2,5 days.
