Testing Document Faculty of Engineering Science Software ...

24
Testing Document Faculty of Engineering Science Software Engineering Program Fourth Year Engineering Project Call Accounting System May 21, 2006 1

Transcript of Testing Document Faculty of Engineering Science Software ...

Page 1: Testing Document Faculty of Engineering Science Software ...

Testing Document

Faculty of Engineering Science

Software Engineering Program

Fourth Year Engineering Project

Call Accounting System

May 21, 2006

1

Page 2: Testing Document Faculty of Engineering Science Software ...

ADD

Students Names:

Name: Anna Bakshi id: 323716399

Email: [email protected] Mobile: +972(54)4317729

Signature: ————————-

Name: Leonid Leontiev id: 314007188

Email: [email protected] Mobile: +972(54)4323356

Signature: ————————-

2

Page 3: Testing Document Faculty of Engineering Science Software ...

ADD

Company: Solan Telecom

Domain: Telecom Billing Solution

Address: Nir-Zvi, e.b 53, Zrifin 72905

Project Technical Advisor:

Name: Shimon Elazari

Position: Development director

Email: [email protected]

Cellular: +972(52)4310810

Signature: ————————-

Date: —-/—-/—-

Project Academic Advisor:

Name: Dr. Mayer Goldberg

Email: [email protected]

Signature: ————————-

Date: —-/—-/—-

Project No. ————————-

3

Page 4: Testing Document Faculty of Engineering Science Software ...

ADD

Remarks:

4

Page 5: Testing Document Faculty of Engineering Science Software ...

CONTENTS ADD

Contents

1 Testing functional requirements 6

2 Testing non-functional requirements 22

3 Test-Driven Development 23

4 Random & automatically-generated tests 23

5 Testing the user interface 24

6 Testing build, integration & deployment 24

5

Page 6: Testing Document Faculty of Engineering Science Software ...

ADD

1 Testing functional requirements

Table 1: System access

Functional Requirement TestLog in

1. Insert correct username and password andsee that system loges in appropriate organi-zation.

2. Insert incorrect username or password andsee that system not logs in.

3. Insert incorrect username and password andsee that system not logs in.

Access mode. Log in with correct username and password andcheck that system operates in correct access mode.

Table 2: Registration

Functional Requirement TestRegistration of new operator.

1. Register new operator.

2. Check that system logs in with usernameand password of new registered operator.

3. Check that permissions after log in are per-missions of operator.

Registration of new client organization.

1. Enter new organization name, username andpassword for administrator of new organiza-tion and codes of switchboards sites of theclient.

2. Log into the system with new defined user-name and password.

3. Check that organization name and switch-boards sites are equals to organization nameand switchboards sites, entered in 1.

6

Page 7: Testing Document Faculty of Engineering Science Software ...

ADD

Functional Requirement TestRegistration of a new user in the organization.

1. Enter the new user information.

2. Select the permissions of new user.

3. Log into the system with username and pass-word of a new user.

4. Check that the user is permitted to do alloperations selected in 2.

5. Check that the user is not permitted to doany operation, that not selected in 2.

Table 3: Definition of client organization

Functional Requirement TestAdding new extension.

1. Define new extension by entering extensioninformation.

2. Check that extension information stored cor-rectly by reloading that information andcomparison with entered information.

3. Check that new extension appear in hierar-chy tree.

Editing extension information.

1. Edit information of existing extension.

2. Check that extension information stored cor-rectly by reloading that information andcomparison with edited information.

3. Check that the position of the extension inhierarchy tree does not changed.

7

Page 8: Testing Document Faculty of Engineering Science Software ...

ADD

Functional Requirement TestDeleting of extension.

1. Delete the extension from the hierarchy tree.

2. Check that extension disappear from the hi-erarchy tree.

3. Check that extension does not appear in thehierarchy tree after reloading.

Grouping under existing administrative unit.

1. Group a number of extensions and / or ad-ministrative units under existing administra-tive unit in the hierarchy tree.

