Firefox Profiles

In essence Firefox profile encapsulates user information: bookmarks, cookies, history, private information, e.g. passwords and so on. Which makes them very useful in many occasions, e.g.

  • Different people sharing the same computer and not willing to create different users on operating system level. Especially with blooming social networks, blogs and other sites where logging in is required, it’s much easier to keep different profiles, than log-out and log-in each time, to each site.
  • Even for the same person who is using the same machine for different purposes, this feature can allow to separate the roles of the machine, from web browsing perspective, e.g. “home”, “work”, etc.
  • Sometimes creating separate profile is also good when working on a specific project which requires a large amount of bookmarks, which can be deleted once the project is complete.
  • Finally profiles are very useful in testing, as they allow to simulate different users without the pain of creating different sessions on OS level

Without further configuration Firefox usese a default profile (in early versions of Firefox you could see it every time you opened a browser). In Firefox 2 or 3, however, you need to start Profile Manager purposely to see the profile you are using and to create/delete additional profiles.

Summary of the commands:

  1. Start Profile Manager
     firefox.exe -ProfileManager

    The switch is not case-sensitive, thus you can type -profilemanager. And in addition you can use -p or -P switch: their meaning is slightly different, according to the command line reference, but they open the same Profile Manager anyways. Usually there’s no need to specify the full path to Firefox (e.g. C:\Program Files\Mozilla Firefox\). With -ProfileManager switch alone, Profile Manager will only start if you don’t have another instance of Firefox running. Thus

  2. Start Profile Manager, while another instance of Firefox is already running, or open Firefox with multiple profiles simultaneously (works with Firefox 2 or higher):
        firefox.exe -P -no-remote

  3. Start Firefox with a specified profile:
        firefox.exe -P "profile name" [-no-remote]

    A -no-remote switch in this case again is only required if another instance of Firefox with different profile is already running.

  4. Create a new profile:
        firefox.exe -CreateProfile "profile name" [-no-remote]

    Once again, -CreateProfile switch is not case-sensitive, and -no-remote switch is only needed if another instance of Firefox is already running.

  5. Create a new profile in the non-default location:
        firefox.exe -CreateProfile "profilename profile_path" [-no-remote]

    Here profile name and path must be quoted together.

  6. Finally, you can start Firefox with a profile, that is not defined through the Profile Manager (useful when you need to test something, with a profile that you recieved, say, from a customer):
        firefox.exe -profile "X:\myprofile" [-no-remote]

  7. And this is how to recreate a default profile

Profiles are defined in the file called profiles.ini, on Windows located in %APPDATA%\Mozilla\Firefox folder. An explanation of the file structure and the meaning of the values is provided on Profiles.ini_file Mozillazine page.

I couldn’t find an official reference to confirm this number, but from what I’ve seen, Firefox allows up to 20 profiles per Windows user.

Firefox Profiles

“End User Experience” Testing

Sometimes running load, usability, functional and UI testing separately is not enough, as it operates on certain sub-set of variables, assuming the others to be static. It’s like projecting a cube in 2d. This is why one of the tests I like to do is “End User Experience” testing: simulating a real user, performing a real set of tasks.


1. Choose a few transactions or scenarios most commonly performed by the users. Say, if I did this type of testing for, I would probably choose “Add New Post”, “Search on site” and few more.

2. Define an overall goal for each transaction. It’s best if the goal is close to what typical real user would do. For example: if an average post length on WordPress is about 240 words, tested transaction “Add New Post” may have an overall goal of creating post with 240 words.

3. Break transactions into steps, and define data for each step: what exactly will you do during the transaction? How will you navigate from step to step? Which options, features, shortcuts you will use? And so on. Since there’s usually more than one way to accomplish the same task, defining those actions is very helpful for the analysis: it takes away the guessing game of “how did I actually accomplish it?” and it also allows to later concentrate on some transactions that are seems problematic. For example: in order to add new post, I may go to Dashboard, or I may just click a “New Post” button from the top menu. My final results may be different depending on how did I accomplish it, and thus it’s important to remember which way it was done.

At this step, we have something like the following table:

Transaction Goal Actions & Data
Add New Post Create post with 240 words
  1. Navigate to Dashboard
  2. Click Add New in Left-side menu
  3. Provide title (4 words)
  4. Type 100 words
  5. Provide link with 10 words
  6. Type 130 more words
  7. Click Publish
etc. etc. etc.


There are many ways to perform this test, for example:

  • Single “experienced” user runs the designed test in normal (not too fast, not too slow) pace, noticing time it took him or her to accomplish different steps of the testing, different inconveniences (was the scrollbar present? Was font too small?) and issues.
  • Same “experienced” user runs the same test, but this time automatic load test is running on background.
  • Same as above, but this time let “novice” user to run the test (how fast he or she will discover how to accomplish steps? How much time the mistakes this user will make will cost him or her? Will their wrongdoing cause any additional problems?)
  • and so on.
“End User Experience” Testing