Ex:3: Basics of Software testing and Writing Test cases for the

given scenario.
Software Testing
Software testing is the process of verifying a system with the purpose of
identifying any errors, gaps or missing requirements versus the actual
requirement. Software testing is broadly categorised into two types -
functional testing and non-functional testing.
The process of software testing aims not only at finding faults in the existing
software but also finding measures to improve the software in terms of
efficiency, accuracy and usability.

➔ Software Testing Process

We can divide the activities within the fundamental test process into the
following basic steps:
➢ Planning and Control
○ Test planning involves producing a document that describes an
overall approach and test objectives. It involves reviewing the
test basis, identifying the test conditions based on analysis of
test items, writing test cases and Designing the test
environment.
➢ Analysis and Design
○ To review the test basis. The test basis is the information on
which test cases are based, such as requirements, design
specifications, product risk analysis, architecture and
interfaces
○ To identify test conditions
○ To design the tests
➢ Implementation and Execution
 ○ Test execution involves actually running the specified test on a
computer system either manually or by using an automated
test tool. It is a Fundamental Test Process in which actual
work is done.
➢ Evaluating exit criteria and Reporting
○ To assess if more test are needed or if the exit criteria specified
should be changed
○ To write a test summary report for stakeholders
➢ Test closure
○ To check which planned deliverables are actually delivered and
to ensure that all incident reports have been resolved
○ To finalize and archive testware such as scripts, test
environments, etc. for later reuse
○ To handover the testware to the maintenance organization.
They will give support to the software
Alpha, Beta and Acceptance Testing
➢ Acceptance testing is performed to determine whether or not the
software system has met the requirement specifications. The main
purpose of this test is to gauge whether the application meets the
intended specifications and satisfies the client’s requirements.
➢ Alpha Testing is a type of software testing performed to identify
bugs before releasing the product to real users or to the public. Unit
testing, integration testing and system testing when combined are
known as alpha testing.
➢ Beta Testing is performed by real users of the software
application in a real environment. In beta testing a sample of the
intended audience tests the application. Beta testing is also
known as pre-release testing.
➔ Static and Dynamic Testing
➢ Static Testing is a type of testing in which the code is not
executed. It can be done manually or by a set of tools. This type of
testing checks the code, requirement documents and design
documents and puts review comments on the work document.
➢ Dynamic testing is done when the code is in operation mode.
Dynamic testing is performed in a runtime environment. When the
code being executed is input with a value, the result or the output of
the code is checked and compared with the expected output.

➔ White box and Black box testing

White box testing is when we test the internal structure of a software
module: the code itself. White-box testing is also called glass testing or
open-box testing. It is usually performed by the team members who know
the code, usually developer. Since the developers have an in-depth
understanding of the project code, they are capable of making the changes in
the source code easily and in a small time.
Techniques included in white-box testing :
➢ Control Flow Testing
➢ Data Flow testing
➢ Statement coverage
 ➢ Path testing

Black box testing is a type of testing in which the tester only focuses on the
inputs and the expected outputs, without knowing how the application works
internally and how
 these inputs are processed. Tester treats the Application
Under Test (AUT) as a black box.
Techniques included in black-box testing :
➢ Regression Testing
➢ Functional Testing

Test Case Template

The Test case template contains the header section which has a set of
parameters that provides information about the test case such as the tester’s
name, test case description, prerequisite, etc. The body section contains the
actual test case content, such as test Id, test steps, test input, expected result, etc.
Here a test case template for login functionality has been created with its
parameters and values. 
Assume we need to write test cases for a scenario (Verify the login of the
Gmail account).

Here are some test cases.

Assume we need to write test cases for a scenario (Verify the login of the Gmail
account).
Here are some test cases.

1. Enter valid User Name and valid Password

2. Enter valid User Name and invalid Password
3. Enter invalid User Name and valid Password
4. Enter invalid User Name and invalid Password
 How To Write Test Cases in Manual Testing
Follow the below steps to write the test cases.

Step #1 – Test Case ID:

Each test case should be represented by a unique ID. It’s good practice to
follow some naming convention for better understanding and discrimination
purposes.

Step #2 – Test Case Description:

Pick test cases properly from the test scenarios

Example: Test scenario: Verify the login of Gmail

Test case: Enter a valid username and valid password

Step #3 – Pre-Conditions:
Conditions that need to meet before executing the test case. Mention if any
preconditions are available.

Example: Need a valid Gmail account to do login

Step #4 – Test Steps:

To execute test cases, you need to perform some actions. So write proper test
steps. Mention all the test steps in detail and in the order how it could be
executed from the end-user’s perspective.

Example: 

 Enter Username
 Enter Password
 Click Login button

Step #5 – Test Data:

You need proper test data to execute the test steps. So gather appropriate test
data. The data which could be used an input for the test cases.

Example:

 Username: [email protected]
 Password: STM

Step #6 – Expected Result:

The result which we expect once the test cases were executed. It might be
anything such as Home Page, Relevant screen, Error message, etc.,

Example: Successful login

Step #7 –  Post Condition:

Conditions that need to achieve when the test case was successfully executed.

Example: Gmail inbox is shown

Step #8 – Actual Result:

The result which system shows once the test case was executed. Capture the
result after the execution. Based on this result and the expected result, we set
the status of the test case.

Example: Redirected to Gmail inbox

Step #9 – Status:
Finally set the status as Pass or Fail based on the expected result against the
actual result. If the actual and expected results are the same, mention it as
Passed. Else make it as Failed. If a test fails, it has to go through the bug life
cycle to be fixed.

Example:

Result: Pass

Other important fields of a test case template:

Project Name: Name of the project the test cases belong to

Module Name: Name of the module the test cases belong to

Reference Document: Mention the path of the reference documents (if any

such as Requirement Document, Test Plan, Test Scenarios, etc.,)

Created By: Name of the Tester who created the test cases

Date of Creation: When the test cases were created

Reviewed By: Name of the Tester who created the test cases

Date of Review: When the test cases were reviewed

Executed By: Name of the Tester who executed the test case

Date of Execution: When the test case was executed

Comments: Include value information which helps the team