TVAC Electronic Call Sheet System Team HeatWave Summer 2007

The Paper Call Sheet FrontBack

Advantages  Electronic data can be made more secure than paper storage with backup systems and redundancy on geographically dispersed servers  Electronic call sheets can be searched instantly  Data can be shared more quickly and easily with other emergency services and municipal organizations  Enables data mining for statistics that can be used to improve procedures and detect patterns

System Architecture  3-tier architecture  Built on latest Java EE framework (EE 5, EJB 3.0, JPA)  All server functionality exposed via Web Service  Built entirely with open- source components DB Internet Client EJB Containter Web Containter App Server mySQL WSB | EJB Servlet

System Capabilities (Release 1)  Create call sheet  Search call sheets  View call sheet details  Edit call sheet  Delete call sheet

Walk-thru: Call Sheet Creation Tom’s Restaurant

Call sheet created successfully. (id=54234) 54234

Walk-thru: Call Sheet Search Corner of Deli New York

Search selection Search results stored in JTable View detail (driven by search selection) Walk-thru: Call Sheet Search

Critical code paths: GUI  CallSheetSearchUI : Covers 80% of use cases Procedures followed  Blackbox testing  Boundary value analysis  Whitebox testing  Statement coverage  Branch coverage  Control flow path coverage  Data flow path coverage

Critical code paths: GUI (cont) Results obtained  Search by Call Sheet ID, location, town, date range  Boundary value errors  View call sheet detail based on JTable selection of search results  Statement, control and data flow path errors  Edit a call sheet  Control and data flow path errors  Delete call sheets  No errors

Critical code paths: Controller  Requests from the client module are intercepted by the servlet and forward to the processRequest method in CallSheetServlet.java  This method draws all the subsystems together and performs the following tasks: Reads the client’s XML request Converts the request to a call sheet object Invokes the appropriate database method Returns the request result to the client  The centrality of this method and the abundance of custom code make this the most critical method of the Controller.

Critical code paths: Data Store  Managed persistence and connections eliminated most of the data store “plumbing”  CallSheetFacade.java (stateless EJB) contains most of the custom logic  findBySearchCriteria() method involves building an EJB-QL query from our custom SearchCriteria object  Custom code, EJB-QL syntax, and direct coupling with the Controller make CallSheetFacade the most critical section of code in the data store

Code inspection: GUI  Line by line review of the critical section  Q & A format  17 Issues documented and prioritized in issue tracker:issue tracker

Code inspection: Controller  CallSheetServlet Procedures followed  Formal code review Results obtained  Edit and delete functionality not implemented  Missing comments  Missing / incorrect Java Doc  Dead code

Code inspection: DataStore  Line by line review of the critical section, CallSheetFacade.java  Issues discovered Dead code Missing error handling Missing comments

Testing: Statement Adequacy Coverage  Coverage testing was done to ensure that each line of code in the critical paths was run at least once.  Due to the reduction in code size brought about by Java EE 5 and the familiarity with the code brought about by the code reviews, coverage tests were designed to reach each line and were verified with a visual debugger.  Unit, integration, and acceptance tests exercised the paths more rigorously by testing a variety of paths through the critical code

Testing: GUI (CallSheetSearchUI.java)  Code for UI construction and layout does not branch Normal testing covers the straight-line code (lines 1-131, methods CallSheetSearchUI(), draw(), createSection1(), createSection2(), and createSection3()  Updating functions require specific actions and data to achieve full code coverage (presented in the next two slides)  In the following test cases, expected results are that the application reports problems when the action cannot be performed and otherwise completes the operation successfully.  In addition to the following actions and data, perform one test case where you resize the search screen (lines ).

Testing: GUI (actions) SearchDeleteUpdate Perform search action with no call sheets in the database Perform delete action with no call sheets in the database Perform update to create a new call sheet (no call sheet number specified) Perform search with representative test data loaded but with no matching results Perform delete with representative data loaded but specified call sheet does not exist Perform update action where the new call sheet data is invalid (e.g. bogus date info) Perform search with representative test data and search criteria returns matching results Perform delete with representative data and delete is successful Perform update to modify an existing call sheet (with call sheet number specified) Results in 27 test cases using 3 sets of data for each of the 9 boxes. Using these 27 tests, all lines of code are executed.

Testing: GUI (data) LocationDateCoverage (lines) = null<> null <> null= null102 <> null Normal case, covers most code When creating a representative set of data. Be sure that you have at least three records with the following fields set as indicated. This data will ensure that the specified lines of code are covered.

Testing: GUI (data) Test type Lines not executed Search/Delete with no data Update with invalid data We ensured that all code is covered by tests as indicated in the charts above. However, to gain full confidence in the code it was necessary to cover some of the same lines of code but by following different code paths to get there. Tests described here were designed to skip lines of code to see the impact when those lines are not executed.

Testing: Controller  Procedures followed Create call sheet Search for call sheets View call sheet detail Edit a call sheet Delete call sheets

Testing: Controller (cont)  Results obtained Create call sheet SAVE SUCCESS …. Search for call sheets SEARCH SUCCESS Broadway New York View call sheet detail … … … Edit a call sheet SAVE SUCCESS 2 …… Delete call sheets DELETE SUCCESS 1

Testing: Data Store (CallSheetFacade.java)  Class under test is very limited in code size due to implementation of EJB.  Due to limited code size, coverage testing was accomplished by using debugger and manually tracking the covered lines.  Developed small test classes to invoke methods in CallSheetFacade.java. Was able to accomplish both black box and white box testing with these acceptance and unit tests.