DEPARTMENT OF INFORMATION TECHNOLOGY

SUBJECT:SOFTWARE TESTING AND AUTOMATION

YEAR:III SEM:VI SEC:A&B

PART-A

1.How to Write a Test Plan in Software Testing

Test Plan is the most important task of Test Management Process. Follow the seven
steps below to create a test plan as per IEEE 829

1. Analyze the product

2. Design the Test Strategy
3. Define the Test Objectives
4. Define Test Criteria
5. Resource Planning
6. Plan Test Environment
7. Schedule & Estimation
8. Determine Test Deliverables
 2. list of the intergroup Responsibilities?

3.What are the phases of testing software?

In the software testing life cycle, there are usually five phases of testing:

 Static testing. During static testing, developers work to avoid potential problems that might
arise later. ...
 Unit testing. The next phase of software testing is unit testing. ...
 Integration testing. ...
 System testing. .
 Acceptance testing.

4.Define Resource Requirement

 Resource requirement is a detailed summary of all types of resources required to complete
project task. Resource could be human, equipment and materials needed to complete a
project.
 The resource requirement and planning is important factor of the test planning because helps
in determining the number of resources (employee, equipment…) to be used for the project.
Therefore, the Test Manager can make the correct schedule & estimation for the project.
PART-B

1.Explain briefly about Test Case?

Test Case

The test case is defined as a group of conditions under which a tester determines whether a
software application is working as per the customer's requirements or not. Test case
designing includes preconditions, case name, input conditions, and expected result. A test
case is a first level action and derived from test scenarios.

Test case gives detailed information about testing strategy, testing process, preconditions, and
expected output.

Why we write the test cases?

We will write the test for the following reasons:

o To require consistency in the test case execution

 o To make sure a better test coverage

o It depends on the process rather than on a person

o To avoid training for every new test engineer on the product

To require consistency in the test case execution: we will see the test case and start testing
the application.

To make sure a better test coverage: for this, we should cover all possible scenarios and
document it, so that we need not remember all the scenarios again and again.

It depends on the process rather than on a person: A test engineer has tested an
application during the first release, second release, and left the company at the time of third
release.. If the person is not there for the third release, it becomes difficult for the new person.
Hence all the derived values are documented so that it can be used in the future.

To avoid giving training for every new test engineer on the product: Those scenarios
should be documented so that the new test engineer can test with the given scenarios and also
can write the new scenarios.

Test case template

The primary purpose of writing a test case is to achieve the efficiency of the application.
Test case type

It can be functional, integration or system test cases or positive or negative or positive and
negative test cases.

Release

One release can contain many versions of the release.

Pre-condition

These are the necessary conditions that need to be satisfied by every test engineer before
starting the test execution process. Or it is the data configuration or the data setup that needs
to be created for the testing.
Test data

These are the values or the input we need to create as per the per-condition.

For example, Username, Password, and account number of the users.

Severity

The severity can be major, minor, and critical, the severity in the test case talks about the
importance of that particular test cases. All the text execution process always depends on the
severity of the test cases.

For example, we will take the Gmail application and let us see the severity based on the
modules:

Modules Severity

Login Critical

Help Minor

Compose mail Critical

Setting Minor

Inbox Critical

Sent items Major

Logout Critical

Example of a test case template

Here, we are writing a test case for the ICICI application’s Login module:
Types of test cases

We have a different kind of test cases, which are as follows:

o Function test cases

o Integration test cases

o System test cases

The functional test cases

Firstly, we check for which field we will write test cases and then describe accordingly.
Rules to write functional test cases:

o In the expected results column, try to use should be or must be.

o Highlight the Object names.

o We have to describe only those steps which we required the most; otherwise, we do
not need to define all the steps.
o To reduce the excess execution time, we will write steps correctly.

o Write a generic test case; do not try to hard code it.

Integration test case

In this, we should not write something which we already covered in the functional test cases,
and something we have written in the integration test case should not be written in the system
test case again.

Rules to write integration test cases

o Firstly, understand the product

o Identify the possible scenarios

o Write the test case based on the priority

System test cases

