You and a partner are developing a program that lets a user play tic-tac-toe against the computer.

The goal is to identify test cases before the code actually exists.

You want to maximize code coverage by testing as many paths through the logic as possible at the same time as controlling time and expense by designing a minimal set of test cases to give you confidence that the code works.

Rules of the game

• The user can choose to play X or O.
• X always goes first.
• Then X and O take turns placing a marker on the board (please show the order with a subscript as in the figure below).
• The goal is to win by placing three markers (X-X-X) or (O-O-O) across one row, down one column, or along a diagonal.

The game often ends in a tie when the nine positions are filled but neither X nor O completed a line

A	B	C
1	O2	X3
2	X1
3	X2	O1

Scope of this exercise

You are engaged in an Agile development process. In this increment, you are focusing on the logic of deciding what move to make. In other words, test the artificial intelligence of a computer playing a game.

Previous increments prepared the board and prototype user interface. You can assume that tests for valid game moves were completed in an earlier increment. For example, assume user or computer dont try to play into an occupied square or play an X when its Os turn. Similarly,

dont worry about how the board is represented internally or displayed to the user. Just trust that some 3x3 display is mapped onto an appropriate data structure in the code.

The code you are testing

The development team has specified the logic for calculating the expert level computers move as trying the following in order:

1. If you have two pieces in a line and can complete a line by placing the third, put your X or O in the winning cell.

2. If the user has two markers in a line and can complete the line on his/her next move, put your marker in the cell that blocks the user from winning.

3. If the middle of the board is free, put a marker there.

4. If least one corner is free, put a marker in a corner. Choose the corner randomly.

5. Select randomly from any of the unoccupied cells.

Notes: The five rules above simplify the logic, and dont always pick the best move. Therefore it is possible for the user to beat the computer. The user doesnt have to follow the same rules and make very silly, but legal, moves.

By removing one or more checks from the points a-e above it is possible to implement other difficulty levels such as intermediary and easy (the user will have easier time to win). However you will be testing the full set of checks as above.

The test objective

The test objective is to verify that the program is applying the rules above in all situations. The goal of this exercise is to design functional tests. Your task is to design and document enough test cases be confident of the verification testing. Testing every possibly configuration of pieces is virtually impossible, even for a game as simple as tic-tac-toe.

Your company will outsource your test cases to test specialists who will implement and execute the tests. Testers will compare actual results with expected results and report all deviations as possible defects.

Instructions

Work with one partner. Healthy discussion and an exchange of different views is good. Finding a consensus approach is part of the exercise. Remember, many different solutions may be good.

First, decide how many test cases you need and list them. Use a numbered list so that the numbering gives each test case a unique identifier and add a headline-style title.

Second, write a detailed specification for two at least test cases. Use the following template:

• Test case identifier from your list of test cases
• Test case title -- from you list of test cases
• Condition in this case it is sufficient to specify which of the rules listed above apply. Do not assume there is a one-to-one relationship between test cases and rules. Some rules may justify several different tests and other may not need any.
• Precondition state before computer makes a move. The precondition must be a valid state that could be reached in a game when the program works correctly.
• Action trigger that causes the program to do something. For example, the user asking the computer to make the first move is an action.
• During play, the users move sets the precondition and the fact the user completes a turn is the trigger for the computer to take a turn.
• Postcondition expected state after the computer has moved. If more than one correct outcome may be possible, show them all.

Dont forget that the computer may be playing as X or as O.

Third, create your solution as an MS Word document. A good way to represent your pre- and post- conditions is drawing the board as a 3x3 table, as in the diagram above.