UNIT 5-TESTING

PART-A

1. Mention the steps in mapping design to code.(A/M 2017)(N/D 2015)

The steps involved in mapping design to code are,
1. Class and interface definitions The required visibility and associations between classes are
indicated by the interaction diagrams.
2. Method definitions A method body implementation may be shown in a UML note box. It should
be placed with in braces, it is semantic influence. The syntax may be pseudo-code, or any language.
It is common to exclude the method signature (public void ...), but it is legal to include it.

2. Explain about OO integration testing.(A/M 2017)

It is a level of software testing where individual units are combined and tested as a group.
The purpose of this level of testing is to expose faults in the interaction between integrated units.
Test drivers and test stubs are used to assist in Integration Testing.

3. What is refactoring and testing?(A/M 2018)(N/D 2016)

Rule of three is a code refactoring rule of thumb to decide when a replicated piece of code
should be replaced by a new procedure. It states that the code can be copied once, but that when the
same code is used three times, it should be extracted into a new procedure.
Testing is generally described as a group of procedures carried out to evaluate some aspect of
a piece of software. Testing can be described as a process used for revealing defects in software and
for establishing that the software has attained a specified degree of quality with respect to selected
attributes

4. What is regression testing?(N/D 2016)

 Regression Testing is defined as a type of software testing to confirm that a recent program or code
change has not adversely affected existing features.
 Regression Testing is nothing but a full or partial selection of already executed test cases which are
re-executed to ensure existing functionalities work fine.
 5. What is unit testing?(N/D 2017,2019)
 In unit testing, the individual classes are tested. It is seen whether the class attributes are
implemented as per design and whether the methods and the interfaces are error-free.
 Unit testing is the responsibility of the application engineer who implements the structure.

6. Define a test case.(N/D 2016)

A TEST CASE is a set of conditions or variables under which a tester will determine
whether a system under test satisfies requirements or works correctly. The process of developing test
cases can also help find problems in the requirements or design of an application.
Test Case Summary: To verify that clicking the ... Test Procedure: Select the coin denomination
in ... Test Case ID: TC001
Test Suite ID: TS001

7. What is meant by OO Testing?(N/D 2018)

The shift from traditional to object-oriented environment involves looking at and
reconsidering old strategies and methods for testing the software. The traditional programming
consists of procedures operating on data, while the object-oriented paradigm focuseson
objects that are instances of classes.

8. Define class testing.(N/D 2018,A/M 2019)

A type of specification based testing or black box testing technique, Equivalence Partitioning
or Equivalence Class Testing is a widely used method that decreases the number of possible test
cases that are required to a software product.

9. List out the issues in OO Testing.(N/D 2015)

 Implication of Encapsulation
 Implication of Inheritance
 Implication of Genericity
 Implications of Polymorphism

10. List the issues of class testing.

 Issue1: Adequately testing classes
 Issue2: Observation of object states and state changes.
 Issue3: The retesting of classes-I
 Issue4: The retesting of classes-II

11. What are the two major goals considered for integrated testing?
 To detect defects that occur on the interfaces of units.
 To assemble the individual units into working subsystems and finally a complete system that is ready
for system test.

12. What are the challenges of class testing?

OO class is the target for test case design.
Encapsulation: Difficult to obtain a snapshot of a class without building extra methods which
display the classes’ state Inheritance and Polymorphism: Each new context of use (subclass)
requires re-testing because a method may be implemented differently (polymorphism). Other
unaltered methods within the subclass may use the redefined method and need to be tested.
 13. What are the three different incremental strategies of integration testing?
 Thread-based testing
 Use-based testing
 Cluster testing

14. List the types of errors found during integration testing.
 Messaging errors User
 interface errors

15. What are the challenges of GUI testing?

GUI test automation is harder than API test automation – Documentation; GUIs are slower that
APIs Observing visible GUI state is difficult Observing invisible GUI state is tricky almost
impossible Controlling GUI actions is difficult

16. List the automated GUI testing tools.

 Capture/Replay testing tools
 Random testing
 Unit testing
 Model-Based testing

17. Write about GUI Testing. (A/M 2019)

 GUI is often designed for the naïve user who does not have the knowledge of commands but can
interact through the mouse pointer and interacting with the web elements.
 In such scenario, the developer has to think from the perspective of the naive user and the tester
makes sure that the look and feel of the screen are simple, interacting through GUI on a website is
easy to understand, etc.
 Therefore, GUI testing involves the testing of the screens which have the controls such as menus,
icons, buttons, types of bars i.e. toolbar, menu bar, dialog boxes and windows, etc.

18. Define software quality assurance? (N/V 2019)

 Software Quality Assurance (SQA) is a set of activities for ensuring quality in software engineering
processes.
 It ensures that developed software meets and complies with the defined or standardized quality
specifications.
 SQA is an ongoing process within the Software Development Life Cycle (SDLC) that routinely
checks the developed software to ensure it meets the desired quality measures.
 SQA practices are implemented in most types of software development, regardless of the underlying
software development model being used.
 SQA incorporates and implements software testing methodologies to test the software.
 PART-B
1. Explain about the mapping of design code implementation in an object oriented language.(N/D
2016)(N/D 2015)(N/D 2018) 16Mrks
 Mapping Designs to Code Implementation in an object-oriented language requires writing source
code for: 1) Class and interface definitions 2) Method definitions 3) Collection Classes in Code
 Mapping Designs to Code Creating Class Definitions from DCDs DCDs describe the class or
interface name, superclasses, operation signatures, and attributes of a class. This is sufficient to
create a basic class definition in an OO language.
 Mapping Designs to Code Creating Class Definitions from DCDs From the DCD, a mapping to
the attribute definitions and method signatures of SalesLineItem is straightforward, as shown
 Mapping Designs to Code Creating Methods from Interaction Diagrams The sequence of the
messages in an interaction diagram translates to a series of statements in the method definitions. The
enterItem interaction diagram illustrates the Java definition of the enterItem method. For this
example, we will explore the implementation of the Register and its enterItem method.
 Mapping Designs to Code Creating Methods from Interaction Diagrams The enterItem message is
