KINDS OF TESTING

[Spoorthi]

WHAT KINDS OF TESTING SHOULD BE CONSIDERED?

2. Black
   box testing: not based on any knowledge of internal design or code.
   Tests are based on requirements and functionality
3. White
   box testing: based on knowledge of the internal logic of an
   application’s code. Tests are based on coverage of code statements,
   branches, paths, and conditions.
4. Unit
   testing: the most ‘micro’ scale of testing; to test particular
   functions or code modules. Typically done by the programmer and not by
   testers, as it requires detailed knowledge of the internal program design
   and code. Not always easily done unless the application has a
   well-designed architecture with tight code; may require developing test
   driver modules or test harnesses.
5. Incremental
   integration testing: continuous testing of an application as new
   functionality is added; requires that various aspects of an applications
   functionality be independent enough to work separately before all parts of
   the program are completed, or that test drivers be developed as needed;
   done by programmers or by testers.
6. Integration
   testing: testing of combined parts of an application to determine if
   they function together correctly the ‘parts’ can be code modules,
   individual applications, client and server applications on a networked.
   This type of testing is especially relevant to client/server and
   distributed systems.
7. Functional
   testing: black-box type testing geared to functional requirements of
   an apllication; testers should do this type of testing. This does not mean
   that the programmers should not check their code works before releasing it
   (which of course applies to any stage of testing).
8. System
   testing: black –box type testing that is based on overall requirements
   specifications; covers all combined parts of system.
9. End
   to end testing: similar to system testing; the ‘macro’ end of the test
   scale; involves testing of a complete application environment in a
   situation that mimics real-world use, such as interacting with database,
   using network communications, or interacting with other hardware, applications,
   or systems if appropriate.
10. Sanity
    testing: typically an initial testing effort to determine if a new
    software version is performing well enough to accept it for a major
    testing effort. For example, if the new software is crashing systems every
    5minutes warrant further testing in item current state.
11. Regression
    testing: re-testing after fixes or modifications of the software or
    its environment. It can be difficult to determine how much re-testing is
    needed, especially near the end of the development cycle. Automated
    testing tools can be especially useful for this type of testing.
12. Acceptance
    testing: final testing based on specifications of the end-user or
    customer, or based on use by end users/customers over some limited period
    of time.
13. Load
    testing: testing an application under heavy loads, such as testing of
    a web site under a range of loads to determine at what point the system’s
    response time degrades or fails.
14. Stress
    testing: term often used interchangeably with ‘load’ and ‘performance’
    testing. Also used to describe such tests as system functional testing
    while under unusually heavy loads, heavy repletion of certain actions or
    inputs input of large numerical values, large complex queries to a
    database system, etc.
15. Performance
    testing: term often used interchagebly with ‘stress’ and ‘load’
    testing. Ideally ‘performance’ testing (and another ‘type’ of testing) is
    defined in requirements documentation or QA or test plans.
16. Usability
    testing: testing for ‘user-frindlyness’. Clearly this is subjective,
    and will depend on the targeted end-ser or customer. User interviews,
    surveys, video recording of user sessions, and other techniques can be
    used programmers and testers are usually not appropriate as usability
    testers.
17. Install/uninstall
    testing: testing of full, partial, or upgrade install/uninstall
    processes.
18. Recovery
    testing: testing how well a system recovers from crashes, hardware
    failures or other catastrophic problems.
19. Security
    testing: testing how well system protects against unauthorized
    internal or external access, damage, etc, any require sophisticated
    testing techniques.
20. Compatability
    testing: testing how well software performs in a particular
    hardware/software/operating/system/network/etc environment.
21. Exploratory
    testing: often taken to mean a creative, informal software test that
    is not based on formal test plans of test cases; testers may be learning
    the software as they test it.
22. Ad-hoc
    testing: similar to exploratory testing, but often taken to mean that
    the testers have significant understanding of the software testing it.
23. User
    acceptance testing: determinig if software is satisfactory to an
    end-user or customer.
24. Comparison
    testing: comparing software weakness and strengths to competing
    products.
25. Alpha
    testing: testing of an application when development is nearing
    completion; minor design changes may still be made as a result of such
    testing. Typically done by end-users or others, not by programmers or
    testers.
26. Beta
    testing: testing when devolvement and testing are essentially
    completed and final bugs and problems need to be found before final
    release. Typically done by end-users or others, not by programmers or
    testers.
27. Mutation
    testing: method for determining if a set of test data or test cases is
    useful, by deliberately introducing various code changes (‘bugs’) and
    retesting with the original test data/cases to determine if the ‘bugs’ are
    detected proper implementation requires large computational resources.

Edited by: spoorthi

[sk_kireeti]

This is excellent collection Spoorthi[img]smileys/smiley32.gif[/img]. Every one should have this knowledge. No matter either development or a testing resource.

Keep it up[img]smileys/smiley20.gif[/img]

Thanks,
Krishna

[Spoorthi]