2. Check that hierarchy tree changed appropri-ately.

3. Check that hierarchy tree does not changesafter refresh.

Grouping under new administrative unit.

1. Group a number of extensions and / or ad-ministrative units under new administrativeunit in the hierarchy tree.

2. Check that hierarchy tree changed appropri-ately.

3. Check that new administrative unit informa-tion stored correctly by reloading that infor-mation and comparison with entered infor-mation.

4. Check that hierarchy tree does not changesafter refresh.

Table 4: Projects

Functional Requirement Test

8

Page 9: Testing Document Faculty of Engineering Science Software ...

ADD

Functional Requirement TestAdding new project.

1. Add new project by entering project infor-mation.

2. Check that new project appear in projectslist.

3. Check that new project does not disappearfrom the projects list after reloading.

4. Check that new project information storedcorrectly by reloading that information andcomparison with entered information.

Editing project information.

1. Edit project information.

2. Check that the project still in the projectslist.

3. Check that edited project information storedcorrectly by reloading that information andcomparison with entered information.

Deleting of project.

1. Delete existing project from the projects list.

2. Check that deleted project disappear fromthe projects list.

3. Check that deleted project does not appearin the project list after reloading.

Table 5: Projects

Telecommunication carriers Test

9

Page 10: Testing Document Faculty of Engineering Science Software ...

ADD

Functional Requirement TestAdding new telecommunication carrier.

1. Add new telecommunication carrier by en-tering telecommunication carrier informa-tion.

2. Check that new telecommunication carrierappear in telecommunication carriers list.

3. Check that new telecommunication carrierdoes not disappear from the telecommuni-cation carriers list after reloading.

4. Check that new telecommunication carrierinformation stored correctly by reloadingthat information and comparison with en-tered information.

Editing telecommunication carrier information.

1. Edit telecommunication carrier information.

2. Check that the telecommunication carrierstill in the telecommunication carriers list.

3. Check that edited telecommunication car-rier information stored correctly by reload-ing that information and comparison withentered information.

Deleting of telecommunication carrier.

1. Delete existing telecommunication carrierfrom the telecommunication carriers list.

2. Check that deleted telecommunication car-rier disappear from the telecommunicationcarriers list.

3. Check that deleted telecommunication car-rier does not appear in the telecommunica-tion carriers list after reloading.

Table 6: Trunks

Functional Requirement Test

10

Page 11: Testing Document Faculty of Engineering Science Software ...

ADD

Functional Requirement TestEditing trunk information.

1. Edit trunk information.

2. Check that edited trunk still appear in thetrunks list.

3. Check that edited trunk information storedcorrectly by reloading that information andcomparison with entered information.

4. Check that edited trunk still appear in thetrunks list.

Table 7: Phone Book

Functional Requirement TestAdding new phone number.

1. Add new phone number information (includ-ing phone number subscriber, organizationthat processes this phone number and nameof group to which phone number belongs(Supplier etc.)).

2. Check that phone number informationstored correctly by reloading that informa-tion and comparison with entered informa-tion.

3. Check that new phone number appears inthe phone book.

11

Page 12: Testing Document Faculty of Engineering Science Software ...

ADD

Functional Requirement TestEdit existing phone number.

1. Edit existing phone number information (in-cluding phone number subscriber, organiza-tion that processes this phone number andname of group to which phone number be-longs (Supplier etc.)).

2. Check that phone number informationstored correctly by reloading that informa-tion and comparison with entered informa-tion.

3. Check that edited phone number still ap-pears in the phone book.

Edit existing phone number.

1. Delete existing phone number from thephone book.

2. Check that deleted phone number disappearfrom the phone book.

3. Check that deleted phone number not ap-pear in the phone book after refreshing.

Table 8: Reports

Functional Requirement TestViewing the reports concerning user organizationonly

1. Log in the system as user permitted to viewall organization reports.

2. Check that user available to view all reportsconcerning his organization.

3. Check that user does not available to viewreports, concerning other organizations.

