0% found this document useful (0 votes)
17 views7 pages

SQE Assignment

The document compares three software testing philosophies: Test-Driven Development (TDD), Behavior-Driven Development (BDD), and Acceptance Test-Driven Development (ATDD), discussing their definitions, pros, cons, and impact on software quality. It also explains Model-Based Testing (MBT) using Finite State Machines (FSMs) to generate test cases for systems with various states, such as a login system. Additionally, it contrasts control-flow based testing with data-flow based testing, highlighting their objectives and providing examples to illustrate their differences.

Uploaded by

Zainab Imran
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
17 views7 pages

SQE Assignment

The document compares three software testing philosophies: Test-Driven Development (TDD), Behavior-Driven Development (BDD), and Acceptance Test-Driven Development (ATDD), discussing their definitions, pros, cons, and impact on software quality. It also explains Model-Based Testing (MBT) using Finite State Machines (FSMs) to generate test cases for systems with various states, such as a login system. Additionally, it contrasts control-flow based testing with data-flow based testing, highlighting their objectives and providing examples to illustrate their differences.

Uploaded by

Zainab Imran
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 7

GOVERNMENT

COLLEGE
UNIVERSITY
FASILABAD
ASSIGNMENT NO 1

SUBMITTED BY:
ZAINAB IMRAN

Roll no : 234837

SUBMITTED TO :
MAM IQRA

SUBJECT:
SOFTWARE QUALITY
ENGENIEERING
Q: 1 Compare and contrast the following software testing philosophies:
Test-Driven Development (TDD), Behavior-Driven Development (BDD), and
Acceptance Test-Driven Development (ATDD). Discuss the pros and cons of
each approach and how they influence software quality?
What is Software Testing?

Define software testing as the process of evaluating a software product to identify defects and
ensure it meets specified requirements.

Why is Testing Important?

 Prevent defects from reaching end-users


 Reduce costs associated with fixing defects later in the development cycle
 Improve software reliability, security, and performance
 Enhance user experience

Test-Driven Development (TDD)

Definition: A development approach where tests are written before the actual code.

Pros:

 Early detection of defects


 Improved code quality and maintainability
 Acts as living documentation

Cons:

 Increased development time initially


 Requires a strong understanding of unit testing

Core Principle: "Write tests before code."

Process:

 Write a test case that fails because the functionality doesn't exist yet.
 Write the minimum amount of code to make the test pass.
 Refactor the code to improve its design and readability.

Benefits:

 Increased code quality and maintainability


 Early detection of defects
 Improved test coverage
 Challenges:
 Steep learning curve for new developers
 Can be time-consuming initially

Behavior-Driven Development (BDD)

Definition: Focuses on defining system behavior from the user's perspective.

Pros:

 Promotes collaboration between developers, testers, and stakeholders


 Encourages clear and concise specifications
 Improves communication and understanding of requirements

Cons:

 Can be more time-consuming to set up initially


 Requires a shared understanding of the domain language

Example: Use a scenario-based approach to demonstrate BDD in action.

Focus: Defining system behavior from the user's perspective.

Key Concepts:

Given-When-Then (GWT) format for specifying scenarios

Domain-Driven Design (DDD) to align with business language

Benefits:

 Improved collaboration between developers, testers, and stakeholders


 Clear and concise specifications
 Enhanced communication and understanding of requirements

Challenges:

 Requires a shared understanding of the domain language


 Can be more time-consuming to set up initially
Acceptance Test-Driven Development (ATDD)

Definition: Combines aspects of TDD and BDD, focusing on high-level acceptance tests.
Pros:
 Early validation of system behavior against requirements
 Improved communication between development teams and stakeholders
 Enhances test coverage and reduces the risk of defects

Cons:
 Requires more upfront effort to define acceptance criteria
 May be less suitable for small projects or quick iterations

Example: Show how ATDD can be used to drive the development of a feature.
Combination: Blends aspects of TDD and BDD.
Focus: Writing acceptance tests before development to define system behavior.

Benefits:
 Early validation of system behavior against requirements
 Improved communication between development teams and stakeholders
 Reduced risk of defects

