DNA

Dynamic Neural Art - Test Plan
Version 1.0


Spring Quarter 1997 Project Team:
Project Sponsor: Alp Sendil (Manager)
Gregory Abowd Enda Sullivan (Architect) & (QA)
Bob Sumner (Programmer)
Lynn Bacher (Technical Writer)


Table of Contents
  1. Scope
  2. Schedule
  3. Validation Tests
  4. Verification Tests
  5. Document Revision History


I. Scope

This test plan will address the validation of the DNA project. There are 3 basic parts of the project to test.
  1. The web interface which collects users votes and keeps track of the current status of the system.
  2. The fractal generation program, which takes the all the votes from the last generation, and based on a genetic algorithm, creates new fractals.
  3. The color integration program, which takes the same vote information given to the fractal generation program and uses that to incorporate new color maps into the images.
Each of these will be tested to ensure they meet the requirements document. The testers will use a Testing Report Form to document their results. These results will then be added to the Test Plan.


II. Schedule

To see a copy of the schedule click here.


III. Validation tests

Test 1


(See task #1.22)
Purpose
Generate new fractals when given the list of parameters. The parameters are generated from the learning algorithm.

Test description
We should have a new fractal which accurately represents the parameters which were passed in. This part of the system will actually produce 2 images for each set of parameters. The images will be in gif format, and should be of different sizes. This will be a black box test, indicating that we will pass parameters in, and only really care that it produces the correct output.
For this test to be successful, it should automatically [i.e. with no user interaction] produce 2 files called 1s.gif which will be of the size 100x75 pixels. The second images 1l.gif will be of the size 800x600. Both of these images should be placed into the directory /net/www-int/projects/DNA/graphics and should be made to be world readable. In addition the file which contains the parameters which made up this image should be copied into the directory /net/www-int/projects/DNA/voting. These files should be in the format:

<Number of votes [initially set to 0]>
<Line one of the parameters>
<Line two of the parameters>
<Line three of the parameters>

Each file must be both world readable and writeable. [ie it must have permissions 666]. This is because the internal server will execute the script which reads them, thus it must have read and write permissions.
This test will be performed by the programmer as soon as all parts of the code [including the color map generation part] are completed.

Results

Tester 
Date 
Platform 
Outcome 
Comments 

Test 2


(See task #1.015)
Purpose
Incorporating color into the images. The purpose of this part of the system, is to combine colors from previous winning images to produce new colors. This should be done in a command line, non-interactive way.

Test description
This test is a little more difficult to do. Again, we will run a black box test here, but the output is inherently non-deterministic. We would not want the same inputs to always produce the exact same output, otherwise all of our pictures would tend towards the same color [probably a shade of blue/gray]. We do want it to produce output which has some of the characteristics of the to winning pictures. It should have also have a large element of randomness.

To achieve this, the only real requirement for the outputs of this test, is that this portion of the system produces valid color maps. With no user interaction, it should be able to take the current color maps, and the current vote tallies for each image, and should produce 9 new color maps. Each of these should have some of the aspects of the old color maps, but can also have new mutations.

These color maps should be placed into files called 0.map, 1.map etc...and should be placed into the directory /net/www-int/projects/DNA/voting. All of these files should be world readable.
This test will be performed by the manager, who is currently programming that aspect of the system.

Results

Tester 
Date 
Platform 
Outcome 
Comments 

Test 3


(See task #3.31)

Purpose
The web page is the part of our system which the users will actually be using. Therefore, its very important that we have a easy to use interface. It also has to be functional.

Test description
To test this part of the system, we will create a web page which displays all 9 images, and allows the user to enlarge each picture, one at a time. The user will also be able to select their top three choices from a list of all the possible images.
When selecting their top 3 they are only allowed to have one choice for first place, one choice for second place and one choice for third. All 3 of the above can actually be the same picture. (i.e. A user can really like one picture, and select it as first, second and third)
It would be ideal to perform user interface tests on this page, however due to lack of time, that may not be possible right now. In the meantime, we will perform a fairly simple blackbox test. HTML is already a well tested language, so we can assume most functionality works. For example on the page we will use radio buttons to enforce the rule that only one image may be selected as first place. There is no need to test the fact that only one can be selected then, since we already know HTML does that correctly.
We will however test the functionality of this page. Specifically we will test:

The submit button   Should call the appropriate script passing the selected pictures as parameters  
The clear button   Should clear out all choices from the images  
Clicking on a picture   Should show the image larger in more detail  
Click on a voting area in any of the pictures   Should be able to select only one picture in each voting level.  

This test will be performed by the Architect, and can be completed as soon as the final version of the web page exists.
Each of these tests should be performed on ALL of the platforms which we have specified as our target platform.

Results

Tester 
Date 
Platform 
Outcome 
Comments 

Test 4


(See task #4.4)

Purpose
This test will check to ensure that the CGI script which is behind the web page functions correctly. Basically the web page passes its votes to the CGI script when submit is pressed. The CGI script is then responsible for updating the vote counts.

Test description
This test will be performed when the web page is finished. A working model of the web page already exists, and we are able to do preliminary tests. Using the sample web page, we can create votes for some of the pictures, and if the code is working properly, this script will update the data files.
Each picture has an associated data file with it. The first line in each of these files is how many votes that file has already received. This file gets set back to 0 by the fractal learning program. If the CGI script is working correctly, points will be added to the number on the first line of the corresponding file. (For example, assume I pick image 5 as my first choice. 15 points will be added to the number on the first line of the file /net/www-int/projects/DNA/voting/5.data ). Second place vote will result in 10 additional points for that file, and third place file will add 5 points.
The script must do a few additional things. When accepting a vote, the page will notify the user that their vote has been received, and tell them how many votes until the images get updated. If their vote can not be currently accepted, the script should notify them.

Conditions when a vote can not be taken:
  1. The page is currently being updated
  2. The fractals which the user is seeing are not the most current fractals. Thus we are in the process of updating the pictures. While this process is ongoing, we cannot allow them to vote, because this would lead to some votes being lost.
  3. The internal server is currently down. However they most likely would not even get to the page in this case.

In addition the CGI script must ensure that 2 users do not attempt to write to the same file at the same time, as this would create a race condition. Thus file locking must be used.

The CGI must also create a history of old pictures. This will happen at the same time when the script calls the learning algorithm. It should create a directory under the main web page which is called the generation number, and should add to that directory a copy of all the small images. In addition it should copy a standard index.html file in there.

Finally the CGI should update a file called /net/www-int/projects/DNA/voting/vote.count to reflect the addition of this count.

The calling of the learning algorithm is achieved via an e-mail message. This message should be sent when 5 votes have been received.

Actual testing of each of these functions is achieved by opening a web browser, preferably multiple browsers on multiple platforms, and attempting to vote. Setting the vote.count back to 0 and then going through the various files and checking to see if the appropriate number of points were added to them after each vote.

When the 5th vote happens, you can check that the appropriate e-mail message was generated, the user was notified in the web browser and the old pictures were archived.

Results

Tester 
Date 
Platform 
Outcome 
Comments 

Test 5


(See task #2.21)

Test 6


(See task #4.4)

Test 7


(See task #3.311 & #3.312)


IV. Verification Tests

This section contains details on each of the tests that are designed for verification ("Are we building the thing right?"). There is a section devoted to each test which contains a high-level description of the test, a pointer to reference material within project documentation, the actual test to be performed, and the results of the test (once completed). We will not be completing this section for now. If it were to be filled in, it would follow the same format as the validation tests section.


V. Revision History


DNA Home Page
Last Modified 5/5/97 -- C. Lynn Bacher (lynn@cc.gatech.edu)