Level Test Plan for Empire Classic

Ajmal Khan
Blekinge Institute of Technology 371 79 Karlskrona, Sweden

Bilal Ilyas
Blekinge Institute of Technology 371 79 Karlskrona, Sweden

Eleftherios Alveras
Blekinge Institute of Technology 371 79 Karlskrona, Sweden

ajkh11@student.bth.se Islam Saeed Elkhalifa

Blekinge Institute of Technology 371 79 Karlskrona, Sweden

biil11@student.bth.se Mahwish Anwar

Blekinge Institute of Technology 371 79 Karlskrona, Sweden

elac11@student.bth.se Mubashir Iqbal

Blekinge Institute of Technology 371 79 Karlskrona, Sweden

ismo10@student.bth.se ABSTRACT

maan11@student.bth.se

muiq10@studnet.bth.se

Finding the quality of a system becomes more difficult when no requirements, design documents, developers, and documentation of the system is available and all that the testing team has is large, undocumented, unstructured, spaghetti code of a system that has been abandoned. The idea of testing such a system flies in the face of everything given in the books of software engineering especially when there is a lack of adequate resources to adopt reverse software engineering. In this test plan we offer one possible solution to handle this problem and suggest system testing to be the best possible way to test the system. The plan also mentions completing the incomplete requirements, prioritizing them and making test cases for testing such a system. The objective of test plan mainly focuses on ensuring that the version 4.2 of the Empire Classic game does not introduce major deviations from its specified behavior, As a result of this plan a test traceability matrix is developed along with sample test cases to illustrate the methodology, and features to be selected and tested.

Empire is a "text based" [5], server based and turn based strategy game of global conquest and diplomacy. A game administrator creates a world and sets its parameters e.g., the size of the map and the duration of the game etc., to start a new game. Now the players can access it through Telnet client software or terminal emulator software, VT100. Normally, a game continues for many days and players use the messaging and news facilities to update themselves when they log in. The game can be played concurrently by different players. When the duration of the game which is set by the administrator expires the game is over. The player with highest score becomes the winner. Highest score means player's (representing a nation) assets at the end of the game. An example of asset could be the number of sectors occupied by a nation at a certain point of time in the game. The game started as Civilization in 1972 [7] and was written in interpreted BASIC but the code of the game died with the death of the hosting machine HP2000 and was written from scratch one again in 1984 using Pascal. Bell Norton and Peter Langston renamed the newer version as Empire. The Pascal version kept developing until 2003 but all the development of the Pascal version stopped in 2003 and the game was ported to Linux and C++. The Empire Classic Version 4.20 can be downloaded from [4]. This report describes the 2 levels of testing; system testing and acceptance testing. These levels are described in the approach section of this report. We are not planning for unit testing, because we are assuming that the unknown developers of the game have already done the unit testing. The design documents for the game are not available which is another reason for the assumption mentioned above. Although the design documents of the game could be constructed using Reverse Engineering but the strict deadlines given by the customer does not allow enough time to do that. Therefore, only system testing and acceptance testing will be carried out. The timeline for this project is assumed to be fixed (approximately 2 months) and the customer is considered to be unwilling to extend the deadline. Since the testing team comprises of 6 students and all of them are taking other courses as part of their Master degree, their schedules in the other courses might significantly affect the execution of this test plan. The acceptance testing will be carried out by the customer (the course responsible of the course Software Verification and Validation) at the customer site (Blekinge Institute of Technology), after the system has been tested and delivered. A table can be found on Appendix A showing a time schedule.

1. INTRODUCTION 1.1 Document Identifier

Table 1: Document Identifier Document ID LTP_01 Department of Software Engineering Blekinge Institute of Technology 2011-03-23 Ajmal Khan Bilal Ilyas EleftheriosAlveras Islam Saeed Elkhalifa Mahwish Anwar Mubashir Iqbal Dr. Kia Peterson Final ajkh11 biil11 elac11 ismo10 maan11 muiq10

Organization Issue Date

Author(s)

Approver(s) Version

1.2 Scope
This is the test plan for dynamic testing of Empire Classic (version 4.2), referred to as "Empire4" in this document. This test plan covers section 1 and 2 of IEEE Standard for Software and System Test Documentation, 2008 [13]. This test plan mainly focuses on ensuring that the version 4.2 of the game does not introduce major deviations from its specified behavior.

The objective of the testing team is to find any functionality problems in order to improve the gaming experience of the users. The scope of testing for this project involves system testing and excludes unit and integration testing due to the reasons mentioned in the section 2.5 of this plan. We are testing the functionality of the game by playing the game using a terminal emulator with "Telnet" [6]. The team does not test the game on any mobile devices e.g., mobile phones, personal digital assistant (PDA), tablet computers, and smartphones etc.

1.3 Level in the Overall Sequence

