The folks at TechSmith make a nice screencasting tool called Jing that I've been using for quick tutorials and various documentation. It comes in two flavors, free and pro, but interestingly, I've found the free versions limitations to almost be features.
For example, it only records 5 minutes of video. Personally I find that tutorials longer than 5 minutes to be too long anyway. If you're rambling on for longer than 5 minutes, your listeners are gonna move on.
Which brings me to another limit/feature... you can't edit the video. I also like this because I want to make quick tutorials... not monkey around with video editing. This forces the issue.
The free version only records video to swf (pro version does mp4) which again, is kinda nice. You can drop the resulting swf onto any modern browser (with flash installed) and the video will play. No additional apps required. It's also a *snap to embed in a web page (see below). Additionally, it runs on Mac & Windows, has nice stingers and can also do screengrabs with markup.
Now, that said, if you're looking to build a slick, more professional screencast, Jing will fall short. It's strengths are agility and functionality... pretty is another apps job.
*Update... okay, so there are some issues playing back swf files on windows :) Here's a link to the video.
This past year, I switched the default browser on all my machines--Macs and PCs--from Safari, to Google's Chrome. Ironically, the reason was because of UX (User Experience).
::SPOILER::It was the URL bar.
Like most browsers up to that point, Safari had two forms in the bar; one for entering a URL and one for searching the web. Google melded these two into a single URL/Search bar (reminds me of a single button mouse), thus, when I open a new page, focus is in the bar and I can just start typing a search term or a url. Brilliant!
Safari and Chrome share the same engine, WebKit, so they're very similar in speed and general abilities, which makes this coup even more impressive. They snuck inovation in to the very top of my browser workflow! Because this is what I end up doing most in a browser, once I got a taste, I was addicted and found myself typing searches into other browser's url bars. I became annoyed with Safari's antiquated two-form functionality, and eventually I moved on.
The irony of course, is that Apple has a history of being pretty good at UX... and I'm excited by the idea that more companies are making UX a priority. I wouldn't say the torch has been passed... but rather, additional torches have been distributed.
I've been watching some of the presentation videos from the 2011 Google Test Automation Conference (GTAC) and found this one to be particularly interesting. Entitled "Building a Test Grid for the Cloud", Simon Stewart talks about writing tests, ensuring test isolation and testing in the cloud (including Amazon's EC2).
There's an old joke in Bluegrass music circles that goes "Bluegrass musicians will drive hundreds of miles to jam with people from their home town". It's funny 'cause it's true. While attending a ThoughtWorks workshop this past year, with a faction of my company's QA team, I discovered this joke can also apply to software testers. Eg. it can take traveling hundreds of miles to get testers from the same company to work together.
At the workshop, it quickly became clear that many of the questions or pain-points expressed by individuals within our group, were at least shared by, and in many cases, could be solved by, other individuals from our group. With that powerful knowledge in hand, I paired up with a coworker to hatch a plan (over cocktails... 'cause we're from Wisconsin) to leverage this shared knowledge and pain.
The plan was simple enough; set up bi-weekly QA meetings, at which a pair of testers would facilitate the meeting and make a presentation to the rest of the group. Fairly straight ahead but there's some details to call out...
The meeting will:
Be one hour. Topics must be sized and focussed to fit.
Facilitated by a pair of testers. The idea being each will QA the other's work, thus solidifying their concept and streamlining the meeting.
Be tool agnostic as possible (unless the a tool itself is being presented).
Include an example(s).
Attempt to ask and answer a question.
Concentrate on topics that affect the entire group. Questions will come up at the meetings themselves that can/should be tabled for a future meeting topic.
The overall premise for the meetings are for the presenters to "show their cards", as it were. Show examples of what they are actually doing; not what some book says you should be doing. This is essental and it takes a lot of courage to expose yourselves in this way... especially to a room full of QA! I've found the fear/pain from such exposure can be lessened substantially by pairing facilitators and allowing them to come to a concusses before presenting. Strength in numbers! This has also proved to keep the conversations at the meetings focused.
We've been running these for a couple months now and the response has been extremely positive. I documented one of the topics from a meeting in a previous post... I'll try to continue to do so.
My current project, internally known as Bug Remediation, had the lofty goal of fixing every single bug for one of my company's mature products. Today we accomplished just that. One of my apps now has zero known issues. No really... zero!
Over the last year I have been working on various products and projects, during which time, I had also been experimenting with new testing tools. All this experimentation had led to some nice epiphanies but had also left behind some serious organizational collateral damage. Honestly, I'd never given test organization all that much love (and it showed). So I decided to look at this as a learning opportunity and see how others were organizing their code. And when Google proved to be less than forthcoming on the subject, I turned to some of my QA brethren. My coworker Jason and I paired up to hash out a structure.
This discussion turned out to be extremely interesting as Jason and I work on different products, use different tools and program in different languages. Test organization is something all testers must tackle, thus the goal was to keep everything product, tool and language agnostic. We came up with the following...
The basic structure is:
Product > Project > (Domain) > Tests > Steps
Imagine each of part of the structure as being a bucket that holds the next... in my case they're folders but they could easily be classes and methods or what-have-you. With that in mind, let me explain some of these "buckets"...
My team works on multiple products so this is the hightest level of my test hierarchy. If you work on only one product, this might not be your uber-bucket... or maybe you work with multiple companies and "Company" would make more sense for you... whatever works. For my example, each Product can have many Projects.
A project equates to a software release. 'Nuff said.
This is an optional bucket that can also take many forms. It's primary purpose is to organize individual tests. For example you might separate tests based on which web page they're found on. They could be broken down by user story, etc.... It depends on the situation at hand.
For me, these are actual test files that test specific functionality. These could--as in Jason's case--also easily be classes. Each of these files/classes can then be bundled together and run as a larger suite of tests, or included in any number of instances as required.
These are the actual steps take to accomplish the test. Often times these are functions or methods.
Obviously this is not rocket surgery but it's something that all testers deal with. My example is working for me currently but I could see how it might shift in the future. As always... YMMV.