The Seapine View

One thing I think about is release frequency. How often should we release new, non-maintenance releases of our software? As often as possible? Bi-annually? Yearly?

On the one hand, I like to give user continual improvements. When people come up with great suggestions, especially when they are straightforward, you want to get them out into peoples hands. Customers will sometimes say “How hard can it be to add XYZ” and often they are right (though just as often they aren’t.) Sales and marketing folks often like something new to talk about, but making them happy isn’t always high on my list.

On the other hand, frequent releases can be a hassle for large (and small) companies. You might need to validate that the software doesn’t break something else you use. You might need to push the update out to lots of desktops. And the constant “noise” of releases can be annoying to decide if this release is worth the time of installing.

Continue reading…

TestTrack TCM now has a new quick start guide available! Download it from the Seapine documentation page.

Thanks to Amy Kearns, one of our wonderful technical writers, and the rest of the TestTrack team for producing this great guide.

Even if you’ve been using TestTrack TCM for a while, you owe it to yourself to take a quick look at this document to make sure you are taking full advantage of the power of TestTrack TCM.

Not a TestTrack TCM user?

If you’ve been looking for a better way to manage your test cases and your testing process (especially if you are already a TestTrack Pro user), this document can also help you get started understanding what TestTrack TCM has to offer you.

Please check out the TestTrack TCM Quick Start Guide today and let me know what you think!

This expression means that it is better to try to avoid problems in the first place, rather than trying to fix them once they arise.  If that is so, and I do believe this homily is accurate, then “an ounce of prevention against poor software quality is worth a pound of customer loyalty, and a ton of corporate profits!”

How so?  Well, Seapine Software has now surveyed nearly one thousand software development and QA individuals through our Seapine Software Quality-Ready Assessment and found that 20% of organizations have limited ability to trace software development artifacts and that 19% of organizations do not track project data electronically.  The survey also uncovered that if software organizations release once per year that 34% of those organizations are only on-time and within budget once every four years.  Ouch!  What actions should they be taking to guard against poor software quality?  To find out take a look at our most recent QRA Fast Facts white paper: http://downloads.seapine.com/pub/papers/QRAFastFactsTrack.pdf

I am always asked how I would organize my scripts and workspaces. I am also asked to explain how and when I record my scripts.

Before I start automating I outline the test I want to automate. I then try and break down the test into bite size pieces. If I have a test that requires me to login to my application and create a new contact, I try and view it as two tasks or two scripts. The first task or script would be the login. I first create a new script and record the login process into it. Most tools encrypt your password so no worries. Once my Login script is recorded I then save it as a separate file and store it in an area for either the test or utility scripts.

Creating a new contact sounds easy but my test requires that I iterate through a dataset stored in the company database. My first step would be to record the new script. I enter some sample data into all the fields that I may be testing. This allows the tool to record my entries. After a successful record, I then replay my script. I get it working just the way want it. I am now ready to setup my dataset. Each tool its different, but QA Wizard allows me to select the datasheet I want to iterate. I change the typed text statements and enter the column locations for each controls data point. I run it to make sure it works.

All I have left is to make an executable test. I create a batch adding the two scripts I created. I then send my batch to the scheduler or runtime tool and away we go.

I always try and break down my tests into the smallest bite size chunks. This allows me to reuse them and to make changes without destroying the main areas of my test.

The Wall Street Journal recently featured an article (“Consumers Are Downbeat on Economy” by Sudeep Reddy) that stated “Consumer sentiment about the economy dropped to a 28-year low amid surging gasoline prices, falling home prices and a weakening job market.”  When the economy tightens the ability to maintain a quality-focused customer experience can create a competitive advantage.  But does that theory really hold true as it relates to software development?  Do customers truly care about software quality?  After all, software doesn’t really wear out, spoil, or fall apart.  In fact, sometimes defective software works; as long as it’s used in exactly the same way once the bug is fixed.  So, unless we’re talking about applications that perform critical functions in highly public situations (regulatory and compliance related), such as public transportation, utilities or medical devices, the average consumer may not actually care that much about software quality … right?  Wrong.  Seapine Software has now surveyed nearly one thousand software development and QA individuals through our Seapine Software Quality-Ready Assessment and found that the top two factors driving organizations to focus on Application Lifecycle Management solutions are:

