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

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 1unctionality Testin* -pproac.................................................................................................................................11 2.5 ,ser -cceptance Testin* -pproac...........................................................................................................................11 2. 2ustification............................................................................................................................................................... 11 $. Testin* Sc.edule and Resourcin*...................................................................................................................................12 $.1 Testin* Delivera"les.................................................................................................................................................12 $.2 Testin* Resources.....................................................................................................................................................12 $.$ Testin* Sc.edule.......................................................................................................................................................1$ 4. Testin* 1ocus.................................................................................................................................................................. 14 4.1 1unctional -rea for Testin* 1ocus............................................................................................................................14 4.2 %on&1unctional -rea for Testin* 1ocus....................................................................................................................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* C.ec4lists...........................................................................................................................................................20 3.1 5e" System Security C.ec4list................................................................................................................................20 3.2 Internal Code 6uality C.ec4list................................................................................................................................21 +. References....................................................................................................................................................................... 22 10. -ppendi7 1 & ,sa"ility Testin* 8valuation S.eet.........................................................................................................2$ Tas4 Instructions.........................................................................................................................................................2$ Test Plan Document Student Information System 2

!"serve steps ta4en.....................................................................................................................................................2$ If user does not follow t.e 4nown pat.9 w.at did t.ey clic4 on:.................................................................................2$ ,ser;s ver"al comments..............................................................................................................................................2$ 6uality C.ec4list............................................................................................................................................................ 24 11. -ppendi7 2 & Internal 6uality Testin* 8valuation S.eet..............................................................................................25 12. Test Trac4in* Spreads.eet...........................................................................................................................................$5 1$. -ppendi7 4& Scope and )andatory Re'uirements.......................................................................................................$ 14. -ppendi7 5& Security Re'uirements............................................................................................................................$(

Modification History
Version "! "!+ Date (/") to ,/") -/"( Authors Pro0ect Team Pro0ect Team Summary of Changes Document Drafted Document u1dated after consu$tation wit% 1ro0ect $eader

Test Plan Document

Student Information System

Glossary
Term Name /e.aviour Incident !n Demand Results System Principles ,)< 8R !!-D IIS TP Definition Student "e.aviour includin* fi*.ts9 disputes etc Same as "e.aviour T.e twice an year e7ams done "y students Sc.ool users wit. .i*.er level of privile*es ,nified )odellin* <an*ua*e 8ntity Relations.ip !"#ect !riented -nalysis and Desi*n Internet Information Server Test Plan

Test Plan Document

Student Information System

1. Scope
1.1 Identification.
T.e Student Information System =referred to as SIS from .ere onwards in t.is document> is identified "y t.e acronym SIS =Student Information System>. T.is document is t.e Software Test Plan document identified "y SIS?TP v1.0.

1.2 Purpose of Document.

T.e purpose of t.is document is to provide a test plan document t.at defines a plan and test cases for t.e 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 System development pro#ect. T.e document is developed for t.e purpose of readin* and review "y t.e followin* parties@ 1. Development Team 2. Desi*n Team $. -nalysis Team 4. Data -ssistant ,sers T.e document must "e used "y t.e a"ove parties in strict confidence.

1.2 System overview.

T.e Client !r*aniAation .as identified t.at t.ey are now collectin* a ran*e of data a"out t.eir students includin* attendance data9 ac.ievement data9 "e.aviour data9 contact details9 timeta"les9 alternative pro*rams data and ot.er information. T.e ultimate aim is to develop a unified IT System for administrative staff9 academic staff and mana*ement w.ic. will populate a centraliAed information system. T.is information system will t.en also "e a"le to e7pose t.e information collected to individual staff mem"ers in a usa"le and efficient manner. )a#or o"#ectives of t.is pro#ect are@ Provide a sin*le consistent *ateway to student data for all levels of sc.ool administration staff9 Create a consistent9 easy to use9 accessi"le and secure system around t.e needs of sc.ool administration and mana*ement9 Deliver a unified student information mana*ement system to allow administrators and academics to perform t.eir respective tas4s efficiently9 Simplify t.e 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 5or4 /rea4down Structure Client )eetin*s and Status Reports System Re'uirements Specification Software Desi*n Document Test Plan Document Student Information System 5

1.! "est Plan Scope.

1.!.1 #$%ectives T.e purpose of t.is 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 tested Note@ T.e 4ey features and functionalities of t.e system to "e tested are listed "elow. Feature Master Data Management -llow respective administrators to mana*e t.e master data suc. as Room Details9 Pro*ram Data9 Su"#ect Data Functionalities Required 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 t.e student data includin* attendance data9 ac.ievement data9 "e.aviour data9 contact details9 timeta"les9 alternative pro*rams data and ot.er information

1. -llow administrators to update student data element 2. 8nforce "usiness rules to ensure t.e inte*rity of student data $. -llow Bsuper; administrator users to define access privile*es to student data elements

Access/Search -llow t.e users to searc. for re'uired information easily

Reporting -llow users to *enerate summary and detailed reports on student data.

1. -ut.oriAed users s.ould "e a"le to view information as re'uired. 2. -llow a multi dimensional searc. "ased upon 4eyword9 id9 name9 description9 notes etc. $. Include multiple types of searc. criteria suc. as e7act matc.9 partial matc.9 wildcard searc. etc. 4. -ut.oriAed users only s.ould "e a"le to 'uery t.e relevant information. 1. -llow *eneration of period administrative reports suc. as mont.ly 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. 1. T.e administrators s.ould "e a"le to mana*e t.e users & Reports on users of t.e system & Tools to remove users from t.e system & Define access privile*es for users

Administrative Tools -dministrators s.ould "e a"le to mana*e t.e report;s administration and confi*uration

Test Plan Document

Student Information System

Feature

Functionalities Required & Run maintenance tas4s =T/C> 2. -udit t.e usa*e of t.e system $. Run audit reports for activities in t.e system

1.!.& 'on(functional re)uirements to $e tested T.e non functional re'uirements of t.e system t.at need to "e tested include@ Operational Requirements T.e system s.ould provide 100C uptime. T.e system must "e tec.nolo*ically9 functionally and operationally feasi"le for at least 5 years from *o live. T.e system must provide different levels of access for users T.e system must .ave a .i*. level of accessi"ility and usa"ility

Security Requirements Confidential data s.ould only "e viewa"le "y aut.orised personnel. Different types of user *roups are to "e created wit. different roles and privile*es. erformance Requirements T.e system s.ould "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 T.e system must "e ro"ust suc. t.at additional developmentDmaintenance on t.e system can "e performed wit.out any ma#or restructure of t.e system

1.!.4 "eam Mem$er Details T.e followin* ta"le contains t.e names of Tec.!ne team mem"ers wit. t.eir roles and responsi"ilities@ )em"er %ame Saud -ldawis. Student Id@ $00+(1+5 smdowis.E.otmail.com Contact %o@ 0421 4+51$ Role /usiness -nalyst Responsi!ilities -nalyse9 understand and document t.e processes in system;s current state. - Identify sta4e.olders and devise a communication plan. - Identify and document all "usiness9 tec.nical and process re'uirements. - 5or4 wit. users to prioritiAe and rationaliAe t.e re'uirements. - Felp Pro#ect )ana*er in definin* acceptance criteria for t.e pro#ect. - Felp Pro#ect )ana*er in Student Information System S"ills -nalytical and investi*ative s4ills Process )odellin* Data )odellin* Specification writin* and "usiness writin* Interpersonal communication s4ills Presentation and trainin* s4ills Gnowled*e of "ot. traditional and a*ile software development tec.ni'ues <eaders.ip s4ills (

Test Plan Document

-"dulra.man -ltoi"i Student Id@ $00321(1 )r?altoomE.otmail.com Contact No: 04 !"#$!

