test plan document v0.2

8/13/2019 Test Plan Document v0.2

1/37

Student Information System

Abbreviated Name: SIS_TP

Software Design Document (TP)

Revision: V!"

Name Signatures

#iras A$%amad & '""*

Abdu$ra%man A$toibi & '""+,

Saud A$dawis% & '"",-

#a%ad A$.a%.a & '"""-

Test Plan Document Student Information System 1


2/37

Contents

Contents................................................................................................................................................................................2

1. Scope................................................................................................................................................................................5

1.1 Identification...............................................................................................................................................................5

1.2 Purpose of Document..................................................................................................................................................5

1.2 System overview.........................................................................................................................................................5

1.4. Referenced Documents..............................................................................................................................................5

1.5 Test Plan Scope...........................................................................................................................................................

1.5.1 !"#ectives ...........................................................................................................................................................

1.5.2 Scope....................................................................................................................................................................

1.5.$ %on&functional re'uirements to "e tested.............................................................................................................(

1.5.4 Team )em"er Details..........................................................................................................................................(

2. Testin* Strate*y................................................................................................................................................................+

2.1 ,sa"ility Testin* -pproac........................................................................................................................................+

2.$ /as Testin* -pproac.............................................................................................................................................10

2.4 unctionality Testin* -pproac................................................................................................................................11

2.5 ,ser -cceptance Testin* -pproac..........................................................................................................................11

2. ustification...............................................................................................................................................................11

$. Testin* Scedule and Resourcin*...................................................................................................................................12$.1 Testin* Delivera"les.................................................................................................................................................12

$.2 Testin* Resources.....................................................................................................................................................12

$.$ Testin* Scedule.......................................................................................................................................................1$

4. Testin* ocus..................................................................................................................................................................14

4.1 unctional -rea for Testin* ocus............................................................................................................................14

4.2 %on&unctional -rea for Testin* ocus....................................................................................................................14

5. Test Result -dministration.............................................................................................................................................1

. -cceptance Testin*.........................................................................................................................................................1(

.1 -cceptance Testin* Criteria......................................................................................................................................1(

.2 -cceptance Testin* Responsi"ility...........................................................................................................................1(

(. ,nit Test Cases...............................................................................................................................................................1(

3. Testin* Ceclists...........................................................................................................................................................20

3.1 e" System Security Ceclist................................................................................................................................20

3.2 Internal Code 6uality Ceclist................................................................................................................................21

+. References.......................................................................................................................................................................22

10. -ppendi7 1 & ,sa"ility Testin* 8valuation Seet.........................................................................................................2$

Tas Instructions.........................................................................................................................................................2$



3/37

!"serve steps taen.....................................................................................................................................................2$

If user does not follow te nown pat9 wat did tey clic on:.................................................................................2$

,ser;s ver"al comments..............................................................................................................................................2$

6uality Ceclist............................................................................................................................................................24

11. -ppendi7 2 & Internal 6uality Testin* 8valuation Seet..............................................................................................25

12. Test Tracin* Spreadseet...........................................................................................................................................$5

1$. -ppendi7 4& Scope and )andatory Re'uirements....................................................................................................... $

14. -ppendi7 5& Security Re'uirements............................................................................................................................ $(

Modification History

Version Date Authors Summary of Changes

"! /" to ,/" Pro0ect Team Document Drafted

"!+ -/" Pro0ect Team Document u1dated after consu$tation wit% 1ro0ect $eader

Test Plan Document Student Information System $


4/37

Glossary

Term Name Definition

/eaviour Student "eaviour includin* fi*ts9 disputes etc

Incident Same as "eaviour

!n Demand Results Te twice an year e7ams done "y students

System Principles Scool users wit i*er level of privile*es

,)< ,nified )odellin*


5/37

1. Scope

1.1 Identification.Te Student Information System =referred to as SIS from ere onwards in tis document> is identified "y te acronym SIS

=Student Information System>.

Tis document is te Software Test Plan document identified "y SIS?TP v1.0.

1.2 Purpose of Document.Te purpose of tis document is to provide a test plan document tat defines a plan and test cases for te testin* of

Student Information System. This document describes the appropriate strategies, process, workflows and

methodologies used to plan, organize, execute and manage testing of software projects within Student

Information Systemdevelopment pro#ect.

Te document is developed for te purpose of readin* and review "y te followin* parties@

1. Development Team

2. Desi*n Team

$. -nalysis Team

4. Data -ssistant ,sers

Te document must "e used "y te a"ove parties in strict confidence.

1.2 System overview.Te Client !r*aniAation as identified tat tey are now collectin* a ran*e of data a"out teir students includin*

attendance data9 acievement data9 "eaviour data9 contact details9 timeta"les9 alternative pro*rams data and oter

information.

Te ultimate aim is to develop a unified IT System for administrative staff9 academic staff and mana*ement wic will

populate a centraliAed information system. Tis information system will ten also "e a"le to e7pose te information

collected to individual staff mem"ers in a usa"le and efficient manner.

)a#or o"#ectives of tis pro#ect are@

Provide a sin*le consistent *ateway to student data for all levels of scool administration staff9

Create a consistent9 easy to use9 accessi"le and secure system around te needs of scool administration and

mana*ement9

Deliver a unified student information mana*ement system to allow administrators and academics to perform teir

respective tass efficiently9

Simplify te administrative processes for students and parents9

Provide easy accessi"ility to student information via a central point

1.4. eferenced Documents.Software Pro#ect )ana*ement Plan

or /readown Structure

Client )eetin*s and Status Reports

System Re'uirements Specification

Software Desi*n Document



6/37

1.! "est Plan Scope.

1.!.1 #$%ectives

Te purpose of tis test plan is to provide a test plan and test cases for testin* of@

1.

1.!.2 Scope

1.5.2.1 Key Features and Functionalities of the System to be testedNote@ Te ey features and functionalities of te system to "e tested are listed "elow.

Feature Functionalities Required

Master Data Management

-llow respective administrators to

mana*e te master data suc as

Room Details9 Pro*ram Data9

Su"#ect Data

1. -llow administrators to update master data includin*

room details9 pro*ram data and su"#ect data

2. -llow Bsuper; administrator users to define access

privile*es to master data elements

Student Data Management

-ll respective administrators to

mana*e te student data includin*

attendance data9 acievement data9

"eaviour data9 contact details9

timeta"les9 alternative pro*rams

data and oter information

1. -llow administrators to update student data element

2. 8nforce "usiness rules to ensure te inte*rity of student

