TEST SPECIFICATION REPORT for BRAIN BASED CONCANTRATION ENHANCEMENT SYSTEM

by MENTALLIGENT
Berk ESEROL Evin ASLAN rem Gke AYDIN stn YILDIRIM 1534908 1559921 1550268 1629419

MINDER CENG 429 Levent Bayndr 4/24/2011

Table of Contents

1. INTRODUCTION
The BCES project is an Assistant Desktop Application for Doctors to deal with patients with lack of attention and concentration. This project has to be implemented in a short period of time. Because the project has different modules, in this short time interval, all of them should have must be implemented till the end of semester. Thus in the progress of implementing BCES, each member is working on different modules and engines that are assigned to him. After members updating the code or adding new features, it is tested about this feature and when it is ensured about its correctness, he commits this part to SVN repository. However, testing and debugging process continues to its existence.

1.1. Goals and Objectives

BCES is composed of different modules and each module can be thought of an independently built process. In order to make all these federates and inter-federate modules work in a harmony, first of all one should verify duties of modules that are critic for the performance and verify whether these modules communicate correctly when they are integrated. Therefore testing is very critical for the project and with being aware of this from the beginning of the project, many small tests are executed during the development phase of BCES. Also goals for testing the process of the project are making BCES give the maximum efficiency and reliablity in: being bug-free, effective in applying the aim of enhancement of concentration, logically correctness, high performance, well designed product.

1.2. Statement of Scope

A description of the scope of software testing is developed. Functionality/features/behavior to be tested is noted.

This document briefly describes the testing process of BCES project. As in fact the testing process is continuous from the starting date of the project to the end date, this document also includes some information about how the testing has been done up till now in the project. However the main aim and scope of this document is to present the testing plan for the remaining part of the project in which the implementation is considered to be nearly complete.

At this point it is important to emphasize that every detail in our test plan is decided by considering the specific properties of our project and the major constraints that we have for testing (i.e. mostly time and reliablity). We tried to develop a testing plan which is adequate for a ReaTime Feedback Based Project. So this report also denotes testing criteria and testing approach of Mentalligent. The main feature of the project to be tested is making the application respond to the users brain functional state more reliable.

1.3. Major Constraints

1.3.1 Data Extraction Latency Using a EPOC-Lib library provided by the company, Minder, we have encountered a serious latency problem during the implementation. Because the FFT transformations applied on extracted brainwaves from the device takes a couple of seconds, the delay of the expected real-time data is increasing continuously. So, we can not visualize the instant concentration value of the user graphically in real-time. As expected, this situation leads a feeling of that our application is not showing the real concentration state. In fact, transformation of the sent data from the BCID should be at maximum rate, be as compact as possible and correctly deliverable in order to obey with the speed constraints.Thus BCES is diligently tested for data transfers and the performance of application in certain situation. To improve this latency problem, we will decide to make changes in the structure of the library in the supervision of the Minder. 1.3.2 Time BCES is intended to use for adapting the route of the games in the application accordingly the concentration status of the user, so it is designed to extract the brainwaves quickly and reply to the interactions with the user in a rapid manner. So researching for quicker parts and testing and debugging the project to speed up the application are important parts of the project. Morevoer, since BCES is a run-time application, to reach the same state at which the data extracted from the BCID is not corresponding to the state of the user is time consuming even if we have added a user-based calibration system at the beggining of the project. There is left nearly 1 month to complete the project, including removing the bugs found and improving the project. As a result of this, time is the other greatest constraint for testing of BCES. 1.3.3 Test Results Over Testing Process Power Amount and method of different test procedures will be decided by this ratio. For example it is essential to write test codes for unit testing of some modules and their results will benefit. However, writing of such code also brings both human resource requirement and time cost. Another example is that, during integration tests the project will be manually tested by creating various scenarios and their results will be obtained. These result may even be less useful with respect to other testing procedures. Therefore, the amount of usefulness of test results per the amount of time it takes and per the amount of human resource requirement is one of the most important factors limiting the testing of the project.

4 1.3.4 Hardware The architecture of computers used in beta testing should have enough capacity to run the application. Memory usage, performance of the processor are the other factors limiting tests of the project. Because in the FFT transformation applied to the raw data extracted from the BCID use multi-threaded programming way, to handle with the parrallel and concurent processing the power of the processor is really important. For example, we have to work on a computer with quad-core instead of dual-core. Because, if we not work on that, the performance of the application becomes really bad and slow.

1.4. Definitions, Acronyms and Abbreviations

BCID: Brain Computer Interface Device BCES: Brainwave Based Concentration Enhancing Software CVS: Current Version System SVN: Sub-Version System SWT: Standard Widget Toolkit FFT: Fast Fourier Transform User: The person using the software with a BCID Casual user: The possible end user group for the software. Database: Collection of all information about the users. Neurofeedback: Feedback generated by the brain activities of the user.

1.5. References
BCES Software Requirements Specification, by Mentalligent, Fall 2010
http://mentalligent.blogspot.com/2011/03/software-requirement-specifications-for.html

