Unit IV

Object Oriented Testing

• Software typically undergoes many levels of testing, from unit testing
to system or acceptance testing.
• As information systems are becoming more complex, the
object-oriented paradigm is gaining popularity because of its benefits
in analysis, design, and coding.
• Conventional testing methods cannot be applied for testing classes
because of problems involved in testing classes, abstract classes,
inheritance, dynamic binding, message passing, polymorphism,
concurrency, etc.
Object Oriented Testing
• Object-oriented testing is a type of software testing that focuses on
verifying the behaviour of individual objects or classes in an
object-oriented system.
• The goal of object-oriented testing is to ensure that each object or class
in the system performs its functions correctly and interacts properly
with other objects or classes.
Issues in Testing Classes
• it is not possible to test the class dynamically, only its instances i.e,
objects can be tested.
• the concept of inheritance opens various issues e.g., if changes are
made to a parent class or superclass, in a larger system of a class it
will be difficult to test subclasses individually and isolate the error to
one class.
• control flow is characterized by message passing among objects, and
the control flow switches from one object to another by inter-object
communication. Consequently, there is no control flow within a class
like functions.
Issues in Testing Classes
• in a function, arguments passed to the function with global data
determine the path of execution within the procedure.
• in an object, the state associated with the object also influences the
path of execution, and methods of a class can communicate among
themselves through this state because this state is persistent across
invocations of methods.
Techniques of object-oriented testing
• Fault Based Testing: It tries to identify possible faults (areas of design
or code that may lead to errors.). For all of these faults, a test case is
developed to “flush” the errors out.
• Class Testing Based on Method Testing: Each method of the class
performs a well defined cohesive function and can, therefore, be
related to unit testing of the traditional testing techniques. Therefore
all the methods of a class can be involved at least once to test the
class.
Techniques of object-oriented testing
• Random Testing: It is supported by developing a random test
sequence that tries the minimum variety of operations typical to the
behavior of the categories
• Partition Testing: This methodology categorizes the inputs and
outputs of a category so as to check them severely. This minimizes
the number of cases that have to be designed.
• Scenario-based Testing: It primarily involves capturing the user
actions then stimulating them to similar actions throughout the test.
These tests tend to search out interaction form of error.
Purpose of Object Oriented Testing
• Object Interaction Validation: Check to make sure objects interact with
one another appropriately in various situations. Testing makes ensuring
that the interactions between objects in object-oriented systems result in
the desired results.
• Determining Design Errors: Find the object-oriented design’s limitations
and design faults. Testing ensures that the design complies with the
desired architecture by assisting in the identification of problems with
inheritance, polymorphism, encapsulation and other OOP concepts.
• Finding Integration Problems: Evaluate an object’s ability to integrate and
communicate with other objects when it is part of a bigger component or
subsystem. This helps in locating integration difficulties, such improper
method calls or issues with data exchange.
Purpose of Object Oriented Testing
• Assessment of Reusable Code: Evaluate object-oriented code’s reusability.
Code reuse is promoted by object-oriented programming via features like
inheritance and composition. Testing ensures that reusable parts perform
as intended in various scenarios.
• Verification of Handling Exceptions: Confirm that objects respond correctly
to error circumstances and exceptions. The purpose of object-oriented
testing is to make sure that the software responds carefully and is durable
in the face of unforeseen occurrences or faults.
• Verification of Uniformity: Maintain uniformity inside and between objects
and the object-oriented system as a whole. Maintainability and readability
are enhanced by consistency in naming standards, coding styles and
compliance to design patterns.
Units for Object-Oriented Testing
• Traditional software has a variety of definitions for “unit.” Two that
pertain to object-oriented software are
• A unit is the smallest software component that can be compiled and
executed.
• A unit is a software component that would never be assigned to more than
one designer to develop.
Implications of Composition and Encapsulation
• Composition (as opposed to
decomposition) is the central design
strategy in object-oriented software
development. Together with the goal
of reuse, composition creates the need
for very strong unit testing.
• Encapsulation has the potential to
resolve this concern, but only if the
units (classes) are highly cohesive and
very loosely coupled.
Implications of Inheritance
• If a given class inherits attributes and/or operations from super
classes, the stand-alone compilation criterion of a unit is sacrificed.

