A Few Thoughts on Test Data | June 2010 software testing newsletter from RBCS

We have some thoughts on test data to share with you as the featured article. If you're working on a project that requires sophisticated test data, this might provide some additional considerations for you.

After years of thinking about an RBCS blog, we've finally launched one. It's a fact-focused spot, and lately I've spent a lot of time on risk based testing, test metrics, and best practices. Take a look, and leave a comment. We've provided more information and an excerpt below. I look forward to seeing your comments there. We also want you to speak up in other ways, as you'll see later in the newsletter.

Have you been to Malaysia? I have, quite a few times, and I always enjoy it. I'm going back for another SOFTEC conference. You can learn more about that conference in the letter.

In addition to this newsletter, RBCS offers a number of other free new media venues for keeping up wth us and our partners, getting valuable discounts on RBCS products and services, and finding useful information about testing. We've got an overview of those venues here.

I hope you enjoy your summer--and our June newsletter.

Regards,

Rex Black, President

Become a fan of RBCS on Facebook and follow RBCS on Twitter to network with other testers, and to receive up to the minute event schedules, news, and exclusive offers and discounts.

Listen to us on iTunes!

Subscribe to our video channel on YouTube!

A Few Thoughts on Test Data

by Rex Black

This article is excerpted from Chapter 3 of Rex Black's popular book Managing the Testing Process, 3e.

A number of RBCS clients find that obtaining good test data poses many challenges. For any large-scale system, testers usually cannot create sufficient and sufficiently diverse test data by hand; i.e., one record at a time. While data-generation tools exist and can create almost unlimited amounts of data, the data so generated often do not exhibit the same diversity and distribution of values as production data. For these reasons, many of our clients consider production data ideal for testing, particularly for systems where large sets of records have accumulated over years of use with various revisions of the systems currently in use, and systems previously in use.

However, to use production data, we must preserve privacy. Production data often contains personal data about individuals which must be handled securely. However, requiring secure data handling during testing activities imposes undesirable inefficiencies and constraints. Therefore, many organizations want to anonymize (scramble) the production data prior to using it for testing.

This anonymization process leads to the next set of challenges, though. The anonymization process must occur securely, in the sense that it is not reversible should the data fall into the wrong hands. For example, simply substituting the next digit or the next letter in sequence would be obvious to anyone it doesn't take long to deduce that "Kpio Cspxo" is actually "John Brown" which makes the de-anonymization process trivial.

View this article in its entirety on our articles page.

The ISTQB Has a New Website

Recently the International Software Testing Qualifications Board (ISTQB) revealed their new and improved website. Check it out at www.istqb.org.

Visit the RBCS Blog!

We are happy to announce the debut of the RBCS blog! For informative installments and an opportunity to comment and interact with the online software testing community, visit our blog page today!

Check out this excerpt from a recent blog posting from the May 27, 2010 blog posting, Software Test Coverage Dimensions: Measures of confidence:

"While not every coverage dimension applies to all systems, you should consider the following:

Risk coverage: One or more tests (depending on the level of risk) for each quality risk item identified during quality risk analysis. You can only have confidence that the residual level of quality risk is acceptable if you test the risks. The percentage of risks with passing tests measures the residual level of risk.

Requirements coverage: One or more tests for each requirements specification element. You can only have confidence that the system will "conform to requirements as specified" (to use Crosby's definition of quality) if you test the requirements. The percentage of requirements with passing tests measures the extent to which the system conforms.

Design coverage: One or more tests for each design specification element. You can only have confidence that the design is effective if you test the design. The percentage of design elements with passing tests measures design effectivity.

Environment coverage: Appropriate environment-sensitive tests run in each supported environment. You can only have confidence that the system is "fit for use" (to use Juran's definition of quality) if you test the supported environments. The percentage of environments with passing tests measures environment support.

Use case, user profile, and/or user story coverage: Proper test cases for each use case, user profile, and/or user story. Again, you can only have confidence that the system is "fit for use" if you test the way the user will use the system. The percentage of use cases, user profiles, and/or user stories with passing tests measures user readiness."

Read the complete blog on our blog page!

June "Rexisms"

Some of you may have heard Rex's sayings over the years. We decided to coin them "Rexisms" for your reading pleasure. So here they are to ponder - some useful aphorisms to help you plan, prepare, perform, and perfect your testing activities, compiled from over a quarter-century of software and systems engineering experience.

Non-functional quality characteristics, such as performance, reliability, and usability, are almost invisible in most software products--until they are missing or bad.

Measuring processes against realistic goals for effectiveness and efficiency is good. Using those measurements to evaluate people is bad.

When I see software engineers trying to make software development easy by magical silver-bullet fixes, I'm reminded of H.L. Mencken's classic quote, "There is always an easy solution to every human problem--neat, plausible, and wrong."

A Call for "Isms"

Have you heard something useful in the test lab recently that you want to share? Is there a priceless tid bit, quote or saying regarding software testing that you would like to publish in our newsletter along side a "Rexism"? If so, please send it to info@rbcs-us.com along with your full name and contact information. "Isms" will be reviewed and chosen by Rex and the staff at RBCS, Inc. "Isms" selected to be published will appear in an upcoming newsletter and be posted on our facebook and twitter pages.

SOFTEC 2010

July 19-21, 2010

SOFTEC is organized by the Malaysian Software Testing Board and is supported by the Government of Malaysia through the Ministry of Science, Technology & Innovations, the Economic Planning Unit, Prime Minister's Department and Standards and Industrial Research Institute of Malaysia (SIRIM) Berhad.

SOFTEC2010 brings together speakers who are industry experts and influential academician who are authorities in software testing. IT professionals, academia, students and business managers will gain knowledge, insights and shared experiences at SOFTEC2010. For more information, visit http://www.mstb.org/softec2010.

RBCS Sponsors Little League Teams

RBCS, Inc was the proud sponsor of two Bulverde Little League Teams for the 2010 season. The coach pitch team, Chix with Stix and the minors team, Firestix, did a great job. Play ball girls!