4. Check that in produced reports no items,concerning other organizations.

12

Page 13: Testing Document Faculty of Engineering Science Software ...

ADD

Functional Requirement TestCorrectness of reports.

1. Check that each produced report containsall the fields, described in functional require-ments.

2. Check that each produced report containsonly fields, described in functional require-ments.

3. Check that each report contains all data(with respect to user permissions con-straints) presented in DB.

4. Check that each report contains only data(with respect to user permissions con-straints) presented in DB.

5. Check that in each report the data isgrouped by the group by fields of the report.

Definition of new report.

1. Define a new report.

2. Check that system allows to define all re-port information, as described in functionalrequirements 2.5.3.

3. Check that system allows to define only in-formation described in functional require-ments 2.5.3.

4. Check that systems stores report definitioncorrectly by reloading that information andcomparison with entered information.

5. Check that new report appears in the orga-nization reports list.

6. check that report does not appears in thereport list of other organizations.

13

Page 14: Testing Document Faculty of Engineering Science Software ...

ADD

Functional Requirement TestDefinition of new style.

1. Define a new report style.

2. Check that system allows to define all styleinformation, as described in functional re-quirements 2.5.3.6.

3. Check that system allows to define only in-formation described in functional require-ments 2.5.3.6.

4. Check that systems stores report style defini-tion correctly by reloading that informationand comparison with entered information.

5. Check that new report style appears in theorganization report styles list.

6. check that report style does not appears inthe report styles list of other organizations.

7. check that report style does not appears inthe other organization reports styles lists.

Type of report production.

1. Export report as pdf document and checkthat generated file contains the same data,as report in the screen.

2. Export report as Word document and checkthat generated file contains the same data,as report in the screen.

3. Export report as Excel document and checkthat generated file contains the same data,as report in the screen.

14

Page 15: Testing Document Faculty of Engineering Science Software ...

ADD

Functional Requirement TestScheduling.

1. Apply monthly scheduling on the selectedreport and style. Check that first reportgenerated as defined in scheduler. Advancethe system clock on one month and checkthat additional report generated as definedin scheduling.

2. Apply weekly scheduling on the selected re-port and style. Check that first report gen-erated as defined in scheduler. Advance thesystem clock on one week and check thatadditional report generated as defined inscheduling.

3. Apply daily scheduling on the selected re-port and style. Check that first report gen-erated as defined in scheduler. Advance thesystem clock on one day and check that addi-tional report generated as defined in schedul-ing.

4. Apply hourly scheduling on the selected re-port and style. Check that first report gen-erated as defined in scheduler. Advance thesystem clock on one hour and check thatadditional report generated as defined inscheduling.

Digits mask.

1. Choose organization unit and apply “Maskdigits” option.

2. Check that in report the phone numbers ofchosen organization unit masked.

3. Check that in report the phone numbers ofall other organization units are not masked.

Table 9: Price list definition

Functional Requirement Test

15

Page 16: Testing Document Faculty of Engineering Science Software ...

ADD

Functional Requirement TestTime from which the price list is valid.

1. Define new price list with the time fromwhich the price list is valid.

2. Check that the time from which the price listis valid equals to time defined in 1.

3. Check that there is only one valid price listin the system.

Holidays definition.

1. Define holidays in calendar (definition byadding and removing holidays to / from cal-endar).

2. Check that after reloading the calendar theholidays are equals to defined ones.

Weekends definition.

1. Define the weekends in calendar.

2. Check that the system stores the weekendsby reloading the calendar and comparison ofweekends with defined.

Weekly time table definition.

1. Check that system allows to define morethan one time table by trying to define afew time tables.

2. Check uniqueness of weekly time table nameby trying to define more than one weeklytime table with the same name.

3. Check that periods of times of common tariffdoes not overlap and cover the entire week bytrying to define overlap periods of times ofcommon tariff and truing define the periodsof times of common tariff that all togetherdoes not cover the entire week.

4. Check that defined time tables unavailablefrom other organizations.

