The Latest

In major companies, one out of every four expense dollars is spent on information technology. As IT becomes more important to business, it has to be run as a business--be market competitive, be market ready, offer the customers options, manage itself with a strong fiscal accountability, treat the money it's responsible for as an investment. The notion of running IT as a business really means making IT competitive through the regular market pressures of the business that houses it, and more and more companies are understanding this.

There are five main risk areas in E-Business (EB) system development. These risks relate to usability, performance, security, availability and functionality. This paper presents an overview of the risks of E-Business and a framework for creating an E-business Test Strategy.

A two-stage approach to transforming quality control to quality assurance: Quality Assessment (Stage 1) provides objective quantitative evaluation of quality while identifying and fixing software defects early in the development cycle, before they get to the customer and even before testing; Quality Assurance (Stage 2) helps prevent defects from entering the code base by enforcing coding standards during, and by preventing new defects from occurring during times of change through accurate impact analysis.

This slide presentation discusses CMM Level 2 and 3. It describes characteristics of a mature measurement program at Level 3 and discusses measurement requirements from an assessor's perspective. The presentation provides examples and offers ideas on good and bad practices/programs. Measurement requirements are embedded throughout the model.

Those who talk about software development process seldom forget to mention the importance of a project post mortem. All books on process management that I have read and all company Web sites that I have visited have something to read about project post mortems. And my concern here is, do we realize the importance just because everyone else is talking about it or are we committed to use it because the concept sounds relevant? And if we are committed, then how do we take the best out of it?

"No Fred, we're not considering you for that promotion. You're too valuable where you are." How many of us have heard those words, or said them at least once to our staff? Sometimes, we use the "too valuable" phrase to avoid discussing problems with a staff member, problems you can bring out in the open and manage.

Exploratory software testing is a powerful and fun approach to testing. In some situations, it can be orders of magnitude more productive than scripted testing. I haven't found a tester yet who didn't, at least unconsciously, perform exploratory testing at one time or another. Yet few of us study this approach, and it doesn't get much respect in our field. It's high time we stop the denial, and publicly recognize the exploratory approach for what it is: scientific thinking in real time. Friends, that's a good thing.