The Crucial Role of Application Testing in Software Development

During the software development life cycle (SDLC), time and resources need to be committed to application testing. This is the testing that is done by the testing group, (i.e., the black box testers.) The allocation of time and resources is always a problem, as some organizations aren’t quite sure how much should be assigned.

Where does testing belong? Some say at the beginning, others say at the end. Some even say nowhere, as it doesn’t really add anything to the product’s reliability or success. After all, the developers have done the white box testing, so no additional testing needs to be done. Nothing could be further from the truth. Applications testing is one of the most misunderstood contributions to the success of the project and corporation.

Application testers are not always a part of the project team; they are not invited to the meetings to ensure everyone understands what the expectations and deliverables will be. Yet without this involvement, how can the test group effectively perform its job?

What They Said vs. What They Meant

I have been on the receiving end of a number of variations on the following conversation:

“I need you to test this product, but there is no hurry. It isn’t going out until Friday.”

“What is it supposed to do?”

“Don’t worry about it — just test it.”

“If I don’t know what it is supposed to do, how will I be able to ensure that it will do what it was intended to do?”

“If you need to know what it is supposed to do, ask the programmer.”

Does this exchange sound familiar? Over 90 percent of programmers have never been to a customer’s site or seen the program run in the customer’s environment. Yet they will design, develop and ship the product. Why? “We have always done it that way.” How about this one? “It works on my machine.” It may work on the developer’s machine — but if it doesn’t work on the deliverable machine, it is of little value.

Few programmers speak the customer’s language. Therefore, from the very beginning, there is often a lack of understanding and communication with the customer to ensure that everyone is on the right track. Without a complete understanding of what is required, each person could have a different take on what they think the client meant to say. There is an old saying: “I know you understood what I said. What you fail to realize is that what I said is not what I meant.” Sounds like double talk, doesn’t it? Yet programmers often fail to have a good understanding before starting a project. There is sometimes too much of a rush to do the “HOW” before really understanding the “WHAT.” Putting the cart before the horse?

Like the other groups, the testing group needs to be involved in the project throughout the entire SDLC. It sometimes may take longer to write a test case than it did for the programmer to write the code. When will the test group get the time to develop a test plan, write test scripts and test cases? Where will the test group get the information on the customer’s needs? This information does not just come out of thin air. Good tests require careful planning and a good understanding of the customer’s expectations. How can this be accomplished if testing is not involved from the very beginning?

In fact, some organizations are developing code from test cases as opposed to the other way around. If you have a better understanding of what is needed, you will have a better chance of achieving those objectives more easily. This will result in a savings of development costs — and in the long run, maintenance costs as well. Everyone wants to do better with less.

No Time Like the Present

Too often, the job responsibilities of quality assurance (QA) and quality control (QC) are confusing. Most organizations put the two responsibilities together and have a “QA/Tester” title. This is a bad thing to do, because they are two distinct and different jobs. So what are the responsibilities of quality assurance and quality control?

Quality Control. QC testers are there to demonstrate that the product will meet the user’s needs — not to demonstrate the program runs. A program can be “right,” meaning that it runs as designed, yet not be the “right program,” meaning it doesn’t meet the user’s needs.

Quality Assurance. QA is chartered to ensure that processes have been defined, documented, and will be repeated each time. One of the major jobs of the QA group is “lessons learned.” How can anyone get better if there’s no learning from previous successes or failures? When encountering a defect, what does a tester do? Log it, write a problem report and move on. Unless someone performs a “ROOT CAUSE ANALYSIS,” a project is doomed to keep suffering from the same mistakes.

A Root Cause Analysis identifies why a problem occurred in the first place and how it can be prevented in the future. When should this be done? As a project goes along. Waiting means repeating the error over and over again. “Lessons learned” should be an ongoing process and improve the quality of the product undergoing analysis, as well as future products. The sooner it’s known why a problem occurred, the cheaper it will be to repair and prevent in the future. What costs more — fix it now and prevent it from repeating? Or let it happen, and fix it and fix it and fix it? Taking advantage of lessons learned is an ongoing process. Continuous monitoring of what is good and bad is required during the entire life cycle of development and maintenance. Repeat good things, and prevent reoccurrences of bad things.

Ever heard the comment, “We don’t have the time or money to do it right now — we will fix it when it comes back”? What is the guarantee it will come back? If it does, it could cost a lot more to fix than it would have cost to prevent. Additionally, what about the company’s image? Do customers want a buggy product, or would they like to have it correct the first time? Also, what about the competition? Might they might try to capitalize on the fact you sent out a buggy product?

If testing is left for the end of the development cycle and problems are uncovered, it may be necessary to change some of the things that were previously tested. Once changes are made, retesting is necessary — “regression testing.” That often leads to the “fix one — break two” problem. As one error is corrected, additional errors result. The size of the fix has nothing to do with the regression testing process. You touch it — you must regression test. The success of testing is not based on the quantity of testing done, but on its quality.

The amount of time available for testing will be shorter, depending on where in the product cycle testing is involved. It will also affect the cost of the project, perhaps resulting in delivering less than originally planned.

Ounce of Prevention

Many of these problems can be prevented. Prevention is much cheaper than cure. However, to achieve success, it may be necessary to improve the way things are currently done. A better and clearer requirements process is the place to start. A quality product will result when software testers are more involved with other team members, when there is better communication, documented and enforced standards, and a clearer understanding of each person’s responsibilities and contributions.

A needs analysis — i.e., separating needs from wants — accompanied by structured walk-throughs prior to designing the code is essential to provide a quality product up front. Minimize scope creep. Design and develop more testable requirements prior to the design. Testers will ask the types of questions relative to the product’s use and customer’s expectations. This information is essential before — not after — the product design is complete.

Testing is an integral part of every software development project, and testers should be more involved and supported. When it comes to testing, earlier is better. Meeting customer needs is what testing is all about — not just putting out code. Testing is a major contributor to the overall success of the project, and that success can’t be achieved when most testers inherit whatever anyone else decides to give them. Expectations that are too high cannot be met.