Review – Is ‘Login’ an object or not?
by Dima


From one side a “Login” is a Recruiting application object, but on the other hand objects need to use the “Login” object too. What do we do?

It will be more accurate to talk about the “Account” object, where the “Login” is its functional part. When we were building the Recruiting application we did not create the “Account” object and naturally we did not analyse this object at all. Well, we can say now that the “Account” object is a part of the SalesForce platform and we cannot write a full suite of tests for the “Account” object because many functionalities are beyond our exercise scope.

However, if we will include the “Account” object into our test suite as a separate object we can draw parallels between its actions and actions that other objects can perform.

Account registration is by nature an ‘add’ action similar to the Recruiting Web Site ‘New’ button action. Editing and deletion of an account is usually hidden in Preferences or Setting somewhere in UI.

Full suite of tests for the “Account” object in common sense should include – registration, login, logout, account modification (including password recovery) as well as account deactivation (deletion).

Despite all the arguments in favour of not bothering with the “Account” object inclusion and testing I propose to include it (but write tests for login and logout only) because this object will be present in the majority of web applications.

It is time to decide how other objects (Websites, Candidates, Positions) will login to run their own tests. We think that they should not use the “Account” object methods because in this case it will require making the “Account” object special. Other classes will use a simple special method to login into applications as they do now.

Some notes for tests ‘parallelizer’ – if you have two browsers open, logging in one of them will allow to skip logging in the other. On the other hand, if you have logged out in the first browser you will be logged out in the second one too, which may trigger false test failure. Different browsers, and most likely browsers on different computers, can work independently.

What can be tested for login and logout anyway?

1) Incorrect username or password

We are checking both – ability to get in with correct credentials and inability to get in with wrong ones.
Important note for SalesForce implementation. If someone were to attempt to login leaving the username or password blank – you will not get a standard message “Your login attempt has failed…”. You will just stay on the same page without any messages displayed.

2) Attempt to login from fully blank login page (both fields not specified)

Extreme scenario for test (1) above.

3) Logout straight after login

This test was inspired by “YouTube – GTAC 2008 Automated Model-Based Testing of Web Applications” presentation. If you do not have time; scroll and listen from 9th to 11th minutes where presenter demonstrated a bug on United Airlines website.

4) Expired session

Chain – login, enter data, wait for system timeout, attempt to save, compare expected with factual. This will be successful if we can save before expiration. Test will fail if we can save after expiration or can’t save before expiration. Testing can be sped up by setting the system expiration time to the lowest allowed value before running this test.

5) Attempt to login from unregistered IP address

Not so often seen approach which is also quite hard to test. One time I had to wait for two hours for the confirmation email and could not use SalesForce from a new IP.

We decided to implement 1-3, 4 – skip for now (time to complete running tests), 5 – skip (too specific).


1) неправильный логин или пароль

Print this post | Home

One comment

  1. Alexei Lupan says:

    Что можно протестировать при логине? Например: “Тестируем поля логин/пароль“.