Today I offer a time-saving tip for those who has to work on multiple test desktops, including virtual machines.

What do you do when preparing for your test session?

• Opening folders?


• Opening browsers?


• Opening test cases?


• Opening test reports?


• Starting application-under-test?

If each desktop or VM is configured for a specific testing environment, the steps above probably become even more complicated.

• Opening folders: "Well.. let's click "My computer"..then Q:\ drive... then "Projects".. then..."


• Opening browsers: "What ip should I use, again? Is it 13.24.597.68:3397? "

Would you like to have a magic button to bring everything up in one click?



Today you can create one for yourself and your team.

[sourcecode language="bash"]

@echo off

REM Open mailbox
start "QuickTestingTips" "C:\Program Files\Microsoft Office\OFFICE11\OUTLOOK.EXE"

REM Open folders
explorer.exe "C:\Documents and Settings\All Users\Documents"
explorer.exe "c:\project\test cases\module1"
explorer.exe "c:\temp"

REM Open browsers
start "QuickTestingTips" "C:\Program Files\Internet Explorer\iexplore.exe" google.com
start "QuickTestingTips" "C:\Program Files\Mozilla Firefox\firefox.exe" yahoo.com

REM Open bugtracker
start "QuickTestingTips" "C:\Program Files\Internet Explorer\iexplore.exe" jira.com

REM Open documents
start "QuickTestingTips" "C:\Temp\TestReport.doc"
start "QuickTestingTips" "C:\Temp\TestPlan.xls"

REM Start Application Under Test
start "QuickTestingTips" "C:\WINDOWS\system32\calc.exe"

REM Last but not least
start "QuickTestingTips" "C:\Program Files\Internet Explorer\iexplore.exe" softwaretestingclub.com

[/sourcecode]

Instructions

Create a text file on your desktop, and paste the source code.
Save the file and change its extension to ".bat". - You've just created an MS-DOS batch file.
Double-click on it to start it, or right-click and select "Edit" to put relevant parameters.

• Use REM to comment out a line


• Use quotes while supplying an extended syntax path (i.e. with long names and space characters between words)


• Study extended MS-DOS batch file syntax if you want to make your scripts even more powerful


• Store scripts in a shared folder to make them accessible by teammates

Downloads

herewego.bat

On a current project, we have a lot of testing that requires deep domain knowledge. Given the level of domain knowledge, we're planning on getting domain experts to do a good portion of the testing. This has uncovered an interesting opportunity for us. To date, most testing done in this organization has been scripted (giant Word documents full of steps and screenshots). In the past I believe this was done because the testers didn't have the requisite domain knowledge to execute the tests without a lot of help. But now, by making this shift, we can reassess if we really need test scripts.

We've decided that for much of the testing, we'll switch to checklists instead of test scripts. While we might still have a couple of test procedure documents which provide high-level outlines for how to do something, the details of the testing will be in some (relatively) simple Excel checklists. This saves us a lot of work, since we don't need to update a bunch of artifacts. I suspect it will also increase our test execution velocity by reducing the overhead of running a series of tests.

Kaner has been talking a lot recently about the value of checklists. If you've not reviewed the work, check it out. Look for opportunities where you might leverage checklists instead of some of the more traditional heavyweight scripts associated with testing in IT corporate environments.

Today's tip (again) comes from Christina Zaza. Tina gave an experience report recently at IWST, and in that explained that when she sits down to test, she opens everything she thinks she'll need before she starts. This helps her avoid having to wait for something to load, or having to potentially go find something when she's in the middle of testing.

"As dumb as it sounds, stopping to open additional documents and tools right when you need them actually slows down the process."

Her list of things she commonly needs includes:

• opening the application(s) she's testing


• logging into databases databases


• opening data or requirements spreadsheets (or other files)


• opening various testing tools

Today's tip comes from Christina Zaza. Tina gave an experience report recently at IWST, and in that talk she outlined some of the things she does when she sits down to do some "heads down" testing:

• Block off time on your calendar


• Book yourself a conference room


• Consider closing your email and instant messenger


• Let calls go to voice mail

I've noticed a pattern I have when it comes to tracking what I need to get done. I alternate technology, and I think I know why. First, here's the pattern:

• for a couple of weeks, I create small simple project plans for everything (OmniPlan, MS Project, Basecamp, a Google spreadsheet, whatever)


• then for a couple of weeks, I'll use my inbox as my to-do list


• then for a couple of weeks, I'll use pen and paper (post-its, notepads, whatever)

I just keep rotating through these three different methods of tracking work. I think I do it because after a period of a couple of weeks, I stop paying attention to whatever method I'm currently using. For example:

• If my desk is covered with post-it notes, I ignore them. If there's only a couple, I'll do what needs to be done to throw them away.


• If my inbox has five items, I'll clear it. If there's 80 emails, what's ten more?

You see the pattern. I think this is ok, and it's a pattern that apparently works for me - stuff gets done.

If you find you're ignoring your current method of tracking what needs to get done, try switching it up a bit and see what happens.