Hi, Thanks for opening this discussion. See my comments down there having Jari: at the beginning.
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of ext Arto Sinnelä As mentioned in today's QA meeting, Jari and I have commented something regarding these on bug 12965 (mainly about the usage of "requirement" and "feature" attributes). To summarize, to me it seems that there are no clear decisions available yet on the discussion items mentioned above. Please let me know if there are. Otherwise I hope we could agree on these soon in order to communicate and clarify the practices, and update our QA tools where needed. Jari: You are expecting decision by whom? Vatula as head of QA or shall we have consensus as resolution this email thread? Surely having this big picture known and communicated helps tooling and testing to have common goal to aim. I'd personally prefer this current practice over using "requirement" for featurezilla ID AND "feature" for feature name if that means that a test engineer / community member doing the test planning should provide the feature name. In my opinion, test engineer / community member who wants to create test cases for certain featurezilla items should not need to provide some meta data about the features but focus on actual test planning. We already have too many attributes to be entered in test plans, which makes test plan writing rather laborious and not very interesting for community members. Jari: For me the intent for fields (from meego.com QA point of view) might be following: - Feature - text field describing the functionality tested. For this I would like to take one example from http://meego.com/developers/meego-architecture/meego-architecture-domain-view where "Multimedia domain provides audio and video playback, streaming, and imaging functionality to the system.". I suppose we need to include Product Management and Architecture to these discussions - of course one possibility is to have "Master" features in bugzilla to include functionality items and then only IDs can be used here and requirement field might come obsolete. I'm not aiming to have only one list to be used by whole community - I would like us in meego.com QA to have one common one in order to be able tell what works and what does not with terminology that could be understood by non-technical people too. Other groups then have possibility to define other lists with maybe finer details. - Requirement - field to have feature or bug ID's as comma separated list. This enables the linkage between tests and bugs.meego.com items. - Component - I would like this to be used by Projects more than by Meego.com QA. Component here shall be the ones in bugzilla (and architecture). Auto-population from bugzilla might be good idea here (drop box populated or component selected according req or ...). - Domain - Having this might be handy when we start to have a lot of features or components tested with a one test set. It can be use for grouping giving "managerial" view. Domains are defined in architecture, but unfortunately today we do not have these in our tooling (e.g. bugzilla). Or do we? So Arto - Was this kind of data in your mind (to be communicated with the decision)? And for community member I would say that these are not mandatory ... but having something on these field might help to tell the story with test session report. Based on my previous experiences, it is very difficult to get everyone to use exactly right feature names etc so I'd prefer a solution where this kind of data would be linked automatically to featurezilla items. Although, I assume that this is not yet possible e.g. for domain names (?). Jari: I totally agree with you on auto-population as much as possible. And I'm not seeking for one and only list for Feature names for everybody, maybe just for Meego.com QA in order to tell what works and what does not similar way for all the verticals. Then we can maybe start to compare functionality statuses between verticals (e.g. Core OS vs. Handset). Br, Jari _______________________________________________ MeeGo-qa mailing list [email protected] http://lists.meego.com/listinfo/meego-qa