Implications of Polymorphism
• The essence of polymorphism is that the same method applies to
different objects. Considering classes as units implies that any issues
of polymorphism will be covered by the class/unit testing.
Levels of Object-Oriented Testing
• Three or four levels of object-oriented testing are used, depending on
the choice of what constitutes a unit.
• If individual operations or methods are considered to be units, we
have four levels: operation/method, class, integration, and system
testing.
• Class and integration testing can be well renamed as intraclass and
interclass testing.
Data Flow Testing for Object-Oriented
Software
• It is event driven
• Data flow testing for object-oriented (OO) software is a structural,
white-box testing technique that focuses on how variables (data) are
defined and used throughout the lifecycle of objects.
 Core Levels of OO Data Flow Testing

Data flow analysis in object-oriented systems is typically categorized into three levels of increasing
complexity:

∙ Intra-method Testing: Focuses on the data flow within a single method of a class. It is identical to
traditional procedural data flow testing but ignores class attributes and interactions with other
methods.

∙ Inter-method (Class-level) Testing: Examines the data interactions between a public method and
other methods within the same class that it calls directly or indirectly. This captures how class
attributes (state variables) are defined in one method and used in another.

∙ Intra-class Testing: Tests the interactions that occur when a sequence of public methods is called
in an arbitrary order. This is critical for OO software because an object's state can be modified by
one method and then accessed by another at a much later point in time.
 Example: ooNextDate
