CALL FOR PAPERS: Conference of the Association for Software Testing

Posted by Ben Simo

CALL FOR PAPERS
The 3rd Annual Conference of the Association of Software Testing (CAST) 2008

Toronto, Ontario, Canada, July 14-16, 2008


Beyond the Boundaries: Interdisciplinary Approaches to Software Testing

Keynote Presentation by Gerald M. Weinberg

The Association for Software Testing is pleased to announce its third annual conference (CAST 2008), to be held July 14-16. The meeting will be held in Toronto, Canada, a city which features enormous diversity in culture, businesses, educational institutions, and the arts. Toronto is the perfect location for a conference on this year’s theme: "Beyond the Boundaries: Interdisciplinary Approaches to Software Testing".

Interdisciplinary approaches draw from diversified branches of learning or practice, such that insights can be drawn upon and synthesized to influence a particular craft. The CAST 2008 Program Committee is now seeking papers that explain how one, two or more disciplines might assist with software testing.

Examples could include ways in which statistics and metrics combined with critical thinking can help software testers interpret performance test results; ways in which logical thinking combined with document design and modeling help testers better understand business requirements and execute functional tests; or ways in which research in human/computer interaction might influence usability testing.

Apropos of this theme, the Association is delighted to announce that the first of our keynote speakers will be Gerald M. Weinberg, presenting a talk entitled Lessons from Past to Carry into the Future. Fifty years ago, in 1958, Jerry established the very first separate software testing group, to aid in producing life-critical software for Project Mercury. Jerry will speak of many steps, done and not yet done, needed to complete the task of creating a true software testing profession.

Both academic research papers and industrial experience reports are welcome. The following (non-exclusive) list suggests topics of interest that the Committee would consider highly suitable for submission:

• General systems (e.g. modeling, non-linearity, complexity)
• Mathematics (e.g. probability, statistics, combinatorics / permutations, graphing, metrics, equivalence partitioning)
• Epistemology (e.g. logic, lateral thinking, critical thinking, experiment design, decision making)
• Cognitive science (e.g. biases, perception, descriptive decision making, human factors, dynamics of heuristics, learning)
• Communication (e.g. rhetoric, document design, writing)
• Visualization (e.g. graphical presentation of test results, display and presentation of test data)
• Interdisciplinary approaches to teaching software testing

In addition to looking for papers that demonstrate an interdisciplinary approach to software testing, we’re looking for personal experience reports that clearly demonstrate skills and practices of seasoned software testing professionals. We’ll be looking for rich, diverse experiences and intriguing papers that illuminate the theme. If you have hands-on experience and a fascinating story to tell, contact us and we will assist you in evolving your tale so it will be ready to present at CAST.

CONFERENCE FORMAT

CAST is designed as a forum to stimulate discussions leading to innovation in software testing, and so is distinguished by significant interaction among presenters and attendees. Papers and experience reports accepted by the program committee are challenged, debated, and discussed by the conference attendees. We encourage and facilitate conversation by building flexibility into the schedule so that topics generating high energy can be explored more deeply without adversely disrupting the course of conference events. Trained facilitators will ensure that discussion sessions are appropriately structured and productive. Discussion sessions will have a recorder, and transcripts or summaries of the discussions will be made available to participants after the conference.

SUBMISSIONS

CAST 2008, although not associate with ACM, encourages authors to follow the ACM SIG Proceedings style, freely available at http://www.acm.org/sigs/publications/proceedings-templates.

We expect a typical submission to be between 4 to 6 pages long. All papers should be submitted electronically in PDF format via email to: CFP@associationforsoftwaretesting.org

Authors of accepted papers will receive complimentary registration to CAST 2008. Papers will be published in the conference proceedings. Authors will also be invited to submit their papers for inclusion in a future edition of the Journal of the Association of Software Testers (JAST).

IMPORTANT DATES

• Monday Feb 4, 2008 : Deadline for abstract submission
• Monday February 25, 2008 : Notification of acceptance/rejection to authors
• Monday March 17, 2008 : Submission of revised paper integrating the reviewers’ comments
• Friday April 4:, 2008 : End of the second period of reviewing
• Monday April 28, 2008 : Final camera-ready papers due
• July 14-16, 2008: Conference

CONFERENCE CONTACT

For further information about CAST 2008, please contact a member of the conference committee as listed below:

• Sponsorship: Scott Barber, executive.director@associationforsoftwaretesting.org
• General Conference Information: Michael Bolton, cast2008(“at” symbol)michaelbolton.net
• Program: CFP@associationforsoftwaretesting.org

Evidence That Quality Has Everything To Do With Value

Posted by Ben Simo

“Quality is value to some person.”

Gerald Weinberg,
Quality Software Management – Systems Thinking

This morning, Jason Gorman's blog post title Proof That Value Has Little To Do With Quality? caught my attention. This title contradicts my definition of Quality. To me, Quality is all about value to stakeholders.

Quality is not about implementing the best development practices. Quality is not about writing solid code. Quality may not be about impressive features. Quality may have no relation to elegance. Quality may not even be reliable. Quality may be cheap or it may be expensive. Quality may be well planned or it may be haphazard.

