1. Software TestingMethodsA quick review on existingapproaches, their benefitsand pitfalls.
2. Basic Testing MethodsBasically, testing methods can be classified in thisfields: Dynamic or Static The Box Approach  White Box  Black Box  Gray Box Visual Testing
3. Testing Levels classificationsBased on which level of software you want to test, we canimplement the testing methods in these levels: Unittesting Integration testing System testing
5. Basic Testing MethodsDynamic or 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 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
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 softwares 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Unit testing 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)
19. 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.
20. Section 2 :Software Testing PracticesIn this section, we’ll take a look at how testing canbe implemented in popular project managementmethodologies:1. Waterfall development2. Extreme Programming3. Scrum4. 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 doesnt 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.
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 :Testing Methods, 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 and pitfalls Static Testing White Box Testing Black Box Testing Unit Testing Integration Testing System Testing
30. White Box TestingDynamic testing implements in white-box testingmethods. 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 and pitfalls 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 users 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 users 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 and pitfalls 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 and pitfalls 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 and pitfalls Static Testing White Box Testing Black Box Testing Unit Testing Integration TestingSystem Testing
46. System TestingSystem testing mainly is a sort of Black Boxtesting, to get more detailed informationsee black box testing benefits and pitfalls.
47. 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.