Manual Testing Notes
Q- Validation VS Verification
-> What is verification? Verification includes systematic procedures of review, analysis, and
testing, employed throughout the software development life cycle, beginning with the software
requirements phase and continuing through the coding phase. Verification can be achieved by
Feasibility Review Requirements Review Design Review Code Walkthrough Code
Inspection Requirement Tracing
-> What is Validation? Is the process of checking the end product to assure that it meets
requirements and expectations under operating conditions ‘Done by executing the system
functions through a series of Tests that can be observed and evaluated for compliance with
expected Results.
Q- Static Vs Dynamic Testing
Dynamic Testing involves working with the software, giving input values and checking the
output is expected Dynamic Testing takes place only after compilation Dynamic testing
techniques are time dependent and involve executing a specific sequence of instructions on
paper or by the computer. Examples include structured walkthroughs, in which the program
logic is simulated by walking through the code and verbally describing it. Boundary testing is a
dynamic testing technique that requires the execution of test cases on the computer with a
specific focus on the boundary values associated with the inputs or outputs of the program.
Functional Testing: Functional Testing refers to verifying if the module performs its intended
functions in accordance with the specification. The purpose is to ensure that the application’s
behaviour is as expected. E.g. data entry, navigation, processing, retrivel and display based on
requirements. Determines the extent to which a product meets expected functional
requirements through validation of product features. This process can be as simple as a smoke
test to ensure primary functional operation, or as detailed as checking a verify of scenarios and
validating that all output meets specified expectations
Regression Testing: Regression Testing is retesting the application after the bug fixes just to
make sure that the bug has been fixed and its impact on rest of application. The selective
retesting of the software system that has been modified to ensure that any defects have been
resolved and that no other previously working functions have failed as a result of the
reparations. Regression tests are also used to verify that newly added features have not created
problems with previous versions of the software. Regression test packages are made of subsets
of the various types of test and takes place multiple times over the life of a system that
represents a product. It occurs at all levels during the development life cycle to verify defect
resolution and check for new defects. production system may be involved in regression testing
when there is a significant chance that the system might be effected by the changes elsewhere,
such as to adjacent applications or infrastructure.
Smoke Testing: Smoke –Testing of application functionality made immediately after a build or
issuance. A smoke test is scripted, shallow and wide test, usually designed to touch every part
or the application in a cursory way without bothering with finer details. Pre and post build are
issuance test results may be compare to detect build or issuance problem. A smoke test is
similar to sanitary test but usually scripted and performed across a broader range rather than A
narrower and detailed sanity test. It is performed only when the build is ready every file is
compiled, linked and combined into program is then put through a “smoke test”, a relatively
simple check to see whether the product “smokes” when is runs.
Sanity Testing: Sanity –Testing conducted at the beginning of a level of test (or each iteration or
build) to determine if the quality of the product being delivered is performing well enough to
start execution of the detailed testing. An example of a sanity testing would be can you get end-
to –end through the application (doesn’t mean results are accurat)