Software engineering Assignment 3

Question 1: Explain the working of software testing.

Ans : Software testing is defined as an activity to check whether the actual results match the
expected results and to ensure that the software system is defects free. It involves execution
of a software component or system component to evaluate one or more properties of interest.
Software testing also helps to identify errors, gaps or missing requirements in contrary to the
actual requirements. It can be either done manually or using automated tools.
Software Testing Types:
Manual Testing: Manual testing is the process of testing software by hand to learn more
about it, to find what is and isn’t working. This usually includes verifying all the features
specified in requirements documents, but often also includes the testers trying the software
with the perspective of their end user’s in mind.

Automation Testing: Automation testing is the process of testing the software using an
automation tool to find the defects. In this process, testers execute the test scripts and
generate the test results automatically by using automation tools. Some of the famous
automation testing tools for functional testing are QTP/UFT and Selenium.

Testing Approaches:
There are three types of software testing approaches.

1. White Box Testing

2. Black Box Testing
3. Grey Box Testing

White Box Testing: It is also called as Glass Box, Clear Box, Structural Testing. White Box
Testing is based on applications internal code structure. In white-box testing, an internal
perspective of the system, as well as programming skills, are used to design test cases. This
testing is usually done at the unit level.

Black Box Testing: It is also called as behavioral/ Specification-Based/Input-Output Testing.

Black Box Testing is a software testing method in which testers evaluate the functionality of
the software under test without looking at the internal code structure.

Grey Box Testing: Grey box is the combination of both White Box and Black Box
Testing. The tester who works on this type of testing needs to have access to design
documents. This helps to create better test cases in this process.

Testing Levels:

1. Unit Testing
2. Integration Testing
3. System Testing

1. Unit Testing: Unit Testing is done to check whether the individual modules of the
source code are working properly. i.e. testing each and every unit of the application
 separately by the developer in the developer’s environment. It is AKA Module
Testing or Component Testing

2. Integration Testing: Integration Testing is the process of testing the connectivity or

data transfer between a couple of unit tested modules. It is AKA I&T Testing or
String Testing. It is subdivided into Top-Down Approach, Bottom-Up Approach and
Sandwich Approach (Combination of Top Down and Bottom Up).

3. System Testing (end to end testing): It’s a black box testing. Testing the fully
integrated application this is also called as end to end scenario testing. To ensure that
the software works in all intended target systems. Verify thorough testing of every
input in the application to check for desired outputs. Testing of the users experiences
with the application.

Question 2: What do you understand by software reviews? Explain.

Ans : Software Review is systematic inspection of a software by one or more individuals

who work together to find and resolve errors and defects in the software during the early
stages of Software Development Life Cycle (SDLC). Software review is an essential part of
Software Development Life Cycle (SDLC) that helps software engineers in validating the
quality, functionality and other vital features and components of the software. It is a whole
process that includes testing the software product and it makes sure that it meets the
requirements stated by the client.
Usually performed manually, software review is used to verify various documents like
requirements, system designs, codes, test plans and test cases.
Objectives of Software Review:
The objective of software review is:

1. To improve the productivity of the development team.

2. To make the testing process time and cost effective.
3. To make the final software with fewer defects.
4. To eliminate the inadequacies.
Process of Software Review:

Types of Software Reviews:

There are mainly 3 types of software reviews:

1. Software Peer Review:

Peer review is the process of assessing the technical content and quality of the product
 and it is usually conducted by the author of the work product along with some other
developers.
Peer review is performed in order to examine or resolve the defects in the software,
whose quality is also checked by other members of the team.

Peer Review has following types:

 (i) Code Review:
Computer source code is examined in a systematic way.
 (ii) Pair Programming:
It is a code review where two developers develop code together at the same platform.
 (iii) Walkthrough:
Members of the development team is guided bu author and other interested parties
and the participants ask questions and make comments about defects.
 (iv) Technical Review:
A team of highly qualified individuals examines the software product for its client’s
use and identifies technical defects from specifications and standards.
 (v) Inspection:
In inspection the reviewers follow a well-defined process to find defects.