▪ ooNextDate is an object-oriented variation of the classic "NextDate" problem used in
software testing to illustrate challenges in testing OO systems, such as encapsulation and
polymorphism.
▪ It takes a date (month, day, year) as input and returns the next day, focusing on validating
date boundaries, leap years, and state changes within objects.
∙ Problem Scope: Unlike the procedural NextDate problem, ooNextDate is typically
implemented with objects like Date, Day, Month, and Year.
∙ Testing Focus:
o Encapsulation: Testing ensures that the internal state of the date objects is maintained
correctly.
o Unit Testing: Focuses on methods that increment days, months, and years.
o Integration Testing: Evaluates how the Date class interacts with Month and Day objects,
testing message-driven interactions.
∙ Boundary Conditions: Tests must cover month-ends, year-ends, leap years, and invalid
date inputs (e.g., February 29th in a non-leap year).
GUI Testing
• GUI is the abbreviation of ‘Graphical User Interface’. It contains
several visual elements, such as buttons, text boxes, menus,
checkboxes, images, etc.
• GUI testing refers to the validating UI functions or features of an
application that are visible to the users, and they should comply with
business requirements.
• GUI testing is also known as UI testing. That means ‘User Interface
testing. So, you can use both acronyms alternatively.
Features of Graphical User Interface Testing
• It provides a customizable test report.
• It is run tests in parallel or distributed on a Selenium Grid with built-in
Selenium Webdriver.
• It allows you to test the functionality from a user’s perspective.
• Sometimes the internal functions of the system work correctly but
the user interface doesn’t then GUI testing is good to have in addition
to the other types.
• It provides reliable object identification, even for web elements with
dynamic IDs.
Types of GUI testing
• Functional Testing
• It determines whether a UI works according to its function requirements.
First, you have to specify the functions you want to test. Then you need to
determine input data and output as per the requirements. After that, you can
execute test cases and compare your actual result to the prior expected
result.
• Usability Testing
• This ensures how easily a user can handle an application. The main factors for
this graphical user interface testing are-
• Faster access – Readability – Satisfaction – Navigation – Experience
Types of GUI testing
• Compatibility Testing
• This testing displays the balance of the app’s design, layouts, and behavior
throughout several OS, browsers, mobile devices, databases, hardware
platforms, networks, etc. Furthermore, compatibility testing checks if the app
can meet the expectations of different OS browsers and devices. This is a
robust way to identify bugs before the final product launch.
• Accessibility Testing
• Accessibility testing ensures that all users (including most disabled persons)
get entrance and interact with software with its maximum possibility. There
are several accessibility criteria for this purpose ex. Accessibility of text and
labels, image contrast ratio, navigations, and more. This testing aims to
remove barriers to communicating with users who face problems with poorly
designed UI.
Graphical user interface (GUI) testing
Techniques/Methods
Graphical user interface (GUI) testing
Techniques/Methods
• Manual Based Testing
• The first method of GUI testing is Manual based testing. The simplest way of
executing the GUI testing is purely using the application manually. Usually,
manual-based testing is implemented by enthusiastic parament test
engineers.
• Model-Based Testing
• The next approach of GUI testing is Model-based Testing as we knew that a
model is a visual narrative of System performance, which helps us to
understand and predict the system performance or activity.
Graphical user interface (GUI) testing
Techniques/Methods
• Record and Replay
• We can perform the GUI testing with the help of Automation tools, which can
be completed in two types. Throughout the record part, the test steps are
encapsulated by the automation tool. And in the playback, these recorded
test steps are implemented on the application under test.
• Hybrid Tests
• The hybrid tests are the different approach in order to perform GUI testing at
the current time. It is a beneficial technique for non-technical background
users to develop a test case by recording their sessions. And after that, the
user who is familiar with coding can further control these recorded tests
technically.
Graphical user interface (GUI) testing
Techniques/Methods
• Code-based Testing
• Another method of performing Graphical user interface testing is Code-based
testing. In order to develop test cases by using the code the GUI testing
provides some GUI testing tools. To discover more difficult test scenarios, we
can use the code-based testing approach.
Challenges and Limitations of GUI testing
• Complexity of GUI systems: Visual noise raises the complexity of a
UI system. Unnecessary white spaces and contrast are the cause of
this problem. Also, additional elements and functions distract users
and result in a poor user experience.
• Maintenance and scalability: Scalability of UI leverages the
reusability of a component. That means the design and code should
be able to adapt to the changes in features. In this way, maintenance
of UI becomes easy. Otherwise, it would be costly to maintain your UI
with changing requirements.
• Integration with other testing types: One of the toughest challenges of
GUI testing is to perform regression testing. Because code changes bother
the regression testing to give the expected output. Another problem occurs
in structural testing.
Exploratory Testing
• Exploratory Testing is a type of software testing in which the tester is
free to select any possible methodology to test the software.
• It is an unscripted approach to software testing.
• In exploratory testing, software developers use their learning,
knowledge, skills, and abilities to test the software developed by
themselves.
• Exploratory testing checks the functionality and operations of the
software as well as identify the functional and technical faults in it.
• Exploratory testing aims to optimize and improve the software in
every possible way.
Why use Exploratory Testing?
• Random and unstructured testing: Exploratory testing is
unstructured and thus can help to reveal bugs that would of
undiscovered during structured phases of testing.
• Testers can play around with user stories: With exploratory testing,
testers can annotate defects, add assertions, and voice memos and in
this way, the user story is converted to a test case.
• Facilitate agile workflow: Exploratory testing helps formalize the
findings and document them automatically. Everyone can participate
in exploratory testing with the help of visual feedback thus enabling
the team to adapt to changes quickly and facilitating agile workflow.
Why use Exploratory Testing?
• Reinforce traditional testing process: Using tools for automated test
case documentation testers can convert exploratory testing
sequences into functional test scripts.
• Speeds up documentation: Exploratory testing speeds up
documentation and creates an instant feedback loop.
• Export documentation to test cases: Integration exploratory testing
with tools like Jira recorded documentation can be directly exported
to test cases.
When should you use Exploratory Testing?
• When need to learn quickly about the application: Exploratory testing is
beneficial for the scenarios when a new tester enters the team and needs
to learn quickly about the application and provide rapid feedback.
• Review from a user perspective: It comes in handy when there is a need to
review products from a user perspective.
• Early iteration required: Exploratory testing is helpful in scenarios when an
early iteration is required as the teams don’t have much time to structure
the test cases.
• Testing mission-critical applications: Exploratory testing ensures that the
tester doesn’t miss the edge cases that can lead to critical quality failures.
• Aid unit test: Exploratory testing can be used to aid unit tests, document
the test cases, and use test cases to test extensively during the later
sprints.
Types of Exploratory Testing
• Freestyle: In freestyle exploratory testing, the application is tested in
an ad-hoc way, there is no maximum coverage, and there are no rules
to follow for testing. It is done in the following cases:
• When there is a need to get friendly with the application.
• To check other test engineers’ work.
• To perform smoke tests quickly.
• Strategy Based: Strategy-based testing can be performed with the
help of multiple testing techniques like decision-table testing,
cause-effect graphing, boundary value analysis, equivalence
partitioning, and error guessing. It is done by an experienced tester
who has known the application for the longest time.
Types of Exploratory Testing
• Scenario Based: Scenario-based exploratory testing is done based on
scenarios with the help of multiple scenarios like end-to-end, test
scenarios. The scenarios can be provided by the user or can be
prepared by the test team.
• Collaborative Exploratory Testing: During exploration, several testers
work together, exchanging observations and insights. Working
together improves the variety of viewpoints and raises the possibility
of finding various kinds of flaws.
Types of Exploratory Testing
• Charter-Based Exploratory Testing: The charter, a written document
that describes the goals and scope of the investigation, is followed by
testers. The charter could list particular features to test, situations to
consider or goals to accomplish.
• Timing-Boxed Exploratory Testing: There is a temporal limit on how
long exploration can last. The goal of testers is to find as many serious
flaws as they can in the allotted period.
Exploratory Testing Process
Exploratory Testing Process
• Learn: This is the first phase of exploratory testing in which the tester
learns about the faults or issues that occur in the software. The tester
uses his/her knowledge, skill, and experience to observe and find
what kind of problem the software is suffering from. This is the initial
phase of exploratory testing. It also involves different new learning
for the tester.
• Test Case Creation: When the fault is identified i.e. tester comes to
know what kind of problem the software is suffering from then the
tester creates test cases according to defects to test the software.
Test cases are designed by keeping in mind the problems end users
can face.
Exploratory Testing Process
• Test Case Execution: After the creation of test cases according to end
user problems, the tester executes the test cases. Execution of test
cases is a prominent phase of any testing process. This includes the
computational and operational tasks performed by the software to
get the desired output.
• Analysis: After the execution of the test cases, the result is analyzed
and observed whether the software is working properly or not. If the
defects are found then they are fixed and the above three steps are
performed again. Hence this whole process goes on in a cycle and
software testing is performed.
Best Practices for Exploratory Testing
• Understand the customer: For effective exploratory testing, it is important to
understand the customer’s viewpoint and expectations properly. End users
browse the same software in different ways based on age, gender preferences,
and other factors. Testers must be able to approach the software from all those
user perspectives.
• The aim of testing should be clear: For effective exploratory testing, the testers
need to have a clear mindset and have clarity on the mission of testing. Testers
should maintain clear notes on what needs to be tested, and why it needs to be
tested.
• Proper documentation: It is important to make proper notes and take a
document and monitor test coverage, risk, Tets execution log, issues, and queries.
• Tracking of issues: The tester should maintain a proper record of questions and
issues raised during testing.
Challenges of Exploratory Testing
• Replication of failure: In exploratory testing replication of failure to
identify the cause is difficult.
• Difficult to determine the best test case: In exploratory testing,
determining the best test case to execute or to determine the best
tool to use can be challenging.
• Difficult to document all events: During exploratory testing
documentation of all events is difficult.
• Difficult reporting: Reporting test results is difficult in exploratory
testing as the report does not have well-planned test scripts to
compare with the outcome.
Advantages of Exploratory Testing
• Less preparation required: It takes no preparation as it is an unscripted
testing technique.
• Finds critical defects: Exploratory testing involves an investigation process
that helps to find critical defects very quickly.
• Improves productivity: In exploratory testing, testers use their knowledge,
skills, and experience to test the software. It helps to expand the
imagination of the testers by executing more test cases, thus enhancing the
overall quality of the software.
• Generation of new ideas: Exploratory testing encourages creativity and
intuition thus the generation of new ideas during test execution.
• Catch defects missed in test cases: Exploratory testing helps to uncover
bugs that are normally ignored by other testing techniques.
Disadvantages of Exploratory Testing
• Tests cannot be reviewed in advance: In exploratory testing, Testing is
performed randomly so once testing is performed it cannot be reviewed.
• Dependent on the tester’s knowledge: In exploratory testing, the testing is
dependent on the tester’s knowledge, experience, and skill. Thus, it is
limited by the tester’s domain knowledge.
• Difficult to keep track of tests: In Exploratory testing, as testing is done in
an ad-hoc manner, keeping track of tests performed is difficult.
• Not possible to repeat test methodology: Due to the ad-hoc nature of
testing in exploratory testing, tests are done randomly and thus it is not
suitable for longer execution time, and it is not possible to repeat the same
test methodology.
Model-Based Testing
• Model-based testing is nothing but a simple testing technique in
which we get different test cases that are described by the model. In
this type, the test cases are generated via both online and offline test
case models.
Significance of Model-Based Testing
• Early Defect Detection: Model-Based Testing (MBT) makes it possible
for testers to find problems during the requirements or design phases
by using model validation. By doing this, flaws are kept from
spreading to more expensive fixing development phases.
• Lower Maintenance Costs: Since test cases are derived from models,
any modifications to the system can immediately update the
appropriate test cases, which in turn can reflect any changes made to
the models. This lessens the work and expense of maintaining test
cases, particularly in complex and large-scale systems.
Significance of Model-Based Testing
• Reusable Test Assets: Models and test cases developed during the
software development lifecycle can be utilized again for regression
testing. This guarantees uniformity in testing procedures across
projects and helps optimize the return on investment in testing
efforts.
• Encouragement of Agile and DevOps Methods: Because it facilitates
quick feedback loops and continuous testing, it works well with Agile
and DevOps approaches. As part of the CI/CD pipeline, test cases can
be automatically developed and run, giving developers quick
feedback and guaranteeing the quality of deliverables.
Significance of Model-Based Testing
• Enhanced Test Coverage: It generates test cases from models that
describe all potential system behaviors and scenarios, assisting in
ensuring thorough test coverage. This aids in the early detection of
possible flaws throughout the development process.
Types of Model-Based Testing
• Statecharts: These are an expansion of FSMs (Finite State Machines) that
enable complicated transitions, parallelism, and hierarchical state
representation. They are frequently used to simulate the behavior of
reactive systems, like embedded systems and user interfaces.
• Markov Models: These systems display probabilistic behavior, with state
changes taking place according to probabilistic rules. They are employed in
system performance and reliability analysis as well as modelling stochastic
processes.
• Decision Tables: Decision Tables are a condensed, tabular method of
expressing intricate decision reasoning. They are frequently utilized in
rule-based systems and business logic validation, and they are helpful for
modelling systems having conditional behavior.
Types of Model-Based Testing
• Entity-Relationship Diagrams (ERDs): These diagrams show how different
entities in a database schema are related to one another. They are
frequently employed in database design for showing the relationships and
data structure between various entities.
• Control Flow Graphs (CFGs): CFGs show the order in which the code is
executed, illustrating the control flow of a program. They are employed in
test case generation, coverage analysis, and programme behavior analysis.
• Data flow diagrams (DFDs): These show how data moves through a system
with an emphasis on the entry, processing, and output of data. They are
helpful in determining data dependencies and confirming that data
transformations in software systems are accurate.
Types of Model-Based Testing
• Unified Modelling Language (UML) diagrams: It offers a common
notation for expressing different software system components. Use
case diagrams show how users and systems interact, whereas activity
diagrams show how control moves across a system.
Advantages of Model-Based Testing
• Efficiency: The automation efficiency is so much higher in this type and the
higher level also be acquired by the model.
• Comprehensive testing is also possible in this type and the changes that
have been made can be easily tested by model.
• Different types of machines like finite state machines, unified model
diagrams, and state charts are mostly taking part in this testing technique.
• By reducing the cost of the process available in this type. Simultaneously
many numbers of processes are running together for performance
increase.
• The defects that are made in the beginning stage are identified and the
defect counts increase accordingly the testing undergoes in a progressing
manner.
Commercial tool support for model-based
testing
• Testsigma
• fMBT
• GraphWalker
• Modbat
• Tosca
• BPM-X
Benefits of Using Model-Based Testing Tools
1. Enhanced Test Coverage: MBT’s systematic approach ensures that even
complex edge cases and corner scenarios are thoroughly tested, significantly
increasing test coverage compared to traditional methods.
2. Improved Efficiency and Reduced Costs: By eliminating the need for
manual test case creation, MBT tools save significant time and resources,
leading to increased productivity and reduced testing costs.
3. Early Bug Detection and Improved Quality: MBT’s ability to identify
bugs early in the development cycle fosters higher-quality software with
fewer defects reaching end users.
4. Enhanced Maintainability: Changes to the system model automatically
update the generated test cases, ensuring test coverage remains accurate and
relevant.
Use Case Testing
• A Use Case is a tool for defining the required user interaction and if you are
trying to create a new application or make changes to an existing
application, several discussions are made. It plays a vital role in SDLS.
• It depends upon the user’s actions and the response of the system to the user’s
actions.
• They are user-oriented, not system-oriented.
• It is a list of actions that will be taken by the actor while interacting will the system.
• It describes the functional requirements of the system.
• They help to uncover the integration defects, defects that arise due to incorrect
interaction between different components.
• Use cases are used to hearten designers to outcomes before attempting to specify
outcomes, and thereby they help to make requirements more proactive in system
development.
Who writes Use Case?
• The client provides the customer requirement specification (CRS) for
the application.
• The development team will write the use case according to the CRS.
• The client reviews the use cases.
• If use cases are approved by the client, then the development team
starts further the design and coding phase.
• Approved use cases are also sent to the testing team, so they can
start writing test cases.
What is Use Case Testing?
• Use Case Testing is generally a part of black box testing and that helps
developers and testers to identify test scenarios that exercise the
whole system on each transaction basis from start to finish. Business
experts and developers must have a mutual understanding of the
requirement, as it’s very difficult to attain.
• Use case testing is a functional testing technique that helps in identifying and
testing scenarios on the whole system or doing start-to-end transactions.
• It helps to identify the gaps in software that might not be identified by testing
individual components.
• It is used to develop test cases at the system level or acceptance level.
Feature of Use Case Testing
• User-focused Approach: The interactions and scenarios that users have
with the system are the main focus of testing. It places a strong emphasis
on verifying the system’s response to user input and activities.
• Scenario-Based Testing: Use case scenarios, which depict common or
important interactions between users and the system, serve as the
framework for organizing testing. This strategy helps in making sure that
the system lives up to user expectations in practical settings.
• Requirements Validation: Use Case Testing verifies that the system
satisfies the specifications given in the use cases. Testing makes ensuring
that the functional requirements are implemented correctly, as each use
case usually reflects a particular functional requirement.
Feature of Use Case Testing
• Testing, both positive and negative: Positive testing (valid inputs and
expected behavior) and negative testing (invalid inputs and error
handling) are both included in use case testing. This broad method
assists in identifying flaws in a variety of situations.
• Integration Testing: Integration testing, which verifies how various
parts or subsystems interact within the framework of a use case, is
frequently a part of use case testing.
Benefits of Use Case Testing
• Helps manage complexity: Use case-driven analysis that helps manage
complexity since it focuses on one specific usage aspect at a time.
• Testing from the user’s perspective: Use cases are designed from the
user’s perspective. Thus, use case testing is done from the user’s
perspective and helps to uncover the issues related to the user experience.
• Reduced complexity of test cases: The complexity of the test cases will be
reduced as the testing team will follow the path given in the use case
document.
• Test functional requirements: Use cases help to capture the functional
requirements of a system. Thus, use case testing tests the functional
requirements of the system.
• Starts from a simple view of the system: Use cases start from the simple
view of the system and are used primarily for the users.
Drawbacks of Use Case Testing
• Missing use case: If there is a use case missing from the use case
document, then it will impact the testing process as there is a high
possibility that the test cases for the missing use case will also be left
out.
• Cover only functional requirements: Since use cases cover only
functional requirements so use case testing by default is functional
requirements oriented.
• Use cases are from the user’s perspective: 100% test coverage is not
possible in cases as use cases are written from the user’s perspective
and there may be some scenarios that are not from the user’s
perspective, so then it may not be included in the test document.
Test Driven Development (TDD)
• The changes in Agile development have met in practical ways to make
good software instantly. One of the ways is Test-Driven Development
(TDD), which helps get good output.
What is Test Driven Development (TDD)
• Test-driven development (TDD) is a method of coding in which you
first write a test and it fails, then write the code to pass the test of
development, and clean up the code. This process recycled for one
new feature or change. In other methods in which you write either all
the code or all the tests first, TDD will combine and write tests and
code together into one.
History of Test Driven Development (TDD)
• TDD shares similarities with test-first programming from extreme
programming, which started in 1999. However, TDD has gained more
widespread interest on its own. Programmers also use TDD to
improve and fix old code written with different methods.
Test-driven work in Test Driven Development
(TDD)
• TDD, or Test-Driven Development, is not just for software only. It is also
used to create product and service teams as test-driven work. To make
testing successful, it needs to be created at both small and big levels in
test-driven development.
• These will be checks to help plan and check the outcomes of the tests. They
follow a similar process to TDD, with some small changes which are as
follows:
• “Add a check” instead of “Add a test”
• “Run all checks” instead of “Run all tests”
• “Do the work” instead of “Write some code”
• “Run all checks” instead of “Run tests”
• “Clean up the work” instead of “Refactor code”
• Repeat these steps
Process of Test Driven Development (TDD)
• It is the process in which test cases are written before the code that
validates those cases. It depends on the repetition of a concise
development cycle. Test-driven Development is a technique in which
automated Unit tests are used to drive the design and free decoupling of
dependencies. The following sequence of steps is generally followed:
• Write a complete test case describing the function. To make the test cases the
developer must understand the features and requirements using user stories and
use cases.
• Run all the test cases and make sure that the new test case fails.
• Write the code that passes the test case
• Run the test cases
• Refactor code – This is done to remove duplication of code.
• Repeat the above-mentioned steps again and again
TDD Vs. Traditional Testing
• Approach: Test Driven Development (TDD) it is a way of making
software in that tests are written first after that the code is written. In
traditional testing it the other way, It will making the code first and
then start testing in it.
• Testing Scope: TDD checks small parts of code one by one. Traditional
testing checks the whole system, including how different parts work
together.
• Iterative: TDD is works in small small steps. It will write a small code
and tests, and then improve regularly to code until it passes all the
tests which are required. Traditional testing tests the code one time
and then fixing any problems which ate been find.
• Debugging: TDD will try to find mistakes early in the process of code,
which makes it will easier to fix them. Traditional testing will find the
mistakes for after, which can be when held then it will harder to fix in
the future.
• Documentation: TDD will focuses on documentation of the tests and
their results. Traditional testing might have been more clear
information about how the testing made done and the system will
tested.
Advantages of Test Driven Development
(TDD)
• Unit test provides constant feedback about the functions.
• Quality of design increases which further helps in proper
maintenance.
• Test driven development act as a safety net against the bugs.
• TDD ensures that your application actually meets requirements
defined for it.
• TDD have very short development lifecycle.
Disadvantages of Test Driven Development
(TDD)
• Increased Code Volume: Using TDD means writing extra code for tests
cases , which can make the overall codebase larger and more Unstructured.
• False Security from Tests: Passing tests will make the developers think the
code is safer only for assuming purpose.
• Maintenance Overheads: Keeping a lot of tests up-to-date can be difficult
to maintain the information and its also time-consuming process.
• Time-Consuming Test Processes: Writing and maintaining the tests can
take a long time.
• Testing Environment Set-Up: TDD needs to be a proper testing
environment in which it will make effort to set up and maintain the codes
and data.
Test – Then – Code Cycles
• Write a Test
• Run a Test
• Write a Code
• Run all Tests
• Refactor
• Repeat
MDD versus TDD
• Test Driven Development (TDD)
• Test Driven Development (TDD) is a software development technique which
develops the test cases before the software is fully developed and make
necessary updates based on test results. Means here some tests are written
and the system is build accordingly when it passes the test cases. And the test
cases are designed based on various circumstances and reaction of the
system.
• Benefits of TDD :
• It gives a clarification that what we want from the respective code.
• It creates a detailed specification.
• It reduces time spent on rework.
• It helps in quick identification of errors and problems.
• It creates SOLID code and supports a clean interface.
MDD versus TDD
• Model Driven Development (MDD)
• Model Driven Development (MDD) is an Agile version of Model Driven
Architecture (MDA) or Model Driven Development (MDD) where extensive
models are created before source code is written. It does not create a bigger
version of the model rather it creates agile versions of the model which
enhance the outcome of software development.
• Benefits of AMDD :
• It helps in rapid development of the software application.
• It gives a clarification that what we want from the respective code.
• It allows regular adaptation to changing circumstances.
• It gives continuous attention to technical excellence.
Difference Between TDD and MMD
Software Testing Excellence
• Craftsmanship
• Mastery of the subject matter
• Mastery of the associated tools
• Mastery of the associated techniques
• The ability to make appropriate choices about tools and techniques
• Extensive experience with the subject matter
• A significant history of high-quality work with the subject matter
Best Practices of Software Testing
• They are usually defined by practitioners.
• They are “tried and true.”
• They are very dependent on the subject matter.
• They have a significant history of success.
• High-level programming languages (FORTRAN and COBOL)
• Structured programming
• Third-generation programming languages
• Software reviews and inspections
Best Practices of Software Testing
• Software reviews and inspections
• The waterfall model of the software development life cycle
• Fourth-generation programming languages (domain specific)
• The object-oriented paradigm
• Various replacements for the waterfall model
• Rapid prototyping
• Software metrics
• CASE (computer-aided software engineering) tools
• Commercial tools for project, change, and configuration management
Best Practices of Software Testing
• Integrated development environments
• Software process maturity (and assessment)
• Software process improvement
• Executable specifications
• Automatic code generation
• UML (and its variants)
• Model-driven development
• Extreme Programming (with its odd acronym, XP)
• Agile programming
• Test-driven development
• Automated testing frameworks
Top 10 Best Practices for Software Testing
Excellence
• Model-Driven Agile Development
• Careful Definition and Identification of Levels of Testing
• System-Level Model-Based Testing
• System Testing Extensions
• Incidence Matrices to Guide Regression Testing
• Determine the order and contents of builds (or increments)
• Facilitate fault isolation when faults are revealed (or reported)
• Guide regression testing
• Use of MM-Paths for Integration Testing
Top 10 Best Practices for Software Testing
Excellence
• Intelligent Combination of Specification-Based and Code-Based
Unit-Level Testing
• Code Coverage Metrics Based on the Nature of Individual Units
• Exploratory Testing during Maintenance
• Test-Driven Development
Mapping Best Practices to Diverse Projects
• Best practices are necessarily project dependent. The software
controlling a NASA space mission is clearly distinct from a
quick-and-dirty program to develop some information requested by
someone’s supervisor. Here are three distinct project types.
• A Mission-Critical Project
• Mission-critical projects have severe reliability and performance constraints,
and are often characterized by highly complex software. They are usually
large enough so that no single person can comprehend the full system with
all its potential interactions.
Mapping Best Practices to Diverse Projects
• A Time-Critical Project
• While mission-critical projects may also be time-critical, this section refers to
those projects that must be completed rapidly. Time-to-market and the
associated loss of market share are the usual drivers of this project type.

• Corrective Maintenance of Legacy Code

• Corrective maintenance is the most common form of software maintenance.
It is in response to a reported fault. Software maintenance typically
represents three-fourths of the programming activity in most organizations,
and this is exacerbated by the pattern that maintenance changes are usually
done by someone who did not create the code being changed.
Best Testing Practices for Diverse Projects