Testing Course

Introduction
I.
1. What is software testing
Software testing is the process of verifying a product to identify defects
and to confirm that the application works according to the specified
requirements.
The purpose of testing is to ensure product quality, prevent costly errors in
production, and guarantee user satisfaction.
Example:
If the application must send a confirmation email after registration, testing
checks whether the email is actually sent, whether it has the correct
content, and whether it reaches the recipient.

2. QA vs QC

Criterion QA (Quality Assurance) QC (Quality Control)

When Before and during development After development

Activity
Preventive Detective
type

Goal Preventing defects Identifying defects

Who The whole team (QA, Dev, PM) Testers / QA team

Defining processes, plans, code Executing tests, reporting

Examples
reviews bugs

Example:
QA defines testing procedures; QC verifies the actual outcome of the application.

3. Main types of testing

Type Description Example

Unit testing Tests a small unit of code calculateTotal() method

Integration Tests communication between

Login and database
testing modules

Functional Verifies that the application meets the

The “Save” button works
testing requirements
Type Description Example

Regression Verifies that old features still work Login still works after an
testing after changes update

Smoke testing Quick stability check You can log in and log out

Buttons and texts display

UI testing Tests the interface
correctly

API testing Tests REST endpoints GET /users returns 200 OK

4. SDLC – Software Development Life Cycle

Phases of developing a software product:
5. Planning – defining scope and resources.
6. Requirement Analysis – analyzing requirements.
7. Design – application architecture.
8. Development – writing code.
9. Testing – verifying functionality.
[Link] – releasing to production.
[Link] – fixing and improving.
Role of QA:
QA participates from the analysis phase to prevent defects (not only to find
them).

5. STLC – Software Testing Life Cycle

Phases of software testing:
6. Requirement Analysis – understanding the requirements.
7. Test Planning – defining the testing strategy.
8. Test Case Design – writing test cases.
9. Test Environment Setup – preparing the test environment.
[Link] Execution – running the tests.
[Link] Reporting – reporting issues.
[Link] Closure – documenting testing conclusions.

6. Agile/Scrum in QA
Agile is a methodology based on fast delivery, adaptability, and
collaboration.
Scrum is one of the most popular Agile implementations.
Main roles:
• Product Owner – sets priorities.
• Scrum Master – facilitates the team.
• QA Tester – tests each product increment.
Ceremonies:
Sprint Planning, Daily Stand-up, Sprint Review, Retrospective.
QA’s role in Agile:
QA participates in defining requirements, tests in every sprint, automates
regression, and provides continuous feedback.

7. Practical exercise: Write a simple Test Plan

Example – ToDo App:
Title: Test Plan – ToDo App
Author: [Your name]
Version: 1.0
1. Scope: Testing basic functionalities (login, add, delete, complete task).
2. Scope details:
Include: authentication, task operations.
Exclude: email notifications, PDF export.
3. Test strategy: manual (automation later).
4. Test environment: Chrome, Firefox, Windows 10.
5. Entry criteria: stable build, approved requirements.
6. Exit criteria: 100% test cases executed, no critical defects.
7. Risks: lack of test data, requirement changes.
8. Deliverables: Test Plan, Test Cases, Bug Reports, Test Summary.

8. Practical exercise 2 – Basic Test Cases

ID Scenario Steps Expected result

TC0 Create new Fill out form, Account created

1 account Submit successfully

TC0 Enter valid

Valid login Redirect to dashboard
2 credentials

TC0
Add task Click “Add Task” Task appears in the list
3

TC0
Delete task Select task, Delete Task disappears
4

TC0 Logout Click Logout User is logged out

ID Scenario Steps Expected result

9. Interview questions –
1. What is software testing?
Answer:
Software testing is the process of verifying a product to ensure it works
according to the specified requirements and meets end-user needs. The
main goal is to identify defects and ensure product quality before it
reaches the customer.
Explanation:
Testing is not just about finding bugs, but also about confirming that the
application provides correct, stable, and secure results under various
conditions.

2. What is the difference between QA and QC?

Answer:
• QA (Quality Assurance) refers to preventive activities that ensure the
quality of the development process. The goal is defect prevention.
• QC (Quality Control) refers to reactive activities that check the final
product to identify defects. The goal is defect detection.
Example:
QA sets procedures and work standards to prevent errors; QC runs tests
and reports discovered bugs.