As mentioned in the part section 2.5 the level of testing that will be planned is the system testing, reasons and motivations has been mentioned, usually in normal testing, system testing comes after the unit testing where the smallest pieces of the system are tested, and after the integration testing where the interaction between system units are tested. In our case the system testing is performed as a standalone activity, no test plan will developed for unit or integration testing, reasons for excluding other testing levels are mentioned in the approach part 2.5.

This test plan does not include regression testing or re-testing due to the non-availability of the developer team. Therefore, no test conditions for regression testing are mentioned in this test plan. During the live on server testing the game will be tested by connecting it from the Windows 7/Vista/XP and Unix operating system (Ubuntu version 11.10). The log in and log out related security features would be tested by starting a game, logging out and then logging in after 1 week to ensure the game behaves as expected and that the security of the game is not compromised by restarting the server etc.

2. DETAILS FOR THIS LEVEL OF TEST PLAN 2.1 Test items and Their Identifiers
The objects of testing are listed in Appendix C and the game source website http://empire.sourceforge.net/ along with their identifiers. The requirements were grouped according to the important features. Items that are to be specifically excluded from testing are mainly implicit features detailed in section 2.4.

1.4 Test Classes and Overall Test Conditions

1.4.1 Test Cases
The test cases shall be divided into the following four classes: Invalid Input: Contains test cases that check the system behavior on giving an erroneous input. The purpose is to ensure that the system behaves the way it should even if erroneous input is given to the system. Valid Input: Contains test cases that test the systems behavior when it receives legal values from the user. Stress-Testing class: Contains test cases that test the robustness of the system and its scalability with respect to the number of players that can play the game on line. For example, one test case in this class will check the scalability of the system by making sure that the game behaves as expected when the maximum number of players allowed plays the game simultaneously. Output Class: Contains test cases that will test the output given by the system e.g., the display of the assets at the end of the game, the display of information, such as command related information or data like the types of ships, etc. The above classes are compatible with our decision to perform only system testing. In addition, since the games documentation is rather inadequate, most of the information a player needs to play the game can be found in-game, which justifies the Output class. Experience of a previous player has also led us to consider that playing the game at its limits (largest map possible, largest number of players) is not uncommon. Therefore, there is a need to test the game under stress conditions; hence the class StressTesting.

2.2 Test Traceability Matrix

A sample traceability matrix is shown in Table 2. Each unit of the traceability matrix depicts the traceability relationship between the row (requirements) and the column (test cases). The requirements were identified and linked to corresponding test case(s) given in Appendix B. The relationship of rows and columns can represent forward traceability as well as backward traceability. Team has only developed sample traceability matrix and test cases to illustrate the methodology.

2.3 Features to Be Tested

We got the system without design documents, and requirement specifications and, therefore, we did not have any details about the features of the system. To solve this problem we decided to identify the features of the system by studying the available online documentation. Similarly, to handle the problem of incomplete requirements we observed the system, interacted with it, used it and studied the available documents to make a requirement document. Next, we grouped those requirements by features. Of course, only a small portion of the requirements were extracted for the purpose of demonstrating our approach. The requirement extraction and groping of the features was done manually and no automatic tool was used due to the lack of available documentation.

2.3.1 Methodology
Methodology used by the team was to first extract a portion of the system requirements from the game description available on the game website, and then analyze the requirements and identify system features. The following constraints apply to the requirements engineering process: Customer is not available to verify or explain the requirements; therefore only explicit requirements can be extracted and verified through reading about the game and playing the game. There is no description of system features and system specifications available, the only available source of requirements is the game description found on the game website.

1.4.2 Test Conditions

The test conditions that we decided on and we think are compatible with the specific characteristics of this project, are the following: The system shall be tested on the laptops using telnet as well as live on the server available on the Internet. The scalability of the game on the server would be checked by at least arranging 255 players to play the game live and simultaneously. At least 3 tries will be made to connect the created but inactive game and expired games.

Table 2: Test Traceability Matrix No. 1 Req. Id UM002 Requirement Description Administrator creates the game by generating the world and setting world parameters, after that the game is considered active. The game must be created by an administrator and hosted on a server. Players must be able to access the game concurrently. Players can only access active games. The creator of a game sets its duration. When that duration is over, the game ends. .. .. Test Case Applied 2 Test Cases TC-001 x TC-002 x TC-003 TC-004 TC-005 TC-006

UM003

3 4 5 6

UM004 UM006 GR-001 GR-002 . .

1 1 1 1 7 1 1 2 x

x x

x 1 1 1

