Software Testing: Line By Line

I was reading an article a few months ago entitled, “is Silicon Valley the next Detroit…”, and I found it very interesting.

It was a little backwater Newsweek article (you can read it here) and probably didn’t get much press. However sensational it was, it did reference one great industry titan that once dominated our culture, General Motors (among others as a testament to the size and scope of the Detroit Metro Area and the Auto Industry – much of this parallels Silicon Valley’s dominance in the Information Technology space).

Continue reading…

One of the basic challenges with test automation is adoption. I can’t tell you how many times I’ve cataloged licenses for a company and found out they already have many different automation software packages, none of which is being used. Traditionally I’ve been told that is because the tools don’t work and that the teams had a hard time implementing the automation.

Let’s take one thing off the table, there is NO tool problem. Most automation tools do the same thing, catalog objects, record and playback and advanced scripting abilities, so, please if you trying to organize an automation project, don’t make it a tool decision.

Continue reading…

I got some comments on my post “Test Everything all the Time” — most notably people commenting that it’s impossible to test “everything”. I can’t agree more. The point of the post was to make the point that we need to be able to test “everything we can” all the time. That is, you should be constantly iterating your automation, and not “waiting to run” the automation. Also, the point was to talk about how test design can solve all of your problems, not the automation tool. The tool is just an means to an end.

Continue reading…

The challenges with any automation effort is to know your capability. I’ve seen too many automation efforts begin and end with a tool decision. Generally these tools are very complex pieces of software that do many more things then we would ever use in our normal everyday testing. It even adds more misery to the situation when we give this new tool to people who are entirely incapable of using and scaling the “newly” selected savior to our automation effort.

When I teach, I call this moment .. “it’s like giving and atomic bomb to a caveman”

Continue reading…

Back from more training, I was up at a client in Bellevue and really enjoyed teaching a performance class to a world class testing organization. I found that the students were very receptive to many of the concepts and ideas that the class offers.

One of the items that we talked about was the nature of the service based app delivery model. As we have all seen over the last 5 years, the cloud is really changing the software development deployment abstraction. I think we will see most of our applications served through this new cloud model, but our development cycles will be 10x faster and more chaotic.

Continue reading…

I’ve been teaching a lot lately, was in India for one week, and I’m off to Seattle in two weeks to teach on performance topics. I thoroughly enjoy teaching, it allows me to stay sharp with current trends, and provides a nice break from the “implementation focus” that I generally have day to day.

Continue reading…

The Cloud demands that we be as nimble as possible, delivering features and fixes in almost real-time fashion. Both customer and provider rely on software development that can maintain quality while being light on its feet and constantly moving. In addition, Cloud-oriented systems tend to be highly complex and dynamic in structure — more than our industry has ever seen before.

The traditional software development and testing models do not support this constant “diligence in motion”; therefore a new Cloud delivery model must be adopted. Traditional models worked reasonably well in the world of client / server, since users were most often internal resources. User experience was downplayed, and glitches tolerated.

The lengthy cycle for requirements generation and feature development, followed by a set of testing cycles, allows for extended periods of time without testing. But these gaps do not correlate with the needs of Cloud consumers. For them, ongoing, reliable, uninterrupted experience is everything.

An effective delivery model of software for the Cloud pivots on one key moment – the instance of feature release. A provider or customer must be able to fix or change application features on-the-fly; that is, all tests for this fix or new feature are complete at the moment of feature release.

The only way companies can realistically achieve this model is to have superior test sets, that are fully automated – and to go about automation the right way. Otherwise it can quickly become unachievable and unmanageable.

Continue reading…