3. What is a bug?
Answer:
A bug (or defect) is a discrepancy between the expected behavior of the
application and the actual behavior observed during testing.
Example:
If the requirement states that the password must have at least 8
characters but the application allows “123”, that is a bug.

4. What is SDLC?
Answer:
SDLC (Software Development Life Cycle) represents the full life cycle of a
software product—from idea to release and maintenance.
SDLC stages:
1. Planning
2. Requirement Analysis
3. Design
 4. Development
5. Testing
6. Deployment
7. Maintenance
Role of QA:
QA is involved from the analysis phase to prevent defects (“shift-left testing”).

5. What is STLC?
Answer:
STLC (Software Testing Life Cycle) is the process describing the specific
testing activities within a software project.
STLC stages:
1. Requirement Analysis
2. Test Planning
3. Test Case Design
4. Environment Setup
5. Test Execution
6. Defect Reporting
7. Test Closure
SDLC vs STLC difference:
SDLC is the product development life cycle; STLC is the specific testing cycle
within SDLC.

6. What is a Test Plan?

Answer:
A Test Plan is a document describing the strategy, scope, environment,
resources, risks, and planned activities for testing a software product.
Typical content:
• Testing scope
• Included and excluded features
• Types of testing
• Test environment (browser, OS, server)
• Entry and exit criteria
• Risks
• Deliverables (test cases, bug reports, final reports)
Example:
“Test Plan – ToDo App: the goal is to verify login, add task, and logout
functionalities on Chrome.”
 7. What is Smoke Testing?
Answer:
Smoke Testing is a quick check of the application’s essential functionalities
to determine whether the build is stable enough for detailed testing.
Example:
Check if the application is accessible, if login works, and if a task can be
added.
If these pass, the build is “stable” and full testing can proceed.

8. What is Regression Testing?

Answer:
Regression Testing is the process of retesting existing functionality after a
code change to verify that new changes have not affected existing
features.
Example:
After adding the “edit task” feature, QA checks whether “add task” and
“delete task” still work correctly.
Goal:
Prevent the reappearance of old defects or the introduction of new bugs
after changes.

9. What is a Test Case?

Answer:
A Test Case is a detailed description of a testing scenario, including test
conditions, steps to follow, input data, and the expected result.
Typical structure:
• ID: TC01
• Description: Verify valid login
• Steps:
1. Open the application
2. Enter valid username and password
3. Click “Login”
• Expected result: The user is authenticated and redirected to the
dashboard
Goal:
Ensure each requirement is tested systematically.

[Link] is Agile?
Answer:
Agile is a software development methodology based on iterative delivery,
close team collaboration, and continuous adaptation to change.
Agile principles:
• Rapid delivery of working software.
• Collaboration between development, QA, and the client.
• Quick response to change.
• Continuous testing throughout development.
In QA:
QA tests in every sprint, automates regression tests, participates in daily
meetings, and provides immediate feedback on product quality.
Practical example:
In a two-week sprint, QA writes and runs tests for the new features developed,
reporting defects immediately, not at the end of the project.

II.
1. The role of QA in the development team
An intermediate QA does more than run tests:
• participates in defining requirements,
• writes acceptance criteria,
• designs clear test cases,
• performs API and UI testing,
• prioritizes tests based on risk.

2. Advanced types of testing

Type Description Example

Regression Retesting after changes verify login after an update

experiment with unexpected

Exploratory Free-form testing
behaviors

Usability Ease of use messages are clear

Verify across different

Compatibility Chrome vs Edge
browsers

Negative
Invalid behavior enter incorrect data
testing

3. Defect examples and reporting

Bug report example:
ID: BUG001
Title: Task duplicated on double-click
Severity: Major
Priority: High
Description: If the “Add” button is double-clicked quickly, the task is added twice.
Steps:
1. Open the application
 2. Double-click “Add Task” quickly
Expected result: a single task is added
Actual result: two identical tasks

4. Agile QA in practice
In Agile, QA works in short sprints:
• Participates in daily meetings.
• Writes test cases for each User Story.
• Executes manual tests and automates repeatable scenarios.
• Delivers testing reports at the end of the sprint.

5. Practical exercise: Sprint test planning

