The Seapine View

For developers that use the TestTrack SOAP SDK for integration or moving data between systems, a common issue is the ability to move HTML-formatted text. The TestTrack SOAP SDK supports HTML-formatted text, but you must add a small section of code to your SOAP application so TestTrack knows you are sending HTML-formatted text.

SOAP expects plain text for multi-line fields by default. Use the following to enable HTML-formatted text support:

ttsdk.formattedTextSupport(cookie, true);

To learn more, see step 9 in the Creating Defects how to scenario.

Thanks to everyone who joined us for the Zen Mastery of the TestTrack SDK webinar. The recording is now available if you missed the webinar or want to watch it again. Q&A from the session follows.

Continue reading…

Thanks to everyone who joined us for the Extending and Automating the TestTrack SDK webinar. The recording is now available if you missed the webinar or want to watch it again. Q&A from the session is below. You can also download the slides and sample code from this webinar.

The next session, Zen Mastery of the TestTrack SDK, is scheduled for October 20th. If you’re already registered for the series, you’ll receive the meeting information in the next few days.

Continue reading…

I wrote a sample application that can send a TestTrack report to one or more email addresses. This is a console application, so you can create a batch file and use Windows Scheduler to run it at pre-determined times. The application is written in C# using the .NET framework version 3.5. The email is sent using the System.Net.Mail namespace, specifically, the SmtpClient class.  If you’re not sure whether this will work in your environment, you can find more information here.

Continue reading…

I got a call from a TestTrack TCM user who asked if you could schedule scripts to run on a continuous scheduled basis, rather than just once. I responded that you couldn’t, mainly because each test run represents a single execution of a test, not a continuous one.

I asked the user for more details in order to better understand the need. He revealed that his group does automated builds and wanted to launch tests after each build and log those results in TestTrack TCM. He wanted to incorporate TestTrack TCM with the automated build process and did not know how to.  So how do you do it? Well the answer will vary depending on your process.
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…

My co-workers and I have documented several ways of getting information out of TestTrack including using the TestTrack Software Developer Kit (SDK).  For this entry, I’d like to focus on a tried and true friend: SQL. The Structured Query Language has been used for over 25 years and it still is a good tool to have.  SQL Server, Oracle, mySQL, and PostgreSQL all have a query tool to easily retrieve data.  The TestTrack Native database has a, ODBC driver so you can use products like Microsoft Access to query.

Continue reading…

In this installment of the TestTrack SDK Helpful Hint posts, I am going to discuss ways to troubleshoot issues when programming with the SOAP SDK.

Basic Programming Tips

If you are using the TestTrack SDK, chances are that you have some familiarity with programming, so the following list is probably nothing new to you:

• Run in Debug mode: If you are in an Integrated Development Environment, chances are you have the ability to use breakpoints and run the application in Debug mode. With the TestTrack SDK, you could see how a CDefect object is being built, like the array of CEvents used in the workflow.
• Print out to console: If you are not in an Integrated Development Environment and do not have access to breakpoints, then you might only be able to print to console the values of variables to make sure everything is being built correctly.
• Keep it simple: Start simple and build up until you run into the issue. For example, let’s say you are writing an application that logs in to TestTrack, gets a list of defects based on field values, gets a number of them for modification, and then logs out. When you run the application you get exceptions. So where is the problem?  Break it down. First, write a simple application that logs in and out of TestTrack. Did that cause a problem?  Then add the code to get the defect list. Did that cause a problem? So you get the idea. You keep building it up until the issue appears again. This should allow you to isolate the issue.

Continue reading…

In part 1 of this article, I  looked at raw performance numbers of the TestTrack SDK. Interesting data but no pretty pictures!

We saw the performance differences between IIS and Apache on the Windows server. If you graph the results though, you’ll see that the difference is very minor.

Chart 1: Apache vs. IIS in calling getRecordListForTable, timing for entire query
Continue reading…

Every so often we are asked for performance metrics on the TestTrack SDK, but unfortunately we don’t have any standard metrics as far as timing and footprint. Performance is also critical for most of the integrations we do and, while we test that on an individual project basis, it would be helpful if we also knew baseline numbers for the SDK itself. JMeter is a tool I’ve been meaning to look at for awhile and I finally found time to take it for a spin. My goal was to compile some statistics on TestTrack SOAP SDK performance and scalability. Quite a lot of possibilities to test but I’m going to look at just record query performance in two posts I’ll publish over the next couple of weeks.

Getting Started

First I had to learn JMeter, and luckily they have quite a bit of quality documentation so the learning curve was minor. It only took me an hour or so to get a simple test plan up and working to pull the project list, login and logoff. Once that was up, it was just a matter of defining the test scenario.
Continue reading…