Project Atlantis: Test Report

Contributors:

• Abu Sesay
• Ai (Tino) Duong
• Daisuke Kinjo
• Saima Makhani
• Jian Yang
• Keith Kwong
• Ian Ko
• David Hayes
• David Mitchell
• Lukasz Galek
• David Nilson
• Erin Moeller
• Trudy Petersen

Table Of Contents

• Introduction
1. Document Key
• Unit Testing
  1. Student - View Timetable
  2. Student - Course Registration
  3. Administrator - Add Course
  4. Administrator - Add New Student
  5. Conclusion
• Integration Testing
  1. Add Course to Timetable
  2. Drop Course from Timetable
  3. View Student Timetable
  4. Add Student
  5. Add Course
  6. Waiting List
  7. Modify Course
  8. Modify Administrator
  9. Conclusion
• Acceptance Testing
  1. A New Student
  2. A New Professor
  3. The Grad Student
  4. The Administrator
• Conclusion

Introduction

next previous top

WinterSoft prides itself on complete software, which includes extensive testing. We do not believe in cutting corners, especially at this crucial stage of development. As shown in our previous document, where some companies only highlight the major functionality, WinterSoft covered every component in the system. Although resulting in a much larger document, we do not believe in following the ways of other companies. If providing more testing can ensure a more rigid system, then WinterSoft is willing to go that extra mile.

Document Key

next previous top

While we have done all of the testing required to get the system running smoothly, this document will highlight only the major parts of the system. Tables are used to help the reader understand the inputs and outputs. The Unit and Integration testing sections will have a header explaining the part of the system that is to be tested. The rest of the table is broken down into categories as follows:

For more information on testing, see our own Test Plan and The University of Atlantis' Acceptance Test Document.

Unit Testing

next previous top

Individual tests are performed on each unit in the hopes of clearing up any errors prior to the integration. By recognizing our errors before integration, it will save us from tracing the errors to such a low level once the components are integrated. The following is a list and description of the tests performed on the individual components.

1. Student - View Timetable

next previous top

No errors were generated for the View Timetable unit.

2. Student - Course Registration

next previous top

No errors were generated for the Course Registration unit.

3. Administrator - Add Course

next previous top

No Errors were generated for the preceding Administrator, Add Course unit tests.

4. Administrator - Add New Student

next previous top

No Errors were generated for the preceding Administrator, Add New Student unit tests.

5. Conclusion

next previous top

The unit testing revealed no errors and this is attributed to the rigorous testing done by the programmers during the development stage. These tests were done to ensure that each part is working properly prior to the integration of each module. It is believed that the integration testing will reveal more errors as the database is introduced into the system.

Integration Testing

next previous top

The integration testing is designed to reveal errors after the individual units have been merged. This will be the heart of WinterSoft's testing. WinterSoft is generally able to assume that errors generated in this area are problems with the integration and not the individual units, due to thorough unit testing.

1. Add Course to Timetable

next previous top

The integration testing for the "Add Course" functionality revealed no unexpected errors, although some functionality has been modified in such a way that complete testing could not be carried out. These modifications are acceptable.

2. Drop Course From Timetable

next previous top

The integration testing for the "Drop Course" functionality revealed no unexpected errors.

3. View Student Timetable

next previous top

The integration testing for the "View Student Timetable" functionality revealed no unexpected errors.

4. Add Student

next previous top

The integration testing for the "Add Student" functionality revealed no unexpected errors.

5. Add Course

next previous top

No errors were generated in our first two tests, but another tester found an error which may be attributed to a problem with the database, or with how the system interacts with the database.

6. Waiting List

next previous top

Note: No test case was written for this functionality before, so it is appended here.

The following test examines the component interaction between the ADD COURSE element of the STUDENT CONSOLE logical component and the WAITING LIST operational component. It assumes that a student user is already logged into the system and that the course they are trying to register in is full.

Case 1:

The integration testing for the "Waiting List" functionality revealed no unexpected errors.

7. Modify Course

next previous top

NOTE: The following test was done during integration testing, but the only case that closely resembles it from the test plan is in unit testing, which is why it loosely follows the format of unit test 6.11 Modify Course.

The Modify Course integration test produced an error, which may be attributed to problems with the database, or how the system interacts with the database.

8. Modify Administrator

next previous top

