Prototype Testing Iteration 1

The aim of carrying out testing is to examine that all of the different parts of the system work correctly. As the prototype for the first iteration has been designed and implemented, the next stage is to test what has been implemented. As outlined in section 5.1, two types of testing were carried out to complete iteration 1. Firstly, Unit testing was used to ensure that a detailed examination of the prototype and its functions implemented so far is carried out. So for this iteration, the testing of the database and the AAI was undertaken. Testing was also carried out throughout the implementation of the database and AAI. Maciaszek (2005) states that testing is simply not just a stage after implementation, but it should be carried out throughout the implementation also. Errors were discovered in the code throughout the implementation stage and so were fixed by the author as they appeared. This is the main reason why there are not many errors found in the test plan for iteration 1 [Appendix F]. The second type of testing is Acceptance testing. There are numerous types of Acceptance testing but the one carried out at the end of the implementation stage in iteration 1 was Alpha acceptance testing. This is important as this requires participation of the problem owner to ensure that what has been implemented so far meets their specification and that it works. The next section will discuss the testing that was carried out.

5.4.1 Testing of the Automatic Administrative Interface (AAI) and the database

Unit testing was carried simultaneously on the AAI and the database. The reason for this is that if data is inserted in the AAI it should subsequently appear in the MySQL database. This approach tests every part of the AAI (classlist, lectures, messages etc) and also tests the database by seeing if the data has been added, deleted or updated into the correct table. The unit testing also examines the validation of data entered into the AAI and subsequently the database (for example, no input validation – notify when there has been no input inserted into a field.). The test plan was devised with a number of headings. Firstly, there is the test number and a description of what the test is. The next heading is the expected result of the test, followed by the actual result of the test. Finally, if the actual result differs from the expected result, any corrective action is inserted into the final column. The test plan for the testing of iteration 1 is in Appendix F. Unit testing can be carried out by the author and the problem owner doesn’t need to be present. But in the second stage of the testing; Alpha acceptance testing, the problem owners’ participation is required to get their feedback and then whether they ‘accept’ (hence Acceptance testing) what has been implemented. The author quickly demonstrated the functionalities that have been developed in the AAI and they were received with positive feedback from the problem owner. The problem owner asked the author to make one alteration in the lectures functionality. Currently for this functionality, the author implemented a large text box where a teacher can enter in the lecture notes. This method was not very effective or efficient and it would be time consuming if a teacher would have to type in all of the lecture notes. The author was asked see if Django can provide a feature that would allow a file to be uploaded. The author researched the Django documentation and found an upload feature. The data type of the lecture notes field in the lectures table was changed from a CharField to a FileField. Now this would be more suitable as a teacher could select a file such as a PowerPoint presentation to be uploaded, which then can be displayed later on the user interface when it is developed in the second iteration. Once the file is displayed on the user interface it can be downloaded by a student.

5.5 Iteration 1 Summary - As iteration 1 is complete, the author requires feedback from the problem owner to see if any of the 4 web application development concepts identified in the requirements stage are demonstrated in the prototype so far. It was briefly discussed how the AAI demonstrates the concept of interaction with the data tier. As a teacher is creating, updating and deleting data (such as questions) the AAI is constantly interacting with the data tier by adding, updating and deleting records. This feedback session was short as it was agreed that it would be best to have a look in the Evaluation stage rather then now to see if the web application development concepts are demonstrated in the prototype system. Iteration one is completed as the database and the AAI has been designed and implemented.

6

The Case Study – Prototype Development Iteration 2

Iteration 1 focused on designing, implementing and testing the first part of the system (the AAI). The second iteration focuses with the design, implementation and testing of the second part of the system. This is a public user interface where anyone can view the learning material. Unlike the AAI, this part of the system is public as a teacher would want students to view and use the learning material that has been created in the AAI and is displayed on the user interface. This chapter includes the design and implementation of the user interface features. The chapter ends with a section on how testing of the user interface features was carried out.