data

$. -llow Bsuper; administrator users to define access

privile*es to student data elements

Access/Search

-llow te users to searc for

re'uired information easily

1. -utoriAed users sould "e a"le to view information as

re'uired.

2. -llow a multi dimensional searc "ased upon eyword9

id9 name9 description9 notes etc.

$. Include multiple types of searc criteria suc as e7act

matc9 partial matc9 wildcard searc etc.

4. -utoriAed users only sould "e a"le to 'uery te

relevant information.

Reporting

-llow users to *enerate summary

and detailed reports on student

data.

1. -llow *eneration of period administrative reports suc

as montly attendance reports.

2. -llow *eneration of summary reports suc as total

num"ers of students "y eac class.

$. -llow *eneration of detailed reports suc as all students

enrolled in a class or pro*ram of study.

Administrative Tools

-dministrators sould "e a"le to

mana*e te report;s administration

and confi*uration

1. Te administrators sould "e a"le to mana*e te users

& Reports on users of te system

& Tools to remove users from te system

& Define access privile*es for users

Test Plan Document Student Information System


7/37

Feature Functionalities Required

& Run maintenance tass =T/C>

2. -udit te usa*e of te system

$. Run audit reports for activities in te system

1.!.& 'on(functional re)uirements to $e tested

Te non functional re'uirements of te system tat need to "e tested include@

Operational Requirements

- Te system sould provide 100 uptime.

- Te system must "e tecnolo*ically9 functionally and operationally feasi"le for at least 5 years from *o live.

- Te system must provide different levels of access for users

- Te system must ave a i* level of accessi"ility and usa"ility

Security Requirements

- Confidential data sould only "e viewa"le "y autorised personnel.

- Different types of user *roups are to "e created wit different roles and privile*es.

erformance Requirements

Te system sould "e a"le to andle

- ,p to 50 simultaneous users

- Data for appro7imately 1000 active students at any *iven time

- Data for appro7imately 10000 students istorically

Other non functional requirements

- Te system must "e ro"ust suc tat additional developmentmaintenance on te system can "e performed witout

any ma#or restructure of te system

1.!.4 "eam Mem$er Details

Te followin* ta"le contains te names of Tec!ne team mem"ers wit teir roles and responsi"ilities@

)em"er %ame Role Responsi!ilities S"ills

Saud -ldawis

Student Id@ $00+(1+5

smdowisEotmail.com

Contact %o@04214+51$

/usiness -nalyst-

-nalyse9 understand anddocument te processes insystem;s current state.

- Identify staeolders anddevise a communicationplan.

- Identify and document all"usiness9 tecnical andprocess re'uirements.

- or wit users to prioritiAeand rationaliAe tere'uirements.

- Felp Pro#ect )ana*er indefinin* acceptance criteriafor te pro#ect.

- Felp Pro#ect )ana*er in

--nalytical andinvesti*ative sills

- Process )odellin*- Data )odellin*- Specification writin*

and "usiness writin*- Interpersonal

communication sills- Presentation and

trainin* sills- Gnowled*e of "ot

traditional and a*ilesoftwaredevelopmenttecni'ues

-


8/37

"usy period writin* andreviewin* documentation.

-"dulraman -ltoi"i

Student Id@ $00321(1

)r?altoomEotmail.com

Contact No: 04!"#$!

System Desi*ner

Pro*rammer

- Desi*n i* level softwareinfrastructure.

- Desi*n prototypes andmodels accordin* to userre'uirements.

- -ssist "usiness analysts indesi*nin* use case dia*rams

and use case scenarios.- Felp pro*rammers in

desi*nin* unified modellin*dia*rams9 entity relationsipdia*rams9 data flowdia*rams9 moc screens andwire frames.

- Felp in code reviews andcode 'uality assurance.

- ,nified modellin*tecni'ues

- !"#ect !rienteddesi*n and analysissills

- Data"ase desi*n anddevelopment sills

-ell developedcodin* sills in& e" "ased

tecnolo*ies

includin* -SP.%8T

and PFP

& D/)S systems

includin* )yS6

- Test Plan

development sills- Test script

development ande7ecution sills

- Proficient in use oftest tools suc as6uality Centre

- Silled in functional9tecnical and 'ualitytestin*

- ,ser acceptancetestin* sills

mailto:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]


9/37

2. "estin* Strate*yTe test metodolo*y will "e ept li*twei*t and simple. Te standard testin* practices will "e used as outlined "elow.

2.1 +sa$ility "estin* ,pproac-.Te usa"ility testin* will "e tested "y

1. Conductin* re*ular reviews of te user interface to ensure it meets te usa"ility *uidelines of top ten usa"ility

euristics

%ielsen ao" =2004>. Ten ,sa"ility Feuristics9 retrieved online from

[email protected]?list.tml

Te ten principles of %ielsen will "e applied in te followin* way@

#isi!ility of system status

Te user will always see te current navi*ation pat9 te mode of data"ase operation

=addeditdeleteupdate>.

Match !et$een system and the real $orld

Te lan*ua*e used for navi*ation elements9 field names and messa*es will "e ept very person and will

"e reviewed to ensure tere is no terminolo*y tat te end user can not relate to. Tis will "e covered

durin* usa"ility testin* were peer students from oter discipline =suc as arts> will "e ased to review

te lan*ua*e used in te system.

%ser control and freedom

Te users will always "e *iven te option to cancel out of an operation if tey can*e teir mind. Tis

will "e acieved "y asin* te user for review all re'uests. -t te time of review9 tey will "e ased to

cancel or commit te action.

&onsistency and standards

Te user controls will "e ept similar to wat te user e7pects to find in oter ma#or we"sites suc as

Internet /anin*9 Social %etworin* etc. Tis will elp te user feel familiar wit te system strai*t

away.

Te stylin* will "e ept consistent trou*out te site.

'rror prevention

Test Plan Document Student Information System +
http://www.useit.com/papers/heuristic/heuristic_list.htmlhttp://www.useit.com/papers/heuristic/heuristic_list.html


10/37

Te users will "e restricted from performin* invalid actions "y restrictin* te invalid actions on user

interface. or e7ample9

o if a user does not ave access to a menu item9 te menu item won;t "e sown.

o if a record is not availa"le for deletion9 ten delete option will not "e availa"le on te record.

Recognition rather than recall

Te user will always "e presented wit relevant options so tat tey do not ave to tin. Te users will

rater ave to #ust select te actions.

