The Deliberate Tester

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:

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.”

test	successful login
open page	http://bigcomp.org/test_system/login
enter	username	peter123
enter	password	pa55woRd!
click	login 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.”

test	successful login
username	password	login?
peter123	pa55woRd!	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?”

test	successful login
username	password	login?
peter123	pa55woRd!	user logged in
alfred567	P4$sw0rD	user logged in
james987	_pass123	user 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.”

test	successful 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

test	successful 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

test	failing 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.”