The requirements are extracted based on the rules described for playing the game and the historical information provided by the communities who played the game. Game has been abandoned and only one server exists for playing the game [7]. The requirements were elicited and derived from the game description found on empire.sourceforge.net, first from the game description general system features and functional requirements were elicited, then analyzed and then validated. A result of this is software requirements specification containing system requirements grouped by features found in Appendix C, the system features are identified, one system feature can have one or more associated functional requirements. Further requirement elicitation from the game itself, as well as from the available online documentation is due. That will produce a large number of system features and not all the features can be tested given the limited time, a selection should be performed to select features for testing or there should be some order to test system features. In our case we came to a conclusion that all system features should be tested unless there is a shortage in resources, for example time. Since limited resources may hinder the testing of all the features that can be extracted, a strategy needs to be planned. The strategy we decided on is to ensure that the most important features are tested first. This strategy is illustrated by the following two issues. First there should be some order to test the features, we have used a method to prioritize system features scheduled to be tested, and we have identified the following classes of priority. Note that these classes were identified by our team, based on our experience with strategy games and our understanding of the game. They may not depict the intention of the original development team. The results of this classification can be seen in Appendix D.

a) Critical The critical features are those which are part and parcel of the system and therefore, their implementation is vital for the game. These requirements/features critical, they have to be implemented and they have to be implemented right. Otherwise, the game will probably be a waste of time for any player or even become dangerous (e.g. if user authentication does not work). b) Standard These requirements should be implemented correctly, as they represent essential aspects of the game. However, the game can still be functional without them. c) Trivial These requirements would be nice to make sure that they are implemented correctly, but if they are not, the game play is not severely damaged. d) Irrelevant These requirements do not describe actual modules of the game, e.g. the game does not implement the protocol TELNET or uses it in any way (the server uses it, not the game itself). We cannot test something that is not a part of the game. Testing will start from the features from the critical class and then the standard, trivial and at the end the irrelevant. We have classified all the system features we acquired in the critical class because we could extract the explicit and important features and their associated requirements, they fit in the description of the critical class. The second issue is that, inside each class the features shall be further prioritized and ranked in order of importance, to perform this requirement prioritization method, Analytical Hierarchy Process (AHP) can be used for the prioritization [9]. The reason for prioritizing the requirements is that there could be a dependency between them, so if a feature or a group of

requirements are depending on another feature, the second feature should be tested first. The reason that this prioritization is not demonstrated in this report is time limitations, as the computational effort required by AHP is quite high. However, requirement prioritization is planned as part of the overall testing process.

2.3.2 Rationale
The methodology we have used ensures that we will acquire a description of the system features, as we dont have a clear requirements specification, in addition it ensures that the features and their associated requirements are consistent, clear, prioritized and well documented because we have performed elicitation, analysis and specification of the requirements.

reasons. We have no design documents, no unit tests reports from the unknown developers and no details of the interfaces between the different components. It is not possible for this team to make the design documents from the incomplete requirements and the available spaghetti code in such a short time. Due to these reasons no other level of testing will be considered except the System testing. The testing team will carry out System testing due to the following reasons: 1. 2. 3. The system is ready and has been handed over to this team for testing. Now it needs to be verified. System testing will give us an external view of the system that matches closely with the users view of the system. We can test the system in a controlled environment before transferring it to the production environment where any player from any part of the world will be able to take part in an online started game. This will enable us to ensure that the gaming experience provided by the system is according to the expectation mentioned in the requirement specification and that the game is supposed to do what it is required to do and not to do what it is not supposed to do. No design documents are required for carrying out System testing and we can carry out system testing although we do not have any design documents. The required setting, telnet emulator, telnet facility, laptops, desktop computers and skill to network them is available and the required testing conditions for system testing can be provided formally. The testing team has the skill to write scenario-based system test scripts with predicted output and have enough knowledge to log the results in a formal way. The other testing levels like unit and integration testing is preferred to be performed during system development. This is not applicable to our system as the system has already been developed.

2.3.3 Implementation
The team has classified all the features as important, reasons for that are mentioned above, after that team has demonstrated the method by implementing a traceability matrix in section 2.2 showing an example of requirements and the corresponding test cases to verify them, test cases can be found on appendix B, the system didnt perform requirements prioritization for the requirements within one priority class using the Analytical Hierarchy Process because of time shortage.

4.

2.4 Features Not to Be Tested

It is likely that not all of the features will be tested due to the limitations of available resources. Limited available time, pressing deadlines as well as external factors may hinder the testing process. As a result, the time might not suffice to test all of the features. However, with the strategy that is outlined in the section 2.3.1, we ensure that the features that will not be tested will be the less important ones. 5.

6.

