Skip to content

11 1 Deployment Test Plan

Jump to bottom
claycompton edited this page Oct 23, 2013 · 12 revisions

  • #1669 monthly downloads statistics line graph should have tool tip for actual amounts to be seen

  • Opened by johnataylor 8 hours ago

      </td>
  <td>

Pull Request #1668: initial commit

    </td>
    <td>

  • Verify tool tips across browsers (IE7+, C, FF, S, O)

  • Culture-specific scenarios for decimal separators:

    • German
    • Hindi

  • Accessibility spot-check

  • Screen reader compatibility (JAWS, NVDA)

      </td>

  • #1659 Integrate Microsoft.Owin.Security

  • Opened by anurse 5 days ago

      </td>
  <td>

    • Pull Request #1667: Integrate Microsoft.Owin.Security

        </td>
    <td>
    • Verify Andrew's test note scenarios (below)
    • Perform P0 scenarios with RequireSSL turned on and off on the server.
    • Log in and log out, verify cookies through Fiddler
    • What is https://claims.nuget.org/apikey?
    • We register the route "OwinRoute"
    • Try to upload with multiple API Key credentials in the table -- I think we throw up, but it's good to double-check
    • What happens if two users ever have the same API Key? How do we handle the error?
    • Fail authorization, verify error message (password and API Key)

    Andrew's Test Notes - Create some SHA1-password users before deployment (I'll send out instructions) - Log in with various users having PBKDF2 ("new") and SHA1 ("old") passwords, verify that SHA1 passwords are replaced (instructions to come) - Log off and try to directly hit a URL like "/account", verify redirect to login page and redirect back to "/account" after login - Upload packages through the GUI - Upload packages through NuGet push API - Use NuGet push with no API Key -> Get Username prompt - Use NuGet push with bogus API Key -> Get Forbidden response - Use NuGet push with API key that doesn't own package -> Get Forbidden response - Log in, then navigate to "http://[nuget site root]/" -> Redirects to SSL Homepage - Log off, verify that the following Cookies are NOT present: ".AspNet.Cookies", ".ForceSSL"

        </td>
