LTKK

Lappeenranta University of Technology

Department of Information Technology
Laboratory of Information Processing

Testing document
Library Management Program

Authors:

Kalenova Diana
Korotkaya Zhanna
Kramarenko Sergey
Kornev Vladimir
Krestyannikov Evgeny

Supervisors:

Yana Selioukova
Jan Voracek

Lappeenranta, Finland
2002

Table of Content:
1.

Introduction ......................................................................................................... 3

2.

Purpose ............................................................................................................... 3

3.

Scope .................................................................................................................. 4

4.

References........................................................................................................... 4

5.

Document overview .............................................................................................. 4

6.

Software Testing Strategies ................................................................................... 5

a.
b.
c.
d.

7.

Unit testing. .............................................................................................................................. 5

Integration testing..................................................................................................................... 5
Validation testing...................................................................................................................... 5
System testing........................................................................................................................... 6
Test items............................................................................................................ 7

8.

Test 1 ............................................................................................................................................ 8
Test 2 .......................................................................................................................................... 11
Test 3 .......................................................................................................................................... 12
Test 4 .......................................................................................................................................... 12
Features to be tested.......................................................................................... 13

9.

Features not to be tested .................................................................................... 13

10.

Items pass/fail criteria ..................................................................................... 13

11.

Responsibilities ............................................................................................... 13

12.

Test Plan Document Outline ............................................................................. 14

13.

Acknowledgements.......................................................................................... 15

14.

Literature ....................................................................................................... 16

1. Introduction
This paper is description of the company strategy in testing field. Systematic and comprehensive
testing is fundament for making high quality software. You can find testing strategies, testing
methods and test cases, validation and verification, overall consistency between requirements
and current product of the team. Document contain real set of the tests, which will apply for
testing the Library Management System. The need in testing explain in next quotation:
The development of software systems involves a series of production activities where
opportunities for injection of human fallibilities are enormous. Errors may begin to occur at the
very inception of the process where the objectives may be erroneously or imperfectly
specified, as well as [in] later design and development stages Because of human inability to
perform and communicate with perfection, software development is accompanied by a quality
assurance activity.[1]

