With the passage of time, ‘Software Development Industry’ has also become aware of the importance of ‘Quality Assurance’ in order to successfully comply with the concept of ‘Total Quality Management’ (TQM). People/Customers now have more confidence in such software/programs which have undergone critical tests and QA measurements. For this purpose in this article it has been tried to provide a better understanding about the importance of ‘Software Quality Assurance’ (SQA) to head towards ‘Total Quality Management’ (TQM).

In today’s technology driven world, software perform a key role in daily business and even in private life i.e. software are used in cars, trains, planes, banking systems, enterprises and so on. Therefore, software’s quality plays a crucial role and is important for the acceptance of software by end users and hence proves to be a key factor in success of software product. Developing software is an expensive process as it takes a lot of skilled people to develop it yet efficient companies spend excessive amounts to make it a “quality software” and also to fulfill the customers’ quality needs. On the other hand there are some companies as well which don’t take quality assurance measures seriously thinking of it as mere additional costs. But as a result the possible software failure causes millions of breakdown costs, loss of market share and reputation or can even cause injuries to people. Thus, it is important that SQA measures should be strongly considered to prevent a lot of financial losses as well as life threats and such measures will eventually result in the firm’s proper implementation of TQM principles. The International Organization for Standardization (ISO) has provided all the characteristics regarding SQA in its ‘ISO 9126’ standard which was first provided in 1991 and was revised and divided in 4 parts in 2001 as “ISO/IEC 9126-1 to ISO/IEC 9126-4”.

Implementing SQA measures can result in numerous benefits for the organization. Some of which are as follows:

• Although implementing SQA measures can be costly for the firm but it will eventually decrease the amount of time and money spent on software revisiting requirements, design code and the documentation procedures etc. which might occur in future.
• Quality Assured Software mostly no longer requires modifications and repairs which will save a lot of time and money.
• Software Quality Assurance decreases the time between ‘Development’ & ‘Deployment’
• SQA measures can help in catching errors and bugs etc. before they are too costly to fix.
• Customers have more confidence and interest in quality assured software. Therefore SQA can help the firms in increasing their customer base, market share and sales volume.

On the other hand, neglecting SQA can result in a number of adverse effects. The history is full of incidents where lack of quality assurance has caused the firms to suffer huge losses and sometimes even proved to be fatal to the people.

• In 1985, Canada’s “Therac-25” radiation therapy machine malfunctioned and delivered lethal radiation doses to patients. As a result 5 people died and a few were critically injured. The situation was caused by a bug called “race-condition” i.e. making the electron beam to fire in high-power mode without proper patient shielding
• A 2002 study commissioned by National Institute of Standards and Technology found software bugs cost the U.S. economy about $59.5 billion annually and also that about $22.2 billion could be eliminated by improving testing.

‘Software Quality Assurance’ is just as important as ‘Software Development’ and IT based organizations cannot hope to successfully implement the principles of ‘Total Quality Management’ without seriously considering the Software QA measures in that

(a) SQA saves a lot of repetitive work, modifications and repairs of software

(b) SQA helps in meeting the timelines

(c) Due to increased efficiency increases the profit per product

“Software bugs caused the bank accounts of 823 customers of a major U.S. bank to be credited with $924,844,208.32 each in May of 1996, according to newspaper reports. The American Bankers Association claimed it was the largest such error in banking history”

We know that software bugs can be annoying and costly but they can never be costlier than faulty software. Software errors cost a little over $60 Billion annually to US economy alone. Today, Delivering quality product to marketplace in a timely and efficient fashion does not promise remarkable success in software industry. It takes a lot more. Today’s software products are increasingly complex, often operating within multi-layer, multi-platform environments. Being created in rapid development environments, these softwares are pushed into the market at breakneck speed.

Fresh graduates often work as Testers at their first jobs even though their titles may reflect upon them as developers and might know nothing about testing. It is done because management fears bearing too much damage if the resource fails. In time, they are then promoted to being developers, their area of specialization.

