Unit 5 - updnioiiihiioihgguy76ygfated.pptx

jhihhuih

1. Unit 5 TESTING METHODS AND CONCEPTS

2. Role of an Software Engineer :

3. TYPES OF SOFTWARE TESTING:

4. TYPES OF SOFTWARE: ????

5. 1.Programming Software Eg.Compiler , Debuggers 2.Application Software. Eg.Mobile Apps, Desktop apps 3.System Software Eg. Device Drivers, Operating Systems

6. SOFTWARE TESTING : Software testing is the process of evaluating a software application or system to identify any bugs, errors, or missing requirements , and to ensure it behaves as expected. Types of Testing : Manual Testing Performed by humans. Testers follow test cases without automation tools. Good for exploratory, usability, and ad hoc testing. Automated Testing Uses scripts and tools (e.g., Selenium, JUnit). Efficient for repetitive tasks and regression tests.

7. Now, What is mean by Quality??? 1.Bug-Free 2.On-Time Delivery. 3.Budget Friendly. 4.Fullfilling requirements. 5.Easy to maintain.

8. Time consuming Testing activities :

9. So, What is manual Testing?

10. Phases of STLC :

11. STLC : Software Testing Life Cycle

12. Verification and Validaiton

13. Writing Test cases :

14. Black Box Testing :

15. White Box Testing :

16. BT :

17. WT :

18. Functional Testing :

19. Non-Functional Testing :

20. Exploratory Testing :

21. When to use ET:

22. Bug’s Life cycle :

23. What is your idea?

24. Point 1 :

25. Point 2 :

26. Point 3 :

27. Point 4:

28. Point 5:

29. How it will be handled by Developer?

30. JIRA – The rescuer for developers….

31. Regression Testing :

32. Smoke Testing :

33. Example :

34. CI tools 1. BitBucket Pipelines

35. 2 . Jenkins

36. 3. AWS CodePipeline

37. 4. CircleCI

38. 5. Azure Pipelines

39. Test cases :

40. How Test scenarios differ from Test cases?

41. Exploratory Testing : In Banking Application….

42. Exploratory Testing :

43. How to prioritizes test cases :

44. Any idea ??????????

45. Functional vs Non Functional Testing :

46. Example :

47. Let’s start with writing test cases………..

48. Creating manual test cases for WhatsApp involves testing its core features like messaging, calling, media sharing, status updates, and account settings. Below is a list of manual test cases categorized by functionality. Test Case ID Description Steps Expected Result TC001 Verify phone number registration 1. Open WhatsApp 2. Enter valid phone number 3. Verify OTP User is registered and navigated to home screen TC002 Verify OTP validation with wrong OTP 1. Enter incorrect OTP Error message is displayed TC003 Verify login with existing account 1. Reinstall WhatsApp 2. Enter registered number 3. Verify OTP Old chats and account info restored 1. Login & Registration

49. 2.Messaging Test Case ID Description Steps Expected Result TC004 Send a text message 1. Open chat 2. Type and send message Message appears in chat window TC005 Send an emoji 1. Open emoji panel 2. Select emoji 3. Send Emoji is sent TC006 Receive a message 1. Use another device to send message Message is received in real-time TC007 Message read receipt 1. Send message 2. Ask recipient to read Double blue ticks appear 2. Messaging

50. 3. Media Sharing Test Case ID Description Steps Expected Result TC008 Send an image from gallery 1. Open chat 2. Tap on attachment 3. Choose image and send Image is sent successfully TC009 Send a voice note 1. Press and hold mic icon 2. Record and send Voice note appears in chat TC010 Share contact 1. Tap attachment 2. Choose contact to share Contact shared in chat TC011 Send document 1. Tap attachment 2. Choose file 3. Send Document sent successfully

51. 4. Voice and Video Calls Test Case ID Description Steps Expected Result TC012 Make a voice call 1. Open contact 2. Tap call icon Voice call initiated TC013 Make a video call 1. Tap video call icon Video call started TC014 Receive a call 1. Get call from another user Call screen appears TC015 Mute microphone during call 1. Tap mute icon Mic is muted

52. Write in same way for Group Chats Status feature Privacy And setting Save and Archive messages

53. Sample 2 : Test cases based on typical functionalities of a payment app like GPay