Story: “As a user, I want to edit an existing task.”
QA activities:
• Analyze requirements and acceptance criteria.
• Write 5 test cases for this feature.
• Execute the tests and report any defects.

6. Interview questions –
1. What is Exploratory Testing?
Answer:
Exploratory Testing is a type of testing where the tester explores the
application freely, without following predefined test cases. The goal is to
discover new defects, unexpected behaviors, and gaps in the coverage of
scripted tests.
Explanation:
The tester uses experience, intuition, and product knowledge to find issues
that may escape automated or planned testing. It is especially useful in
early testing phases, new products, or when requirements are not fully
defined.
Example:
The tester checks what happens when clicking “Add Task” multiple times
quickly or when entering special characters in a text field.

2. What is the difference between Severity and Priority?

Answer:
• Severity describes how severe the technical impact of the defect is on
application functionality.
• Priority describes how urgently the defect must be fixed from a business
perspective.
Explanation:
Severity is determined by QA (technical impact).
Priority is set by the Product Owner or Project Manager (impact on users
and timelines).
Example:
 • A typo on the home page: Severity = Minor, Priority = High (visible to
customers).
• An error in a rarely used function: Severity = Major, Priority = Low.

3. What is a build?
Answer:
A build is a compiled version of the application, created by the
development team and delivered to the testing team for validation.
Explanation:
Each build contains code changes (new features, bug fixes) and is
identified by a version number (e.g., v1.0.2). QA receives the build, runs
tests, and validates that the changes work correctly and don’t affect other
components.
Example:
Build 1.0.5 contains the fix for the “login fails with special-character
passwords” bug. QA will test the fix and verify that the main features still
work.

4. What are entry and exit criteria?

Answer:
Entry Criteria are the conditions that must be met to start testing.
Exit Criteria are the conditions that must be met to finish testing.
Examples:
• Entry Criteria:
o The build is stable and delivered.
o Requirements are clearly defined and approved.
o The test environment is prepared.
• Exit Criteria:
o All planned tests have been executed.
o No open critical defects.
o The final test report is completed.
Explanation:
These criteria ensure testing starts and finishes under controlled conditions,
guaranteeing the quality of results.

5. How do you decide which tests are a priority?

Answer:
Test priority is set based on risk, impact, and frequency of use.
Explanation:
• Test critical business functionalities first (e.g., login, checkout, payment).
• Then test components with high technical risk or recently modified ones.
• Less important or rare tests are left for later.
Example:
In an e-commerce app, test “Add to cart” and “Payment” before secondary
sections like “Edit profile”.
 Recommended method:
Use a “Risk vs Impact” matrix to decide test order.

6. What is Regression Testing and when do you do it?

Answer:
Regression Testing is the process of retesting existing functionalities after
a code change to verify that the application still works correctly.
When:
• After introducing a new feature.
• After fixing a bug.
• Before an important release.
Explanation:
The goal is to prevent new defects from appearing in areas that previously
worked correctly.
Example:
After adding “Edit Task,” run the old tests for “Add Task,” “Delete Task,”
and “View Tasks” to verify they’re still functional.

7. What is Agile and how does QA collaborate with the dev team?
Answer:
Agile is a software development methodology based on iterative delivery,
team collaboration, and rapid adaptation to change.
QA collaboration with the dev team:
• QA attends all team meetings (Sprint Planning, Daily Stand-up, Sprint Review,
Retrospective).
• QA works alongside developers in the same sprint: tests each User Story as
soon as it’s implemented.
• QA provides quick feedback, reports defects in Jira, and helps refine acceptance
criteria.
• QA automates repetitive tests to save time in future sprints.
Practical example:
In a two-week sprint, QA writes test cases for each User Story, validates
developed features, reports bugs immediately, and participates in the final demo.
Explanation:
In Agile, testing is continuous in every sprint, not only at the end of the project, to
detect errors quickly and maintain product quality.

Final exercise — Day 1

Create the following documents:
1. A full Test Plan for the ToDo App (Word or Markdown).
2. At least 10 Test Cases (functional and negative).
3. 2 fictitious Bug Reports.
4. A mini “Test Summary Report.”
Conclusion
After Day 1 you should be able to:
• Clearly explain QA vs QC differences.
• Describe SDLC and STLC.
• Create a Test Plan.
• Write test cases.
• Answer basic and intermediate interview questions correctly.
• Understand how QA integrates into Agile.