System Desi*ner D Pro*rammer

"usy period writin* and reviewin* documentation. Desi*n .i*. level software infrastructure. Desi*n prototypes and models accordin* to user re'uirements. -ssist "usiness analysts in desi*nin* use case dia*rams and use case scenarios. Felp pro*rammers in desi*nin* unified modellin* dia*rams9 entity relations.ip dia*rams9 data flow dia*rams9 moc4 screens and wire frames. Felp in code reviews and code 'uality assurance.

,nified modellin* tec.ni'ues !"#ect !riented desi*n and analysis s4ills Data"ase desi*n and development s4ills 5ell developed codin* s4ills in & 5e" "ased tec.nolo*ies includin* -SP.%8T and PFP & D/)S systems includin* )yS6<9 !racle and )S -ccess

1iras -l.amad Student Id@ $00+34+3 feras.al.amadE.otmail.com Contact %o@ 040251+($$

Pro*rammer

1a.ad -lya.ya Student Id@ $003+051 fa.ad12E.otmail.com.au Contact %o@ 0410155+++

Tester

-ssist "usiness analysts in documentin* "usiness re'uirements. 5or4 wit. "usiness analysts and system desi*ner to convert t.e "usiness re'uirements into a tec.nical desi*n. ,nderta4e pro*ram desi*n. 5rite code to meet pro*ram desi*n specifications. )odify code to correct errors or en.ance t.e pro*ram desi*n. Prepare documentation for ot.er pro*rammers and support personnel. -dvise /usiness -nalysts9 System Desi*ner on functional aspects of t.e system. Felp t.e pro#ect mana*er9 'uality mana*er in developin* a 'uality plan and acceptance criteria. /uild test plans /uild test scripts 87ecute test scripts Felp t.e pro#ect mana*er and "usiness analysts developin* a ris4 mana*ement plan wit. miti*ation strate*ies. Conduct t.e tec.nical and functional testin* =1ollow t.e H&)odel of testin*>

Data"ase desi*n and development s4ills 5ell developed codin* s4ills in & 5e" "ased tec.nolo*ies includin* -SP.%8T and PFP & D/)S systems includin* )yS6<9 !racle and )S -ccess

Test Plan development s4ills Test script development and e7ecution s4ills Proficient in use of test tools suc. as 6uality Centre S4illed in functional9 tec.nical and 'uality testin* ,ser acceptance testin* s4ills

Test Plan Document

Student Information System

2. "estin* Strate*y
T.e test met.odolo*y will "e 4ept li*.twei*.t and simple. T.e standard testin* practices will "e used as outlined "elow.

2.1 +sa$ility "estin* ,pproac-.

T.e usa"ility testin* will "e tested "y 1. Conductin* re*ular reviews of t.e user interface to ensure it meets t.e usa"ility *uidelines of top ten usa"ility .euristics

%ielsen 2a4o" =2004>. Ten ,sa"ility Feuristics9 retrieved online from .ttp@DDwww.useit.comDpapersD.euristicD.euristic?list..tml

T.e ten principles of %ielsen will "e applied in t.e followin* way@

#isi!ility of system status T.e user will always see t.e current navi*ation pat.9 t.e mode of data"ase operation =addDeditDdeleteDupdate>.

Match !et$een system and the real $orld T.e lan*ua*e used for navi*ation elements9 field names and messa*es will "e 4ept very person and will "e reviewed to ensure t.ere is no terminolo*y t.at t.e end user can not relate to. T.is will "e covered durin* usa"ility testin* w.ere peer students from ot.er discipline =suc. as arts> will "e as4ed to review t.e lan*ua*e used in t.e system.

%ser control and freedom T.e users will always "e *iven t.e option to cancel out of an operation if t.ey c.an*e t.eir mind. T.is will "e ac.ieved "y as4in* t.e user for review all re'uests. -t t.e time of review9 t.ey will "e as4ed to cancel or commit t.e action.

&onsistency and standards T.e user controls will "e 4ept similar to w.at t.e user e7pects to find in ot.er ma#or we"sites suc. as Internet /an4in*9 Social %etwor4in* etc. T.is will .elp t.e user feel familiar wit. t.e system strai*.t away.

T.e stylin* will "e 4ept consistent t.rou*.out t.e site.

'rror prevention Student Information System +

Test Plan Document

T.e users will "e restricted from performin* invalid actions "y restrictin* t.e invalid actions on user interface. 1or e7ample9 o o if a user does not .ave access to a menu item9 t.e menu item won;t "e s.own. if a record is not availa"le for deletion9 t.en delete option will not "e availa"le on t.e record.

Recognition rather than recall T.e user will always "e presented wit. relevant options so t.at t.ey do not .ave to t.in4. T.e users will rat.er .ave to #ust select t.e actions.

Fle(i!ility and efficiency of use T.e e7pert users will "e *iven t.e option to perform super&user li4e functions suc. as import and e7port file9 perform operations on "ul4 records.

Aesthetic and minimalist design T.e information will "e relevant and applica"le only.

)elp users recogni*e+ diagnose+ and recover from errors T.e error messa*es will contain t.e followin* elements as a minimum@ o o T.e cause of error T.e actions t.at can "e ta4en to correct t.e error

)elp and documentation o o - compre.ensive user manual will "e produced If t.e user re'uires 4nowin* a particular "usiness rule9 t.en t.e information will "e presented on t.e relevant screen=s>.

2. Conduct a formal user acceptance testin* p.ase at t.e end of t.e pro#ect

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

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

T.e "as. testin* approac. is to test early ="y developers> to remove as many "u*s as possi"le9 as early in t.e process as possi"le. It is a common pro"lem t.at t.ere are some o"vious "u*s left t.e system after development .as #ust "een finis.ed. T.erefore9 if t.e developers can run some 'uic4 tests as t.ey develop9 most of t.e o"vious "u*s can "e removed at t.at sta*e. Test Plan Document Student Information System 10

T.e developers will "as. test t.e system as eac. component or module in t.e system is developed. T.is approac. will .elp in eliminatin* any of t.e o"vious "u*s from t.e system. T.is will ensure t.at t.e testers will "e dealin* wit. t.e more comple7 issues. T.e testers will "e a"le to focus on "u*s t.at are comple7 and related to t.e core functionality rat.er t.an simple issues t.at can easily "e identified durin* development.

2.4 /unctionality "estin* ,pproac-.

T.e functionality testin* approac. entails testin* t.e system provides IcompleteJ and IaccurateJ functionality. T.e approac. for t.is 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 t.e system T.e functionality will "e tested "y t.e testers in a formal testin* manner. T.e testers will create test cases and collect test data. T.ere will "e formal reviews of t.e test cases wit. developers9 analysts and testers in t.e same room. -fter t.e test cases .ave "een reviewed for accuracy and compre.ensiveness9 t.e testers will manually run t.e tests a*ainst t.e developed system and identify any discrepancies "etween t.e SRS and Desi*n %ote documents. T.ese "u*s will "e verified "y "usiness analysts and t.en corrected "y t.e developers. T.e cycle will continue until all "u*s .ave "een identified and resolved.

2.! +ser ,cceptance "estin* ,pproac-.

T.e user acceptance testin* is conducted to ensure t.at t.e client is .appy wit. all aspects of t.e system t.at .as "een delivered. T.e system is deployed on t.e client site and t.e client is *iven one wee4 to test t.e system to ensure t.ey are .appy wit. internal and e7ternal 'uality of t.e system. T.e informal user acceptance testin* will "e conducted wit. 4& peer students. T.e students will "e *iven some test files and tas4s to perform. T.e users will not "e provided any testin* scripts since one of t.e purposes of user acceptance testin* will "e to identify t.at t.e system is easy to use and learn wit.out any formal trainin*. T.e client will "e as4ed to perform t.e formal user acceptance testin* to accept t.e delivery of t.e software.

