Lovingly Abusing Mac Software

Baby steps into Open Source

2012-01-19T13:33:00.000-08:00

"You should get involved in Open Source. It'll help you network, and practice your skills, and bolster your resumé. And we need more women in Open Source."

To which I think "Hmm... that sounds complicated, and I don't know where to start and I'm busy and I'll get around to it someday."

Well, Someday showed up yesterday afternoon. I'd like to talk about 2 reasons why I think Someday showed up, and then I'll tell you how it went.

The first reason Someday showed up is that I found something I wanted to fix and cared enough about to actually go fix.

"Today has been a prime example of why productivity should never be measured in lines of code! Spent hours just to *move* a line to fix bug." -- Me, on Twitter, yesterday afternoon.

I was using this library for some internal testing at work. The gem version worked, but the latest on GitHub was failing. (Hurray for test cases I could easily run against both versions, toggling back & forth!)

I don't think I would have spent so many hours puzzling over this code just for the sake of working on Open Source. I have to be solving some problem that I care about. (Or at least that I care about getting paid for!)

Once I committed the code to the subversion repository at work, I could have said "Done!" But this is when Someday's other reason kicked in. For months (years?) now, DevChix women have been encouraging each other to get involved in Open Source projects, for all the reasons mentioned at the beginning of this post. And emphasizing how easy it was. And not letting each other get hung up on whether our code is good enough or other silly excuses. All this came flooding back to me as I tried to move on to the next piece of work. I kind of HAD to at least look at GitHub and see whether I might want to give this change back to the original project. Just check and see how hard it would be.

I set up a GitHub account, and walked through their guide for installing git locally, forking a repository, (making a local change), and sending the original developer a change request. All of that took only about an hour. One hour. Seriously. (One and a half, if you count the time to write this blog post.)

Thank you, GitHub, for making it so easy to contribute to a project.

Thank you, DevChix, for encouraging me to dip my toes in an open source project. This is me maybe helping encourage the next person.

As for finding a project you care about, I'm not sure what to suggest. But when it comes along, please join in.

https://github.com/emarley/net_dav

Status: 503

2012-01-17T20:15:00.000-08:00

I don't blog much, so I don't have WordPress or my own domain or anything. Just this low-maintenance blog.

So I can't do a real blackout like Wikipedia or the other big sites that are protesting SOPA and PIPA. This post will have to do.

I respect intellectual property. My paycheck depends on people paying for software instead of pirating it.
I would not mind if piracy were greatly reduced. But these bills that the House and Senate are debating put WAY too much power on the accuser's side. If pirated content is made available on a site, the whole site can be taken down immediately. The service provider and anyone else using the service are immediately cut off from it. The service provider will lose ad revenue, or user subscriptions, and probably spend a bunch of time with lawyers, trying to get their service re-instated. And everyone who uses the service will be rather inconvenienced. The pirate, on the other hand, will probably just wander along to some other site providing a similar service, relatively unscathed.

Beyond this particular pair of bills, Congress has got to start understanding the Internet! It is not enough to know it's a "series of tubes". Either get educated, or start listening to people who DO know how the internet works.

Mouse Wars

2011-12-09T00:22:00.000-08:00

When I started my current job over 6 years ago, or perhaps shortly thereafter, I got a largish Microsoft USB mouse with a few buttons and a scroll wheel. It's very right-handed, and someone else's skin oils had clearly already corroded the finish in a few places. But it worked. Never had to think about it.

More recently, I 'upgraded' to a bluetooth keyboard and a 'magic' trackpad or whatever Apple calls it. I like the trackpad's swipe-y gestures, but they both disconnect from the computer at random intervals. Sigh.

Then, within the last month, I caught myself switching back and forth between the trackpad and mouse a lot because they were both "sticking" -- intermittently failing to track my movements.

To get through the workday, and start diagnosing the issue, I got another mouse from our sysadmin. Unfortunately, he only had bluetooth "magic" mice. (If I want to see a magic mouse, I'll go to Disneyland, thank you very much!) When I went to pair this new bluetooth mouse, I accidentally paired a co-worker's mouse instead -- while he was using it! I moved my USB mouse to his machine so he could re-pair the bluetooth mouse with his computer. He quickly diagnosed that my wired mouse had a short, which caused it to usually stop tracking if I moved the mouse straight vertically.

Once we got the bluetooth paired, I started thinking about really solving my mouse issues. I brought a Microsoft wireless USB mouse from home and tried that as well.

1) All mice are flaky sometimes