I.
1. What is software testing?
Answer:
Software testing is the process by which we verify that an application
works according to the specified requirements and provides a correct
experience to the end user. The purpose of testing is to identify defects
and ensure product quality.
Explanation:
Testing does not guarantee a bug-free product; it ensures correct behavior
under defined conditions.

2. What do QA and QC mean? What’s the difference?

Answer:
QA (Quality Assurance) = preventive, process-oriented activities. Goal:
defect prevention.
QC (Quality Control) = reactive, product-oriented activities. Goal: defect
identification.
Example:
QA writes testing procedures and participates in sprint planning; QC
executes tests and reports bugs.

3. Difference between verification and validation?

Answer:
Verification checks whether the product is built correctly according to the
specification.
Validation checks whether the right product is being built—i.e., it meets
user needs.
Example:
Verification = code review; Validation = manual functional testing.

4. What is SDLC?
Answer:
SDLC (Software Development Life Cycle) are the stages a product goes
through from idea to final product:
1. Planning
2. Requirement Analysis
3. Design
4. Development
5. Testing
6. Deployment
7. Maintenance
Explanation:
QA is involved from Requirement Analysis, not only at the end, to prevent
defects early (shift-left testing).

5. What is STLC?
Answer:
STLC (Software Testing Life Cycle) are the steps the QA team goes
through:
1. Requirement Analysis
2. Test Planning
3. Test Case Design
4. Environment Setup
5. Test Execution
6. Defect Reporting
7. Test Closure
Explanation:
It’s a testing-specific process that runs in parallel with SDLC.

6. What is a Test Plan and what does it contain?

Answer:
A Test Plan is a document describing strategy, scope, environment,
resources, types of testing, and entry/exit criteria.
Example sections:
• Scope (what is and isn’t tested)
• Test Strategy (manual/automation approach)
• Test Environment (browser, OS)
• Deliverables (test cases, bug reports)
• Risks (potential issues)
Explanation:
It’s the main QA document—the testing guide.
 7. What is Smoke Testing?
Answer:
A quick test to check whether the application is stable enough for detailed
testing. Also called a “build verification test.”
Example:
Check you can log in, the dashboard loads, and you can create a task.

8. What is Regression Testing?

Answer:
Testing existing functionality after a code change to confirm no new bugs
were introduced.
Example:
After adding an “edit task” feature, verify “add task” and “delete task” still
work.

9. What is a Bug?
Answer:
A bug is a deviation between expected and actual application behavior.
Example:
Requirement: password must be at least 8 characters.
Actual result: app allows “123”.
That’s a bug.

[Link] is a Test Case?

Answer:
A Test Case describes the steps, input data, and expected result to
validate a specific functionality.
Example:
ID: TC01
Description: Verify valid login
Steps: Enter valid username/password
Expected result: Access to dashboard

II.
1. What types of testing do you know? Give examples.
Answer:
• Functional testing – verifies features against requirements.
• Regression testing – retesting after changes.
• Smoke testing – quick checks of build stability.
• Exploratory testing – unscripted, experience-based testing.
• Usability testing – checks ease of use.
• Compatibility testing – checks across multiple browsers/devices.
Explanation:
Effective QA combines planned testing with exploratory testing for
maximum coverage.
2. What is Agile and how is it applied in testing?
Answer:
Agile is an iterative methodology based on frequent deliveries and close
collaboration.
QA is active in every sprint—continuous testing, regression automation,
rapid feedback.
Explanation:
QA is not a “final step” anymore; it partners with devs from design (shift-
left testing).

3. Difference between Severity and Priority?

Answer:
Severity: how severe the technical impact of a defect is.
Priority: how urgent it is to fix.
Example:
• Missing “Logout” button → Severity: Major, Priority: High.
• A typo → Severity: Minor, Priority: Low.

4. What is a negative Test Case?

Answer:
A test that checks the application’s reaction to incorrect input or
unexpected behavior.
Example:
Enter “abc” as password instead of 8+ characters → the app should show
an error message.

5. What is a Test Scenario?

Answer:
A high-level description of what is being tested, without detailed steps.
Used early for quick planning.
Example:
“Verify the flow of creating and completing a task in the ToDo App.”

6. What is a reproducible defect?