2.0 1ustification
T.e wide ran*e of testin* approac.es .as "een used to adapt a fle7i"le and compre.ensive testin* approac.. T.e "rief rationale for eac. of t.e testin* approac.es includes@ 1. T.e "as. testin* approac. will "e used to remove t.e lar*e and o"vious "u*s earlyK 2. T.e testers will perform compre.ensive functional testin* =usin* manually defined test cases> to ensure t.e system functionality is IcompleteJ and IaccurateJ $. T.e usa"ility testin* will test t.e ease of use9 relia"ility9 efficiency9 e7tensi"ility and ot.er internal and e7ternal 'uality factors. 4. T.e user acceptance testin* will ensure t.at t.e client is .appy wit. t.e delivered product.

Test Plan Document

Student Information System

11

&. "estin* Sc-edule and

&.1 "estin* Delivera$les

esourcin*

In addition to t.e 'uality event .eld t.rou*.out t.e development9 strin*ent testin* will "e done on t.e final delivera"le. 1ollowin* ta"le demonstrates t.e final testin* t.at will "e underta4en on eac. of t.e 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 t.e completion of Pro#ect Plan "efore t.e formal si*n&off System Requirement Specifications Testing Type@ Prototype /uilds =Part of desi*n p.ase> -ho@ /usiness -nalysts and System Desi*ner -hen@ Durin* t.e desi*n p.ase of t.e pro#ect Design Documents Testing Type@ Review )eetin*s -ho@ /usiness -nalysts9 System Desi*ner and Pro*rammers -hen@ -fter t.e desi*n documents .ave "een produced and "efore t.e completion of desi*n p.ase Technical Development Testing Type@ 1ormal testin* p.ase -ho@ see ne7t point -hen@ see ne7t point Testing Testing Type@ 1ormal testin* met.odolo*y -ho@ Testin* Team9 some end user involvement9 some pro*rammer =coder> involvement -hen@ -t t.e conclusion of tec.nical development roduct Documentation Testing Type@ ,ser Reviews9 )oc4 run t.rou*. -ho@ Trainin* Team9 /usiness -nalysts9 8nd ,sers -hen@ 2ust "efore t.e system *o live

&.2 "estin*

esources

T.e roles and responsi"ilities for t.e testin* of t.e solution .ave "een defined for eac. applica"le role wit.in t.e pro#ect team@ Role Developer Tester Testing Responsibilities Test Plan Document 87ecute unit tests. 8nsure all unit testin* "u*s are corrected. -ssist t.e testers in validatin* t.at a certain issue is a "u* or not. Felp t.e pro#ect mana*er9 'uality mana*er in developin* a 'uality plan and acceptance criteria. /uild test plans /uild test scripts 87ecute test scripts Student Information System 12

/usiness -nalysts -

Pro#ect )ana*er

Felp t.e pro#ect mana*er and "usiness analysts developin* a ris4 mana*ement plan wit. miti*ation strate*ies. Provide assistance to developers and testers in understandin* t.e re'uirements Provide assistance to testers in preparin* test cases Conduct reviews of t.e test plans wit. testers to ensure t.e test covera*e is compre.ensive Provide sc.edulin* and estimatin* assistance to t.e rest of t.e team for testin* re'uirements !verloo4 t.e process of trac4in* "u*s and rectifyin* t.em to ensure t.e 'uality is delivered Provide assistance to t.e team in creatin* and si*nin* off a test plan

&.& "estin* Sc-edule

Test Phase ,nit Testin* Description of task T.e individual units of t.e code will "e tested. T.is testin* will "e performed "y t.e developers =/as. testin*>. Resource Name(s) -"dulra.man -ltoi"i 1iras -l.amad Dates 25 -u*ust to 25 !cto"er =System Development Cycle> 25 !cto"er to 2 %ovem"er =Testin* Cycle> System Testin* T.e system;s functional testin* will "e completed durin* t.is p.ase. /as. testin* will "e performed "y t.e developers and t.e functional testin* =formal> will "e performed "y t.e tester =1a.ad -lya.ya> Inte*ration Testin* T.e inte*ration testin* will "e performed "y t.e developments =/as. inte*ration testin*> and t.e testers -"dulra.man -ltoi"i 1iras -l.amad 1a.ad -lya.ya 25 -u*ust to 25 !cto"er =System Development Cycle> 2 %ovem"er to + %ovem"er =Testin* Cycle>

-"dulra.man -ltoi"i 1iras -l.amad 1a.ad -lya.ya

2 %ovem"er to + %ovem"er =/as. Inte*ration Testin*> 2 %ovem"er to + %ovem"er =Testin* Cycle>

,sa"ility Testin*

T.e usa"ility testin* will "e performed wit. students. T.e testers will run t.e system a*ainst t.e prescri"ed testin* c.ec4lists to test t.e usa"ility.

1a.ad -lya.ya Peer students =4& students>

15 %ovem"er to 25 %ovem"er

Security and 6uality Testin*

1. Presentation layer security to "e tested "y t.e testers. 2. T.e system;s tec.nical security will "e tested "y developers.

1iras -l.amad 1a.ad -lya.ya Peer students =4& students>

15 %ovem"er to 25 %ovem"er

Test Plan Document

Student Information System

1$

,ser -cceptance Testin*

T.e user acceptance testin* will "e completed "y t.e 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 t.e Software Re'uirement Specification Document will "e tested. T.e detailed test cases .ave "een defined in Section ( ,nit Test Cases.

4.2 'on(/unctional ,rea for "estin* /ocus

T.e followin* non functional areas will "e tar*eted for testin*@ 1> ,ser Security 1. ,ser lo*in security@ T.e passwords will "e tested to ensure t.ere are secure. a. %ot same as t.e user name ". %ot same as user;s name c. %ot same as email address 2. Security of screens and reports as determined "y t.e security privile*es set up in t.e system a. !nly t.e options t.at t.e user .as access to will "e displayed $. Test to ensure stron* passwords a. Contain at least one alp.a"et9 num"er and special sym"ol 4. Test to ensure S6< in#ection attac4s are stopped.

2> System Security 1. Test to ensure t.at t.e secure pa*es are not accessi"le wit.out lo**in* in. 2. Test to ensure t.e system cannot "e .i#ac4ed via D%S attac4s. a. If more t.an 10 re'uests are received "y a pa*e =in a *iven second>9 t.en t.e system s.ould not entertain any more re'uests from t.at IP -ddress

$> ,sa"ility Testin* 1. Test to ensure usa"ility *oals identified in t.is document. a. T.e usa"ility testin* will "e conducted "y as4in* 4 to 5 peer students to use t.e system and provide o"#ective and su"#ective feed"ac4 on t.e system 'uality.

See -ppendi7 1 L ,sa"ility Testin* 8valuation S.eet Test Plan Document Student Information System 14

4> Internal 6uality Testin* 1. Test to ensure t.e main a"ility9 e7tensi"ility and understanda"ility of t.e code. See -ppendi7 2 LInternal 6uality Testin* 8valuation S.eet T.ere will "e no ot.er performance testin* e7cept t.e efficiency testin* conducted durin* "as. testin*. T.e system is very li*.twei*.t wit. only up to 5 simultaneous users. T.erefore9 t.ere is no need to spend time on performance testin* in t.is pro#ect w.ic. is runnin* under very ti*.t timelines already.

Test Plan Document

Student Information System

15

!. "est

esult ,dministration

T.e testin* tools D "u* trac4in* will "e performed usin* li*.t wei*.t testin* tools. -n e7cel spreads.eet will "e maintained containin* all "u*s and status of t.e "u*. See -ppendi7 $ L Test Trac4in* Spreads.eet T.e process followed for maintainin* t.e "u*s will "e@
/u* re'uires /assistant

