Ethics Reviewer: Testing Strategies Introduction Testing provides valuable information on the state of the internal system. As developers it is vital for us to understand the conformance of the system to the original requirements including functional, reliability and security. It makes us aware of any potential risks as well as the usability of the system. Ultimately, verification and validation is used to ensure correct decisions have been made to build the right system. It is also important to consider the inevitability of defects and bugs. Testing must incorporate finding these defects to avert negative impacts on the product. Functional Testing Having completed unit and integration testing, the next step involved working closely with the specification and carrying out functional testing. This is a verification activity. During the initial stages, we created a specification based on the clientâ€™s requirements. These were mandatory features of the Ethics Reviewer that must execute within a set amount of time. These tests were written in complete English and ensure the system is feature complete. We used JUnit 4.0. It provided some good features such as parameterization and annotation support. Functional testing was approached just like unit testing. We wrote the tests as soon as there was code that produced something that interacted with the user. This comes back to the point of relating functional tests to the specification. Once there was a range of functional tests, we carried out numerous variations on the initial tests. Generally, functional testing was used to test all our view classes individually and the database controller classes. The diagram below outlines our testing approach.
User Testing After completing sections of functional aspects of the application, our aim was to ensure the system works as expected by the end user. We set up test environments and ran through the sections as if we were the end users. This was done recursively and eventually upon completion of the system, the entire system was testing from front to back from both lecturersâ€™ perspective and student perspective. Since the project will be used in focus groups amongst multiple students, we created a placebo class of 10 students which all ran the application simultaneously to ensure most importantly the messaging system was interactive. Any bugs or errors were noted of and corrected. Evaluation The product solution met the clientâ€™s needs exactly primarily due to the fact we iterated through the requirements to ensure everything was met. It is essential when such a system is used over a short period of time, i.e. focus group class length is roughly 50 minutes, the application must be user friendly and each feature must be easy to understand to avoid time being wasted. Ease of use was a main concern during testing phases. Small sections were tested at a time until the production of the entire system, which was then tested amongst small focus groups.