The Seapine View

“We’re overrunning our schedule and we have to go live now. I know the software’s not perfect but it must be good enough…right?”

If you are responsible for quality that sort of question can be a tough one to answer. Often, there can be a lot of pressure on you to agree that the software is done even if it’s not ready. On the other hand, if you are too cautious you might unnecessarily delay the release which will incur unnecessary costs, miss opportunities, and ultimately the quality team may end up being seen as a hindrance and source of delay.

So how do you decide when it’s the right time to ship? Continue reading…

Unlike a wildebeest, your products are unlikely to thrive in the middle of the herd right now. In challenging economic times, your customers start focusing on value and you need to separate yourself from the herd. I was reminded of this earlier in the week while listening to Activision Publishing’s CEO discuss the gaming market. In responding to a question about current challenges in the gaming industry, Eric Hirshberg had this to say (paraphrasing):

It’s really the best of times and the worst of times for the gaming industry. The top 10 titles are bigger than ever and growing, the part of the industry that is struggling is the “middle class of title.” The middle-budget and middle-rating games aren’t seeing as much interest as they did just a few years ago … There’s no way to market yourself out of a mediocre game.

His point was that quality is the key imperative to a title’s success, and that’s something we’re seeing in every industry right now. The products that best meet users’ needs—and do so reliably—are the products that win in this market.

Continue reading…

On January 19, I presented the ‘Manager’s Guide to Defining Testing in an Agile Age’ webinar. This is the last post in a three-part series I’ve been doing to highlight the key takeaways from the webinar;  get your testers involved early, make your testers first-class participants, and today I’d like to drill down into the third and last area.

Automate testing processes and activities.

In one sense, Agile methodologies were a reaction to the over-tooling of traditional methodologies. Many Agile proponents believe that too much time was being spent operating and collecting data for tools instead of focusing on the actual work to be done.

But automation is essential in many aspects of Agile testing. Automation enables the easy collection and analysis of data that enable testers and other project team members to make decisions about the quality and completeness of work. And testers need to make use of automated defect tracking to make sure a feature is retested when a defect is found, even if the defect is fixed right away.

Continue reading…

If you haven’t been intimately involved in an application development project, this question probably evokes some puzzlement. You ship your software when it’s done, right? Well, maybe. There are a number of considerations that you take into account when deciding when to ship an application—is the coding complete, is the quality there, and is the business ready?

The developers are responsible for determining when coding is complete, while the business owners have to determine if the application is ready to increase revenue or reduce costs.

I’m interested in focusing on the second aspect—the assessment of application quality. We can point to things like defect rate or requirements met as shipping criteria, but those are still ambiguous terms. Any application is going to have defects, and some requirements will be met better than others.

Continue reading…

It used to be that users, or product management, submitted a set of features and requirements to the development team and waited patiently while development constructed exactly what they asked for. Six months later, when users saw this new application for the first time, they realized that what they asked for wasn’t really what they needed. Something had been lost in the translation from what they needed to what they told development to create, to what development ultimately created. “No problem,” development would say when told the existing software didn’t meet a specific need, “we can change that in the next release.” And six months later, it would indeed be changed!

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…

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…

Seapine recently held an event in Huntsville Alabama for military contractors and government employees. The focus of the event was Seapine’s quality-centric approach to application lifecycle management (ALM), and this was an audience where quality mattered.

Continue reading…

Make plans to join us when the Seapine ALM Tour 2010 stops in Huntsville, Alabama on September 23. Meet some of our product management team, see the upcoming Seapine ALM 2011 release, and learn ways to boost agility, collaboration, and traceability! It’s all free!

Continue reading…

Many web applications behave differently depending on what browser the user is using. For example, many web sites will switch to a mobile web interface if the user’s browser indicates that the user is using a mobile platform. Most web applications are designed to fully support all popular browsers. However, you probably want to make sure that your web application responds correctly regardless of the browser. With QA Wizard Pro load testing, you can simulate different user agents during playback to test this behavior.

Continue reading…