SKILL DEVELOPMENT LAB LABORATORY 17

EXPT. No. - 7: Implement Test plan document for library application

Aim: To create and understand test plan document for library application

Theory:
The Library Management System is an online application for assisting a librarian in
managing a book library in a University. The system would provide basic set of features to
add/update clients, add/update books, search for books, and manage check-in / checkout
processes. Our test group tested the system based on the requirement specification.
This test report is the result for testing in the LMS. It mainly focuses on two problems:

1. What we will test?

2. How we will test?

Result :-

GUI test pass criteria:

Librarians could use this GUI to interface with the backend library database without any
difficulties.

Database Test Pass Criteria: Results of all basic and advanced operations are normal.

Basic function test :-

1. Add a student pass criteria:

• Each customer/student should have following attributes: Student ID/SSN (unique),

Name, Address and Phone number.

• The retrieved customer information by viewing customer detail should contain

the fourattributes.

2. Update/delete student pass criteria:

• The record would be selected using the student ID.

• Updates can be made on full. Items only: Name, Address, Phone number.

• The record can be deleted if there are no books issued by user.

• The updated values would be reflected if the same customer's ID/SSN is called for.

• If customer were deleted, it would not appear in further search queries.

3. Add a book pass criteria:

• Each book shall have following attributes: Call Number, ISBN, Title, Author name.

• The retrieved book information should contain the four attributes.

CHAMELI DEVI GROUP OF INSTITUTIONS, INDORE DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING
SKILL DEVELOPMENT LAB LABORATORY 18
4. Update/delete book pass criteria:

• The book item can be retrieved using the call number.

• The data items which can be updated are: ISBN, Title, Author name

• The book can be deleted only if no user has issued it.

• The updated values would be reflected if the same call number is called.

• If book were deleted, it would not appear in further search queries.

5. Search for book pass criteria:

• The product shall let Librarian query books,detail information by their ISBN number
or Author or Title.

• The search results would produce a list of books, which match the search
parameters with following details: Call number, ISBN number, Title, Author.

• The display would also provide the number of copies which is available for issue.

• The display shall provide a means to select one or more rows to a user-list

• A detailed view of each book should provide information about check-in/check

out status, withthe borrower’s information.
• The search display will be restricted to 20 results per page and there would
be means tonavigate from sets of search results.
• The user can perform multiple searches before finally selecting a set of books
for check in orcheckout. These should be stored across searches.

6. A book may have more than one copy. Check-in book pass criteria :
• Librarians can check in a book using its call number.
• The check-in can be initiated from a previous search operation where user has
selected a set of books.
• The return date would automatically reflect the current system date.
• Any late fees would be computed as difference between due date and return date
at rate of 10 Rs a day.
• A book, which has been checked in once, should not be checked in again.

7. Check-out book pass criteria :

• Librarians can check out a book using its call number.
• The checkout can be initiated from a previous search operation where user has

CHAMELI DEVI GROUP OF INSTITUTIONS, INDORE DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING
SKILL DEVELOPMENT LAB LABORATORY 19
selected a set of books.
• The student ID who is issuing the book would be entered.
• The issue date would automatically reflect the current system date.
• The due date would automatically be stamped as 5 days from current date.
• A book, which has been checked out once, should not be checked out again.
• A student who has books due should not be allowed to check out any books.
• The max. No of books that can be issued to a customer would be 10. The system
should not allow checkout of books beyond this limit.

8. View book detail pass criteria :

• This view would display details about a selected book from search operation.
• The details to be displayed are: Call number, IBN, Title, Author, Issue status (In
library or checked out), If book is checked out it would display, User ID & name,
checkout date, due date.
• Books checked in should not display user summary.
• Books checked out should display correct user details.

9. View student detail pass criteria :

• Librarians can select a user record for detailed view.
• The detail view should show: User name, ID, Address & Phone number.
• The books issued by user with issue date, due date, call number, title.
• Late fees & Fines summary and total.
• The display should match existing user profile.
• The books checked out should have their statuses marked.
• The book search query should show the user id correctly.

10. Network test pass criteria:

• Results of operations (ping, ftp and ODBC connectivity check) are normal .

Viva questions :-
1. How to create a test plan document for Library Management System?
2. What is object repository?
3. Define test Plan.
4. What is test strategy?
5. Differentiate between Master Test Plan and Test Plan.
CHAMELI DEVI GROUP OF INSTITUTIONS, INDORE DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING
SKILL DEVELOPMENT LAB LABORATORY 20
EXPT. No. - 8: . Study of Any Testing Tool( WinRunner)

Aim: To study WinRunner testing tool

Theory:
WinRunner is a program that is responsible for the automated testing of software.
WinRunner is a Mercury Interactive enterprise functional testing tool for Microsoft
windows applications.

Testing an Application using WinRunner

After installing the WinRunner on your computer, invoke the WinRunner application:

• Start -> Programs ->WinRunner ->WinRunner

The opening screen of the WinRunner application is displayed, prompting you to select one
of the three options:
1. New Test: To create a new test script.