Using testing as a transitional job for new programmers is not uncommon and is one classic hiring mistake. It does have a couple benefits; why else would someone do it otherwise. For instance, it really does keep bad programmers from causing trouble. A bad tester can be much less damaging than a bad programmer. Moreover, it might serve as a good orientation and introduction to the business and its products for the programmer.

S/he might learn some tricks as a tester that could help them later as a programmer.
All these benefits are outweighed by one huge disadvantage: the new hire HATES his job as a tester. That’s hardly conducive to good work. One could argue that the testers “have” to perform well to get their so called promotions. However, because people tend to be as motivated by effort as by results; they might not care much for their jobs.

Another classic mistake in organizing testing teams is to hire testers from amongst failed programmers. There could be several examples where bad programmers turn out to be brilliant testers. However, what happens when someone’s a bad programmer not because of the skill set but because of inappropriate work habits? For Instance, programmers who make lots of bugs because they are inattentive will also miss lots as a tester, for the very same reason.

So how should we then staff our software testing teams? What are the DOs for staffing QA experts?
1. When interviewing, we should concentrate less on formal qualifications than on intelligence and the Character of the candidate’s thought. Know that a good tester has these qualities
o Methodical and systematic.
o Tactful and diplomatic (but firm when necessary).
o Skeptical, especially about assumptions, and wants to see concrete evidence.
o Able to notice and pursue odd details.
o Good written and verbal skills (for explaining bugs clearly and concisely).
o A knack for anticipating what others are likely to misunderstand. (This is useful both in finding bugs and writing bug reports.)
o A willingness to get one’s hands dirty, to experiment, to try something to see what happens.
2. Try to dodge the trap of testers who are not domain experts. Domain experts know more about the area of study and will help find the most relevant and useful bugs.
3. Good technical writers develop a sense of what’s important, what’s confusing, and so on. Those areas that are hard to explain are often fruitful sources of bugs. Therefore; it is advisable to have some technical writers in the team. Like testers, technical writers often also lack detailed domain knowledge. However, they’re in the business of translating a product’s behavior into terms that make sense to a user.

If you keep in mind these guidelines while selection of your testing resources, you will successfully dodge a testing team that lacks, skills, quality and diversity. All of the members might lack some skills, but the team as a whole will have them all. Over time, in a team with mutual respect, the non-programmers will pick up essential tidbits of programming knowledge, the programmers will pick up domain knowledge, and the people with a writing background will teach the others how to deconstruct documents.

Security Damage can happen to anyone if a considerable attention is not given towards the information and infrastructure security. Do you know, Heartland was a credit card payment processor for more than 250,000 businesses in 2009, when the company revealed that tens of millions of transactions might have been compromised?

Do you know mobile banking and social networks have posed greatest threats in the payment space in 2011?

Ever heard of the dark cloud in the cloud computing space? Fraudsters hone their abilities to exploit vulnerabilities within the cloud space.

Check out the list of 6 massive security breaches (Published by Techweb) in the last few years. This is a brief reflection of the outcomes of ignoring security. If you still want to ignore, ignore it at your own peril.

1- In one of the instances of a physical security breach rather than an electronic one, the Bank of New York Mellon simply lost a tape. In February 2008, the company sent 10 unencrypted backup tapes to a storage facility. When the storage firm’s truck arrived at the facility, however, only nine tapes were still on board. The missing tape contained social security numbers and bank account information on 4.5 million customers. Oops.

2- The Maine-based grocery store chain Hannaford Brothers announced in March 2008 that hackers had gained access to more than 4.2 million credit card transactions. By the time word got out, more than 1,800 of the credit card numbers had already been used at company stores in the Northeast and Florida. Ironically, the chain had passed a PCI assessment not long before the breach was discovered. The breach resulted in two class action lawsuits on behalf of customers, whose outcome is still pending.

3- Increased reliance on data driven websites and the fact that 87% of the web is vulnerable to external threats, the need for secure and reliable service delivery through the web has never been higher. An organizations IT Infrastructure and web applications offer data access to customers, employees and other key stakeholders of a business. A minor security loophole within this infrastructure can cost up to thousands of dollars in the form of higher post deployment costs, legal fees, weak brand image and loss of loyal customers.

