Archive

Archive for March, 2010

Software testing: from elusive and insufficient to attainable and just right

March 14, 2010 4 comments

Even today, the state of software testing can be described as elusive and insufficient.

In short – insufficient software testing carries significant business risks.   Global enterprises invest millions of dollars developing & supporting mission critical software which should enable sales, marketing, supply chain, and customer service organizations to serve their customers better than  competition.

Another perspective at this multi million dollar investment: global enterprises literally fund and operate their own internal software company to gain a competitive advantage.

What if this internal software company just doesn’t do enough when it comes to software testing?  What is the true cost of insufficient software testing?  The answer is both obvious and sobering.

Because every functional area is enabled by a significant IT investment …

every functional area carries a higher cost due to insufficient software testing …

… leading to lower margins and the loss of a competitive advantage if critical IT projects are late.

Let’s ask (and later respond to) three questions.  These questions will help anyone determine the state of software testing in their own organization:

One:  do you design, build, and then test?  Or – think about testing after most of the development has already been completed?

Two:  how do you characterize individuals that perform software testing:  embedded & engaged? Or – disconnected?

Three:  who are they?    The best and the brightest? Or – second class citizens in the technology organization?

Let’s respond to question One.

Software testing – by definition – is an integral part of software delivery cycle.   Software testing must be integrated in all critical areas:

– Design:  should be questioned without any hesitation as early as possible by those who test.   How can this be tested?  Is there another design approach which might make it easier to create an automated test in the future?

– Process:  the benefits of writing automated tests during development cycle are well-known.  Set a realistic code coverage goal:  80% of all critical functionality must be covered by automated tests.   Monitor this goal during development.   Do not release software unless the goal is met.  Create and monitor measures of success to ensure individual accountability.

– Schedule:  schedule must reflect not only software testing but also all the different types of testing required.   Otherwise, schedules become unrealistic.    If the design specifies 10,000 transactions per hour, appropriate tests must be planned and scheduled well in advance to determine if this scalability level can be reached.   That’s why those who test should engage early as equal partners.

Responding to question Two is now much easier.  If those who test engage early as equal partners, they will be embedded and engaged.

I think it’s best to leave question Three unanswered so the reader can answer it themselves.

Instead I will briefly discuss changes that are essential to create the organizational culture where software testing is an equal partner.

– Recruit, hire and retain the best and the brightest for software testing roles

– Create a compensation model that rewards software testing excellence

– Define and practice software testing as a true engineering discipline, not just an exercise in writing scripts

– Make software testing an integral element of delivering great products

Advertisements

How to guarantee failure of a global software development project

March 6, 2010 3 comments

No one wants to witness a failure of a critical software development project.  The failure becomes even more painful if the project has been sponsored at the highest levels in organization to achieve critical business results, for example:  provide 360 degree view of the customer relationship, enable multi channel customer marketing campaigns.

Yet global, critical, “failure is not an option” software development projects fail all the time.

Before getting to the heart of the matter, it’s good to start with a small grain of truth.  History has a way of repeating itself.

Peter Drucker said, “The purpose of the customer is to create customers (implied in his words:  nurture and grow existing customers)”.   Considering that new customers may not profitable until Year 2 or even later, it becomes critical to give some thought to Customer Relationship Management, or CRM.

There are plenty of lessons learned from failed enterprise CRM implementation projects:

– CRM is :  first – a clear strategy, second – an approach to implement the chosen strategy, and third – technology (may be but most likely)
– CRM is comprehensive and requires participation from all functional areas:  sales, marketing, customer service, fulfillment, finance to name a few

The biggest lesson learned from failed enterprise CRM implementation projects:  strategy is not equal technology.   If business goals are not aligned with how technology may support and enable these goals, it’s rather obvious that any global software development projects will experience a guaranteed failure.

It’s essential to first develop a strategy how to structure the project and align the structure with a) what (milestones), b) who (people), c) where (locations), and d) every dependency which will either inhibit or enable your project.

For the moment, let’s assume that the goals are aligned and technology roadmap to success is clear.

What could one do to ensure that a global software development project would experience an almost guaranteed failure?

The top reasons are (I will focus on execution related topics as they relate to building great software):

– Do not spend any time thinking about a solution approach (or strategy) which will recognize all major drivers of complexity:  process changes, architecture changes (many hidden requirements here), competing projects, functional migration efforts, new development efforts, technology platform changes.

– Make every team across the globe operate in the same manner, whether they are migrating existing functionality or developing new features

– Ignore timezone differences

– Declare that one approach will work for every problem (instead of matching one or more approaches to the specific problem)

– Spend no time on thinking about how to componentize major software deliverables

– Discount the value of “design by contract” approach

– Spend very little time on creating the build / test infrastructure which will help teams to integrate code developed in multiple locations

– Spend equally little time on planning rigorous automated testing procedures

– Underestimate how much time may be needed to clarify requirements

– Discount the value of an integrated program plan where all stakeholders understand dependencies and critical milestones

– Discount increasing concerns from business owners, such as “I don’t understand when my customer support representatives will be trained”

Global software development projects do not need to fail.   Simply reverse above ‘suggestions’ to increase your chances of success.