sent to a Register instance; therefore, the enterItem method is defined in class Register.
 Mapping Designs to Code Creating Methods from Interaction Diagrams The enterItem message is
sent to a Register instance; therefore, the enterItem method is defined in class Register. public void
enterItem(ItemID itemID, int qty) Message 1: A getProductDescription message is sent to the
ProductCatalog to retrieve a ProductDescription. ProductDescription desc =
catalog.getProductDescription(itemID); Message 2: The makeLineItem message is sent to the Sale.
currentSale.makeLineItem(desc, qty);
 Mapping Designs to Code Creating Methods from Interaction Diagrams The enterItem message is
sent to a Register instance; therefore, the enterItem method is defined in class Register.
public void enterItem(ItemID itemID, int qty)
Message 1: A getProductDescription
message is sent to the ProductCatalog to retrieve a ProductDescription.
ProductDescription desc = catalog.getProductDescription(itemID);
Message 2: The makeLineItem
message is sent to the Sale. currentSale.makeLineItem(desc, qty);

 Mapping Designs to Code Collection Classes in Code One-to-many relationships are common.
For example, a Sale must maintain visibility to a group of many SalesLineItem instances, as shown
in Figure In OO programming languages, these relationships are usually implemented with collection
of object.
 Mapping Designs to Code Collection Classes in Code For example, the Java libraries contain
collection classes such as ArrayList. Using ArrayList, the Sale class can define an attribute that
maintains an ordered list of SalesLineItem instances.
Test-Driven Development and Refactoring
 Test-Driven Development (TDD) An excellent practice that applicable to the UP iterative
methods is test-driven development (TDD) or test-first development. In this practice, unit testing
code is written before the code to be tested, and the developer writes unit testing code for all
production code.
 Test-Driven Development (TDD) In OO unit testing TDD-style, test code is written before the class
to be tested. The test is written first, imagining the code to be tested is written.
 Test-Driven Development (TDD) Advantage The unit tests actually get written: Human nature is
such that avoidance of writing unit tests is very common, if left as an afterthought.
 Test-Driven Development (TDD) Advantage Programmer satisfaction leading to more consistent test
writing: In the traditional style, a developer first writes the production code, informally debugs it,
and then as an afterthought is expected to add unit tests, it doesn't feel satisfying. This is test-last
 development. However, if the test is written first, we feel a worthwhile challenge and question in
front of us: Can I write code to pass this test? And then, after the code is cut to pass the tests, there is
some feeling of accomplishment meeting a goal
 Test-Driven Development (TDD) Advantage Clarification of detailed interface and behavior:
Consider your state of mind if you write the test for an object first: As you write the test code, you
must imagine that the object code exists. you must think through the details of the public view of the
method, its name, return value, parameters, and behavior. That reflection improves or clarifies the
detailed design.
 Test-Driven Development (TDD) Advantage Provable, repeatable, automated verification:
Obviously, having hundreds or thousands of unit tests that build up over the weeks provides some
meaningful verification of correctness. And because they can be run automatically, it's easy.
Writing tests starts to really feel like it's paying off as the size of the application grows.
 Test-Driven Development (TDD) Advantage The confidence to change things: In TDD, there will
eventually be hundreds or thousands of unit tests and a unit test class for each production class. Get
confidence to change things
 Test-Driven Development cycle (TDDC) Add a test: In test-driven development, each new feature
begins with writing a test. To write a test, the developer must clearly understand the feature's
specification and requirements. This may also be a modification of an existing test. This is a different
feature of test-driven development versus writing unit tests after the code is written: it makes the
developer focus on the requirements before writing the code
 Test-Driven Development cycle (TDDC) Run all tests and see if the new one fails: This validates
that the test is working correctly and that the new test does not mistakenly pass Write some code:
The next step is to write some code that causes the test to pass. The new code written at this stage is
not perfect. That is acceptable because later steps improve
 Test-Driven Development cycle (TDDC) Run tests: If all test cases now pass, the programmer can be
confident that the code meets all the tested requirements. Refactor code: Now the code should be
cleaned up as necessary. Change the code for passing the test to where it logically belongs. Remove
any duplication you can find. Make sure that variable and method names represent their current use.
 Test-Driven Development cycle (TDDC) Repeat: Starting with another new test, the cycle is then
repeated to push forward the functionality.
 Refactoring Refactoring is a structured, disciplined method to rewrite or restructure existing code
without changing its external behaviour, applying small transformation steps combined with re-
executing tests each step.
 Refactoring The essence of refactoring is applying small behaviour preserving transformations one at
a time. After each transformation, the unit tests are re- executed to prove that the refactoring did not
cause a regression (failure). Therefore, there's a relationship between refactoring and TDD. All those
unit tests support the refactoring process.
 Refactoring The activities and goals of refactoring include: remove duplicate code improve clarity
make long methods shorter remove the use of hard- coded literal constants etc.
2. Discuss in detail about OO Integration testing and OO System testing. (N/D 2016) 16Mrks
(N/D 2017) 6Mrks
INTEGRATION TESTING
It is a level of software testing where individual units are combined and tested as a group.
The purpose of this level of testing is to expose faults in the interaction between integrated units.
Test drivers and test stubs are used to assist in Integration Testing.

Definition by ISTQB
 integration testing: Testing performed to expose defects in the interfaces and in the interactions
between integrated components or systems. See also component integration
testing, system integration testing.
 component integration testing: Testing performed to expose defects in the interfaces and
interaction between integrated components.
 system integration testing: Testing the integration of systems and packages; testing interfaces to
external organizations (e.g. Electronic Data Interchange, Internet).
Analogy
During the process of manufacturing a ballpoint pen, the cap, the body, the tail and clip, the ink
cartridge and the ballpoint are produced separately and unit tested separately. When two or more
units are ready, they are assembled and Integration Testing is performed. For example, whether the
cap fits into the body or not.
Method
Any of Black Box Testing, White Box Testing and Gray Box Testing methods can be used.
Normally, the method depends on your definition of ‘unit’
Tasks
 Integration Test Plan