%ew /u* Recorded

/u* -ssi*ned to //- confirmed "u*

/u* re'uires developer to fi7 t.e "u*

/u* -ssi*ned to Developer

T.e "u* .as not "een fi7ed

/u* fi7ed

/u* -ssi*ned to tester for verification

/u* Closed

/u* fi7ed

T.e test cases will "e stored in a s.ares e7cel spreads.eet amon*st t.e team mem"ers. T.e process for updatin* t.e testin* spreads.eet will "e@ 1> Testers will "e a"le to record new "u*s. %ew "u*s are to "e mar4ed wit. /u* Type =Data /u*9 1ront 8nd /u* and /usiness <o*ic /u*> and mar4ed wit. a status of Open. T.e "u*s can "e assi*ned to a particular developer to fi7. T.e types of "u*s will "e classified accordin* to@ a. Data /u*@ Data "u* will occur w.en t.e pre&defined data setup =e.*. pre&set users .ave not "een set up correctly>. ". 1ront 8nd /u*@ T.e front end =presentation layer> .as a pro"lem in renderin* data incorrectlyK or any of t.e la"ellin* is incorrect. c. /usiness <o*ic /u*@ T.e system is "e.avin* adversely to t.e "usiness rules. d. ,sa"ility Issue@ T.ere is an issue wit. t.e system usa"ility. e. Security Issue@ T.ere is a security issue in t.e system. 2> T.e developers will "e a"le to fi7 t.e "u*s and put into Retest. T.e developers will fi7 t.e "u*s into Development environment first to ensure t.ey can "e tested "y developers t.emselves. T.en t.ey will apply t.e "u* into System Test environment for t.e developers to fi7.

Test Plan Document

Student Information System

$> T.e testers will need to test t.e "u*s put into Retest and if t.ey are .appy t.at t.e "u* .as "een fi7ed9 t.ey will put t.e "u* into Deployment Pendin* mode. 4> T.e developers will apply t.e fi7 in t.e System Test environment and put t.e fi7 into Production environment.

0. ,cceptance "estin*
0.1 ,cceptance "estin* Criteria
Attachment to the Requirements

T.e delivera"les will "e accepted "y t.e client if@ & -ll scope defined in t.is pro#ect plan is met 100C & -ll mandatory re'uirements defined in t.e user re'uirements specification document are met 100C & -t least 50C of t.e wis. list re'uirements as defined in t.e user re'uirements document are met See -ppendi7 4 L Scope and )andatory Re'uirements
Usability

T.e delivera"les will "e accepted "y t.e client if@ & - user w.o .as not seen t.e system "efore can perform all tas4s in t.e user acceptance test document in an avera*e time of 5 minutes. =-tomic tas4s9 t.e time e7cludes t.e system process waitin* time>. & Client si*ns off t.e user acceptance testin* document.
Security & Control

-ll security aspects defined in t.e pro#ect plan and t.e user re'uirements must "e met 100C. See -ppendi7 5 L Security Re'uirements
Procedures & Documentation

Refers to t.e precision in t.e documentation of t.e functions and use of t.e system and t.e e7tent t.at t.e automated processes are wor4in* properly as an inte*ral part of t.e entire system. -ll Documents must "e si*ned off "y t.e respective "usiness owners and sta4e.olders. -ll Documents must pass t.e review c.ec4list.

0.2 ,cceptance "estin*

esponsi$ility

T.e responsi"ility for t.e acceptance testin* will "e of /allarat Secondary Colle*e representative )r Simon.

2. +nit "est Cases

