Search This Blog

Welcome to Machers Blog

Blogging the world of Technology and Testing which help people to build their career.

Tuesday, September 8, 2009

Subject: Off-Shore software test automation: A strategic approach t cost and speed effectiveness (Part-1)

Author: A White paper from Logi gear
The following white paper presents an executive overview of an innovative approach to integrating global resourcing and the latest test automation methodologies and tools.
This approach can effectively help any software development or organization meet their goals of time to market, cost containment, and quality.
To provide the paper background for this discussion, the paper also summarizes the software development process, the software testing process, global resourcing and the automation of software testing based on structured approach and methodology known as Action based testing (ABT).
Two industry trends, automating software testing and moving software testing offshore, hold out the promise of providing both cost and time savings. Bringing software to market faster,while reducing costs and helping the bottom line are goals that are very high on any software development organization’s wish list.
Unfortunately, many of these efforts yield results that fall far short of expectations. The trade and popular press are full of stories of failed offshore efforts. In addition, many test automation efforts not only fail to yield time or cost savings, but in fact result in quite the opposite! A coordinated management effort, with good understanding of the planning required, is necessary for success in both of these areas.
In fact, the strategic integration of the latest test automation methodologies and technologies with global resource strategies will not only improve upon both efforts, it will allow an organization to fully capitalize on the speed and cost saving potential of
Off shoring and automation.
The competing goals of delivering a quality software product, reducing costs and meeting time to market targets often lead management to take a tactical approach, focusing entirely on one goal or approach while neglecting to consider the impact of their decisions on other parts of the process. They may simply focus on one dimension such as automating testing to improve time to market, or off shoring testing to drive down costs.
Taking a tactical or one dimensional approach can very often lead to undesirable or unforeseen results. Management needs to consider the interplay between quality, cost, and time-to-market goals. They need to take a more strategic approach and develop an overall strategy and methodologies, and then select tools and partners.
An effective testing automation effort requires:
• A full understanding and appreciation of the software development process
• An understanding of software testing as a strategic effort that can provide cost benefits, speed benefits, as well as providing management with critically important visibility into the quality of their software under development
• An understanding that software testing is a discipline that is separate from development that should have its own budget and funding
• An understanding of the importance of a structured test automation approach that is based on a methodology known as Action-Based Testing (ABT), which creates a hierarchical test development model that can improve the quality and speed of testing while reducing the costs of testing
• An appreciation of the strategic importance of global resourcing strategies and best practices to further drive down costs and impact the bottom line
This white paper will:
• Provide an executive overview of the software development process, and the proper fit of the testing and automated testing processes, to help executive management to achieve a better understanding so that they will be able to make more informed and effective decisions on test automation and global resourcing.
• Discuss the strategic integration of the latest test automation methodologies and technologies such as a structured approach that is based on a methodology known as Action-Based Testing (ABT), with global resource strategies to fully capitalize on the speed, cost advantages, and best practices in automation and global sourcing.
Present the importance of selecting an experienced strategic partner such as Logi Gear, who can provide an integrated testing solution based on ABT and a global resource strategy that will effectively decrease testing time and cut costs while meeting quality goals
Executive Overview of the Software Development Process
At its most basic, there are three broad categories of efforts in any software product development life cycle. These are:
1. Specification or requirements definition
2. Development
3. Testing
This simple list, and the prevailing view of the process, implies a linear relationship between each of the components – the process moves from specification to development to testing as illustrated in Figure 1.
Typical View of Development Process
Specification   Development   Test