NOTE: This error was found during informal integration testing, but was formatted according to the Modify Administrator unit test, as that is the one which most closely adheres to it.

The Modify Administrator integration test produced an error, which may be attributed to problems with the database, or how the system interacts with the database.

9. Conclusion

next previous top

Integration testing produced some errors, most of which seemed to be related to the database. This is good news, because it suggests that our unit testing was largely successful, and the bugs caused here were all integration-related. Careful analysis of bugs by the testers combined with hard work by our coders help to ensure that the system will be error-free.

Acceptance Tests

next previous top

This section is meant to ensure that the Project Atlantis Registration System meets the requirements set forth by the University of Atlantis. It follows the test cases that the University of Atlantis set out for us in the Acceptance Test document it submitted to WinterSoft.

1. A New Student

next previous top

Introduction

The next scenario shows a student accessing the system. The scenario will cover all of the basic functionality that is available to the student. This functionality includes:

• Login
• Adding courses
• Dropping courses
• Viewing the Timetable
• Automatic Logout

Reference

University of Atlantis Acceptance Test Document - Test 1

Scenario Description

Johnny Talbot is an undergraduate student at the University of Atlantis. It is the beginning of the school year and Johnny would like to register for his courses. At the login in screen Johnny enters his student identification number and his password. Once he has been successfully logged into the system Johnny begins to enroll in the courses that he wishes take.

Test

Login

1. Johnny enters his student ID, "12345678".
2. Johnny enters his password, "big_Fish".
3. Johnny clicks the "OK" button.
4. Access is granted by the system and Johnny is taken to the main student screen.
5. The system displays an error message, indicating an invalid password or ID.
6. Johnny re-enters his password as "big_Star", and clicks "OK".
7. Access is granted by the system and Johnny is taken to the main student screen.

Result: No errors found.

Add Course

1. Johnny clicks on the "Course Registration" button, which takes him to the Registration screen "Step 1".
2. Johnny Selects the course name "Fish101" in the select course field, and clicks "OK".
3. The system will take him to the next registration window "Step 2".
4. Johnny selects the Lecture 1, Lab 1 and Tutorial 1 for the course.
5. Johnny then clicks the "Add" button.
6. The system will enroll Johnny into Lec 1, Lab 1 and Tutorial 1 for the course.
7. Johnny adds CRAB103 (L01 and B01) and TURT123 (L01 and B01) using the same steps as taken for FISH101

Result: No errors found.

Drop Course

1. Johnny clicks the "Course Registration " button from the main student screen.
2. Johnny is taken to the course Registration screen "Step 1".
3. Johnny Selects the course name "Crab103" in the select course field, and clicks "OK".
4. The system will take him to the next registration window "Step 2".
5. Johnny clicks on the "Drop" button.
6. The system will display a confirmation message, to ensure Johnny wishes to drop the course.
7. Johnny clicks the "yes" button in the confirmation screen.
8. The system will then remove Johnny from the course.

Result: No errors found.

View Timetable

1. Johnny clicks the "View Timetable" button from the student screen.
2. The system will then display a window, with Johnny's courses for the current trimester.

Result: No errors found.

Automatic Logout

1. After 6 minutes of inactivity the system will log Johnny out.

Result: No errors found.

Conclusion

This acceptance test evaluates all core functionality that project Atlantis offers to the students. Under this test there were no errors found within the system.

2. A New Professor

next previous top

Introduction

This scenario will display some of the functionality available to the professors. It tests the following functionality:

• Login
• Change Password
• Assign Grades
• Remove Course
• Add Course

Reference

University of Atlantis Acceptance Test Document - Test 2

Scenario Description

Matt Damon is a professor at the University of Atlantis. He is a new professor and is logging into the system for the first time. Dr. Damon logs into the system and starts his day by changing his password. After his login password had been changed Dr. Damon begins to work.

Test

Login

1. Dr. Damon enters his personal ID, "00045555".
2. Dr. Damon enters his password, "ima_star".
3. Dr. Damon clicks the "OK" button.
4. Access is granted by the system and Dr. Damon is taken to the administrator screen.

Result: No errors found.

Change Password