2.5 Approach
2.5.1 Testing Levels
Testing will be done at two levels i.e., System testing and Acceptance Testing. One of the team member will make test cases for the Acceptance Testing but no member of the team will take part in the Acceptance Testing at the customer premises as preparation of this test plan is part of course requirement of the Verification and Validation Course at Blekinge Institute of Technology and the course responsible is the customer for the system in hand. Throughout this report the term customer refers to course responsible. Acceptance testing will be done after the system is delivered to the customer with a few sample test cases for the Acceptance testing and the customer will do the acceptance test. Unit testing will not be done because the system developed is outdated, abandoned and the development team responsible for the code is not known. Documentation of the game is not available and the code is very large (approximately 34,000 lines of code in C++). Due to the time limitation it is not possible to do reverse engineering to make the design documents from the code. The requirements of the game are not complete and there is no way to make design documents for the already written code using the incomplete requirements or the available code. The code is spaghetti code and is more structural than modular. For these reasons, this team will not carry out any unit testing. The system has already been integrated and, therefore, no integration testing will be carried out. The team will not check how the components have been integrated due to the following

7.

8.

2.5.2 Testing Tools

Due to the absence of customers, no requirement extraction or prioritization tools were used. The requirements had to be written by interacting with the system and, therefore, no tool was used. Since most of the tools take the design documents as input and we did not have any design documents, we could not use those tools that could be used in the testing process.

2.5.3 Meetings
The testing team will use physical and online meetings to discuss their progress, problems, if any, or other related issues. The frequency of the meeting is one physical meeting per week and one short Skype meeting per week. The Skype meeting will save time and is flexible as any group member can request to call the meeting any time during the week. On the other hand the physical meeting will provide an opportunity to the group leader to check the progress, discuss problems, and share information. Other than the planned meetings, emergency meeting can be arranged if need be any time. The details of the tentatively planned meetings are given in the Gantt chart in Appendix A to this report.

2.5.4 Measures and Metrics

During an earlier project the same testing team carried out the inspection of the code of the game. This provided with information to the testing team about the defects and their severity in most parts of the code. The origin of the defects is already known to be the source code as there are no design documents and the inspection was done on the code of the game. The team already knows what functions have more and/or serious defects. In addition to the metrics collected and mentioned above the testing team will collect the following metrics during this phase. 1. 2. 3. Defects revealed by the system testing and their severity. The origin of the defect (module/function) in the source code. Amount of time spent to discover a defect. Since major and serious defects matter most, therefore, their time will be noticed individually for each defect and for the minor defects, we will just sum up the total time taken by defects of a certain type and a particular severity level together. Number of defects that were not caught at the system testing level but were caught in the Acceptance testing by the customer will be noted.

these scenarios. Scripts will be made for most of the scenarios representing a typical user session e.g., logging in and taking part in an existing game, capturing an island, exploring a new island, populating an island, making ships, engaging an enemy in combat, communicating with another rival nation for diplomatic purposes etc. Each of the test script written for any scenario will contain the expected result(s) also. A few test cases are given in Appendix B with this report.

2.6 Item Pass/Fail Criteria

A criterion that is used to determine whether each test item passed or failed the test is the number of anomalies found in severity category. Our choice is motivated by the fact that it is the most common criteria to pass/fail an item [13]. Also the criteria selection should be based on level of the plan. For higher level plan, testing of system and user functional requirements can be done using the number of defects along with severity [8]. We performed the item selection manually using the number of anomalies as the criterion.

4.

2.7 Suspension Criteria and Resumption Requirements

In this section of the test plan, criteria to suspend all or portion of the testing activity and to resume the testing activity are described. Normally, testing is suspended at the end of each working day and all the test-related documents are handed-over to the testing team leader. Testing is resumed on the following work day morning from the point where it has been suspended [2]. However, in certain situations, normal conditions may not be applicable. All the abnormal conditions and their details require to be specified where testing may need to be suspended based on the effects or criticality level of defects or failures. Further, all the requirements and conditions for resuming or restarting the testing activities need to be specified in this section of the test plan [2][1]. The criteria which could be considered for suspension are: The system contains many critical defects which seriously prevent or limit testing progress Unavailability of assigned test resources (e.g., hardware/software) when needed by the testing team In such conditions, testing will only be resumed when the problem(s) that caused the suspension have been resolved, i.e., after the defects removal by development team, or on the availability of the required test resources. When a critical defect is the cause of the suspension, the fixed version of the system (by the development team) must be verified by the testing team before testing is resumed, i.e., the system will have to undergo a regression test before resuming the normal testing [2]. In our case, as we dont have any development team, and also this is not our task to fix the defects, so we have assumed that testing will be suspended and resumed only on the basis of our test schedule.

2.5.5 Preparing for the System Testing

One of the team members will explore all the material available about the game on the Internet and analyze them. This will provide material to the testing team for brainstorming to complete, to some extent, the incomplete requirement of the system. After the list of requirement has been adequately developed, Appendix C, another team member will develop test cases for system testing of the game. Information will be noted about each test case in terms of its input, expected result, evaluation criteria, test procedure and any data required for carrying out the test. The test cases designed shall cover all aspects of the system. The testing environment will be formal to avoid the risk of testing one part of the system more thoroughly than other during the system testing. The testing team does not have access to resources to test under conditions similar to production environment as this involves hosting the game on some server and providing online access to the game from any part of the world. In spite of these constraints the testing team will try to simulate conditions approximating the production environment as closely as possible in order to carry out the system testing effectively. The human resource and the time resource available are shown in the Gantt chart given in Appendix A.