</tr>
<tr>
    <td>

    • #1648 Background image is not shown for the error page layout Priority - 2 3 - Merged to Dev

    • Opened by TimLovellSmith 10 days ago

        </td>
  <td>

    • TimLovellSmith referenced this issue from a commit 10 days ago TimLovellSmith Fix #1648 - error page looking wrong with no background image. 4da78f3

    • TimLovellSmith referenced this issue from a commit 6 days ago TimLovellSmith Merge pull request #1649 from NuGet/tilovell/1648-fixErrorPageLayout … fbb4cf8 Fix #1648 - error page looking wrong with no background image.

        </td>
  <td>

    • Verify with different error pages (404, 500)

    • Verify across browsers (IE7+, C, FF, S, O)

    • Accessibility spot-check

    • Screen reader compatibility (JAWS, NVDA)

        </td>

  • #1647 Unlisted Packages' pages erroneously show notice that a prerelease version is available Priority - 2 3 - Merged to Dev

  • Opened by claycompton 10 days ago

      </td>
  <td>

    • Pull Request #1654: Fixes # 1647 - erroneous message that a newer prerelease package is avai...

        </td>
    <td>

    • Verify repro scenario

    • Verify all combinations of latest, pre-release, and pending edit on different packages, verify correct messages are shown in each case.

        </td>

  • #1646 Packages don't appear on users' /account/Packages pages if all versions are unlisted 3 - Merged to Dev

  • Opened by claycompton 11 days ago

  • Issue #1645: Getting error page while trying to open "my packages" page.

  • #1370 Manage my packages page broken Priority - 1 3 - Merged to Dev

  • Opened by bhuvak 3 months ago

  • 1 comment

      </td>
  <td>

  • Pull Request #1624: Manage packages page / user profile broken

  • Pull Request #1653: Tilovell/1370 manage packages page broken for bhuva

      </td>
  <td>

  • Upload multiple versions of a package, unlist all of them, verify latest unlisted package is shown for the package page.

  • Unlist selected versions of a package, verify:

    • Consistent preference for latest listed version on package page
    • Verify all version pages load without error

  • Upload multiple versions of a package, unlist selected versons, verify unlisted versions are visible on owner's manage packages page

    • Unlist latest version
    • Unlist oldest version
    • Unlist intermediate version
    • Unlist all versions

  • Verify all combinations of latest, pre-release, and pending edit on different packages, verify correct messages are shown in each case on both package and package version pages.

  • Verify across browsers (IE7+, C, FF, S, O)

  • Accessibility spot-check

  • Screen reader compatibility (JAWS, NVDA)

      </td>

  • #1620 Client side issues for invalid urls on verify package page Priority - 2 2 - In Review

  • Opened by TimLovellSmith 19 days ago

  • 8 comments

      </td>
  <td>

    • Pull Request #1658: Tilovell/1620 url validation problems on verify page

        </td>
    <td>

    • Hack invalid URLs in the NuSpec file and confirm E2E experience with uploading in the Gallery

      • Icon URL
      • Project URL
      • License URL

    • Different kinds of errors:

      • URL is too long (>4000 chars)
      • Wrong protocol
      • Invalid escape sequences
      • Zero-length
      • Not an object / 404

    • Verify equivalent experience with 'nuget push'

        </td>

  • #1608 Sign In / Register Feedback Priority - 2 2 - In Review

  • Opened by jeffhandley 24 days ago

  • 1 comment

      </td>
  <td>

    • Pull Request #1660: Update the registration/sign-in process in line with Jeff's latest feedback

        </td>
    <td>
    • Verify each of the scenarios in Jeff's original bug.
    • Verify across browsers (IE7+, C, FF, S, O)
    • Accessibility spot-check
    • Screen reader compatibility (JAWS, NVDA)

    From Jeff's bug:

    1. Change "Sign in" to "Register / Sign in" and add a tooltip that says "Register for an account or sign in with an existing account"

    2. Change "Email" label on Register to "Email (gravatar, notifications, and password recovery)" with "gravatar" being a link to gravatar.com

    3. On the "Thanks" page, above the "Now that you..." text, show the user's gravatar and username - and add a link to "View Profile" to drive people to that page and their API Key

    4. On the "Thanks" page, move the Confirm your account to be the 1st bullet

    5. On the "Thanks" page, remove the "set up your profile" link

    6. On the "Thanks" page, make "Upload Package" a link in the text

    7. On the "Thanks" page, change "Confirm your account" to "Confirm your email address so that you can publish packages or contact package owners" - this is more clear, and it also covers the "wrong email for gravatar" scenario

    8. Change Email Address page needs to show what the current email address is.

    9. [Next Sprint] Perhaps merge the Change Email Address page into the Edit Profile page, with the form hidden until you click the "change" link. Then the "Cancel" link would just hide the form again. The hard part will be managing state when the password is entered incorrectly.

    10. The link to gravatar.com on the Edit Profile page is coded directly to http://en.gravatar.com - it should just be www.gravatar.com

    11. Confirmation Required needs to say "upload a package or contact a package owner"

      </td>

    • #1594 Remove old code from Credentials table

    • Opened by anurse a month ago

        </td>
  <td>

    Pull Request #1597: [Final Code, but not ready to merge] Credentials Table

        </td>
    <td>

    • Verify sanity scenarios before and after populating the credentials table.

      • Viewing API key
      • Resetting API key
      • Nuget push
      • NuGet delete
      • Password change
      • e-mail address change
      • e-mail confirmation

    • Force a user to have more than one valid-looking credential in the new credentials table, verify scenarios above.

    • Force a user to have no entry in the credentials table, verify handling of core scenarios above.

        </td>

    • #403 Change the version-less package page to show the latest stable, while giving users a good indication that there's a pre-release version available Priority - 1 3 - Merged to Dev Epic - Site Redesign

    • Opened by half-ogre 2 years ago

    • 7 comments

        </td>
  <td>

    Pull Request #1626: Tilovell/403 latest stable should be default package version seen

        </td>
    <td>
    • Create packages whose versions have the following attributes:
      • Latest version is pre-release
      • Last two versions are pre-release
      • Last version is unlisted
      • Last is unlisted, previous is pre-release
      • Last is pre-release, previous is unlisted
      • All versions are unlisted
      • All versions are pre-release
    • Navigate to package page (without version) and verify package details
      • Enable and disable license details (can we test this?)
    • Navigate to package version details, verify package specific details (like casing in the name)
    • Navigate to Report Abuse / Contact Support / Contact Owner with and without version number in URL, verify details shown match the version expectation.
    • Edit Package with and without version number, verify expected data loads, and verify E2E scenarios.
      • Apply changes, verify
      • Undo changes, verify
    • Use NPM, verify package version shown matches versionless expectation in Gallery.
    • Verify API methods from nuget.exe:

      • Delete package

      • Push package

      • Install package
    Clone this wiki locally