54. Test Case 1 – Login with Mobile Number Test Case ID TC_GPay_001 Module Login Description Verify that a user can log in with a valid mobile number Preconditions GPay app is installed, internet is working Test Steps 1. Open GPay app. 2. Enter valid registered mobile number. 3. Tap on "Next". 4. Enter OTP received via SMS. 5. Tap on "Verify". Expected Result User is successfully logged in and navigated to the homepage Boundary Cases Mobile number with exactly 10 digits should work; any other format should be rejected

55. Test Case 2 – Add Bank Account Test Case ID TC_GPay_002 Module Bank Linking Description Verify that user can link a valid bank account Preconditions User logged into GPay Test Steps 1. Go to ‘Bank Account’ section. 2. Select "Add Bank Account". 3. Choose bank from list or search. 4. Enter account details and confirm. Expected Result Bank account is added successfully and visible in the bank account section Boundary Cases Enter invalid account number → show error; Enter correct format → link successfully

56. Test Case 3 – Send Payment Test Case ID TC_GPay_003 Module Payments Description Verify that a user can send money to another user Preconditions User is logged in and bank account is linked Test Steps 1. Tap on ‘New Payment’. 2. Enter recipient’s mobile number or UPI ID. 3. Enter amount (e.g. ₹500). 4. Add remarks (optional). 5. Confirm transaction with UPI PIN. Expected Result Amount is successfully sent and confirmation message is shown Boundary Cases Amount = ₹1 → should work; Amount = ₹0 → should be rejected

57. Test Case 4 – Transaction History Test Case ID TC_GPay_004 Module Transaction History Description Verify that transaction history is displayed correctly Preconditions User has previous transactions Test Steps 1. Go to ‘Transactions’ section. 2. View all past transactions listed. 3. Tap on a transaction to view details. Expected Result Transaction list is displayed with correct amounts, status, and timestamps Boundary Cases No transaction → show empty state message

58. Test Case 5 – Apply for Refund Test Case ID TC_GPay_005 Module Refund Description Verify that user can apply for a refund on failed transactions Preconditions There is at least one failed transaction Test Steps 1. Go to ‘Transactions’. 2. Select failed transaction. 3. Tap on "Request Refund". 4. Enter reason and submit. Expected Result Refund request is sent successfully and acknowledgment is shown Boundary Cases Without reason → show error; With reason → submit successfully

59. How QA team do Testing : Boundary Test Cases Example – Payment Amount Test Case ID TC_GPay_006 Module Payments Description Verify payment functionality for boundary values of amount Preconditions User logged in, linked bank account Test Steps 1. Try sending ₹1 → verify success. 2. Try sending ₹0 → verify error message. 3. Try sending ₹100000 → depending on limits, verify success or error. Expected Result ₹1 is accepted, ₹0 rejected, large amounts are validated as per system limits

60. Black Box Testing :

61. Black box Testing samples : Example 1 – Age Validation The system accepts age as input. The valid age range is from 18 to 60 inclusive. Boundary Values: Lower boundary: 18 Just below: 17 Just above: 19 Upper boundary: 60 Just below: 59 Just above: 61

62. How to frame test cases ?? Test Case Input Age Expected Result TC1 17 Invalid (below lower boundary) TC2 18 Valid (at lower boundary) TC3 19 Valid (just above lower boundary) TC4 59 Valid (just below upper boundary) TC5 60 Valid (at upper boundary) TC6 61 Invalid (above upper boundary)

63. Example 2 – Password Length Requirement: The password length must be between 8 and 12 characters inclusive. Boundary Values: Lower boundary: 8 Just below: 7 Just above: 9 Upper boundary: 12 Just below: 11 Just above: 13

64. Test Cases: Test Case Password Length Expected Result TC1 7 Invalid (too short) TC2 8 Valid (at lower boundary) TC3 9 Valid (just above lower boundary) TC4 11 Valid (just below upper boundary) TC5 12 Valid (at upper boundary) TC6 13 Invalid (too long)

65. Example 3 – Number of Items Ordered Requirement: A customer can order between 1 and 100 items inclusive. Boundary Values: Lower boundary: 1 Just below: 0 Just above: 2 Upper boundary: 100 Just below: 99 Just above: 101

66. Try for Example 3????

