The Deliberate Tester – Chapter 5: Logged In

Back in 2011, I approached Rob Lambert at the Software Testing Club on a small series, packed into a narrative format as I wanted to try that out. Rob decided to run that series on the Software Testing Club back then, and I had some fun writing it. Skip forward 11 years, and the Software Testing Club no longer exists, it’s been a while since I have been in touch with Rob, yet I figured, let’s see how this series aged over the years. As a sort of throwback Friday for myself, I will publish the entries on a weekly basis, and read along with you. I think I ended up with eight chapters in the end and might add a reflection overall at the end. In case you want to catch up with the previous parts, I published these ones earlier:

The Deliberate Tester

Chapter 5: Logged In

“Ok, April, tell me about the business rules for the login.”
“Alright, Peter. Users may log in using a previously created username and a password. The username is given by the system administrator. Any letters or digits shall be allowed. The password has to include at least two letters, at least two digits, and at least one symbol, while being at least 8 characters long.”
“So, this is also checked at the login screen?”
“Yes. To avoid a security hole storing wrong passwords in the database.”
“In that case, shall an email be dispatched to the administrator?”
“Not in this iteration, yet. We will add that functionality in some weeks.”
“So, up until now we have got simple logins with valid passwords that should work, and we got some of the rejected passwords, and of course, we got invalid username and password combinations. What else is there?”
“That should serve as a first list of test ideas, yeah.”
“Alright, then let’s get these rules automated.”

“Let’s start with a password that is too short.”
“Shouldn’t we do the successful login test first? If the most obvious functionality isn’t working, then we don’t need to focus on rejected passwords at all.”
“Yes, you’re right.”
“So, let me sketch the first test.”

testsuccessful login 
open pagehttp://bigcomp.org/test_system/login 
enterusernamepeter123
enterpasswordpa55woRd!
clicklogin button 
loginResult=xpath//tr[td/id=’log_not’]
assert equals${loginResult}user logged in

“Ok, Paris, but this looks too technical to me. Let’s try to rephrase the test in terms of business rules.”
“You mean, like what?”
“Here is what I have in mind.”

testsuccessful login 
usernamepasswordlogin?
peter123pa55woRd!user logged in

“Oh, that looks nice, really. Now that table reflects the business rules of the login very clearly, and we should be able to express login error test cases in a similar format very easily.”
“Yes, I didn’t think of failure tests so far. Let’s try to add some more successful tests first.”
“Ok, how about this?”

testsuccessful login 
usernamepasswordlogin?
peter123pa55woRd!user logged in
alfred567P4$sw0rDuser logged in
james987_pass123user logged in

“Wait a minute. Does the username really matter?”
“Oh, you’re right. I think we can rewrite this by just listing up the valid passwords since the login result is the same all the time.”

testsuccessful login
valid passwords 
pa55woRd! 
P4$sw0rd 
_pass123 
pass123_ 

“Yes, that’s even greater. But still, I think we may improve it. What do you think about this one?”

### Variables

${aShortPassword} P4$sw0rd
${aMediumPassword} MediumPassword12$
${aVeryLongPassword} APasswordThatIsVeryLongAndContainsAtLeast2NumbersAndEven1Symbol%

### Tests
testsuccessful login
valid passwords 
${aShortPassword} 
${aMediumPassword} 
${aVeryLongPassword} 

“Now, that’s a bit more readable, but we also found an open question. What is the maximum length for a password?”
“Oh, we’ll have to clarify this. Let’s write it down on our notes, so we may get back to Eric with all the open points together.”
“Fine, now let’s take a look at passwords that should be rejected.”

### Variables

${aTooShortPassword} a12§$
${aPasswordWithNoSymbols} Password12
${aPasswordWithJustOneNumber} Passw0rd$
${aPasswordWithNoCharacters} 123$5678

### Tests
testfailing login
rejected passwords 
${aTooShortPassword} 
${aPasswordWithNoSymbols} 
${aPasswordWithJustOneNumber} 
${aPasswordWithNoCharacters} 

“That looks fine. Let’s add some more passwords that should be rejected, and then we can bring in the automation code to drive these.”
“Yes, and we need to write some more tests for valid and invalid usernames as well. But I think we may re-use the format from the passwords by then.”

At the end of a busy day, April and Peter visit Eric’s office to show him their list of open questions.
“Eric, we made some great progress with the test automation today. But we also identified some open points regarding the functionality.”
“That sounds great. What about the open points?”
“Oh, we stumbled upon the question of what the maximum password length should be.”
“Ok, I’ll get you an answer tomorrow. So, how did collaboration between programmer and tester feel today?”
“It was fantastic. I’m sure we’ll have the tests up and running by tomorrow. That should also speed up our programming, as we can detect unwanted changes in related areas by then.”
“Awesome. I’ll see you tomorrow then, I suppose.”

  • Print
  • Twitter
  • LinkedIn
  • Google Bookmarks

One thought on “The Deliberate Tester – Chapter 5: Logged In”

Leave a Reply

Your email address will not be published. Required fields are marked *