COMMON: A Vendor's Point of View

I was digging around the other day and ran across a discussion in another forum about the decline in attendance at COMMON. Here is an excerpt from one attendee's point of view that I took some exception to.

"Also, the vendors should put some of the blame on themselves for being pains in the neck after the conference by calling you up every week to see if you are interested yet. Over the years I have learned that the free stuff is not worth giving up my business card only to be hassled by a sales person who can't take no for an answer. I have yet to get really useful information from someone there on the Expo floor because the sales force really can't answer the technical questions that many of us have about their product. It really irks me to walk through the Expo floor only to have one of them ask, "Are you doing any software development?" or some other pitch that the obvious answer is yes. Of course we are; that is why we are there! I would rather see a focused technical session on their product that I could attend if I was interested. Who can decide anything on the five-minute rat race that is given at the Expo?"

My Response:

First of all, the expo is a very strong financial supporter of COMMON. Take away the vendors and your registration fees will jump dramatically.

Second, the expo is a service to the attendees. If you scoff at that thought, then you are missing the point. Most software vendors view themselves as a solution providers. Yes, we would like to sell you our software, but the only way we are going to do that is if we can prove to you that it is a valuable and cost-justifiable solution that you and your company need for problems that you are currently having. I can't tell you how often people stop at our booth to enter a raffle only to leave willingly with product brochures describing solutions that they never new existed for problems that they are currently plagued with. Additionally, any solid vendor is not going to sit still in their product line. There will always be something new. So, skipping the expo because "it's the same ole', same ole" is doing both yourself and your company a disservice.

Third, let's be realistic: if you drop your business card in a fish bowl, someone will call you. If you don't want to be called, don't give out your card, just take some literature and move on. If you are called, but not interested, simply tell the person this and ask them not to call you again. Chances are good that they won't. No sales person has ever made a sale by pestering someone to death.

Finally, many vendors do, indeed, bring their technical resources to the shows. I am living proof. My company sends me quite often, just for that reason. In fact, many of them also give sessions in their particular field of expertise. I have given several "Change Management 101" type sessions. Will they be able to answer your every and most difficult technical question, no. No one person can, and no company can afford to bring their entire shop. But I don't know a vendor on the floor who isn't willing and able to forward your question on to the right person.

So, the next time you are at COMMON, give the Expo another shot. If you have the right mindset, I think you'll be pleasantly surprised. But be careful! You just might find something there that could dramatically improve your life and your company's bottom line.

Setting up QA in an SCM Environment

A customer asks: "The upper management here is also trying to get a Quality Assurance Environment set up to use with our SCM tool. We do not have a lot of experience with QA environments, can you recommend a website, document or other information you might have in order for me to get started? I'm not looking for specific details, but would like road map of things to keep in mind when setting something like this up."

First of all, let me state that there are some SCM vendors that offer their own testing tools and there are other SCM vendors that recommend another vendor's "best of breed" testing tool. Each of those solutions has its pros and cons (I'll save that discussion for another blog-day!)

What all vendors provide, however, is the ability to manage your QA environment. Your first big question is this: how much testing do you need and who's going to be doing it? Is it the programmers? Do you have a separate QA staff? Will then end users get involved?

If it is just the programmers, then you probably just need one "System Test" environment, e.g. DEV to ST to PROD.

If the developers test first, then hand it off to QA, then you should have separate environments (and libraries) for each level, e.g. DEV to ST to QA to PROD. This is because the QA people will want very tight controls over when a series of changes can come into their world and when it can leave their world. They don't want to be shooting a moving target, right?

Finally, if you want the users to get involved in testing and approving their changes, you should set up a User Acceptance Testing level, e.g. DEV to ST to QA to UAT to PROD. Again, the idea is that you want the UAT environment to be very tightly controlled. Only one task's objects should typically be in UAT at a time.

For each environment you defined above, you will teach your SCM tool how to manage it by answering the following questions:

• What are the library name(s) for source, object and data? (You can have them all be in the same library if you wish).
• Will you maintain a full compliment of all database files at each level? (I recommend yes, albeit with a very small set of test data in each level. This gives many advantages to you that I can explain later if you'd like).
• Would you like to have just one data library, or multiples? (Hint: multiple data libraries sometimes come in handy if you have more than one tester, more than one application, etc).
• Will you maintain a full compliment of all objects at each level? (I recommend no. Keep each level empty except for the objects currently being tested at that level. Let you library list find items in the higher levels when you run your tests).
• How should you promote into this environment? (I recommend copy source, compile the object over the appropriate library list).
• Whom can execute the promotions at each level? (I recommend that Programmers can promote freely into the ST, but only QA can promote into QA and UAT).
• Would you like any one (or any group of people) to approve or sign off on the promotion before it can run? (I recommend yes! This is an easy way to get "electronic signatures" on file proving that you have followed your established procedures. It is also a fantastic way to end forever the classic complaint from the end user "this isn't what I was expecting"!)
• When a promotion is ready to be pulled in to the next environment, whom should be notified, how and what to say?
• When a promotion has successfully updated an environment, whom should be notified, how and what to say?
• Would you like to be able to recover (undo) a promotion into this environment? (I recommend yes to give you the ability to back out a promotion that really messed up your environment or that was promoted too soon.)
• When the promotion into the next environment is successful, would you like to remove the items from the lower environment? (I recommend yes for all items except the database files).

There are two "best of breed" testing tools that I have experience with. Original Software and SmartTest. Original's web site has a host of other great white papers that are worth reading to increase your base knowledge of the QA process.

Also, I'd highly recommend that you read this excellent white paper by Paul Conte, "Application Testing Basics: A Practical Guide to Improving Software Quality". You can find it here.