67. Test Cases: Test Case Number of Items Expected Result TC1 Invalid (below lower boundary) TC2 1 Valid (at lower boundary) TC3 2 Valid (just above lower boundary) TC4 99 Valid (just below upper boundary) TC5 100 Valid (at upper boundary) TC6 101 Invalid (above upper boundary)

68. Equivalence Partitioning (EP) Definition: The input domain is divided into valid and invalid partitions (classes). One test case is chosen from each partition.

69. Example 1 – Age Validation (18 to 60) Equivalence Partition Method : Partition Input Range Valid/Invalid P1 18 to 60 Valid P2 Below 18 Invalid P3 Above 60 Invalid : Test Case Input Age Partition Expected Result TC1 25 P1 Valid TC2 15 P2 Invalid TC3 70 P3 Invalid

70. Example 2 – Password Length (8 to 12) Equivalence Partitions: Partition Input Length Valid/Invalid P1 8 to 12 Valid P2 Below 8 Invalid P3 Above 12 Invalid Test Case Password Partition Expected Result TC1 "Pass1234" P1 Valid TC2 "abc" P2 Invalid TC3 "password12345" P3 Invalid

71. Try it for Example 3 ????

72. Partition ID Input Range Description Valid/Invalid P1 1 – 100 Valid number of items Valid P2 <1 (e.g. 0, -1) Invalid – below minimum Invalid P3 >100 (e.g. 101, 150) Invalid – above maximum Invalid Test Case Input Partition Expected Result TC1 1 P1 Valid – order accepted TC2 50 P1 Valid – order accepted TC3 100 P1 Valid – order accepted TC4 P2 Invalid – order rejected TC5 -5 P2 Invalid – order rejected TC6 101 P3 Invalid – order rejected TC7 150 P3 Invalid – order rejected

73. DECISION TABLES : Decision Tables help systematically test combinations of conditions and their effects. The decision table ensures every combination of boundary and non-boundary values is tested. The boundary values are carefully chosen because errors tend to happen at those points. This approach can be easily extended to automated testing or manual test case design.

74. Decision Table FOR EXAMPLE 1 : Rule No. Condition 1: Age ≥ 18 Condition 2: Age ≤ 60 Action: Accept Age Action: Reject Age 1 Yes Yes ✔ ✘ 2 Yes No ✘ ✔ 3 No Yes ✘ ✔ 4 No No ✘ ✔

75. Test Cases Based on Decision Table Test Case Age Condition 1 (≥18) Condition 2 (≤60) Expected Action TC1 18 Yes Yes Accept TC2 30 Yes Yes Accept TC3 60 Yes Yes Accept TC4 61 Yes No Reject TC5 17 No Yes Reject TC6 10 No Yes Reject TC7 -5 No Yes (technically true for some implementations but invalid logically)

76. Try for Password Length???

77. Decision Table Rule No. Condition 1: Length ≥ 8 Condition 2: Length ≤ 12 Action: Accept Password Action: Reject Password 1 Yes Yes ✔ ✘ 2 Yes No ✘ ✔ 3 No Yes ✘ ✔ 4 No No ✘ ✔

78. Test Cases Based on Decision Table Test Case Password Length Condition 1 (≥8) Condition 2 (≤12) Expected Result TC1 8 Yes Yes Accept TC2 10 Yes Yes Accept TC3 12 Yes Yes Accept TC4 13 Yes No Reject TC5 7 No Yes Reject TC6 5 No Yes Reject TC7 20 Yes No Reject TC8 3 No Yes Reject

79. Take Example 3 Home assignment as and check it on 19.09.2025.

80. WHITE BOX TESTING

81. Let’s see about Path Testing…. Path Testing is a white-box testing technique that ensures all possible execution paths of a program are tested at least once. It is based on the program’s control flow graph (CFG) and is mainly used to detect logical errors. Here are examples of Path Testing with step-by-step explanations:

82. Example 1 : Code Snippet void checkNumber (int x) { if (x > 0) printf ("Positive"); else printf ("Non-positive"); } Control Flow Paths: Path 1: Start → Condition TRUE → "Positive" → End Path 2: Start → Condition FALSE → "Non-positive" → End Test Cases: Input: x = 10 → Covers Path 1 Input: x = -5 → Covers Path 2

