Skip to main content

Posts

Showing posts from January, 2007

resources for figuring out ODBC index() function

Microsoft: (edited: man what a day) http://msdn.microsoft.com/library/default.asp?url=/library/en-us/odbc/htm/odbcsqlstatistics.asp (bottom of the page, thanks to Paul Rogers, I'm not sure I ever would have found it on my own.) For Oracle, you probably want to avoid the indexes() function, and do queries straight to the system tables: http://www.ss64.com/orad/ALL_IND_COLUMNS.html http://www.ss64.com/orad/DBA_INDEXES.html

Announcing the Bay Area Developer-Tester/Tester-Developer Summit

If you're interested, leave a comment on the blog or send me an email or an IM or smoke signals or something. Here is the flyer Elisabeth Hendrickson and I have been sending: What: A peer-driven gathering of developer-testers and tester-developers to share knowledge and code. When: Saturday, February 24, 8:30AM – 5:00PM This is a small, peer-driven, non-commercial, invitation-only conference in the tradition of LAWST, AWTA, and the like. The content comes from the participants, and we expect all participants to take an active role. There is no cost to participate. We’re seeking participants who are testers who code, or developers who test. Our emphasis will be on good coding practices for testing, and good testing practices for automation. That might include topics like: test code and patterns; refactoring test code; creating abstract layers; programmatically analyzing/verifying large amounts of data; achieving repeatability with random tests; OO model-based tests; creating doma

Mountain West Ruby Conf March 16-17 Salt Lake City

This looks like a fine outing. I've been lurking as these folks assembled the Mountain West Ruby Conference. It looks like a blast. Chad Fowler is giving the keynote, and at fifty simoleon bucks, the price is definitely right. I'm not much for skiing , but it'd be a blast if I could make it to the shindig.

that's so crazy it's not even wrong

I'd Like a Pony, Please The Watir mail list gets on a regular basis questions like "How do I do X in Watir? The commercial tool that I use gives me X, but I can't figure out how to do it with Watir." (Watir, for those who don't know it, is a set of Ruby libraries for manipulating Internet Explorer. That's all it does. ) (OK, Watir has accumulated a few bells and whistles over time, but mostly it just reaches down IE's throat to move IE's bones around .) X is logging/database connection/encryption/special string handling/test case management/distributed test environment/data-driven frameworks/etc., etc. etc. The answer, of course, is that Watir doesn't do that. Nor will it ever do that. Watir is not intended to be a replacement for an entire test department, it is merely a set of libraries to manipulate Internet Explorer. Ruby itself has a lot of goodness to do this kind of thing, but Watir never will. The people that ask these questions are

significance of developer-tester/tester-developer

This idea of programmers-who-test and testers-who-program is starting to inform my daily work. Reading articles about fantastic projects that sail to the end is all well and good, those great stories are something we strive for, but accomplish only occasionally. From day to day, our designs could be better, our test coverage could be better; our test plans could be better, our test cases could be more powerful. I wrote the same bug in a couple of places this week. Luckily, my Customer was a tester. One of the developers I work with had a merge/commit problem a couple of times this week. Luckily, I was his tester, and I've struggled with merges and commits myself. We're working on figuring out how to prevent such errors in the future. As a toolsmith, my Customers are testers. I go out of my way to write readable code so that they can inspect what I am creating. I encourage collaboration, and my Customers are coming to the realization that I need their help to recognize

You! Luke! Don't write that down! *

Robert Anton Wilson died last Thursday after a long struggle. If you haven't read The Illuminatus Trilogy , go do that now. It's a lot like Pynchon's The Crying of Lot 49 , except 20 times longer and a hell of a lot funnier. Get back to me when you're done. I'll wait. A couple of years ago I was privileged to see the movie about him made in his later years Maybe Logic at the old Durango Film Festival, which renewed my admiration. Robert Anton Wilson refused to be made ridiculous, either by his critics or by his diseases. Both his sense of humor and his sense of the sublime were extraordinary, even in his last years. He refused to fade away, he raised a ruckus until the end. *If you're intrigued by the title of this post, and you're too feeble to read Illuminatus, email me and I'll explain it.

developer-testers and tester-developers

After hearing about a number of system-functional-testing adventures at AWTA , Carl Erickson proposed that there are "developer-testers" and that there are also "tester-developers". In context, the difference was clear, and it's worth talking about the two approaches. (Assuming that I did in fact understand what Carl meant.) Developer-testers are those developers who have become test-infected. They discovered the power of TDD and BDD, and extended that enthusiasm into the wider arena of system or functional tests. There is a lot of this sort of work going on in the Ruby world and in the agile world. For examples, look at some of Carl's publications on his site at atomicobject.com , or talk to anyone in the Chicago Ruby Brigade about Marcel Molina's presentation last winter on functional tests in Rails and 37signals. (Follow the link, the number of examples is gigantic!) The unit-test mentality of rigor and repeatability and close control survives

craft and discipline, larks' tongues in aspic

One of my lightning talks at AWTA had to do with finding better languages than engineering and manufacturing with which to describe software. With all due respect to the Leaners , if software work were like factory work, few of us would do it. I suggest we look to art, literature, and especially music for language to talk about software. I mentioned first a couple of academic examples taken from New Criticism and Structuralism , like Monroe Beardsley's idea that value is based on manifest criteria like unity, variety, and intensity, or the Structuralists' idea that value is based on the degree to which the work reflects the folklore and culture of the milieu where it was produced. If they'd done software, Beardsley would have been analyzing coding standards and function points, while the Structuralists would have been all strict CMM or strict Scrum/XP. If you're a objective-measurements, CMM, or Agile person, I encourage you to find corollary principles in the la

stand back! I know regular expressions!

I get a kick out of xkcd, but the hero programming Perl swinging at the end of the rope had me laughing out loud.

what is "automated testing"?

Apropos of a recent discussion on the software-testing mail list, I was reminded of reading James Bach's Agile Test Automation presentation for the first time. It contains this one great page that says that test automation is: any use of tools to support testing. until that time I had held the idea that test automation was closely related to manual tests. I was familiar with data-driven and keyword-driven test frameworks, and I was familiar with tests that relied on coded parts to run, but I still had this idea that there was a necessary connection between manual tests and automated tests. I had this idea that proper automated testing was simply where the machine took over and emulated human actions that were expensive or boring. That way, of course, lies madness. And expense. It was reading this particular presentation that really lit the light bulb and got me thinking about all the other things that testers do, and all kinds of other ways to approach test automation. Here

the minimum number of tests

Elisabeth Hendrickson wrote about a case of complacency and lack of imagination in a tester she interviewed. I agree with the gist of her argument, that good testers have a "knack" for considering myriad ways to approach any particular situation. But I would also like to point out that just as a "tester who can’t think beyond the most mundane tests" is dangerous, so a tester who assigns equal importance to every possible test is just as dangerous, if not more so. The set of all possible tests is always immense, and the amount of time to do testing is always limited. I like to encourage a knack for choosing the most critical tests. Sometimes this knack looks like intuition or "error guessing", but in those cases it is almost always, as Brian Marick put it in his review of Kaner's "Testing Computer Software" , "past experience and an understanding of the frailties of human developers" applied well. Intuition and error guessing take