o Prepare
o Review
o Rework
o Baseline
 Integration Test Cases/Scripts
o Prepare
o Review
o Rework
o Baseline
 Integration Test
o Perform
 When is Integration Testing performed?
Integration Testing is the second level of testing performed after Unit
Testing and before System Testing.
Who performs Integration Testing?
Developers themselves or independent testers perform Integration Testing.
Approaches
 Big Bang is an approach to Integration Testing where all or most of the units are combined together
and tested at one go. This approach is taken when the testing team receives the entire software in a
bundle. So what is the difference between Big Bang Integration Testing and System Testing? Well,
the former tests only the interactions between the units while the latter tests the entire system.
 Top Down is an approach to Integration Testing where top-level units are tested first and lower level
units are tested step by step after that. This approach is taken when top-down development approach
is followed. Test Stubs are needed to simulate lower level units which may not be available during
the initial phases.
 Bottom Up is an approach to Integration Testing where bottom level units are tested first and upper-
level units step by step after that. This approach is taken when bottom-up development approach is
followed. Test Drivers are needed to simulate higher level units which may not be available during
the initial phases.
 Sandwich/Hybrid is an approach to Integration Testing which is a combination of Top Down and
Bottom Up approaches.
SYSTEM TESTING
It is a level of software testing where a complete and integrated software is tested. The purpose of
this test is to evaluate the system’s compliance with the specified requirements.

Definition by ISTQB
 system testing: The process of testing an integrated system to verify that it meets specified
requirements.
Analogy
During the process of manufacturing a ballpoint pen, the cap, the body, the tail, the ink cartridge and
the ballpoint are produced separately and unit tested separately. When two or more units are ready,
they are assembled and Integration Testing is performed. When the complete pen is integrated,
System Testing is performed.
Method
Usually, Black Box Testing method is used.
Tasks
 System Test Plan
o Prepare
o Review
o Rework
o Baseline
 System Test Cases
o Prepare
o Review
o Rework
o Baseline
 System Test
o Perform
When is it performed?
System Testing is the third level of software testing performed after Integration Testing and before
Acceptance Testing.
Who performs it?
Normally, independent Testers perform System Testing.

3. Explain the following (A/M 2017) 16Mrks

i) GUI Testing (A/M 2018) 6Mrks
ii) OO System testing
GUI TESTING
What is GUI Testing?
o GUI is often designed for the naïve user who does not have the knowledge of commands but can
interact through the mouse pointer and interacting with the web elements.
o In such scenario, the developer has to think from the perspective of the naive user and the tester
makes sure that the look and feel of the screen are simple, interacting through GUI on a website is
easy to understand, etc.
o Therefore, GUI testing involves the testing of the screens which have the controls such as menus,
icons, buttons, types of bars i.e. toolbar, menu bar, dialog boxes and windows, etc.
o GUI testing should focus on the design of the screen and ease of the interaction with the graphical
elements on the screen.
o Also, the tester should keep in mind about the responsiveness and look and feel of the screen while
conducting the GUI testing.
o Bottom line is that the tester needs to think like a user because the end user has no knowledge about
the application or software but it the user interface of the software which makes the user believe
about the utility of that application.
o GUI stands for Graphical User Interface. One can interact with a computer or any software or
website on a computer through two types of interfaces.
o These interfaces are command line interface and graphical user interface. Command line interface is
quite difficult as compared to the graphical user interface as the user is required to remember the
commands and different types of syntaxes.
o Graphical user interface involves interacting with the elements such as text box, radio buttons,
drop-down menu, checkboxes, etc. which are visible on the screen.
o During interaction with GUI, the user is not required to remember the commands but can simply
interact through mouse pointer and pick any element on the website or windows application.
GUI Testing Scope:
The following is the checklist to perform the GUI testing.
 Any GUI element should be tested for its position on the screen, dimensions, length both max and
min, allowed characters or numbers, etc.
 Test about the required functionality of the application that uses GUI.
 Display of proper error message.
 Clear demarcation of screen sections which can provide the look and feel of the application.
 Fonts are large enough which can be easily readable.
 Text alignment on the screen is appropriate.
 Text color and background color of the screen are properly chosen which pleases the end user.
 Images displayed on the screen are not blurred and properly shaped
 GUI elements are displayed appropriately on the screen with the required resolution.
GUI Testing Approaches:
GUI testing can be performed in the following three ways:
1. Manual GUI Testing: Like any traditional manual testing approach, this approach is very simple
where the graphical screens are manually checked by the tester and compared with the prototype
screens or the test cases as prepared against the business requirement documents.
2. Record and Replay (Test Automation): We can automate the GUI testing with the help of tools
such as QTP, Selenium, Sikuli, etc. depending on the programming skills of the tester.
If the tester is not sound to write the computer program using different programming languages then
he can use record and play approach which is provided by many test automation tools such as QTP,
Selenium IDE etc.
During record and play, the tool itself generate the code as a part of the test automation scripts.
Otherwise, the tester can use APIs such as Selenium web driver, Sikuli, etc. and write the test scripts
by his own in the different programming languages such as Java, Ruby, Groovy, PHP, Python, etc.
Such test scripts can automate the test scenarios to test the graphical elements which are present on
the screen under test.
3. Model-based testing: A graphical description of the behavior of the system is known as a Model. A
model helps us to determine the system behavior under test. We use the system requirements in order
to generate the efficient test cases with the help of a Model. Given below is an overview of a model-
based testing.
 Develop a model.
 Determine various inputs for this model.
 Determine expected output for this model.
 Execute the tests.
 Compare the actual result against the expected output.
 Make the decision on the action on the model.
 Charts and Decision tables are two common modeling techniques which can be used for deriving the