Fle(i!ility and efficiency of use

Te e7pert users will "e *iven te option to perform super&user lie functions suc as import and e7port

file9 perform operations on "ul records.

Aesthetic and minimalist design

Te information will "e relevant and applica"le only.

)elp users recogni*e+ diagnose+ and recover from errors

Te error messa*es will contain te followin* elements as a minimum@

o Te cause of error

o Te actions tat can "e taen to correct te error

)elp and documentation

o - compreensive user manual will "e produced

o If te user re'uires nowin* a particular "usiness rule9 ten te information will "e presented on

te relevant screen=s>.

2. Conduct a formal user acceptance testin* pase at te end of te pro#ect

$. Involvin* potential users =peer students> fre'uently durin* te pro#ect

2.& as- "estin* ,pproac-.

Te "as testin* approac is to test early ="y developers> to remove as many "u*s as possi"le9 as early in te process aspossi"le. It is a common pro"lem tat tere are some o"vious "u*s left te system after development as #ust "een

finised. Terefore9 if te developers can run some 'uic tests as tey develop9 most of te o"vious "u*s can "e removed

at tat sta*e.



11/37

Te developers will "as test te system as eac component or module in te system is developed. Tis approac will

elp in eliminatin* any of te o"vious "u*s from te system.

Tis will ensure tat te testers will "e dealin* wit te more comple7 issues. Te testers will "e a"le to focus on "u*s

tat are comple7 and related to te core functionality rater tan simple issues tat can easily "e identified durin*

development.

2.4 /unctionality "estin* ,pproac-.

Te functionality testin* approac entails testin* te system provides completeJ and accurateJ functionality. Teapproac for tis testin* will "e to manually run test cases to verify

1. 8ac isolated re'uirement

2. 8ac isolated functional rule

$. Inte*ration "etween functional areas of te system

Te functionality will "e tested "y te testers in a formal testin* manner. Te testers will create test cases and collect test

data.

Tere will "e formal reviews of te test cases wit developers9 analysts and testers in te same room.

-fter te test cases ave "een reviewed for accuracy and compreensiveness9 te testers will manually run te tests

a*ainst te developed system and identify any discrepancies "etween te SRS and Desi*n %ote documents. Tese "u*s

will "e verified "y "usiness analysts and ten corrected "y te developers. Te cycle will continue until all "u*s ave

"een identified and resolved.

2.! +ser ,cceptance "estin* ,pproac-.Te user acceptance testin* is conducted to ensure tat te client is appy wit all aspects of te system tat as "een

delivered. Te system is deployed on te client site and te client is *iven one wee to test te system to ensure tey are

appy wit internal and e7ternal 'uality of te system.

Te informal user acceptance testin* will "e conducted wit 4& peer students. Te students will "e *iven some test files

and tass to perform. Te users will not "e provided any testin* scripts since one of te purposes of user acceptance

testin* will "e to identify tat te system is easy to use and learn witout any formal trainin*.

Te client will "e ased to perform te formal user acceptance testin* to accept te delivery of te software.

2.0 ustificationTe wide ran*e of testin* approaces as "een used to adapt a fle7i"le and compreensive testin* approac. Te "rief

rationale for eac of te testin* approaces includes@

1. Te "as testin* approac will "e used to remove te lar*e and o"vious "u*s earlyK

2. Te testers will perform compreensive functional testin* =usin* manually defined test cases> to ensure te

system functionality is completeJ and accurateJ

$. Te usa"ility testin* will test te ease of use9 relia"ility9 efficiency9 e7tensi"ility and oter internal and e7ternal

'uality factors.

4. Te user acceptance testin* will ensure tat te client is appy wit te delivered product.



12/37

&. "estin* Sc-edule and esourcin*

&.1 "estin* Delivera$lesIn addition to te 'uality event eld trou*out te development9 strin*ent testin* will "e done on te final delivera"le.

ollowin* ta"le demonstrates te final testin* tat will "e undertaen on eac of te delivera"les@

ro,ect lan Document Testing Type@ 87pert !pinions and reviews

-ho@ )ana*ement personnel and pro#ect mana*er9 one peer pro#ect mana*er

-hen@ -t te completion of Pro#ect Plan "efore te formal si*n&off

System Requirement

Specifications

Testing Type@ Prototype /uilds =Part of desi*n pase>

-ho@ /usiness -nalysts and System Desi*ner

-hen@ Durin* te desi*n pase of te pro#ect

Design Documents Testing Type@ Review )eetin*s

-ho@ /usiness -nalysts9 System Desi*ner and Pro*rammers

-hen@ -fter te desi*n documents ave "een produced and "efore te completion

of desi*n pase

Technical Development Testing Type@ ormal testin* pase

-ho@ see ne7t point

-hen@ see ne7t point

Testing Testing Type@ ormal testin* metodolo*y

-ho@ Testin* Team9 some end user involvement9 some pro*rammer =coder>involvement

-hen@ -t te conclusion of tecnical development

roduct Documentation Testing Type@ ,ser Reviews9 )oc run trou*

-ho@ Trainin* Team9 /usiness -nalysts9 8nd ,sers

-hen@ ust "efore te system *o live

&.2 "estin* esourcesTe roles and responsi"ilities for te testin* of te solution ave "een defined for eac applica"le role witin te pro#ect

team@

Role Testing Responsibilities

Developer - 87ecute unit tests.- 8nsure all unit testin* "u*s are corrected.- -ssist te testers in validatin* tat a certain issue is a "u* or not.

Tester - Felp te pro#ect mana*er9 'uality mana*er in developin* a 'uality plan and

acceptance criteria.- /uild test plans- /uild test scripts- 87ecute test scripts



13/37

- Felp te pro#ect mana*er and "usiness analysts developin* a ris mana*ementplan wit miti*ation strate*ies.

/usiness -nalysts - Provide assistance to developers and testers in understandin* te re'uirements- Provide assistance to testers in preparin* test cases- Conduct reviews of te test plans wit testers to ensure te test covera*e is

compreensive

Pro#ect )ana*er - Provide scedulin* and estimatin* assistance to te rest of te team for testin*re'uirements

- !verloo te process of tracin* "u*s and rectifyin* tem to ensure te

'uality is delivered- Provide assistance to te team in creatin* and si*nin* off a test plan

&.& "estin* Sc-edule

Test Phase Description of task Resource Name(s) Dates

,nit Testin* Te individual units of te

code will "e tested. Tis

testin* will "e performed "y

te developers =/as testin*>.

-"dulraman -ltoi"i

iras -lamad

