TEST SPECIFICATION

REPORT for

BRAIN BASED

CONCANTRATION

ENHANCEMENT SYSTEM

M I N D E R

C E N G 4 2 9

L e v e n t B a y ı n d ı r

4 / 2 4 / 2 0 1 1

by MENTALLIGENT

Berk ESEROL 1534908

Evin ASLAN 1559921

İrem Gökçe AYDIN 1550268

Üstün YILDIRIM 1629419

1

Table of Contents

2

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.

3

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.

5

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)

6

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.

7

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

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