Challenges:
 Requires more upfront effort to define acceptance criteria
 May be less suitable for small projects or quick iterations

QNO 2 Describe model-based testing and explain how finite state machines (FSMs) are
used in this approach. Provide an example where FSM can be applied to test a login
system with multiple states such as "Logged In," "Logged Out," and "Locked
Account."

Model-Based Testing (MBT)

Model-Based Testing (MBT) is a software testing technique that uses formal models to generate
test cases. It involves creating an abstract model of the system under test, and then using this
model to derive test cases. This approach is particularly effective for complex systems with
many interactions and states.
Finite State Machines (FSMs) in MBT

Finite State Machines (FSMs) are a mathematical model of computation used to describe
systems that can have a finite number of states. In the context of MBT, FSMs can be used to
model the behavior of a system, including its different states and the transitions between them.

By creating an FSM model of a system, we can systematically generate test cases to cover all
possible states and transitions. This helps to ensure that the system behaves correctly in all
scenarios.

Example: Testing a Login System with FSM

Consider a simple login system with three states:

1. Logged Out: The initial state where the user is not logged in.
2. Logged In: The state where the user is successfully logged in.
3. Locked Account: The state where the user's account is locked due to multiple failed
login attempts.

Here's how FSM-based MBT can be used to test this system:

1. State Transition Testing:


o Test the transition from "Logged Out" to "Logged In" by providing valid credentials.
o Test the transition from "Logged In" to "Logged Out" by logging out.
o Test the transition from "Logged Out" to "Locked Account" by providing incorrect
credentials multiple times.
2. State Verification Testing:
o Once in the "Logged In" state, verify that the user can access protected resources.
o Once in the "Locked Account" state, verify that the user cannot log in.
3. Error Handling Testing:
o Test the system's behavior when invalid input is provided (e.g., empty username or
password).
o Test the system's recovery mechanisms after a system failure or network outage.

By systematically testing all possible state transitions and error conditions, MBT using FSMs can
help ensure the reliability and security of the login system.

Benefits of MBT with FSMs

 Improved Test Coverage: FSMs can help identify all possible states and transitions,
ensuring comprehensive testing.
 Early Defect Detection: By testing the system's behavior early in the development cycle,
defects can be identified and fixed more quickly.
 Reduced Test Maintenance: As the system evolves, the FSM model can be updated to
reflect the changes, minimizing the effort required to maintain the test suite.
 Increased Test Automation: FSM-based test cases can be automated, reducing manual
effort and increasing efficiency.

Q NO 3 Compare control-flow based testing with dataflow-based testing. What are the
primary objectives of each method? Use a simple code example to illustrate how these
two testing techniques differ in identifying defects.

Control-Flow-Based Testing vs. Data-Flow-Based Testing

Control-flow-based testing and data-flow-based testing are two distinct software testing
techniques that focus on different aspects of a program's execution.

Control-Flow-Based Testing

 Objective: To ensure that all possible execution paths through the program's control flow
are exercised at least once.
 Approach:
o Analyze the control flow graph of the program, which represents the possible execution
paths.
o Design test cases to cover each path, including branches, loops, and conditional statements.
o The goal is to test all possible combinations of decisions and loops.

Data-Flow-Based Testing

 Objective: To ensure that all definitions of variables in the program are used and all uses of
variables are defined.
 Approach:
o Analyze the data flow of the program, which tracks the definition and use of variables.
o Design test cases to cover all possible definitions and uses of variables.
o The goal is to test all possible combinations of data flows through the program.

Example:

Consider the following simple code:

Python
def calculate_area(length, width):
if length <= 0 or width <= 0:
return 0
else:
return length * width
Control-Flow-Based Testing:

 Test Cases:
o Test with positive values for length and width.
o Test with negative values for length and width.
o Test with zero values for length and width.

Data-Flow-Based Testing:

 Test Cases:
o Test with values that cause the if condition to be true.
o Test with values that cause the if condition to be false.
o Test with values that ensure the return statement is executed.

Finite State Machines (FSMs) in MBT

Finite State Machines (FSMs) are a mathematical model of computation used to describe
systems that can have a finite number of states. In the context of MBT, FSMs can be used to

You might also like