Tony Stark, Engineer Extraordinaire ...

For many years, I recall watching movies and seeing how things didn't meet reality. There are a few things that bug me about movies, especially when computers are involved. For instance, the incessant "beep" noises computers make when the monitor is updating. Also, that computers seem to have a screen draw rate that of a typewriter. I know, leave your brain at the door, but its hard sometimes. Movies like Hackers drive me up a wall and try as I might to erase it from my memory, it appears that its still there. ... oh, I'll get back to the point.

I watched Iron Man this weekend, and it had its fair share of these annoyances, but the thing that surprised me the most is that it really stuck to some simple engineering principles to help create the story line.

I won't give away the plot or ending, but I'll elude to some of the details of him and his suit. He ends up building his suit, needless to say because they show part of the fabrication process in all the trailers. During that time he employs engineering principles quite well, started with a design phase, followed by a fabrication phase (but he built the first one by hand, after a few iterations, he automated the fabrication process). After that, he went into a recorded/session captured test cycle with a digital camera. During his flight tests, he records the session and debriefs after the session is complete. The whole test cycle was exploratory in nature, the only way to try it is by doing... in his words "you sometimes have to run before you can walk"

After he create the initial prototypes, he automated the fabrication processes after he put the suit through the paces. Five hours to build a new suit, so he can always have the latest build, usually with improvements after the test

Remind you of anything? Good lesson learned about engineering and how often we can easily take our processes and forget the basics. Great job by the movie makers too on keeping this philosophy alive and keeping true to the basics. Made it seem realistic by employing realistic techniques.

Presentation Zen and Garr Reynolds

I like non-fiction and documentaries. So, I also like learning stuff, kind of like TVO or PBS styles of shows. Have you heard of Google Talks? If you don't know about these Google Talks on YouTube, highly suggest going there and finding out. Very handy resource and a good way to feed your brain with some knowledge. I have basic cable (around 30 channels) at home and often there's nothing on. So, I sometimes feed on this stuff.

So, I was at home watching this presentation by Garr Reynolds about "Presentation Zen". Garr's whole thing is about presentations and how they can just be better. His style has a Steve Job's vibe, but with more pictures. His ideas are distilled down to simplicity for your presentations. I have often been caught in the trap of putting too much information on the power point.

Do you do presentations? I'm sure you do. I do. Either phone calls, webinars (I hate that name, but it makes sense), real presentations in front of people, etc. I tend do at least one of these types of presentations a week. Over the years, I try to do the Toast Master's stuff (speak slow, don't use "umm's", etc), but there's so much more to presenting than just the speaking style.

So, he's basically saying that there are many ways to present data. Lots of ways to represent data and power point is not the answer, its just a tool. Some of the thoughts are from other people and he distills down to a few points. Here are some of the basic tips I got from the presentation and they might help you out (I'm trying them out now):

• go to a white board or get a pen an paper and write out/draw out your presentations. Getting away from your computer will help you clear your mind and get away from the bullet point mentality. It also will get your creativity working because you're not locked down by the computer.
• don't use bullet points, but simple one line ideas. Feel free to use props or other visuals. If you need bullets to give people information, make a handout or give them a PDF so they can have it available. They are there to see the content, not read it.
• don't forget to play and have fun. That includes putting humor or your personality into the presentation.

Great video, got me started on other books to read too. Now it's time for me to go pickup the book! If you just want to see the video, the YouTube, link is above. If anything, take a look at his blog since there's a lot of information up there and its free.

Design for testability, TestNG

Another friend from work sent me an MSN link last Friday about an interview with the guy who created TestNG (a JUnit replacement) that allows for a few things beyond what JUnit can provide. The thing that piqued my interest was that it allows distribution of tests on slave machines, beanshell integration, and dependent methods for application server testing. Also, that TestNG is designed to cover all categories of tests: unit, functional, end-to-end, integration, etc. So I can get someone to create data driven or keyword driven tests and I can remotely execute them. I may not need FiT to do it now!

Anyway, I need to try this out. It would be nice to get this to be used for the simple remote execution aspect. I can then have unit tests tested across multiple environments and centrally controlled, rather than the other way around.

Oh! The creator of TestNG guy also has a great post about how TDD is not the end-all for software development; the anti-TDD movement. Interesting to see that they consider TDD just another tool in the toolbox.

More contemplation is required here for sure. But all really good information about how software development does coincide with testing on many levels.

Oh, here's an aside - I used to help teach people how to do TDD. Mostly as a 2 hour seminar. I'm going to redo the seminar to use testNG now so I can show off the evolution of test tools. I think there's a thought-lock on using xUnit for applications. How I see it, things change and sometimes its good to update the tools. This will be my way of evaluating this tool and I'll let you know how it goes.

Automate!

One my colleagues found this program called Automate! and I found it to be a nice way to do some simple application scripting.

