Handy Reference: Cursor Styles

How about a little front-end fun? Here are some cursor styles, cut and pasted from the following web site: http://rainbow.arch.scriptmania.com/css/css_cursor_control.html. Mouse over the stuff below to see the cursor change.

cursor: auto	the default cursor
cursor: crosshair	gun-style cross
cursor: default	no change
cursor: pointer; cursor: hand	the normal link-hand
cursor: wait	the hourglass
cursor: text	the text-selecting 'I-beam'
cursor: help	an arrow with a question-mark
cursor: move	crosshair with arrows on the ends

Development posts

I'll be mixing in development-oriented posts here until such time that I create a separate blog, or just change the title. I'd like to put in some handy reference materials. For example, it'd be nice to have one reference to string formatting that has every instance, and a few examples of each in action. There are a few such things out there, but they're not as good or clear as they could be.

They made me a developer

There was a bit of a shake-up here at work. They let go the full-time tester, moved me to development, and made the support guy the QA guy. Which is grand for everyone except my QA protege, and I'm not sure what it says about my testing ability. Granted, I'd been angling for a shot at development all along, and I consider this a move in the right direction. I'll always consider myself a tester, regardless of my job title. At least, I hope so. Testing is intellectually exhilarating when done right, and when intellectually exhilarating testing is asked for by the employer/customer.

My casual post-mortem of the shake-up leads me to the following conclusions:

• Our business model doesn't require as many people dedicated to testing, since our clients generally provide their own QA personnel.
• Our testing is not an on-going thing. It happens on an on-demand, by-request basis. Paying two guys to be full-time testers doesn't make sense in our small company. The utility that is gained just can't justify the costs, not unless management and/or QA find better ways to utilize their time.
• If I hadn't shown some proclivity in programming previously, I would be riding into the sunset alongside my colleague (whom I referred to this job, making that whole affair all the more difficult).

In the end, I can see how it was the right way to go. There will come a time when we will have different QA needs. It will evolve into something similar to what we had. I would love to see QA being done by developers. I mean real QA, not cursory checks and over the wall she goes. But that would require the devs to laterally learn that which they're not super-pumped about. It'll be interesting to see how that goes. Implementing new systems and new initiatives around here is a bit like pulling teeth.

Books

Please read Lessons Learned in Software Testing, and Computer Software Testing. The former is a book that can be read straight through and is quite enjoyable. The latter is also quite enjoyable, but it reads more like a textbook for a class. Still, it would be worthwhile to read it straight through and refer to it as needed. There is a lot of combined wisdom and experience that can save you a lot of trouble.

On-the-fly test plans

I'm trying to encourage testing as an inquisitive, intellectually-engaged process. While test cases, test-case management software, and excel spreadsheets can be useful, they can be counter-productive if they take the place of good detective work. In my experience, they serve as a reminder of what to test, or more accurately, the things you jotted down last time you considered what you should test and jotted things down.

I wonder if, in addition to or replacing entirely a bank of static test cases, it would be better to create on-the-fly test plans/cases. This would consist of opening up a blank spreadsheet, entering all of your assumptions about what should be tested, making a test matrix, deciding what portion of those tests should be tested, and reviewing your test plan briefly with a developer who cares.

This should not be interpreted as a linear or step-by-step strategy. These are just some of the elements thrown together roughly in the order of the first occurence of each item. Ideally, a developer or customer will be available throughout the process for clarification. You'll be seen as bugging and bothering people until you uncover some miscommunicated assumptions whose discovery saves everyone a lot of trouble. You'll build a reputation for heading off trouble before it troubles others, and developers will hopefully be more willing to be interrupted to answer questions.

Oops

I accidentally deleted my blog, doh! That's ok, nobody read it yet, or at least, no one commented on it. Maybe the Google crawlers didn't catch up to it yet. In any event, here's the blog again. A whole new world, blabety blah.