12 6 deployment test plan
|
·
#1701
· Opened by TimLovellSmith 21 days ago |
Pull Request #1700: Refactoring - Easier rebranding of the site
|
Component: Config
· Re-brand the site from NuGet Gallery through config, verify new welcome message. · Scan the site, make sure all references to "NuGet Gallery" are replaced. · Artwork is pulled from the Content folder and is all in one place. · Verify through proof on concept re-skinning the site. · Re-write the entire front page using partial pages. · Geopolitical Art Review · Verify across browsers (IE7+, C, FF, S, O) · Accessibility spot-check · Screen reader compatibility (JAWS, NVDA) · E2E: Cover scenarios in Custom Gallery Deployments. |
|
|
·
#1685
· Opened by claycompton 24 days ago |
PR #1738.
|
Component: UI
· Verify across browsers (IE7+, C, FF, S, O) · Accessibility spot-check · Screen reader compatibility (JAWS, NVDA) |
|
|
·
#1601
· Opened by anurse 2 months ago |
- |
- |
(Note: not a feature, but we should see how QA can help out here.) |
|
·
#1585
· Opened by claycompton 2 months ago |
Pull Request #1697: In theory this will fix #1585... font awesome in IE7 - now how to test it? |
Component: UI
· Verify across browsers (IE7+, C, FF, S, O) · Accessibility spot-check · Screen reader compatibility (JAWS, NVDA) |
|
|
·
#253
· Opened by dotnetjunky 2 years ago Issue #1594: Remove code obsoleted by Credentials table Issue #554: NuGet Gallery should support LDAP for on-premise deployments |
Prior versions (reference): Pull Request #562: Support for LDAP authentication Pull Request #1597: [Final Code, but not ready to merge] Credentials Table Current version: Pull Request #1739: Fix #253 by providing support for Microsoft Account Login |
Component: UI
· Check values of new config settings (Auth.MicrosoftAccount.Enabled, Auth.MicrosoftAccount.ClientId, Auth.MicrosoftAccount.ClientSecret), verify behavior and error handling · Re-run AccountManagement scenarios with NuGet accounts, linked accounts, and MSA-only accounts. · Verify package audit records and field data for downloads. · From site · From NPM · From command line · Verify API v1 endpoints. · Consume passwords with both hash types (SHA1 and PBKDF2) for linked accounts · Verify access to user account settings on linked and MSA-only accounts through both NuGet and MSFT Acct login · Re-verify API Key scenarios (push and delete) for linked, unlined, and MSA-only accounts. · Add and remove credentials, verify e-mail notifications. · Geopolitical Art Review · Sanity testing for user identification where two user sessions share an IP address. · Sanity testing of MSFT Account name and current e-mail address not matching. · Sanity testing of a user's MSFT Acct matching an abandoned NuGet user's account address. · Run Andrew's test scenarios listed below. · Verify across browsers (IE7+, C, FF, S, O) · Accessibility spot-check · Screen reader compatibility (JAWS, NVDA)
Andrew's testing notes:
Testing this feature requires a few extra hoops. First, be prepared to use Private Browsing modes often. Once you have associated an MSA with an NGA, in order to sign in using a different MSA you have to either 1) Wipe our your cookies 2) Log out of ALL Microsoft Account sites or 3) Use Private Browsing mode (I recommend 3 :)). Also, always open a brand new Private Browsing mode window when starting to test with a new MSA, as it appears that tabs within a Private Browsing window sometimes share cookies (?). In general, the following high-level elements should be tested: · Nothing has changed about API Key and Password auth, all existing scenarios there should work · Logging in with a never-before-seen MSA which has an email address that has never been registered with an NGA. ==> This should yield a register/signin flow · Logging in with a never-before-seen MSA which has an email address that IS registered with a current NGA. ==> This should yield a signin flow for that email address · Logging in with previously-seen MSAs should immediately log you in to the associated account · Entering invalid data at any point should produce the expected validation errors without interrupting the flow. · From the Manage Credentials dialog it should be possible to do the following: · Add a password to an account which was created via MSA login · Remove a password from an account that also has an MSA associated · Remove an MSA from an account that has a password associated · Remove an MSA from an account that has a second MSA associated (see next item) · It should never be possible to remove all MSAs/Passwords from an account, there must always be at least one MSA or Password associated · It should be possible to associate multiple MSAs using a flow like the following: · Log in to NuGet using MSA 1, associate with NGA alpha · Ensure NGA alpha has a password associated with it · (New Private Browsing window) Log in to NuGet using MSA 2, associate with NGA alpha using its password · You should now be able to use either MSA 1 or MSA 2 to log in to NGA alpha · You should see MSAs 1 and 2 on the Manage Credentials page. Please take extra care to ensure you are using the correct MSA before authenticating. Maybe even just assign each MSA you want to use for testing to a different browser engine (Chrome, IE, Firefox, Safari, Opera, etc.) :)
Bug Bar
This is just my (anurse) opinion, but the bug bar should be something like the following: 1.If a bug aborts the MSA linking flow but does not corrupt data and the user is able to retry the flow, having corrected the error -> Bug 2.If a bug corrupts the MSA linking flow and makes it impossible for the user to recover -> Ship Blocker 3.If a bug allows MSAs to be associated to incorrect users -> Ship Blocker
|
Note: Includes Migrations. |