• The need to reduce risk by preventing poor quality from impacting customer satisfaction (23.9%)
• The need to quickly respond to customer requests and requirements (21.7%)

“The need to address compliance and regulatory issues” actually came in last with 5.4% of the vote.  Now don’t get me wrong, FDA regulations or the Sarbanes-Oxley Act, which makes executives personally responsible for the quality of their organizations financial reports, certainly forces executives to focus on accountability, traceability and quality related issues.  But it’s also true that when customers demand quality corporate executives almost always pay attention.  And based on the survey numbers, customers must care a great deal about software quality.

I found this bit of testing humor while browsing the Software Testing Stuff site…

AGGRESSION TESTING: If this doesn’t work, I’m gonna kill somebody.

COMPRESSION TESTING: []

CONFESSION TESTING: Okay, okay, I did program that bug.

CONGRESSIONAL TESTING: Are you now, or have you ever been a bug?

DEPRESSION TESTING: If this doesn’t work, I’m gonna kill myself.

EGRESSION TESTING: Uh-oh, a bug… I’m outta here.

DIGRESSION TESTING: Well, it should work, but let me tell you about my truck…

EXPRESSION TESTING: #@%^&*!!!, a bug!

OBSESSION TESTING: I’ll find this bug if it is the last thing that I
do.

OPPRESSION TESTING: You will test this, now!

POISSION TESTING: Alors! Regardez le poission!

REPRESSION TESTING: It’s not a bug, it’s a feature.

SUCCESSION TESTING: The system is dead. Long live the new system!

SUGGESTION TESTING: Well, it works but wouldn’t it be better if…

PRESIDENTIAL TESTING: Using the definition of testing as defined in the affidavit…

Conversion can be a tricky business. No one wants to convert from one thing to another. It assumes you were wrong in some way. And you know it’s going to be hard. And what if the new thing isn’t really any better than the old thing? Then all that work was for nothing.

Continue reading…

All too often QA is an after thought in the project planning stage. I have taken over many projects that are going the wrong direction or have already turned the corner heading for disaster. One of the many problems that I detect is that QA was never included in the planning phase or the design phase. I receive comments from team members that boggle the mind. “They can plan when we know what it will look like.” This is just plain wrong. I was going to use the word stupid, but I thought it might be too strong.

Planning for success requires a solid team approach. That means that QA is involved with the design phase, as well as, including them in the requirements phase of the project. This statement is even more critical if you have an Automation department. In order for automation to be successful, you must plan for success.
Some areas that are critical to your planning are:

• Identify areas that require larges amount of data entry.
• Discover areas that may have repetitive testing with iterative data.
• Look for areas that may require data validation.
• What area of the application has complex business rules?

These areas all require a great deal of planning in order to be successful with automated testing. Which of these areas that I have identified above is QA not involved? I would argue they should be involved in all of them. My experience tells me that you will save over 50% in script and manual test development if QA can develop their scripts early, even against a prototype.

TestTrack 2008.1.1 was released on May 5, 2008!

Check out the release notes. It’s a simple upgrade if you are already a customer (with up-to-date maintenance). If not, don’t worry. You can download a TestTrack Studio 30 day evaluation.

One of the challenges with any product is how to handle “bad” feature requests. Not every user idea is a diamond in the rough. Sometimes it’s as simple as being very specific to that company/department/users use of the product. Sometimes what they want is counter to what the product is really designed to do. It may just be really, really hard. Or it just may be, in your opinion, a wrong-headed idea.

In any of these cases, what do you do with that idea and how do you convey that back to the user? The typical approach is to respond with something along the lines of “Your input really matters. Thanks for the idea. We’ll definitely consider it.” And that makes everyone feel good, but it’s not entirely truthful to anyone.

Continue reading…