It's a quick

1. Software Testing
Methods
A quick review 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
Based on 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 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

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 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
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)

18. Testing Levels classifications
 Unittesting
 Integration testing
System testing

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 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 :
Software Testing 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 :
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 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.

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 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 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 Testing
System testing mainly is a sort of Black Box
testing, to get more detailed information
see 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.