2) Some (all?) of the wired mouse's flakiness can be explained by the short; holding the wire straight prevents it.

3) Both the bluetooth trackpad and the bluetooth mouse are flaky sometimes. Is it the bluetooth? Is it an OS or computer hardware issue?

4) The wireless USB mouse is a little flaky at work, but not at home.

I think this leads me to blame either my Mac Pro or the desk surface at work. Neither of these have changed conspicuously since before I started noticing these issues.

Upgrading from 10.7.0 to 10.7.2 did seem to temporarily alleviate some flakiness. Maybe it's drivers? Maybe simply a reboot helped?

What is your favorite part about writing?

2011-11-01T20:58:00.000-07:00

It's national month of "do that creative thing you keep meaning to do" as far as I can tell. I think novel-writing came first, then drawing. BlogHer is hopping on the band wagon with NaBloPoMo. They're posting a prompt for their bloggers each day. I guess I'll try this a bit. No promises about a post every day or anything, though.

So, what is my favorite part about writing? Maybe that the process of writing down my thoughts in complete sentences helps me understand them in a new way. This is especially true of writing stuff out with pen on paper, but even here at the keyboard I tend to gain new insights and clarity. ''

Sometimes I hope my blog will somehow bring me fame and fortune. Sure, that'd be nice, but I don't write nearly enough for that (not to mention writing *well* enough!).

Does this have anything to do with testing? Oh, I could probably make some tortured analogy, but no. I won't. My goal in writing this blog post is just to write something, to exercise a muscle that I might need soon to write about testing.

Women at WWDC

2011-06-15T15:01:00.001-07:00

[originally posted to the DevChix mailing list]

I enjoyed several social gatherings (formal & informal) last week at
WWDC, not least of which was the Thursday women's lunch that Alexis
instigated. We picnic-ed in a sunny/shady spot at Yerba Buena gardens,
probably about 20 of us, sitting in a circle. I really liked the bit
where we each got a minute or two to introduce ourselves & talk a bit
about our interests. I recently encountered the idea
of 'plussing' each other -- an improv concept where you focus on
adding to what someone else is doing, rather than competing with them.
I definitely saw this in action at Thursday's lunch. When one person
finished modestly introducing herself, someone else chimed in with
"yeah, but you also got blah blah award" or "you also wrote
such-and-such book". This sort of thing happened a few times. It
created a great atmosphere of cheering each other on, I thought. Thank
you, Alexis and everyone else who was present.

As in past years, there weren't many women at the conference. I
couldn't really tell if there were more or less than last year.

I didn't see any women presenters, but I heard that there were a few
in sessions I didn't attend. The presenters are frequently engineers
who actually did the work, or managers of those people, so I think
that more reflects on Apple's general diversity than any specific
disparity in women speaking.

I had one thought about how to make conferences better for
newbies/underrepresented/underconnected people. Introduce people! Look
for opportunities to connect people you know, even if you're not sure
whether they have much in common. They're at the same tech conference,
odds are they have some overlapping work. Find someone who it's their
first time at the conference, and invite them along to lunch with your
usual gang or something like that. (I'm pointing this advice at myself
as much as anyone else -- after 5 trips to WWDC, I need to stop
thinking of myself as the newbie!)

Tangent Time: Turkey Edition

2010-12-02T16:56:00.000-08:00

The week before Thanksgiving, I was sick on Thursday and so my tangent time was reading Being Geek. This book is not just for programmers. Most of the content applies to testers, UI designers and other people who also participate in creating software just as much as programmers. And the bits that are specifically about programmers are still worth reading, because understanding how programmers function can be very useful when you work with them all day.

--------

Then we got weathered-in (the ice was more a problem than the snow) for three days last week. My home machine wasn't really set up for testing stuff, so I picked up another tangent time project: procmail. I check email on 4 machines. Only 2 of them can run Mail filtering rules, so my inbox often filled up with subversion commit messages when I was away from my desk. And every time I wanted to tweak my rules, I had to remember to sync the changes from my work machine to my personal laptop (or vice-versa). My work mail filtering really needed to be handled further up-stream. Thus, procmail.