4- In 2009, the Department of Veterans Affairs was having trouble with one of the hard drives in a database RAID array. So, naturally, the agency sent the drive out for repair. Unfortunately, it neglected to erase the unencrypted data on the disc. When the contractor was unable to repair the disc, they simply recycled it — again without erasing — leaving the personal information for some 76 million veterans accessible to whoever next got the disc.

5- Certegy Check Services, a subsidiary of Fidelity National Information Service, revealed in 2007 that one of its employees had been stealing customer records and selling them to a data broker. The records included credit card, bank account, and other personal information, and Certegy estimated the breach affected 8.5 million customers. The thief got jail time and a multimillion-dollar fine, and Certegy wound up out nearly $1,000,000 in donations and court costs.

6- In May 2009, the Connecticut health care provider Health Net reported that an unencrypted portable storage device was missing, containing seven years’ worth of financial and medical information on 1.5 million customers. The capper? The device actually went missing six months before the company reported it. The Connecticut attorney general promptly filed suit. Health Net settled for $250,000 and is on the hook for another $500,000 if any of the data is accessed and misused before November 30, 2011.

The primary reason for testing the security of an operational system, thus, is to identify potential vulnerabilities and subsequently spare your organization of bearing such heavy losses. Typically, vulnerabilities are exploited repeatedly by attackers to attack weaknesses that organizations have not patched or corrected. In a situation like such, security and penetration testing becomes critical to all organizations interested in protecting their networks, yet far too little attention is paid to it making these organizations prone to the security breaches discussed above and their likes.

If involved right from the first phase of system development life cycle, security testing can help in eliminating the flaws into design and implementation of the system and in turn help the organization in blocking the potential security loopholes in earlier stages. This would not only include conformance of resistance of the systems your organization uses, but it will also ensure that people in your organization understand and obey security testing policies, hence adding up to the organization-wide security.

1. VENDOR’S PROFILE

The vendor profile provides information about the vendor’s reputation in the field, flexibility, capacity, financial health and its credibility etc. This factor helps a lot in determining whether and to what extent does a particular vendor pays heed to customer’s requirements of project scope, time, cost and quality.

CONSENSUS AD IDEM & EFFECTIVE COMMUNICATION SYSTEM

Does this vendor share your stream of thoughts and your ideology? Or does it share or even understand your mission and vision? Your firm and the vendors your select should have the identity of minds between them i.e. the vendors should be able to fully understand what is actually required from them by the firm and hence should be able to develop a quality product on time and within budget. Beside this there should be an effective communication system established between the two of you so that the vendor can quickly adhere to the firm’s requirements and also to any changes made in the project scope during development.

3. MODE OF PAYMENTS

Firms should also take into account the payment structure while selecting their vendors as it can significantly impact the firm’s cash flows.

4. MISCELLANEOUS FACTORS

Besides all of the above mentioned important factors, firms should also consider some other factors which can help them in selecting the best vendor which seriously considers the quality standards while developing an approved and quality assured product. Factors such as ‘cultural values’, ‘expert opinion & consulting services’, ‘Type of technologies used by the vendor’, ‘contract terms’ and ‘repairs and after sale services (if needed)’ should be considered before selecting the vendors.

1. QUALITY

Why do companies that apparently have nothing whatsoever to do with technology invest big amounts of money in IT projects? The bottom line is that they all want the overall efficiency and Quality of their end product or service to nourish and improve. Maintaining quality standards and providing quality service to facilitate customers and end users is the key to win their confidence in the firm’s goodwill. This would mean that while evaluating a vendor for your IT project, make Quality your priority. You can only hope to deliver good quality through this investment if your vendor delivers good quality to you.

As a simple example imagine that you own a retail store and wish to sell online, for most of your target audience buys online. The vendor you select can either make a website that is very user friendly and provides a wonderful interface with the most secure transaction systems; while it can also create a website prone to hacker attacks and flawed security. At the end of the day, it only takes a couple of Credit card frauds to cost you a life time of bad word of mouth and customers worth thousands of dollars in sale.