1. Professor Damon clicks on the "Change Password" button from the main administrator screen.
2. The system displays the change password window.
3. Professor Damon enters his old password into the "Old Password" text box, "ima_star".
4. Professor Damon enters his new password into the "New Password" text box, "movie_man".
5. Professor Damon enters his new password into the "Confirm New Password" text box, "movie_man".
6. Professor clicks the "OK" button.
7. The system displays a message saying that the password has been changed.
8. Professor Damon clicks the "OK" button on the display message box.
9. The system brings Dr. Damon back to the main administrator window.

Result: No errors found.

Assign Grades

1. Professor Damon clicks on the "Assign Grades" button on the main administrator window.
2. The system brings him to the assign grades window named "Step 1".
3. Professor Damon selects the course name for which he wishes to assign grades from the "select course" field, " MPHL355".
4. Professor Damon clicks "OK", and the system opens the next window named "Step 2".
5. Professor Damon selects the lecture number from the "select lecture section" field , "L01".
6. Professor Damon clicks "OK", and the system opens the next window named "Step 3".
7. Professor Damon enters the appropriate grades by the student ID's that are displayed (grades are entered by percentage).
8. Professor Damon clicks the "OK" button, and the system brings him back to the main administrator window.

Result: No errors found.

Remove Course

1. Professor Damon clicks on the "Remove Course" button.
2. The system brings him to the remove course screen.
3. Professor Damon selects the course name from the "select course" field box, "FISH201"
4. Professor Damon clicks the "OK" button and the system displays a confirmation prompt to ensure that the user wishes to remove the course.
5. Professor Damon clicks "Yes" in the confirmation box.
6. The system will display a message saying the course has been removed.
7. Professor Damon clicks the "OK" button in the display box, and the system brings him back to the administrator main window.

Result: no error found

Add a Course

1. Professor Damon clicks on the "Add Course" button.
2. The system brings Dr. Damon to the add course window named "Step 1".
3. Professor Damon enters the name of the course he wishes to add in the "course name/number" field, "FISH513".
4. Professor Damon clicks "OK", and the system brings him to the next window named "Step 2".
5. Professor Damon clicks on the "ADD" button for the lecture section, and the system takes him to the next window, "Add Lecture Section".
6. Professor Damon then fills in the appropriate information for the lecture section that he wishes to add. Section - "L01"
   Days - "MWF"
   Time - "8:00"
   Room - "Big224"
   MaxStudents - "40"
   Instructor - "Prof. Damon"
   
7. Professor Damon clicks "OK", the system closes the Add lecture Section screen.
8. Professor Damon clicks on the "ADD" button for the lab section, and the system takes him to the next window, "Add Lab Section".
9. Professor Damon then fills in the appropriate information for the lab section he wishes to add. Section - "B01"
   Days - "MWF"
   Time - "9:00"
   Room - "Big224"
   MaxStudents - "15"
   Instructor - "Dr. Jones"
   
10. Professor Damon clicks "OK", the system closes the Add Lab Section.
11. Professor Damon clicks on the "ADD" button for the tutorial section, and the system takes him to the next window, "Add Tutorial Section".
12. Professor Damon then fills in the appropriate information for the tutorial section that he wishes to add. Section - "T02"
    Days - "MWF"
    Time - "14:00"
    Room - "MS201"
    MaxStudents - "20"
    Instructor - "Jeff Miller"
    
13. Professor Damon clicks "OK" and the system closes the Add tutorial Section.
14. Professor Damon clicks on the "ADD" button for the pre-requisite section, and the system takes him to the next window, "Add pre-requisite Section".
15. Professor Damon enters "MERM420" as a pre-requiste and the system displays an error because MERM420 is not a course offered at the University of Atlantis.
16. Professor Damon enters MERM413 and clicks OK, and the system closes the add pre-req window.
17. Professor Damon enters the course description for the course in the " Description" field box , "This course will teach students physical fittness".
18. Professor Damon clicks the "OK" button , and the system will bring him back to the main administrator window.

Result: No errors found.

Logout

1. Dr. Damon clicks the "Logout" button from the main screen.
2. The system logs him out and displays a message.

Result: No errors found.

Conclusion

After extensive testing of the core functionality for the administrator the system ran without error.

3. The Grad Student

next previous top

Introduction

The next scenario shows the features of the system that a Grad Student from the University of Atlantis would use in the system. The scenario will cover the basic functionality that is available to a Grad Student. This functionality includes:

• View past grades
• Add prerequisite
• Add conflicting course
• Change section

Reference

