The Seapine View

Communication between testers and developers is key to ensuring the right information gets to the right people. During testing, a number of bugs will be discovered and those bugs need to be sent to the development team. Also, the more information testing can provide the easier development can trace and resolve the bug in questions. The type of information provided by testing can be very basic from error numbers to screen captures etc.

Continue reading…

In most companies, there are finite software release cycles. There is usually a deadline for a release to make it out the door. Schedules are often driven by business needs, whether it be to produce more revenue or to take advantage of a particular event, such as a holiday. Given a development cycle with a hard stop, it’s up to the team and business owners to decide which features to include in the release and to ensure they are code complete and tested.

It’s not unusual for development to take longer than anticipated, and this can cut into the QA time. This is especially true if QA does not get the first ‘testable’ build until all features are code complete.

However, if developers can provide QA with feature complete (or almost complete) releases earlier in the process, they will be able to start testing those features earlier in the process. The testers have typically completed their test planning and test case development by this time, so they are ready to begin work. Thanks to the ability to get incomplete but functional builds earlier in the process, QA is able to test earlier in the process and, thus, test more.

Continue reading…

A velocity chart shows how many points have been delivered in a sprint in an agile project. The velocity chart is a great tool for sprint planning as well. Knowing how many points your team has delivered in past sprints allows to estimate with confidence how many points they can deliver in future sprints.

TestTrack provides a velocity chart and on this post I am going to show you how to create it.

Continue reading…

I’ve been using Surround SCM since before version 1 was released, and I was always frustrated with searching. Specifically, searching by filename. In my daily life at Seapine, I bounce between working with hundreds of files stored on two Surround SCM Servers. For whatever reason, I was never able to put together the right criteria using advanced find to return the files I was looking for. That has changed with Surround SCM 2011.

Continue reading…

You can test a variety of data with one script by creating a local datasheet in QA Wizard Pro. After the datasheet is associated with a script, the input values are read from the associated datasheet when the script runs. The Local Datasheets How To walks you through creating a local datasheet, associating it with a script or using datasheet statements and functions, and running the script using datasheet values.

Download the Local Datasheets How To now.

If you use a robust software configuration management system like Surround SCM, chances are you are using branches. Changes made in one branch usually need to make it to another branch. Surround SCM offers different ways to merge these changes.

Continue reading…

Large binary files can result in long check ins that tie up the client and affect your productivity. A slow connection to the server can aggravate this. Using the Command Line Interface (CLI) for those check ins can free your client up of this operation and allow you to continue with your work. You can also create a custom menu in Surround SCM to launch a batch file that checks in the file in the background.

Continue reading…

Recently, I’ve found myself saying ‘let’s assume the user…’ more than a few times when discussing documentation projects with the technical writing team. And I cringe every time I say it. There are things that may seem obvious to us, but aren’t obvious to users. So, you’re a user. What would you like to see in the documentation? What should we assume about you and the types of documentation and online help you’d like to see us provide?

Continue reading…

You can use QA Wizard Pro to shorten your testing cycle by combining scripts into a batch file that runs unattended. With batch files, you can:

• Schedule groups of test scripts to run 24 hours a day, 7 days a week for a shorter, more thorough testing cycle.
• Execute regression test suites as part of a nightly build process to ensure application functionality is not compromised by code changes.
• Create unique script batches, including what scripts to include and their order of execution, to test subsets of application functionality.

Download the Unattended Testing How To and learn how to create, configure, schedule, and run a QA Wizard Pro batch file now.

We’ve all read the horrifying statistics around IT project failure—they fail often and sometimes spectacularly! Yet enterprises must continue to build, deliver, and support applications to meet business opportunities. As an alternative to curling up in the fetal position when faced with this dilemma, Agile methodologies and iterative delivery have evolved to address this very problem. Rapidly delivering a few features at a time makes it possible to break a big project down in to smaller and more manageable pieces. It also enables users to validate the software at each iteration, and allows for mid-course corrections to be easily made in response to changing business needs.

Tester’s Dilemma

Testing has always been a weak link in Agile. Traditionally, testers analyze requirements and determine what and how to test while developers are coding the requirements. With Agile, there are no formal requirements and there is no period of down-time while testers wait for testable functionality. In an Agile environment, testers have learn to work from user stories—brief descriptions of how users envision working with the software—and they need to figure out what and how to test pretty quickly.

Continue reading…