The point is that while selecting vendors prefer those that provide some assurance for their Quality; better yet, select the ones that have been certified by a renounced, well-reputed Quality assurance service provider

2. PRICE/COST

Price or cost of the project quoted by the vendors has always been considered as one of the most important aspect of vendor selection criteria. However, it is the “Value-for-money” that matters the most. Price alone can and should never act as the governing principle or you might end up preferring a cheap vendor selling a failed project over a costly vendor selling an excellent product. Value of money can thus act as a governing principle.

3. FINANCIAL HEALTH/STABILITY

The financial stability of the vendor is another important criterion to consider before making your choice. If the vendor itself isn’t financially sound, it can never become a reliable source for your organization because in order to provide quality product using excellent expertise one must also possess such resources.

4. PAST PERFORMANCE RECORDS

Firms must also carefully examine the performance history of the vendor. If the vendor seems to have shown good results, maintains a happy customer base and seems to have sustained its quality of performance over the years it is probably a good investment to do business with such a vendor. Even those vendors that are good but show inconsistency in their performance are risky business partners.

Come back later to read the Next 4 factors in selecting the right IT vendor for your organization.

Much of this risk can be avoided by selecting the “Right” vendor to do your job. Among other things, being able to select the proper vendor(s) for your business is probably one of the most nerve wracking and crucial activities which a firm must undertake. Selecting exactly the “right” Software Developer can equip your organization with a competitive advantage over your competitors which is why the matter of vendor identification, evaluation and Selection should be dealt with great care.

The vendor selection process deploys a tremendous amount of firm’s financial resources in return of which the firm expects significant benefits. Globalization and increased competition all over the world, calls for organizations to settle for nothing less than the best. The quality of service your vendor provides you directly affects the quality of service you provide to your customers. This is why, today; people have more confidence in the products/services of firms which employ the measures of quality management and assurance right from the stage of product development.

Come back to read on 8 important factors to consider while selecting the right vendor for your job.

Mobile applications, although have limited computing resources, are often built to be as agile and reliable as PC-based applications. In order to meet the challenge, mobile application testing has evolved as a separate stream of testing.

By missing the major user characterizations, mobile application lose the “gloss” within first couple of months and therefore, user retention period for mobile applications is very low, only around 10% users are found still using the same mobile application after six months of its download.



Many people have pointed fingers at many aspects and loop holes in mobile app testing, some of which are mentioned below.

1)       The major challenge in Mobile App Testing is the multiplicity of mobile devices with different capabilities, features and restrictions. Devices may have different technical capabilities such as amount of available memory, screen resolution, screen orientation and size of the display, network connectivity options, support for different standards and interfaces.

2)       Many mobile solutions involve a significant hardware element in addition to the PDA, such as scanners, mobile telephony, GPS and position based devices, telemetry, etc… These extra hardware elements place additional demands on the tester, particularly in terms of isolating a bug to hardware or software.

3)       Mobile applications are often intended to be used by people with no technical or IT background; such as meter readers, milkmen, insurance sales people; on devices that have small screens, and no or awkward keyboards. Good usability testing, carried out in conjunction with key users, in their own environment, is essential.

4)       There are multiple operating systems that are prevalent in the mobile space like Symbian, Android, iPhone OS, Windows, Linux, Blackberry OS, palm OS, Brew, etc. Each of the operating systems can have further versions for different types of devices which makes platform testing complex and further challenging

5)       Another challenge is that the developers need to focus on developing applications that are easy to use on a mobile and consume less power.

The Most important aspect that our analysis, development and testing teams often miss is that mobile application development takes a lot less time duration then mobile application testing, compared to the conventional model where application analysis & development takes more time precedence over testing. We therefore, deliberately tend to give less time for testing which might result in the application starting to lose out to competition over time. Due to this misunderstanding and thus improper testing strategy in mobile application; growing number of mobile applications are being taken off-app store every month, just in September 2011 alone following stats were witnessed