Test Case No T1 Test Case Name and relevant use case ,se Case@ Record !n Demand Result Test Case %ame@ Test successfully recordin* an on demand result. T2 ,se Case@ Record !n Demand Result Pre Condition T.e student already e7ists in t.e system. Post Condition T.e on demand result as "een successfully recorded in t.e system. T.e on demand result could not "e recorded. -n 1(

T.e student e7ists in t.e system.

Test Plan Document

Student Information System

Test Case %ame@ Record on demand result w.en it .as already "een recorded. T$ ,se Case@ Record !n Demand Result Test Case %ame@ Record on demand result for an inactive student. T4 ,se Case@ Record /e.aviour Information Test Case %ame@ Record "e.aviour information successfully. T5 ,se Case@ Record /e.aviour Information Test Case %ame@ Record resolution for a "e.aviour incident.

T.e on demand result .as already "een entered. T.e student is inactive in t.e data"ase.

appropriate error messa*e .as "een displayed. T.e on demand result could not "e recorded. -n appropriate error messa*e .as "een displayed. T.e "e.aviour information .as "een recorded. T.e resolution is "lan4. T.e resolution .as "een recorded. -n email .as "een sent to appropriate contact=s> as per email confi*uration. T.e resolution .as "een updated. -n email .as "een sent to appropriate contact=s> as per email confi*uration T.e contact information .as "een entered in t.e system.

T.e student e7ists.

T.e student e7ists. T.e "e.aviour information e7ists. T.e resolution .as not "een entered.

,se Case@ Record /e.aviour Information Test Case %ame@ ,pdate resolution for a "e.aviour incident and ensure t.at an email is sent to appropriate contact=s> re*ardin* t.e update of t.e resolution.

T.e student e7ists. T.e "e.aviour information e7ists. T.e resolution .as already "een entered. T.e student e7ists. T.e student;s contact information .as not "een entered yet. T.e student e7ists. T.e student;s emer*ency contact information .as not "een entered yet. T.e student e7ists.

T(

,se Case@ Record Contact Information Test Case %ame@ 8nter contact information for a student.

T3

,se Case@ Record Contact Information Test Case %ame@ 8nter emer*ency contact information for a student.

T.e emer*ency contact information .as "een entered in t.e system.

T+

,se Case@ Record 5elfare Information Test Case %ame@ Record 5elfare information successfully.

T.e 5elfare information .as "een recorded.

T10

,se Case@ Record 5elfare Information Test Case %ame@ Record comment for a welfare record.

T.e student e7ists. T.e 5elfare information e7ists.

T.e comment .as "een added to t.e welfare record. -n email .as "een sent to appropriate contact=s> as per email confi*uration. T.e comment .as "een added. T.e e7istin* comment .as "een 4ept. /ot. comments .ave appropriate dates to 13

T11

,se Case@ Record 5elfare Information Test Case %ame@ -dd a new comment a*ainst welfare information and ensure t.e comment .istory is 4ept =new comment does not replace e7istin*

T.e student e7ists. T.e 5elfare information e7ists.

Test Plan Document

Student Information System

comment>

indicate w.en t.ey were addedDupdated. -n email .as "een sent to appropriate contact=s> as per email confi*uration

T12

,se Case@ <o*in to System Test Case %ame@ <o*in to system successfully.

T.e user e7ists.

T.e user .as "een lo**ed in successfully and t.ey are a"le to see t.e navi*ation on t.e left .and side. T.e user can not "e lo**ed in. 8nsure t.at t.e error messa*e is *eneric and does not provide t.e user information a"out w.et.er user id or password was invalid. T.e user can not "e lo**ed in. 8nsure t.at t.e error messa*e is *eneric and does not provide t.e user information a"out w.et.er user id or password was invalid. T.e user is a"le to access t.e screen.

T1$

,se Case@ <o*in to System Test Case %ame@ ,nsuccessful lo*in into t.e system. ,ser Id is invalid

%D-

T14

,se Case@ <o*in to System Test Case %ame@ ,nsuccessful lo*in into t.e system. Password is invalid

%D-

T15

,se Case@ <o*in to System Test Case %ame@ 8nsure t.at t.e user is a"le to access a screen for w.ic. a privile*e .as "een assi*ned to t.em.

T.e user e7ists T.e user .as appropriate privile*e to access t.e add student screen. T.e user e7ists T.e user does not .ave appropriate privile*e to access t.e add student screen. T.e student e7ists

T1

,se Case@ <o*in to System Test Case %ame@ 8nsure t.at t.e user is una"le to access a screen for w.ic. a privile*e .as not "een assi*ned to t.em.

T.e user is not a"le to access t.e screen. T.e user is sent to t.e user;s .ome screen.

T1(

,se Case@ Searc. Student Test Case %ame@ 1indin* a student successfully usin* a student id.

T.e user is a"le to find t.e student successfully.

T13

,se Case@ Searc. Student Test Case %ame@ T.e student is not a"le to find a student usin* a student id.

%D-

-n appropriate messa*e is displayed to t.e user.

T1+

,se Case@ -dd Student Test Case %ame@ -dd a student into t.e system successfully

T.e student id does not already e7ist in t.e system.

T.e student .as "een successfully added into t.e system. T.e student could not "e added. -n appropriate 1+

T20

,se Case@ -dd Student

T.e student wit. t.e id already e7ists. Student Information System

Test Plan Document

Test Case %ame@ Test t.at a student wit. duplicate student id cannot "e added into t.e system. T21 ,se Case@ -dd ,ser Test Case %ame@ -dd a user into t.e system successfully T22 ,se Case@ -dd ,ser Test Case %ame@ Test t.at a user wit. duplicate id cannot "e added into t.e system. T2$ ,se Case@ -dd ,ser Test Case %ame@ Test t.at a user wit. duplicate password can n"e added into t.e system. T24 ,se Case@ Setup Roles Privile*es Test Case %ame@ -dd a new privile*e can "e added successfully. T25 ,se Case@ Setup Roles Privile*es Test Case %ame@ 8nsure t.at privile*e cannot "e added for t.e same pa*e multiple times. T2 ,se Case@ Setup Roles Privile*es for users Test Case %ame@ -dd a new privile*e for a user successfully. T2( ,se Case@ Setup Roles Privile*es for users Test Case %ame@ 8nsure t.at same privile*e cannot "e assi*ned to a user twice. T.e user id does not already e7ist in t.e system.

messa*e is displayed on t.e screen. T.e user .as "een successfully added into t.e system. T.e user could not "e added. -n appropriate messa*e is displayed on t.e screen. T.e user .as "een added into t.e system.

T.e user wit. t.e id already e7ists.

T.e user wit. t.e user id does not e7ist. - user wit. same password e7ists.

T.ere is no privile*e for t.e same PFP pa*e already.

T.e privile*e .as "een added successfully.

T.ere is already privile*e for t.e same PFP pa*e already.

T.e privile*e could not "e added into t.e system.

T.e user .as not "een assi*ned t.at privile*e already.

T.e privile*e .as "een assi*ned to t.e user successfully. T.e pa*e is now accessi"le from t.e user lo*in. T.e privile*e could not "e assi*ned. T.e pa*e is still not visi"le under t.e user lo*in.

T.ere is already privile*e for t.e same user.

3. "estin* C-ec4lists
3.1 5e$ System Security C-ec4list
1. Try to directly access "oo4mar4ed we" pa*e wit.out lo*in to t.e system. 2. Do not si*n&on system9 directly try to download t.e file from t.e availa"le download url9 suc. as t.e input M<I%GN.ttp@DDurlDdownload:nameNfileO.ttp@DDurlDdownload:nameNfileMD<I%GO and c.ec4 if t.e systems restrict you to download t.e file. $. si*n out and t.en press t.e /ac4 "utton to access t.e pa*e accessed "efore. Test Plan Document Student Information System 20

4. ID D password aut.entication met.od@ c.ec4 wit. valid and invalid passwords9 password rules say cannot "e less t.an c.arecters9 user id and password cannot "e t.e same etc. 5. Important information =suc. as passwords9 ID num"ers9 credit card num"ers9 etc.> s.ould not *et displayed in t.e input "o7 w.en typin*. T.ey s.ould "e all encrypted and in asteri7 format. . )anually c.an*e t.e parameter value in t.e ,R< to c.ec4 if you can access special pa*es. 1or e7ample9 suppose in a we" system If ordinary users access t.e correspondin* url in t.e parameters l N e and t.e correspondin* url for advanced users in t.e parameters l N s. %ow if a user manually c.an*e t.e value from e to s it s.ould not allow you to access t.e pa*e. 12. In t.e url9 enter t.e followin* address to c.ec4 if it can "e downloaded restricted files@ M<I%GN.ttp@DDurlDdownload.#sp:fileNCO.ttp@DDurlDdownload.#sp:fileNCMD<I%GO@ P windows P system$2 P drivers P etc P .osts9 M<I%GN.ttp@DDurlDdownload.#sp:fileO.ttp@DDurlDdownload.#sp:fileMD<I%GO N D etc D passwd 1$. -fter session time out try to access restricted pa*e. 14. 8rror messa*es w.et.er t.ey contain s'l statements9 s'l error messa*es9 as well as we" serverQs a"solute pat.9 etc. 15. ID D password aut.entication9 t.e same account on different mac.ines can not lo* on at t.e same time. So at a time only one user can lo*in to t.e system wit. an user id. 1 . ID D password aut.entication met.ods9 entered t.e wron* password several times and c.ec4 if t.e account *ets loc4ed. 1(. -dd or modify important information =passwords9 ID num"ers9 credit card num"er9 etc.>. C.ec4 if it *ets reflected immeditely or cac.in* t.e old values.

3.2 Internal Code 6uality C-ec4list

1. Specification D Desi*n Is t.e functionality descri"ed in t.e specification fully implemented "y t.e code: Is only specified functionality implemented wit. no additional functionality added: Is t.e pro*ram interface implemented as descri"ed in t.e #avadocs: -re t.e #avadocs complete9 includin* D/C or 8rror c.ec4in* specs as appropriate: Does t.e code conform to t.e class codin* standard: Is t.e code correct: Does t.e code implement t.e detailed desi*n provided: =Su**estion@ perform a .and trace of t.e e7ecution to verify correctness. Does t.e implementation avoid "one.ead pro*rammin*: Is t.e code free of Rsmells:R =Duplicate code9 lon* met.ods9 "i* classes9 "rea4in* encapsulation9 etc.>

2. InitialiAation and Declarations -re varia"les and class mem"ers of t.e correct type and appropriate mode -re varia"les declared in t.e proper scope: Is a constructor called w.en a new o"#ect is desired: -re all o"#ect references initialiAed "efore use: $. )et.od Calls -re parameters presented in t.e correct order: Is t.e correct met.od "ein* called9 or s.ould it "e a different met.od wit. a similar name: -re met.od return values used properly: 4. -rrays Test Plan Document

Student Information System

21

-re t.ere no off&"y&one errors in array inde7in*: Fav all array =or ot.er collection> inde7es "een prevented from *oin* out&of&"ounds: Is a constructor called w.en a new array item is desired: 5. !"#ect Comparision -re all o"#ects =includin* Strin*s> compared wit. Re'ualsR and not RNNR: (. !utput 1ormat -re displayed output free of spellin* and *rammatical errors: -re error messa*es compre.ensive and provide *uidance as to .ow to correct t.e pro"lem: Is t.e output formatted correctly in terms of line steppin* and spacin*: 3. Computation9 Comparisons and -ssi*nments C.ec4 order of computationDevaluation9 operator precedence and parent.esisin* -re all denominators of a division prevented from "ein* Aero: Is inte*er arit.metic9 especially division9 used appropriately to avoid causin* une7pected truncationDroundin*: -re t.e comparison and "oolean operators correct: If t.e test is an error&c.ec49 can t.e error condition actually "e le*itimate in some cases: Is t.e code free of any implicit type conversions: 3. 87ceptions -re all relevant e7ceptions cau*.t: Is t.e appropriate action ta4en for eac. catc. "loc4:

7. eferences
5e" Security C.ec4list9 retrieved online on 15 -u*ust 2012 from .ttp@DDsoftware'atestin*s.comDsecurity&testin*Dwe"&security&testin*&c.ec4list..tml 2ava Code Inspection C.ec4list9 retrieved online on 13 -u*ust 2012 from .ttp@DDusers.csc.calpoly.eduDS#dal"eyD205DResourcesDInspectC.ec4list..tml

Test Plan Document

Student Information System

22

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

Task Instructions Tas4 instructions .ere Describe task Tas4 description .ere !bserve steps taken Steps

If user does not follow t.e 4nown pat.9 w.at did t.ey clic4 on: %ser Notes 1 %one

,ser;s ver"al comments %ser Notes 1 %one

Test Plan Document

Student Information System

2$

6uality C-ec4list
/randin* and visual identity T.e site ,R< .as "een a*reed. T.e standard .eader and footer .ave "een implemented9 to specification9 on all pa*es. Tuidance relatin* to t.e online colour palette .as "een ad.ered to9 especially re*ardin* luminosity and accessi"ility. T.e pa*e layout is "ased9 w.ere possi"le9 on a li'uid widt. =not fi7ed>.

Content and presentation -ll pa*es are spell c.ec4ed and contain no spellin* errors. -ll pa*es use proper *rammar and punctuation. Content .as "een c.ec4ed for accuracy and aut.enticity. Duplication of content T.ere is no duplication of content wit.in t.e site. T.e site does not duplicate content already pu"lis.ed on anot.er 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 t.e re'uired format.

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

8very pa*e .as a set of uni'ue and meanin*ful meta 4eywords in t.e re'uired format. 8very pa*e .as a uni'ue and meanin*ful U.1V ta* . T.e RaltR attri"ute on t.e Uim*V ta* is set for all descriptive ima*es. -ll .yperlin4s =internal and e7ternal>@ Fave "een c.ec4ed for appropriateness and are wor4in*. T.e lin4 te7t is descriptive and reflects t.e content of t.e destination pa*e.

Test Plan Document

Student Information System

24

-ll folderDfile names@ -re lowercase and case&insensitive. ,se only alp.anumeric c.aracters =and .yp.ens w.ere necessary>. -re descriptive and reflect t.e content of t.e pa*e.

1unctionality !n su"mission9 forms collect data in t.e re'uired format and t.e Bt.an4 you; pa*e contains an appropriate messa*e. - print style s.eet .as "een provided for all pa*es. 5.ere specific =usually interactive> content may present an additional load on t.e server9 t.at t.is functionality .as "een volume tested to a*reed metrics.

Tec.nical T.e FT)< is well&formed and is validated as BWFT)< 1.0 Strict;. 1or furt.er information see@ .ttp@DDvalidator.w$.or* T.e CSS is used appropriately to control layout and presentation and is valid. 1or furt.er information see@ .ttp@DD#i*saw.w$.or*Dcss&validatorD T.e 2avaScript .as "een tested and contains no errors. T.e site "een tested across all t.e popular "rowsers9 "ot. on a PC and a )ac. 1or furt.er information see list of current popular "rowsers amon* visitors. T.e site .as "een tested at a variety of screen resolutions. 1or furt.er information see screen resolution ran*es amon* visitors.

