How would You Automate This: Profile

With user accounts for various sites being accessed every day, profile capabilities—create, read, update, and delete—may be the most common function on the web. How would you automate them?

As I mentioned in the search article, to be reliable, most tests must start with a known data set.

When it comes to creating profiles, I often use what I refer to as “families” of information for users. I have used examples from television programs, especially anime, so I can readily recognize individuals and see if details about them are not where they should be, as well as their relationships with other people. I can, of course, add to these users’ details, but I also have to be able to return to a known state for further testing.

Another option beyond the “families of information” approach is to create a variety of users with self-referencing data to reflect the names of the fields.

I currently use a system that has a series of steps called “prologue” that creates various users and populates key values, as well as an “epilogue” that removes them. This way, the families of data are where I want them to be.

Common Automation Tricks

One of the challenges I know I will face, especially with creating new users or updating values, is that I will do something that will create a new primary key entry. This can cause problems if examined through subsequent tests, so to keep everything together, I append a value of ${starttime} to all variables. This allows me to create (and later delete) accounts, groups, and users, as well as use the same data set for tests without colliding with other tests. An additional benefit is that performing certain tasks, such as searching for documents, may fail if I do not have the proper permissions.

I may want to automate a failing state. How might I be able to set that up in a way that’s meaningful?

Example:

  • What happens if I create two accounts that are exactly the same?
  • What happens if usernames are based on an email address? Would having the same email address as another user be an issue?

Another challenge with profiles is that they often have required fields. Let’s say I have ten required fields and leaving any of them blank results in an error message. If I only have one test that leaves all the fields blank, and then I fill them all in and confirm it works, that’s too limited a test to be useful. In this case, use a staged level of filling in the fields:

  • Start with zero fields filled in, submit, receive the error message.
  • Fill in three fields and submit again. Confirm error message again.
  • Fill in three more fields and submit again. Confirm the error.
  • Fill in the final four fields and submit again. This time it should work.

These four distinct tests are better than a zero/all comparison but not as tedious as writing ten distinct tests to test each field.

I will also want to verify that I can update fields and confirm that those updates have been made. To this end, again, I recommend updating a few fields at a time rather than trying to write a single test for each field.

If I delete a profile, I want to confirm that it is no longer visible, either by confirming I receive a message saying the account has been deleted or by receiving an error message when trying to view the account in question (the preferred approach will depend on the application).

Things That Are Hard to Automate

Images can be tricky to verify in automated tests. I can upload a profile image, but will I see it? If not, will I still see the default gray non-image? Element inspection helps with this. By inspecting an element to confirm that an image filename exists, I can then do something on the back end to force the HTML to be correct but the image to not appear, making sure the test returns false.

Email validation can be a challenge to automate, but using tools like mailinator.com can streamline the process. Additionally, by using the ${starttime} value as part of the address, each time I set up the email, I can confirm it will be available for that one test. I could also set up a custom email service on my domain. The email interaction does not need to be through a GUI; command line tools to fetch email or a tool like “curl” can grab the text of a web request.

Creating UI-level tests that exercise all error conditions might be a tall order, but these are certainly possible via test automation. Additionally, by creating a variety of automated permutations, those permutations can also be reused with other platforms (iOS, Android, Windows, MacOS, Linux, IoT, etc.).

Common Themes

In this series, there are going to be some familiar patterns and areas that need to be considered for effective testing. Several of these are areas that could be combined into modules, considering I will likely use them frequently.

Permissions

I certainly don’t want anyone to be able to edit anyone else’s profile without the appropriate permissions, so as part of a general test setup, I would create a user, define their permissions, and confirm that I have a way to change or remove those permissions.

Known Data Set

Having a known set of values in place is critical to being able to test for both the presence of values as well as for changes and updates. Tests that will set up default groups and individuals accounts to use for these tests is ideal—and of course, to also remove those groups and individuals accounts at the end of each series of tests.

Follow the Possible Routes

It’s likely that each profile test will follow the traditional CRUD routine: create a user, read/view that user, update that user’s details, and delete that user.

Deliberately Test for Errors

Looking at the test cases created, I want to confirm that a procedure works and ensure I can create conditions where the application fails gracefully. That means writing tests specifically to get a negative outcome.

Examples:

  • Test for users that aren’t there.
  • Test to abandon the workflow (press cancel) and ensure I can still interact with the application.
  • Test to insert an HTML tag.
  • Use non-URL values in webpage fields.
  • Remove permissions for a user in the middle of an edit.

Localization Tests

Include tests that allow me to use international characters and see if they are saved. This can be diacritical characters used with Roman alphabets or using completely different alphabets (Kanji, Hangeul, Cyrillic, etc.).

Cross-Browser Testing is Important

I have noticed that different browsers will respond differently for certain actions, or there will be a sequence that doesn’t quite work the same way. Older versions of IE have often been the culprit, but I have seen Firefox, Safari, and Chrome act differently as well. Test the scripts with multiple browsers to ensure that the steps work the same for each. In the cases that don’t, have browser-specific versions that can be run in those instances.

Download your risk-free, full-featured version of Ranorex Studio now to experience the power of test automation.

Get a free 30-day trial

About the Author

Michael Larsen has, for the better part of his 20+ year career, found himself in the role of being the “Army of One” or “The Lone Tester” more times than not. He has worked for with a broad array of technologies and industries including virtual machine software, capacitance touch devices, video game development and distributed database and web applications. Michael currently works with Socialtext in Palo Alto, CA.

You might also like these articles