The goal of the testing activity is to find as many errors as possible before the
user of the software finds them. We can use testing to determine whether a program
component meets its requirements. To accomplish its primary goal (finding errors)
or any of its secondary purposes (meeting requirements), software testing must be
applied in a systematic fashion. Testing involves operation of a system or application
under controlled conditions and evaluating the results.
Verification and Validation
Verification and Validation (V & V) is a Software Testing activity to enhance
quality of the software being built. It is planned and conducted systematically
through out the software lifecycle.
- Verification is the checking or testing of items, including software, for conformance
and consistency with an associated specification. Software testing is just one kind
of verification, which also uses techniques such as reviews, analysis, inspections
and walkthroughs.
- Validation is the process of checking that what has been specified is what the user
actually wanted. Validation activity may begin when most or all software functions
as per customer expectations. Validation testing provides final assurance that the
software meets all functional, behavioral and performance requirements. Usually
Black-box testing is used for this activity.
Verification: Are we building the Project right?
Validation: Are we building the right product?
Debugging vs Testing
The term bug is often used to refer to a problem or fault in a computer. There are
software bugs and hardware bugs.
Software testing should not be confused with debugging. Debugging is the process
of analyzing and locating bugs when software does not behave as expected. Although
the identification of some bugs will be obvious from playing with the software,
a methodical approach to software testing is a much more thorough means of identifying
bugs. Debugging is therefore an activity, which supports testing, but cannot replace
testing. However, no amount of testing can be guaranteed to discover all bugs.
Common Problems
- Poor requirements – if requirements are unclear, incomplete, too general, or not
testable, there will be problems
- Unrealistic schedule – if too much work is crammed in too little time, problems
are inevitable
- Inadequate testing – no one will know whether or not the program is any good until
the customer complains or systems crash
- Requirements change – requests to pile on new features after development is underway
are common
- Miscommunication – if developers don’t know what is needed or customers have erroneous
expectations, problems are guaranteed
- Poorly documented code – sufficient comments not built into the source code, requirement
changes not updated in the impacted documents
Solutions
- Solid requirements – clear, complete, detailed, cohesive, attainable, testable requirements
that are agreed to by all players use prototypes to help nail down requirements.
- Realistic schedules – allow adequate time for planning, design, testing, bug fixing,
re-testing, changes, and documentation; personnel should be able to complete the
project without burning out.
- Adequate testing - start testing early on, re-test after fixes or changes, plan
for adequate time for testing and bug-fixing.
- Stick to initial requirements as much as possible – be prepared to defend against
excessive changes and additions once development has begun, and be prepared to explain
consequences. If changes are necessary, they should be adequately reflected in related
schedule changes. If possible, use rapid prototype during the design phase so that
customer can see what to expect. This will provide them a higher comfort level with
their requirements decisions and minimize changes later on.
Communication
Require walkthroughs and inspections when appropriate; make extensive use of group
communication tools - e-mail, groupware, networked bug-tracking tools and change
management tools, intranet capabilities, etc.; ensure that information/documentation
is available and up-to-date - preferably electronic, not paper; promote teamwork
and cooperation; use prototypes early on so that customers' expectations are clarified.