Answer:
A bug that occurs every time the same steps are followed.
Explanation:
Bug reports must include exact repro steps.

7. What is a build?
Answer:
A compiled version of the application delivered to QA for testing. Usually
numbered (e.g., v1.0.3).
 8. What are ‘Entry’ and ‘Exit’ criteria in testing?
Answer:
Entry criteria: conditions to start testing (stable build, approved
requirements).
Exit criteria: conditions to end testing (all tests executed, critical bugs
fixed).

9. What is Exploratory Testing?

Answer:
Free-form testing without pre-written test cases, based on experience and
curiosity.
Goal: discover problems not covered by scripted tests.
Example:
Test what happens when creating 1000 tasks at once, even if not explicitly
required.

[Link] is a Test Summary Report?

Answer:
A final report summarizing testing activity: how many tests ran,
passed/failed, what defects were found, conclusions, and
recommendations.

III.
1. How does QA integrate into the DevOps process?
Answer:
QA contributes to the CI/CD pipeline through test automation,
Jenkins/GitHub Actions reports, post-deployment monitoring, and log
analysis.
Explanation:
Modern QA collaborates with DevOps to ensure continuous quality, not just
pre-release.

2. What is shift-left testing?

Answer:
A strategy where QA is involved as early as possible (requirements and
design) to prevent defects before coding.

3. What is a Test Strategy Document?

Answer:
A document that defines the overall testing approach in a project: types of
tests, tools, responsibilities, metrics, risks, and the automation plan.
 4. What quality metrics does a QA Lead track?
Answer:
• Test Coverage (%)
• Defect Density
• Pass Rate (%)
• Defect Reopen Rate
• Mean Time to Detect/Fix (MTTD/MTTF)
Explanation:
These metrics help measure testing effectiveness and guide improvement
decisions.

5. How do you prioritize tests in a regression cycle?

Answer:
Based on risk analysis: critical, frequently used, or recently modified
functionalities have higher priority.

6. How do you document a defect?

Answer:
By creating a clear, complete Bug Report.
Structure:
• ID
• Short title
• Description + reproduction steps
• Expected / actual result
• Severity / Priority
• Screenshot / Logs / Video

7. How do you contribute to process quality, not just product

quality?
Answer:
By reviewing requirements, clarifying acceptance, automating repetitive
tests, standardizing, and providing constant feedback to the team.

8. How do you ensure testing is efficient and complete?

Answer:
By tracking traceability (Requirement Traceability Matrix), coverage
metrics, continuous reporting, and peer review sessions.

9. What does automated end-to-end testing mean?

Answer:
It simulates a complete user flow (from login to logout) and verifies all
interactions between components (UI, API, DB).
 [Link] a simple JUnit test example for validating a function.
@Test
void shouldReturnTrueWhenPasswordIsValid() {
PasswordValidator validator = new PasswordValidator();
boolean result = [Link]("Test@1234");
assertTrue(result);
}
Explanation:
This is a unit test validating the logic of a password validation function.

Common trick questions

Question Correct answer Explanation

Is QA the same as a QA = process quality; Tester =

Not entirely
tester? executes tests

Can you guarantee a Testing reduces risk; it doesn’t

No
bug-free product? eliminate it

Is testing done only at Modern QA starts at project

No
the end? inception

Is manual testing It’s combined with automation

No
going away? (hybrid testing)

Smoke – every build; Smoke checks build stability;

When to do Smoke vs
Regression – at sprint Regression checks product
Regression?
end integrity

Chapter 2 — Test Design Techniques

Objectives
1. Understand what test design techniques are.
2. Use Equivalence Partitioning, Boundary Value Analysis, Decision Table, and
State Transition concepts.
3. Write smarter, more efficient test cases.
4. Explain these concepts in a QA interview.

1. What are test design techniques

Test design techniques are logical methods used by QAs to write
representative test cases, covering as many scenarios as possible with a
minimal number of tests.
Their purpose:
• reduce the number of tests without losing coverage,
• early defect detection,
• optimize testing effort.
Two major categories:

Type Description Examples

The tester doesn’t see the code; Equivalence Partitioning, Boundary

Black Box
tests behavior based on Value Analysis, Decision Tables,
Testing
requirements. State Transition

White Box The tester analyzes source code Path Testing, Statement Coverage,
Testing and internal flows. Branch Coverage