BCES Detailed Design Report, by Mentalligent, Fall 2010

http://mentalligent.blogspot.com/2011/03/software-detailed-description-design.html

Test Specification Template, METU Computer Engineering, Spring 2011

https://cow.ceng.metu.edu.tr/Courses/download_courseFile.php?id=3258

IEEE Standards for Test Design Specification, IEEE Std 828, 1998
http://en.wikipedia.org/wiki/Software_Test_Documentation

2. TEST PLAN
This section describes the overall testing strategy and the project management issues that are required to properly execute effective tests.

First of all, in this document whole testing process of BCES is described. In other words, past, current and future actions about testing procudure of BCES and the reasons of problems that make testing neccessary are mentioned in this document. Each member of Mentalligent is responsible from his/her own distributed work. To have a stable development process, each member actively tests all additional changes that he/she has done in case of any work to be done. So, testing works are also distributed to each related member.

2.1. Software To Be Tested

The software to be tested is the BCES itself. More specifically, the modules that creates the whole system is tested and more importantly the data extraction from the device is tested in from the beginning of the implementation.

2.2. Testing Strategy

2.2.1. Unit Testing Unit testing is done for data extraction and modules in BCES. 2.2.1.1 Module Tests BCES contains 5 modules communicating via Manager component and having their own classes. Because of having the brain wave data extraction library from the company, for us, it has been possible in terms of taking time to do function level unit test in each class of each module. First of all, it requires extra coding to do unit test for data extraction process from BCID. Priority has been given to some critical functions and classes in EPOC Library that have critical requirements for their interior processing and easily observable results independent from other functions or classes. In some unit tests of modules, blackbox method is used. So, only outputs are checked for having expected values while testing the average Beta Brainwave values in every 2 seconds. Up to now, unit tests are applied five of the modules which are GUI module, Game module, Database module, BCID module and of course Manager module. There is also a Provider class for help to Manager class to establish a communication between our application and the Game Module via socket programming. So, unit tests for this module is also has been done. Detailed unit test applications are explained for each component in the following paragraphs. These paragraphs contain past tests. After now, unit tests will be written for one remaining modules which are AI component for the decision of next behaviour of the game. Furthermore, unit tests will be added in case of upcoming class or function extensions for all components. Manager module unit tests: Unit constructors BCID initializer GUI initializer Database initializer Provider initializer(Thread implementation) Module functions implementation BCID module unit tests: Unit constructors Manager initializer EPOC Library implementation(Thread implementation)

GUI module unit tests: Unit constructors Manager initializer Game initializer GUI Widgets implementation(Menu Handlers) Thread implementation for extraction of brainwaves from BCID via Manager Game module unit test: Unit constructors Manager Initializer Provider Initializer SWT representation on GUI Browser implementation Database module unit test: Unit constructors Menu handlers JDBC implementation 2.2.1.2 Data Tests As TRASTRAPS contains lots of initial data, while preparing _les that contains information about models and their properties, correctness and properness of all _les were checked so that those _les contain all information that is necessary to represent a model by having _delity to reality. For each, unit those values are checked and if they are valid, they were stored to database. This test will be applied to all future updates on TRASTRAPS. 2.2.2. Integration Testing
The integration testing strategy is specified. This section includes a discussion of the order of integration by software function. Test cases are NOT included here.

Because of communication throught the RTI infrastructure, it is essential to do integration testing while integrating federates to each other. As soon as, a new interaction or a new object is de_ned to be subscribed or published between federates, an integration test is applied to check correctness the communication. 2.2.3. Validation Testing
The validation testing strategy is specified. This section includes a discussion of the order of validation by software function. Test cases are NOT included here.

2.2.4. High-order Testing

The high-order testing strategy is specified. This section includes a discussion of the types of high order tests to be conducted, the responsibility for those tests. Test cases are NOT included here.

2.3. Test Metrics

A description of all test metrics to be used during the testing activity is noted here.

2.4. Testing Tools and Environment

A description of the test environment, including tools, simulators, specialized hardware, test files, and other resources is presented here.

3. TEST PROCEDURE
This section describes as detailed test procedure including test tactics and test cases for the software.

3.1. Unit Test Cases

The procedure for unit testing is described for each software component is presented.

3.2. Integration Testing

The integration testing procedure is specified.

3.3. Validation Testing

The validation testing procedure is specified.

3.4. High-Order Testing (a.k.a. System Testing)

The high-order testing procedure is specified.

4. TESTING RESOURCES AND STAFFING

Specialized testing resources are described and staffing is defined.

5. TEST WORK PRODUCTS

The work products produced as a consequence of the testing strategy and testing procedure are identified.

6. TEST RECORD KEEPING AND TEST LOG

Mechanisms for storing and evaluating test results are specified. The test log is used to maintain a chronological record of all tests and their results.

7. ORGANIZATION AND RESPONSIBILITIES

The organization of testing is specified along with the responsibilities of the team members.

8. TEST SCHEDULE
A detailed schedule for unit, integration, and validation testing as well as high order tests is described.