Posts Tagged ‘Software Quality’
Engineering application software is pretty complex after all!
Toyota recalled approximately 133,000 2010 Prius and 14,500 Lexus vehicles in the U.S. recently to update software in the vehicle’s antilock brake system (ABS) because of uneven braking. This recall was necessary for the issue would harm those in the car should it occur.
The weak link in a car’s software is not a virus or ill-behaved third party application, but the computer code and how it responds, or fails to respond, to unforeseen conditions. The computer running the software is designed to do just one thing, and is not a buggy device. This example illustrates how critical software is, for it not only results in lost profits and lost brand loyalty, but potentially lost lives.
Software Quality – A trade-off between time, budget and quality
Software is pretty complex and there is very limited understanding of its principles. Most defects in software are design errors, not production defects. Complications also arise from the dynamic nature of software programs. Often, testing has to be restarted after the preliminary defect is fixed and the associated costs can be prohibitively expensive.
Despite the challenges, testing is an integral part of ensuring a quality software development cycle.
Ensuring software quality is not about finding bugs and defects. These complications are directly related to the code that is written. Quality means complying with the business outcomes expected of the software. Factors that need to be assessed are:
- Functionality – correctness, reliability, usability and integrity
- Engineering – efficiency, testability and documentation
- Adaptability – flexibility, reusability and maintainability
Test Automation – Is it the holy grail of product quality?
- Test automation is expensive and takes ages to justify the investments.
- Automation resources are top-heavy and would mean a lot of upfront costs.
- Product roadmap is not clearly defined and we aren’t sure if automation is appropriate for us?
These are some of the initial reactions that we get to hear whenever we think of test automation. These reactions aren’t unfounded and it merits careful assessment.
Some questions to consider before deciding to automate are:
- Is your product fairly stable and do you have paying customers for its initial version?
- Does the product have a clearly defined roadmap?
- Does every version upgrade, both minor and major warrant running all the functional tests over and over again? Essentially, the test scripts would be re-used multiple times justifying the investments
Architecture driven software development ensures quality
The one most important thing that can influence the quality of the software is the architecture used. Software architecture plays a key role, and it is collection of design decisions – intended to ensure functionality and other quality attributes of the software like reliability, usability, scalability, efficiency, maintainability, and portability.
Software architecture represents earliest design decisions that are hardest to change, is a communication vehicle among stakeholders and are the most critical to get it right.
Architecting the software right ensures the business goals of high quality, quick time to market, effective use of limited resources, optimal leveraging of available skills, low cost production, low cost maintenance and mass customization, which results in improved efficiency and productivity.
Software Quality – what is it in reality?
The moment we mention software quality, the first thing that comes to our mind is bug-free software. Is bug-free software the only thing about software quality?Absolutely not!
We can define software quality thus, it is a part of each phase of the development life cycle including testing and encompasses a whole load of factors and not just bug-free and aesthetic software. These factors that are a combination of tangible and intangible sum of quality attributes like functionality, reliability, usability, efficiency, maintainability and scalability forms an important part of the software.
A bug free, aesthetically appealing product that fails to solve business problems of the target audience for which it was designed is a poor quality product. Essentially, software quality is about meeting user needs and it is about the quality attributes as much as it is about being aesthetic and bug-free.
How important is UAT
Whenever a software organization delivers a new project or customizes an enhancement feature for an existing product, it always strives for client satisfaction. While various testing approaches and methodologies are followed within organizations to increase the quality of output, the most important testing for client satisfaction is User Acceptance Testing. During this testing, actual business users will get to test the enhanced product. UAT (User Acceptance Testing) is the last major test before delivery. If UAT goes badly, it is fair to say that much of the good work prior to UAT is wasted.
What is UAT (User Acceptance Testing)?
The explanation of UAT is in its name. Taking each part separately explains what it is about.
How to Handle Intermittent Bugs
One of the greatest challenges that a tester comes across in his testing is dealing with intermittent bugs. These are mysterious, undesirable bugs that have been observed at least once, but cannot be easily re-created. Or in simple terms, they are also called as ‘non-reproducible’ bugs. Most of the testers would have come across situations quite often in their career where some bugs cannot be reproduced again. Usually, the common answers offered by testers for this kind of bugs are
- This bug is not producible always. We have captured the log.
- It doesn’t occur if we re-start the application
- It will take significant amount of time for the investigation
But then, non-reproducible bugs are errors of the testers even though they may not agree. Moreover this is true for Technical Support & Testing functions.
Removing software defects and errors – we’re closer to the Holy Grail!
Defect free or bug free software is in the wish list of many software vendors for ages and it hasn’t materialized and people are still looking for the Holy Grail. No piece of software can be bug free, however we can ensure that it works well in a controlled environment.
Defects are introduced in the software at all phases starting from requirements to analysis to design to development to verification to implementation to maintenance. In addition, 50% of the bugs are introduced when programmers try to fix a known bug. Essentially, any activity that is performed by a programmer or a member of the project team has potential for introducing a bug, which will in turn result in a defect and not allow the software from serving its intended purpose.
Software Development – The problem is of plenty, not scarcity
Software developers often are faced with a bewildering array of choices while developing software. Oftentimes frameworks, tools and technologies are mandated by client organizations to development teams. It is very possible that the team members are not exposed to at least one of the important technologies, tools or frameworks.
In the rush to shorten the learning curve and to get the development completed, very often basic development guidelines for successful development are ignored. Basic principles of object orientation and modularity of code are ignored and several transversal functions are unstated and are not met. This is discovered half way through the development and in order to accommodate various stated and unstated need, the development goals of code quality are almost never met.
How to Overcome the Challenges of a Testing Organization – Part II
I have earlier written in Part I about the challenges of a testing organization. We also touched upon shortly about the solution, which is a Testing Centre of Excellence (TCoE). In this post, let us see in detail what exactly a Testing Centre of Excellence is.
In a traditional model of testing, members of separate project teams do the verification and validation in the software development lifecycle. These teams need to be trained for each project and is not an efficient process. Additionally, they cannot ensure consistent quality across a business unit as they are focused on specific projects that have varying levels of budget allocation.
TCoE
Assume that there are 6 projects that are carried out in a business unit; each project will have phases like requirements, design, development, testing, deployment and support. In a TCoE, testing as a function is kept as a shared service across all the 6 projects that provide unbiased verification and validation.

