• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1667
  • Last Modified:

Why testing/QA department is important in a software company ?

I need to explain my CEO that the department of QA is very important and we should hire proper trained QA people in contrast to using the development resources for QA.

I need some solid link/paper to prove my statement
5 Solutions
Tommy BraasCommented:
It should be a trivial argument: Cost, cost and cost.

No QA = no sales = no profit = bankruptcy

Developers don't want to do QA, because that is not what they do. If developers are forced to do QA (apart from what is required as a natural part of development), they will find other jobs. It takes new hires 1-6 months to get up to speed depending on the complexity of the product. COST

Developers tend to do positive testing (path of least resistance), and won't find all bugs. That equals unstable software, which equals lower sales, which equals lower profits. COST

Developers are trained to do development, not QA. Use your resources for what they are intended. QA staff is cheaper than development staff. Developers need to continue development on the next version of a product while the previous version is in testing and build & release phases. By using the developers to do the testing, the developers will have lower productivity, each release will take longer. That equals lower sales, which equals lower profits. COST

Even though the statements above are not quoted from a paper or anything, it should provide you with enough ammunition (talking the CEO language) to defend your position.

As a parallell, would you use a medical doctor to do a janitors job? Use your resources to do the job they were intended for, not for something else "just because they can". I'm a developer and thouroughly dislike doing QA and I would quit my job if they wanted me to do more QA than what is natural during development.

Good luck!

You need to have proper QA people who think can think like users and will therefore use your system like users.  This may sound obvious, but its not something thast programmers are usually very good at.

Programmers are usually good at unit testing or component testing, but its not a good idea for programers to test their own code.  They know how it works and how it is written, and they'll usually test it around that.

Good QA people will be able to think what they need to do to test an application fully and will be able to produce complete test plans, test scenarios and the like.

If you have a good QA person performing QA throughout the project lifecycle, ie during development and not just when development has finished you'll save you money in the long term.
just ask the CEO if he would be willing to use a NEW parachute design, if that design had NEVER been tested?

Would he be willing to travel in a NEW airplane, if that Plane had never been tested?


This is a tough call for your CEO. Whether to go for a full fledged QA team or to use existing resources to carry out the task. Each possibilty has its pros and cons. One needs to do a complete intorpection to arrive at a decision. It could really harm the organization if the right decision is not made at the right time with right people. So rather than just choosing a solution that everybody seems to be using, you need to see the advantages and disadvantages of the choices available. I am providing you a start here to move in the right direction and ultimately it boils down to the finances available and other personal issues which are specific to your situation.

Full-fledged QA team VS Make shift arrangement
Product quality can make or break a company. Unfortunately, in software, most companies not only fail to deliver a quality product to their customers, but also fail to understand the attributes of a quality product. High-quality software requires more than a lack of bugs: it must effortlessly satisfy a user's needs with a minimum amount of training.

High-quality software meets both user and business requirements. User requirements include needed features, good performance and efficient workflow. Business requirements include on-time and under-budget delivery. Most financially successful products must balance these requirements. Delivering a product that has a poor workflow or inappropriate or buggy features virtually guarantees commercial failure. Likewise, delivering a high-quality user experience by breaking a corporate budget virtually guarantees that the company will not be able to recover the costs of development.

Companies with name recognition, market power or monopoly control can produce financially successful late products with buggy features and poor user experiences. Ironically, this is why new market entries rarely gain market share by producing products that mimic those of the leaders: leaders are not required to deliver high-quality products for success.

The staggering success of Apple's iPod, iTunes and online music sales strategies demonstrates how high-quality products that target real users' needs can not only take on market leaders but can soundly defeat them.

These products perfectly meet user and market demands without sacrificing user experience or quality by adding irrelevant features such as support for windows media formats (WMF), digital rights management (DRM) and non-Apple hardware. Apple's perfect storm of hardware, software and content for the right price not only ensured, but was required for, market success while all other vendors struggle. In addition, Apple has been able to execute a strategy of continual improvement of their product line providing a moving target for those who are trying to play catch-up.

Categories of Quality

Modern development techniques divide quality into two broad categories : external and internal quality. While external quality measures the value of the end user experience, internal quality measures how well the development of the product can meet time and cost constraints.

Software organizations often fail to identify which category of quality is deficient in a broken product. This failure makes it nearly impossible to correct the deficiencies. This section examines the two categories of quality and how they effect the final product.

External Quality
External quality measure the value of a product to a user. External quality has two aspects: perceived quality and workflow.