16

Page 17: Testing Document Faculty of Engineering Science Software ...

ADD

Functional Requirement TestManaging the list of area codes for phone numbers.

1. Add the new legal area code and check thatthe new code is stored in the system byreloading the list of area codes and compar-ing the area codes in list before and afterreloading.

2. Delete the area code from the list by savinglegacy of the list and check that the systemallows to save modified list.

3. Delete the area code from the list by crashinglegacy of the list and check that the systemdoes not allows to save modified list.

Definition of tariff contract by sequence of timeslots.

1. Check that system allows to define new tariffcontract.

2. Check that the system does not allows todefine an empty sequence.

3. Check that the beginning time of first timeslot in sequence is zero relatively to the be-ginning of call.

4. Check that the end time of the last time slotin sequence is infinity.

5. Check the system does not allows to definedoverlap time slots.

6. Check that the system stores correctly thedefined contract by reloading the contractand comparing the data in the contract withentered data.

17

Page 18: Testing Document Faculty of Engineering Science Software ...

ADD

Functional Requirement TestBuilding a price list.

1. Check that the system allows to define a se-quence of time slots for each selected periodof time of common tariff in time table.

2. Check that the system does not allow tostore time table with period (or periods) oftime of common tariff without defined se-quence of time slots.

3. Check that system allows to define only onesequence of time slots for each selected pe-riod of time of common tariff in time table.

4. Check that the system allows to select 2 timetables (holiday time table and weekday timetable) for each area code.

5. Check that the system allows to store areacode with exactly 2 selected time tables.

6. check that system forces selection of 2 timetables for each area code in area codes list.

7. Check that the system allows to select alist of area codes for each telecommunicationcarrier.

8. Check that the system allows to select onlyone list of area codes for each telecommuni-cation carrier.

9. Check that system forces selection of areacodes list for each telecommunication car-rier.

Table 10: Alerts

Functional Requirement Test

18

Page 19: Testing Document Faculty of Engineering Science Software ...

ADD

Functional Requirement TestCall exceeded time duration limit.

1. Check that the system allows to define callexceeded time duration limit alert for anynumber of extensions.

2. Update DB with call exceeded time durationlimit and check that alert generated.

3. Check that the alert was sent to all emailsthat alert appear in the distribution list ofthe alert.

4. Update DB with call that not exceeded timeduration limit and check that alert was notgenerated.

5. Check that the alert was not sent to anyemail that appear in the distribution list ofthe alert.

Calls on numbers that start with specific digits.

1. Check that the system allows to define callson numbers that start with specific digitsalert for any number of extensions.

2. Check that the system allows to define listof starts of phone numbers.

3. Check that the system stores correctly thedefined list of starts of phone numbers byreloading the list and comparing the con-tents of the list with defined data.

4. Update DB with call on number that startswith one of digits, defined in 2 and checkthat alert appear in the distribution list ofthe alert.

5. Update DB with call on number that doesnot starts with any digit, defined in 2 andcheck that alert was not generated.

6. Check that the alert was not sent to anyemail that appear in the distribution list ofalert.

19

Page 20: Testing Document Faculty of Engineering Science Software ...

ADD

Functional Requirement TestTime off call (e.g. off work time).

1. Check that the system allows to define timeof call alert for any subset of extensions.

2. Check that the system allows to define timeperiod for generating the alert.

3. Check that the system stores correctly thetime period for generating the alert byreloading the alert definition and comparingthe time period with the entered one.

4. Update DB with call in the defined time pe-riod and check that alert appear in all theemails from the distribution list of the alert.

5. Update DB with call not in the defined timeperiod and check that alert was not gener-ated.

6. Update DB with call not in the defined timeperiod and check that alert was not appearin any email from the distribution list of thealert.

20

Page 21: Testing Document Faculty of Engineering Science Software ...

ADD

Functional Requirement TestDay of week (e.g. weekend).

1. Check that the system allows to define dayof week alert for any subset of extensions.

