1.5 Overview of testing strategy

Testing begins at the lowest level and moves on to higher levels as the project progresses. This is the overview of the testing strategy that will be used:

• The code for SAM will be written in Python, which is an Object Oriented language. Therefore, the basic unit of code is a class. As coding of each class progresses, the author is expected to carry out Informal Testing (see section 3). The aim of Informal Testing is to ensure the code fulfills its methods defined so far, and for the author to be reasonably confident in the code's functionality before running Unit Tests (see next dot point). Also, it ensures that major design flaws are spotted and fixed early. Since this form of testing is informal, and procedures for it may vary between individuals, there is no set procedure or documentation for Informal Testing.
• Prior to any formal testing, static analysis must be performed on the code. This will be done via the use of pychecker, which is a program that finds common bugs and mistakes in Python code, similar to the errors found in, for example, a C compiler. pychecker is run via the testing script for SAM (see section 1.7).
• The lowest level of formal testing is Unit Testing (see section 4). This is performed once the coding of a feature of a class is complete, and Informal Testing has been carried out by the author. Unit Testing is designed to ensure that each individual class of RAMI performs its function(s) correctly as a discrete, independent unit.
• Unit tested classes are then combined together incrementally to form the complete system. This is the next level of testing - Integration Testing (see section 5). The purpose of Integration Testing is to ensure that classes interface correctly with each other.
• The next level of testing is System Testing (see section 9). System Testing tests the final product as a whole for defects. This step consists of GUI Testing (see section 7) and Documentation Testing (see section 11).
• Function Testing (see section 8) is the next level of testing and ensures that the product complies with the requirements set out in the SRS.
• Installation Testing (see section 10) will be performed once the product is fully integrated. This step will ensure that the product can be installed onto the platform it is designed for.
• The highest level of testing is Acceptance Testing (see section 12). This is to consist of the core part of the Function Testing step, along with a similar procedure for non-functional parts of the SRS. It is to be performed with the Client to demonstrate that the product satisfies the requirements in the SRS and use cases in the DDD.