In some of my previous Knowledge Center articles, I’ve talked about testing as a means to build confidence in the quality of your data center’s applications. It’s good to have confidence before you turn an application loose on users, but why wait until the end of the project? The most efficient form of quality assurance is building software the right way, right from the start. What can IT managers and professionals do, starting from the first day of the project, to deliver quality applications?
The first step in building a quality application is to know what you need to build. An amazingly large number of projects get started without clarity among the project stakeholders about what the requirements are. As many as 45 percent of defects are introduced in specifications. One working definition for quality is “fitness for use.”
If we’re unclear on the intended uses, how can we build something that is fit for use? Not only do we need some specification of the requirements-whether formal or informal-but we should also conduct a thorough project stakeholder review of this specification to look for defects and to build consensus and understanding.
Another important early step is properly organizing the project. The overall approach to application development is the software development life cycle (SDLC) model. There are four main varieties of SDLC in common use today:
1. Sequential (also called Waterfall or V-Model)
In this approach, the team proceeds through a sequence of phases, starting with requirements, then design, then implementation, and then multiple levels of testing. This model works best when you can specify requirements that will change very little, if at all, over the course of the project. It also works best when you can plan the project with great accuracy, which typically means it’s similar to a project the team’s done before.
2. Iterative (also called Incremental or Evolutionary)
In this approach, the high-level requirements are grouped together into iterations (or increments)-often based on technical risk, business importance or both. The system is then designed, built and tested group by group. This model works well if you need to deliver the most important features by a rigid deadline but can accept some features arriving later. This model can tolerate some change in the plan (often due to uncertainty or change in requirements) and still deliver the key features on time, which is not true of the sequential models.
3. Agile (such as Scrum and XP)
In Agile approaches, each iteration is compressed to as short as two weeks. Documentation is minimized, change is expected from one iteration to the next and within each iteration. Various rules help prevent devolution into churn and chaos. This model works when applied with discipline, and its emphasis on accommodating change allows it to produce results even in rapidly evolving situations.
4. Code-and-fix
This approach is actually the absence of an approach. It involves starting the development of the application without any requirements, without a clear plan, without anything but a deadline in many cases. This model can only work for the simplest, shortest and least risky of development projects.
Now, the first three of these models exhibit significant variation in practice. You should feel free to intelligently tailor the model to your specific needs, but beware of violating certain aspects of the model that enable other features of the model.
How to Minimize Bugs
How to minimize bugs
With the project properly organized and the requirements clearly understood (whether for the whole project or only for this iteration), design and coding can start. Of course, coding presents not only the opportunity to create great new features, but also the risk that the programmer will create great big bugs. To mitigate this risk, there are three things every programmer should do with every piece of code written:
1. Unit testing
The programmer should test every line of code, every branch, every condition and every loop. Higher levels of testing, such as system test, often touch half or less of the code-and any untested code is a potential hiding place for bugs. New tools, both commercial and freeware, make the job of unit testing much easier than it was in the past.
2. Static analysis
Even code that passes unit tests can still contain latent defects, maintainability problems and security vulnerabilities. Static analysis can cheaply and quickly find bugs that would take hours to find and remove during higher levels of testing. The programmer now has a wide variety of tools available to help with this task as well.
3. Code review
Once a given unit of code is written, tested and analyzed, having a walk-through or technical review of the code among the programming team is a great way to catch most of the remaining bugs, as well as ensure good understanding of how the program works across the entire team. Studies show that as few as three experienced programmers, following a rigorous inspection process, can find as many as 90 percent of remaining bugs.
We can be very confident indeed in each unit of code, if programmers go through these three steps prior to checking their code into the source code repository.
Continuous Integration
Continuous integration
Even with high-quality units, there remains the risk of integration bugs. Integration bugs occur when two or more interoperating units don’t communicate, share data or transfer control properly.
To help mitigate integration risk, the project team can use continuous integration. This involves checking in code as it is finished, compiling and building that code together and running automated tests against the code to check for integration bugs. As with unit testing and static analysis, a variety of tools now exist to help with this process.
When we deliver quality applications-applications that are fit for use-we get to enjoy positive outcomes such as satisfied users and customers, improved reputation, more revenue or resources, and greater job satisfaction. In this article, we’ve seen that the pathway to delivering quality and enjoying those outcomes starts on the first day of the project and continues to the very end. Good requirements. Proper organization. Quality-focused programming. Continuous integration. And, once the application is ready, we can go through formal system, system integration and user acceptance testing.
If you’ve followed the steps outlined in this article, you’ll be amazed at how smoothly those tests go, and how quickly and confidently you can put a quality application into your data center.
Rex Black is President of RBCS. Rex is also the immediate past president of the International Software Testing Qualifications Board and the American Software Testing Qualifications Board. Rex has published six books, which have sold over 50,000 copies, including Japanese, Chinese, Indian, Hebrew and Russian editions. Rex has written over thirty articles, presented hundreds of papers, workshops and seminars, and given over fifty speeches at conferences and events around the world. Rex may be reached at [email protected]