2. Equivalence Partitioning (EP)

Definition
Equivalence Partitioning is a method of dividing input data into equivalent groups
(partitions), so that testing one value from a group covers the behavior of the
entire group.
Practical example
Requirement: “The age field accepts values between 18 and 60.”
Possible partitions:
• invalid values below 18
• valid values between 18 and 60
• invalid values above 60
Test Cases:
1. Age = 15 → Invalid
2. Age = 25 → Valid
3. Age = 65 → Invalid
Explanation:
You don’t need to test every possible value; one representative per partition is
enough.

3. Boundary Value Analysis (BVA)

Definition
Boundary Value Analysis tests values at the edges of the interval, because most
defects appear there.
Practical example
Requirement: “The age field accepts values between 18 and 60 inclusive.”
Test values:
• Below lower bound: 17 → Invalid
• Lower bound: 18 → Valid
• Upper bound: 60 → Valid
• Above upper bound: 61 → Invalid
Explanation:
We verify how the system reacts to edge values, where validation logic most
often fails.

4. Decision Table Testing

Definition
Decision Table Testing is used to test multiple combinations of conditions and
actions.
Practical example
Requirement: “A user can log in only if they have an active account and enter
correct credentials.”

Cas Active Correct

Expected result
e account data

1 Yes Yes Successful login

2 Yes No Invalid data error

Inactive account
3 No Yes
error

Inactive account
4 No No
error

Explanation:
All logical combinations are verified to ensure complete coverage.

5. State Transition Testing

Definition
State Transition Testing is used when the system has states and transitions
between them. Testing verifies that state transitions are allowed and correct.
Practical example
The ToDo App has the following states:
• Login page
• Dashboard
• Logout
Possible transitions:
• Login → Dashboard (valid)
• Dashboard → Logout (valid)
• Logout → Dashboard (invalid)
Test Cases:
 1. Valid login → Dashboard displayed.
2. Logout → login page.
3. Access Dashboard without login → “unauthorized” error.
Explanation:
This technique is useful for complex flows such as authentication, ordering,
payments, etc.

6. Combining techniques
QAs often combine EP + BVA for maximum coverage.
Example
Requirement: “Grade must be between 1 and 10.”
Partitions (EP):
• Below 1 → invalid
• Between 1 and 10 → valid
• Above 10 → invalid
Limits (BVA):
• 0 (invalid)
• 1 (valid)
• 10 (valid)
• 11 (invalid)

7. Practical exercise – combining techniques

Requirement: “The password field must be 8–16 characters and contain at
least one uppercase letter and one number.”
a) Apply Equivalence Partitioning:
• Passwords < 8 chars → invalid
• Passwords 8–16 chars → valid
• Passwords > 16 chars → invalid
b) Apply Boundary Value Analysis:
• 7 chars → invalid
• 8 chars → valid
• 16 chars → valid
• 17 chars → invalid

8. Practical exercise – Decision Table

Requirement: “The customer gets a discount if logged in and has more
than 3 completed orders.”

No Logged >3 Expected

. in orders result

1 Yes Yes Discount

No Logged >3 Expected
. in orders result

applied

2 Yes No No discount

3 No Yes No discount

4 No No No discount

9. Practical exercise – State Transition

Banking app — account goes through states:
• Active
• Warned (after 2 wrong passwords)
• Locked (after 3 wrong passwords)
Transitions:
• Active → Warned → Locked (valid)
• Locked → Active (invalid without reset)

[Link]’s role in applying these techniques

An effective QA:
• analyzes requirements,
• identifies boundaries and logical conditions,
• creates test cases based on EP/BVA/Decision Tables,
• prioritizes critical tests.

Interview questions –
1. What is Equivalence Partitioning?
Answer:
A method for dividing input data into equivalent groups (partitions) so one
test from a group represents all values in that group.
2. What is Boundary Value Analysis?
Answer:
A method for testing boundary values of input ranges. Most errors occur at
the limits of accepted values.
3. What is Decision Table Testing?
Answer:
A method used to cover all possible combinations of logical conditions that
lead to different outcomes.
4. What is State Transition Testing?
Answer:
A method used to test the behavior of a system that changes state based
on performed actions.
 5. Why are these techniques important?
