Keeping a Browser Window Open

Greetings, testers. There's a question I see fairly frequently in the community forums and in the support channels, and it often looks something like this: "How can I keep my browser from closing when a test is done?" What it usually boils down to is that the person asking the question is really trying to do one of two things, at different times during their testing process.

Test Creation

"I want to be able to execute the test, leave the browser open when it completes, and the continue recording the next steps." That's a very normal way of building tests, iteratively working through the steps. You've got a few steps recorded successfully, and want to add more.

The Run To Here command is exactly what you're looking for — just right-click on the last step, choose Run... To Here, and away you go. A browser is launched, the existing steps run, and when they're done the browser is left open with a recorder attached awaiting your further commands.

As of the Test Studio 2013 R2 release Run To Here is cross-browser, meaning that you'll have an opportunity to choose between your installed and calibrated browsers.

Test Execution

The other time that people often want to leave a browser open is during test execution. They've got a test that completes a user task and want to run that test and follow it up with another one. Often this has to do with some setup steps, login for example: "if the correct user is already up and signed in, then I don't want to restart the browser for the next test."

In this case, go ahead and create a test containing all the steps required for a successful login. I would not actually put any validation into this; I'd use a separate set of tests for each of your login scenarios (testing that login works, that it fails properly when given an incorrect password, etc.). You can see an example of this in the Demo Tests project installed with Test Studio.

The test "Login with correct credentials" has all the steps needed to log into the application, without any validation. We're going to assume that this will always complete successfully. You'll just create this once, and if anything changes to the login process you'll only have to modify it in that one place. This would also be a good time to consider encrypting the password so it's not visible to everyone who has access to Test Studio.

For each of your other tests that need to begin with a logged-in user, start by using the Test as Step command.

If you were instructing someone doing manual testing, you'd show them how to log in once. Then all the rest of your tests would begin with "start by logging in, then..." This is exactly the same thing. "Teach" Test Studio how to log in, then just have it do so wherever you need.

Peace,
Steven

About the Author

Steven Vore

Steven Vore is an Evangelist for Telerik's Test Studio. He has worked in software support and testing for the better part of two decades, and enjoys exploring ways to make software easier to use. He is a fan of movies and music, and can often be found on Twitter as @StevenJV.