2.5.6 Performing the System Testing

The team will be divided into 2 groups and half of the test cases will be performed by each group to expedite the process and meet the deadline. Each group will be responsible of making the log of all the defects discovered and all the related information. The groups will ensure that all the requirements in the requirement specification document and associated with respective test cases in the Test Traceability document that are related to the system testing are tested.

2.8 Test Deliverables

The documents that shall be produced during the testing process are the following: Test Strategy [10] Test Case Specification [10][3] Test Summary Report [10][3] Test Plan [11][12]

2.5.7 Developing System Test Cases

To ensure this the formality of the testing process will use scenarios and the testers "will have to read their lines written for them" like actors in a drama with no whimsical activities in the process. The whole process of system testing will be divided into different scenarios and test cases will be designed to test each of

Test Design Specification [3] Test Traceability Matrix [12][11] Test Incident Report (a.k.a. bug report) [3] Test Log [3] Test input data and test output data shall be included in the test case specification document [13]. Testing tools shall not be used, as mentioned in the section 2.5 [13]. The delivery process of the completed information is inconsequential, as there are no individual or organizational entities that shall need the test deliverables listed above [13].

[6]

[7] [8]

[9]

[10]

3. REFERENCES
[1] [2] [3] [4] Ammann, P. and Offutt, J. 2008. Introduction to Software Testing. Cambridge University Press. Burnstein, I. 2003. Practical software testing: a processoriented approach. Springer. Copeland, L. 2004. A practitioners guide to software test design. Artech House. Empire - Browse /EmpireClassic at SourceForge.net: http://sourceforge.net/projects/empire/files/EmpireClassic/ . Accessed: 2012-03-21. Empire Classic About: http://empire.sourceforge.net/About.html. Accessed: 201203-21.

[11]

[12]

[13]

Empire Classic FAQ:http://empire.sourceforge.net/FAQ.html. Accessed: 2012-03-21. Empire Classic: http://empire.sourceforge.net/. Accessed: 2012-03-21. IEEE 829 - Standard for Test Documentation Overview: http://gerrardconsulting.com/tkb/guidelines/ieee829/main. html. Accessed: 2012-03-21. Karlsson, J. and Ryan, K. 1997. A cost-value approach for prioritizing requirements. IEEE Software. 14, 5 (Oct. 1997), 6774. Software Testing Documentation: http://extremesoftwaretesting.com/Testing/TestingDocume ntation.html. Accessed: 2012-03-22. Software Testing Life Cycle: http://www.slideshare.net/UdayaSree/software-testing-lifecycle-presentation. Accessed: 2012-03-22. What are Test Deliverables - Software Testing Mentor: http://www.softwaretestingmentor.com/testdeliverables/what-are-test-deliverables.php. Accessed: 2012-03-22. 2008. IEEE Standard for Software and System Test Documentation. IEEE Std 829-2008.

[5]

Appendix A
Table 3: Schedule Activity Kick-off Meeting Requirement Elicitation Requirement Prioritization Test Preparation Test Case Development Test Execution Finalization & Deliverable Submission Expected Start Date 26 March 29 March 5 April 9 April 16 April 30 April 28 May Expected End Date 28 March 4 April 6 April 13 April 27 April 26 May 31 May

The entire team shall participate in all of the activities in the schedule above. The team members are Ajmal Khan, Bilal Ilyas, Eleftherios
Alveras, I. S. Elkhalifa, Mahwish Anwar, Mubashir Iqbal.

Appendix B
Abbreviations Table 4: Table of Abbreviations Complete Word User Management Game Rule Test Case Test Cases Table 5: Test Case 001 Test Case Id Created By Requirement Id TC-001 Mubashir Iqbal UM-002 Test Case Description Performed By Requirement Description Verify that only administrator can create world and set parameters of the world. (To be filled by tester) Administrator creates the game by generating the world and setting world parameters, after that the game is considered active. Abbreviation UM GR TC

Dependency or Pre-requisites Execution Priority Test Steps

Game server should be alive. Low 1. Login by using administrators account. 2. Try to create new world in the game. 3. If successful, then specify the parameters for the newly created world. 4. Set these parameters to newly created world. 5. Login by using players (non-administrator) account. 6. Try to create new world in the game. 7. If successful, then specify the parameters for the newly created world. 8. If successful, set these parameters to newly created world. 1. Administrator user name and password 2. Simpler player user name and password 3. Integers values for world parameters Only administrator should be able to create new world in the game and same behavior should be presented to set the parameters for a world. NILL (To be filled by tester) (To be filled by tester) (To be filled by tester) (To be filled by tester)

Test Data

Expected Results Other Test Cases Involved Actual Results Status(Pass/Fail) Bug Id(s) Remarks

Table 6: Test Case 002 Test Case Id Created By Requirement Id TC-002 Mubashir Iqbal UM-002 Test Case Description Performed By Requirement Description Verify that game should only be active after administrator creates a world and set its parameters (To be filled by tester) Administrator creates the game by generating the world and setting world parameters, after that the game is considered active.

Dependency or Pre-requisites Execution Priority Test Steps

Game server should be alive. High 1. Login by using administrators account. 2. Try to create new world in the game. 3. If successful, then specify the parameters for the newly created world. 4. Set these parameters to newly created world. 1. Administrator user name and password 2. Integers values for world parameters Game should be active and available to players to participate in the game. NILL
(To be filled by tester) (To be filled by tester) (To be filled by tester) (To be filled by tester)

Test Data Expected Results Other Test Cases Involved Actual Results Status(Pass/Fail) Bug Ids Remarks

Table 7: Test Case 003 Test Case Id TC-003 Test Case Description Performed By Requirement Description Requirement Description 1. Verify that only administrator can create and host the game on server. 2. Verify that creator can set game duration. (To be filled by tester) The game must be created by an administrator and hosted on a server. The creator of a game sets its duration.

Created By Requirement Id Requirement Id Dependency or Pre-requisites Execution Priority Test Steps

Mubashir Iqbal UM-003 GR-001

Game server should be alive. Medium 1. Login by using administrators account. 2. Perform only administrator part of TC-001 (Test step 1-4) 3. If successful, then host the game on server. 4. Then, perform player part of TC-001 (Test step 5-8) 5. If successful, then try host the game on server. 6. If successful, then set game duration. 1. Administrator user name and password 2. Simpler player user name and password 3. Integers values for world parameters 4. Time value to set the game duration Game should be successfully hosted on server only by using administrator account.Only game creator can set and update the game duration. TC-001
(To be filled by tester) (To be filled by tester) (To be filled by tester) (To be filled by tester)

Test Data

Expected Results Other Test Cases Involved Actual Results Status(Pass/Fail) Bug Ids Remarks

Table 8: Test Case 004 Test Case Id Created By Requirement Id Dependency or Pre-requisites Execution Priority Test Steps TC-004 Mubashir Iqbal UM-004 Test Case Description Performed By Requirement Description Verify that multiple user can play the game concurrently. (To be filled by tester) Players must be able to access the game concurrently.

Game server should be alive. Game already been created and hosted on server. High 1. Login by using a players account. 2. Try to connect to the already created game. 3. Login by using another players account. 4. Try to connect to the same game. 5. Repeat the steps for multiple players with-out log out any user 6. And also, check behavior of game by logging out some of the users which are playing the game. 1. User names and password for multiple users. 2. .. Multiple users should be able to play the game concurrently and by logging out one user from the game should not affect any other users session and scores etc. NILL
(To be filled by tester) (To be filled by tester) (To be filled by tester) (To be filled by tester)

Test Data Expected Results Other Test Cases Involved Actual Results Status(Pass/Fail) Bug Ids Remarks

Table 9: Test Case 005 Test Case Id Created By Requirement Id Dependency or Pre-requisites TC-005 Mubashir Iqbal UM-006 Test Case Description Performed By Requirement Description Only active games should be accessible for user to play. (To be filled by tester) Players can only access active games.

Game server should be alive. Multiple games should be hosted on the server. At least one game should be active. At least one game should be in-active.

Execution Priority Test Steps

High 1. Login by using players account. 2. Try to connect to the already created and active game. 3. Try to connect to the already created and inactive game. 1. User names and password for multiple users. 2. .. User should only be able to connect with active games. NILL
(To be filled by tester) (To be filled by tester) (To be filled by tester) (To be filled by tester)

Test Data Expected Results Other Test Cases Involved Actual Results Status(Pass/Fail) Bug Ids Remarks

Table 10: Test Case 006 Test Case Id Created By Requirement Id Dependency or Pre-requisites Execution Priority Test Steps TC-006 Mubashir Iqbal GR-002 Test Case Description Performed By Requirement Description Verify that expired games and not available to play. (To be filled by tester) When that duration is over, the game ends.

Game server should be alive. High 1. Login by using administrators account. 2. Create and host a game. 3. Set a short duration for the game. 4. Login by using players account. 5. Try to connect with the newly created game. 6. Wait until game is expired. 7. Try to play the game after its expiry time. 1. User names and password for multiple users. 2. .. Game should not be available after expiry time. NILL
(To be filled by tester) (To be filled by tester) (To be filled by tester) (To be filled by tester)

Test Data Expected Results Other Test Cases Involved Actual Results Status(Pass/Fail) Bug Ids Remarks

Appendix C Software Requirements Specifications for the Empire Game Description