We will write the system test cases for the end-to-end business flows. And we have the entire
modules ready to write the system test cases.

The process to write test cases

The method of writing a test case can be completed into the following steps, which are as
below:
System study

In this, we will understand the application by looking at the requirements or the SRS, which
is given by the customer.
Identify all scenarios:

o I have documented all possible scenarios in a document, which is called test

design/high-level design.
o The test design is a record having all the possible scenarios.

Write test cases

Convert all the identified scenarios to test claims and group the scenarios related to their
features, prioritize the module, and write test cases by applying test case design techniques
and use the standard test case template, which means that the one which is decided for the
project.

Review the test cases

Review the test case by giving it to the head of the team and, after that, fix the review
feedback given by the reviewer.

Test case approval

After fixing the test case based on the feedback, send it again for the approval.

Store in the test case repository

After the approval of the particular test case, store in the familiar place that is known as the
test case repository.

2.What is Bug Reporting and also Explain about it?

Bug Reporting

The Bug is the informal name of defects, which means that software or application is not
working as per the requirement.

In software testing, a software bug can also be issue, error, fault, or failure. The bug occurred
when developers made any mistake or error while developing the product.
While testing the application or executing the test cases, the test engineer may not get the
expected result as per the requirement. And the bug had various names in different companies
such as error, issues, problem, fault, and mistake, etc.

Basic terminology of defect

Terms Description Raised by

Defect When the application is not working as per the Test Engineer
requirement.

Bug Informal name of defect Test Engineer

Error Problem in code leads to the errors. Developer, Automation Test

Engineer

Issue When the application is not meeting the business Customer

requirement.

Mistak Problem in the document is known as a mistake. --

e

Failure Lots of defect leads to failure of the software. --

Why defect/bug occur?

In software testing, the bug can occur for the following reasons:

o Wrong coding -Wrong coding means improper implementation.

o Missing coding - Here, missing coding means that the developer may not have
developed the code only for that particular feature.
o Extra coding - Here, extra coding means that the developers develop the extra
features, which are not required according to the client's requirements.
Bug tracking tool
o Jira -Jira is one of the most important bug tracking tools. Jira is an open-source tool
that is used for bug tracking, project management, and issue tracking in manual
testing.
o Bugzilla - It is also used as a test management tool because, in this, we can easily link
other test case management tools such as ALM, quality Centre, etc.
o Redmine - Redmine tool is written in Ruby programing language and also
compatible with multiple databases like MySQL, Microsoft SQL, and SQLite

o Mantis – Track Full-text search, Audit trails of changes, made to issues Revision
control system integration

o Backlog - The backlog is widely used to manage the IT projects and track the bugs. It
is mainly built for the development team for reporting the bugs with the complete
details of the issues, comments. Updates and change of status

Defect/Bug Report Template Fields With Examples And Explanations

Defect ID

If you use defect tracking software, the tool generates an ID automatically. However, if you
are using excel sheets or other forms of non-tool-based defect tracking, then you may have to
come up with a nomenclature for descriptive identifiers.

Example: bug_1

Defect Title
This is like the headline for your bug. A succinct, one-liner that highlights the problem.

Example: 404 on accessing the purchase order report page as a sales manager

Defect Description
In order for you to add all the information, you will have to test thoroughly and narrow down
the exact sequence of steps that are causing this issue.
Steps to Reproduce
This is a composite element of a bug report because it has 3 parts:

 Steps: As the name indicates, the steps to reproduce is a step-by-step listing of the
sequence of actions followed until the problem is encountered.
 Expected Results: The behavior of the system that was expected by the user.
 Actual Results: The actual behavior observed by the user.
Environment
Context plays a critical role in testing. The same application feature might behave differently
on a Windows 32-bit OS versus a Windows 64-bit OS. If the application is sensitive to OS,
browser, network, etc

Severity
1) High or 1: Causes crash or serious user/customer data loss. No workaround for the
problem.
#2) Medium or 2: Prevents users from the ability to perform the most commonly
used actions. Workaround exists.
#3) Low or 3: Cosmetic problems or minor issues that don’t pertain to the critical
features of the product

Sample Bug/Defect Template With Example