These trends show, that we can never use the same testing methodologies as we have been using on the conventional web and desktop applications, we have to devise a new strategy and methodology, which is going to take into account what actually is the mobile world, what it constitutes of and the adjustments it calls for in our conventional testing patterns and strategies.

Find these strategies, the solution to these challenges here

About the Author

Ahmad Bilal Khalid, is a Senior QA Engineer at Kualitatem with extensive experience in enterprise software testing and mobile application testing.

User experience in interactive and digital media is no different than a customer experience gained by actually visiting an outlet. Similarly, a dysfunctional and complicated web/mobile experience makes the potential customer to stop using a service just like a confusing physical outlet would let a customer walk out of it.

In the past few years, with massive explosion of web and mobile devices, companies have started shifting their marketing budgets from traditional media to digital media – creating a new paradigm to reach out to their audience. This has enabled brands to focus their various campaigns around specific geo & demographics while pushing the frontiers of marketing and brand recognition. This rapid growth has resulted in information being available at ‘one-click’. As this is a great way to engage your intended consumers, it also opens up another critical aspect of customer satisfaction: User Experience.

Click to Read Complete Article

Khurram Javed Mir, Co-Founder & CMO at Kualitatem, shares his experience about the three widely spread myths regarding QA and testing in the Digital Media Industry.

1) It’s the Boss’s Fault!

Some IT project failure might be deep rooted in management’s attitude and could be traced back to the Boss. It is not alien, rather highly likely, that it could be the Boss who could have led to a failure, not intentionally of course. But, because s/he is the most important person and decision maker in the entire management hierarchy; her/his decisions can strongly influence where the organization ends up being.
Boss plays the defining role of where and what the company is and where it aspires to be. Without clarifying the mission and vision of an organization, no worker can be confident about moving in the right direction.
Boss might also be at fault when s/he relies too much on their gut feeling rather logic. It’s true that gut feelings should no way be ignored, but over reliance on them can at times be damaging. Many times it is the unrealistic target and estimate of time, cost and scope set by the Boss that cause projects to fail. If they’re not planned according to the time they would actually take, they can never be successful.
Moreover, organizations that create a so-called wall between the Boss and the doers, who actually carry out the operations, are more prone to failing IT projects compared to those that have an open door policy. It is the open sharing of ideas, the concept of those ideas getting heard and the ease of communication between those who have the first-hand knowledge and those whose decisions matter which makes it less likely for organizations to make wrong decisions or doing things the wrong way and hence; are a lot less vulnerable to failures.

2) The Team’s no Gem either!

Many times it might not be the management, but the QA team that causes failures. QA team is the building block of a Quality Assurance Company and thus laid back teams can do more damage to an organization than anyone else can. The Cliché, “Never assume anything” is especially true for software projects. Good communication with the customer, users and especially the Development and QA team is important for project success. Does everyone in the team understand you? Do they know exactly what is expected of them or have you assumed they know? Do they communicate well with one another, with users, with clients and with other departments?

3) End Product ≠ Specifications

It so happens several times that despite a good leader and an efficient team; meeting deadlines and producing within budget; the project fails! It fails because it is not what your client asked you to make. The software might not be doing what it was supposed to; or times may be it would do things that it is not supposed to.
Non-Conformance with Industry Standards: Conforming to industry standards in your software projects can prove effective by ensuring accessibility, portability, usability, robustness and reducing problems now and in the future. Bodies such as the International Organization for Standardization (ISO) and World Wide Web Consortium (W3C) have developed open standards that, when used, are hard to challenge.

4) Ignored Problems:

These are issues that could easily be foreseen but caused failure simply because they were ignored.
Inadequate Testing: When the pressure to deliver is on, it is often the testing that suffers. All the testing is left until the end of the development cycle and only lip service paid to it. Often, the result is a product filled with bugs and an unhappy customer.

The bottom Line is that Project failures are inevitable, no matter what the underlying reasons might be. The most one could do is minimize the chances and frequency of their occurrences. You Might want to review these reasons once before you run your next software project. See if it makes a difference!