Browse Prior Art Database

Optimal content sequence in test scenario reflecting real-life product usage

IP.com Disclosure Number: IPCOM000241070D
Publication Date: 2015-Mar-24
Document File: 2 page(s) / 51K

Publishing Venue

The IP.com Prior Art Database

Abstract

Internal (in-lab) decisions (like: QA activities, release prioritization, risk mitigation) very often do not reflect real life product usage scenarios. In other words customer use our products differently than we think about it. Such situation leads to many issues not considered during product release cycle. That also leads to poor product quality and unsatisfied customers. Problems: · Short release cycles enforce for risk management and risk mitigation. To create good mitigation plan it is necessary to understand which product components are being utilized most frequently. · Prioritization of components by customer license type to support release management · Identification of enhancement requests to address in first place · Optimizing test plan and execution to match real life product usage

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 01 of 2

Optimal content sequence in test scenario reflecting real -

-life product usage

life product usage

Existing solutions like:
customer feedback gathered by beta forums, services and sales representatives (then provided to the test team in free forms: emails and/or conference)

UI based tools recording customer actions on web applications (ready for playback - for example Java scripts) have the following drawbacks;
no standard/formalized output
mis-communication between customer and sales/services teams
difficulties with test scenario design/creation - human errors / gaps
missing mapping with existing data like: defects, features, test scenarios

Customer's actions are being saved as a map of keys in runtime by product. Each map is associated with particular customer. Thanks to the keys in a map it is possible to estimate each product decision impact to customers before release.

Key is a set consisting of component, sub component and impact values provided by development team during implementation process (in repository tools). For example UI(component)-loginAction(sub component)-capability(impact).

Key mapping database - correlation map between keys and source files (is generated automatically using repository items like defects, tasks - each item contains key and changed code).

Key mapping database is also extended by manually added annotations in the code (annotations describes component-subcomponent-impact value).

Thanks to that map and code execution information prog...