Quality is all about value. Quality is about value to people that matter.

Jason references an interesting article about a web site that started as a learning exercise and "seems to come from the Anti-Perfectionist School of Design", yet is profiting its creator millions of dollars annually. In spite of many flaws, this web site is profitable because users find it valuable and users bring advertising dollars. I consider this to be a high quality web site in spite of its obvious flaws because it has value to people who matter. Instead of viewing this as an example of value having little to do with quality, I see this as a great example of Quality having everything to do with value. I suspect that Jason and I define Quality differently. This story is an example of how value sometimes has very little to do with all the other things we often call Quality.

Perhaps my thinking is too touchy-feely for those who think we need to measure and assure Quality through quantitative metrics and processes enforcement. By it's very nature, quality is subjective. Sometimes we can quantify the results of Quality: as in the $10 million in annual advertising profits. I suspect that some of you are subjectively estimating how better metrics and process might lead to better profits.

The real measure of Quality is a measure of value (not necessarily quantitative value) to those who matter.

"As professionals, we have no real control over the ultimate value of the software we create. And neither do our customers, or requirements analysts, or product owners, or whoever it is who's been charged with figuring out what the best use of the budget would be. It's all guesswork, like choosing lottery numbers or selecting which horse to bet on."
- Jason Gorman,
Proof That Value Has Little To Do With Quality?

While there is guesswork in determining who matters and what they value, it is not as random as selecting lottery numbers. Better understanding of who matters and what they value can help us reduce the guesswork. Ongoing dialog can bring better understanding. If Quality is nothing more than a lottery, then we might as well limit ourselves to BUFD and scripted manual testing.

Interactions, collaboration, and responding to our changing understandings can help us take control over Quality.

"Above all, listen to what your customers are telling you about Quality. ... Your customers are in a perfect position to tell you about Quality, because that's all they're really buying. They're not buying a product. They're buying your assurances that their expectations for that product will be met. ... Your customers may not have all the hard business facts. They may not be aware of your specs and your standards and your inspection reports ... They may not be able to give you a precise definition of Quality, but one thing's for certain -- they know it when they see it."

-John Guaspari,
I Know It When I See It: A Modern Fable About Quality

And, as Jason rightly points out, what satisfies users (and the business) today may not satisfy them tomorrow. Keep the dialog going.

Regular Expressions

Posted by Ben Simo

(bb|[^b]{2}); [Tt]hat is the \?\.

Regular expressions are great tools for testers. I have found them useful for describing GUI objects to GUI test automation tools. I have found them useful for automation results validation. I have found them useful for extracting data I care about from voluminous log files. I've also found them useful for manipulating data.

What are regular expressions? Regular expressions are patterns for finding text of interest. They are supported by many test tools, system utilities, text editors, and programming languages.

Regular expressions can include the following meta characters to define patterns.

• ^ Matches the beginning
  
• $ Matches the end
  
• . Matches any single character
  
• * Matches zero or more occurrences of the preceding character
  
• \ Escape character
  
• ? Matches zero or one occurrence of the preceding character
  
• + Matches one or more occurrences of the previous character
  
• [ ] Defines a character class
  
• [^ ] Defines an exclusion-based character class
  
• \{ \} Matches a specific number or range of instances of the previous character
  
• \( \) Treats the expression between \( and \) as a group
  
• | Or. Use to match one of many expressions
  
• \< Matches the beginning of a word
  
• \> Matches the end of a word
  
• \b Word boundary
  
• \B Not a word boundary

* Many tools do not support all meta characters

Here are some example regular expressions:

“frog”

• Matches “frog”, “bullfrog”, and “tree frog”; but not “Frog”

“^Frog”

• Matches “Froggy went a courting”, but not “Quality Frog”

“frog$”

• Matches “frog”, “bullfrog”, and “tree frog”; but not “froggy” or “The frog sat on a log.”

“.at”

• Matches “cat”, “rat”, “bat”, “goat”, and “gnat”

“20*5”

• Matches “2005”, “20005”, “20000000000000000000000005”, “25”; but not “2ABC5” or “2006”

“Spee?d”

• Matches “Sped” and “Speed”; but not “Speeed”

“20+5”

• Matches “2005” and “20005”, but not “25”

“200[5-9]”

• Matches “2005”, “2006”, “2007”, and “2009”; but not “2004”

“199[0-9]|200[0-9]”

• Matches years 1990 through 2009.

“[0-9][0-9]*\.[0-9][0-9][^0-9]”

• Matches “1.29”, “1.29%”, and “1234.55”; but not “1.299” or “.29”

“A[LKRSZ|C[AOT]|D[CE]|F[LM]|G[AU]|HI|I[ADLN]|K[SY]|LA|M[AFRHINOPST]|N[CDEHJMVY]|O[HKR]|P[ARW]|RI|S[CD]|T[NX]|UT|V[AIT]|W[AIVY]“

• Matches any valid 2-letter US postal state or territory name abbreviation.

Want to learn more?

Take a look at my slides from last night's presentation to the Denver Mercury User Group. Check out Wikipedia. Or try a Google Search. If you ask bb|[^b]{2}, check out Think Geek.

Ha[p]{2}y T[ea]sting\.