.

DIFFERENCE WHITE BOX TESTING SMOKE TESTING FUNCTONAL TESTING

WHAT Testing each and every line of the Testing the basic and critical features of an application before doing Testing the each and every component of an application
code. thorough and rigorous testing thoroughly and rigorously as per cx reqt.

WHEN 1. Reqt. Should be present. 1. As soon as T.E will get the build. 1. Requirement should be present.
2. Coding should be done. 2. When company gives build to customer chances e there dev. Missed to 2. Coding should be done.
copy few of the files, so customers will do smoke testing to check 3. WBT should be done.
whether files are copied properly or not. 4. S/W or build should be installed into server.
3. Release engg/Build Engg will do smoke testing to check whether 5. Resources (TE) should be available.
build/sw is installed properly into testing server and prod. Server. 6. Smoke testing should be done.
4. Developers will do smoke testing after WBT or before giving S/W to TEs. 7. Functional scenarios and test cases should be be ready.

WHY To ensure each and every line of the 1. s/w is testable or not. To ensure that every component of and application is working
code is working or not 2. TE will do smoke testing in first day of every test cycle so that developer properly or not
will get sufficient time to fix the defect.
3. Release enginer will do to check sw is properly installed in the server or
not.
4. Getting a new build means dev will change some code and as a te we
should do smoke testing.
5. It is build verification.
6. It is health checkup.
7. It is done by TE to get confidence.
TYPE Path testing Formal testing Over testing/ Exhausted testing.
Loop testing Informal testing Under testing
Conditional testing Optimized testing
Unit testing
Testing from memory point of view
Testing from performance point of
view
ALTERNATE Open box Sanity Component testing
NAME Glass box Skim
Transparent Dry run
Clear box Build verification
Mutation Health check up
Structural Confidence
unit Positive

DIFFERENCE SYSTEM TESTING INTEGRATION TESTING ACCPETANCE TESTING

WHAT It is an end-to-end testing done by T.E. where in test server Testing the data flow between two or more modules It is an end-to-end testing done by T.E./customer/end user
similar to production server where they use the application in real time business data
for a particular period of time and ensure that s/w can
able to handle all real time business scenarios and
situation.
WHEN 1. Requirement should be present. 1. Requirement should be present. 1. Requirement should be present.
2. Coding should be done. 2. Coding should be done. 2. Coding should be done.
3. WBT should be done. 3. WBT should be done. 3. WBT should be done.
4. S/W or build should be installed into server. 4. S/W or build should be installed into server. 4. S/W or build should be installed into server.
5. Resources (TE) should be available 5. Resources (TE) should be available 5. Resources (TE) should be available
6. Smoke testing should be done. 6. Smoke testing should be done. 6. Smoke testing should be done.
7. Functional testing should be done. 7. Functional testing should be done. 7. Functional testing should be done.
8. IT should be done. 8. Integration scenarios & test cases should be ready. 8. IT should be done.
9. When min bunch of modules are ready. 9. System tesing should be done.
[Link] functionalities of all modules should be working [Link] testing should be done.
fine. [Link] testing should be done.
[Link] /SW should be relatively stable 12.S/W should be released to the customer.
[Link] server similar to prod. server should be
available.
[Link] we start getting less no. of requirements.
[Link] scenarios & test cases should be ready.
WHY To navigate through all the modules and test that the end or To check data flow between two modules is working To ensure that s/w meets business reqt.
last module is working properly properly or not
To get confidence on s/w.
Chances are there developers may have developed wrong
features.
Chances are there T.E may miss some defects.

TYPE End to end testing Incremental testing User acceptance

Acceptance testing Non-Incremental testing Operational acceptance
Smoke testing Contract acceptance
Adhok testing Compliance acceptance
Usability testing Beta testing
Performance testing
Compatibility testing
Regression testing
ALTERNATE End to end testing Data flow testing User acceptable testing
NAME Interface testing Final acceptable testing
Red box testing

DIFFERENCE USABILITY TESTING PERFORMANCE TESTING ADHOC TESTING

WHAT Testing the user friendliness of an application Testing the stability and response time by applying load Testing the s/w randomly with looking into the reqt is called as adhoc
testing

WHEN 1. Req should be present. 1. Req should be present. 1. As soon as we get the build we will do smoke testing and not
2. Coding should be done. 2. Coding should be done. do adhoc testing.
3. WBT should be done. 3. WBT should be done. 2. While doing ft,it,st if te comes up with some new creative
4. S/w or build should be installed into server. 4. S/w or build should be installed into server. adhoc scenarios and if he is having time then he should do
5. Resources (TE) should be available. 5. Resources (TE) should be available. adhoc testing but not waste much time doing adhoc testing
6. Smoke testing should be done. 6. Smoke testing should be done. and should get back to ft,it,st etc.
7. FT should be done. 7. FT should be done. 3. While doing ft,it,st if te comes up with some new creative
8. IT should be done. 8. IT should be done. adhoc scenarios and if he is not having time then he should do
9. ST should be done. 9. ST should be done. documentation and send it to the TL and start doing FT,IT,St
 [Link] testing should be done. [Link] testing should be done. etc.
[Link] scenerios and test cases should be 4. When the testings are completely done according to CX reqt
ready. then will do adhoc testing.
5. When min 10-15 stable builds are ready.

WHY 1. Test the look and feel of the s/w. 1. Chances are there customers use the s/w randomly and they
2. might find defects to avoid this we will do adhoc.
2. This is negative testing so we will do adhoc testing
3. DE will develop the sw acc to cx reqt and TE will test the sw acc
to cx reqt so there will be less defect tracked.
4. To find more defect we will do adhoc testing.
5. The intention of doing adhoc testing is to somehow break the
product, that’s why adhoc testing should be done

TYPE GUI testing Load testing No types

Yellow box testing Volume testing
Accessibility testing Stress testing
Scalability testing
Soak/endurance testing
ALTERNATE Cosmetic testing Spike testing Negative testing
NAME Benchmark Monkey testing
Breakpoint Gorilla Testing
Baseline Out of box Testing
Bottleneck
Threshold

DIFFERENCE GLOBALIZATION TESTING EXPLORATORY TESTING COMPATABILITY TESTING

WHAT Developing the s/w for different lang. is called as Understanding the application, identifying all the possible Testing the functionality of the application in different hardwar,
globalization. scenarios, documenting it and test the application refering the software, platform, environment.
 Testing the s/w developed for different or document. OR
multiple languages.
Explore the application, understand how each and every feature
works and test application acc, to the understanding.
WHEN 1. Reqt should be present. 1. No reqt. Once we test the s/w for base platform then we do compatibility
2. Coding should be done. 2. When there is reqt. but TE is not having time to understand testing for other platform.
3. Resource should be available. the reqt.
4. s/w installed in server. 3. When there is reqt but very hard to understand it means
5. Wbt should be done. reqt is complex.
6. Ft should be done.
7. It done
8. St done
9. Check whether s/w id developed in
different lang or not.
WHY 1. To check whether right language is When requirement is not there then T.E. do exploratory testing to If we don’t do compatibility testing and release s/w cx might use
displayed. understand the reqt. and to detect the blocker or critical defect. the s/w for diff. platform and might face problem.
2. To check right content is displayed in right
To check that the application is working properly in all the
place.
platform
3. To ensure s/w is developed as per country
standards and country culture.

TYPE Internationalization testing (I18N)

Localization testing (L10N)

ALTERNATE Portability testing

NAME Configuration testing