2. Check that the system allows to define daysof week to generate the alert.

3. Check that the system stores correctly thedefined days of week by reloading the alertinformation and comparing with entereddays of week.

4. Update DB with call in the defined day ofweek for producing the alert and check thatalert appear in all the emails from the dis-tribution list of the alert.

5. Update DB with call not in the defined dayof week and check that alert was not gener-ated.

6. Update DB with call not in the defined dayof week and check that alert was not appearin any email from the distribution list of thealert.

Table 11: System audit

Functional Requirement Test

21

Page 22: Testing Document Faculty of Engineering Science Software ...

ADD

Functional Requirement TestRecording the operations.

1. Apply random sequence of operations on thesystem.

2. Check that all applied operations recordedin the log file by comparing the informationabout applied operations and data recordedin the log file.

3. Check that only applied operations recordedin the log file and there is no any recordabout operation that was not applied.

4. Check that the recorded information is notvisible from other organization.

Log file size.

1. Log in the system as system operator anddefine the threshold for log file size.

2. Log in the system as organization adminis-trator and define the maximum log file size.

3. Check that the system not allows to definesize bigger, than the threshold defined bysystem operator.

4. Apply random sequence of operations on thesystem and check that the log file riches themaximum size.

5. Check that the size of log file does not exceedthe maximum log file size.

6. Check that the system deletes old recordswhen the log file reaches the defined size.

2 Testing non-functional requirements

2.1 System speed

The response times were not defined exactly. The test is performed manually and checksthat the system responds in a reasonable time.

22

Page 23: Testing Document Faculty of Engineering Science Software ...

ADD

2.2 Capacity

The capacity was not defined exactly. The only requirement was that the number of usersthat can access the system simultaneously is about 30% of the entire number of customers ofthe system. Considering the constraints of usage of the system we made an assumption thatthe entire number of customers of the system is close to 1000 and the systems should accepts300 calls simultaneously. For testing it we create a module, that will access the system viahttp protocol and log into the system.

2.3 Safety & Security

The system does not allow to unauthorized user access to system data. The test is per-formed manually and checks that the system does not allow to access directly to specific htmlpage. To avoid user access to data of other organizations we checks in each use case that thedisplayed and modified data belongs to user’s organization only.

2.4 Usability

There are 2 levels of system complexity. The low level takes about 1 hour to learn andthe high level takes several hours till several days to learn. We will not perform testing ofusability of the system. The usability will be checked by Solan Telecom and we should toprocess with respect to its opinion.

2.5 Availability

The system must be available continuously 24 hours a day. We will not test this requirementbecause it depends on s server the system runs on.

3 Test-Driven Development

We did not make use of the TDD development strategy. In the development process we had tolearn various technologies and tools: Crystal Reports, development web application, SQL Server2000, java script. We learned these technologies during writing project code and we could not writetests before writing code because before writing code we did not know how these technologies work.

4 Random & automatically-generated tests

4.1 DB generating.

We automatically generate “synthetic” DB by filling the DB tables with random data.

4.2 GUI tests

23

Page 24: Testing Document Faculty of Engineering Science Software ...

ADD

We automatically generate the GUI stress tests by generating random sequence of eventsthat represents the button clicks and different selections. The only thing that this test showsis the GUI stability.

4.3 Report generating.

We automatically generate different reports by random choosing report fields and summarytypes. But we can not check correctness of reports in this stage because the result availableonly after generating report style and applying style on report.

4.4 Report style generating.

We automatically generate different report styles by random choosing style parameters:color, font name and size, picture position etc. But we should manually check if the styleapplied correctly because result of applying style on report is a screen and we have no toolsto determine if the screen displayed correctly or not.

5 Testing the user interface

We test GUI in 3 ways:

1 Manual testing.

2 Automatic functionality test.

3 Automatic stress test.

The automatic tests works in the following way: exchanging the presentation layer with the testlayer, which simulates the GUI events, calls the controller, receives response and checks the responsevalidity.

6 Testing build, integration & deployment

24