Statement of test case techniques:The test cases have been designed keeping in mind to increase the testability of game as much as possible. All cases have been covered like positive, negative, functional, structural etc. The test cases covers not only testing of application but also the data of card.txt file.There can be lots of test cases, but the following test case document has designed cases such that everything is covered but without any redundant data. No case is missing , but also no overlapping of cases is there.For better understandability of tester and reviewer, the test cases have been divided into differenttest scenarios. The categories of cases are :“Generation of cards from different mode” ->This will cover cases for different ways and modes to generate cards for players. Major focus is that cards are random. It cover generation of cards from card.txt file as well as randomly if file is not accessible.“Card distributed to user” -> This talks about number of cards distributed and who will get the first 2 cards”Cases for sticks, bust and twists” -> This section covers all combination of cases of actions pf players like stick , bust and twist“Different modes to end game” -> It is mainly designed to cover the cases of how game can be end and what will happen after then“Summing of cards” -> This part is related to cases that the resultant sum of cards shouldbe correct. Different rules are there like treating face value cards as 10 , so such cases are covered.“Pontoon and five trick cases” -> As there are some special scenarios like pontoon and five trick cards which have priority over all other cases, so these are special cases which cover these tricks. User wins if he has such cases , so extra cases are designed for these high priority scenarios.“Data from card.txt file” -> There should be appropriate data in card.txt file without any extra missing or redundant card , so checking of this file is done with help of these cases\“Decision making of computer” -> As computer has to be smart enough to make judgement so these cases also need to be tested , Hence, its covered in this sectionAs all sections and functionality is tested, thus selection of cases is according to its coverage.After executing the test plan, the tester would be confident about boundary cases as weel. Not only positive , but also negative scenarios have been covered.Emphasis to each stage of game is given , so the test selection could be justified with help pf division of categories itself