2. Software Management Review:

Software Management Review evaluates the work status. In this section decisions
regarding downstream activities are taken.

3. Software Audit Review:

Software Audit Review is a type of external review in which one or more critics, who are
not a part of the development team, organize an independent inspection of the software
product and its processes to assess their compliance with stated specifications and
standards. This is done by managerial level people.

Question 3: What are the difference between defect amplification and defect removal?

Ans : Defect amplification model is used to illustrate the generation and detection of
errors during the preliminary design, detail design, and coding steps of the software
engineering process.

 A box represents a software development step.

 During the step, errors may be inadvertently generated.
 Review may fail to uncover newly generated errors and errors from previous steps,
resulting in some number of errors that are passed through.
  In some cases, errors passed through from previous steps are amplified (amplification
factor, x) by current work.
 box subdivisions represent each of these characteristics and the percent of efficiency
for detecting errors, a function of the thoroughness of the review.

Question 4: Differentiate between automated testing and manual testing.

Parameter Automation Testing Manual Testing

Definition Automation Testing uses automation In manual testing, test cases are
tools to execute test cases. executed by a human tester and
software.
Processing Automated testing is significantly faster Manual testing is time-
time than a manual approach. consuming and takes up human
resources.
Reliability Manual testing is not as
Automated testing is a reliable method, accurate because of the
as it is performed by tools and scripts. possibility of the human errors.
There is no testing Fatigue.

Cost-effective Not cost effective for low volume Not cost effective for high
regression volume regression.
Human Automated testing does not involve The manual testing method
observation human consideration. So it can never allows human observation,
give assurance of user-friendliness and which may be useful to offer
positive customer experience. user-friendly system.
Performance Performance Tests like Load Testing, Performance Testing is not
Testing Stress Testing, Spike Testing, etc. have feasible manually
to be tested by an automation tool
compulsorily.
Programming Programming knowledge is a must in No need for programming in
knowledge automation testing. Manual Testing.
Ideal approach Automation testing is useful when Manual testing proves useful
frequently executing the same set of test when the test case only needs to
 cases run once or twice.
Framework Automation testing uses frameworks Manual Testing does not use
like Data Drive, Keyword, Hybrid to frameworks but may use
accelerate the automation process. guidelines, checklists, stringent
processes to draft certain test
cases.
Documentation Automated Tests acts as a document Manual Test cases provide no
provides training value especially for training value
automated unit test cases. A new
developer can look into a unit test cases
and understand the code base quickly.

When to Use? Automated Testing is suited for Manual Testing is suitable for
Regression Testing, Performance Exploratory, Usability and
Testing, Load Testing or highly Adhoc Testing. It should also be
repeatable functional test cases. used where the AUT changes
frequently.

Question 5: What are the possible test cases? Test any one software application of your
choice by the available online tool of your choice.

A test case is a document, which has a set of test data, preconditions, expected results and
postconditions, developed for a particular test scenario in order to verify compliance against
a specific requirement.
Test Case acts as the starting point for the test execution, and after applying a set of input
values, the application has a definitive outcome and leaves the system at some end point or
also known as execution postcondition.

Typical Test Case Parameters:

 Test Case ID
 Test Scenario
 Test Case Description
 Test Steps
 Prerequisite
 Test Data
 Expected Result
 Test Parameters
 Actual Result
 Environment Information
 Comments
Example:
Let us say that we need to check an input field that can accept maximum of 10 characters.
While developing the test cases for the above scenario, the test cases are documented the
following way. In the below example, the first case is a pass scenario while the second case
is a FAIL.

Scenario Test Step Expected Result Actual

Outcome

Verify that the Login to Application Application

input field that application and should be able to accepts all 10
can accept key in 10 accept all 10 characters.
maximum of 10 characters characters.
characters

Verify that the Login to Application Application

input field that application and should NOT accepts all 10
can accept key in 11 accept all 11 characters.
maximum of 11 characters characters.
characters

If the expected result doesn't match with the actual result, then we log a defect. The defect
goes through the defect life cycle and the testers address the same after fix.