GTAC: Call for Proposals

Posted by Lydia Ash - GTAC Conference Chair

Overview
The Test Automation Conference has been hosted by Google over the past several years bringing together a select set of industry practitioners as speakers and participants around the topic of software testing and automation. The annual conference provides a forum for presentations on important topics in our field connecting professions with others in their field through collaboration and targeted breakout sessions, but also has served the testing community by bringing the presentations public allowing anyone access to the information.

GTAC conference participants are typically software engineers who are actively working on problems of software quality, automated testing, and testing techniques. GTAC conferences cover a number of areas, but many presentations focus on themes such as advanced techniques in quality evaluation, advanced approaches to automating software testing, and experiences and findings from quality efforts on software projects.

The Conference
The conference is a two day event comprised of a single track of presentations. The philosophy is to engage a small set of active participants who all experience the same topics carrying the discussions into lightning talks, speaker Q&A, and topical discussion groups. The emphasis for the 2008 GTAC conference is solving the hard engineering problems in the quality of our software. Each year we have worked to identify a location that has a unique profile of technology professionals. This year the conference will be held in Seattle, WA, USA on October 23 and 24.

Presentations are targeted at experienced engineers actively working on software quality. We encourage innovative ideas, controversial experiences, problems, and solutions that further the discussion of engineering and software quality. Presentations are generally 45 min in length and speakers should be prepared for an active question and answer session following their presentation.

Process of Selection
All presentation submissions will be handled electronically. Presentation proposals should be a relatively detailed extended abstract including the topic, outline, and details of what will be presented. Presentation proposals should be emailed to gtac@google.com
All presentation proposals must be received by June 6, 2008. Where employer or disclosure authorization is needed, the author(s) will need to obtain this prior to submitting their proposal.

The program committee will evaluate proposals based on the quality and relevance. All submissions will be held confidentially prior to contacting the selected presenters and the publication in the proceedings.

Notification
Accepted proposal authors will be contacted on or before July 10 to confirm their availability and travel needs. Authors of proposals not selected will be notified on or before July 10. Accepted proposals will be presented at the conference and made available to the public on YouTube.

Copyright
TAC requires presenters to present at the conference and permit their presentation to be made available on YouTube.

Important Dates for Presentations
June 6 - Final deadline for proposal submissions for presentations
July 10 - Deadline for selected presenters to be contacted by the selection committee and notified of their acceptance
October 23 and 24 - GTAC conference in Seattle

Attendees
TAC conference has worked to invite a select audience, each member applies to the conference for committee selection. This is to ensure active participation from each attendee and provide a variety of technical perspectives to interact, discuss, and network.

Important Dates for Attendees
July 7 - Call for attendee profile submissions
July 25 - Deadline for attendee profiles
August 11 - Selected attendees to be notified by the conference committee, registration opens
August 29 - Registration deadline, wait-list opens
September 19 - Wait list notifications and attendee closure
October 23 and 24 - GTAC conference in Seattle

Questions
If you have questions about the submission process or potential topics please send a mail to us at: gtac@google.com
Please see the Google Testing blog for more information: http://googletesting.blogspot.com/search/label/GTAC

Permalink | Links to this post | 1 comments  

GTAC 2008 in Seattle

Before the end of our last Google Test Automation Conference in August 2007, we were already getting questions from participants and blog readers wondering about the next conference. Now we can tell you when and where that will happen (drum roll please)... the 2008 Test Automation Conference will be held October 23 and 24 in Seattle. More details will be coming shortly...

As with previous years, the focus of the conference will be solving software engineering challenges using tools and automation, with special focus on SaaS. Engineers in the testing world are frequently so busy shipping software that they do not take the time to share the technical details of the work they are doing, the approaches that are working, and the lessons they have learned. There will be a call for proposals in late April.

As has been the precedent in previous years, our conference is for active and vocal participation, not quiet attendance. GTAC is a place to share great ideas and to get challenged. As we have done previously, attendants will apply by proposing what they will bring to the conference and how they can further the discussions. Applications for attendance will be opened in late June.