I learned the danger of reference material written for a context that doesn't match my own. And the importance of escaping square brackets in regular expressions. And I did everything very cautiously, because I've heard horror stories of buggy procmail rules bringing down mail servers. And I already used up my one 'kill the mail server' forgiveness card last year.

--------

Today I propped open Brian Marick's Everyday Scripting with Ruby and worked my way through Part I. Yes, it was all familiar material. But if I was going to have problems with incompatible Ruby versions, or accessing the supplemental files, I wanted to have them while I wasn't also trying to debug some fancy meta-programming code I barely understood, or something like that. I've skimmed the book before, but this time I made myself actually write the code for all the exercises. I learned a little, but mostly I set myself up well to jump into Part II next week.

Tangent Time

2010-11-07T23:52:00.000-08:00

I'm trying out a new practice at work. I'm calling it tangent time. One afternoon a week, I push my main project aside, shut my door, and quit all my communication applications. I spend my time on something sort of related to the testing I'm doing the rest of the week, but not directly. It's some tangent that caught my eye while I was busy doing the "real" work.

Why:
My manager and I came up with this during a recent one-on-one. (You do have those with your manager and/or reports, right?) I felt like I wasn't getting much done, due to lots of interruptions and a general burn-out sort of feeling. I also felt like there was a lot I could be learning that I just wasn't getting time for--knowledge and skills that would make me more productive in the long run. Even though, in the short run, my main project is way overdue and just needs. to. ship. already.

How:
I picked Thursday afternoons. I don't have any regular meetings that day, and it's not Chaos Monday or Brain-Dead Friday or Apple Announcement Tuesday. Right after lunch, I double-check that my email didn't explode, and then quit Mail and iChat and Gmail and Twitter. I shut my door, though it's glass, so people can still see I'm there if they really need me. I get a nice solid 3 hour block. I stop at 4:30 so that people who leave at 5 can still get my attention before the end of the day.

What:
Something tangentially related to work. I'm intentionally not being more specific than that, because part of the point is not to feel so obligated, so trapped.

The first week, I watched videos. Merlin Mann's talk at Twitter about Boring Meetings. I've sat through a few boring meetings this year, and if Apple stops throwing OS updates and app stores at us, I might get to lead some meetings in a few months. I'd rather they not suck. The second video was Steve Jobs announcing the Mac app store, Lion, and the MacBook Air. I was AFI (away from internet) during the event, and wanted to catch up on what everyone at work was buzzing about.

The second week, I worked through a bunch of Ruby koans. I mostly worked through them as intended, implementing each snippet of code in sequence to make the tests pass. But I did take a detour to hack the test framework so that it wouldn't give me quite as many hints by default.

Well?
The primary goal was to refresh my attitudes towards work. It's still early, but I think this is working. I used to follow some of these tangents as a way to procrastinate from my main work, and feel guilty. Now I am supposed to follow these tangents. It seems to give me a renewed interest in the both the tangent and official work.

Additionally, the tangents may not be as tangential as I thought. When I did the koans, within an hour, I had picked up 2 other tricks/recipes that weren't part of the official learning. But they solved real problems I'd been tripping over writing my testing robots recently.

For extra bonus points, I see some evidence that it's helping me concentrate a little better and not be so interrupt-driven, even when I'm not in tangent time.

The iPad as a Conference Laptop

2010-04-26T11:48:00.000-07:00

I went to the Voices That Matter -- iPhone conference this weekend here in Seattle. I intend to talk more about the event itself later, but for now I want to talk about what I put in my bag -- and what I didn't.

This is the first conference I haven't taken my laptop to. I relied on my iPad and iPhone, and I would say the experiment was very successful.

Battery life would have been a total non-issue if I'd remembered to re-charge my battery Saturday night. While I was charging it at the conference Sunday, I wished for a slightly longer charging cable, but maybe that would have created a tripping hazard.

Typing was a little slow, but with all the slides posted online, I really only needed to type a few phrases when the speaker went beyond the slides or to jog my memory later. If I expected to do more iPad typing, I could have slipped my Apple bluetooth keyboard in my messenger bag and still kept it smaller and lighter than my laptop bag. I saw a few other people with folding keyboards, probably from the PDA era.

