Since its inception, the software development industry has been plagued by the issue of quality or the lack of it. A common perception among people is that the responsibility to ensure software quality rests solely with the software development teams or QA teams. Due to this perception, which in my opinion is flawed and unfair, the development teams have always been the target of never ending sarcasm and criticism, sometimes veiled and sometimes overt. While the software companies make fortunes selling the very applications these dev teams create, yet internally, dev teams become an abhorred lot. This obviously affects morale of the teams and has a spiralling downward effect on quality.
Now, it becomes imperative to analyse this situation and see if there is a light at the end of the tunnel of these quality issues. The first thing that comes to mind when we talk about software quality is – “Bug”. This is the most frightening word in life of a developer. So let’s talk about bug, a software bug.
Software bugs are called “bugs” for a reason: These pests have been around for a long time, they always turn up in code at the most inopportune times, and there’s no proven way to eradicate their existence. Today’s business climate is brutal for everyone, more so for dev teams. There is a dearth of time and resources (including but not limited to skilled and trained manpower) coupled with intense cost pressures. Due to this brutal climate, “the need for speed” has become mantra of the software development. The idea of “quality development” exists less in the form of driving force for development and more in the form of slogans and sales literatures. Summing it up, the pursuit of quality, and the forces driving software development have become intrinsically contradicting. There cannot be a better breeding environment for bugs than this.
While the business climate is likely to remain brutal, there is certainly a need for change in the collective approach towards software development. Quality cannot be sprinkled onto an application right before it gets exposed to the clients. Rather, it must be a part of the entire software development life cycle from inception through implementation. Hence, the responsibility for quality falls on the shoulders of everyone who is involved with the development process; it is not solely the responsibility of QA team or Dev team.
Here are some practical measures that in my opinion have potential to improve the quality of software.
Give our experts a call to discover how our innovative solutions could help your business.
1.Get the Requirements Right
Understanding business requirements correctly is the core of good software development. Any loss in translation or ambiguity in understanding the business requirements would result in unnecessary waste of time and money. It must be kept in mind that a team working on something which is not required is worse than the team sitting idle. An unnecessary change results in a rollback sooner or later, but the whole process of creation and rollback induces bugs in the system without adding any value.
Less rework means less retesting and fewer cycles which greatly reduce the overall effort.
Impact: Meet business requirements; achieve a satisfying user experience.
Responsibility: Managers, business analysts, user experience designers, architects.
2.Develop Detailed Solution Specifications
A System Requirement Specification should not leave anything to imagination and describe behaviour of the system in all possible usage scenarios that can be anticipated by common sense. Ambiguous or incomplete specifications are among the prime causes of defects in a system.
Detailed requirements result in better built applications that can be thoroughly tested.
Impact: Meet business requirements; achieve a satisfying user experience.
Responsibility: Business Analysts, user experience designers, architects.
3.Do not gold plate the requirements
Quality is a perception. If the user feels that the product is satisfying his requirements and is reliable, the product would be called a quality product. Creating a functionality to handle unnecessary complex hypothetical business scenarios is hardly of any value to the customer and is a potential source of leaking bugs.
When the requirement is reasonable, the ability to achieve quality is improved because the application development team is not charged with unrealistically perfect expectations. Rather, it is chartered with a definition of quality that fits the given time, resource, and budget constraints.
Impact: Meet business requirements and minimize potential of bugs
Responsibility: Business stakeholders; Business Analysts.
4.Adopt Simple Design
Simpler, cleaner designs result in code that is simpler, cleaner, and easier to test and rework—which means that the code will have fewer bugs and that those bugs will be easier to diagnose and repair.
Impact: Reduce defects.
Responsibility: Business Analysts, Managers.
5.Write Quality Code
The Dev teams need to move beyond the comforting mantra of “Software will always have bugs” and should always strive for improving the quality of their code. Code audits and reviews and test driven development is the way to go.
Impact: Reduce defects.
Responsibility: Development Team.
6.Test Smarter to Test Less
Irrespective of what those testing certification courses taught, the exceptions are what their name suggests – exceptions. Excessive testing of exceptional scenarios is a waste of time because it affects the testing of real life scenarios.
A focus on testing the most crucial and at risk areas ensures that they receive the lion’s share of test resources and that any bugs that slip through are likely to be confined to the least-important features.
Impact: Reduce defects.
Responsibility: Quality assurance
7.Optimize the Use of Testing Tools
Automation frees resources from mundane testing to focus on the highest-priority tests and increases test cycles’ repeatability. QA teams need to adopt automated testing as soon as possible.
Impact: Reduce defects.
Responsibility: Quality assurance
8.Establish Quality Metrics
There should be clearly defined metrics to measure the quality of work. For example, number of bugs reported in a newly developed feature. This will help in measuring the quality of work at any point of time. Highly visible metrics keep quality at the top of mind for the entire team and expose when efforts fall short.
Impact: Reduce defects.
Responsibility: Development Team.
9.Align Individual Goals with Quality
Quality metrics should be the part of an Individual team member’s goal and his incentives should be directly related to the quality of work produced. Team members perform according to their incentives; making quality improvement part of their goals reinforces desirable behaviour.
Impact: Meet business requirements; achieve a satisfying user experience; reduce defects.
Responsibility: Management.
Summing it up, Software quality is a team sport, and everyone needs to play.
Quality must move beyond the purview of just QA professionals to become an integrated part of the entire software development life cycle to reduce schedule-killing rework, improve user satisfaction, and reduce the risk of untested non-functional requirements such as security and performance. Quality must be made measurable and people making genuine efforts to improvise it must be encouraged and incentivised.