Hi all We (Nokia and Intel QA Leads) had 2 days meeting in Shanghai and we were discussing many QA related items during the 2 days. I shortly informed QA community about the meeting in the Weekly QA Meeting and promised to create short summary about topics discussed. So here it comes, pretty raw, not all notes, but this high lights topics discussed. We can give further clarification on topics discussed in next QA Weekly meeting, so let's have a short q&a session next time.
MeeGo 1.2 Operative issues Test Plans (or specifications) for MeeGo are located in http://Testplans.meego.com Test Plans needs to be walked through for validity, there are several gaps in the usage of the fields. Findings and issues discussed are in Test Set attributes section of the minutes. - Example of Invalid Plan: http://testplans.meego.com/mcts/mcts-baseos-nb-tests/src/testinfo.xml.html - AGREED: We will starting writing bugs against test plans - NOTE: Some of the created bugs might lead to new feature requests to used test management tools. - AP May: Rise discussion about the naming test plans and test specifications in qa-mailing list Test Case and Test Set attributes: We walked through the test xml field usage in real life against the target state and we faced many misunderstandings / mistakes in usage of the fields. We agreed several actions to start the reviews of the asset. We agreed that we will start rising bugs also about the misused or blank fields. We agreed that following discussions needs to be started: - Feature field / AP Jari: Start discussion with Product Management about usage of the feature field. First step is to create QA Proposal for the feature usage discuss it with PM and the discuss on meego-qa mailing list. Approval in MeeGo QA Weekly meeting. NOTE: From QA perspective it would be good to link it to architecture - Requirement / AP Jari: Verify from QA-Tools lead Ville Ilvonen which field is used in qa-reports.meego.com for linking test case to requirements in Featurezilla - Domain field usage / AP Jari: Agree this with Product Management and discuss on qa-mailing list. Approval from QA Weekly meeting. - Domain field usage should follow Eric's definition: http://meego.com/developers/meego-architecture/meego-architecture-domain-view - On UX side: Domains == "application" and Component == [application name] - Test Type: - These are not defined properly today: http://wiki.meego.com/Quality/TestAreas - NOTE: Jari is the owner for the test type definitions - AGREED: Jari will fine tune the list and get first official version "approved" by asking comments from qa-mailing list and getting approval from QA Weekly meeting During the discussion we also agreed that - QA-Reports approach needs to be re-think before automation will flud the tool, from visibility view perspective - AP Niko: Discuss this with QA-Tools owner Ville. How do we separate automation reports in reporting and rise feature requests accordingly. To Procedures list we need to prioritize also Test Case verdicts - http://wiki.meego.com/Quality/Glossary - This is priority issue to be agreed in MeeGo QA Weekly - Handled in QA Weekly 2011-01-11 Execution road mapping - We have a release test execution roadmap here: http://wiki.meego.com/Quality/Plans/Test-execution - AP Jari: The list needs to be re-planned and reviewed with RE. - NOTE for Tools back-log: Current release info is coming from Release Management and we should be capable of linking all test reports executed for the image - AGREED: Test Road mapping tool needs to have link to qa-reports after execution (manual work) - IDEA: We need to have a view in QA-Repots to show all the executed tests for that particular build/image - AP Jake: Feature request needs to be addressed towards QA-Tools Key Events: - Defined in http://wiki.meego.com/Release_Engineering/Milestones - Visible in release plan - should be in also in Test Road mapping tools - QA Targets not defined measurable level nor followed-up => We need in future the tracing towards MM-Targets - AP Jari & V-PV: create better definitions for MM quality criteria and ask for approval for those - We need to start proper definition creation from MM3, which is next MM in MeeGo 1.2 - Proposals to be handled in QA Weekly Testing tools approach The tools has base on Core automated testing and single team approach. At the moment for Core Program QA situation is good. But for UX Manual testing situation is not optimal. Current tool chain support all the needed actions to be done, but there is room for improvement in multi-team / community test execution of the test cases. The situation is very understandable due to selected approach and the current situation in MeeGo, we have been doing this from 1.0 onwards, which is like half a year. - Example issue: Selecting test cases for the daily execution is very heavy process for Manual UX testers These topics were widely discussed and we shared the understanding. QA-Tools team has done a good job to get tools up and running. Now we need to discuss on how we can ease up the Manual UX testing work. OTS Deployment in MeeGo QA Testing Target is to have 2 different separate OTS system: - Internal OTS (Used by QA and RE) - Community OTS (could be used by anyone) - Not in place today Internal OTS is up and running as a system. Intel QA has developed flash support for Netbooks, which is not in use in Internal OTS hosted by IT. May's team is working on the topic together with IT. We have also issues with Creation of Images which would contain proper test packages. Jari will initiate the discussion about the package content with RE Team. V-PV --- Veli-Pekka Vatula MeeGo QA Lead _______________________________________________ MeeGo-qa mailing list [email protected] http://lists.meego.com/listinfo/meego-qa