After playing with it makes, the system seemed to break down all the functionality down into simple terms. I also like it from a perspective that it will take a non-coder less time to absorb - plain english tests. The language is so plain that you don't need to know about variables and structures to get productive. It did seem a little more than record/playback because you have to structure your script to look for object; meaning that you don't "record" in regular terms, you actually have to know how to use the application to determine locations, etc.

Why am I writing about this tool, well from my experience, I have a hard time getting people to write scripts from a point of view of automating redundant tasks, that seems to be a hard concept to get people to do absorb. Part of it is because often we don't treat our automation efforts like development projects (although that is changing).

I think context is what matters. For me, I'm relatively language agnostic meaning that I don't care what language I'm in, I'll learn it and try it out. But for some people, that's not their strength. Automate is language independent, albeit vendor lock, it can be a useful tool.

I'm only saying that this is an interesting tool for those people are out there. I wish there was an open source alternative for this type of application, however many of the developers out in the open source world can already program, so this is definitely filling a niche. Actually, if there is an open source alternative (and I'm not talking about AutoIT or autohotkey), please let me know. I know a bunch of people who would like to know this information.

It comes with 30 eval, but after that it can range from $800 to sky's the limit.

Expected quality of the experience...

On my trip out west, I got to go to a restaurant that I wanted to go to for a while. The reason I went was because I read that they had some of the best Indian food around. I bought the cookbook written by the owner of the restaurant and made some of the recipes. It all seemed very appealing and given the opportunity to experience the cooking first hand.

My expectation was to have some of the best Indian food around. When I got there, I was met by the owner at the door, explained how it works around the restaurant, so there was no guessing from my part. He told me there was a 2 hour waiting list and they had a nice lounge for drinks and they offered free h'dourves. The guy taking our names remembered my name and came and found me. He didn’t just yell out my name, but gave the personal touch. They also told us that we didn’t have to wait the whole time in the restaurant, so we went for a walk around the area. For the most part, even with the wait, it was an enjoyable experience because of the service level given and the atmosphere.

When we eventually got to our table, and no one person was responsible for order, it seemed that everyone did everything. The owner went out of his way to come talk to us too, even when it was so busy, he could easily spend his whole night at the door. We got there around 7, ate at 8, left around 9:30 and it still had a 2 hour wait at the door. Good prices and overall impression left me wanting for more... to the point where when I didn't finish my meal (it was huge), the owner came over at said "eat, you look famished" and proceeded to put more food my plate.

All of this was above and beyond the experience I expected. The principles are simple and applicable anywhere. Give you customer the easiest possible experience and give them the best service you can.

In software, we should do the same exact thing. From a testing perspective, so as above - test of the restaurant condition - will it meet your expectations of a good product? Software should be easy to use and complicated software sometimes screams to me that we put too much on the user. Sometime users are power users, but if you're planning on making something useful, do it right.

In that, simplicity is the key. Think of Google, it beats all the other search engines out there because of its simplicity. In the background, the system is very sophisticated, but the key in how it works is in the user experience and the simplicity of finding information. The results from most searches meet my expectations (which means my result is usually somewhere on the first page).

So, another lesson learned for me, and a personal test heuristic too – the restaurant condition. Or is it a test oracle? I’ll explain more about that on a later posting.

CAST 2008

The 3rd Annual Conference of the Association of Software Testing (CAST) 2008

Toronto, Ontario, Canada, July 14-16, 2008

Beyond the Boundaries: Interdisciplinary Approaches to Software Testing

Keynote Presentations by Gerald M. Weinberg,

Cem Kaner, Robert Sabourin, and Brian Fisher

Tutorials by Gerald M. Weinberg, Scott Barber, Hung Nguyen, and Julian Harty

The Association for Software Testing is pleased to announce its third annual conference (CAST 2008), to be held July 14-16. The meeting will be held in Toronto, Canada, a city which features enormous diversity in culture, businesses, educational institutions, and the arts. Toronto is the perfect location for a conference on this year’s theme: "Beyond the Boundaries: Interdisciplinary Approaches to Software Testing".

You can view the most recent brochure here, and you can see the conference program here.

