Chris McMahon's Blog

Selenesse is the mashup between Fitnesse and Selenium I helped work on some time ago.  I keep encountering this pattern in my selenesse tests, so I thought I'd share it... Every once in a while a test needs some sort of persistent quasi-random bit of data.  In the example below I'm adding a new unique "location" and then checking that my new location appears selected in a selectbox.   This is also a neat trick for testing search, or anywhere else you need to add a bit of data to the system and then retrieve that exact bit of data from somewhere else in the system.  | note | eval javascript inline FTW! | | type; | location_name | javascript{RN='TestLocation' + Math.floor(Math.random()*9999999999);while (String(RN).length < 14) { RN= RN+'0';}} | | note | instantiate a variable and assign the new value to it in a single line FTW! | | $LOCATION= | getValue | location_name | | note | click a thingie to add the new data to the system | | click |...

Before it gets lost in history, I want to riff off Alan Page once again, who made some excellent points .  But as someone who has been designing and creating GUI (browser) tests for a long time, I'd like to address some of those and also point out some bits of ROI that Alan missed.  Making UI tests not fragile is design work.  It requires an understanding of the architecture of the application.  In the case of a web app, the UI test designer is really required to understand things like how AJAX works, standards for identifying elements on pages, how the state of any particular page may or may not change, how user-visible messages are managed in the app, etc. etc.  Without this sort of deep understanding of software architecture, UI tests are bound to be fragile. I've said before that UI tests should be a shallow layer that tests only presentation, and that rarely tests logic, math, or any underlying manipulation of data.  If tests are designed in this w...

Alan just posted this: http://angryweasel.com/blog/?p=325 This is the nicest test example I've seen in a long time, and I think it bears a little more analysis. If I were in charge of the development of this app, I would make automated testing happen on 3 levels. First, there would have to be some sort of test for generating a single random number. Which seems easy enough, but at this level, you really have to understand exactly what a call to rand() (or whatever) on your particular OS is going to do. I once wrote a script in Perl (praise Allah just a toy, not production code) that returned perfectly random numbers on OSX but returned exactly the same values every time on Windows. You'd better test that your call to rand() really returns random numbers, regardless of the OS it is running on. At a higher level, you'd want to do exactly what Alan talks about in looping 100,000 times (although 100K seems like overkill to me). This is what I think of as an "i...

Today stickyminds published my article with expanded descriptions of the "10 Frontiers for Software Testing" that I suggested as starting points for those interested in attending the second Writing About Testing conference .  Since I announced the CFP for the first WAT conference in October 2009, I have published several dozen articles on software and software testing.  (I actually lost count: it is well over thirty but fewer than fifty individual pieces.) My friend Charley Baker asked me recently where I get the ideas for so many articles.   It is an interesting question, and worth answering: The most important source of ideas is simply everyday work.  As I go about doing my job, it happens fairly often that a situation crops up that I think would be of general interest to the community of software testers and developers.  So I write it down and I make it public.  Articles about bugs, bug reports, test design, architecture, workflow, telecommu...

I took a poll of those interested so far in attending the second Writing About Testing peer conference May 13 and 14 and found that nine people are very seriously considering attending.  This is what they are thinking of discussing: Lisa Crispin (CO)  new and emerging approaches since the publication of Agile Testing Alan Page (WA) a new approach to test design, also personas for tester career roles Marlena Compton   (Australia) ongoing research in visualization of software project data Dawn Cannan   (NC) executable specifications within larger testing projects Sylvia Killinen (CO) practicing software craftsmanship Elena Yatzeck (IL) implementing DSLs for use by non-programmers Shmuel Gershon (Israel) diverse approaches to writing about testing using personas Charley Baker (CO) large-scale, Enterprise automation systems, open source Marisa Burt (CO) EAI in Enterprise systems UPDATED: Zeger Van Hese (Belgium) critical theory, etc. Frank Cohen (...

I read with interest Matt Archer's blog post entitled " How test automation with Selenium or Watir can fail " He shows a couple of examples that, while perfectly valid, are poor sorts of tests to execute at the UI level.  Conveniently, Mr. Archer's tests are so well documented that it is possible to point to exactly to where the smells come in.  The test in the first example describes a UI element that has only two possible states: either "two-man lift" or "one-man lift", depending on the weight of an item.  In a well-designed test for a well-designed UI, it should be possible for the test to validate that only those two states are available to the user of the UI, and then stop.   But Mr. Archer's test actually reaches out to the system under test in order to open a file whose contents may be variable or even arbitrary, iterates over the contents of the file, and attempts to check that the proper value is displayed in the UI based on the ...

The last Weekend Testers (Australia/New Zealand) was brilliant. Let me urge you to read Marlena Compton's report and the transcript of the session . This sort of practical implementation of critical theory is long overdue in the testing community, and the WTANZ crew did a great job of using a well-known theoretical tool to analyze and dissect some real problems in some real work. Compare what WTANZ did with Zeger Van Hese's recent demonstration of deconstruction . This sort of work, bringing reputable and sophisticated critical theory to bear on actual testing and QA activity, is a field wide open, barely explored, and long overdue.  May we see much more of it soon.