thank u really i typed by cing material ......i thought nobody is gvng
responce but got responce frm u feeling happy abt my work....thanks[img]smileys/smiley1.gif[/img]

[sk_kireeti]

Hi Spoorthi,

Hardwork will never go waste!!! of course it may take some time for people to recognize it....

Keep it up.

Thanks,
Krishna

[BINNY]

Hi spoorthi,

Excellent JOB [img]smileys/smiley1.gif[/img]

[raghu]

Thanks , u r getting some great info in testing.


Keep going ! [img]smileys/smiley32.gif[/img]

Originally Posted by spoorthi

WHAT KINDS OF TESTING SHOULD BE CONSIDERED?

2. Black
   box testing: not based on any knowledge of internal design or code.
   Tests are based on requirements and functionality
3. White
   box testing: based on knowledge of the internal logic of an
   application’s code. Tests are based on coverage of code statements,
   branches, paths, and conditions.
4. Unit
   testing: the most ‘micro’ scale of testing; to test particular
   functions or code modules. Typically done by the programmer and not by
   testers, as it requires detailed knowledge of the internal program design
   and code. Not always easily done unless the application has a
   well-designed architecture with tight code; may require developing test
   driver modules or test harnesses.
5. Incremental
   integration testing: continuous testing of an application as new
   functionality is added; requires that various aspects of an applications
   functionality be independent enough to work separately before all parts of
   the program are completed, or that test drivers be developed as needed;
   done by programmers or by testers.
6. Integration
   testing: testing of combined parts of an application to determine if
   they function together correctly the ‘parts’ can be code modules,
   individual applications, client and server applications on a networked.
   This type of testing is especially relevant to client/server and
   distributed systems.
7. Functional
   testing: black-box type testing geared to functional requirements of
   an apllication; testers should do this type of testing. This does not mean
   that the programmers should not check their code works before releasing it
   (which of course applies to any stage of testing).
8. System
   testing: black –box type testing that is based on overall requirements
   specifications; covers all combined parts of system.
9. End
   to end testing: similar to system testing; the ‘macro’ end of the test
   scale; involves testing of a complete application environment in a
   situation that mimics real-world use, such as interacting with database,
   using network communications, or interacting with other hardware, applications,
   or systems if appropriate.
10. Sanity
    testing: typically an initial testing effort to determine if a new
    software version is performing well enough to accept it for a major
    testing effort. For example, if the new software is crashing systems every
    5minutes warrant further testing in item current state.
11. Regression
    testing: re-testing after fixes or modifications of the software or
    its environment. It can be difficult to determine how much re-testing is
    needed, especially near the end of the development cycle. Automated
    testing tools can be especially useful for this type of testing.
12. Acceptance
    testing: final testing based on specifications of the end-user or
    customer, or based on use by end users/customers over some limited period
    of time.
13. Load
    testing: testing an application under heavy loads, such as testing of
    a web site under a range of loads to determine at what point the system’s
    response time degrades or fails.
14. Stress
    testing: term often used interchangeably with ‘load’ and ‘performance’
    testing. Also used to describe such tests as system functional testing
    while under unusually heavy loads, heavy repletion of certain actions or
    inputs input of large numerical values, large complex queries to a
    database system, etc.
15. Performance
    testing: term often used interchagebly with ‘stress’ and ‘load’
    testing. Ideally ‘performance’ testing (and another ‘type’ of testing) is
    defined in requirements documentation or QA or test plans.
16. Usability
    testing: testing for ‘user-frindlyness’. Clearly this is subjective,
    and will depend on the targeted end-ser or customer. User interviews,
    surveys, video recording of user sessions, and other techniques can be
    used programmers and testers are usually not appropriate as usability
    testers.
17. Install/uninstall
    testing: testing of full, partial, or upgrade install/uninstall
    processes.
18. Recovery
    testing: testing how well a system recovers from crashes, hardware
    failures or other catastrophic problems.
19. Security
    testing: testing how well system protects against unauthorized
    internal or external access, damage, etc, any require sophisticated
    testing techniques.
20. Compatability
    testing: testing how well software performs in a particular
    hardware/software/operating/system/network/etc environment.
21. Exploratory
    testing: often taken to mean a creative, informal software test that
    is not based on formal test plans of test cases; testers may be learning
    the software as they test it.
22. Ad-hoc
    testing: similar to exploratory testing, but often taken to mean that
    the testers have significant understanding of the software testing it.
23. User
    acceptance testing: determinig if software is satisfactory to an
    end-user or customer.
24. Comparison
    testing: comparing software weakness and strengths to competing
    products.
25. Alpha
    testing: testing of an application when development is nearing
    completion; minor design changes may still be made as a result of such
    testing. Typically done by end-users or others, not by programmers or
    testers.
26. Beta
    testing: testing when devolvement and testing are essentially
    completed and final bugs and problems need to be found before final
    release. Typically done by end-users or others, not by programmers or
    testers.