This document contains a requirements specification for the empire game, the requirements are grouped by feature where each feature can have one or more functional requirements, specification is done with reference to the IEEE recommended practice for software requirements specification. The requirements is specified in the context of performing system testing, in system testing the overall system is tested against the requirements specification to ensure its conformance to the specifications.

Methodology
The requirements were elicited and derived from the game description found on empire.sourceforge.net, first from the game description general system features and functional requirements were elicited, then analyzed and then validated. Constraints and considerations Customer is not available; therefore only explicit requirements can be extracted through reading about the game. Only available source of requirements is the game description found on the website The requirements are extracted based on the rules described for playing the game and the historical information provided by the communities who played the game. Game has been abandoned and only one server exists for playing the game. Requirements grouped by features a) User management Description User management is the feature to manage the different users of the game. Associated functional requirements The game has 2 types of users, administrators and players. Administrator creates the game by generating the world and setting world parameters, after that the game is considered active. The game must be created by an administrator and hosted on a server. Players must be able to access the game concurrently. A player must locate a server to log into and play the game. Players can only access active games. Each player must have a unique nation number or name and password. The server should check the nation name in the database, if the user exist server should ask for the password. And authenticate the player and grant him access to the game. Every time a player log in to that game, the game shall load the resources of that nation as they were when you last left them. If the nation doesnt exist the system should ask the player if he is a new player, if the player enters yes the server must ask the player to choose a password, then remember the player and grant him access to the game.

A player must use telnet to connect to the server. Players must be able to play at various times with news and mail facilities letting players know what has transpired since their last game session. The player can communicate with other players through mail or radio (a primitive chat) to negotiate peaceful coexistence (diplomacy), or engage the other nations through combat (conquest). b) Game rules Description This feature describes the general rules to initiate and terminate the game. Associated functional requirements The creator of a game sets its duration. When that duration is over, the game ends. The winner of the game is the one that has attained the highest score when the game ends. The score is determined by the value of "power" a nation has. The value of power is calculated based on the assets a nation has, e.g. the number of sectors a nation has occupied. The exact formula for computing the value of power was not found. c) Game playground Description A feature describes the playground of the game. Associated functional requirements Map Each game shall take place on a map. The map shall be modeled with a rectangular grid (like a chess board). Each map shall be randomly generated, based upon parameters, which are set by the game administrator. Sector basic Each cell in the grid shall be called "sector". Each sector shall be either a water sector or a land sector. Each sector shall be identified by a pair of coordinates (e.g. x and y). The sector [1, 1] corresponds to the top-left sector of the map. Islands Each map shall have a set of islands. An island occupies a subset of sectors of the map, which comprises the map of the island. Each island sector shall either be a water sector (for modeling rivers, lakes and coast lines) or land sector. Each island sector shall be identified by a pair of coordinates (e.g. x and y). The island sector [1, 1] corresponds to the top-left sector of the island map. The world coordinates of an island shall be represented by the world coordinates of the island's sector [1, 1]. The world coordinates of an island shall be determined randomly during the generation of the map. The translation formula between world coordinates and island coordinates for a sector that is also an island sector is:

World coordinate wcX of island sector [isX, isY] = island coordinate X + isX - 1 o World coordinate wcY of island sector [isX, isY] = island coordinate Y + isY - 1 Each island shall have a random size and shape. Sector Detailed A sector may be a part of an island map, in which case it shall also be an island sector. A sector can never belong to more than one island. If a sector is also an island sector, it has two types of coordinates: o world coordinates (coordinates in the map) o island coordinates (coordinates on the island it belongs to) Each nation in the game shall be controlled by one player. Each nation shall start on one of the map's islands. Each land sector may contain "people" or/and "items". A land sector shall NOT contain ships, unless designated as Waterway. A water sector shall contain NEITHER people NOR items. A water sector may contain ships. Each land sector shall either be "owned" or "not-owned". An owned land sector can only be owned by a single nation. A land sector is owned by a nation, if and only if it contains people belonging to that nation. A not-owned land sector is not owned by any nation. An land sector is not-owned, if and only if it contains no people from any nation. A not-owned land sector may contain items (which were abandoned by a nation which moved all the people from the sector, but left some items behind). A land sector may be a mountain. A land sector that is owned shall have a "designation". A mountain shall have no designations, even if it is owned. A designated sector shall have a specific function, as described in this page. d) Game items Description This feature describes different items on the game else that the playground and their properties, a user play the game using these items. Associated functional requirements People There shall be two types of people: o civilians o military Civilians shall be able to "breed" (population growth). All population growth appears as new civilians. Civilians shall be able to produce items. Civilians shall NOT be able to attack or defend a sector. If a nation's sector is conquered by another nation, the ownership of the civilians of that sector shall pass to the conquering nation. Civilians can be "drafted" to become military. Military can NOT be converted back to civilians. Military shall NOT be able to produce items.

