Check List for Test Cases

Project ID Project Name Prepared by Version no.

Following aspects are to be considered while preparing test cases in System Testing. In case, any aspect is not application for the project under consideration, the N.A. needs to be mentioned against the same aspect.
Sl no. 1 2 3 4 5 6 7 8 Aspects to be considered Look and feel Alignment of the page(s) Size Checks Validations at Submit Data Storing Data Viewing Links in the page(s) Multi-browser compatibility No. of Test Cases

After preparing test cases, the QC member will fill this document and make sure that this is upto date. The version number of this document would be compatible to that of the Test Cases. Subsequently, this document is kept in project box file, SVN & CDD while closing the project. In case, any more aspects are needed for the project under consideration, such aspects need to be included in the above table and the number of test cases needs to be updated against the same aspect.

Prepared by: Signature: Date:

Annexure - Types of Testing

Unit Testing and Component Testing A software unit represents a small unit of software functionality. A unit typically is the work of one programmer. Unit Testing focuses on the programming logic within the unit, while ignoring the interaction with other components. Called components are replaced with stubs, simulators, or trusted components and calling components are replaced with drivers or trusted super-components. A software component is the integration of one or more software units. It performs one or many meaningful tasks. Component testing is similar to unit testing but the interaction is with other components not stubs or simulators. Software developers usually perform unit and component testing. If the development of a component involves one developer, unit testing and component testing are combined. In a system the functionality of a use case or a Module/Process/Function will be considered as the unit/component for test case development. For test cases can be developed using the format referred in the section Test Case Format While doing the unit testing for each module / function as the case may be, the following checklist to be kept in mind Test Item Is the number of input parameters equal to number of arguments? Do parameter and argument attributes match? Do parameter and argument units system match? Is the number of arguments transmitted to called modules equal to number of parameters? Are the attributes of arguments transmitted to called modules equal to attributes of parameters? Is the units system of arguments transmitted to called modules equal to units system of parameters? Are the number of attributes and the order of arguments to built-in functions correct? Are any references to parameters not associated with current point of entry? Have input only arguments altered? Are global variable definitions consistent across modules? Are constraints passed as arguments? Tested/Not Tested

When a module performs external I/O, additional interface tests must be conducted.
Test Item File attributes correct? OPEN/CLOSE statements correct? Format specification matches I/O statement? Buffer size matches record size? Files opened before use? End-of-file conditions handled? I/O errors handled? Any textual errors in output information? Tested / Not Tested

The local data structure for a module is a common source of errors. Test cases should be designed to uncover errors in the following categories Test Item Improper or inconsistent typing Erroneous initialization or default values Incorrect (misspelled or truncated) variable names Inconsistent data types Underflow, overflow and addressing exceptions Tested / Not Tested

From a strategic point of view, the following questions should be addressed Test Item Has the component interface been fully tested? Have local data structured been exercised at their boundaries? Have all independent basis paths been tested? Have all loops been tested appropriately? Have data flow paths been tested? Have all error-handling paths been tested? Tested / Not Tested

Integration Testing Integration testing examines the interactions between various software components. The test usually goes through several real-word business scenarios to see whether the system can successfully complete workflow tasks. Software quality assurance team usually conducts the test by following a comprehensive testing plan. Integration testing generally follows three common strategies - top-down approach, bottom-up approach or middle-out approach. The top-down approach to integration testing requires the highest-level modules be test and integrated first. The bottom-up approach tests and integrates the lowest-level units first. The Middle-out or umbrella approach performs testing along functional data and control-flow paths. First, the inputs for functions are integrated in the bottom-up pattern, and then the outputs for each function are integrated in the top-down manner.

In a system the functionality of a group of use case or a group of Modules/Processes will be considered as the unit for test case development in integration testing. Test cases for integration testing can be developed using the format referred in the section Test Case Format The following checklist can be applied as integration tests are planned and during the integration process itself. Has the software architecture been fully defined in the design document? Has the structure of global data been identified? Is the component-level design complete for all modules within the system? Has an integration schedule been established? Have drivers and stubs been defined and developed? Has an appropriate integration strategy been chosen based on the needs of the customer? If a top-down strategy has been chosen, are stubs available so that top-level modules can be adequately tested? Is regression testing performed as new modules are integrated? Are components integrated depths first so that appropriate functionality along one control path can be demonstrated? Are error-recording mechanisms in place? If a bottom-up strategy has been chosen, are drivers available so that bottom level module clusters can be adequately tested?

System Testing System testing specifically goes after behaviors and bugs that are properties of the entire system as distinct from properties attributable to components. System testing examines performance, throughput, security, recovery, resource loss transaction synchronization and etc. Test cases for system testing should cover these features. These are developed using the format referred in the section Test Case Format Acceptance Testing User acceptance testing tests usability of the system. Even end users or their representatives should be part of software project team, and requirements or product management team interacts with end users. Test cases for acceptance testing should cover usability features. These are developed using the format referred in the section Test Case Format. Test Case Format for Reference The test cases should be written in enough detail that they could be given to a new team member who would be able to quickly start to carry out the tests and find defects. Refer doc no. AST/QMS/FORMS/14/TCF for preparation of Test Cases. Software bugs are identified as critical in the operation point of view. These are categorized as A, B, C. These are defined as

Category A - All bugs in the test case pertaining to the main requirement Category B - All bugs in the test case pertaining to the derived (sub level) requirement. Category C - All bugs in the test case pertaining to the esthetics are fall into this category. Complexity - in the point of implementation can be categorized as High, Medium and Low. It is categorized in the perspective of an implementer / developer.
Unique-test-case-id Purpose <Test Case Title> <Short sentence or two about the aspect of the system is being tested. If this gets too long, break the test case up or put more information into the feature descriptions.> <Assumptions that must be met before the test case can be run. E.g., "logged in", "guest login allowed", "user test user exists". > <List of variables and their possible values used in the test case. You can list specific values or describe value ranges. The test case should be performed once for each combination of values. These values are written in set notation, one per line. E.g.: loginID = {Valid loginID, invalid loginID, valid email, invalid email, empty} password = {valid, invalid, empty}> <Steps to carry out the test. See step formatting rules below. Visit LoginPage Enter userID Enter password Click login See the terms of use page Click agree radio button at page bottom Click submit button See Personal Page Verify that welcome message is correct username > <Required output/result to be mentioned> <Specify the criticality either as A or B or C> <Specify the complexity either as High or Medium or Low> < indicate Pass/Fail>

Pre requisite Test Data

Steps

Expected Results Test Criticality Test Complexity

Entry Criteria Unit Testing Design is base lined Reviewed Unit test cases Planned Unit testing activities Integration Testing Design ids baselines Unit test defects are fixed Planned Integration test activities System Testing All Unit testing errors found during development are fixed Code review errors found during development are fixed Test cases are reviewed and approved prior to execution Test environment is installed and configured. Acceptance All the bugs found during system testing are fixed. Exit Criteria Unit Testing All Unit test cases are executed and passed. Ensure all the previously reported defects are also fixed Minimum criteria: All High and Medium severity defects are fixed. Integration Testing All Unit test cases are executed and passed. Ensure all the previously reported defects are also fixed Minimum criteria: All High and Medium severity defects are fixed System Testing All Unit test cases are executed and passed. For regression testing, ensure all the previously reported defects are also fixed Minimum criteria: All High and Medium severity defects are fixed Acceptance All the acceptance test cases are executed and defects are fixed (if any)