27. Mutation
    testing: method for determining if a set of test data or test cases is
    useful, by deliberately introducing various code changes (‘bugs’) and
    retesting with the original test data/cases to determine if the ‘bugs’ are
    detected proper implementation requires large computational resources.

Edited by: spoorthi

[kiran2710]

Nice one, helpful 2 beginers........

[nandhini_7]

thanks spoorthi

[butair]

Spoorthi;
Thanks for the post. Learned some new ones.

Aren't #11 and #22 the same?

[praveenkumar216]

Its good collection and it will useful for all for refreshments.

2. Black
   box testing: not based on any knowledge of internal design or code.
   Tests are based on requirements and functionality
3. White
   box testing: based on knowledge of the internal logic of an
   application’s code. Tests are based on coverage of code statements,
   branches, paths, and conditions.
4. Unit
   testing: the most ‘micro’ scale of testing; to test particular
   functions or code modules. Typically done by the programmer and not by
   testers, as it requires detailed knowledge of the internal program design
   and code. Not always easily done unless the application has a
   well-designed architecture with tight code; may require developing test
   driver modules or test harnesses.
5. Incremental
   integration testing: continuous testing of an application as new
   functionality is added; requires that various aspects of an applications
   functionality be independent enough to work separately before all parts of
   the program are completed, or that test drivers be developed as needed;
   done by programmers or by testers.
6. Integration
   testing: testing of combined parts of an application to determine if
   they function together correctly the ‘parts’ can be code modules,
   individual applications, client and server applications on a networked.
   This type of testing is especially relevant to client/server and
   distributed systems.
7. Functional
   testing: black-box type testing geared to functional requirements of
   an apllication; testers should do this type of testing. This does not mean
   that the programmers should not check their code works before releasing it
   (which of course applies to any stage of testing).
8. System
   testing: black –box type testing that is based on overall requirements
   specifications; covers all combined parts of system.
9. End
   to end testing: similar to system testing; the ‘macro’ end of the test
   scale; involves testing of a complete application environment in a
   situation that mimics real-world use, such as interacting with database,
   using network communications, or interacting with other hardware, applications,
   or systems if appropriate.
10. Sanity
    testing: typically an initial testing effort to determine if a new
    software version is performing well enough to accept it for a major
    testing effort. For example, if the new software is crashing systems every
    5minutes warrant further testing in item current state.
11. Regression
    testing: re-testing after fixes or modifications of the software or
    its environment. It can be difficult to determine how much re-testing is
    needed, especially near the end of the development cycle. Automated
    testing tools can be especially useful for this type of testing.
12. Acceptance
    testing: final testing based on specifications of the end-user or
    customer, or based on use by end users/customers over some limited period
    of time.
13. Load
    testing: testing an application under heavy loads, such as testing of
    a web site under a range of loads to determine at what point the system’s
    response time degrades or fails.
14. Stress
    testing: term often used interchangeably with ‘load’ and ‘performance’
    testing. Also used to describe such tests as system functional testing
    while under unusually heavy loads, heavy repletion of certain actions or
    inputs input of large numerical values, large complex queries to a
    database system, etc.
15. Performance
    testing: term often used interchagebly with ‘stress’ and ‘load’
    testing. Ideally ‘performance’ testing (and another ‘type’ of testing) is
    defined in requirements documentation or QA or test plans.
16. Usability
    testing: testing for ‘user-frindlyness’. Clearly this is subjective,
    and will depend on the targeted end-ser or customer. User interviews,
    surveys, video recording of user sessions, and other techniques can be
    used programmers and testers are usually not appropriate as usability
    testers.
17. Install/uninstall
    testing: testing of full, partial, or upgrade install/uninstall
    processes.
18. Recovery
    testing: testing how well a system recovers from crashes, hardware
    failures or other catastrophic problems.
19. Security
    testing: testing how well system protects against unauthorized
    internal or external access, damage, etc, any require sophisticated
    testing techniques.
20. Compatability
    testing: testing how well software performs in a particular
    hardware/software/operating/system/network/etc environment.
21. Exploratory
    testing: often taken to mean a creative, informal software test that
    is not based on formal test plans of test cases; testers may be learning
    the software as they test it.
22. Ad-hoc
    testing: similar to exploratory testing, but often taken to mean that
    the testers have significant understanding of the software testing it.
23. User
    acceptance testing: determinig if software is satisfactory to an
    end-user or customer.
24. Comparison
    testing: comparing software weakness and strengths to competing
    products.
25. Alpha
    testing: testing of an application when development is nearing
    completion; minor design changes may still be made as a result of such
    testing. Typically done by end-users or others, not by programmers or
    testers.
26. Beta
    testing: testing when devolvement and testing are essentially
    completed and final bugs and problems need to be found before final
    release. Typically done by end-users or others, not by programmers or
    testers.
27. Mutation
    testing: method for determining if a set of test data or test cases is
    useful, by deliberately introducing various code changes (‘bugs’) and
    retesting with the original test data/cases to determine if the ‘bugs’ are
    detected proper implementation requires large computational resources.

Edited by: spoorthi [/quote]