SOFTWARE TESTING

The IEEE definition of test case is “Documentation specifying inputs, predicted results, and a set of execution conditions for a test item.” The aim is to divide the software function into small units of function that is testable with input, and producing result that is measurable.

Designing good test cases is a complex art. The complexity comes from three sources: 

Test case is a set of conditions/steps under which a tester will decide whether an application, software system or one of its features is working correctly or not.

• Test cases help us discover information. Different types of tests are more effective for different classes of information.
• Test cases can be “good” in a variety of ways. No test case will be good in all of them.
• People tend to create test cases according to certain testing styles, such as domain testing or risk-based testing. Good domain tests are different from good risk-based tests.

Document Collection for Test Case Writing:

1) User Requirements Document

A document which list the business process, user profiles, user environment, interaction with other systems, replacement of existing systems, functional requirements, nonfunctional requirements, licensing and installation requirements, performance requirements, security requirements, usability and concurrent requirements etc.,

2) Business Use Case Document

A document which details the use case scenario of the functional requirements from the business perspective. This document covers the business actors (or system), goals, pre-conditions, post-conditions, basic flow, alternate flow, options, exceptions of each and every business flow of the system under requirements.

3) Functional Requirements Document

A document which details the functional requirements of each feature for the system under requirements. Normally, functional requirements document serves as a common repository for both development and testing team as well as to the project stakeholders including the customers for the committed (sometimes frozen) requirements, which should be treated as a most important document for any software development.

4) Software Project Plan (Optional)

A document which describes the details of the project, objectives, priorities, milestones, activities, organization structure, strategy, progress monitoring, risk analysis, assumptions, dependencies, constraints, training requirements, client responsibilities, project schedule etc.,

5) QA / Test Plan

A document which details the quality management system, documentation standards, change control mechanism, critical modules and functionalities, configuration management system, testing plans, defect tracking, acceptance criteria, The test plan document is used to identify the features to be tested, features not to be tested, testing team allocations and their interface, resource requirements, testing schedule, test case writing, test coverage, test deliverables, pre-requisite for test execution, bug reporting and tracking mechanism, test metrics etc.,