The iPad was quicker to setup and teardown when I moved from one room to the other. I could even pull it out to reference my notes between sessions. The iPad played nicely with the conference center wi-fi (though maybe that's more a review of Bell Harbor Conference Center?).

But what about Xcode? This is a developer's conference and the iPad doesn't have dev tools on it. Technically true. Only one session really encouraged you to follow along in Xcode. The others were more presentations, and I think scrambling to keep up with the demos in Xcode would have been more of a distraction than a learning tool.

I tried two different cases. On Saturday, I used Apple's folio-style case. There's a slot in the back that lets you prop the ipad up at an angle for typing. I've found this very handy and reasonably comfortable for typing on my lap. But when I sat at a table, it felt a little too high, so I mostly left it flat, or used the beveled edge of the table for tilt. It worked fine. On Sunday, I used a homemade sleeve. I enjoyed having a case with a little personality. And it's a way to show off my knitting hobby without being obnoxious. ("Look what I made!") The soft yarn gives the iPad some padding and doubles as a smudge-removing cloth. I tried using this case, folded up a bit, to prop up my iPad for typing, but it didn't work so well. I found myself typing less on Sunday, so maybe the wedge of Apple's case really is valuable, or maybe I was just lazier on the second day of the conference.

Will my laptop go to WWDC? Yes. Will it leave my hotel room? Maybe not.

Links for today's talk

2010-03-03T11:11:00.000-08:00

I'm speaking about testing software on mobile touch devices this afternoon. I'll post my slides or a video or something later.

But here's some links to people doing similar stuff that I want to refer people to if they're interested:

http://blog.omnigroup.com -- where our designers and engineers talk about their perspectives on the iPad and many other things

www.viddler.com/explore/rentzsch/videos/26/ -- the talk that first got me started thinking about how differently we need to design, develop, and test for the iPhone, by an iPhone developer

vimeo.com/8581946 -- I want to point people both to this speaker (and his blog) and this whole series of lectures about ergonomics and design.

OK, catch you on the flip side!

Making your iPhone App Environmentally Friendly

2010-02-24T21:21:00.000-08:00

With a traditional desktop application, most of your users will be sitting at a desk, using a keyboard and mouse. So you can test the applications reasonably well by sitting at *your* desk, using your mouse and keyboard. Sure, there's edge cases, like laptops and graphics tablets. But your test lab or office cube is a pretty good approximaation of their home office or work cubicle.

Stop and think for a minute of all the places where you've used your cell phone lately. A lot of places besides your desk, right? In the next 24 hours, I bet I will use mine sitting at my desk, sitting in meetings, waiting for the bus, riding in a friend's car, shopping at a yarn store, and lying in bed. And all of these environments can reveal bugs that you won't find sitting at your desk.
- At a meeting: In a meeting, I might try to pull up important information on my iPhone and every second the app takes to load, my colleagues get more annoyed with me.
- At the bus stop: I may be interrupted at any moment, when the bus shows up. So don't penalize me for quitting the app. Pause my game so I can continue it later. Save my data.
- In a vehicle: Location isn't just something that can change every time I use the app. It can change *while* I'm using the app. Use the app while you're moving, and figure out whether the user will be happier if you update location-related stuff periodically, or let the user tell you when to update.
- In a store: I've probably only got one hand available, because the other's holding a shopping basket. Can I navigate the application without setting my stuff down?
- In bed: I like to read while lying on my side. So "upright" for me is now perpendicular to the floor. I turn an iPhone perpendicular, and in many applications, it happily rotates the screen for me, so text is still parallel to the floor. Not helpful. Amazon's Kindle app actually handles this very nicely. For a few seconds after a rotation, it shows a lock icon. Tap the lock and the text will get locked into position. After that, I can happily turn it any which-way and still read my book.
- On a plane: If you fly much, you know that all electronics get turned off for the first bit, and then they can be on, but with cell and wifi turned off. Can I use your application with no connection to the outside world? The first time I tried to use OmniFocus on a plane, it went into a loop of insanity, trying every minute or so to connect to the server and sync my data. By the time I dismissed the alert that sync had failed, it'd be nearly ready to try again. If you must fail, make sure you fail gracefully.

So figure out which of these environments are right for your app. I don't need to play an immersive multi-player game while browsing the grocery store aisles, but I better be able to check my shopping list! Test in these environments, or at least find ways to simulate these environments in your test lab. This is one case where a tin foil hat might actually be a legitimate approach!

And now a word from our sponsors....

2010-02-10T22:22:00.000-08:00

I'm not blogging to make money. Let me make sure that's clear up front.

But I buy a ton of stuff from Amazon, and when it's good stuff, I tell other people about it. Amazon likes that, so they'll pay me for this. And when someone wants to pay me for something I'm doing already, I'm generally willing to go along with that.

So I'm going to try out this Amazon Associates thing. I'm hoping that it will make it easier for me to link to books and such in my posts. I also hope it will improve your experience of looking up the stuff I'm linking to. But if it turns out that it actually interferes with the primary point of this blog (discussing software testing), then I'll give it the boot. So let's test this thing out, okay?

Right now I'm reading Beautiful Testing: Leading Professionals Reveal How They Improve Software (Theory in Practice) and I hope to post a review of it soon. Maybe separate reviews for each chapter, since it's an anthology?

The road to a presentation starts with a single step...

2010-02-04T14:08:00.001-08:00

I have an opportunity to give a talk at another company soon. I've got a (very rough) idea of what the talk needs to contain, so I'll be coming back to it soon. But first, I need a bio and a talk 'blurb'. I'd love constructive feedback on this first draft. In particular, there has got to be *something* better than "hot new development platform"!

Touch devices are the hot new development platform. As testers, we need to borrow strategies from testing both desktop software and pre-touch phones. However, we must also go beyond these perspectives, and develop new heuristics specific to touch devices. Liz will share some of the lessons she's learned in iPhone testing and why it's essential to literally get your hands on touch devices while testing touch-based software.

Liz Marley tests the Omni Group's Mac and iPhone productivity software. She's also very eager to begin testing iPad apps as soon as possible! Liz has 6 years of professional testing experience, and 4 years of debugging homework assignments while earning a computer science degree from Harvey Mudd College.

Touchy Testing

2010-01-29T10:48:00.001-08:00

I've been thinking for a while about the unique challenges of testing mobile, touch-based devices. I'm crafting this post entirely on my iPhone, and working around the UI designed for keyboard/mouse-based computers. [I ended up having to type it in an email, and tried the email-to-post feature, but now I've resorted to copy/pasting text from a bounced mail message to a browser window on my desktop machine.]

As a Mac and iPhone software tester, I'm itching to get my hands on an iPad as soon as possible. I told one of our engineers today that I think it's essential for testers to literally get their hands on these devices. I did some iPhone testing before I owned one, and did a decent job of finding bugs on borrowed devices and the simulator. But once I got an iPhone and began to use it day-to-day, I discovered all sorts of new user scenarios. Airplanes, reading in bed, Seattle weather, ... I expect the iPad will not be just a giant iPhone, but have a whole new set of interactions. I look forward to the discoveries. And who can turn down a shiny new toy?

Some other people have written much more eloquently on why it's not just a giant iPhone:

http://speirs.org/blog/2010/1/29/future-shock.html

http://www.mcubedsw.com/blog/index.php/site/thoughts_on_the_ipad/

http://heta.metalbat.com/?p=1998

Why Blog?

2009-12-08T16:49:00.000-08:00

Gus Mueller led me to Dan Wood's article on blogging the other day. I didn't quite get around to reading it until just now, but in the meantime, I semi-subconsciously thought about why I think that blogging is a good thing to do. Dan's reasons, although very good reasons, are not my reasons.

Blogging pushes me to develop my thoughts from un-examined opinions to defensible theses.
Dan hopes future customers will read his blog. I hope other future people find my blog: mentors, co-authors of papers, peers, critics, skeptics, co-workers, people I can mentor?
Blogging exercises my communication skills. A big part of testing is detective work. But another big part is story-telling. I want to get better at telling clear, convincing, entertaining stories.

Testing for Experts, or When a Spec is Worth the Bother

2009-12-02T23:47:00.000-08:00

@jonbell's Ignite Seattle talk collided with a recent testing adventure of mine. I was really frustrated testing a new feature for one of our apps. About the time I read his talk, (oops, forgot to go in person!) I stopped trying to test the feature and started writing up how I thought this feature was supposed to work. Now I'm not so grumpy anymore.

I used to think there was just testing. Then I broke it out into two types of testing: learning and checking. Now I think there's 3.

I still think there's learning. And I still think there's checking. But there's also learning A to check B.

For many of the features I'm supposed to test, the only written spec is the bug. Sometimes it only has a sentence or two. And that's enough for the engineer to write the feature (mostly) correctly and enough for me to (mostly)test it.[0] Writing more details would just lead to time-wasting, abandoned specs.[1] For example, "Add a 'new folder' toolbar button." The engineers I work with all know how a toolbar button typically works, and so do I. We can make reasonable guesses about what the user expects. I check that it feels predictable[2], shake out a few corner cases, and off we go.

But sometimes we're building expert features. I am not an expert in our users' field. I can't trust my gut to know which operation ought to take precedence when two of them interact. When I realize I'm in this situation, I need to learn first, and then test. This is when I really need a spec. Maybe the engineer needed a spec too, and the bug is already full of notes from him and our PM clarifying how the feature needs to work. Or more often, I need to write my own spec.

"But you just said you don't know this stuff. How can you write the spec?"

I'd say I'm *exactly* the person to write the spec, because I'm the one who knows what questions it needs to answer. If I ask the engineer "How is this supposed to work?" I might get part of what I need to know, but I tend to feel like I'm wasting their time if I camp out in their offices too long. On the other hand, if I write up a short wiki page on how I *think* it's supposed to work, they're often quick to jump in with corrections and clarifying comments.

Developing the spec is the learning step. Now I can pretend to be an expert in the field, and properly check the behavior of the new expert feature.

[0] Honestly, now, when was the last time you *fully* tested something?

[1] Thinking of http://www.joelonsoftware.com/articles/fog0000000033.html

[2] borrowing from Jon

Knitting & Testing

2009-11-14T16:26:00.000-08:00

This afternoon, I dropped by while James Bach was signing copies of his latest book, The Buccaneer Scholar. Somehow I mentioned that I knit, and he explained one of his new teaching ideas, that test script writers could learn a lot from the way knitters write patterns. It's common to write test scripts so that anyone could read and execute them. But a knitting pattern is written for the (more-or-less) knowledgeable knitter, who is already familiar with a number of abbreviations and other conventions in knitting patterns. Just as it would be incredibly tedious to re-explain how to ssk (slip-slip-knit) every time that stitch is required, we could perhaps save a lot of tedium in our test scripts by developing a common jargon within a testing community[1].

[Edit: In the following paragraph, I completely failed to mention the contributions of @superpuppy, who shares with me an interest both in knitting and in breaking software.]

Then James sent me on a mission to find 2 books -- one that just assumed you knew knitting and used its jargon, and another that provided the introduction needed to understand and implement the patterns in the more advanced book. I found some books for him (5, since I'm an over-achiever), but the process sent me in 3 other directions as well:

1) The books on that shelf were not the intro ones I would have recommended if I was picking from all knitting books ever. While the Borders' collection of knitting books was respectable for a mall-sized chain bookstore, the selection felt limited compared to a yarn store or the internet. The main book I referenced while learning to knit was the Vogue Knitting Quick Reference. For crochet, I used 10-20-30 Minutes To Learn To Crochet.[2] The books I did offer James were still reasonable intro guides, covering the jargon and formatting of patterns. The crochet intro explained not only the cryptic terminology, but also the standard way of diagramming crochet. (The knitting may have taught how to read knitting charts as well, though I didn't notice it.)

2) There are a lot of parallels between knitting books and software testing texts. There's the plain old pattern collections, like test scripts. Then there's books that talk about what to do when things go wrong. And just as a tester may turn to hardware documentation while testing software that runs on it, so a knitter might find a book exclusively about various types of fibers instructive. At first I thought this was because the two crafts are similar, but perhaps it's more because human beings learn different skills in similar ways.