test cases. Charts represent the system state and check the state against some inputs. Decision tables
are a comparison approach where the results are compared in a tabular manner i.e. actual result
against expected output. Fitness testing tool is an example of Decision table based modeling
approach.
Therefore, the model-based testing can be defined as an evolutionary approach for the creation of the
efficient test cases from the business requirements. It helps to test all possible intermittent states
which GUI can land in a particular scenario based on the given set of inputs.
Challenges in GUI Testing:
Regression testing is one of the challenges which the tester may encounter when the application
undergoes GUI changes very frequently. Any change made to the GUI element makes it difficult for
a tester to accept whether the current solution is correct and has not made any impact to other GUI
elements. Such problem to test the impact of change on one GUI element on the other GUI element
can be minimized only if the project team maintains enough documents about the application
changes at the GUI level.
Commonly Used GUI Testing Tools:
The following are the most commonly used GUI Testing tools.
 Selenium
 Sikuli
 UFT
 Cucumber
 Silk Test
ii) OO System testing
SYSTEM TESTING
It is a level of software testing where a complete and integrated software is tested. The purpose of
this test is to evaluate the system’s compliance with the specified requirements.

Definition by ISTQB
 system testing: The process of testing an integrated system to verify that it meets specified
requirements.
Analogy
During the process of manufacturing a ballpoint pen, the cap, the body, the tail, the ink cartridge and
the ballpoint are produced separately and unit tested separately. When two or more units are ready,
they are assembled and Integration Testing is performed. When the complete pen is integrated,
System Testing is performed.
Method
Usually, Black Box Testing method is used.
Tasks
 System Test Plan
o Prepare
o Review
o Rework
o Baseline
 System Test Cases
o Prepare
o Review
o Rework
o Baseline

When is it performed?
System Testing is the third level of software testing performed after Integration Testing and before
Acceptance Testing.
Who performs it?
Normally, independent Testers perform System Testing.
 4. Discuss about the comparison between OO Integration testing and OO System testing.(A/M
18)(7 Marks)

System Testing Integration Testing

In integration testing, we check the

In system testing, we check the system as a interfacing between the inter-
1. whole. connected componenets.

It is performed after unit testing.

2. It is performed after integration testing.

It is carried out for performing both functional It is generally limited to functional

3. and non-functional testing(performance, usability aspects of the integrated components.
etc).

Since the interfacing logic is required

Since the testing is limited to evaluation of to perform this testing, hence, it
functional requirements, hence, it includes black- requires white/grey box testing
4. box testing techniques only. techniques along with black- box
techniques.

The different type of system testing are- The different approaches of

Functional testing, Performance testing, Usability performing integration testing namely
5. testing, Reliability testing, Security testing, - Top down, bottom up, big bang and
Scalability testing, Installation testing etc. hybrid integration.

5. Explain the issues involved in OO Testing.(A/M 2017,2018) (N/D 2017)16&13Marks

Traditional testing methods are not directly applicable to OO programs as they involve OO
concepts including encapsulation, inheritance, and polymorphism. These concepts lead to issues,
which are yet to be resolved. Some of these issues are listed below.
1. Basic unit of unit testing.
 The class is natural unit for unit test case design.
 The methods are meaningless apart from their class.
 Testing a class instance (an object) can validate a class in isolation.
 When individually validated classes are used to create more complex classes in an application
system, the entire subsystem must be tested as whole before it can be considered to be
validated(integration testing).
 2. Implication of Encapsulation.
 Encapsulation of attributes and methods in class may create obstacles while testing. As methods are
invoked through the object of corresponding class, testing cannot be accomplished without object.
 In addition, the state of object at the time of invocation of method affects its behavior. Hence, testing
depends not only on the object but on the state of object also, which is very difficult to acquire.
3. Implication of Inheritance.
 Inheritance introduce problems that are not found in traditional software.
 Test cases designed for base class are not applicable to derived class always (especially, when
derived class is used in different context). Thus, most testing methods require some kind of
adaptation in order to function properly in an OO environment.
4. Implication of Genericity.
 Genericity is basically change in underlying structure.
 We need to apply white box testing techniques that exercise this change.
i.)Parameterization may or may not affect the functionality of access methods.
ii.)In Tableclass, elemType may have little impact on implementations of the access methods of the
Table. Example: generic (parameterized class) class Tableclass(elemType) int numberelements;
create(); insert(elemType entry); delete(elemType entry); isEmpty() returns boolean;
isentered(elemType entry) returns boolean; endclass
But UniqueTable class would need to evaluate the equivalence of elements and this could vary
depending on the representation of elemType. Example: class UniqueTable extends Table
insert(elemType entry); endclass;
5. Implications of Polymorphism
 Each possible binding of polymorphic component requires a seperate set of test cases.
 Many server classes may need to be integrated before a client class can be tested.
 It is difficult to determine such bindings.
 It complicates the integration planning and testing.
6. Implications for testing processes
 Here we need to re-examine all testing techniques and processes.

6. How is class test different from conventional testing? Explain with an example. (N/D 2017)
7Marks
Conventional testing focuses on input-process-output, whereas class testing focuses on each
method, then designing sequences of methods to exercise states of a class

1. Conventional testing: It is nothing but validation i.e. testing done while executing the code.
Unconventional testing: It is Verification, which involves verification of docs, code etc.
2. Conventional testing: is a sort of testing in which the test engineers will check the developed
application or its related parts are working according to the requirements or not.
Unconventional testing: is a sort of testing in which Quality Assurance people will check each and
every role in the organization from the Initial Phase of SDLC to the end.
3. In Conventional testing, the developed components of the application are checked by the tester for
whether they are working according to the expectations of the consumers or not.
A typical Unconventional testing starts from the coding phase of the systems development life
cycle.
4. Unconventional testing keeps a track of the whole software development process on the basis of the
quality assurance principles i.e.whether or not the software has been developed according to the
guidelines and specifications provided by the client company.
The Conventional testing is focused more up on the functionality of the software system or
application
 It is concluded that Conventional testing is nothing but a similar initiative of quality
management system. Unconventional testing is to just by looking at the name that it doesn’t follow
any conventions.

7. What is integration testing? Explain the same with respect to object oriented system. (N/D
2017) 13M

