Topics covered

Development testing

Test-driven development

Release testing

User testing
 Software Testing

 Basic idea of testing is the execution of software and the observation of its

behavior or outcome.

 If a failure is observed, the executed record is analyzed to locate and fix

the fault.

 Otherwise, we gain some confidence that the software under testing is

more likely to fulfill its designated function.

Can reveal the presence of errors NOT their absence.
 Why Testing ?

Ensure that the software systems would

work as expected when they are used by
their target customers and users.

Demonstrate their operation through

some dry-run or controlled
experimentation in Lab settings.

To demonstrate quality
Testing fulfills two or proper behavior
primary purposes To detect and fix
problems
 Verification and Validation
 Software testing is one of the “verification and validation,” or V&V, software practices.

Verification: Verification (the first V) is the process of evaluating a system or component

to determine whether the products of a given development phase satisfy the conditions
imposed at the start of that phase.
Validation: is the process of evaluating a system or component during or at the end of
the development process to determine whether it satisfies specified requirements.

Verification is usually conducted by QA (quality assurance) team whereas

validation is often conducted by the testing team.
 Testing Techniques

Black Black box/ functional testing

White White box/ structural testing

Grey Grey box testing

 Functional/ External / Black Box Testing

 Functional testing focuses on the external behavior of a SW system or its

various components, while viewing the object to be tested as a black-box

without seeing the contents inside.

Black box Testing
 Test Cases for Black Box Testing

 A Test Case is defined as a group of test inputs, execution condition, and

expected results which further lead to developing a particular test objective

 Applicability (BBT)

 System testing requires more time

 Suitable for IV&V (Independent verification and validation)

Criteria: when to stop (BBT)

When you
complete
Traditionally functional
coverage

When reliability is
Usage-based achieved
Black Box Testing (Focus on Inputs & Outputs – No code visibility)

 Black box testing verifies the system's functionality without knowing the

internal code structure. You check if the input gives the expected

output, based on requirements.

 Test Case 1: Student Login Functionality
Field Details

Test Case ID TC_LOGIN_001

Verify that a student can successfully log in using valid
Test Description
credentials.
Student is registered in the system and has valid login
Pre-conditions
credentials.
1. Open login page.2. Enter valid email and password.3. Click
Test Steps
"Login".
Expected Result Student is redirected to the dashboard.

Actual Result (Leave Blank)

Status (Pass/Fail – Leave Blank)

Black Box Testing (Focus on Inputs & Outputs – No code visibility)
Test Case ID Feature Black Box Testing Focus

Enter valid/invalid credentials and check login

TC_LOGIN_001 Student Login
success or failure.

Select a course and ensure the system registers

TC_ENROLL_002 Course Enrollment
it correctly in the backend.

Upload different file types (PDF, .exe) and check

TC_ASSIGNMENT_003 Upload Assignment
if only valid types are accepted.

Select a course and verify the correct grades are

TC_GRADE_004 View Grades
shown as per user expectations.

Trigger report generation and verify contents

TC_SPR_001 Generate Progress Report
match academic record.
 Black Box Testing

Advantages
• Efficient when used on large systems.
• Since the tester and developer are independent of each other, testing is balanced
and unprejudiced.
• Tester can be non-technical.
• There is no need for the tester to have detailed functional knowledge of system.
• Test cases can be designed as soon as the functional specifications are complete.
Disadvantages
• Test cases are challenging to design without having clear functional specifications.
• It is difficult to identify all possible inputs in limited testing time. As a result, writing
test cases may be slow and difficult.
• There is a high probability of repeating tests already performed by the programmer.
 Structural/ Internal / White Box Testing

 Structural testing focus on the internal implementation, while viewing the

object to be tested as a white-box that allows us to see the contents

inside.
 Applicability (WBT)

 Test in the small objects or Software components

 Or an early stage

 Dual role of programmers/testers

Criterion for stopping (WBT)

When coverage
Mostly goals are met.

When
Occasionally quality/reliability
goals are met.
 White Box Testing (Focus on internal logic/code)

 White box testing involves looking into the code structure, testing

control flow, conditions, loops, data handling, etc. It is usually done by

developers or testers with programming access.

 Test Case 1: Student Login Functionality
Field Details
Test Case ID WBTC_LOGIN_001
Test Description Verify internal logic of the login function using valid and invalid credentials.
The login function exists and is connected to the database. User table
Pre-conditions
contains hashed passwords.
1. Call loginUser(email, password) function.2. Check if email exists in
Test Steps DB.3. Hash the input password.4. Compare with stored hash.5. If match,
redirect to dashboard. Else, show error.
- Condition check for email existence. - Hashing logic execution. -
Code Coverage Goals
Comparison branch (success/failure). - Redirection logic.
Function returns success (e.g., true or redirect) if credentials match; failure
Expected Result
otherwise.
Actual Result (Leave Blank)
Status (Pass/Fail – Leave Blank)
 White Box Testing (Focus on internal logic/code)
Test Case ID Feature White Box Testing Focus

Test authentication method: correct hash

TC_LOGIN_001 Student Login comparison, input validation, SQL injection
prevention.

Check logic that updates student-course

TC_ENROLL_002 Course Enrollment
relationship in the database.

Inspect file upload code for file size/type checks,

TC_ASSIGNMENT_003 Upload Assignment
error handling, and storage path.

Test how grade retrieval query fetches data and

TC_GRADE_004 View Grades
how loops generate report per course.

Generate Progress Verify all data (grades, attendance, remarks) is

TC_SPR_001
Report fetched and formatted properly in report.
 White box testing
Advantages Disadvantages
 To start the testing of the software  To test the software application a highly
no need to wait for the GUI, you can skilled resource is required to carry out
start the White Box Testing. testing who has deep knowledge of the
internal structure of the code which
 As we cover all possible paths of increases the cost.
code so this is thorough testing.  Updated test script is required if changing
 Tester can ask about the implementation too frequently.
implementation of each section, so it  If the application test is large in size then
might be possible to remove unused exhaustive testing is impossible.
 It is not possible for testing each and every
lines of code which might be
path/condition of software program, which
causing introduction of bugs. might miss the defects in code.
 As the tester is aware of internal  White box testing is a very expensive type
coding structure, then it is helpful to of testing.
derive which type of input data is  To analyze each and every line by line or
needed to test the software path by path is nearly impossible work.
application effectively.
 Gray-Box (mixed black-/white-) Testing

 Many of the middle levels of testing.

example: procedures in modules

procedures individually as black box,

procedure interconnection (white-box) at module level.

 When to Stop Testing

 Resource-based criteria (decision is based on resource consumption):

Stop when you run out of time.

Stop when you run out of money.

 Activity-based criteria
 Stop when you complete planned test activities.
 Quality-based criteria

 Stop when quality goals reached.

Direct quality measure: reliability (resemble actual customer usages)

Indirect quality measure: coverage.

Testing Technique General scope Opacity Scripted/non-scripted Who generally does it
Unit testing Small unit of code, no White box Non-scripted Programmer
longer than a class
Integration testing Multiple classes White box, Black box Both Programmer
Functional testing Whole product Black box Scripted Independent tester
System testing Whole product in Black box Scripted Independent tester
representative
environment
Regression testing Major functionalities Black box, White box Both Programmer or
of the whole system independent tester
Smoke testing Major functionalities Black box, White box Both Programmer or
of the initial builds of independent tester
the system
Sanity testing Major functionalities Black box, White box Both Programmer or
of the final builds of independent tester
the system
User acceptance test Whole product in Black box Both Customer
customer’s
environment