1. Overview
1.1. Purpose of this Document
This document outlines the plan and scenarios for testing the vendor portal for the SFO release of Microsoft’s Software Licensing & Protection Service.
1.2. Related Documents
Title |
URL |
Microsoft User Interface Guidelines |
http://ui/ |
Design elements and screenshot mockups for SFO can be found here: |
|
2. Feature Overview
2.1. Feature Description.
SLPS Licensing & Protection technologies are primarily targeted at Independent Software Vendors that need to license and protect their products. Then vendor portal is the primary tool used by ISVs to define their products and associated features and how these features will be packaged and licensed.
2.2. Feature Goals
· Vendor can order a private permutation by using this feature.
· Vendor can issue license for their products.
· Vendor can define the multi type for his license by changing the settings.
· Vendor can manage licenses (reissue/delete/export/activation) using the portal.
· Vendor can add his own customer.
· Vendor can change their password.
2.3. Feature Non-Goals
· Verify at client whether the license can work as it defined.
3. Scope
3.1. Testing Overview.
Testing will focus on functional and boundary testing of various scenarios identified for the personas that consume the Vendor Portal. A secondary aspect of testing will be ensuring that the UI goals of the portal have been met.
3.2. Goals.
· Execution of all identified P1& P2 Vendor Portal test cases.
· Testing scenarios listed for each persona identified as a consumer of the portal.
· Testing authentication and authorization security build into the portal.
· Automating P1 cases that can be automated through web automation.
· Stress testing the vendor portal is a P2 goal.
3.3. Non-Goals
· Testing of the server API is not a goal for this spec; server API testing is covered in a different specification.
· Automating all scenarios is not a goal for the SFO release.
· UI performance.
4. Open Issues
The security is needed? (firewalls, encryptions, passwords, etc.) will be required and what is it expected to do? How can it be tested?
5. Approach
5.1. Functional
The functional testing of Vendor Portal listed the some test cases to the user work flows.
· The vendor can signs up a new account from SecureLM website.
· Vendor can log into the suite if he got the credentials.
· Allowable vendor who with existing credentials to receive a reset password via email.
· Vendor can navigate to SecureLM Suite and log in after enter username and password.
· The vendor can get the permutation notification mail after he ordered permutation in SecureLM Suite.
· Visual Studio user logs into the Portal UI and can create limited number of licenses.
· Portal UI enables vendor to add features/feature set into the product.
· Vendor Portal enables vendors to bind licenses to machine IDs Boundary.
· Portal enables vendor to define perpetual, trial, subscription license types.
· The vendor portal can normally display in other browser except IE. (e.g. Firefox)
1.1. Error Handling
The following table describes possible error conditions that should be handled with explicit messaging to the end-user. Generally, we should not generate errors which refer to stack trace, asserts or code specific language.
Message |
Event |
Type |
Invalid username or password. |
User/password is not correct when login. |
Critical, user needs to start over. |
Passwords don’t match. |
The vendor changes his password. |
Critical, user needs to start over. |
Please select the record. |
When user to edit some records before a record be selected. |
N/A |
Please input the right character. |
Input the information to some textbox for adding or searching. |
Critical, user needs to start over. |
Sorry connection Time Out. |
The time is too long to get the response from user for the browser. |
N/A |
The descriptions get off default maximum length. |
Input the description for record. |
Critical, user needs to start over. |
The maximum/ minimum must be integer and between…and… |
Input the number to the property of license. |
Critical, user needs to start over. |
Please upload one file the type of is LRI. |
Upload an invalidation file when manual activation a license. |
Critical, user needs to start over. |
The Device Id is invalidation. |
The device changed by user. |
Critical, user needs to start over. |