Integration testing is a level of software testing where individual units are combined and
tested as a group. The purpose of this level of testing is to expose faults in
the interaction between integrated units. Test drivers and test stubs are used
to assist in integration testing. The software testing phase in which individual software modules are
combined and tested as a group. It occurs after unit testing and before validation testing.
Purpose of Integration Testing:
The purpose of integration testing is to verify the functional, performance, and reliability between
the modules that are integrated.
Integration Strategies: Big-Bang Integration
Big Bang Integration Testing is an integration testing strategy wherein all units are linked at once,
resulting in a complete system. When this type of testing strategy is adopted, it is difficult to isolate
any errors found, because attention is not paid to verifying the interfaces across individual units.
Big Bang Integration - WorkFlow Diagram
Big Bang Testing is represented by the following workflow diagram:

Disadvantages of Big-Bang Testing

 Defects present at the interfaces of components are identified at very late stage as all components are
integrated in one shot.
 It is very difficult to isolate the defects found.
 There is high probability of missing some critical defects, which might pop up in the production
environment.
 It is very difficult to cover all the cases for integration testing without missing even a single scenario.
Top-Down Integration
 Top-down and bottom-up integration strategies are still applicable to object- oriented systems,
 provided that we correctly identify dependencies among classes.
 Unlike traditional procedural languages, where the identification of the use relation among modules is
straight forward, object- oriented systems are characterized by several different relations which can
hold between classes.
 Top-down integration testing is an integration testing technique used in order to simulate the behavior
of the lower-level modules that are not yet integrated.
 Stubs are the modules that act as temporary replacement for a called module and give the same output
as that of the actual product.
 The replacement for the 'called' modules is known as 'Stubs' and is also used when the software needs
to interact with an external system.

Stub - Flow Diagram:

The above diagrams clearly states that Modules 1, 2 and 3 are available for integration, whereas,
below modules are still under development that cannot be integrated at this point of time. Hence,
Stubs are used to test the modules. The order of Integration will be:
1,2
1,3
2,Stub 1
2,Stub 2
3,Stub 3
3,Stub 4

Testing Approach:
+ Firstly, the integration between the modules 1,2 and 3
+ Test the integration between the module 2 and stub 1,stub 2
+ Test the integration between the module 3 and stub 3,stub 4

Each component at lower hierarchy is tested individually and then the components that rely upon these
components are tested.
Bottom Up Integration - Flow Diagram
 The order of Integration by Bottom-down approach will be:
4,2
5,2
6,3
7,3
2,1 and 3,1
Testing Approach :
+ Firstly, Test 4,5,6,7 individually using drivers.
+ Test 2 such that it calls 4 and 5 separately. If an error occurs we know that
the problem is in one of the modules.
+ Test 1 such that it calls 3 and If an error occurs we know that the problem is
in 3 or in the interface between 1 and 3

Though Top level components are the most important, yet tested last using this strategy. In Bottom-
up approach, the Components 2 and 3 are replaced by drivers while testing components 4,5,6,7. They
are generally more complex than stubs.

Integration Testing is a phase in software testing in which standalone modules are combined and
tested as a single entity.
During that phase, the interface and the communication between each one of those modules are tested.
There are two popular approaches for Integration testing which is Top down Integration Testing and
Bottom up Integration Testing.
In Hybrid Integration Testing, we exploit the advantages of Top-down and Bottom-up approaches.
As the name suggests, we make use of both the Integration techniques.

Hybrid Integration Testing - Features

 It is viewed as three layers; viz - The Main Target Layer, a layer above the target layer and a layer
below the target layer.
 Testing is mainly focused for the middle level target layer and is selected on the basis of system
characteristics and the structure of the code.
 Hybrid Integration testing can be adopted if the customer wants to work on a working version of the
application as soon as possible aimed at producing a basic working system in the earlier stages of the
development cycle.
 8. What is GUI based testing? How does it help to improve software design? (N/D 2018) 15M

What is GUI Testing?

Graphical User Interface GUI testing is a process of testing an application’s visual elements,
such as images, texts, buttons, etc., to validate their expected performance as well as their functional
accuracy. By testing the graphical user interface, the team can validate various graphical icons and
visual indicators, like the radio button, check box, text box, list box, menu, dialog box, bars,
among other things.
Performed manually or with the assistance of automation tools, the GUI tests are focused on
testing the functionality as well as elements of the graphical user interface, which are visible to the
user to ensure that it meets the requested specifications. This goal is achieved through the use of a
variety of test cases and test scripts.
GUI Testing: Features
Clarity about GUI testing can further be achieved by understanding its various features. Hence,
following are some critical features of GUI testing and other aspects related to it.
1. The process of GUI testing is more difficult than command in line interface testing.
2. Majority of testing tools used for GUI testing are primarily focused on regression testing.
3. It also confirms the appearance elements, such as the font and images, conforms to their design
specifications.
GUI Testing Guidelines:
While performing GUI testing, the team of testers should consider some important guidelines, which
can further help them to validate the accuracy of the various visual indicators. These guidelines offer
great assistance to the team and enable them to make various necessary changes.
These guidelines are:
1. It is crucial for the team to check the elements of GUI, like size, font, length, width, and more.
2. Ensure error messages are being displayed accurately.
3. Validate the font size and readability of font.
4. Check the alignment of the text.
5. Quality and clarity of images.
6. The images should be aligned properly. Different Ways of GUI Testing:
There are mainly three important GUI testing techniques, which are used by software testers around
the world to validate the accuracy as well as the quality of graphical user interface elements.
These three techniques are:
I. Manual Based Testing: Testers checked all the graphics with the prerequisites in business document
manually. For example, a test can check the multiplication (33X5) manually.
II. Record & Replay: This is an automated GUI testing tool; all the tasks are recorded during the test.
The recorded steps or tasks are executed with expected behavior. Now, this can be repeated several
times with various data sets.
III. Model Based Testing: This type of testing acts as a graphic description (just like science models).
Such testing predicts the system's behavior and this technique generates the test cases efficiently.
Charts and decision tables are some of the model-based techniques.
Advantages of GUI Testing:
Tests the user interface from the users perspective.
Efficiently reduces the number of risks towards the end of development life cycle.
Offers developers and testers ease of use and learning.
Helps validate the compliance of various icons and elements with their design specifications.
Increases the reliability and improves quality of the product.
It requires more memory resources, which leads the system to perform slowly.
Disadvantages of GUI Testing:
The process of testing is time consuming and may require extra software for running GUIs.
 Since the interface of an application changes frequently, the team might have to refactor recorded