This is an overly simplistic view of the process of developing software that focuses on the tasks while ignoring the strategic interplay between the three parts of the process. It is, unfortunately, how the process may be implemented in many companies. There are several problems with this task-focused view of the process, including:
• It assumes that the specification delivered will not change
• It assumes the engineering will deliver software to testing on time and that there will not be any changes
• It involves testing far too late in the process
It is essential to understand that each step in the overall product development life cycle is in itself its own discipline and process. Further, each process is substantially enhanced if it is informed by, and continuously involved with, the other steps in the process. In reality, the steps in the development life cycle should both overlap each other and provide feedback to each other. For example:
• As product marketing/planning starts to develop a requirements document (hopefully with extensive customer and user input), engineering can start to investigate alternative ways of implementation, develop initial implementation estimates, identify critical paths, and start to work on translating requirements into a workable engineering plan.
• Engineering can also provide feedback to those developing the requirements on feasibility, risks, and time to implement certain features and functionality that may trigger alterations to the requirements specification.
• Testing involvement at these early stages provides visibility into what will need to be tested so that a test plan can start to be developed and test cases planned.
• Testing can design and automate test cases in advance so they are ready when development starts to deliver them code to be tested.
• Testing can also provide feedback, time estimates, risk assessments, and identify critical areas or provide feedback on the merits of different ways of implementing the requirements. They can even ask development to put hooks into the software that will make testing easier and faster.
• All will be able to more effectively deal with any changes or alterations and there will be fewer project slowing “surprises”.
Figure 2 illustrates the more parallel nature of the process with the invaluable feedback loops. The strategic integration of the three disciplines into a more streamlined and cooperative process helps to improve quality, improve delivery time, and reduce costs.
Specification 
------------------------ Development -------------------------------------------
------------------------------------------------------------------------------------------- Test--------------

How Quality Fits
Many incorrectly associate quality assurance with software testing. It is possible to do an excellent job of software testing and still deliver a poor quality product! Poor requirements definitions, or poor implementations, can lead to a product with unwanted or unusable features. Testing may verify that such a product is relatively reliable and works as intended, but nobody wants it or wants to use it. Such a “working” product will be seen to be of poor quality in the eyes of users and the marketplace. Delivering a product like this can have a very negative impact on an organization, driving up costs, and potentially impacting current or future revenue streams.
It is important to understand that quality entails efforts at every step in the development life cycle. It is also important to understand the costs of quality throughout the process, and that costs differ depending on where in the process they are incurred.
Quality cost, or the total cost to deliver a quality product, is simply the sum total of all quality related costs incurred at every phase of a project. There are four broad categories of quality costs:
1. Prevention costs – Prevention costs represent all costs spent to prevent software, documentation, and other product related errors. These costs include tasks such as staff training, requirements analysis, early prototyping, defensive programming, usability analysis, clarity of specification, and more. Prevention quality costs are the most cost-effective quality dollars that a company can spend. In essence, it costs much less to avoid errors up front than it does to identify them later, determine how to fix them, and develop new code to rectify them.

2. Appraisal costs – Appraisal costs represent all of the money that is spent on testing activities, which are any and all activities associated with searching for errors in software and associated materials. It includes the testing done by developers themselves, as well as the testing performed by the software testing organization. It is one of the largest costs associated with quality. However, it is far less expensive to find the errors early and fix the problems prior to software release.
3. Internal failure costs – Internal failure costs represent all of the costs associated with fixing bugs found prior to release. Again, whatever these costs, it is much less expensive and disruptive to fix problems internally prior to product release than it is after the product is released to customers.
4. External failure costs – External failure costs are all of those costs associated with defects and errors that are discovered after the product is released. These costs include all of the direct costs of identifying and fixing the problems, usually under high-pressure, as well as all of the sales and marketing costs associated with damage control. There are also intangible costs such as loss of goodwill, low customer satisfaction, and impact on future sales. External failure costs are very costly, and are typically much higher than internal failure costs. External failures can also negatively impact an organization’s reputation, putting at risk current and future revenue streams. External failures present the very real risk of negatively impacting an organization’s bottom line profitability.
The challenge to management is to do a cost-benefit analysis to achieve an optimum balance between prevention and appraisal costs to help to minimize failure costs, reduce overall costs, and positively impact the bottom line.

To be Continued in Part-2

No comments: