The Seapine View

I recently got the chance to perform some usability tests on QA Wizard Pro. Besides the large amount of useful information we pulled out of it, it also conveniently gives me something to write about. I’ll split the information up into a few parts containing some of the more useful lessons learned.

Part 1: Pre-Test

We didn’t arbitrarily decide to run general-purpose usability tests, we had a specific goal in mind. We had recently discussed (at length) and then changed the way scripts were recorded. Out of the available options our choice seemed to be the clearest available, so I continued and implemented it. Most (maybe all) of the QA Wizard Pro developers hated it to varying degrees. Still, they were willing to concede if it’s really what the customers wanted. But we had no way of really knowing what the customers would want, or what potential customers (as first-time users) might think of it. Or did we?

It was suggested that we could just grab some Seapine employees who had never used QA Wizard Pro before, and have them be usability testers. It sounded like a great idea, so I brought it up and we decided to make it happen. I asked around, trying for some prime candidates. Ideally, we wanted someone from QA (as they would be our target audience) who had never used any version of QA Wizard before. Unfortunately, all of the QA department had gone through training on each Seapine product, so all of them had had some experience with it. So, we ended up with a couple developers.

Next up, how do we get them to test what we want? The original script had something like “Record a script where…”, but we decided early that that was too much information. We wanted the users to find the menu items by themselves to see if the wording, placement, etc. of the menu items was appropriate. We created goal-oriented tasks instead asking the user to accomplish something using the product.

Lastly, we wanted some way to record what was going on with the screen, and ideally anything that our test user said as well. For the sake of speed and convenience, a software solution seemed ideal, so I took a look at Camtasia. QA Wizard Pro however also does recording, so I was a little worried about Camtasia recording the user using QA Wizard Pro recording a recording. Seemed like a lot of recording all going on at once. Luckily, a little testing showed that my worries were unfounded and it all would work smoothly together.

With all of that ready, a fresh install of QA Wizard Pro and Camtasia on a computer, and two willing candidates, we were set to test.

So, in summary, lessons learned from the pre-test:

• Don’t make tasks that lead the user exactly where you want them to go. Make goal-oriented tasks and see how a user would actually try to use your product to accomplish those goals.
• Recording the screen and sound proved quite useful. We used Camtasia, and it worked perfectly.

So, did the usability tests get us what we were looking for? Stay tuned for part 2.

Surround SCM offers a workflow to give users a clearer view of the state of files. Furthermore, it can be used to marry the source code tool with an existing process in place.

This article will show how to use the workflow from a basic peer review code process to a continuous integration process. We will combine simple workflows to create more complex workflows.

Finally, we will discuss how to further enhance the workflow.

Refer to the Surround SCM user guide for further details on how to set up the states and transitions for the workflow. This article assumes that you already know how to set up a basic workflow.

While this example only covers software development processes, the Surround SCM workflow is flexible enough to accomodate other processes as well.
Continue reading…

Surround SCM’s merge logic (which usually allows auto-merging of files without requiring the user to manually merge files) used in promoting must always promote the “tip” version of the files, this is the latest version of the files.

In some occasions the version of the file that the needs to be promoted may not always be the “tip” version.

The following article will show how you can take a specific set of files and a specific version and merge them into another branch.
Continue reading…

Guiffy is the integrated tool provided with Surround SCM that is used for viewing differences and merging of text files.

A nice feature provided by Guiffy is the ability to compare two folders. This allows you to select any two folders and compare them recursively. You can also drill down to a specific file and view differences of this file between the two folders.
Continue reading…

One of the most extensible features of the TestTrack triggers functionality is the ability to execute scripts when a trigger activates. From within the executing script, you can pull pretty much any piece of information from the object that triggered the script, via environment variables.

Problem is, your defect object isn’t the same as my defect object or another user’s defect object. This makes it impossible for Seapine to provide a standard answer when you’re wondering how to get the value of a custom field, specific event or some other field in the object.

Some of the standard fields are covered in the next sections, or you can create a trigger in TestTrack to provide you with that information for your installation.

Continue reading…

This article includes information for how Surround SCM reports can be automated and posted on an intranet for employees to view the detailed history of files and also changes to files within the last 30 days.

This is a simple example that could be expanded with more complex reports and a more complex script file.
Continue reading…