Software Testing Methods A quick review on existing approaches, their benefits and pitfalls.
Basic Testing Methods Basically, testing methods can be classified in this fields:  Dynamic or Static  The Box Approach  White Box  Black Box  Gray Box  Visual Testing
Testing Levels classifications Based on which level of software you want to test, we can implement the testing methods in these levels:  Unittesting  Integration testing  System testing
Testing Goals and Aims  Performance testing  Usability testing  Scalability testing  Software Stress testing  Recovery testing  Security testing  Conformance testing  Smoke testing  Compatibility testing  System testing  Alpha testing  Beta testing
Basic Testing Methods Dynamic or Static  The Box Approach  White Box  Black Box  Gray Box  Visual Testing
Static Testing  It is generally not detailed testing, but checks mainly for the sanity of the code, algorithm, or document.  primarily syntax checking of the code and/or manually reviewing the code or document to find errors.  Mainly implemented in black-box point of view  Bugs discovered at this stage are less expensive to fix them later.
Dynamic Testing  Dynamic Testing involves working with the software, giving input values and checking if the output is as expected.  Unit Tests, Integration Tests, System Tests and Acceptance Tests are few of the Dynamic Testing methodologies.  In the dynamic testing, testing begins before the software becomes completed.
Basic Testing Methods  Dynamic or Static The Box Approach  White Box  Black Box  Gray Box  Visual Testing
White box  testing the internal of the software, the methods and it’s components to specify it can meet the needs of the end user.  The following types of testing fall under the white box testing technique - Unit Testing, Integration Testing
Black-Box  examining the functionality without knowing any information about how it is made.  The tester is only aware of what the software is supposed to do, not how it does it.  The following types of testing fall under the Black box testing technique - System Testing, Acceptance Testing.
Gray Box Testing  Involves having knowledge of internal data structures and algorithms for purposes of designing tests  The tester is not required to have full access to the software's source code
Basic Testing Methods  Dynamic or Static  The Box Approach  White Box  Black Box  Gray Box  Visual Testing
Visual Testing  Recording of the entire test process – capturing everything that occurs on the test system in video format.  It is suitable to apply in agile projects, since agile methods require greater communication between testers and developers and collaboration within small teams.
Testing Levels classifications Unit testing  Integration testing  System testing
Unit testing A unit test is a procedure used to verify that a particular module of source code is working properly.  The test cases should be written for each peace of code, functions and methods  This type of testing is mostly done by the developers and not by end-users.
Testing Levels classifications  Unit testing Integration testing  System testing
Integration testing  Integration Testing involves with verifying the interfaces of system components in software design.  Tries to show the mistakes in interactions and interfaces between system modules.  To approaches is suggested for Integration Testing* :  Bottom-Up  Top-Down * Refer to the documents for further information(Integration Testing.pdf)
Testing Levels classifications  Unittesting  Integration testing System testing
System Testing  Mainly testing the system to meet its requirements.  Elaborating that how the third-party systems or any external system is interacting with the system.
Section 2 : Software Testing Practices In this section, we’ll take a look at how testing can be implemented in popular project management methodologies: 1. Waterfall development 2. Extreme Programming 3. Scrum 4. Agile
Waterfall Development  Positive Points  The software is ready, and every step of testing process will be completely mature and sensible.  The test reporting results are clear and enables the management to specify which decision should be taken.
Waterfall Development  Negative Points  It assumes that the system is completely ready, So It happens pretty late.  Fixing the errors found can be so expensive.  Running a script for one user without errors doesn't prove anything.  Running all scripts together make it very difficult to tune and troubleshoot  Running a single large test (or even a few of them) gives minimal information about the system behavior.
Section 2 : Software Testing Practices 1. Waterfall development 2. Extreme Programming 3. Scrum 4. Agile
Extreme Programming  Rather than designing whole of the system at the start of the project, the preliminary design work is reduced to solving the simple tasks that have already been identified.  The developers communicate directly with customers and other developers to understand the initial requirements.  During the XP, developers usually work in pairs to test the code.
Extreme Programming  Benefits  The best method when the customer doesn’t have a clear understanding of the details of the new system.  When the technology used to develop the system is new compared to other technologies.  When the team size is not very large (usually 2 to 12 people).
Extreme Programming  Pitfalls:  All code must have Unit tests.  All code must pass all Unit tests before it can be released.  When a Bug is found tests are created before the bug is addressed (a bug is not an error in logic, it is a test you forgot to write)
Section 3 : Testing Methods, Benefits and Pitfalls  Static Testing  White Box Testing  Black Box Testing  Unit Testing  Integration Testing  System Testing
Static Testing  Benefits  Capture defects early, so saves rework cost  Checklist-based approach  Focuses on coverage  Group perspective  Highest probability of finding defects  Pitfalls:  Time-consuming  Cannot test data dependencies  High skill levels on each field required
Testing methods: benefits and pitfalls  Static Testing  White Box Testing  Black Box Testing  Unit Testing  Integration Testing  System Testing
White Box Testing Dynamic testing implements in white-box testing methods.  Benefits  Forces test developer in implementation  Approximates the partitioning done by execution equivalence  Reveals errors in "hidden" code  As the knowledge of internal coding structure is prerequisite, it becomes very easy to find out which type of input/data can help in testing the application effectively.  It helps in optimizing the code.  It helps in removing the extra lines of code, which can bring in hidden defects.
White Box Testing  Pitfalls:  Expensive  Miss cases omitted in the code  A skilled tester is needed to carry out this type of testing, which increases the cost.  It is nearly impossible to look into every bit of code to find out hidden errors  Not looking at the code in a runtime environment. (The OS, environment and third-party situations can result in finding bugs that it cannot recognize )  Very few white-box tests can be done without modifying the program
Testing methods: benefits and pitfalls  StaticTesting  White Box Testing  Black Box Testing  UnitTesting  Integration Testing  System Testing
Black Box Testing  Benefits  Black box tests are reproducible.  The environment the program is running is also tested.  The invested effort can be used multiple times.  More effective on larger units of code than glass box testing  Tester needs no knowledge of implementation, including specific programming languages  Tests are done from a user's point of view  Will help to expose any ambiguities or inconsistencies in the specifications  Efficient when used on Larger systems
Black Box Testing  Benefits  Tester and developer are independent of each other, test is balanced and unprejudiced  Tester can be non-technical.  There is no need of having detailed functional knowledge of system to the tester.  Tests will be done from an end user's point of view. Because end user should accept the system. (Look for acceptance testing)  Testing helps to identify the vagueness and contradiction in functional specifications.  Test cases can be designed as soon as the functional specifications are complete
Black Box Testing  Pitfalls:  The results are often overestimated.  Not all properties of a software product can be tested  The reason for a failure is not found.  Only a small number of possible inputs can actually be tested, to test every possible input stream would take nearly forever  Without clear and concise specifications, test cases are hard to design  There may be unnecessary repetition of test inputs if the tester is not informed of test cases the programmer has already tried  May leave many program paths untested  Cannot be directed toward specific segments of code which may be very complex (and therefore more error prone)
Black Box Testing  Pitfalls:  Most testing related research has been directed toward glass box testing  Test cases are tough and challenging to design, without having clear functional specifications  It is difficult to identify tricky inputs, if the test cases are not developed based on specifications.  It is difficult to identify all possible inputs in limited testing time. So writing test cases is slow and difficult  Chances of having unidentified paths during this testing  Chances of having repetition of tests that are already done by programmer.
Testing methods: benefits and pitfalls  StaticTesting  White Box Testing  Black Box Testing  Unit Testing  Integration Testing  System Testing
Unit Testing  Benefits:  Unit testing provides a strict, written contract that the piece of code must satisfy.  allows the programmer to re-factor code at a later date, and make sure the module still works correctly  Unit testing helps eliminate uncertainty in the pieces themselves and can be used in a bottom-up testing style approach.  Unit testing provides a sort of "living document".
Unit Testing  Pitfalls:  Unit-testing will not catch every error in the program, will not catch integration errors  A unit test can only show the presence of errors; it cannot show the absence of errors.
Testing methods: benefits and pitfalls  Static Testing  White Box Testing  Black Box Testing  Unit Testing  Integration Testing  System Testing
Integration Testing  Bottom-Up Approach  Benefits  Helpfulif errors like deep down in the dependency structure.  Test conditions are easier to create.  Observation results are reasonable easy.  Reduced effort in creating stub modules.
Integration Testing  Bottom-Up Approach  Pitfalls:  Need to create stub modules.(It is easier than creating stub code)  The entire system is subjected to the small amount of test.(because the top modules are included in the tests at the final stage).
Integration Testing  Top-Down Approach  Benefits:  If major defects are more likely at the top level modules top-down is beneficial.  Getting I/O functions early can ease test writing.  Early demonstration of the main functionality can be helpful in highlighting requirements issue and the in boosting morale.
Integration Testing  Top-Down Approach  Pitfalls:  Too much effort on stubs.  Stub complexity can introduce errors.  Defining stubs can be difficult if some code is yet to be written.  It may be impossible accurately to reproduce test conditions.  Some observation maybe possible to make.  Encourages the idea that test and development can overlap.  Encourages deferring full testing of modules (until lower level modules can complete.)
Testing methods: benefits and pitfalls  Static Testing  White Box Testing  Black Box Testing  Unit Testing  Integration Testing System Testing
System Testing System testing mainly is a sort of Black Box testing, to get more detailed information see black box testing benefits and pitfalls.
My Opinion  Using the Black Box Approach with Integration testing method – Top-Down view.  Breaking the system down into sub systems at the first step of each process.  Specify one person to run the test parts.  Make a simple documentation for each part with expecting features point of view.