2. Purpose
The main goals of the test plan are to describe time and pats of the testing process, which contain
an approach to testing, testing methods, tasks and deliverables. Also, here will be describing
individual responsibilities (the testing logistics, resource requirements you can find in
Requirements documentation).
This part of paper contains goals of the test plan and its implementation. You can find different
types of testing.
The goals of the testing are showed below:
Demonstrate real testing functions of the program product
Explain level of the quality each function
Check requirements for the purposes of management approval.
Provide a baseline for test group performance measurement.
Provide criteria against which the customer will formally accept the product
The Test Plan can apply for conduct acceptance testing and system
[http://www.cc.gatech.edu/classes/cs3302a_99_winter/projects/testing.html] 25.04.2002

3. Scope
The scopes of this project are described by the Requirements documentation, budget, and time
limitation.

4. References
Pressman, R, Software Engineering: A Practitioners Approach, McGraw-Hill, 2001.
Templates for testing http://www.tuffley.aust.com/tcs20003.htm
Testing and quality http://www.softwareqatest.com/
Sample projects www.cc.gatech.edu/classes/cs3302a_99_winter/grouplist.html
Package of related templates
www.cc.gatech.edu/classes/cs3302a_99_winter/projects/milestones.html
Implementation Plan Instructions http://www.it.lut.fi/opetus/0102/010758001/ip.html

5. Document overview
Paper contain next parts:
Approach is point of view, which will be applied for testing
Test items are description of the functions.
Features to be tested are features of the functions of the software, which will be tested
Features not to be tested are features of the functions of the software, which will not be tested
Also you can find in this document next information:
Test activities
Test coverage
Items pass/fail criteria
Responsibilities

6. Software Testing Strategies

There are a lot of testing strategies. These are four groups of activities:

Unit testing

Integration testing

Validation testing

System testing

Below I describe all these activities.[1]

a. Unit testing.
Focuses unit testing is verification of the smallest units of software design the module. We test
next units of project:

interface each module It examination of the interaction between modules

local data structures It is checking for correspond to specification.

boundary conditions are tested that modules work correctly just as in the requirements

independent paths is examination each path of the module

Usually unit test is white-box oriented. It is making parallel for multiple modules.

b. Integration testing.
Integration testing is a systematic technique for construction the program structure.
The software consists of the several modules performing various actions (data insertion, report
generating, etc). We must to control modules activity.
Usually black-box testing techniques are applied in this stage. We can divide integration tests on
few. [1]

Top-down Integration is incremental approach to making program structure (from large

to small).

Bottom-up Integration It is started from small units to big.

Regression testing

c. Validation testing.
5

Main question of validation testing is Are we making product right? Answer receives after
series black-box tests, and then we can see conformity with requirements to all functional,
behavioral, and performance accordance to specification. The basic document for developing
test cases is Requirements documentation. There are alpha and beta tests. Performance series of
alpha and beta tests emulate natural customer. [1]

d. System testing.
System testing is actually a series of different tests, which test all computer-based system.
These include tests with integration of time accounting software, company project base system.
Each test has special purpose, all work to verify that all system elements have been properly
integrated and perform allocated functions. [1]
These Testing Strategies were applied to library system and showed good practical results. The
results were errors, which were fond in sours code and high quality of end product.

7. Test items
For more depicting I show figure, which describe our system

Test 1
Purpose
Purposes of this test to check capacity for work the interfaces of the user (for student, teacher
and Department) and librarian interface.
Test description
This case is user test. Tester will execute it after design user interfaces with according
timetable. Test includes corresponding user interfaces to Requirements documentation
Design specifications document
Test will perform 100 times for finding bugs and errors. It check capacity for work each
function and button in scenarios:
Scenario 1: Logging into the system
Each user has Users ID and password. When user (student, teacher, Department or different
kind of users) enters the system he receives the screen prompting to enter login and
password. In the case of incorrect this information system asks to reenter this information.
Scenario 2: Search using Database
One of the functions, LLS offers the search in Database. Different search types:
Title, Author, Keywords, Printing year etc. User selects search type and input search string
with additional possibilities of searching as a separate words, case sensitive, full string etc.
The user can select number of records per page, ordering data by alphabet, keywords
relevance, availability, year of printing etc.
Scenario 3: Lending of the book
This kind of functions the LLS can be established only in the case of personal presence in
our library. User ID (student card, badge etc) serves for identification of the user in the
database. After successful authorization of the user the librarian chooses the lend option
8

and inputs librarian item ID into the database. According to the item priority and users
status this item can be given for the particular period of time. After books lending the some
changes appear in the database:
The books status changes to charged.
In the borrowed items field appears the ID item.
Date of returning of this book appeared in the date of returning field.
Scenario 4: Renewing of the book
This kind of functions can be established as through personal presence in the library as using
web and WAP interfaces. For this user should logging into the system after this he can
choose the item(s) to be renewed and try to do it by pressing renew button.
The case of web and WAP interfaces, the following scheme is presented:
If the item(s) are not ordered the description about renewing will be appeared in the status
field the due date will change.
If the item(s) are ordered, not renewed will appear in the status field and due date will not
change.
In the case of personal presence the actions are almost the same, but it performed by the
librarian.
Scenario 5: Place an order
In the case of absence of required item in the library, the user can leave an order for it. The
function for ordering can be established as through personal presence in the library as using
web interface. In both cases, after successful authorization, user can fill in special ordering
form his needs. After order, the system selects the book, which will be returned sooner, and
mark it somehow that this book is ordered by user. If book is become available this user will
be notified in the way, which he has selected: email, sms, ordering mail.
Scenario 6: Returning the book

This kind of possibilities of the LLS can be performed only through personal presence in the
library. The user should only bring the item into the library. Further actions are performed by
the librarian, who selects returning button in the database and inputs ID of the returned
item. After these actions, the status of this item is changed to not charge and is deleted
from the users given items.
Scenario 7: Modification the database by the librarian
The librarians perform modification of the librarian database. Here there are several
situations. Let us consider its one-by-one.
Maintenance of the users database.
It can be done only by personal presence in the library.
For registering the user should have a personal ID. He fills an application form, and receives
a password and login for a logging into the system. The information from the application
form is inserted into the database by the librarian through the special options, which are
available only for staff.
In the case of change of some users details (as changing of the last name, e-mail, ordering
address, phone number, users status etc) he should fill the application form again with the
modified information.
The situation of deleting the user also is possible. It can be provided in according to the
users requirement by the librarian in the case of absence any items on users account. For
this purpose there is a special option in the system. Only the librarians and administrators
have rights for it.
Maintenance of the library items database
The procedures of the lending and renewing the librarian items were described above (see
4.3 and 4.4 in Requirements document).
The procedure of adding the new library item is available also. For this purpose the
catalogue card should be filled by the librarian and input into the library system.
The situation of deleting library item(s) can arise, for example:
Lost of the book
Contents of the item(s) is deemed to be out of data and no historical value
Impossibility for using the item due to the technical or physical conditions
10

For realization the deleting procedure there is a special option in the system. Only the
librarians and administrators have rights for it.
Librarians and administrators could provide the case of changing the priority of different
library items. It can be done, for example, in the case of loss one of two available copies of
item.
Scenario 8: Overdue item
In accordance to the customer requirements, our system should automatically generate
notifications to user, who did not return the item in time, by e-mail or sms and if book is still
not returned, another one notification will send to this user next day.
The lending period of library items is defined by the priority of this item and status of user. It
can be from 1 day to 4 weeks.
If the item is not returned during 2 weeks after the first notification the letter to the Financial
Department is sent.
Results
Results of performing this test are finding bugs errors, notification and transmission their
to designer for correction.
Test 2
Purpose
Purposes of this test to check capacity for work the database
Test description
In this subsection check work of the database:
Maintenance database, which must correspond Requirements documentation
Design specifications document
Performing functions of the database add, delete, searching, lending, ordering, and
renewing and other (according with Requirements documentation and Design
specifications document)
11

Case of the incorrect input

Volume of the database
Tester executes test according with timetable.
Results
Results of performing this test are finding bugs errors, notification and transmission their to
designer for correction.

Test 3
Purpose
Test of the Hardware and Software.
Test description
This test must show ability to work correctly with hardware and software, which described in
Requirements documentation for each person (user, librarian, server and other). Tester
executes test according with timetable. It is executed by performing previews tests 10 times
on corresponding hardware and software.
Results
Results of performing this test are finding bugs errors, notification and transmission their to
designer for correction.

Test 4
Purpose
Test of the guideline.
Test description

12

Goal of this test understand level of the friendly of the user interfaces. Test executes by 100
users (student, teacher and Department) according with timetable.
Results
Results of performing this test are finding bugs errors, notification and transmission their to
designer for correction.
Conclusion after executed test: all tests were applied to the library systems, some errors
were found. The errors were passed to designer and corrected.

8. Features to be tested
These are all features which described in Requirements documentation and
Design specifications document.

9. Features not to be tested

These are: color set of the user interfaces

10.

Items pass/fail criteria

The criteria for items pass are corresponding each item to Requirements documentation and
Design specifications document, working without errors. This state of the program to satisfy
all persons (customer, user, librarian and tester).
The fail criteria are opposite to criteria of the passing.

11.

Responsibilities

Responsibilities of the tester

13

testing strategies and document,

design of testing methods and test cases
Validation and verification, overall consistency between requirements and current
product of the team.
Accordance with these requirements to tester were performed

12.

Test Plan Document Outline

You can find Test Plan Document Outline below:

This plan shows that work of the tester is very long. Time was spend for checking documents own
company and documents of the ITL (Innovative Technologies Laboratories).

14

13.

Acknowledgements

Our team would like to thank Jan Voracek and Yana Selioukova for their help with this project,
materials provided and their supervision.
We would also like to acknowledge the help of our customers team during the development stage.
We shared a lot of ideas; this was a team work, but rather a mutual understanding approach.
Also, we would like to mention Diana Kolenova who always supported and inspired us in this work.

15

14.

Literature

1. Pressman, R. S.: Software Engineering, A Practitioner's Approach (European adaptation,

fifth edition). McGraw Hill, 2000.
2. Project Plan of this project, which available on the Home Page of Project:
http://www.lut.fi/~krestyan/swe.htm [cited 15.04.2002]
3. Software Engineering Homepage
http://www.it.lut.fi/opetus/01-02/010758001/
4. Volere Requirements Specification Template, Suzanne Robertson and James Robertson, The
Atlantic Systems Guild http://atlsysguild.com/GuildSite/Robs/Template.html
5. Structuring Use Cases with Goals, Alistair Cockburn,
http://members.aol.com/acockburn/papers/usecases.htm
6. Sommerville, Ian, Pete Sawyer, and Stephen Viller (1998), Viewpoints for requirements
elicitation: a practical approach, in Proceedings of the IEEE International Conference on
Requirements Engineering - ICRE'98, April 6-10, 1998, Colorado Springs, Colorado.
http://www.comp.lancs.ac.uk/computing/research/cseg/projects/reaims/publications.html

16