Chris McMahon's Blog

Since one post from this blog is (or at least used to be) a little chunk of official documentation for Basic Auth in Ruby, I decided I should write this down also. Socialtext is switching some of the SaaS servers to be https all the time. So I had to rejigger my selenium test-runner script, because it reads (test data) from and writes (test results) to the wiki. I found this very elegant example . My take on it looks like def put_test_results_to_wiki http = Net::HTTP.new(@test_host,443) req = Net::HTTP::Put.new(@put_loc, initheader = {'Content-Type' =>'text/x.socialtext-wiki'}) http.use_ssl = true req.basic_auth @test_user, @test_pass req.body = ".pre\n" + @content + "\n.pre" response = http.request(req) puts response end What is a little peculiar about this is that Basic Auth is very much optional for SSL connections. Normally the client would do a GET, the ser...

I like to point out that historical, well-vetted aesthetic frameworks are useful for evaluating software . But what if similar aesthetic frameworks could not only validate software itself but also *predict* software test techniques? For example, let's examine overarching schools of painting: first came realism, where painters attempted to represent as much as possible what appears to the human eye. We can test realistic scenarios, we do this all the time. I would suggest that most bugs are not discovered under what we understand to be realistic circumstances. Then came expressionism, where painters attempted to express things not seen. Likewise, test techniques moved on to persona testing (imagining the use of software by peculiar users) and soap-opera testing. Such techniques expose significant bugs. Then came abstract expressionism. Think of Jackson Pollack. Are there abstract expressionist test techniques? Of course there are . I would really like to hear of any other ...

Both of these have been crossing my path with increasing frequency in recent months (not at work, but in conversations with others whom one would think would know better): 1) Stories are scheduled work for features. Stories should not include: testing refactoring documentation undefined customer support calling your mom The problem with writing stories for stuff other than scheduled work on features is that you completely undermine the concept of velocity. Velocity is the number of story points accomplished per iteration. If you assign story points to activities other than scheduled work on features, you cheat the business of accurate information about release schedules. (Although it might make you feel better to be accomplishing so many points each iteration, if you are not delivering features, you fail.) 2) Doing it "by the book". Part of the agile culture is to have retrospectives at the end of each iteration. Each retrospective is an opportunity to change your process...

I'm chris_mcmahon there if you want to follow me.

Not long ago Audrey Tang started working for Socialtext. It has been a remarkable experience, as Audrey is mostly fixing bugs based on bug reports submitted by our testers. Audrey is in Taiwan and another of our testers is working from Bangladesh (although he is usually in Vancouver BC). Today they needed to hash out some details of a bug report so they shared a VNC session on a machine hosted in Palo Alto CA. It took only a couple of minutes to arrive at an agreement that the bug was fixed. Audrey's comment in IRC really struck us all: " having an excellent qa team is like driving with a first-grade GPS navigation system :)" We have worked very hard to create consistent, readable, executable bug reports for real, visible bugs. Having a developer as good as Audrey validate that work means a lot.

Very recently I was part of a bug hunt: an effort to find as many defects as possible in a UI in a short period of time. I am not an outstanding UI tester. I have worked with testers whose eye for detail, line, color, consistency, work flow, etc. etc. make them really outstanding testers to have examining the front end. But I've spent most of my career on green-screen apps, test automation, environment maintenance, stuff like that. I lack the really expert artist's eye that great UI testers have. That said, I was on a roll on this particular bug hunt, finding a lot of nice, sophisticated bugs. It was classic ET: decide a test approach, determine your next test based on the results of your last test; and when you stop finding bugs, change your test approach. I'd followed all the logical paths I could think of; I'd tried really big inputs and really small inputs; I'd tried permissions errors, navigation errors, and checking error messages themselves. I tried ...

My colleague Matt Heusser is doing this workshop on technical debt soon. I posted a little meditation on techdebt as impedance mismatch , but that seems to me to be trivially true, facile. Since I made The Software Artists public, though, I've been fielding a lot of questions on the software-test mail list that has me rethinking my position on technical debt. So here is what I *really* think: Technical debt doesn't really exist. At least, it doesn't exist for high-performing software teams. It's a useful concept for those encumbered by poor programming and poor testing, but the idea ceases to be useful about the time the code base becomes manageable. I have a graph and and I have a metaphor that both explain my position. I'll just describe the graph because I'm too lazy to hunt down some free software to draw it. This graph describes a couple of different projects I've been involved in, for a couple of different employers. The critical line on the gra...