Scenario Description

Benjamin views his past grades to see how he did last trimester. Then, he adds ENGL 601 L01 for the new trimester. He runs into problems for ENGL 601 because it requires ENGL 501 so he registers for ENGL 501 L01 first. He then tries to add WATR 401 L01, but it conflicts with ENGL 501 so he registers for WATR 401 L02. After adding WATR 401, he realizes that he picked the wrong lecture time. It was too early in the day, and he would not be able to wake up for it. He changes the section to L03.

Test

View Grades

1. Ben clicks on "View Course Taken" button from the Main Student screen.
2. The marks recorded for Ben in the system are displayed.

Result: No errors are generated.

Add a Course with Prerequisites

1. Ben selects the course registration option from the Main Student screen.
2. Ben attempts to add ENGL 601 L01 to his schedule.
3. An error message appears to tell Ben about that a prerequisite is required to take the course.
4. He then adds ENGL 501 L01 to his schedule.
5. Finally Ben adds ENGL 601 to his schedule successfully.

Result: No errors are generated.

Add a Conflicting Course

1. Ben attempts to add WATR 401 L01 to his schedule.
2. The time conflict error message is displayed.
3. Ben then registers for L02 successfully.

Result: No errors are generated.

Change Course Registration

1. Ben clicks on the "Course Registration" button from the menu on the Main Student screen and then the Step 1 window appears.
2. Ben selects WATR401 from the Step 1 window and clicks on the "OK" button.
3. The Step 2 window appears, with a list of lectures, labs and tutorials for the course.
4. Ben changes the section to L03, and he logs out of the system.

Result: No errors are generated.

Conclusion

No errors were found while testing this functionality.

4. The Administrator

next previous top

Introduction

The following scenario will demonstrate the basic functionality available to an administrator, including:

• Overloading a course
• Setting Trimester Deadlines
• Creating a new freshman student

Reference

Scenario Description

A new trimester is approaching and a student, Keanu Reeves, has requested that the administrator overload him into SWIM562 for lecture section 20, lab section 20, tutorial section 22. Mel is feeling extremely annoyed since students have been requesting that he overload courses all day. Mel has not had time to eat his lunch. Keanu Reeves gives him the proper documents, and Mel goes ahead and adds Keanu to the course. Mel then needs to specify deadlines for the upcoming semester. Finally, Mel must add Danny Devito into the system as a new student so that he may be able to register for courses. Then he can eat his lunch.

Test

Overloading a Course

• Mel clicks on Overload a Course from the Main Administrator screen.
• Mel selects Keanu's student ID from the student list and also he selects the course that the Keanu wishes to take.
• Mel clicks on the "OK" button and the Step 2 window appears, with the list of lectures and labs for the course.
• Mel selects "L20" in the provided lecture section field.
• He then selects "B20" in the lab section field.
• Mel clicks on "OK" button to confirm the overload.
• Keanu Reeves is now overloaded into SWIM562.

Result: No errors are generated.

Setting Trimester Deadlines

• Mel clicks on the "Set Trimester Deadlines" button from the main screen.
• The Set Trimester Deadlines screen opens, and Mel enters "01/08/2001" as the registration start date.
• Mel enters "24/09/2001" in the registration end date.
• Mel chooses OK and the registration period is updated.

Note: Changing the registration start date or registration end date affects the other, since the registration period is fixed. No errors were generated.

Creating a new freshman student

• Mel clicks on the "Add Student" button from the main screen.
• The system automatically generates a student ID number for the student.
• Mel enters "Danny Devito" in the student name section.
• The initial password "new_fishy" is entered into the password field.
• Mel selects the status of the new student, either part time/full time or inactive.
• Mel clicks on "OK" button to confirm adding the new student.
• Danny Devito is now in the system as a new student.

Result: No errors are generated.

Conclusion

No errors were found while testing this functionality; the note about Trimester Deadlines reflects a method of setting deadlines which The University of Atlantis approved.

Conclusion

next previous top

This test report tracks our progress in testing the Project Atlantis Registration system, so that we can keep track of potential problem areas, and the process that we went through to deal with bugs. WinterSoft believes that thorough testing is one of the keys to quality software, and this report helps to ensure that we have completed all testing as required. Unit and integration testing to "squash" bugs, and acceptance testing to ensure the system meets our customer's requirements.