(text stolen from Scott Barber's blog)

Jerry Seinfeld has a trick

I read in some magazine a number of years ago about Jerry Seinfeld and one of the reasons he was successful. When he started his career, he had a hard time finding new material. Sometimes it came to him, but often he would have a writing block. Then he tried a technique where he uses a calender to track that he writes one new joke every day.

So, here are some new things I'm practising everyday:

1. Trying to write this blog everyday. I have made sure I have enough material to cover me for a while, its just that sometimes I need to edit, which takes me the most time.
2. Going for a walk every day, even if its for 20 minutes. Sometimes I bike to work, but I try to get some blood flowing each day.
3. Not eating snacks after dinner. Basically making sure I'm hungry before I go bed. I have a huge problem with snacking, so I decided to not cut it out, but make a conscience effort to remove it from the evening.

Anyway, so far, I have been able to keep this blog floating for the time being. As for the walking, some days are better than others. Same goes for the snacking.

I guess what I'm trying to say is that practise makes perfect (or at least consistant)...Same goes with software development. Any of our efforts require you to take the time to learn and practice the art. So, resolve to do something every day to improve what you do at your job.

Zipline and single points of failure

Ever heard of a Zipline? Basically, you attach yourself via a harness to a rope and you zip along a line, except the line happens to be 500 to 1000 feet off the ground and your line can be up to 1000 feet long. So, after doing this on my recent vacation out to Western Canada, I occasionally thought to myself, what's the single points of failure on this thing? A little morbid, but I like trying to understand my surroundings, and my instincts tend to lean towards breaking things.

The rope... each "rope" made of steel was comprised of 200 threads of steel. This is the type you use when you're stringing heavy objects to buildings, etc. The harness had at least 5 different points of failure with some redundancy. The zip line harness had two points, with two carabeeners available too. The platform in the trees had redundancy too...It keeps going on and on. A seemingly unsafe ride was probably more safer than walking across a street.

A good lesson from this is that we should take our single points of failure and make sure we fortify them or make them redundant in the systems we build and support. The feeling of being secure made the overall experience quite enjoyable. The fact that it was secure was not the most exciting part, the part where I was going around 120 km/h at around 500-1000 feet off the ground was the enjoyable part. I highly suggest shelling out the money if you want a great ride.

PS: That's a picture of me on the zipline.

Scheduled posting now live in Blogger

I went on vacation for a few weeks, so you may have noticed that there were posts available before the date had arrived. Good to see that when I get back from vacation that this feature is now available on blogger!

Anyway, I'm going to try to make use of this feature since I keep about 10 posts on my computer before I post them, so this might be a good add-on for me. If anything, it will prevent me from moving to Wordpress or something like that in the future.

Books - Managing Humans

Not often do I read a book as funny about management than this one. I've read the Mythical Man-Month, PeopleWare but those books were quite insightful, but d-r-y. This book was refreshing because the point of view is from someone who's lived through the industry.

There's a lot of biting humour and the thing I got from it is that people are not broken down into simple categories. Management from a producer or consumer perspective is "an art", and this book tries to convey that message. Anyone trying to manage people or if you're being managed by someone else, try this book out before the two I mentioned above. Again, I think it has taken the best parts of the dry books and distilled it down into a semi-fictional, funny and witty book.

The chapters are broken into small manageable chunks that you could work through over a quick period of time. I read the book in a few nights. Here's a quick sampling of the chapters:

• Ch. 1 - Don't be a prick
• Ch 18 - Status reports 2.0
  
• Ch 25 - A nerd in the cave
• Ch 31 - Rules for the reorg

Let me know how it goes if you end up reading it because of this post.

The Nine Forgettings

This is a presentation I saw at the STARWest 2007 Conference last year. It was a great presentation because as software testers, I think a lot of people don't know how the industry has grown up. In fact, I am one of those people who didn't know where we came from. After this presentation, I decided to find out as much as I could about many of the people mentioned. I would suggest to you that you use your Google-fu to find more information, just so you can arm yourself against people who might steer you into 1983. :-)

Here the Google Video link. I would suggest you watch it since its a great lecture and not too long (around 35 minutes).

However, if you don't have the time, to tie you over, I attached a copy of the power point he created.

KWSQA Quality Conference 2008

I had the privilege of going last week to the KWSQA Conference

This was a great conference because it was developed by practitioners for practitioners. The speakers they had lined up were also quite interesting. I tried to pick speakers that met a few criteria:

1. They spent some time putting themselves on the Internet.
2. Entertainment value
3. I have read their work or attended a presentation before and they were worth coming back for.

Michael Bolton is one of these guys who seems to be published everywhere and has a great teaching style. I was very lucky to be able to participate in a open discussion with him and a few people. I brought my performance testing scenario and we debated and discussed in an open forum our issues. It was great to have that level of interaction with people who have far more experience in the field than I do. They gave me insight into things like "am I really done testing?". I said no because testing goes on, but in fact because of the lack of some cohesive interfaces, my answer changed to, "yes, it is done... for now". It gave me a perspective on how to deal with people. Interestingly enough, things you can do to drive performance tests are:

1. Create interfaces that are scriptable
2. logging and capturing information from that
3. training to build up tools to do performance testing
4. outside consulting
5. test labs (either external, or internal) for any large system

Also, three major types of sizing:

• customer sizing so they know what to buy/maintain, etc;
• development sizing, to see where development should spend the money or time for load, etc;
• product management sizing, they want to see the product perform at a certain level because the market drives the metric.

Given those criteria and advice, I think I have an excellent way to help manage and consult on my next task. I'm also taking a risk-based approach to this whole problem whereby I'm going to ask the question "I want to know what's important to you" and let them drive the tests. There's a lot more to this point and I'll save that for another day.