2. Open Test: To open an existing test script.

3. Quick Preview: To view the quick preview of WinRunner

Recording Test Cases :

There are two modes of recording:
1. Context Sensitive Mode : This mode of recording is used when the location of the GUI
controls (i.e.X and Y coordinates) or the mouse positions are not necessary.
2. Analog Mode : This mode of recording is used when the mouse positions, the location
of the controls in the application, also play an important role in testing the application.
This mode of recording has to be used to validate bitmaps, testing the signature etc.
The procedure for recording a test case is as follows:
• Step 1 :Open a new document: File -> New (or) Select "New Test" from the
WinRunner'sWelcome screen.
• Step 2 : Open (run) the application to be tested.
• Step 3 : Start recording a test case.
Create ->Record - Context Sensitive
• Step 4 : Select the application to be tested by clicking on the application's title bar.
• Step 5 : Perform all the actions to be recorded.
• Step 6 : Once all required actions are recorded, stop the recording.Create -> Stop

CHAMELI DEVI GROUP OF INSTITUTIONS, INDORE DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING
SKILL DEVELOPMENT LAB LABORATORY 21
There are two modes for generating the test cases:
1.Global GUI map file mode
2.GUI map file per test mode
By default, it is in "Global GUI map file mode". In Global GUI map file mode, you have to
explicitly save the information learnt by WinRunner. WinRunner saves it in a file with
extension "gui". When you have to run a test, you need to load the corresponding GUI
map file; otherwise it will not be able to recognize the objects in the test case and displays
an error message
The procedure for saving the GUI map file in Global GUI map file mode is as follows:Step
1: Record a test case by following the preceding procedure.
Step 2: Open the GUI Map Editor window.
Step 3: On selecting the GUI Map Editor. The screen as shown in Fig 4.1.
Step 4: Save the GUI Map file. File -> Save As A File dialog appears and you need to enter
the filename.
Step 5: Close the GUI Map Editor window.

Figure 8.1: GUI Map Editor

The procedure for loading the GUI map file is as follows:
Step 1: Open the GUI Map Editor. Tools -> GUI Map Editor
Step 2: Close all the opened GUI Map files File -> Close all
The procedure for running a test case is as follows :
Step 1: Open the test script to be executed.
Step 2: Run the test Run -> Run from top (or) press F5 to run the test.
WinRunner executes the generated script and displays the results in the Test Results
window.
CHAMELI DEVI GROUP OF INSTITUTIONS, INDORE DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING
SKILL DEVELOPMENT LAB LABORATORY 22
Viva questions :-
1. Explain WinRunner testing process.
2. Explain the different types of modes in which user can run test scripts in WinRunner.
3. How does WinRunner evaluate test results?
4. What is the use of GUI map?
5. What happens when GUI map file get loaded?

CHAMELI DEVI GROUP OF INSTITUTIONS, INDORE DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING
SKILL DEVELOPMENT LAB LABORATORY 23
EXPT. No. - 9: Draw the use case diagram for Automatic Teller Machine (ATM)
Aim: To understand the concept of Use Case Diagram
Theory:
A use case diagram establishes the capability of the system as a whole. Components of use
case diagram are Actor, Use case, System boundary, Relationship and Actor relationship.
Process for Use case diagram are as follows: -
1.Introduction: Describe a quick background of the use case.
2.Actors: List the actors that interact and participate in the use case.
3.Pre-Conditions: Pre-conditions that need to be satisfied for the use case to perform.
4.Post Conditions: Define the different states in which we expect the system to be in,
after the use case executes.
5.Flow of events:
i.Basic Flow: List the primary events that will occur when this use case is executed.
ii.Alternative Flows: Any Subsidiary events that can occur in the use case should be
separately listed. List each such event as an alternative flow. A use case can have
many alternative flows as required.
6.Special Requirements: Business rules should be listed for basic & information flows as
special requirements in the use case narration. These rules will also be used for
writing test cases. Both success and failures scenario should be described.
Components of Use case diagram: -
1. Actor: -The users that interact with a system. An actor can be a person, an
organization, or an outside system that interacts with your application or system.
They must be external objects that produce or consume data.

Figure 9.1: Actor

2. Use case: - The use cases, which the specific roles are played by the actors within
and aroundthe system.

Figure 9.2: Use case

CHAMELI DEVI GROUP OF INSTITUTIONS, INDORE DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING
SKILL DEVELOPMENT LAB LABORATORY 24
3. System Boundary: - The boundary, which defines the system of interest in
relation to the worldaround it.

Figure 9.3: Boundary

4. Relationship: - The relationships between and among the actors and the use cases.

i. Association: - An association is a relationship between two classifiers,

such as classes oruse cases that describes the reasons for the relationship
and the rules that govern the relationship.

Figure 9.4: Association

ii. Include Relation: - An include relationship is a relationship in which one

use case (the base use case) includes the functionality of another use case
(the inclusion use case). The include relationship supports the reuse of
functionality in a use-case model.

Figure 9.5: Include

