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.

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.


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