,pdatin* - process =eit.er "usiness or system> is in place for maintenance of t.e we"site or application. - contact for maintenance .as "een identified.

11. ,ppendi9 2 ( Internal 6uality "estin* :valuation S-eet

Reference@ www.sprin*erslc.com.auDassetsDdownloadsDwindy?.illD!verview.doc PFP 1ile 1ormattin* Test Plan Document Student Information System 25

PFP code must always "e delimited "y t.e full&form9 standard PFP ta*s@ U:p.p :V S.ort.and ta*s are not permitted. 1or files containin* only PFP code9 t.e closin* ta* must always "e omitted. It is not re'uired "y PFP9 and omittin* it prevents t.e accidental in#ection of trailin* w.ite space. <ine Termination

<ine termination follows t.e ,ni7 te7t file convention. <ines must end wit. a sin*le linefeed = .F> c.aracter. <inefeed c.aracters are represented as ordinal 109 or .e7adecimal 070-. Do not use carria*e returns =&R> as is t.e convention in -pple !SQs =070D> or t.e carria*e return & linefeed com"ination =&R.F> as is standard for t.e 5indows !S =070D9 070->. Indentin* and <ine <en*t. Indentation ,se an indent of 4 spaces9 wit. no ta"s. T.is .elps to avoid pro"lems wit. diffs9 patc.es9 SH% .istory and annotations. )a7imum <ine <en*t. T.e tar*et line len*t. is 30 c.aracters. T.at is to say9 developers s.ould strive 4eep eac. line of t.eir code under 30 c.aracters w.ere possi"le and practical. Fowever9 lon*er lines are accepta"le in some circumstances. T.e ma7imum len*t. of any line of PFP code is 120 c.aracters. %amin* Conventions Classes Class names may only contain alp.anumeric c.aracters and underscores. %um"ers are not permitted. T.e first letter of t.e class name must "e capitaliAed. If a class name is comprised of more t.an one word9 t.e first letter of eac. new word must "e capitaliAed and preceded "y an underscore. Successive capitaliAed letters are not allowed.

1or e7ample9 '(ample/ DF is not allowed w.ile '(ample/ df is accepta"le. 1unctions and )et.ods 1unction names may only contain alp.anumeric c.aracters and underscores. %um"ers are not permitted in function names. 1unction names must always start wit. a lowercase letter. 5.en a function name consists of more t.an one word9 eac. new word must "e preceded "y an underscore. Her"osity is *enerally encoura*ed. 1unction names s.ould "e as ver"ose as is practical to fully descri"e t.eir purpose and "e.avior. 1or e7ample9 Test Plan Document Student Information System 2

U:p.p pu"lic function filter?input=> X Y pu"lic function *et?element?"y?id=> X Y :V -ccessors for instance or static varia"les s.ould always "e prefi7ed wit. R*etR or RsetR. 1or e7ample9 *et?employee?name=> set?"usiness?address=> 1unctions in t.e *lo"al scope =a.4.a Rfloatin* functionsR> are permitted "ut discoura*ed in most cases. Consider wrappin* t.ese functions in a static class. Haria"les Haria"le names may only contain alp.anumeric c.aracters and underscores. %um"ers are not permitted in varia"le names. Haria"le names must always start wit. a lowercase letter. 5.en a function name consists of more t.an one word9 eac. new word must "e preceded "y an underscore. Her"osity is *enerally encoura*ed. Haria"les s.ould always "e as ver"ose as practical to descri"e t.e data t.at t.e developer intends to store in t.em. Terse varia"le names suc. as RZiR and RZnR are discoura*ed for all "ut t.e smallest loop conte7ts. If a loop contains more t.an 10 lines of code9 t.e inde7 varia"les s.ould .ave more descriptive names. Constants Constants may contain "ot. alp.anumeric c.aracters and underscores. %um"ers are not permitted in constant names. -ll letters used in a constant name must "e capitaliAed9 w.ile all words in a constant name must "e separated "y underscore c.aracters. 1or e7ample 0MA1'/FO.D'R is permitted "ut 0MA1'FO.D'R is not. Constants must "e defined in t.e *lo"al scope wit. t.e RdefineR function9 in t.e constants.p.p file only. Control Structures T.ese include if9 for9 foreac.9 w.ile9 switc. etc. Control statements s.ould .ave one space "etween t.e control 4eyword and openin* parent.esis9 to distin*uis. t.em from function calls. /races =X Y> are to "e used for all control structures9 even in situations w.ere t.ey are tec.nically optional. Favin* t.em increases reada"ility and decreases t.e li4eli.ood of lo*ic errors "ein* introduced w.en new lines are added. -ll comparison operators wit.in a control structure must "e prefi7ed and suffi7ed wit. a space c.aracter for reada"ility. Switc. statements must contain a default case. If a "rea4 is omitted from a switc. statement9 to allow a case to flow t.rou*. to t.e ne7t case9 it must "e replaced "y a comment to t.is effect to prevent it "ein* perceived as a lo*ic error. Test Plan Document Student Information System 2(

U:p.p if ==condition1> [[ =condition2>> X action1K Y elseif ==condition$> \\ =condition4>> X action2K Y else X defaultactionK Y :V

Split long if statements onto several lines 5.en t.e if clause e7ceeds t.e c.aracterDline limit9 it is "est to simplify it. In suc. cases9 it is advisa"le to e7press conditions as varia"les and compare t.em in t.e if=> condition. T.is .as t.e "enefit of Rnamin*R and splittin* t.e condition sets into smaller9 "etter understanda"le c.un4s@

Test Plan Document

Student Information System

23

U:p.p Zis?foo N =Zcondition1 [[ Zcondition2>K Zis?"ar N =Zcondition$ \\ Zcondtion4>K if =Zis?foo \\ Zis?"ar> X DD .... Y :V Fowever9 lon* if statements may also "e split onto several lines. T.e conditions .ave to "e positioned onto t.e followin* line9 and indented 4 c.aracters. T.e lo*ical operators =\\9 [[9 etc.> s.ould "e at t.e "e*innin* of t.e line to ma4e it easier to comment =and e7clude> t.e condition. T.e closin* parent.esis and openin* "race must "e placed on t.eir own line at t.e end of t.e conditions. Geepin* t.e operators at t.e "e*innin* of t.e line .as two advanta*es@ It is trivial to comment out a particular line durin* development w.ile 4eepin* syntactically correct code =e7cept of course t.e first line>. 1urt.er9 t.e lo*ic 4ept at t.e front w.ere itQs not for*otten. Scannin* suc. conditions is very easy since t.ey are ali*ned "elow eac. ot.er. U:p.p if ==Zcondition1 [[ Zcondition2> \\ Zcondition$ \\ Zcondition4 >X DDcode .ere Y :V T.e first condition may "e ali*ned to t.e ot.ers. U:p.p if = Zcondition1 [[ Zcondition2 [[ Zcondition$ >X DDcode .ere Y :V

Ternary operators T.e same rule as for if clauses also applies for t.e ternary operator. It may "e split onto several lines9 4eepin* t.e 'uestion mar4 and t.e colon at t.e front. U:p.p Za N Zcondition1 \\ Zcondition2 : Zfoo @ Z"arK Test Plan Document Student Information System 2+

Z" N Zcondition$ \\ Zcondition4 : Zfoo?man?t.is?is?too?lon*?w.at?s.ould?i?do @ Z"arK :V Strin*s

String .iterals 5.en a strin* is literal =contains no varia"le su"stitutions>9 t.e apostrop.e or Rsin*le 'uoteR s.ould always "e used to demarcate t.e strin*@ Za N Q87ample Strin*QK String .iterals &ontaining Apostrophes 5.en a literal strin* itself contains apostrop.es9 it is permitted to demarcate t.e strin* wit. 'uotation mar4s or Rdou"le 'uotesR. T.is is especially useful for S6< statements@ Zs'l N RS8<8CT ]id]9 ]name] from ]people] R . R5F8R8 ]name]NQ1redQ !R ]name]NQSusanQRK T.is synta7 is preferred over escapin* apostrop.es as it is muc. easier to read. -rrays Numerically 0nde(ed Arrays %e*ative num"ers are not permitted as indices. -n inde7ed array may start wit. any non&ne*ative num"er9 .owever all "ase indices "esides 0 are discoura*ed. 5.en declarin* inde7ed arrays wit. t.e -rray function9 a trailin* space must "e added after eac. comma delimiter to improve reada"ility@ Zsample-rray N array=19 29 $9 QIntenseQ9 QDesi*nQ>K It is permitted to declare multi&line inde7ed arrays usin* t.e RarrayR construct. In t.is case9 eac. successive line must "e padded wit. spaces suc. t.at "e*innin* of eac. line is ali*ned@ Zsample-rray N array=19 29 $9 QIntenseQ9 QDesi*nQ9 Za9 Z"9 Zc9 5 .449 Zd9 500>K -lternately9 t.e initial array item may "e*in on t.e followin* line. If so9 it s.ould "e padded at one indentation level *reater t.an t.e line containin* t.e array declaration9 and all successive lines s.ould .ave t.e same indentationK t.e closin* paren s.ould "e on a line "y itself at t.e same indentation level as t.e line containin* t.e array declaration@ Zsample-rray N array= 19 29 $9 QIntenseQ9 QDesi*nQ9 Za9 Z"9 Zc9 5 .449 Zd9 5009 >K Test Plan Document Student Information System $0

5.en usin* t.is latter declaration9 we encoura*e usin* a trailin* comma for t.e last item in t.e arrayK t.is minimiAes t.e impact of addin* new items on successive lines9 and .elps to ensure no parse errors occur due to a missin* comma. Classes &lass Declaration

T.e "race s.ould always "e written on t.e same line as t.e class name. 8very class must .ave a documentation "loc4 t.at conforms to t.e 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 "lan4 lines must separate t.e class from any additional PFP code in t.e class file. T.e followin* is an e7ample of an accepta"le class declaration@ D^^ ^ Documentation /loc4 Fere ^D class Sample?Class X DD all contents of class DD must "e indented four spaces Y Classes t.at e7tend ot.er classes or w.ic. implement interfaces s.ould declare t.eir dependencies on t.e same line w.en possi"le. class SampleClass e7tends 1oo?-"stract implements /ar?Interface X Y If as a result of suc. declarations9 t.e line len*t. e7ceeds t.e ma7imum line len*t.9 "rea4 t.e line "efore t.e Re7tendsR andDor RimplementsR 4eywords9 and pad t.ose lines "y one indentation level. class Sample?Class e7tends 1oo?-"stract implements /ar?Interface X Y If t.e class implements multiple interfaces and t.e declaration e7ceeds t.e ma7imum line len*t.9 "rea4 after eac. comma separatin* t.e interfaces9 and indent t.e interface names suc. t.at t.ey ali*n. class Sample?Class implements /ar?Interface9 /aA?Interface X Y Test Plan Document Student Information System $1

Function and Method Declaration )et.ods inside classes must always declare t.eir visi"ility "y usin* one of t.e private9 protected9 or pu"lic modifiers. -s wit. classes9 t.e "race s.ould always "e written on t.e same line as t.e function name. Space "etween t.e function name and t.e openin* parent.esis for t.e ar*uments is not permitted. 1unctions in t.e *lo"al scope are stron*ly discoura*ed. T.e followin* is an e7ample of an accepta"le function declaration in a class@ D^^ ^ Documentation /loc4 Fere ^D class 1oo X D^^ ^ Documentation /loc4 Fere ^D pu"lic function "ar=> X DD all contents of function DD must "e indented four spaces Y Y

Functions 8very function9 includin* o"#ect met.ods9 must .ave a doc"loc4 t.at contains at a minimum@ - description of t.e function -ll of t.e ar*uments -ll of t.e possi"le return values It is not necessary to use t.e REaccessR ta* "ecause t.e access level is already 4nown from t.e Rpu"licR9 RprivateR9 or RprotectedR modifier used to declare t.e function. If a function or met.od may t.row an e7ception9 use Et.rows for all 4nown e7ception classes@ Et.rows e7ceptionclass MdescriptionO 1unction Calls 1unctions s.ould "e called wit. no spaces "etween t.e function name9 t.e openin* parent.esis9 and t.e first parameterK spaces "etween commas and eac. parameter9 and no space "etween t.e last parameter9 t.e closin* parent.esis9 and t.e semicolon. 1or e7ample@

U:p.p Zvar N foo=Z"ar9 Z"aA9 Z'uu7>K :V -s displayed a"ove9 t.ere s.ould "e one space on eit.er side of an e'uals si*n used to assi*n t.e return value of a function to a varia"le. In t.e case of a "loc4 of related assi*nments9 more space may "e inserted to promote reada"ility@ U:p.p Zs.ort N foo=Z"ar>K Test Plan Document

Student Information System

$2

Zlon*?varia"le N foo=Z"aA>K :V To support reada"ility9 parameters in su"se'uent calls to t.e same functionDmet.od may "e ali*ned "y parameter name@ U:p.p Zt.is&VcallSome1unction=Qparam1Q9 QsecondQ9 true>K Zt.is&VcallSome1unction=Qparameter2Q9 Qt.irdQ9 false>K Zt.is&VcallSome1unction=Q$Q9 Qverrrrrrylon*Q9 true>K :V Split function call on several lines 5.en t.e function call .as a lar*e amount of parameter t.at e7ceeds t.e c.aracterDline limit9 it is allowed to split parameters in function calls onto several lines.

U:p.p Zt.is&Vsome!"#ect&Vsu"!"#ect&VcallT.is1unction5it.-<on*%ame= Zparameter!ne9 ZparameterTwo9 ZaHery<on*ParameterT.ree >K :V Several parameters per line are allowed. Parameters need to "e indented 4 spaces compared to t.e level of t.e function call. T.e openin* parent.esis is to "e put at t.e end of t.e function call line9 t.e closin* parent.esis *ets its own line at t.e end of t.e parameters.

T.is s.ows a visual end to t.e parameter indentations and follows t.e openin*Dclosin* "race rules for functions and conditionals. T.e same applies not only for parameter varia"les9 "ut also for nested function calls and for arrays.

U:p.p Zt.is&Vsome!"#ect&Vsu"!"#ect&VcallT.is1unction5it.-<on*%ame= Zt.is&Vsome!t.er1unc= Zt.is&Vsome8ven!t.er1unc= QFelp me_Q9 array= QfooQ NV Q"arQ9 QspamQ NV Qe**sQ9 >9 2$ >9 Zt.is&Vsome8ven!t.er1unc=> >9 Zt.is&Vwowowowowow=12>

Test Plan Document

Student Information System

$$

>K :V %estin* t.ose function parameters is allowed if it .elps to ma4e t.e code more reada"le9 not only w.en it is necessary w.en t.e c.aracters per line limit is reac.ed. ,sin* fluent application pro*rammin* interfaces often leads to many concatenated function calls. T.ose calls may "e split onto several lines. 5.en doin* t.is9 all su"se'uent lines are indented "y 4 spaces and "e*in wit. t.e R&VR arrow.

U:p.p Zsome!"#ect&Vsome1unction=RsomeR9 RparameterR> &Vsome!t.er1unc=2$9 42> &Vand-T.ird1unction=>K :V Haria"le -ssi*nments -li*nment of assi*nments To support reada"ility9 t.e e'ual si*ns may "e ali*ned in "loc4&related assi*nments@ U:p.p Zs.ort N foo=Z"ar>K Zlon*er N foo=Z"aA>K :V T.e rule can "e "ro4en w.en t.e len*t. of t.e varia"le name is at least 3 c.aracters lon*erDs.orter t.an t.e previous one@

U:p.p Zs.ort N foo=Z"ar>K Zt.isHaria"le%ameIsHeeeeeeeeeery<on* N foo=Z"aA>K :V Split lon* assi*ments onto several lines -ssi*nments may "e split onto several lines w.en t.e c.aracterDline limit would "e e7ceeded. T.e e'ual si*n .as to "e positioned onto t.e followin* line9 and indented "y 4 c.aracters. U:p.p ZT<!/-<SMQTS18QO&VadditionalFeaderDataMZt.is&Vstr-pplication%ameO N Zt.is&V7a#a7&V*et2avascript=t$li"?e7t)*m@@siteRelPat.=Qnr?7a#a7Q>>K :V

Test Plan Document

Student Information System

$4

12. "est "rac4in* Spreads-eet

T.e test trac4in* spreads.eet will contain t.e followin* columns@ 1ield %ame /u* %um"er /u* Title Reproduction Steps /u* Type Description -n incremental "u* num"er will "e assi*ned to eac. "u*. - "rief description of t.e "u*. Steps for reproduction T.e type of "u* Data /u*9 /usiness <o*ic /u*9 ,sa"ility /u*9 Security /u* /u* Raised /y /u* Raised Date Status T.e name of team mem"er raisin* t.e "u* T.e date "u* was raised Raised -ssi*ned to /-ssi*ned to Developer -ssi*ned to Test for Herification Closed Status Date T.e date status was last c.an*ed

Test Plan Document

Student Information System

$5

1&. ,ppendi9 4( Scope and Mandatory e)uirements

Feature Master Data Management -llow respective administrators to mana*e t.e master data suc. as Room Details9 Pro*ram Data9 Su"#ect Data Functionalities Required 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 t.e student data includin* attendance data9 ac.ievement data9 "e.aviour data9 contact details9 timeta"les9 alternative pro*rams data and ot.er information

$. -llow administrators to update student data element 4. 8nforce "usiness rules to ensure t.e inte*rity of student data . -llow Bsuper; administrator users to define access privile*es to student data elements

Access/Search -llow t.e users to searc. for re'uired information easily

Reporting -llow users to *enerate summary and detailed reports on student data.

5. -ut.oriAed users s.ould "e a"le to view information as re'uired. . -llow a multi dimensional searc. "ased upon 4eyword9 id9 name9 description9 notes etc. (. Include multiple types of searc. criteria suc. as e7act matc.9 partial matc.9 wildcard searc. etc. 3. -ut.oriAed users only s.ould "e a"le to 'uery t.e relevant information. 4. -llow *eneration of period administrative reports suc. as mont.ly 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. 4. T.e administrators s.ould "e a"le to mana*e t.e users & Reports on users of t.e system & Tools to remove users from t.e system & Define access privile*es for users & Run maintenance tas4s =T/C> 5. -udit t.e usa*e of t.e system . Run audit reports for activities in t.e system

Administrative Tools -dministrators s.ould "e a"le to mana*e t.e report;s administration and confi*uration

Test Plan Document

Student Information System

14. ,ppendi9 !( Security e)uirements

1. T.e pa*es are only accessi"le to t.e users t.at .ave access to t.e pa*e. 2. T.e protected pa*es are only accessi"le to lo**ed in users. $. T.e te7t fields only allow valid input. 4. T.e te7t fields filter out any S6< in#ection attempts. 5. T.e files on t.e we" server are not remotely accessi"le =allow?url?open and allow?url?include are not allowed> . T.e directory traversal is disa"led. (. T.e lo*in pa*e is secured usin* SS< certification. 3. -ll data validations are validations on t.e server side as a minimum =even if t.ere is client side validation>. +. <o*in credentials are different for all internal systems =1TP9 Data"ase and 5e" Server> 10. -ll server softwares are patc.ed wit. latest software. 11. !nly data"ase and we" server are runnin*. !t.er services suc. as S)TP are disa"led on t.e server.

Test Plan Document

Student Information System

$(