83. Example 2: Nested IF Code Snippet: void checkGrade (int marks) { if (marks >= 50) { if (marks >= 90) printf ("Excellent"); else printf ("Pass"); } else { printf ("Fail"); } } Control Flow Paths: Path 1: Start → (marks >= 50 TRUE) → (marks >= 90 TRUE) → "Excellent" → End Path 2: Start → (marks >= 50 TRUE) → (marks >= 90 FALSE) → "Pass" → End Path 3: Start → (marks >= 50 FALSE) → "Fail" → End Test Cases: Input: marks = 95 → Covers Path 1 Input: marks = 70 → Covers Path 2 Input: marks = 30 → Covers Path 3

84. Example 3: Loop with Decision Code Snippet: void sumUntil10(int arr [], int n) { int sum = 0; for (int i = 0; i < n; i ++) { if ( arr [ i ] == 10) break; sum += arr [ i ]; } printf ("%d", sum); } Control Flow Paths: Path 1: Loop executes 0 times (n=0) → Print sum Path 2: Loop executes, but arr [ i ] == 10 never occurs → Normal sum → Print sum Path 3: Loop executes, arr [ i ] == 10 occurs → Break early → Print sum Test Cases: Input: n=0 → Covers Path 1 Input: arr = {1, 2, 3}, n=3 → Covers Path 2 Input: arr = {5, 10, 7}, n=3 → Covers Path 3

85. Features : Path testing helps achieve complete branch coverage and sometimes basis path coverage . It is particularly useful for detecting unreachable code and logical errors . The number of paths grows quickly as the complexity of the program increases (cyclomatic complexity helps determine this number).

86. Loop Testing : Loop Testing is a white-box testing technique that specifically focuses on validating loops in the program to ensure they work correctly under different conditions.

87. Code snippet : #include < stdio.h > int main() { int n, i , sum = 0; printf ("Enter n: "); scanf ("%d", &n); for ( i = 1; i <= n; i ++) { sum += i ; } printf ("Sum = %d", sum); return 0; }

88. Test Case ID Input (n) Test Description Expected Result TC-01 Verify loop skip (no execution). Sum = 0 TC-02 1 Single iteration. Sum = 1 TC-03 5 Multiple iterations. Sum = 15 TC-04 Large n (e.g. 10000) Stress test. Correct sum without crash TC-05 Negative n (-5) Invalid input. Program should reject or not enter loop

89. Home Assignment : Problem Statement: Write a program to calculate the sum of the first N natural numbers using a for loop. The program should take n as input. It should sum numbers from 1 to n. Finally, display the result. Handle cases where n is 0 or negative.

90. Problem statement : Write a program to find the maximum element in an array using loops. Input: number of elements n and the elements of the array. Use a for loop to read all elements. Use another for loop to find the largest number. Print the maximum value as output. Handle the case when no elements are entered (n=0).

91. LOOP TESTING : Test Case ID Input Data (n & marks) Test Description Expected Result Actual Result TC-01 n = 0 Verify loop skips entirely and program handles division by zero. Loop skipped, program should show error or handle gracefully. TC-02 n = 1, marks = [85] Verify loop executes exactly once. sum=85, avg=85, Grade=B TC-03 n = 2, marks = [90, 80] Verify loop executes twice and accumulates correctly. sum=170, avg=85, Grade=B TC-04 n = 5, marks = [100, 95, 90, 85, 80] Verify normal multi-iteration case. sum=450, avg=90, Grade=A TC-05 n = 3, marks = [30, 40, 45] Verify loop calculates average leading to Fail grade. sum=115, avg≈38.33, Grade=F TC-06 n = 3, marks = [50, 60, 40] Verify average is exactly on grade boundary (C). avg≈50, Grade=C TC-07 n = 100, marks = [valid marks up to 100 subjects] Stress test with maximum allowed iterations. Handles all inputs, computes correct average & grade. TC-08 n = 3, marks = [-10, 50, 60] Test invalid input (negative marks). Reject invalid input or calculate average including negative. TC-09 n = 3, marks = [100, 100, 100] Test upper boundary (all max marks). avg=100, Grade=A TC-10 n = 3, marks = [0, 0, 0] Test lower boundary (all zero marks). avg=0, Grade=F