Software testing methods

  • 1.
    Software Testing Methods A quickreview on existing approaches, their benefits and pitfalls.
  • 2.
    Basic Testing Methods Basically,testing methods can be classified in this fields:  Dynamic or Static  The Box Approach  White Box  Black Box  Gray Box  Visual Testing
  • 3.
    Testing Levels classifications Basedon which level of software you want to test, we can implement the testing methods in these levels:  Unittesting  Integration testing  System testing
  • 4.
    Testing Goals andAims  Performance testing  Usability testing  Scalability testing  Software Stress testing  Recovery testing  Security testing  Conformance testing  Smoke testing  Compatibility testing  System testing  Alpha testing  Beta testing
  • 5.
    Basic Testing Methods Dynamicor Static  The Box Approach  White Box  Black Box  Gray Box  Visual Testing
  • 6.
    Static Testing  It is generally not detailed testing, but checks mainly for the sanity of the code, algorithm, or document.  primarily syntax checking of the code and/or manually reviewing the code or document to find errors.  Mainly implemented in black-box point of view  Bugs discovered at this stage are less expensive to fix them later.
  • 7.
    Dynamic Testing  Dynamic Testing involves working with the software, giving input values and checking if the output is as expected.  Unit Tests, Integration Tests, System Tests and Acceptance Tests are few of the Dynamic Testing methodologies.  In the dynamic testing, testing begins before the software becomes completed.
  • 8.
    Basic Testing Methods Dynamic or Static The Box Approach  White Box  Black Box  Gray Box  Visual Testing
  • 9.
    White box  testingthe internal of the software, the methods and it’s components to specify it can meet the needs of the end user.  The following types of testing fall under the white box testing technique - Unit Testing, Integration Testing
  • 10.
    Black-Box  examining the functionality without knowing any information about how it is made.  The tester is only aware of what the software is supposed to do, not how it does it.  The following types of testing fall under the Black box testing technique - System Testing, Acceptance Testing.
  • 11.
    Gray Box Testing Involves having knowledge of internal data structures and algorithms for purposes of designing tests  The tester is not required to have full access to the software's source code
  • 12.
    Basic Testing Methods Dynamic or Static  The Box Approach  White Box  Black Box  Gray Box  Visual Testing
  • 13.
    Visual Testing  Recording of the entire test process – capturing everything that occurs on the test system in video format.  It is suitable to apply in agile projects, since agile methods require greater communication between testers and developers and collaboration within small teams.
  • 14.
    Testing Levels classifications Unittesting  Integration testing  System testing
  • 15.
    Unit testing A unit test is a procedure used to verify that a particular module of source code is working properly.  The test cases should be written for each peace of code, functions and methods  This type of testing is mostly done by the developers and not by end-users.
  • 16.
    Testing Levels classifications Unit testing Integration testing  System testing
  • 17.
    Integration testing  Integration Testing involves with verifying the interfaces of system components in software design.  Tries to show the mistakes in interactions and interfaces between system modules.  To approaches is suggested for Integration Testing* :  Bottom-Up  Top-Down * Refer to the documents for further information(Integration Testing.pdf)
  • 18.
    Testing Levels classifications Unittesting  Integration testing System testing
  • 19.
    System Testing  Mainlytesting the system to meet its requirements.  Elaborating that how the third-party systems or any external system is interacting with the system.
  • 20.
    Section 2 : SoftwareTesting Practices In this section, we’ll take a look at how testing can be implemented in popular project management methodologies: 1. Waterfall development 2. Extreme Programming 3. Scrum 4. Agile
  • 21.
    Waterfall Development  Positive Points  The software is ready, and every step of testing process will be completely mature and sensible.  The test reporting results are clear and enables the management to specify which decision should be taken.
  • 22.
    Waterfall Development  Negative Points  It assumes that the system is completely ready, So It happens pretty late.  Fixing the errors found can be so expensive.  Running a script for one user without errors doesn't prove anything.  Running all scripts together make it very difficult to tune and troubleshoot  Running a single large test (or even a few of them) gives minimal information about the system behavior.
  • 23.
    Section 2 : SoftwareTesting Practices 1. Waterfall development 2. Extreme Programming 3. Scrum 4. Agile
  • 24.
    Extreme Programming  Rather than designing whole of the system at the start of the project, the preliminary design work is reduced to solving the simple tasks that have already been identified.  The developers communicate directly with customers and other developers to understand the initial requirements.  During the XP, developers usually work in pairs to test the code.
  • 25.
    Extreme Programming  Benefits  The best method when the customer doesn’t have a clear understanding of the details of the new system.  When the technology used to develop the system is new compared to other technologies.  When the team size is not very large (usually 2 to 12 people).
  • 26.
    Extreme Programming  Pitfalls:  All code must have Unit tests.  All code must pass all Unit tests before it can be released.  When a Bug is found tests are created before the bug is addressed (a bug is not an error in logic, it is a test you forgot to write)
  • 27.
    Section 3 : TestingMethods, Benefits and Pitfalls  Static Testing  White Box Testing  Black Box Testing  Unit Testing  Integration Testing  System Testing
  • 28.
    Static Testing  Benefits  Capture defects early, so saves rework cost  Checklist-based approach  Focuses on coverage  Group perspective  Highest probability of finding defects  Pitfalls:  Time-consuming  Cannot test data dependencies  High skill levels on each field required
  • 29.
    Testing methods: benefits andpitfalls  Static Testing  White Box Testing  Black Box Testing  Unit Testing  Integration Testing  System Testing
  • 30.
    White Box Testing Dynamictesting implements in white-box testing methods.  Benefits  Forces test developer in implementation  Approximates the partitioning done by execution equivalence  Reveals errors in "hidden" code  As the knowledge of internal coding structure is prerequisite, it becomes very easy to find out which type of input/data can help in testing the application effectively.  It helps in optimizing the code.  It helps in removing the extra lines of code, which can bring in hidden defects.
  • 31.
    White Box Testing  Pitfalls:  Expensive  Miss cases omitted in the code  A skilled tester is needed to carry out this type of testing, which increases the cost.  It is nearly impossible to look into every bit of code to find out hidden errors  Not looking at the code in a runtime environment. (The OS, environment and third-party situations can result in finding bugs that it cannot recognize )  Very few white-box tests can be done without modifying the program
  • 32.
    Testing methods: benefits andpitfalls  StaticTesting  White Box Testing  Black Box Testing  UnitTesting  Integration Testing  System Testing
  • 33.
    Black Box Testing  Benefits  Black box tests are reproducible.  The environment the program is running is also tested.  The invested effort can be used multiple times.  More effective on larger units of code than glass box testing  Tester needs no knowledge of implementation, including specific programming languages  Tests are done from a user's point of view  Will help to expose any ambiguities or inconsistencies in the specifications  Efficient when used on Larger systems
  • 34.
    Black Box Testing  Benefits  Tester and developer are independent of each other, test is balanced and unprejudiced  Tester can be non-technical.  There is no need of having detailed functional knowledge of system to the tester.  Tests will be done from an end user's point of view. Because end user should accept the system. (Look for acceptance testing)  Testing helps to identify the vagueness and contradiction in functional specifications.  Test cases can be designed as soon as the functional specifications are complete
  • 35.
    Black Box Testing  Pitfalls:  The results are often overestimated.  Not all properties of a software product can be tested  The reason for a failure is not found.  Only a small number of possible inputs can actually be tested, to test every possible input stream would take nearly forever  Without clear and concise specifications, test cases are hard to design  There may be unnecessary repetition of test inputs if the tester is not informed of test cases the programmer has already tried  May leave many program paths untested  Cannot be directed toward specific segments of code which may be very complex (and therefore more error prone)
  • 36.
    Black Box Testing  Pitfalls:  Most testing related research has been directed toward glass box testing  Test cases are tough and challenging to design, without having clear functional specifications  It is difficult to identify tricky inputs, if the test cases are not developed based on specifications.  It is difficult to identify all possible inputs in limited testing time. So writing test cases is slow and difficult  Chances of having unidentified paths during this testing  Chances of having repetition of tests that are already done by programmer.
  • 37.
    Testing methods: benefits andpitfalls  StaticTesting  White Box Testing  Black Box Testing  Unit Testing  Integration Testing  System Testing
  • 38.
    Unit Testing  Benefits:  Unit testing provides a strict, written contract that the piece of code must satisfy.  allows the programmer to re-factor code at a later date, and make sure the module still works correctly  Unit testing helps eliminate uncertainty in the pieces themselves and can be used in a bottom-up testing style approach.  Unit testing provides a sort of "living document".
  • 39.
    Unit Testing  Pitfalls:  Unit-testing will not catch every error in the program, will not catch integration errors  A unit test can only show the presence of errors; it cannot show the absence of errors.
  • 40.
    Testing methods: benefits andpitfalls  Static Testing  White Box Testing  Black Box Testing  Unit Testing  Integration Testing  System Testing
  • 41.
    Integration Testing  Bottom-Up Approach  Benefits  Helpfulif errors like deep down in the dependency structure.  Test conditions are easier to create.  Observation results are reasonable easy.  Reduced effort in creating stub modules.
  • 42.
    Integration Testing  Bottom-Up Approach  Pitfalls:  Need to create stub modules.(It is easier than creating stub code)  The entire system is subjected to the small amount of test.(because the top modules are included in the tests at the final stage).
  • 43.
    Integration Testing  Top-Down Approach  Benefits:  If major defects are more likely at the top level modules top-down is beneficial.  Getting I/O functions early can ease test writing.  Early demonstration of the main functionality can be helpful in highlighting requirements issue and the in boosting morale.
  • 44.
    Integration Testing  Top-Down Approach  Pitfalls:  Too much effort on stubs.  Stub complexity can introduce errors.  Defining stubs can be difficult if some code is yet to be written.  It may be impossible accurately to reproduce test conditions.  Some observation maybe possible to make.  Encourages the idea that test and development can overlap.  Encourages deferring full testing of modules (until lower level modules can complete.)
  • 45.
    Testing methods: benefits andpitfalls  Static Testing  White Box Testing  Black Box Testing  Unit Testing  Integration Testing System Testing
  • 46.
    System Testing System testingmainly is a sort of Black Box testing, to get more detailed information see black box testing benefits and pitfalls.
  • 47.
    My Opinion  Usingthe Black Box Approach with Integration testing method – Top-Down view.  Breaking the system down into sub systems at the first step of each process.  Specify one person to run the test parts.  Make a simple documentation for each part with expecting features point of view.