The Seapine View

One of our loyal readers read my post on third-party reporting with PostgreSQL, in which I referenced Pentaho’s reporting solution. I received an email pointing me to a new book that is all about Pentaho reporting.

The reason I started to look at Pentaho was my quest to find an open source reporting tool that was compatible with any of the database systems we support.  Since PostgreSQL was the only common denominator that is also open source, PostgreSQL support was critical. A tool like this one can be leveraged for reporting across all of our server-based applications.

Continue reading…

In my last post we looked at how to set the fields when you create a defect from scratch using the TestTrack SDK. In this post we are going to take a look at setting the Reported By records, setting workflow events and setting the source control files.
Continue reading…

For those of you that program in Java, there are newly generated TestTrack SOAP classes available for download from the Seapine Labs web site:

http://labs.seapine.com/wiki/index.php/Generated_Java_Classes#Download

As mentioned in the labs article, these classes were generated using NetBean’s JAX-RPC client (v 1.6). While there are other Web Service clients you can use, this is the one that I have been able to get consistent results with.
Continue reading…

In my last post, SQL Is Still Your Friend,  I wrote about using SQL to query TestTrack data.  As a continuation of that thought, I wanted to bring a query tool to your attention: Microsoft Excel.  There are plenty of alternatives to using Excel for queries but it has two major advantages: 1) almost everyone uses MS Office so your spreadsheet is portable and 2) after you retrieve the data from the database, you can use the extensive library of Excel functions to work with the data.
Continue reading…

In this post I am going to take a look at how to create a defect from scratch. You may have this need if you are using the TestTrack SDK to add defects from a custom submission form, or maybe from another tool.

I am splitting this into two posts, given that there is a lot of information to go over. In the first part, I will focus on setting fields. In the next post, I’ll get into more advanced topics, including how to add a workflow event.
Continue reading…

I worked with a developer once who was troubleshooting a defect I found, and after trying to duplicate it his response was “it works fine on my machine.” He was technically correct (it did work fine on his machine), and he wasn’t trying to avoid solving the problem, he was merely commenting that the code was functioning properly on his system. After working on it for some time, we found that at one point in the past he had an older version of the software on his machine which included a library file that was missing from the new version. Hence, when he ran the program it functioned properly, yet on a new install it would fail.

Continue reading…

A good test case describes the steps to be taken to perform a particular test. Most of these steps will involve the application under test, but there are also typically some set-up tasks to do prior to running the test, and clean-up tasks once the test is complete. These tasks may include copying over a fresh set of test data, clearing the browser cache, or killing off any hanging application processes. When you automate a test case you are focused on capturing your interactions with the application and verifying the application’s response, so the set-up and clean-up tasks usually get done manually. By thinking outside of the (application) window you can easily add many of these tasks to a script, saving you even more time.

Continue reading…

This post is a follow up to my first one about Surround SCM triggers and executables.

A few years back, while still working in support I conducted an experiment to really comprehend how executables work when they are launched by Surround SCM as part of a trigger. I wanted to know “where” the script runs, what it considers to be the “current” directory, and whether it depended on the location of the executable.
Continue reading…

• Are you interested in the software quality management and testing world?
• Would you like to hear industry experts speaking about their involvement in real projects?
• Do you want to know the latest trends currently happening in your industry?

Continue reading…

Keyword-driven testing is a testing methodology that allows you to separate the actions that you want to perform from the automated script that executes the given actions. The actions can be entered into a table, such as an Excel spreadsheet, and then run by an automated script. Since the QA Wizard Pro scripting language mirrors these keywords in its own implementation, keyword-driven testing with QA Wizard Pro is easy.

Continue reading…