SoftwareTestPro.com Requirements Feed

Situational Awareness

matt.heusser@gmail.com — Sat, 15 Dec 2012 10:36:34 -0700

Have you ever been in a place and realized, in a moment, that something was amiss?

“Just Make Sure it Doesn’t Suck” - Good Application Testing Despite Vague Requirements

jeffrey.wharton@neotys.com — Fri, 05 Oct 2012 16:00:00 -0600

Where do I start? What am I doing? Why am I even here? Have you ever asked yourself these questions at the beginning of a performance testing project? Have you been one of the many test engineers who have been delivered an application and told to “just test it?”

The Fuzzy Line Between Requirements and Design

testyt@redwoodco.com — Tue, 23 Aug 2011 08:00:00 -0600

Some people say that requirements re about what you build, and design is about how you build it . There are two problems with this simplistic demarcation.

The “World Series” of Test Requirements

jamieg0926@gmail.com — Tue, 23 Aug 2011 08:00:00 -0600

We first met Jamie in the November/December 2010 issue where she took us step by step through the process of re-engineering a group of testers working on the ROSS project into a productive, efficient team with the emphasis on “team.” In this article, she moves beyond the test team to the requirements team in order to achieve better alignment resulting in improved efficiencies and better design in the end product.

A Lifecycle Approach to Systems Quality

rbaucom@redwoodcollaborative.com — Thu, 23 Jun 2011 16:21:00 -0600

...because you can’t test in quality at the end.

Performance Requirements: An Attempt at a Systematic View

alex.podelko@oracle.com — Wed, 15 Jun 2011 00:00:00 -0600

“Response times (in the case of interactive work) or processing times (in the case of batch jobs or scheduled activities) define how fast requests should be processed.”

Who builds the Test Scenarios?

bsmall@insight.com — Tue, 07 Jun 2011 08:00:00 -0600

My favorite book is Digital Fortress by Dan Brown. Without ruining the book for those that have not read it there is a great quote in the book. The phrase “Quis custodiet ipsos custodes” is Latin for “Who guards the guards” I believe this is from the Roman poet Juvenal. The interesting point here is on an Agile team when the developers build and run unit tests, or even integration tests, who checks these?

Introduction to Jama Software Survey

jrovansek@redwoodco.com — Mon, 07 Mar 2011 10:53:00 -0700

We hope this survey created by Jama Software and Ravenflow on software development is valuable to you and information like this truly helps the industry take a snapshot of latest trends. They surveyed over eight hundred software professionals and focused on industry practices regarding requirements.

Ditch the Requirements - Focus on the Customer Instead

seth_stp@setheliot.com — Thu, 10 Feb 2011 10:00:00 -0700

Quality can be defined as meeting the customers' needs. Juran posted this definition in 1988, defining quality as "fitness for use". Testers like this definition as it gives them a "north star" to guide their actions and it reinforces a role that most testers relish, that of customer advocate. However Crosby's older definition of quality as "conformance to requirements" still holds strong sway, and many test processes are guided by test cases correlated directly to requirements.

You’re a New QA Manager! What’s next?

Mon, 20 Dec 2010 11:30:00 -0700

Congratulations! You’ve just joined a company as the new QA Manager and you’re eager to dive right in and be successful. What will be your first steps besides familiarizing yourself with the applications under test? Our recommendation is to thoroughly review the processes and policies within the company as well as those internal to QA. Your success significantly depends on close collaboration with each of the touch points QA has. Therefore, your first task is to assess these relationships and improve them as necessary. This article will arm you with a “checklist” that will help you with this endeavor.

What's the Real Risk to Our Test Effort?

shaun.bradshaw@zenergytechnologies.com — Thu, 04 Nov 2010 10:00:00 -0600

When planning a test effort, the topic of risk and contingencies typically comes up. Sometimes we answer the call of identified risks by listing boilerplate issues we’ve encountered, or have read about, rather than truly considering what risks are likely to impact the project and more specifically, which risks are likely to negatively impact our test effort.

Drive innovation with a collaborative requirements-driven quality solution

rbaucom@redwoodcollaborative.com — Tue, 02 Nov 2010 09:00:00 -0600

Organizations continue to face an unparalleled rate of change. And while decision makers understand that to be successful their organizations must continually innovate—to seize new business opportunities, achieve key objectives and execute with reduced cost and risk—keeping up with business needs is a constant struggle.

No Requirements? No Problem.

daven.kruse@gmail.com — Sun, 12 Sep 2010 17:49:27 -0600

Solutions to testing without requirements.

