Tester Challenge: what do you do to test reset password

Testers, here is a challenge:

Show the world, what do you do to test reset password?

1 Like

It depends…
Can you be more specific, how does this specific password reset work? SMS code? Email link? Something else? It’s a bit broad as it is.

1 Like

Yep, let’s say what if it comes through as an email link.

Sorry, not entirely sure what format these would generally be given in.

It’s already been mentioned the question is vague so I will make a few assumptions also I’d usually try and test each page in isolation and this could certainly be broken up into individual tests. However while I check most pages separately I do find it fun and sometimes useful to occasionally follow the full user journey. We have something similar for our sign up that requires validation a couple of times so doing the journey is the easiest… at the moment. Actually 3 separate dynamically generated links / codes to sign up.

Assumptions
Pre existing user - with email address, possibly a password recovery question that we need to know

Recovery Password link is tested as part of the Sign In testing

visit Password Recovery page

  • Check UX (all elements that are required on the page as well as validation and alerts)
  • Provide email address and or security question
    This could be expanded to invalid email formats and unregistered users
  • Submit

Poll for email

  • Copy Password Reset link generated

#this is where the argument for silo’ing the test would probably come in.
visit Password Reset page

  • Check UX (all elements that are required on the page as well as validation and alerts)
    Focusing on special chars and password requirements
    As well as both text fields matching
    Special requirements might include not pasting the password
    That the text fields are actually password fields
  • Check end state (sign in page or other) after submission

Could make an argument to test sign in with the new credentials to ensure the journey worked E2E

You could also test this all separately by mocking or checking the database or payloads.

3 Likes

I like Kurt’s detailed thinking. I prefer to split it into 2 test cases, one for the UX, and one for the business logic triggers. The logic is easier to test using a simple script that just does the E2E.

  1. cause user password to become invalid (try login x times) basically verify user is locked out
  2. visit password reset page, visit reset link
  3. wait for email (or whatever process)
  4. visit link (or whatever process like typing in SMS code)
  5. Enter new password (or simply login successfully)

And then go and structure some UX test cases around that workflow, by adding them into the specific stages as “implementations”. This “drop-in” idea only works if you have a test FW that lets you run arbitrary kinds of code inside a test. So my preference is to test the end result, not the UX at all to begin with. You might find, the only UX testing you want to prioritize, is for translation and accessibility analysis?

I know step #1 is not mandatory, but it’s part of exploring the “page” or dialog, that links to step #2. And that’s a step still in the user journey.

1 Like

As noted there are a number of scenarios. Let’s assume we are smoke testing the basic happy path. You come to the website, you have forgotten your password and you want to get a reset password link via email.

Automating going to the website, clicking the forgot password link, giving it your email address should be straightforward. The big problem most people face is how do you get the email. The answer is set up an email SMTP server.

You don’t need something really elaborate. Just Google Search for “python smtp server” and you should find a number of StackOverFlow links for creating an SMTP server using Python. It is usually a few lines of code. Some of the examples will store the emails in the file system, some will require you to retrieve them from a web interface. Use what works for you. If you are putting the email server on the same machine as the tests, the tests can just access the file system to get the emails. If the test environment is distributed then use an example SMTP server with a web interface.

Because the email server is locate and simple, it will be fast and easy to use. Now the test is simply, click the reset password link, have it send a reset link to the SMTP server, retrieve the email from the SMTP server and open the link in a browser.

Darrell

1 Like