test script to improve its accuracy.
Limited access or no access to the source code makes the process of testing difficult.
Commonly Used GUI Testing Tools:
The following are the most commonly used GUI Testing tools.
Selenium
Sikuli
UFT
Cucumber
Silk Test
TestComplete

How does it help to improve software design?

The challenge: designing a supportive user interface
If you are aware of how a sub optimally designed GUI might hamper the user: congratulations!
However, how can you find out which of several possible user interface variants supports the user
experience best?
Your own experience in the field will not necessarily contribute a good piece of advice, because
quite likely you are professionally blinkered – ironically due to your very experience.
You need a method that offers a lot of insights and can help you make the right choices. Such a
method is to sketch a few different GUI variants and have potential or actual users check them out.
You don't need to implement these variants in your software. A wireframe tool to set up some
mockups is sufficient, preferably with some scriptable interactivity.
A wizard page for Xtext
 Our case deals with a wizard page for Xtext, a tool for creating domain-specific languages and
associated language infrastructures.
 Don't worry, you do not need to understand in detail what Xtext is and what it does to follow this
use case and the basic principle behind usability tests.
 Suffice to know that Xtext is Eclipse-based, has a wizard to create a new Xtext project and that this
wizard includes a particular page to configure some advanced options for a new Xtext project.
 The diagram shows the implementation of this dialogue in the current Xtext release.
 There has been some discussion going on among Xtext core developers on whether this wizard
page's design really satisfies users' needs or not.
 There wasn't a clear conclusion, so itemis' usability experts were asked to investigate further and
run a usability test on the current GUI and some alternatives.
 You can configure it e.g. to toggle a certain option from disabled to enabled state if some
checkbox has been checked.
 This is really nice, because this way users can play around with mockup interfaces and get a more
realistic impression of how the real implementation would behave. Fig. 2 shows a wireframe
version of the screenshot.
Original wizard page
 Wireframe of the original user interface (variant 1)
Running usability tests
 In the relaxed atmosphere of a usability dinner, five software developers were asked to perform a
simple task with all three user interface variants: creating a new Xtext project with support for an
Eclipse editor front-end.
 The participants had none to moderate Xtext experience and none to senior expert level Eclipse
experience. The "New Project" wizard or at least the “Advanced Xtext Configuration” wizard page
was new to all of them.
 While performing their task, they were asked to think aloud and comment on what they see, what
they like, what they dislike, what irritates them etc.
Hidden option dependencies
 The most prominent test result: All users stumbled over an unexpected dependency between wizard
options.
 The background: If you want to support a front-end in your Xtext project you have to check
"Generic IDE Support" first, and then select the kind of front-end you want, i.e. Eclipse Plugin,
IntelliJ IDEA Plugin or Web Integration.
 By default, "Generic IDE Support" is preselected in the wizard. However, the user could get into a
situation where the option is disabled, because e.g. he unchecked it inadvertently.
 Not everyone noticed that message immediately and not everyone was immediately able to tell
what to do next. Sure, sooner or later everyone managed to find out that he had to enable "Generic
IDE Support" first in order to activate Eclipse support.
 However, this is a severe usability issue, because everyone got irritated by the unexpected
dependency and by the "unavoidable" necessity of dealing with an error message.

Automatically setting the "Generic IDE Support" option (variant 2)

 A second wizard page variant (fig. 3) copes with this deficiency. It looks almost identical to the first
version, but its dynamic behavior is different: If the user checks "Eclipse Plugin", the "Generic IDE
Support" option is automatically checked, too, i.e. the user interface essentially does by itself what
the user would have to do otherwise.
"Generic IDE Support" is also disabled so it cannot be unchecked as long as "Eclipse Plugin" or one
of the other front-end options are checked. Users liked this behaviour very much and had no issues
fulfilling their task. This holds even though the dependency was still not explicitly visible in the
GUI.

Making option dependencies visible (variant 3)

A third variant of the wizard page visualized the options in a dependency hierarchy (fig 4). Users
were now able to see that
 "Generic IDE Support" is a requirement for "Eclipse Plugin", "IntelliJ IDEA Plugin", and "Web
Integration", and
 There is no dependency between IDE issues and the remaining options like e.g. testing support or
source layout.
 On the other hand some users found it confusing that they could not select "Eclipse Plugin" right
away, but instead had to check "Generic IDE Support" first. Overall, users felt that variant 2
supported them best, followed by variant
9. Discuss the various types of testing strategies in object oriented environment. (A/M 2018)

Testing is a continuous activity during software development. In object-oriented systems, testing

encompasses three levels, namely, unit testing, subsystem testing, and system testing.
Unit Testing:
 In unit testing, the individual classes are tested. It is seen whether the class attributes are
implemented as per design and whether the methods and the interfaces are error-free.
 Unit testing is the responsibility of the application engineer who implements the structure.
Subsystem Testing:
 This involves testing a particular module or a subsystem and is the responsibility of the subsystem
lead. It involves testing the associations within the subsystem as well as the interaction of the
subsystem with the outside.
 Subsystem tests can be used as regression tests for each newly released version of the subsystem.
System Testing:
 System testing involves testing the system as a whole and is the

responsibility of the quality-assurance team. The team often uses system tests as regression tests
when assembling new releases.
Object-Oriented Testing Techniques:
Grey Box Testing:
The different types of test cases that can be designed for testing object-oriented programs are called
grey box test cases. Some of the important types of grey box testing are:
 State model based testing: This encompasses state coverage, state transition coverage, and state