25 -u*ust to 25 !cto"er

=System Development

Cycle>

25 !cto"er to 2

%ovem"er

=Testin* Cycle>

System Testin* Te system;s functional

testin* will "e completed

durin* tis pase.

/as testin* will "e

performed "y te developers

and te functional testin*

=formal> will "e performed "y

te tester =aad -lyaya>

-"dulraman -ltoi"i

iras -lamad

aad -lyaya

25 -u*ust to 25 !cto"er

=System Development

Cycle>

2 %ovem"er to +

%ovem"er

=Testin* Cycle>

Inte*ration Testin* Te inte*ration testin* will "e

performed "y te

developments =/as

inte*ration testin*> and te

testers

-"dulraman -ltoi"i

iras -lamad

aad -lyaya

2 %ovem"er to +

%ovem"er =/as

Inte*ration Testin*>

2 %ovem"er to +

%ovem"er

=Testin* Cycle>

,sa"ility Testin* Te usa"ility testin* will "eperformed wit students.

Te testers will run te

system a*ainst te prescri"ed

testin* ceclists to test te

usa"ility.

aad -lyaya

Peer students =4& students>

15 %ovem"er to 25%ovem"er

Security and 6uality

Testin*

1. Presentation layer security

to "e tested "y te testers.

2. Te system;s tecnicalsecurity will "e tested "y

developers.

iras -lamad

aad -lyaya

Peer students =4& students>

15 %ovem"er to 25

%ovem"er

Test Plan Document Student Information System 1$


14/37

,ser -cceptance Testin* Te user acceptance testin*

will "e completed "y te lient.

Simon 25 %ovem"er to $0

%ovem"er

4. "estin* /ocus

4.1 /unctional ,rea for "estin* /ocus-ll functional re'uirements identified in te Software Re'uirement Specification Document will "e tested. Te detailed

test cases ave "een defined in Section ( ,nit Test Cases.

4.2 'on(/unctional ,rea for "estin* /ocusTe followin* non functional areas will "e tar*eted for testin*@

1> ,ser Security

1. ,ser lo*in security@ Te passwords will "e tested to ensure tere are secure.

a. %ot same as te user name

". %ot same as user;s name

c. %ot same as email address

2. Security of screens and reports as determined "y te security privile*es set up in te system

a. !nly te options tat te user as access to will "e displayed

$. Test to ensure stron* passwords

a. Contain at least one alpa"et9 num"er and special sym"ol

4. Test to ensure S6< in#ection attacs are stopped.

2> System Security

1. Test to ensure tat te secure pa*es are not accessi"le witout lo**in* in.

2. Test to ensure te system cannot "e i#aced via D%S attacs.

a. If more tan 10 re'uests are received "y a pa*e =in a *iven second>9 ten te system sould

not entertain any more re'uests from tat IP -ddress

$> ,sa"ility Testin*

1. Test to ensure usa"ility *oals identified in tis document.

a. Te usa"ility testin* will "e conducted "y asin* 4 to 5 peer students to use te system and

provide o"#ective and su"#ective feed"ac on te system 'uality.

See -ppendi7 1 L ,sa"ility Testin* 8valuation Seet



15/37

4> Internal 6uality Testin*

1. Test to ensure te main a"ility9 e7tensi"ility and understanda"ility of te code.

See -ppendi7 2 LInternal 6uality Testin* 8valuation Seet

Tere will "e no oter performance testin* e7cept te efficiency testin* conducted durin* "as testin*. Te system is very

li*twei*t wit only up to 5 simultaneous users. Terefore9 tere is no need to spend time on performance testin* in tispro#ect wic is runnin* under very ti*t timelines already.



16/37

!. "est esult ,dministrationTe testin* tools "u* tracin* will "e performed usin* li*t wei*t testin* tools. -n e7cel spreadseet will "e

maintained containin* all "u*s and status of te "u*.

See-ppendi7 $ L Test Tracin* Spreadseet

Te process followed for maintainin* te "u*s will "e@

Te test cases will "e stored in a sares e7cel spreadseet amon*st te team mem"ers. Te process for updatin* te

testin* spreadseet will "e@

1> Testers will "e a"le to record new "u*s. %ew "u*s are to "e mared wit /u* Type =Data /u*9 ront 8nd /u*

and /usiness and mared wit a status of Open. Te "u*s can "e assi*ned to a particular developer to

fi7. Te types of "u*s will "e classified accordin* to@

a. Data /u*@ Data "u* will occur wen te pre&defined data setup =e.*. pre&set users ave not "een set up

correctly>.

". ront 8nd /u*@ Te front end =presentation layer> as a pro"lem in renderin* data incorrectlyK or any of

te la"ellin* is incorrect.

c. /usiness Te developers will "e a"le to fi7 te "u*s and put intoRetest. Te developers will fi7 te "u*s into

Developmentenvironment first to ensure tey can "e tested "y developers temselves. Ten tey will apply te

"u* into System Test environment for te developers to fi7.


%ew /u* Recorded /u* -ssi*ned to /-

/u* -ssi*ned to

Developer

/u* -ssi*ned to tester for

verification

/u* re'uires /-

assistant

/u* re'uires developer to

fi7 te "u*

/- confirmed "u*

/u* fi7ed

Te "u* as not "een

fi7ed

/u* fi7ed

/u* Closed


17/37

$> Te testers will need to test te "u*s put intoRetest and if tey are appy tat te "u* as "een fi7ed9 tey will

put te "u* into Deployment Pendin* mode.

4> Te developers will apply te fi7 in te System Test environment and put te fi7 intoProductionenvironment.

0. ,cceptance "estin*

0.1 ,cceptance "estin* CriteriaAttachment to the Requirements

Te delivera"les will "e accepted "y te client if@

& -ll scope defined in tis pro#ect plan is met 100

& -ll mandatory re'uirements defined in te user re'uirements specification document are met 100

& -t least 50 of te wis list re'uirements as defined in te user re'uirements document are met

See -ppendi7 4 L Scope and )andatory Re'uirements

Usability

Te delivera"les will "e accepted "y te client if@

& - user wo as not seen te system "efore can perform all tass in te user acceptance test document in an avera*e

time of 5 minutes. =-tomic tass9 te time e7cludes te system process waitin* time>.

& Client si*ns off te user acceptance testin* document.

Security & Control

-ll security aspects defined in te pro#ect plan and te user re'uirements must "e met 100.

See -ppendi7 5 L Security Re'uirements

Procedures & Documentation