Military shall NOT be able to breed. Items other than players Items can be any of the following: ore, explosives, artillery, ships and aircraft. Aircraft items shall be either fighters or bombers. Ore shall be used to produce all other items. Ore shall be used as fuel for ships. One unit of ore shall enable a ship to travel 10 water sectors, no matter what the type of the ship is. Explosives shall be used as: o "artillery shells" by artillery o "bombs" by aircraft o "shells" and "torpedoes" by ships Ore, explosives and artillery may be stored in any land sector. Aircraft shall only be stored in land sectors, which are designated as airports. The location of a ship on the map is determined by its world coordinates. Commands to ships shall only use world coordinates, not island coordinates. Each water sector may contain unlimited number of ships. Each ship shall have at least 1 military to operate it. The different types of ships, along with their respective attributes, shall be shown to the player with the command "DATA" There shall be two types of water sectors: o island water sectors; also called island waters or inland waters o sea water sectors; also called sea waters or ocean waters The island waters include all the sectors that form the rivers, lakes and coastline of the islands. All the other water sectors are sea waters. There shall be two types of ships: o ships that can only navigate island waters o ships that can navigate any water sector, be it island water or sea water The ships that can navigate sea waters shall have the option "Sea Going" enabled. e) Interface and connection modes Description This section describes interface properties and the modes of connection and their associated rules. Associated functional requirements The interface of the game shall be a command-line interface. There shall be two types of command-line modes; the "land" mode and the "sea" mode. The command-line shall show a prompt to the user, which shall inform him of whether he is in land or sea mode. The commands a player is allowed to enter shall depend on the command-line mode that is currently active. While in land mode, the commands shall relate to actions on a particular island. While in land mode, the prompt shall be of the following form: [$islandName : $timeUnits1/$timeUnits2], where o $islandName is the name of the island

o o
-

$timeUnits1 is related to in-game time $timeUnits2 is related to in-game time While in sea mode, the commands shall relate to actions on a particular ship. While in sea mode, the prompt shall be of the following form: [$shipType #$shipNumber:$fleetNumber$timeUnits], where o $shipType is the type of the ship o $shipNumber is the number of the ship o $fleetNumber is the number of the fleet the ship is assigned to o $timeUnits is related to in-game time

f) Time settings Description This feature describes the time settings and units used in the game. Associated functional requirements Each island, which has a land sector designated as a capitol, shall produce time units for the player that owns that capitol. Time units, produced by a capitol in an island, may be spent from the player that owns that capitol to perform actions in that island. Spending time units on an island shall NOT have any effect on the time units of any other island. Each ship shall have its own production of time units. The time units of a ship can be spent to perform actions on that ship. A ship shall spend 1 time unit to travel 1 sector. Time units are produced at regular time intervals.

Appendix D
Requirement classification, all the requirements of Appendix C are considered critical, unless stated otherwise. User management The game has 2 types of users, administrators and players. [Standard] The game must be created by an administrator and hosted on a server. [Irrelevant] A player must locate a server to log into and play the game. [Irrelevant] Players can only access active games. [Irrelevant] A player must use telnet to connect to the server. [Irrelevant] The player can communicate with other players through mail or radio (a primitive chat) to negotiate peaceful coexistence (diplomacy), or engage the other nations through combat (conquest). [Standard] Game rules The creator of a game sets its duration. [Standard] When that duration is over, the game ends. [Standard] The winner of the game is the one that has attained the highest score when the game ends. [Standard] The score is determined by the value of "power" a nation has. The value of power is calculated based on the assets a nation has, e.g. the number of sectors a nation has occupied. [Standard] Game playground Each map shall be randomly generated, based upon parameters, which are set by the game administrator. [Trivial] Islands Each island sector shall either be a water sector (for modeling rivers, lakes and coast lines) or land sector. [Standard] Each island shall have a random size and shape. [Trivial] Sector detailed A not-owned land sector may contain items (which were abandoned by a nation which moved all the people from the sector, but left some items behind). [Standard] A land sector may be a mountain. [Trivial] A mountain shall have no designations, even if it is owned. [Trivial]

Appendix E
The specifications of the machines used for the system testing. Table 11: Machine Specifications Team Member Islam Saeed Elkhalifa Ajmal Khan Eleftherios Alveras Mubashir Iqbal PC /LapTop Toshiba Acer Samsung Toshiba Processor Intel Pentium T600 PentiumT42002.0 GHz, 800 MHz FSB Intel Core i5, 2.30 GHz Mobile AMD Sempron Processor 3600+ 2.00 GHZ Intel Core i5, 2.40GHz Intel Core i3, 2.13 GHz Memory 2 GB DDR 4GB DDR3 4 GB DDR 1.50GB DDR3

Bilal Ilyas Mahwish Anwar

Acer Dell

2 GBDDR3 4GB DDR