We are hard at work developing the conference. Please send suggestions, questions and recommendations to: gtac@google.com or post your comments here to the blog.

Permalink | Links to this post | 4 comments  

TotT: Avoiding Flakey Tests

Flaky tests make your life more difficult. You get failure notifications that aren't helpful. You might become numb to failures and miss an actual failure condition. Your changes might get unfairly blamed for causing a flaky test to fail.

Unfortunately, a myriad of factors can make a test flaky. Today, we tackle a simple example: file access from a unit test. Take this function and its test:

def CreateGapLease(self):
  data_file = open('/leases/gap', 'w+')
  data_file.write(contract_data)
  data_file.close()

def testCreateGapLease(self):
  contract_writer.CreateGapLease()
  self.assertEqual(ReadFileContents('/leases/gap'),
         contract_data)

What if /leases/gap already exists and contains some data? testCreateGapLease will fail. This is a general problem where preconditions are assumed to be correct. This could just as easily happen by assuming a database contains the proper information (or no information). What if another test that uses that file was running concurrently?

If you really want to test your code using live resources, always check your assumptions. In this case, clearing the file at the start of the test can reduce its brittleness:

def testCreateGapLease(self):
  if os.path.exists(lease_file):
    RemoveFile(lease_file)
  ...

Unfortunately, this doesn't completely eliminate the flakiness of our test. If /leases/gap is an NFS path or can be written to by a different test, our test can still fail unexpectedly. It's better for the test to use a unique resource. This can be accomplished with a small refactoring of CreateGapLease:

def CreateGapLease(self, lease_path=None):
  if lease_path is None:
    lease_path = '/leases/gap'
  ...

The callers of CreateGapLease can continue invoking it as usual, but the unit test can pass in a different path:

def testCreateGapLease(self):
  lease_file = os.path.join(FLAGS.test_tmpdir, 'gap')
  contract_writer.CreateGapLease(lease_path=lease_file)
  self.assertEqual(ReadFileContents(lease_file),
         contract_data)

Of course, to make your test as fast as possible, it would be better to forgo disk access altogether by using a mock file system.

Remember to download this episode of Testing on the Toilet and post it in your office.

Due to illness availability of the PDF will be slightly delayed

The PDF is now available at the above link

Permalink | Links to this post | 2 comments  

TotT: Time is Random

How can a method be well tested when it's inputs can't be clearly identified? Consider this method in Java:

/** Return a date object representing the start of the next minute from now */
public Date nextMinuteFromNow() {
  long nowAsMillis = System.currentTimeMillis();
  Date then = new Date(nowAsMillis + 60000);
  then.setSeconds(0);
  then.setMilliseconds(0);
  return then;
}

There are two barriers to effectively testing this method:

1. There is no easy way to test corner cases; you're at the mercy of the system clock to supply input conditions.


2. When nextMinuteFromNow() returns, the time has changed. This means the test will not be an assertion, it will be a guess, and may generate low-frequency, hard-to-reproduce failures... flakiness! Class loading and garbage collection pauses, for example, can influence this.

Is System.currentTimeMillis(), starting to look a bit like a random number provider? That's because it is! The current time is yet another source of non-determinism; the results of nextMinuteFromNow() cannot be easily determined from its inputs. Fortunately, this is easy to solve: make the current time an input parameter which you can control.

public Date minuteAfter(Date now) {
  Date then = new Date(now.getTime() + 60000);
  then.setSeconds(0);
  then.setMilliseconds(0);
  return then;
}

// Retain original functionality
@Deprecated public Date nextMinuteFromNow() {
  return minuteAfter(new Date(System.currentTimeMillis()));
}

Writing tests for minuteAfter() is a much easier task than writing tests for nextMinuteFromNow():

public void testMinuteAfter () {
  Date now = stringToDate("2012-12-22 11:59:59.999PM");
  Date then = minuteAfter(now);
  assertEquals("2012-12-23 12:00:00.000AM", dateToString(then));
}

This is just one way to solve this problem. Dependency Injection and mutable Singletons can also be used.

Remember to download this episode of Testing on the Toilet and post it in your office.

Permalink | Links to this post | 3 comments