transition path coverage.
 Use case based testing: Each scenario in each use case is tested.
 Class diagram based testing: Each class, derived class, associations, and aggregations are tested.
 Sequence diagram based testing: The methods in the messages in the sequence diagrams are tested.
 Techniques for Subsystem Testing:
The two main approaches of subsystem testing are:
 Thread based testing: All classes that are needed to realize a single use case in a subsystem are
integrated and tested.
 Use based testing: The interfaces and services of the modules at each level of hierarchy are tested.
Testing starts from the individual classes to the small modules comprising of classes, gradually to
larger modules, and finally all the major subsystems.
Categories of System Testing:
 Alpha testing: This is carried out by the testing team within the organization that develops software.
 Beta testing: This is carried out by select group of co-operating
customers.
 Acceptance testing: This is carried out by the customer before accepting the deliverables.
Black-box testing:
Testing that verifies the item being tested when given the appropriate input provides the expected
results.
Boundary-value testing:
Testing of unusual or extreme situations that an item should be able to handle.
Class testing:
The act of ensuring that a class and its instances (objects) perform as defined.
Component testing:
The act of validating that a component works as defined.
Inheritance-regression testing:
The act of running the test cases of the super classes, both direct and indirect, on a given subclass.
Integration testing:
Testing to verify several portions of software work together.
Model review:
An inspection, ranging anywhere from a formal technical review to an informal walkthrough, by
others who were not directly involved with the development of the model.
Path testing:
The act of ensuring that all logic paths within your code are exercised at least once.
Regression testing:
The acts of ensuring that previously tested behaviors still work as expected after changes have been
made to an application.
Stress testing:
The act of ensuring that the system performs as expected under high volumes of transactions, users,
load, and so on.
Technical review:
A quality assurance technique in which the design of your application is examined critically by a
group of your peers. A review typically focuses on accuracy, quality, usability, and completeness.
This process is often referred to as a walkthrough, an inspection, or a peer review.
User interface testing:
The testing of the user interface (UI) to ensure that it follows accepted UI standards and meets the
requirements defined for it. Often referred to as graphical user interface (GUI) testing.
White-box testing:
Testing to verify that specific lines of code work as defined. Also referred to as clear-box testing.
 10. Outline the object oriented testing strategies. (N/D 2019)
 While there are efforts underway to develop more automated testing processes from test
models of the object model characteristics (for example states, data flows, or associations), testing is
still based on the creation of test cases and test data by team members using a structural (White Box
Testing) and/or a functional (SeeBlack Box Testing) strategy.
Overview of Object Orientated Unit Testing-Implications of Object Oriented Testing
 Once a class is testing thoroughly it can be reused without being unit tested again UML class state
charts can help with selection of test cases for classes Classes easily mirror units in traditional
software testing
 Objective of OO is to facilitate easy code reuse in the form of classes .
 To allow this each class has to be rigorously unit tested due to classes potentially used in
unforeseeable ways when composed in new systems
Example: A XML parser for a web browser
Classes must be created in a way promoting loose coupling and strong cohesion
CLASS TESTING:
 Class testing is testing that ensures a class and its instances (objects) perform as defined. (Source:
Object Testing Patterns).When designing a society of classes, an excellent goal is to structure classes
so they can be tested with a minimum of fuss.
 After all, a class that requires compiling the application, starting the application, logging into the
application, navigating to a particular point in the application ...will likely not get rigorously tested.
 In computer programming, unit testing is a software testing method by which individual units of
source code, sets of one or more computer program modules together with associated control data,
usage procedures, and operating procedures, are tested to determine whether they are fit for use.
 Intuitively, one can view a unit as the smallest testable part of an application. In procedural
 programming, a unit could be an entire module, but it is more commonly an individual function or
procedure.
 In object-oriented programming, a unit is often an entire interface, such as a class, but could
 be an individual method.
 Unit tests are short code fragments created by programmers or occasionally by white box testers
during the development process. It forms the basis for component testing. Ideally, each test case is
independent from the others.
 Substitutes such as method stubs, mock objects, and test harnesses can be used to assist testing a
module in isolation. Unit tests are typically written and run by software developers to ensure that
code meets its design and behaves as intended.
OO INTEGRATION TESTING:
Research confirms that testing methods proposed for procedural approach are not adequate for OO
approach.
Ex. Statement coverage
OO software testing poses additional problems due to the distinguishing characteristics of OO.
Ex. Inheritance
Testing time for OO software found to be increased compared to testing procedural software.
Typical OO software characteristics that impact testing
 State dependent behavior
 Encapsulation
 Inheritance
 Polymorphism and dynamic
 Binding
 Abstract and generic classes
 Exception handling
 Procedural software
unit = single program, function, or procedure Object oriented
software unit = class
unit testing =intra-class testing
integration testing = inter-class testing
cluster of classes dealing with single methods separately is usually too expensive (complex
scaffolding), so methods are usually tested in the context of the class they belong to.
 The process of testing object oriented systems begins with a review of the object-oriented analysis
and design models.
 Once the code is written object-oriented testing (OOT) begins by testing "in the small" with class
testing (class operations and collaborations).
 As classes are integrated to become subsystems class collaboration problems are investigated.
 Finally, use-cases from the OOA model are used to uncover software validation errors.
 OOT similar to testing conventional software in that test cases are developed to exercise the
 classes , their collaborations, and behavior.
 OOT differs from conventional software testing in that more emphasis is placed assessing the
 completeness and consistency of the OOA and OOD models as they are built.
 OOT tends to focus more on integration problems than on unit testing.
Object-Oriented Testing Activities
 Review OOA and OOD models
 Class testing after code is written
 Integration testing within subsystems
 Integration testing as subsystems are added to the system
 Validation testing based on OOA use-cases
Testing OOA and OOD Models
OOA and OOD cannot be tested but can review the correctness and consistency.
Correctness of OOA and OOD models Syntactic Semantic judged by ensuring that proper modeling
conventions and symbolism have been used based on the model's conformance to the real world
problem
Consistency of OOA and OOD Models
 Assess the class-responsibility-collaborator (CRC) model and object-relationship diagram review
