The document provides an overview of software testing, including why it is important, common terminology, and different testing techniques. It discusses black box testing, which focuses on testing functional requirements without knowledge of internal structure. White box testing uses knowledge of internal structure to detect errors. Gray box testing combines aspects of both black box and white box testing. The document also covers test design targets and techniques like equivalence partitioning and boundary value analysis for black box testing, and code coverage analysis, data flow testing and error handling for white box testing.

1. Software Testing – Day One _____________________________________ By Govardhan Reddy M

3. Purpose?

6. White Box

7. Gray Box

9. Process of demonstrating that errors are not present.

10. Process of establishing confidence that a program does what it is supposed to do.

14. Validation

15. Error Finding

19. Typically involves actual testing.

23. PRD: Product Requirement Document.

24. FDD: Funtional/Feature Design Document.

26. Flaws that exists due to improper coding.

27. Undesirable output which negates the requirement.

28. Occurs in the syntax level (syntax error).

30. Application

31. Resource associated with testbed setup.

34. QA

37. High level system wide expression of major activities that collectively achieve the overall desired result.

38. Identifies Risks, Constraints and Exposures present.

39. Introduces significant added value to the plan.

41. Resources (People and Machines).

42. Types and Levels of Testing.

46. FDD: Functional Design Document (LLD)

47. SRS: HLD and/or LLD

49. Trigger event that starts the test.

50. One or more data values which are generated as a result of the input(s) being processed (output).

51. Tools and data required to allow the test to execute (the environment).

53. Most test cases are in the form of a table.

56. Manual Scripts = Test Cases

60. Test coverage

61. How to develop and document test cases

62. How to build and maintain test data

64. Focus on testing functional requirements.

65. Tester would only know legal inputs and what expected outputs will be, But not know what program actually arrives to those outputs.

66. Testing against the specification and no other knowledge is required.

68. Funtional

69. Opaque (not clearly understand)

70. Closed Box Note: Behavioral is not Black Box, As usage of internal knowledge is not strictly forbidden.

74. Tests for data flow coverage as needed.

78. Finite State Modeling: Particular state?

79. Data Flow Modeling: Object Object.

80. Timing Modeling: Execution times?

82. eg. 1 - 20 1 - 9 10 - 20 Note: 1. Test for digit 1, If passed, Then no need to test for digits 2 – 9 2. Test for digit 10, If passed, Then no need to test for digits 11 - 20

85. In Boundary: min + 1, max - 1

86. Out Boundary: min – 1, max + 1 1 - 20 1,20 2,19 0,21

89. No internal is knowledge is required.

90. Tester and programmer are independent.

91. Tests are done from users point of view.

92. Test cases will be designed as soon as specifications are ready.

93. Will help to expose unclearness in the specification.

95. Tests are hard to design without clear and concise specifications.

96. May leave many program paths untested.

97. May be unnecessary repetition of test cases – if the tester was not informed of the test cases for which the programmer has already tried.

98. Most testing research has been detected towards glass box testing.

100. Used to detect errors by means of execution-oriented test case.

102. Method Analysis

103. And to develop and review the same.

105. Glass Box

106. Clear Box

107. Open Box

109. Cyclomatic Complexity: Gives quantitative measure of logical complexity.

111. Simple Condition

112. Compound Condition

115. Concatenated

116. Nested

117. Unstructured Flow

121. Leads to improve CPU time performance.

123. Exception and error handling are checked thoroughly by operating an error causing test vectors.

126. Approximate the partition done by equivalence.

127. Reveals errors in hidden code.

130. Case omitted (leave undone) in the code could be missed out.

131. It is nearly impossible to look into every bit of code to find out hidden errors, Which may create problem, resulting in failure of the application.

135. Think out of the black box.

136. Hate the product while testing and love the product after its release

137. - Emotional Testing.

138. Questions?

139. Thank You!