B.I.M. Test Plan

By

Dare Obasanjo

 

 

 

 

 

 

 

 

 

 

 

 

 

Section I – Introduction

            This document contains a description of the validation testing strategy performed on B.I.M. Each of the test stages in this document is aimed at confirming that B.I.M. was built in accordance with the customer’s enumerated needs.

Section II - Unit Test

Unit tests are to be performed by each developer on various elements of B.I.M. White-box testing is to be used at this level, since errors in logic are easier to find when testing each path through the code. During unit testing test cases that check data and control flow, that make hand checks easy, that check program boundaries (maximum, minimum and off-by-one), that check reactions to incorrect input, and that stress the minimum and maximum requirements of the system are used.

Section III – Module Test

Module testing will be performed by creating stubs and scaffolding of components that various software modules will interact with and exercising their functionality. Modules are tested by individual programmers in this manner with feedback on the kind of stubs and scaffolding required provided by fellow developers who will write components that will interact with the modules.

Both white-box and black box testing will be used at this stage.  Black box testing is used to demonstrate that each module is fully operational and can perform the tasks it was designed to perform while white-box testing will be used to make sure the internal working of the modules conforms to specification.

Section IV – Integration Test

After the modules had been fully tested and components were ready to be combined, integration test will occur. This is done incrementally by adding one module at a time and testing that functionality. In the case of the Client Side Instant Messenger this involves things like testing the ability to add people to the contact list separately from testing if messaging works and separately from if altering the contact list in other ways works. This also involves putting the various communication layers between the group pages and the CSIM through stress tests one at a time.

Once all the modules have been incrementally integrated the entire system will be tested as a whole against the functional requirements in the Software Requirements Specification.

At this stage a test plan matrix containing a one-to-one mapping of tests to functional requirements will created and used to determine what tests will be performed. 

Section V - Alpha Test

During Alpha testing, the B.I.M. suite will be used exclusively by the developers with test data specified by the customer. Also the tests in the test plan matrix are performed to make sure that the system performed its intended tasks properly. At this stage the B.I.M. suite will use a Microsoft Access database as its data store because Microsoft Access enables quick changes to the data in the tables.

Section VI - Beta Test

During beta testing the data store will be changed to Microsoft SQL Server, which is a more robust and standards compliant database. During beta testing, the B.I.M. suite will be deployed at the customer’s site and instructions on how to install, manage and use the system were provided.

At this stage if bugs are still being found at a considerable pace, error-reporting tools will be created which simplify the process of reporting bugs to the developers and allowed the developers to obtain specific data about what caused certain errors to occur.

Usability tests will also performed during this stage and customer feedback welcomed on how to fix certain user interface issues that hamper productivity.

Section VII - Regression Test

Once any changes requested by the customer have been made, it will be paramount to ensure that new functionality does not break old functionality. This means that all the tests in the test plan matrix shall be performed again so as to confirm that the system was built in a valid and verifiable manner.