Answer:
They provide maximum logical coverage with a minimal number of tests,
increasing testing efficiency and reducing execution time.
6. What are the advantages of Boundary Value Analysis?
Answer:
It tests exactly where the most frequent errors occur (at the limits),
reducing the risk of hidden bugs.
7. When do you use each technique?
Answer:
• Equivalence Partitioning: when there are ranges of possible values.
• Boundary Value Analysis: for numeric fields with boundaries.
• Decision Tables: for multiple logical conditions.
• State Transition: for systems that change state (login, orders, flows).

Final exercises —
1. For the “age” field (18–60):
• Create 3 test cases using Equivalence Partitioning.
• Create 4 test cases using Boundary Value Analysis.
2. For a login system:
• Create a Decision Table with combinations of valid/invalid login and
active/inactive account.
3. For an account lock system:
• Describe a State Transition diagram and 3 valid transitions + 1 invalid
transition.

Chapter 3 – WRITING PROFESSIONAL TEST CASES

(Design, Structure, Prioritization, and Best Practices)

Objectives
By the end of this day you will be able to:
1. Define what a test case is and why it matters in QA.
2. Write clear, complete, and verifiable test cases.
3. Prioritize tests (critical/medium/minor) based on risk and impact.
4. Prove requirement coverage with a simple traceability matrix.
5. Answer common interview questions on test case design.

1) What is a Test Case

A Test Case is a step-by-step description of a testing situation with a clear
purpose, input data, execution steps, and expected results.
Its purpose is to verify that a requirement works as expected.
Standard fields of a test case:

Field Description

ID Unique identifier (e.g., TC001)

Title What the test verifies

What must exist beforehand (e.g., logged-

Pre-conditions
in user)

Steps Actions the tester performs

Test Data Input values

Expected
What should happen
Result

Actual Result What happened during execution

Status Passed / Failed / Blocked

Priority High / Medium / Low

2) Principles for Writing Test Cases

1. Clarity – one clear purpose per test.
2. Independence – test outcomes should not depend on the execution
order.
3. Repeatability – any tester can run the test at any time and get the same
outcome.
4. Verifiability – measurable, observable expected results.
5. Maintainability – easy to update when requirements change.

3) Example Test Cases — “ToDo App”

Requirement 1: Functional login

Field Value

ID TC001

Title Verify login with valid credentials

Pre-conditions User account exists and is active

Steps 1) Open app 2) Enter valid email & password 3)

Field Value

Click “Login”

Test Data user = test@[Link], password = Test1234

Expected
User is authenticated and redirected to Dashboard
Result

Actual Result —

Status —

Priority High

Execution note (solution):

If authentication succeeds and Dashboard loads: Passed. Otherwise log a bug.

Requirement 2: Add task

Field Value

ID TC002

Title Verify adding a new task

Pre-conditions User is logged in

1) Go to Dashboard 2) Enter a task name 3) Click

Steps
“Add Task”

Test Data “Buy milk”

Expected
New task appears in the list
Result

Actual Result —

Status —

Priority High

Requirement 3: Delete task

Field Value

ID TC003

Verify deleting an existing

Title
task

Pre-conditions At least one task exists

Steps 1) Select a task 2) Click

Field Value

“Delete”

Test Data —

Expected Task disappears from the

Result list

Actual Result —

Status —

Priority Medium

Requirement 4: Logout

Field Value

ID TC004

Title Verify logout

Pre-conditions User is logged in

Steps 1) Click “Logout”

Test Data —

Expected User is logged out and redirected to the

Result login page

Actual Result —

Status —

Priority Low

4) Practical Exercises WITH Solutions

Exercise 1 — Valid and invalid login
Requirement: System allows login only with valid credentials.
Solution (test set):

#Scenario Input Expected

test@[Link] /
1 Valid login Dashboard shown
Test1234

test@[Link] / Error: “Invalid

2 Wrong password
123456 password”

3 Invalid email test@test / Test1234 Error: “Invalid email

#Scenario Input Expected

format format”

4 Empty fields — Error: “Fields required”

Exercise 2 — Boundary testing for password length

Requirement: Password must be between 8 and 16 characters.
Solution:

Lengt Expect
#Password
h ed

1 1234567 7 Invalid

2 12345678 8 Valid

Abcdefghijklmno
3 16 Valid
p

Abcdefghijklmno
4 17 Invalid
pq

Exercise 3 — Negative tests for task creation