3) It feels like there's a lot more connections between knitting (and/or crochet) and testing than just the idea of how to write up scripts that James identified. I'm going to start a list here, and I hope you'll join in by commenting below, or tweeting me.

- A pattern is a test case/script. There's a set of steps, and an expected output.

- Keeping track of exactly what you've done so far is important. Count your rows, log your actions.

- Following the pattern/script exactly is a reasonable first step. But variation is good too! Try a different yarn and finishing stitch. Try it using the mouse instead of the keyboard, or with a bigger input file.

- When you diverge from the beaten path, keep track of what you did, so you or someone else can do it again later.

- There are books that can teach you how to do this stuff. But a workshop (at Weaving Works, or PNSQC) can be so much more effective. There are also videos (how to knit a moëbius, how to test an Easy button).

- There are heuristics. The Knitting Stitch Bible is nothing but stitch pattern heuristics -- no patterns for whole garments, no 'how to knit and purl' at the beginning, but 39 ribbing variations and 37 cables to choose from. I have yet to find such a concise book of heuristics for software testing, though I do find individual heuristics scattered all over the internet, and James gives great detail about a few in The Buccaneer Scholar. (Why isn't there an encyclopedia of testing heuristics?)

- There are holy wars, based on over-generalizations, imprecise terms, and uninspected biases. Knitting is more refined than crochet. Automated testing is more rigorous than exploratory testing. Well, what do you mean by 'refined', and is that necessarily a good thing? What do you mean by rigor? Or automated?

[1] A community could be a project team, department, company, formal or informal intellectual group, etc.

[2] This book deserves special note as the only intro book for crochet I've ever found that respects left-handed students. Most books show the first diagram or two redrawn for a left-handed context, and then expect you to just reverse the right-handed diagram for all the other techniques they teach. 10-20-30 includes diagrams for many (all?) of the techniques where hand positioning is important.

Upstairs, they call that a Liz

2009-08-24T15:19:00.000-07:00

This is the best analogy I've seen yet for how I became a software tester:

http://www.youtube.com/watch?v=avSLMAKaBxg

I didn't accidentally kill anyone while getting my CS degree, but I sure wrote a lot of bugs and crashes into my homework assignments. Spending all that time chasing down segfaults seems to have trained me to look for similar mistakes in other people's applications.

You Don't Want to Hire a Tester

2008-09-18T13:46:00.000-07:00

Testers can be a real pain. As a developer, you are hiring someone to complain. And not about life in general, or The Establishment, but about the application you have spent long hours lovingly crafting out of bits. You spelled a word wrong, that text box isn't quite aligned with its label, and the whole thing takes just a little too long to load. The documentation's rather terse, and shouldn't the icon be just a little less shiny?

Testers ask questions. Annoying questions. Where are the release notes? Does that change affect this other thing? If the app can do this, why can't it do that? Which third-party apps do we need to be compatible with? Where did this half-baked, unplanned, crazy new feature come from?

Testers check the quality of things besides the software you told them to work on. They clog the network stress-testing an app. They accidentally delete your source control repository if the permissions aren't set right. They critique the bug-tracking database. They suggest changes to the lunch-ordering process.

Testers delay releases. They always seem to find a serious bug when you're just about to push a new version. And now you're elbow-deep in backtraces, rather than basking in the warm fuzzy feeling of a release.

Testers cost money. Besides their paycheck, they want a Mac to test the app. And maybe a second one, to use while they're re-installing the OS on the first one. And then a Wacom tablet, because it sends different events than a mouse.

Testers are trouble. You don't want to hire a tester.

Summary and Questions

2008-09-12T15:11:00.000-07:00

So far, it seems to me that there are a few different broad topics this presentation needs to cover:

The difference and trade-offs between beta testing and internal testing.*
How to utilize beta testing most effectively.
What internal testers can and should be doing to test your applications.
What skills, experience, and other traits you should be looking for when hiring a tester.
What tools and resources are available for testers and their bosses.
How to get along with your tester and make them more efficient.

A few of these topics will require further thought and research on my part, but I think they're all things you need to know. And please let me know if there's something I've missed that you'd like to see addressed. In other words, let's do this presentation backwards, and start with the questions.

-----

*By "internal" testers, I mean both direct employees and contractors/consultants–people who are using your software because you pay them to, not because it helps them get other things done.

Inspired by C4

2008-09-09T14:41:00.000-07:00

I went to C4[2]*† this weekend. I've been interacting with Mac developers all wrong. I should not be apologizing for being a tester, and participating in spite of my profession. It is because of my talents and experience that I can and should attend these events and discuss software, and everything related to it, with Mac developers.

Several people at C4 suggested there should be a talk on testing next year. But as @arclite tweeted, C4 is a state of mind. So I'm not going to wait until next year. I'm not going to make you wait until next year. You, Indie Developer, need some advice on testing your Mac apps now. As I develop my talk for next year (which may or may not actually occur), I'll post the content here. Expect the first installment within a week.

*Is there a better link for people wondering what C4 is?

†Some people have trains of thoughts. Mine seem to be closer to trees. Footnotes seem less distracting than parenthetical commentary.