Most organizations understand perceived quality. Perceived quality measures the reliability, performance, and stability of a software product. Perceived quality is specific to a problem. For example, acceptable performance and reliability of a Web-based application to determine the interest rate for a consumer inquiring about a loan will probably not be acceptable for a customer service representative processing thousands of loans per day.

The second and more important aspect of external quality is how well a software product solves a workflow problem. In addition to performing its advertised feature set adequately, an application must make the users' job easier, faster and more reliable. This means that all applications must consider the target market and probable use to determine external quality. Many fast, reliable products are useless to customers because the perform functions that are not altogether useful.

The quality of an application for a particular workflow is not only a function of the delivered features but also how the UI exposes those features. UIs must clearly and immediately communicate the actions a user must perform next. It is extremely rare that "flexible" user interfaces designed to satisfy a largest number of customers and markets are of high quality. A brilliant discussion of user interface and workflow can be found in Mullet and Sato 1.

Most organizations confuse quality assurance (QA) with high-quality products. QA organizations only measure quality against product specifications. The burden falls on business and marketing organizations to determine proper feature selection. Too many features are just as deadly as too few features.

In the Apple media example, Apple was successful because its business analysts understood precisely how people want to use media: download easily, transfer between many personal computers, and play on portable devices. Users do not care about content format, record company negotiations or media business models. Apple satisfied its customers by eliminating user experience damaging features such as DRM and copy restrictions and including fast data transfer to iPods via firewire, creating easy to use hardware and software that always work and rarely crash. Apple's dedication to stable international standards such as MP3, MPEG-4, Firewire and USB made the development much easier.

On the other hand, Microsoft media has included difficult technologies such as DRM and its own proprietary music format, WMF. In addition, Microsoft does not usually adopt International standards. These decisions were not made for the benefit of its customers, but as concessions to the recording industry and a desire to own all content delivery on the Internet. These decisions created a highly volatile environment forcing frequent upgrades of software, OS, and hardware as newer, incompatible formats are released.

Internal Quality
Internal quality measures how easily a program can be changed without breaking existing features. Changes include bug fixes, new features and existing requirements. Internal quality is directly related to the quality of design and the appropriateness of the programming language given a program's size and domain.

Low internal quality makes it impossible for developers to predict the amount of effort required to add a new feature. In addition, changes will likely cause new, unexpected bugs. Low internal quality makes changes exponentially more expensive. As the cost for adding features increases, products get delayed and more buggy. These costs eventually overwhelm any value the product may provide.

External quality is essential for customer adoption of a product. Internal quality ensures that a company can maintain its market lead and continue to deliver excellent software. Apple made an initial splash with excellent software/hardware with the iPod, iBook and PowerBook series. They made a killing by continually evolving the software and hardware to add new services its customers desired without breaking existing features. Most good competent companies can make that initial release and splash. Only companies that maintain a high degree of internal quality can continue to keep its customers happy.

Interdependance of Quality

Poor internal quality leads to poor external quality as new features and bug fixes create new, unexpected errors. In contrast, high internal quality leads to easy bug fixes and extensions.

Low external quality means developers create designs and code around incorrect assumptions. No matter how careful they are, the result will be disastrous as all code built on these assumptions will be wrong.

High external quality means that the assumptions the code is built around are correct and well understood. Hence, the developers are more likely to create extensions that are correct.

The relationship is not necessarily clear. Poor internal quality can be replaced by extraordinary effort on the part of engineers to create a decent product. These efforts are, in general, not maintainable. This is why early versions of a product may be of high quality and on time, but subsequent versions get later and more buggy. In the push to get the product out the door, developers let internal quality suffer. As internal quality degrades, development takes longer.

Since low internal quality creates exponential cost of change, it is very expensive to correct. Most code bases with low internal quality must be completely rewritten.

Finally, low internal quality is not directly manifested in external quality. At first it is evident in small schedule slips or small bugs. By the time low internal quality effects the external quality, it is usually to late. Hence, organizations that wish to continually improve products must use processes that measure and immediately address internal quality such as Extreme Programming 2.

Conclusion Many organizations define product quality by how many bugs are found by a QA group. While good QA is essential to product quality, it is only one part of a marketing, business development and engineering effort.

Correcting quality problems is not simply fixing bugs. Product features must be carefully selected to address the needs of the target market.

Bugs and schedule slips may be symptoms of festering low internal quality. If these quality issues are not immediately addressed, the quality problems can eventually overwhelm any development efforts.

This discussion may go on for ever. I think thais is the most that can be comprehended at one go. if further help is needed you can contact me at kuldeep_bhayana@keaneindia.com.

All the very best,


Kuldeep Bhayana

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now