Requirement: The app must not allow creating nameless tasks.
Solution:

#Scenario Input Expected

Click “Add Task” with empty Error: “Task name

1 ""
field required”

2 Task with spaces only "" Error: “Invalid input”

Very long task name (>100 long

3 Error: “Name too long”
chars) string

5) Prioritizing Test Cases

Prioritize by risk and user impact:

Level Description Examples

Business-critical, security, Login, Payment,

High
money flow Authorization

Mediu
Frequent but non-critical Edit profile, Filtering lists
m

Low Cosmetic or secondary Labels, UI microcopy

Level Description Examples

Rule: Test what could block users or the release first.

6) Requirement Coverage (Traceability)

Each test case should map to a functional requirement.
Simple Traceability Matrix:

Requirement Requirement Linked Test

ID Description Cases

REQ-01 User login TC001, TC005

REQ-02 Add task TC002

REQ-03 Delete task TC003

Outcome: You can prove every requirement is covered by at least one test.

7) Bug Report — Complete Example

Bug ID: BUG001
Title: Task added twice when “Add Task” is double-clicked
Severity: Major
Priority: High
Steps to Reproduce:
1. Log in with a valid user
2. Enter text “Test task”
3. Double-click “Add Task” quickly
Expected: One single task is added
Actual: Two identical tasks are added
Status: Open
Note (solution): Implement debounce on the button.

8) Interview Questions with Answers and Explanations

1. What is a Test Case?
Answer: A step-by-step description that verifies a specific requirement.
Explanation: Includes steps, input data, expected result, and pre-
conditions.
2. Difference between Test Scenario and Test Case?
Answer: Scenario = high-level idea; Test Case = detailed, step-by-step
implementation.
 Example: Scenario “Verify login”; Cases “Valid login”, “Invalid password”,
“Empty fields”.
3. What is a Test Step?
Answer: A concrete action performed by the tester within a test case.
Explanation: Precise steps ensure reproducibility.
4. What is Test Data?
Answer: The actual input values used to run the test.
Example: email = test@[Link], password = Test1234.
5. What is test Priority?
Answer: The importance/urgency of a test relative to business impact.
High = blocking; Low = cosmetic.
6. What is a Test Summary Report?
Answer: A document summarizing final testing results:
executed/passed/failed/blocked tests and remaining risks.

9) Self-Assessment Quiz (Multiple Choice) WITH Answers

1. What is a Test Case?
A) Document describing a found defect
B) Step-by-step description verifying a requirement
C) List of unimplemented requirements
Answer: B
2. Main purpose of a Test Case?
A) Installation steps
B) Verify the application meets requirements
C) System architecture description
Answer: B
3. Which is NOT mandatory in a test case?
A) ID
B) Test steps
C) Developer name
Answer: C
4. What is the “expected result”?
A) Steps to run the test
B) Correct system behavior per requirement
C) The error that must appear
Answer: B
5. Scenario vs Test Case?
A) No difference
B) Scenario is high-level; Test Case is detailed and step-by-step
C) Scenario is used only in automation
Answer: B
6. What are “pre-conditions”?
A) System state before running the test
 B) Errors found during testing
C) Post-execution steps
Answer: A
7. What is “Test Data”?
A) Input values used to execute the test
B) Results obtained after testing
C) Source code of the app
Answer: A
8. What does “High priority” mean?
A) Minor impact; can be delayed
B) Critical for application flow
C) Only UI aesthetics
Answer: B
9. A good Test Case is…
A) Clear, verifiable, independent
B) Very long and overly detailed
C) Short and vague
Answer: A
[Link] a requirement changes, you…
A) Ignore until next release
B) Update the affected test case(s)
C) Delete all previous tests
Answer: B
[Link] is a Test Summary Report?
A) Report of unimplemented requirements
B) Final report of testing results and test status
C) List of used test data
Answer: B
[Link] do you ensure traceability between requirements and tests?
A) Test Execution Log
B) Requirement Traceability Matrix (RTM)
C) Bug Report
Answer: B

10) Conclusion —
After Day 3 you should be able to:
• Write professional, clear, and logical test cases.
• Prioritize tests correctly based on risk and impact.
• Prove coverage with a simple traceability matrix.
• Communicate results via concise reports.
• Answer interview questions on test case design confidently.