system design (examine the object-behavior model to check mapping of system behavior to
subsystems, review concurrency and task allocation, use use-case scenarios to exercise user interface
design).
 Test object model against the object relationship network to ensure that all design object contain
necessary attributes and operations needed to implement the collaborations defined for each CRC
card
 Review detailed specifications of algorithms used to implement operations using conventional
inspection techniques.
Object-Oriented Testing Strategies
‰ Unit testing in the OO context
 Smallest testable unit is the encapsulated class or object
 Similar to system testing of conventional software
 Do not test operations in isolation from one another
 Driven by class operations and state behavior, not algorithmic detail and data flow
 across module interface
Complete test coverage of a class involves
-Testing all operations associated with an object
 - Setting and interrogating all object attributes
- Exercising the object in all possible states

Design of test for a class uses a verity of methods:

- fault-based testing
- random testing
- partition testing
each of these methods exercises the operations encapsulated by the class test sequences are designed
to ensure that relevant operations are exercised state of the class (the values of its attributes) is
examined to determine if errors exist.
‰ Integration testing in the OO context
o It focuses on groups of classes that collaborate or communicate in some manner integration of
operations one at a time into classes is often meaningless.
o thread-based testing (testing all classes required to respond to one system input or event)
o use-based testing (begins by testing independent classes first and the dependent classes that make use
of them)
o cluster testing (groups of collaborating classes are tested for interaction errors)
o Regression testing is important as each thread, cluster, or subsystem is added to the system levels of
integration are less distinct in object-oriented systems.
‰ Validation testing in the OO context
 focuses on visible user actions and user recognizable outputs from the system
 validation tests are based on the use-case scenarios, the object-behavior model, and the event flow
diagram created in the OOA model
 Conventional black-box testing methods can be used to drive the validation tests.

11. Describe in detail the Test Case Design for OO Software.(N/D 2019)
 Each test case should be uniquely identified and be explicitly associated with a class to be tested
 State the purpose of each test
 List the testing steps for each test including:
 list of states to test for each object involved in the test
 list of messages and operations to exercised as a consequence of the test
 list of exceptions that may occur as the object is tested
 list of external conditions needed to be changed for the test
 supplementary information required to understand or implement the test

‰ Testing Surface Structure and Deep Structure

 Testing surface structure (exercising the structure observable by end-user, this often involves
observing and interviewing users as they manipulate system objects)
 Testing deep structure (exercising internal program structure - the dependencies, behaviors, and
communications mechanisms established as part of the system and object design)

‰ Testing Methods Applicable at The Class Level

Random testing
- requires large numbers data permutations and combinations, and can be inefficient
 Identify operations applicable to a class
 Define constraints on their use
 Identify a minimum test sequence
 Generate a variety of random test sequences.
Partition testing
 - reduces the number of test cases required to test a class
 state-based partitioning - tests designed in way so that operations that cause state changes are tested
separately from those that do not.
 attribute-based partitioning - for each class attribute, operations are classified according to those that
use the attribute, those that modify the attribute, and those that do not us or modify the attribute
 category-based partitioning - operations are categorized according to the function they perform:
initialization, computation, query, termination
‰ Fault-based testing
 best reserved for operations and the class level uses the inheritance structure.
 tester examines the OOA model and hypothesizes a set of plausible defects that may be encountered
in operation calls and message connections and builds appropriate test cases
 misses incorrect specification and errors in subsystem interactions
‰ Inter-Class Test Case Design
Test case design becomes more complicated as integration of the OO system begins – testing of
collaboration between classes
Multiple class testing
 for each client class use the list of class operators to generate random test sequences that send
messages to other server classes
 for each message generated determine the collaborator class and the corresponding server object
operator
 for each server class operator (invoked by a client object message) determine the message it
transmits
 for each message, determine the next level of operators that are invoked and incorporate them into
the test sequence
Tests derived from behavior models
 Use the state transition diagram (STD) as a model that represent the dynamic behavior of a class. test
cases must cover all states in the STD
 breadth first traversal of the state model can be used (test one transition at a time and only make use
of previously tested transitions when testing a new transition)
 test cases can also be derived to ensure that all behaviors for the class have been adequately
exercised
‰ Testing Methods Applicable at Inter-Class Level
Cluster Testing
Is concerned with integrating and testing clusters of cooperating objects
Identify clusters using knowledge of the operation of objects and the system features that
are implemented by these clusters
x Approaches to Cluster Testing
o Use-case or scenario testing
ƒ Testing is based on a user interactions with the system
ƒ Has the advantage that it tests system features as experienced by users
o Thread testing – tests the systems response to events as processing threads through
the system
o Object interaction testing – tests sequences of object interactions that stop when
an object operation does not call on services from another object
Use Case
Scenario-based Testing
x Based on
o use cases
o corresponding sequence diagrams
x Identify scenarios from use-cases and supplement these with interaction diagrams that show
 the objects involved in the scenario
x Concentrates on (functional)
requirements o Every use case
o Every fully expanded extension (<<extend>>) combination
o Every fully expanded uses (<<uses>>) combination
o Tests normal as well as exceptional behavior
x A scenario is a path through sequence diagram
x Many different scenarios may be associated with a sequence diagram
x using the user tasks described in the use-cases and building the test cases from the tasks
and their variants
x uncovers errors that occur when any actor interacts with the OO software
x concentrates on what the use does, not what the product does
x you can get a higher return on your effort by spending more time on reviewing the use cases
as they are created, than spending more time on use-case testing
‰ OO Test Design Issues
 White-box testing methods can be applied to testing the code used to implement class operations,
but not much else
 Black-box testing methods are appropriate for testing OO systems
Object-oriented programming brings additional testing concerns
 classes may contain operations that are inherited from super classes
 subclasses may contain operations that were redefined rather than inherited
 all classes derived from an previously tested base class need to be thoroughly tested