iii. Extend Relation: - An extend relationship to specify that one use case
(extension) extends the behavior of another use case (base). This type of
relationship reveals details about a system or application that are typically
hidden in a use case.

Figure 9.6: Extend

Withdrawal Transaction Use Case

1.Introduction: A withdrawal transaction asks the customer to choose a type of account to
withdraw form. The system verifies that it has sufficient money on hand to satisfy the
request before sending the transaction to the bank.
2.Primary Actor: Customer

CHAMELI DEVI GROUP OF INSTITUTIONS, INDORE DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING
SKILL DEVELOPMENT LAB LABORATORY 25
3.Pre-conditions: The customer must have a valid ATM card and PIN.
4.Post-conditions: The customer receives the cash amount that he wanted to withdraw,
with a receipt, if indicated. The customer’s account balance is updated in the system.
5.Normal flow of events:
i.The customer inserts an ATM card into the ATM machine and enters the PIN.
ii.The system validates the ATM card and PIN.
iii.The customer selects the “Cash Withdrawal‟ option from the Options Menu.
iv.The system prompts the customer to enter the amount of cash that he or she wants
to withdraw.
v.The customer enters a cash amount and selects the “Submit‟ option on the Cash
Withdrawal Screen.
vi.The system validates the amount entered, checks account balance and that the
machine has enough cash for the transaction and asks the customer if he or she wants
a receipt for the transaction.
vii.The customer selects “Yes‟ on the Receipt Screen.
viii.The system ejects the ATM card, provides the cash, prints the receipt and updates
the account balance of the customer in the system.
6. Alternate flow of events:
i.The customer has entered an invalid PIN- The system prompts the customer to enter a
valid PIN.
ii.If ATM card is not compatible-The system rejects the ATM card and displays an error
message.
iii.The customer has entered an amount that exceeds the withdrawal limit.
iv.The system rejects the transaction & displays an error message.

Viva Questions:-
1. Explain the main components of use-case diagram.
2. What is the use of system boundary in use case diagram?
3. Give an example of “extend relation” case in use case diagram.
4. What are the advantages of use case diagram?
5. Explain various types of relationship used in use case diagram.
CHAMELI DEVI GROUP OF INSTITUTIONS, INDORE DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING
SKILL DEVELOPMENT LAB LABORATORY 26
EXPT. No. - 10: Case study of different software process models

Aim: To understand concept of different software process models

Theory: A process model can be defined as a method, tool or steps for developing
software. The goal of a software process model is to provide guidance for systematically
coordinating and controlling the tasks that must be performed in order to achieve the end
product and their project objectives.

A process model is chosen based on the nature of the project and application, the
methods and toolsto be used and the controls, deliverables that are required.

A few software process models are defined as follows:

1. Waterfall Model (Linear Sequential Model)
2. Incremental Process Model
3. Prototyping Model
4. Agile Model

1. Waterfall Model (Linear Sequential Model): - Also called the classic life cycle or
the waterfall model, the linear sequential model suggests a systematic, sequential
approach to software development that begins at the system level and progresses
through analysis, design, coding, testing and maintenance. This model can be used
when the requirements are very clear and fixed and the technology is well
understood.

Figure 10.1: Waterfall model

CHAMELI DEVI GROUP OF INSTITUTIONS, INDORE DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING
SKILL DEVELOPMENT LAB LABORATORY 27
2. Incremental Model: - There are many situations in which initial software
requirements are reasonably well defined, but the overall scope of the
development effort prevent a purely linear process. The incremental model
combines elements of linear and parallel process flows. This model applies linear
sequence in an iterative manner. Initially core working product is delivered. Each
linear sequence produces deliverable “increments” of the software. This model
can be used when the requirements of the complete system are clearly defined.

Figure 10.2: Incremental model

3. Prototype Model: - Prototype can be served as “the first system”. Both

stakeholders and software engineers like prototyping model. Users get feel for the
actual system and the developers get to build something immediately. When
requirements are not properly cleared or when the client doesn’t know the exact
requirement then prototype model can be applied.

Figure 10.3: Prototype model

CHAMELI DEVI GROUP OF INSTITUTIONS, INDORE DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING
SKILL DEVELOPMENT LAB LABORATORY 28
4. Agile Model: - The word ‘agile’ means able to think quickly and clearly. In business,
‘agile’ is used for describing ways of planning and doing work where in it is
understood that making changes as needed is an important part of the job. The
Agile development model is also a type of Incremental model. Software is
developed in incremental, rapid cycles. This results in small incremental releases
with each release building on previous functionality. Each release is thoroughly
tested to ensure software quality is maintained. It is used for time critical
applications. Extreme Programming (XP) is currently one of the most well-known agile
development life cycle models. When new changes are needed to be implemented this
modelis used.

Figure 10.4: Agile model

Viva Questions:-
1. Explain the applications of waterfall model.
2. Under what condition incremental model is best suited model?
3. What is the aim of prototyping?
4. Explain advantages of agile model.
5. Why requirement gathering is most important part in software development process?
CHAMELI DEVI GROUP OF INSTITUTIONS, INDORE DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING