Wednesday, May 28, 2008
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.
Monday, May 26, 2008
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.
Friday, May 23, 2008
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.
Thursday, May 22, 2008
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.
Tuesday, May 20, 2008
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.
Friday, May 16, 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)
Wednesday, May 14, 2008
So, here are some new things I'm practising everyday:
- 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.
- 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.
- 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.
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.
Tuesday, May 13, 2008
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.
Monday, May 12, 2008
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.
Wednesday, May 07, 2008
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
Monday, May 05, 2008
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.
Thursday, May 01, 2008
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:
- They spent some time putting themselves on the Internet.
- Entertainment value
- I have read their work or attended a presentation before and they were worth coming back for.
- Create interfaces that are scriptable
- logging and capturing information from that
- training to build up tools to do performance testing
- outside consulting
- test labs (either external, or internal) for any large system
- 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.