Great piece on ABC TV regarding the LENA product from our good friends at Infoture in Boulder.  If you have a baby, or plan to have one, this is must-see-TV. 

http://cosmos.bcst.yahoo.com/up/player/popup/?cl=7518708

I am very pleased to announce that this week, a new company has been launched. WatirCraft is a software company that will provide products and services in support of the popular Watir open source testing tool. Our goal is to deliver test automation that works --throughout the software lifecycle.

My partner in WatirCraft is Bret Pettichord (the Watir project lead). Bret is widely known in the testing and agile development communities as one of the original authors of Watir, as an early contributor to Selenium, and as co-author of the book Lessons Learned in Software Testing.

I'm announcing this here because many readers of this blog know that for the past ten years, I have been focused on growing ProtoTest.  ProtoTest is not going away - quite the contrary, we have an excellent team and we're enjoying tremendous success in early 2008.  But I will be splitting my time between these two exciting companies in the coming months and years.

Over the last four years Watir has achieved a critical mass in the market that suggests the need for a company like WatirCraft. More than 85,000 people have installed Watir and many have expressed an interest in seeing more resources behind the product and the availability of support services. Bret and I have formed a bond of trust between us about how this kind of company should be run (given the existing Watir project, community, and shared goals.)

WatirCraft’s business model is based on an existing open source project with a broad base of code, where there is a significant community active in software development, and where we can provide subscription-based services to help people be more efficient and effective when using Watir. 

Watircraft will sell annual subscriptions for software and services, plus training and consulting.   Stay tuned for more information.

ProtoTest doesn't do offshore testing.  We believe strongly in the value of close collaboration between testers and developers, testers and product managers, testers and software users.  So far, at least, we have found that the best way to achieve that collaboration is to work side-by-side with our client.

But I'm curious to hear about your recent  experiences with offshore testing.   How big was your project (people and duration)?  What went well?  What didn't go so well?

I've been thinking about respect  lately in the context of software testing. "R-e-s-p-e-c-t, find out what it means to me!"  Sing it with me now.  

Nine years ago when I started ProtoTest, testers as a group didn't get much respect from developers or management.  Over the years, that has changed for the better in many organizations.  For one thing, as the software industry matures, both the producers and consumers of software seem to value quality more.   They are less impressed with software in general (familiarity breeds contempt?) but more impressed with software that works as expected, reliably and securely.   The role testers play in delivering higher quality software garners them some respect. 

But what can you say about those testers who earn the greatest respect?  IMHO, a few things.

They are intellectually honest.  They speak clearly about what they know, what they don't know, and what they suspect but can't prove (yet).   They don't try to spin the truth.

They understand that they are part of a business.  That means they know their industry or domain, and they appreciate that context is the key to selecting the appropriate approach and making effective business decisions.  It's never just about the technology.

Finally, they invest in themselves.  The best test professionals are constantly learning - new tools, new strategies, new techniques.  They are never content with same-old, same-old.  They are too passionate about software quality to be complacent.

There's a short Viewpoint piece in BusinessWeek online that's worth a look:

Insecurity in Open Source

One interesting tidbit - while open source software on average is has better quality and security than proprietary, software, the best proprietary code is shows much higher quality and security than open source. 

Borland is beginning to digest their acquisition of Segue and the Silk toolset.  Today they announced Borland Lifecycle Quality Management.  According to eWeek.com, "Borland LQM supports requirements definition and management; test management and execution; architecture and design analysis; development test and defect prevention; automated functional testing; performance and scalability testing; and defect tracking and version control..."  Of course tools to support these activities have been available from a variety of vendors for quite some time.  It will be interesting to see whether this is more marketing-speak (everybody needs acronyms - all the better if they contain the work "Lifecycle" these days!), or if Borland achieves real advances in integrating this tool suite.

The HP acquisition of Mercury is expected to close in the next 30 to 45 days.  People are speculating about how Mercury will plug into the HP software division, which is still busy integrating the Peregrine acquisition.  Mercury has not done a lot of internal product innovation in the past few years, preferring to add products and capabilities via their own acquisitions.  I wonder if that will change under the HP culture, which has been more engineering-driven (vs. the marketing-and-sales driven culture of Mercury). 

