What is a Test Case?

A Test Case is a set of actions performed to verify a particular feature of the Software Application. It contains Pre-conditions, Test Steps, Expected Results, Actual Results, Test Data etc. With the help of Test Cases, a Test Engineer can compare the Expected Results and Actual Results to determine whether a Software Application is working as per the Client’s requirements.

Difference between Test Scenarios and Test Cases

A Test Scenario is a one line statement, it covers a wide range of possibilities.

A Test Case is a set of steps performed to verify a particular functionality of the Software Application; it is very specific.

How to write Test Cases in Manual Testing

  • Understanding the actual requirement.
  • Gather the Test Data in order to execute the Test Case.
  • Identify the specific set of actions on the AUT.
  • Check the behaviour of the AUT for an expected result.
  • During Test Execution, a tester will check the expected results and actual results.
  • Assign a Pass/Fail status to the test case.
  • Pre-condition must be in place before Test Execution.
  • A test case may also have a Post-condition which specifies anything that applies after the Test Case completes.
The format of Standard Test Case

Test Cases Template

Standard Practices to write good Test Cases
  • Test Cases need to be simple and transparent.
  • Create a Test Cases keeping End User in mind.
  • Do not assume anything.
  • Make sure to do 100% Test Coverage.
  • Peer review.

What is a Test Plan

A Test Plan is a Software Testing document that provides the Objective, schedule, estimation, deliverables and resources required to perform testing for a Software Application. With the help of Test Plan document, we can determine the efforts needed to validate the quality of the Application Under Test.

As per ISTQB Definition, “A Test Plan is a document describing the scope, approach, resources and schedule of the intended testing activities.”

Importance of Test Plan
  • In a Test Plan document, important aspects like Test estimation, Test scope, Test strategy are documented so it can be reviewed by Management Team and re-used by other projects.
  • A Test Plan is like a road man of Software Testing, it is like a rule book which needs to be followed.

How to write a Test Plan

As per IEEE 829 Standard, we need to follow the below 8 steps to create a Test Plan –

  • Analyse the product
  • Design the Test Strategy
  • Define the Test Objectives
  • Define Test Criteria
  • Resource Planning
  • Plan Test Environment
  • Schedule & Estimation
  • Determine Test deliverables

Flow-chart of a Test Plan document

Step-1: Analyse the Product

In order to test the Software Product, first we need to have a through information about it. Therefore, we must learn the product completely before Testing it.

e.g. If there is a banking website say, abcbank.com, so first we need to research its clients and the end users to know their expectations from the banking application.

We need to look around the application website and also review the product documentation. Review of the product documentation helps us understand all the features of the website, also how to use it. In case, more clarity is required we can schedule a meeting with Customer, Product owner, Designer to get more information.

The objective here is, to get as much information about the product as possible.

Step-2: Develop Test Strategy

A Test Strategy document is a high-level document which is prepared by the Test Manager. This document defines –

  • The project’s testing objective and the means to achieve them
  • Determine testing efforts and costs.

We can develop the Test Strategy as follows –


2.1) Define scope of Testing

By defining scope of testing, we mean to identify the component of the system to be tested, they are defined as “In Scope”.

Also, the components of the system that will not be tested, need to be clearly defined as ‘Out of scope’.

To determine scope, you must –

  • Precise Customer Requirement
  • Project Budget
  • Product Specification
  • Skills & talent of the Testing Team

2.2) Identify testing type

A Testing Type is a standard test procedure that gives an expected test result.

The commonly used Testing Types are described as follows –

Unit Test: To test the smallest piece of the software code in the Application.

API Testing: To test the API’s created for the application.

Integration Test: Individual software modules are combined & tested as a group.

System Test: Testing the complete, integrated system to evaluate the system’s compliance with its specified requirements.

Agile Testing: Testing the system using Agile methodology.

  

2.3) Document Risks & Issues

Risk is future’s uncertain event with a probability of occurrence and a potential for loss. When the risk actually happens, it becomes the ‘issue’.


2.4) Create Test Logistics

Under Test Logistics, the following questions need to answered

  • Who will test?

To select the right member for the specified task, we have to consider if his/her skill is qualified for the task or not, also estimate the project budget.

  • When will test occur?

We will start Test when we have all the required items i.e. Test specifications, Requirement Document, Human Resources, Test Environment

Step-3: Define Test Objective

Test Objective is the overall goal of the Software Testing Process. Objective of the testing is finding as many software bugs as possible, ensure that the Software under test is bug free before release.

Test Objectives can be defined by 2 steps as follows –

  1. List all the software features (Functionality, Performance, GUI) which may need to test.
  2. Define the target based on above feature.
Step-4: Define Test Criteria

A Test Criteria is a standard or rule on which a Test Procedure can be based. There are 2 types of Test Criteria as follows –

     1. Suspension Criteria

Specify the critical suspension criteria for a test. If the Suspension Criteria is met during testing, the active test cycle will be suspended until the criteria is resolved.

    2. Exit Criteria 

This criterion specifies that denote a successful completion of a Test Phase. With this parameter, we decide on the completion of our testing for the application under test.

We can define the Exit Criteria with the help of ‘Run Rate’ & ‘Pass Rate’

Run Rate – (#Test Cases executed)/ (#Total Test Cases) *100

It should be 100% in order to confirm the Exit Criteria.

e.g. The Test Specification should have total 120 TCs, but the tester only executed 100 TCs, so the Run Rate = (100/120) *100=83%

Pass Rate – (#Test Cases passed)/(#Test Cases executed) * 100

It should be as high as possible to confirm the Exit Criteria.

e.g. In the above 100 TCs executed, there are 80 TC’s passed, so the pass rate is (80/100) *100 = 80%.

Step-5: Resource Planning 

A Resource Planning is a detailed summary of all types of resources required to complete Project task. A resource can be human, equipment and materials needed to complete a project.

Human Resource: Test Manager, Tester, Developer in Test, Test Administrator, SQA Members

System Resource: Server, Test Tool, Network, Computer

Step-6: Plan Test Environment

Test Environment: A testing environment is a setup of software and hardware on which the testing team is going to execute test cases. The test environment consists of real business and user environment, as well as physical environments, such as server, front end running environment.

How to setup the Test Environment:

To finish this task, we need a strong cooperation between Test Team and Development Team. We, as a Tester should ask the developer some questions to understand the web application under test clearly.

Step-7: Schedule & Estimation

In the Test Estimation phase, suppose you break out the whole project into small tasks and add the estimation for each task as follows –

Then you create the schedule to complete these tasks.

Making schedule is a common term in project management. By creating a solid schedule in the Test Planning, the Test Manager can use it as tool for monitoring the project progress, control the cost overruns.

Step-8: Test Deliverables

Test Deliverables are the list of all the documents, tools and other components that has to be developed and maintained in support of the testing effort.

There are different Test Deliverables at every phase of the SDLC-

  • Before Testing
  • During Testing
  • After the Testing

Test Deliverables Before Testing are as follows –

  • Test Plan Document
  • Test Cases Document
  • Test Design Specifications

Test Deliverables During Testing are as follows –

  • Test Scripts
  • Test Data
  • RTM
  • Error logs and Execution logs

Test Deliverables After the Testing cycle are as follows –

  • Test results/reports
  • Defect Report
  • Release Notes

A sample Test Plan document is as attached-

Test Plan Document

Difference between Test Plan vs Test Strategy 



Tags


You may also like

Leave a Reply

Your email address will not be published. Required fields are marked

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}