Psion Powers-On its Innovation with Qualify

jrovansek@redwoodco.com — Tue, 07 Sep 2010 10:15:24 -0600

Original Software’s new AQM solution provides a Quality Management backbone for Psion Teklogix, enabling better management and visibility of the engineering lifecycle

Configuration Testing Tip

vladimir100@hotmail.com — Tue, 24 Aug 2010 10:24:00 -0600

In my recent paper published in the July/August issue of the ST&QA magazine, I gave tips on improving test coverage

Breaking News!

matt.heusser@gmail.com — Tue, 17 Aug 2010 06:22:53 -0600

Three days left to the get super-early bird rate for STPCon. Matt gives you the real skinny on the conference.

How to Achieve Requirements Traceability

rbaucom@redwoodcollaborative.com — Mon, 16 Aug 2010 08:34:00 -0600

There is often a lack of traceability in many of today’s organizations. This webcast highlights the benefits, tools and processes needed to accomplish traceability.

Baselining Your Testing Team

daven.kruse@gmail.com — Fri, 30 Jul 2010 07:20:28 -0600

Manager's guide on why baselining is important, how it is useful, where to set the line, and how to approach baselining your testers

Requirements Are Like Pornography

Lhayes@worksoft.com — Fri, 18 Jun 2010 13:39:42 -0600

When the Supreme Court of the United States was called upon to distinguish pornography from art, one of the justices famously opined that “I cannot define it, but I know it when I see it”. The conundrum of developing a legally enforceable description of what is and is not an acceptable work of art is disturbingly akin to the challenge of defining software requirements.

Snapshot Survey

rhand@softwaretestpro.com — Fri, 07 May 2010 00:00:00 -0600

Please review the questions and make comments on the survey...

Automated Isn't Automatic

Lhayes@worksoft.com — Sat, 01 May 2010 00:00:00 -0600

No matter how hard you try, you can't avoid the most important and challenging step in the software testing process--the first one. That is, the gathering and defining of requirements that will be tested. That step requires intelligence and skill that no automated testing tool can provide. Read on to find out what can - and can't - be automated.

9 Tips to Survive

c2bb691f8990228@stpcollab.com — Thu, 01 Apr 2010 07:00:00 -0600

Follow these ground rules, based on the author’s real-world experience, to meet the challenges of end-To-end testing.

TQA- Review “The Definitive Guide to Quality Application Delivery” by Don Jones an e-book.

rhand@softwaretestpro.com — Tue, 30 Mar 2010 07:00:00 -0600

If you are part of the STP community you have received the opportunity to download a new e-book, “The Definitive Guide to Quality Application Delivery” by Don Jones sponsored by Micro Focus. This guide is an extremely comprehensive effort, and I have been finding it very helpful in my education about the role of testing in the Software Development Life Cycle. As a quality/testing professional you may find it interesting for different reasons but I thought I would share some thoughts and try to encourage you to take advantage of this complimentary resource from STP on behalf of the book’s sponsor Micro Focus.

This book is a complete guide so I can’t share it all but I chose some excerpts that I found interesting. The book is over 200 pages jammed packed with great resources for the testing professional and all functional roles in the development of quality applications. Don Jones does a great job organizing …

Don't Leave Security for Last

cec1e62c6abde98@stpcollab.com — Wed, 03 Mar 2010 08:00:00 -0700

At the peak of the dot-com boom, my firm consulted extensively for large organizations concerned about the risks of Internet-based applications. My experience with one client in particular—we’ll call it Company X to protect its identity—remains the most palpable argument for integrating security throughout the software lifecycle.

Measuring Confidence Along the Dimensions of Test Coverage

rex_black@rbcs-us.com — Tue, 16 Feb 2010 08:00:00 -0700

When I talk to senior project and product stakeholders outside of test teams, confidence in the system—especially, confidence that the system will have a sufficient level of quality—is one benefit they want from a test team involved in system and system integration testing. Another key benefit such stakeholders commonly mention is providing timely, credible information about quality, including our level of confidence in system quality. Reporting their level of confidence in system quality often proves difficult to many testers. Some testers resort to reporting confidence in terms of their gut feel. They may draw smiley faces and frowny faces on a whiteboard next to major functional areas, and say things like, “I’ve got a bad feeling about function XYZ.” When management decides to release the product anyway, the hapless testers either suffer the Curse of Cassandra if function XYZ fails in production, or watch their credibility evaporate if there are no problems with function XYZ in production. If you’ve been through unpleasant experiences like these a few times, you’re probably looking for a better option…