Equivalence classes for password strength meter

Question

As an example of password strength meter I use the code from GitHub. Firstly, it calculates the score by adding or deducting points according to the length, whether a password contains numbers, chars, username or repetition. And then in accordance with the score a password strength is returned. Below you can find the function returning the strength.

function scoreText(score) {
  if (score === -1) {
    return options.shortPass;
  }
  if (score === -2) {
    return options.containsField;
  }

  score = score < 0 ? 0 : score;

  if (score < 34) {
    return options.badPass;
  }
  if (score < 68) {
    return options.goodPass;
  }

  return options.strongPass;
}

I define the equivalence classes as follows:

• {score = -1, short password}
• {score = -2, contains field (username)}
• {score < 34, bad password}
• {score < 68, good password}
• {score >= 68, strong password}

Can these classes be considered appropriate and adequate for testing? Or is it better to define the classes as categories such as "the password length is less than the min length", "a password has 3 symbols", "a password has upper and lower case" and etc?

Answer 1

The answer depends on perspective. If you want to only unit test this function, then you're on the right track with your example equivalence classes you have defined. Although, you are missing some. I'd recommended using boundary value analysis technique in addition to equivalence partitions -- these 2 techniques often go hand-in-hand.

If you stick with this unit test based approach, I'd also add:

• score < -2
• score = 0
• score is between 1 and 33 (just pick some number in this range)
• score is between 35 and 67 (just pick some number in this range)

The second part of your question is around user experience or user interface perspective. This is also a good option to test, so your examples of "the password length is less than the min length", "a password has 3 symbols", "a password has upper and lower case" should be tested.

Think of the testing triangle. Create lots of unit tests (at the bottom of the triangle), some integration tests (in the middle), fewer UI tests (at the top). They are all important areas to test as they can unveil bugs in different ways.