When people think of software testing they are usually referring to the
execution of a program in order to detect the presence of defects. This type of
testing, that executes a piece of code which could be a program or a smaller
component, is more formally referred to as dynamic testing. Dynamic testing can
be performed either manually or automatically (via an automated testing tool)
but it is always characterized by the execution of code.
The compliment of dynamic software testing is static software testing. Static
testing refers to code walkthroughs, inspections and any review of software
that does not require the actual execution of the code itself. Some web
references identify this type of testing as 'inspections and walkthroughs',
thereby leaving the general term software testing to any activity that involves
Although, in essence, a question of semantics it is useful to divide all
testing activities into two broad categories as these activities (that is
dynamic and static) form a comprehensive quality control strategy for the entire
In order to allow for broad software quality control, within the typical
software development lifecycle (SDLC), all project work items need to be
subjected to static testing. This means that business requirements, technical
specifications and even test plans themselves are the subject of static testing
(i.e. inspections or walkthroughs).
Subjecting all major project work items to static testing implies that the
term 'software' (within the broader term static software testing) refers to all
project work items. Although this definition (for static testing) is broader
than the scope of the term software in dynamic software testing, this scope
implies that all quality control of a software project can be accomplished by
either static or dynamic testing.
Just as dynamic testing can be automated there are certain static tests that
can also be automated. One example of an automated static software testing tool
would be a tool that measures the complexity of the code within a given program.
To measure code complexity the program (being tested) does not need to be
executed but the measurement can be taken using a software tool. Also the
structure, paragraphs used of business requirements or specifications can
be verified using a parsing tool so that conformance to standards can be
verified (i.e. tested).
In general, the static testing of work items (such as business requirements)
implies a standard or format that can be used for reference. Many companies have
procedures that facilitate a process for verifying that a given work item
conforms to standards. This type of static testing (i.e. standards verification)
would be documented and scheduled within the project software quality control
Given the categorization of all software testing into either static or
dynamic groupings a comprehensive software quality control plan can be produced
at the beginning of the project and referenced to monitor and control the
software delivery throughout the complete SDLC (starting with the business
Author: Alex Goodyear
During a software development process, a simple loophole in code can create
huge losses not only for software users but even for development companies.
Well-known example is Y2K problem. That's the reason it becomes important to
improve testing and bring it at a level where the software will be reliable. In
making reliable software, software testing plays an important role. It helps in
reducing errors and bugs in the software. These days, there are many automated
software testing tools available that reduce testing job at higher levels and
make it effective to test a software in cost and time efficient way. It is a
responsibility of software tester to point out the error and bugs in a software
and deliver an error and bug free software to the customer.
Here are some tips to be followed for efficient software testing:
Need to make a good test plan: A good test plan covers all areas of
testing a product and considers initial planning, schedule testing, risk
identification, staff acquisition, and more.
Important to understand the product: It is important to understand the
complete project before you start testing. So, during meetings, it is a good
practice to involve tester's right from the software requirements gathering and
architecture design phase. As a result the testers can get knowledge of
application dependability resulting in detailed test coverage. If any tester is
not asked to be part of this development cycle then he/she can make a request to
involve them in all decision making processes. Besides, talk more with
developers to know more about the project.
Test early, test often: When it comes in find bugs in the project, start
early as possible because a bug found during design stage costs less to
eliminate than the one found during the coding stage.
Test positively: Start testing the application with a determination to
find bugs and errors. Don't think beforehand that there won't be any bugs in the
application. If an application is tested with an intention to find bugs, a
tester will definitely succeed to find even the subtle bugs.
Proper test cases improve testing: It is a good practice to write test
cases during requirement analysis and design phases. Test cases should be for
intended functionality i.e. for valid conditions and then for invalid conditions
to cover the expected as well as unexpected behaviour of product.
Test software in small functional modules: Divide software in small
functional modules and make test cases for it. This will ensure maximum test
Develop unambiguous and clear bug report: Report bugs in clear and
unambiguous way so that it is easily understandable. Also, don't only report
symptoms, but also effects of bugs and proper solutions for it.
Maintain test cases for regression testing: Previous maintained test cases
will help in effective regression testing of particular module as well as of
Note down new concepts: Always note down the new concepts that are learned
during testing. Those will surely help in effective testing of future projects.
Author: Robin K Payne