IBM has had much more time to adapt to their acquisition of Rational, and they have been rolling out new products and incentives to companies that switch from Mercury to IBM Rational tools.

It's a fast-changing landscape for buyers and users of QA and testing tools, which entails both opportunity and  risk.  

At ProtoTest we believe there are no "best practices" for software QA and testing.  "Best practices" implies that there is one right way to do things - for everyone.   We don't think so; instead we think your approach depends on the context of your business.  Plenty has been written about context-driven software testing, so I won't rehash all that here.  But what do we mean by "context?"  And, what's your context?

For instance - what are the risks you are trying to avoid?  If your software fails (in a big way or a small way), what might happen?  Will a customer abandon a shopping cart?  Will a satellite fall out of orbit?  Will you lose a $1-million a year account?

Also - what sort of development process do you follow?  Waterfall?  RUP? Agile? 

How long have the members of your team been in place - Product and Project managers, developers, testers? Are there risks associated with new members, or a whole new team?

What new, unproven or unfamiliar technologies are being used on the next release of software?

These and plenty of other questions can help to determine your context, and then the appropriate QA and testing practices for your team.

When you are planning to bring a tester on board - as an employee, a contractor, or even temp-to-perm, what criteria do you use?  We interview about 15 people each week, and then send some of those people out to client interviews.   The way companies select testers is all over the map.

Sometimes our candidate calls after the interview and tells us that barely any technical questions were asked.  The hiring manager was mainly interested in personality or cultural fit.  Other times, the technical questions seem random, and not really related to the work at hand.  Rarely, behavioral interviewing techniques are used (tell me about a time when...).  Some interviews are astonishingly short.  Others last most of the day, with practically everyone in the company taking a shot at the candidate.

There just doesn't seem to be much consistency in the processes or selection criteria used.  The best we can do is to know our clients and our consultants and candidates well enough to make informed recommendations.

This week we announced that ProtoTest has become a solution partner with Rally Software Development Corp., a leader in the agile development tools market.  Rally made the announcement as part of their participation in the Agile 2006 Conference.  Rally supplies a complete Agile Lifecycle Management solution that supports agile teams with:

• Release and iteration planning, scheduling and tracking
• Real-time dashboards of project status and team velocity
• Customer-centric requirements management
• Early testing and test management
• Defect and issue management
• Collaboration and communication

ProtoTest will be providing consulting to Rally users in support of build and test automation. 

We believe that the agile approach to software development has very favorable implications for software quality.  Things like test-driven development (writing unit tests before coding), short iterations with little or no testing backlog, documented requirements in the form of user stories, and heavy user involvement in the dev process all tend to drive toward a higher-quality product.

Many organizations, when they implement agile, bump into challenges with being able to build and test quickly enough to keep pace with development ("velocity").  That's were we come in... we can help with strategies and tools for automating both the build/deploy step and the testing (unit and functional) to keep the pace up without incurring testing backlog or "debt."

For more info, check out www.agilealliance.org and www.rallydev.com.

This weekend I saw Al Gore's movie "An Inconvenient Truth."  It's a powerful look at the facts regarding global warming (or as Seth Godin put it - "atmosphere cancer.")   There's a consensus in the scientific world that if we don't make major changes in our carbon emissions soon, over the next 50 years we are going to see an increase in average global temperature (including ocean temperature) that will drive a whole host of catastrophic consequences.  More, and more severe, storms, for starters.  Melting of huge slabs of ice in Antartica and Greenland, and at the north pole, which will raise ocean levels to the point that a big part of Florida (and hundreds of millions of people's homes around the world) will be under water.  And there's more.  

This got me thinking... as a services business, how can ProtoTest make changes to be more "green" and help reduce carbon emissions?   One thought is to offer our clients some incentive to allow our consultants to work remotely - from home - whenever possible.   Taking cars off the road, especially during stop-and-go commuting hours, would be a step in the right direction.  What do you think?  Would this work for you?  Would your company be willing to support this initiative?  

For more about the movie and the information that spawned it, visit http://www.climatecrisis.net/.