Refers to te precision in te documentation of te functions and use of te system and te e7tent tat te automatedprocesses are worin* properly as an inte*ral part of te entire system. -ll Documents must "e si*ned off "y terespective "usiness owners and staeolders.

-ll Documents must pass te review ceclist.

0.2 ,cceptance "estin* esponsi$ilityTe responsi"ility for te acceptance testin* will "e of /allarat Secondary Colle*e representative )r Simon.

. +nit "est CasesTest Case No Test Case Name and relevant use case Pre Condition Post Condition

T1 ,se Case@ Record !n Demand Result

Test Case %ame@ Test successfully

recordin* an on demand result.

Te student already e7ists in

te system.

Te on demand result as

"een successfully recorded

in te system.

T2 ,se Case@ Record !n Demand Result Te student e7ists in te

system.

Te on demand result could

not "e recorded. -n

Test Plan Document Student Information System 1(


18/37

Test Case %ame@ Record on demand

result wen it as already "een recorded.

Te on demand result as

already "een entered.

appropriate error messa*e

as "een displayed.

T$ ,se Case@ Record !n Demand Result

Test Case %ame@ Record on demand

result for an inactive student.

Te student is inactive in

te data"ase.

Te on demand result could

not "e recorded. -n

appropriate error messa*e

as "een displayed.

T4 ,se Case@ Record /eaviour Information

Test Case %ame@ Record "eaviour

information successfully.

Te student e7ists. Te "eaviour information

as "een recorded. Te

resolution is "lan.

T5 ,se Case@ Record /eaviour Information

Test Case %ame@ Record resolution for a

"eaviour incident.

Te student e7ists.

Te "eaviour information

e7ists.

Te resolution as not "een

entered.

Te resolution as "een

recorded.

-n email as "een sent to

appropriate contact=s> as per

email confi*uration.

T ,se Case@ Record /eaviour Information

Test Case %ame@ ,pdate resolution for a

"eaviour incident and ensure tat an

email is sent to appropriate contact=s>

re*ardin* te update of te resolution.

Te student e7ists.

Te "eaviour information

e7ists.

Te resolution as already

"een entered.

Te resolution as "een

updated.



email confi*uration

T( ,se Case@ Record Contact Information

Test Case %ame@ 8nter contact

information for a student.

Te student e7ists.

Te student;s contact

information as not "eenentered yet.

Te contact information as

"een entered in te system.

T3 ,se Case@ Record Contact Information

Test Case %ame@ 8nter emer*ency contact

information for a student.

Te student e7ists.

Te student;s emer*ency

contact information as not

"een entered yet.

Te emer*ency contact

information as "een

entered in te system.

T+ ,se Case@ Record elfare Information

Test Case %ame@ Record elfare

information successfully.

Te student e7ists. Te elfare information

as "een recorded.

T10 ,se Case@ Record elfare Information

Test Case %ame@ Record comment for a

welfare record.

Te student e7ists.

Te elfare information

e7ists.

Te comment as "een

added to te welfare record.



email confi*uration.

T11 ,se Case@ Record elfare Information

Test Case %ame@ -dd a new comment

a*ainst welfare information and ensure

te comment istory is ept =new

comment does not replace e7istin*

Te student e7ists.

Te elfare information

e7ists.

Te comment as "een

added.

Te e7istin* comment as

"een ept. /ot comments

ave appropriate dates to



19/37

comment> indicate wen tey were

addedupdated.



email confi*uration

T12 ,se Case@


20/37

Test Case %ame@ Test tat a student wit

duplicate student id cannot "e added into

te system.

messa*e is displayed on te

screen.

T21 ,se Case@ -dd ,ser

Test Case %ame@ -dd a user into te

system successfully

Te user id does not already

e7ist in te system.

Te user as "een

successfully added into te

system.

T22 ,se Case@ -dd ,ser

Test Case %ame@ Test tat a user wit

duplicate id cannot "e added into te

system.

Te user wit te id alreadye7ists.

Te user could not "eadded. -n appropriate

messa*e is displayed on te

screen.

T2$ ,se Case@ -dd ,ser

Test Case %ame@ Test tat a user wit

duplicate password can n"e added into te

system.

Te user wit te user id

does not e7ist. - user wit

same password e7ists.

Te user as "een added

into te system.

T24 ,se Case@ Setup Roles Privile*es

Test Case %ame@ -dd a new privile*e can

"e added successfully.

Tere is no privile*e for te

same PFP pa*e already.

Te privile*e as "een

added successfully.

T25 ,se Case@ Setup Roles Privile*es

Test Case %ame@ 8nsure tat privile*e

cannot "e added for te same pa*e

multiple times.

Tere is already privile*e

for te same PFP pa*e

already.

Te privile*e could not "e

added into te system.

T2 ,se Case@ Setup Roles Privile*es forusers

Test Case %ame@ -dd a new privile*e for

a user successfully.

Te user as not "eenassi*ned tat privile*e

already.

Te privile*e as "eenassi*ned to te user

successfully. Te pa*e is

now accessi"le from te

user lo*in.

T2( ,se Case@ Setup Roles Privile*es for

users

Test Case %ame@ 8nsure tat same

privile*e cannot "e assi*ned to a user

twice.

Tere is already privile*e

for te same user.

Te privile*e could not "e

assi*ned. Te pa*e is still

not visi"le under te user

lo*in.

3. "estin* C-eclists

3.1 5e$ System Security C-eclist1. Try to directly access "oomared we" pa*e witout lo*in to te system.

2. Do not si*n&on system9 directly try to download te file from te availa"le download url9 suc as te input

M


21/37

4. ID password autentication metod@ cec wit valid and invalid passwords9 password rules say cannot "e less tan

carecters9 user id and password cannot "e te same etc.

5. Important information =suc as passwords9 ID num"ers9 credit card num"ers9 etc.> sould not *et displayed in te input

"o7 wen typin*. Tey sould "e all encrypted and in asteri7 format.

. )anually can*e te parameter value in te ,R< to cec if you can access special pa*es. or e7ample9 suppose in a

we" system If ordinary users access te correspondin* url in te parameters l N e and te correspondin* url for advanced

users in te parameters l N s. %ow if a user manually can*e te value from e to s it sould not allow you to access te

pa*e.

12. In te url9 enter te followin* address to cec if it can "e downloaded restricted files@

M

2. InitialiAation and Declarations

-re varia"les and class mem"ers of te correct type and appropriate mode-re varia"les declared in te proper scope:Is a constructor called wen a new o"#ect is desired:-re all o"#ect references initialiAed "efore use:

$. )etod Calls

-re parameters presented in te correct order:Is te correct metod "ein* called9 or sould it "e a different metod wit a similar name:-re metod return values used properly:

4. -rrays

http://www.csc.calpoly.edu/~jdalbey/SWE/CodeSmells/bonehead.htmlhttp://www.csc.calpoly.edu/~jdalbey/SWE/CodeSmells/bonehead.html


22/37

-re tere no off&"y&one errors in array inde7in*:Fav all array =or oter collection> inde7es "een prevented from *oin* out&of&"ounds:Is a constructor called wen a new array item is desired:

5. !"#ect Comparision

-re all o"#ects =includin* Strin*s> compared wit e'uals and not NN:

(. !utput ormat

-re displayed output free of spellin* and *rammatical errors:-re error messa*es compreensive and provide *uidance as to ow to correct te pro"lem:Is te output formatted correctly in terms of line steppin* and spacin*:

3. Computation9 Comparisons and -ssi*nments

Cec order of computationevaluation9 operator precedence and parentesisin*-re all denominators of a division prevented from "ein* Aero:Is inte*er aritmetic9 especially division9 used appropriately to avoid causin* une7pected truncationroundin*:-re te comparison and "oolean operators correct:

If te test is an error&cec9 can te error condition actually "e le*itimate in some cases:Is te code free of any implicit type conversions:

3. 87ceptions

-re all relevant e7ceptions cau*t:Is te appropriate action taen for eac catc "loc:

7. eferencese" Security Ceclist9 retrieved online on 15 -u*ust 2012 from

ttp@software'atestin*s.comsecurity&testin*we"&security&testin*&ceclist.tml

ava Code Inspection Ceclist9 retrieved online on 13 -u*ust 2012 from

[email protected]#dal"ey205ResourcesInspectCeclist.tml

http://softwareqatestings.com/security-testing/web-security-testing-checklist.htmlhttp://users.csc.calpoly.edu/~jdalbey/205/Resources/InspectChecklist.htmlhttp://softwareqatestings.com/security-testing/web-security-testing-checklist.htmlhttp://users.csc.calpoly.edu/~jdalbey/205/Resources/InspectChecklist.html


23/37

18. ,ppendi9 1 ( +sa$ility "estin* :valuation S-eet

Task Instructions

Tas instructions ere

Describe task

Tas description ere

!bserve steps taken

Steps

If user does not follow te nown pat9 wat did tey clic on:

%ser Notes

1 %one

,ser;s ver"al comments

%ser Notes

1 %one

Test Plan Document Student Information System 2$


24/37

6uality C-eclist

/randin* and visual identity

Te site ,R< as "een a*reed.

Te standard eader and footer ave "een implemented9 to specification9 on all pa*es.

uidance relatin* to te online colour palette as "een adered to9 especially re*ardin*

luminosity and accessi"ility.

Te pa*e layout is "ased9 were possi"le9 on a li'uid widt =not fi7ed>.

Content and presentation

-ll pa*es are spell ceced and contain no spellin* errors.

-ll pa*es use proper *rammar and punctuation.

Content as "een ceced for accuracy and autenticity.

Duplication of content

Tere is no duplication of content witin te site.

Te site does not duplicate content already pu"lised on anoter we"site.

- custom error pa*e as "een developed.

Pa*e optimisation

8very pa*e as a uni'ue and meanin*ful pa*e title in te re'uired format.

8very pa*e as a uni'ue and meanin*ful meta description in te re'uired format.

8very pa*e as a set of uni'ue and meanin*ful meta eywords in te re'uired format.

8very pa*e as a uni'ue and meanin*ful U1V ta* .

Te alt attri"ute on te Uim*V ta* is set for all descriptive ima*es.

-ll yperlins =internal and e7ternal>@

Fave "een ceced for appropriateness and are worin*.

Te lin te7t is descriptive and reflects te content of te destination pa*e.



25/37

-ll folderfile names@

-re lowercase and case&insensitive.

,se only alpanumeric caracters =and ypens were necessary>.

-re descriptive and reflect te content of te pa*e.

unctionality

!n su"mission9 forms collect data in te re'uired format and te Btan you; pa*e

contains an appropriate messa*e.

- print style seet as "een provided for all pa*es.

ere specific =usually interactive> content may present an additional load on te

server9 tat tis functionality as "een volume tested to a*reed metrics.

Tecnical

Te FT)< is well&formed and is validated as BWFT)< 1.0 Strict;.

or furter information see@ [email protected]$.or*

Te CSS is used appropriately to control layout and presentation and is valid.

or furter information see@ ttp@#i*saw.w$.or*css&validator

Te avaScript as "een tested and contains no errors.

Te site "een tested across all te popular "rowsers9 "ot on a PC and a )ac.

or furter information see list of current popular "rowsers amon* visitors.

Te site as "een tested at a variety of screen resolutions.

or furter information see screen resolution ran*es amon* visitors.

,pdatin*

- process =eiter "usiness or system> is in place for maintenance of te we"site or

application.

- contact for maintenance as "een identified.

11. ,ppendi9 2 ( Internal 6uality "estin* :valuation S-eetReference@ www.sprin*erslc.com.auassetsdownloadswindy?ill!verview.doc

PFP ile ormattin*

http://validator.w3.org/http://jigsaw.w3.org/css-validator/http://www.springerslc.com.au/assets/downloads/windy_hill/Overview.dochttp://validator.w3.org/http://jigsaw.w3.org/css-validator/http://www.springerslc.com.au/assets/downloads/windy_hill/Overview.doc


26/37

PFP code must always "e delimited "y te full&form9 standard PFP ta*s@

U:pp

:V

Sortand ta*s are not permitted.

or files containin* only PFP code9 te closin* ta* must always "e omitted. It is not re'uired "y PFP9 and omittin* itprevents te accidental in#ection of trailin* wite space.


27/37

U:pp

pu"lic functionfilter?input=> X

Y

pu"lic function*et?element?"y?id=> X

Y

:V

-ccessors for instance or static varia"les sould always "e prefi7ed wit *et or set.

or e7ample9

*et?employee?name=>

set?"usiness?address=>

unctions in te *lo"al scope =a..a floatin* functions> are permitted "ut discoura*ed in most cases. Consider wrappin*

tese functions in a static class.

Haria"les

Haria"le names may only contain alpanumeric caracters and underscores. %um"ers are not permitted in varia"le

names. Haria"le names must always start wit a lowercase letter. en a function name consists of more tan one word9

eac new word must "e preceded "y an underscore.

Her"osity is *enerally encoura*ed. Haria"les sould always "e as ver"ose as practical to descri"e te data tat te

developer intends to store in tem. Terse varia"le names suc as Zi and Zn are discoura*ed for all "ut te smallest

loop conte7ts. If a loop contains more tan 10 lines of code9 te inde7 varia"les sould ave more descriptive names.

Constants

Constants may contain "ot alpanumeric caracters and underscores. %um"ers are not permitted in constant names.

-ll letters used in a constant name must "e capitaliAed9 wile all words in a constant name must "e separated "y

underscore caracters.

or e7ample 0MA1'FO.D'Ris permitted "ut 0MA1'FO.D'R is not.

Constants must "e defined in te *lo"al scope wit te define function9 in te constants.pp file only.

Control Structures

Tese include if9 for9 foreac9 wile9 switc etc.

Control statements sould ave one space "etween te control eyword and openin* parentesis9 to distin*uis tem from

function calls.

/races =X Y> are to "e used for all control structures9 even in situations were tey are tecnically optional. Favin* tem

increases reada"ility and decreases te lieliood of lo*ic errors "ein* introduced wen new lines are added.

-ll comparison operators witin a control structure must "e prefi7ed and suffi7ed wit a space caracter for reada"ility.

Switc statements must contain a default case.

If a "rea is omitted from a switc statement9 to allow a case to flow trou* to te ne7t case9 it must "e replaced "y a

comment to tis effect to prevent it "ein* perceived as a lo*ic error.

Test Plan Document Student Information System 2(


28/37

U:pp

if ==condition1> [[ =condition2>> X

action1K

Y elseif ==condition$> \\ =condition4>> X

action2K

Y else X

defaultactionK

Y

:V

Split long if statements onto several lines

en te if clause e7ceeds te caracterline limit9 it is "est to simplify it.

In suc cases9 it is advisa"le to e7press conditions as varia"les and compare tem in te if=> condition. Tis as te"enefit of namin* and splittin* te condition sets into smaller9 "etter understanda"le cuns@



29/37

U:pp

Zis?foo N =Zcondition1 [[ Zcondition2>K

Zis?"ar N =Zcondition$ \\ Zcondtion4>K

if =Zis?foo \\ Zis?"ar> X

....

Y

:V

Fowever9 lon* if statements may also "e split onto several lines. Te conditions ave to "e positioned onto te followin*

line9 and indented 4 caracters.

Te lo*ical operators =\\9 [[9 etc.> sould "e at te "e*innin* of te line to mae it easier to comment =and e7clude> te

condition. Te closin* parentesis and openin* "race must "e placed on teir own line at te end of te conditions.

Geepin* te operators at te "e*innin* of te line as two advanta*es@ It is trivial to comment out a particular line durin*

development wile eepin* syntactically correct code =e7cept of course te first line>.

urter9 te lo*ic ept at te front were itQs not for*otten. Scannin* suc conditions is very easy since tey are ali*ned

"elow eac oter.

U:pp

if ==Zcondition1

[[ Zcondition2>

\\ Zcondition$

\\ Zcondition4

> X

code ere

Y

:V

Te first condition may "e ali*ned to te oters.

U:pp

if = Zcondition1

[[ Zcondition2

[[ Zcondition$

> X

code ereY

:V

Ternary operators

Te same rule as for if clauses also applies for te ternary operator. It may "e split onto several lines9 eepin* te 'uestion

mar and te colon at te front.

U:pp

Za N Zcondition1 \\ Zcondition2

: Zfoo @ Z"arK

Test Plan Document Student Information System 2+


30/37

Z" N Zcondition$ \\ Zcondition4

: Zfoo?man?tis?is?too?lon*?wat?sould?i?do

@ Z"arK

:V

Strin*s

String .iterals

en a strin* is literal =contains no varia"le su"stitutions>9 te apostrope or sin*le 'uote sould always "e used to

demarcate te strin*@

Za N Q87ample Strin*QK

String .iterals &ontaining Apostrophes

en a literal strin* itself contains apostropes9 it is permitted to demarcate te strin* wit 'uotation mars or dou"le

'uotes. Tis is especially useful for S6< statements@

Zs'l N S8K

It is permitted to declare multi&line inde7ed arrays usin* te array construct. In tis case9 eac successive line must "e

padded wit spaces suc tat "e*innin* of eac line is ali*ned@

Zsample-rray Narray=19 29 $9 QIntenseQ9 QDesi*nQ9

Za9 Z"9 Zc9

5.449 Zd9 500>K

-lternately9 te initial array item may "e*in on te followin* line. If so9 it sould "e padded at one indentation level

*reater tan te line containin* te array declaration9 and all successive lines sould ave te same indentationK te

closin* paren sould "e on a line "y itself at te same indentation level as te line containin* te array declaration@

Zsample-rray Narray=

19 29 $9 QIntenseQ9 QDesi*nQ9 Za9 Z"9 Zc9

5.449 Zd9 5009

>K

Test Plan Document Student Information System $0
http://www.php.net/arrayhttp://www.php.net/arrayhttp://www.php.net/arrayhttp://www.php.net/arrayhttp://www.php.net/arrayhttp://www.php.net/arrayhttp://www.php.net/arrayhttp://www.php.net/arrayhttp://www.php.net/array


31/37

en usin* tis latter declaration9 we encoura*e usin* a trailin* comma for te last item in te arrayK tis minimiAes te

impact of addin* new items on successive lines9 and elps to ensure no parse errors occur due to a missin* comma.

Classes

&lass Declaration

Te "race sould always "e written on te same line as te class name. 8very class must ave a documentation "loc tat

conforms to te PFPDocumentor standard.

-ll code in a class must "e indented wit four spaces. !nly one class is permitted in eac PFP file.

Placin* additional code in class files is permitted "ut discoura*ed. In suc files9 two "lan lines must separate te class

from any additional PFP code in te class file.

Te followin* is an e7ample of an accepta"le class declaration@

^^

^ Documentation /loc Fere

^

class Sample?Class X

all contents of class

must "e indented four spaces

Y

Classes tat e7tend oter classes or wic implement interfaces sould declare teir dependencies on te same line wen

possi"le.

class SampleClass e7tends oo?-"stract implements /ar?Interface X

Y

If as a result of suc declarations9 te line len*t e7ceeds te ma7imum line len*t9 "rea te line "efore te e7tends

andor implements eywords9 and pad tose lines "y one indentation level.

class Sample?Class

e7tends oo?-"stract

implements /ar?Interface X

Y

If te class implements multiple interfaces and te declaration e7ceeds te ma7imum line len*t9 "rea after eac comma

separatin* te interfaces9 and indent te interface names suc tat tey ali*n.

class Sample?Class

implements /ar?Interface9

/aA?Interface X

Y



32/37

Function and Method Declaration

)etods inside classes must always declare teir visi"ility "y usin* one of te private9 protected9 or pu"lic modifiers.

-s wit classes9 te "race sould always "e written on te same line as te function name. Space "etween te function

name and te openin* parentesis for te ar*uments is not permitted.

unctions in te *lo"al scope are stron*ly discoura*ed.

Te followin* is an e7ample of an accepta"le function declaration in a class@

^^^ Documentation /loc Fere

^

class oo X

^^

^ Documentation /loc Fere

^

pu"lic function "ar=> X

all contents of function

must "e indented four spaces

YY

Functions

8very function9 includin* o"#ect metods9 must ave a doc"loc tat contains at a minimum@

- description of te function

-ll of te ar*uments

-ll of te possi"le return values

It is not necessary to use te Eaccess ta* "ecause te access level is already nown from te pu"lic9 private9 or

protected modifier used to declare te function.

If a function or metod may trow an e7ception9 use Etrows for all nown e7ception classes@

Etrows e7ceptionclass MdescriptionO

unction Calls

unctions sould "e called wit no spaces "etween te function name9 te openin* parentesis9 and te first parameterK

spaces "etween commas and eac parameter9 and no space "etween te last parameter9 te closin* parentesis9 and tesemicolon.

or e7ample@

U:pp

Zvar N foo=Z"ar9 Z"aA9 Z'uu7>K

:V

-s displayed a"ove9 tere sould "e one space on eiter side of an e'uals si*n used to assi*n te return value of a

function to a varia"le. In te case of a "loc of related assi*nments9 more space may "e inserted to promote reada"ility@

U:pp

Zsort N foo=Z"ar>K



33/37

Zlon*?varia"le N foo=Z"aA>K

:V

To support reada"ility9 parameters in su"se'uent calls to te same functionmetod may "e ali*ned "y parameter name@

U:pp

Ztis&VcallSomeunction=Qparam1Q9 QsecondQ9 true>K

Ztis&VcallSomeunction=Qparameter2Q9 QtirdQ9 false>K

Ztis&VcallSomeunction=Q$Q9 Qverrrrrrylon*Q9 true>K

:V

Split function call on several lines

en te function call as a lar*e amount of parameter tat e7ceeds te caracterline limit9 it is allowed to split

parameters in function calls onto several lines.

U:pp

Ztis&Vsome!"#ect&Vsu"!"#ect&VcallTisunctionit-


34/37

>K

:V

%estin* tose function parameters is allowed if it elps to mae te code more reada"le9 not only wen it is necessary

wen te caracters per line limit is reaced.

,sin* fluent application pro*rammin* interfaces often leads to many concatenated function calls. Tose calls may "e split

onto several lines. en doin* tis9 all su"se'uent lines are indented "y 4 spaces and "e*in wit te &V arrow.

U:pp

Zsome!"#ect&Vsomeunction=some9 parameter>

&Vsome!terunc=2$9 42>

&Vand-Tirdunction=>K

:V

Haria"le -ssi*nments

-li*nment of assi*nments

To support reada"ility9 te e'ual si*ns may "e ali*ned in "loc&related assi*nments@

U:pp

Zsort N foo=Z"ar>K

Zlon*er N foo=Z"aA>K

:V

Te rule can "e "roen wen te len*t of te varia"le name is at least 3 caracters lon*ersorter tan te previous one@

U:pp

Zsort N foo=Z"ar>K

ZtisHaria"le%ameIsHeeeeeeeeeery>K

:V



35/37


36/37

1&. ,ppendi9 4( Scope and Mandatory e)uirementsFeature Functionalities Required

Master Data Management

-llow respective administrators to

mana*e te master data suc as

Room Details9 Pro*ram Data9

Su"#ect Data

4. -llow administrators to update master data includin*

room details9 pro*ram data and su"#ect data

5. -llow Bsuper; administrator users to define access

privile*es to master data elements

Student Data Management

-ll respective administrators to

mana*e te student data includin*

attendance data9 acievement data9

"eaviour data9 contact details9

timeta"les9 alternative pro*ramsdata and oter information

$. -llow administrators to update student data element

4. 8nforce "usiness rules to ensure te inte*rity of student

data

. -llow Bsuper; administrator users to define access

privile*es to student data elements

Access/Search

-llow te users to searc for

re'uired information easily

5. -utoriAed users sould "e a"le to view information as

re'uired.

. -llow a multi dimensional searc "ased upon eyword9

id9 name9 description9 notes etc.

(. Include multiple types of searc criteria suc as e7act

matc9 partial matc9 wildcard searc etc.

3. -utoriAed users only sould "e a"le to 'uery terelevant information.

Reporting

-llow users to *enerate summary

and detailed reports on student

data.

4. -llow *eneration of period administrative reports suc

as montly attendance reports.

5. -llow *eneration of summary reports suc as total

num"ers of students "y eac class.

. -llow *eneration of detailed reports suc as all students

enrolled in a class or pro*ram of study.

Administrative Tools

-dministrators sould "e a"le to

mana*e te report;s administration

and confi*uration

4. Te administrators sould "e a"le to mana*e te users

& Reports on users of te system

& Tools to remove users from te system

& Define access privile*es for users

& Run maintenance tass =T/C>

5. -udit te usa*e of te system

. Run audit reports for activities in te system

Test Plan Document Student Information System $


37/37

14. ,ppendi9 !( Security e)uirements1. Te pa*es are only accessi"le to te users tat ave access to te pa*e.

2. Te protected pa*es are only accessi"le to lo**ed in users.

$. Te te7t fields only allow valid input.

4. Te te7t fields filter out any S6< in#ection attempts.

5. Te files on te we" server are not remotely accessi"le =allow?url?open and allow?url?include are not allowed>

. Te directory traversal is disa"led.

(. Te lo*in pa*e is secured usin* SS< certification.

3. -ll data validations are validations on te server side as a minimum =even if tere is client side validation>.

+.

10. -ll server softwares are patced wit latest software.

11. !nly data"ase and we" server are runnin*. !ter services suc as S)TP are disa"led on te server.