System Testing

System Testing includes testing of a fully integrated software system. Generally, a computer system is
made with the integration of software (any software is only a single element of a computer system).
The software is developed in units and then interfaced with other software and hardware to create a
complete computer system. In other words, a computer system consists of a group of software to
perform the various tasks, but only software cannot perform the task; for that software must be
interfaced with compatible hardware. System testing is a series of different type of tests with the
purpose to exercise and examine the full working of an integrated software computer system against
requirements.

There is four levels of software testing: unit testing, integration testing, system testing and
acceptance testing, all are used for the testing purpose. Unit Testing used to test a single software;
Integration Testing used to test a group of units of software, System Testing used to test a whole
system and Acceptance Testing used to test the acceptability of business requirements. Here we are
discussing system testing which is the third level of testing levels.

Hierarchy of Testing Levels

There are mainly two widely used methods for software testing, one is White box testing which uses
internal coding to design test cases and another is black box testing which uses GUI or user
perspective to develop test cases.

o White box testing

o Black box testing

System testing falls under Black box testing as it includes testing of the external working of the
software. Testing follows user's perspective to identify minor defects.

System Testing includes the following steps.

o Verification of input functions of the application to test whether it is producing the expected
output or not.
o Testing of integrated software by including external peripherals to check the interaction of
various components with each other.
o Testing of the whole system for End to End testing.
o Behavior testing of the application via auser's experience

Types of System Testing

System testing is divided into more than 50 types, but software testing companies typically uses some
of them. These are listed below:
Regression Testing
Regression testing is performed under system testing to confirm and identify that if there's any defect
in the system due to modification in any other part of the system. It makes sure, any changes done
during the development process have not introduced a new defect and also gives assurance; old
defects will not exist on the addition of new software over the time.

Load Testing
Load testing is performed under system testing to clarify whether the system can work under real-
time loads or not.

Functional Testing
Functional testing of a system is performed to find if there's any missing function in the system.
Tester makes a list of vital functions that should be in the system and can be added during functional
testing and should improve quality of the system.
Recovery Testing
Recovery testing of a system is performed under system testing to confirm reliability, trustworthiness,
accountability of the system and all are lying on recouping skills of the system. It should be able to
recover from all the possible system crashes successfully.

Migration Testing
Migration testing is performed to ensure that if the system needs to be modified in new infrastructure
so it should be modified without any issue.

Usability Testing
The purpose of this testing to make sure that the system is well familiar with the user and it meets its
objective for what it supposed to do.

Software and Hardware Testing

This testing of the system intends to check hardware and software compatibility. The hardware
configuration must be compatible with the software to run it without any issue. Compatibility provides
flexibility by providing interactions between hardware and software.

Why is System Testing Important?

o System Testing gives hundred percent assurance of system performance as it covers end to
end function of the system.
o It includes testing of System software architecture and business requirements.
o It helps in mitigating live issues and bugs even after production.
o System testing uses both existing system and a new system to feed same data in both and
then compare the differences in functionalities of added and existing functions so, the user can
understand benefits of new added functions of the system.

o Software Testing Introduction

o
o Software testing is a process of identifying the correctness of a software by considering its all
attributes (Reliability, Scalability, Portability, Re-usability, Usability) and evaluating the
execution of software components to find the software bugs or errors or defects.
o Software testing provides an independent view and objective of the software and gives surety
of fitness of the software. It involves testing of all components under the required services to
confirm that whether it is satisfying the specified requirements or not. The process is also
providing the client with information about the quality of the software.
 o Testing is mandatory because it will be a dangerous situation if the software fails any of time
due to lack of testing. So, without testing software cannot be deployed to the end user.
o
o Overview
o Testing is a group of techniques to determine the correctness of the application under the
predefined script but, testing cannot find all the defect of application. The main intent of
testing is to detect failures of the application so that failures can be discovered and corrected.
It does not demonstrate that a product functions properly under all conditions but only that it
is not working in some specific conditions.
o Testing furnishes comparison that compares the behavior and state of software against
mechanisms because the problem can be recognized by the mechanism. The mechanism may
include past versions of the same specified product, comparable products, and interfaces of
expected purpose, relevant standards, or other criteria but not limited up to these.
o Testing includes an examination of code and also the execution of code in various
environments, conditions as well as all the examining aspects of the code. In the current
scenario of software development, a testing team may be separate from the development
team so that Information derived from testing can be used to correct the process of software
development.
o The success of software depends upon acceptance of its targeted audience, easy graphical
user interface, strong functionality load test, etc. For example, the audience of banking is
totally different from the audience of a video game. Therefore, when an organization develops
a software product, it can assess whether the software product will be beneficial to its
purchasers and other audience.

Software Development Life Cycle (SDLC)

SDLC is a process that creates a structure of development of software. There are different phases
within SDLC, and each phase has its own different activity. It makes development team able to
design, create and deliver a high-quality product.

SDLC describes various phases of software development and the order of execution of phases. Each
phase requires deliverable from the previous phase in a life cycle of software development.
Requirements are translated into design, design into development and development into testing, after
testing it is given to the client.

Let's see all phases in detail.>

Different phases of the software development cycle

o Requirement Phase
o Design Phase
o Build /Development Phase
o Testing Phase
o Deployment/ Deliver Phase
o Maintenance
1. Requirement Phase
This is the most crucial phase of software development life cycle for the developing team as well as for
the project manager. During this phase, the client states requirements, specifications, expectations
and any other special requirement related to the product or software. All these are gathered by the
business manager or project manager or analyst of the service providing company.

Requirement includes how the product will be used and who will use the product to determine the load
of operations. All information gathered from this phase is critical to developing the product as per the
customer requirements.

2. Design Phase
Design phase includes a detailed analysis of new software according to the requirement phase. This is
the high priority phase in the development life cycle of a system because the logical designing of the
system is converted into physical designing. The output of requirement phase is a collection of things
that are required and design phase gives the way to accomplish these requirements. The decision of
all required essential tools such as programming
language like Java, .NET, PHP; database like Oracle, MySQL, a combination of hardware and
software to provide a platform on which software can run without any problem is taken in this phase.

There are several techniques and tools such as data flow diagrams, flowcharts, decision tables and
decision trees, Data dictionary, and the structured dictionary are used for describing the system
design.

3. Build /Development Phase

After the successful completion of requirement and design phase, the next step is to implement the
design into the development of a software system. In this phase, work is divided into small units, and
coding starts by the team of developers according to the design discussed in the previous phase and
according to the requirements of client discussed in requirement phase to produce the desired result.

Front-end developers develop easy and attractive GUI and necessary interfaces to interact with back-
end operations and back-end developers do back-end coding according to the required operations. All
is done according to the procedure and guidelines demonstrated by the project manager.

Since, this is the coding phase it takes the longest time and more focused approach for the developer
in the software development life cycle.

4. Testing Phase
Testing is the last step of completing software system. In this phase, after getting the developed GUI
and back-end combination, it is tested against the requirements stated in the requirement phase.
Testing determines whether the software is actually giving the result as per the requirements
addressed in the requirement phase or not. Development team makes a test plan to start the test.
This test plan includes all types of essential testing such as integration testing, unit testing,
acceptance testing, and system testing. Non-functional testing is also done in this phase.

If there are any defects in the software, or it is not working as per expectations, then testing team
gives information to the development team in detail about the issue. If it is a valid defect or worth to
sort out, it will be fixed and development team replaces it with the new one and it also needs to be
verified.

5. Deployment/ Deliver Phase

When software testing is completed with satisfying result and there are no remaining issues in the
working of software, it is delivered to the customer for their use.

As soon as customers receive the product, they are recommended first to do the beta testing. In beta
testing, customer can require any changes which are not present in the software but mentioned in the
requirement document or any other GUI changes to make it more user-friendly. Besides this, if any
type of defect is encountered while a customer using the software; it will be informed to the
development team of that particular software to sort out the problem. If it is a severe issue, then the
development team solves it in a short time otherwise, if it is less severe, then it will wait for the next
version.

After the solution of all type of bugs and changes, software finally deployed to the end user.

6. Maintenance
The maintenance phase is the last and long-lasting phase of SDLC because it is the process which
continues till the software's life cycle comes to an end. When a customer starts using software, then
actual problems start to occur, and at that time there's a need to solve these problems. This phase
also includes making changes in hardware and software to maintain its operational effectiveness like
to improve its performance, enhance security features and according to customer's requirements with
upcoming time. This process to take care of product time to time is called maintenance.

"So, all these are six phases of software development life cycle (SDLC) under which the process of
development of software takes place. All are compulsory phases without any one of the development
cannot be possible because development continues for the lifetime of software with maintenance
phase".

Error, Fault, Failure

What is the difference between error, fault and failure in software testing?
Error – a human action that produces an incorrect result. This is also sometimes referred to
as Mistake.

Fault – a manifestation of an error in software, also known as Defect or Bug.

Failure – a deviation of the software from its expected delivery or service.

An error is something that a human does, we all make mistakes and when we do whilst
developing software, it is known as an error. The result of an error being made is a fault. It is
something that is wrong in the software (source code or documentation – specifications,
manuals, etc.). Faults are also known as defects or bugs.

When a system or piece of software produces an incorrect result or does not perform the
correct action, this is known as a failure. Failures are caused by faults in the software. Note that
software system can contain faults but still never fail (this can occur if the faults are in those
parts of the system that are never used). In other words, failure is the manifestation of one or
more faults (bugs).

Reliability

Another term that should be understood is reliability. A system is said to be reliable when it
performs correctly for long periods of time. However, the same system used by two different
people may appear reliable to one but not to the other. This is because the different people use
the system in different ways.

Reliability: the probability that the software will not cause the failure of the system for a
specified time under specified conditions.

The definition of reliability therefore includes the phrase ‘under specified conditions’. When
reporting on the reliability of a system it is important to explain under what conditions the
system will achieve the specified level of reliability. For example, a system may achieve a
reliability of no more than one failure per month providing no more than 10 people use the
system simultaneously.

Incident

While executing a test, you might observe that the actual results vary
from expected results. When the actual result is different from the
expected result then it is called as incidents, bugs, defects, problems or
issues.
  To be specific, we sometimes make difference between incidents
and the defects or bugs. An incident is basically any situation where
the system exhibits questionable behavior, but often we refer to an
incident as a defect only when the root cause is some problem in
the item we are testing.
 Other causes of incidents include misconfiguration or failure of the
test environment, corrupted test data, bad tests, invalid expected
results and tester mistakes.

Test Case

What is Test case?

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 input Login to Application should Application

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

Verify that the input Login to Application should Application

field that can accept application and NOT accept all 11 accepts all 10
maximum of 11 key in 11 characters. 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.

What is a Test Plan?

Test planning, the most important activity to ensure that there is initially a list of tasks and milestones in a
baseline plan to track the progress of the project. It also defines the size of the test effort.
It is the main document often called as master test plan or a project test plan and usually developed during the
early phase of the project.

Test Plan Identifiers:

S.No. Parameter Description

1. Test plan identifier Unique identifying reference.

2. Introduction A brief introduction about the project and to the

document.

3. Test items A test item is a software item that is the application

under test.

4. Features to be A feature that needs to tested on the testware.

tested
5. Features not to be Identify the features and the reasons for not including as
tested part of testing.

6. Approach Details about the overall approach to testing.

7. Item pass/fail Documented whether a software item has passed or

criteria failed its test.

8. Test deliverables The deliverables that are delivered as part of the testing
process,such as test plans, test specifications and test
summary reports.

9. Testing tasks All tasks for planning and executing the testing.

10. Environmental Defining the environmental requirements such as

needs hardware, software, OS, network configurations, tools
required.

11. Responsibilities Lists the roles and responsibilities of the team members.

12. Staffing and Captures the actual staffing requirements and any
training needs specific skills and training requirements.

13. Schedule States the important project delivery dates and key
milestones.

14. Risks and High-level project risks and assumptions and a

Mitigation mitigating plan for each identified risk.

15. Approvals Captures all approvers of the document, their titles and
the sign off date.

Test Planning Activities:

 To determine the scope and the risks that need to be tested and that are NOT to be tested.

 Documenting Test Strategy.

  Making sure that the testing activities have been included.

 Deciding Entry and Exit criteria.

 Evaluating the test estimate.

 Planning when and how to test and deciding how the test results will be evaluated, and defining test
exit criterion.

 The Test artefacts delivered as part of test execution.

 Defining the management information, including the metrics required and defect resolution and risk
issues.

 Ensuring that the test documentation generates repeatable test assets.

Software Testing Overview

Software Testing is evaluation of the software against requirements gathered from users and system
specifications. Testing is conducted at the phase level in software development life cycle or at module level in
program code. Software testing comprises of Validation and Verification.

Software Validation
Validation is process of examining whether or not the software satisfies the user requirements. It is carried out
at the end of the SDLC. If the software matches requirements for which it was made, it is validated.

 Validation ensures the product under development is as per the user requirements.
 Validation answers the question – "Are we developing the product which attempts all that user needs
from this software ?".
 Validation emphasizes on user requirements.

Software Verification
Verification is the process of confirming if the software is meeting the business requirements, and is
developed adhering to the proper specifications and methodologies.

 Verification ensures the product being developed is according to design specifications.

 Verification answers the question– "Are we developing this product by firmly following all design
specifications ?"
 Verifications concentrates on the design and system specifications.
Target of the test are -

 Errors - These are actual coding mistakes made by developers. In addition, there is a difference in
output of software and desired output, is considered as an error.

 Fault - When error exists fault occurs. A fault, also known as a bug, is a result of an error which can
cause system to fail.

 Failure - failure is said to be the inability of the system to perform the desired task. Failure occurs
when fault exists in the system.

Manual Vs Automated Testing

Testing can either be done manually or using an automated testing tool:

 Manual - This testing is performed without taking help of automated testing tools. The software tester
prepares test cases for different sections and levels of the code, executes the tests and reports the
result to the manager.
Manual testing is time and resource consuming. The tester needs to confirm whether or not right test
cases are used. Major portion of testing involves manual testing.

 Automated This testing is a testing procedure done with aid of automated testing tools. The
limitations with manual testing can be overcome using automated test tools.
A test needs to check if a webpage can be opened in Internet Explorer. This can be easily done with manual
testing. But to check if the web-server can take the load of 1 million users, it is quite impossible to test
manually.
There are software and hardware tools which helps tester in conducting load testing, stress testing, regression
testing.

Testing Approaches
Tests can be conducted based on two approaches –

 Functionality testing
 Implementation testing
When functionality is being tested without taking the actual implementation in concern it is known as black-box
testing. The other side is known as white-box testing where not only functionality is tested but the way it is
implemented is also analyzed.
Exhaustive tests are the best-desired method for a perfect testing. Every single possible value in the range of
the input and output values is tested. It is not possible to test each and every value in real world scenario if the
range of values is large.

Black-box testing
It is carried out to test functionality of the program. It is also called ‘Behavioral’ testing. The tester in this case,
has a set of input values and respective desired results. On providing input, if the output matches with the
desired results, the program is tested ‘ok’, and problematic otherwise.

In this testing method, the design and structure of the code are not known to the tester, and testing engineers
and end users conduct this test on the software.
Black-box testing techniques:

 Equivalence class - The input is divided into similar classes. If one element of a class passes the
test, it is assumed that all the class is passed.

 Boundary values - The input is divided into higher and lower end values. If these values pass the
test, it is assumed that all values in between may pass too.
  Cause-effect graphing - In both previous methods, only one input value at a time is tested. Cause
(input) – Effect (output) is a testing technique where combinations of input values are tested in a
systematic way.

 Pair-wise Testing - The behavior of software depends on multiple parameters. In pairwise testing, the
multiple parameters are tested pair-wise for their different values.

 State-based testing - The system changes state on provision of input. These systems are tested
based on their states and input.

White-box testing
It is conducted to test program and its implementation, in order to improve code efficiency or structure. It is
also known as ‘Structural’ testing.

In this testing method, the design and structure of the code are known to the tester. Programmers of the code
conduct this test on the code.
The below are some White-box testing techniques:

 Control-flow testing - The purpose of the control-flow testing to set up test cases which covers all
statements and branch conditions. The branch conditions are tested for both being true and false, so
that all statements can be covered.

 Data-flow testing - This testing technique emphasis to cover all the data variables included in the
program. It tests where the variables were declared and defined and where they were used or
changed.

Testing Levels
Testing itself may be defined at various levels of SDLC. The testing process runs parallel to software
development. Before jumping on the next stage, a stage is tested, validated and verified.
Testing separately is done just to make sure that there are no hidden bugs or issues left in the software.
Software is tested on various levels -

Unit Testing
While coding, the programmer performs some tests on that unit of program to know if it is error free. Testing is
performed under white-box testing approach. Unit testing helps developers decide that individual units of the
program are working as per requirement and are error free.

Integration Testing
Even if the units of software are working fine individually, there is a need to find out if the units if integrated
together would also work without errors. For example, argument passing and data updation etc.
System Testing
The software is compiled as product and then it is tested as a whole. This can be accomplished using one or
more of the following tests:

 Functionality testing - Tests all functionalities of the software against the requirement.

 Performance testing - This test proves how efficient the software is. It tests the effectiveness and
average time taken by the software to do desired task. Performance testing is done by means of load
testing and stress testing where the software is put under high user and data load under various
environment conditions.

 Security & Portability - These tests are done when the software is meant to work on various
platforms and accessed by number of persons.

Acceptance Testing
When the software is ready to hand over to the customer it has to go through last phase of testing where it is
tested for user-interaction and response. This is important because even if the software matches all user
requirements and if user does not like the way it appears or works, it may be rejected.

 Alpha testing - The team of developer themselves perform alpha testing by using the system as if it
is being used in work environment. They try to find out how user would react to some action in
software and how the system should respond to inputs.

 Beta testing - After the software is tested internally, it is handed over to the users to use it under their
production environment only for testing purpose. This is not as yet the delivered product. Developers
expect that users at this stage will bring minute problems, which were skipped to attend.

Regression Testing
Whenever a software product is updated with new code, feature or functionality, it is tested thoroughly to
detect if there is any negative impact of the added code. This is known as regression testing.

Testing Documentation
Testing documents are prepared at different stages -

Before Testing
Testing starts with test cases generation. Following documents are needed for reference –

 SRS document - Functional Requirements document

 Test Policy document - This describes how far testing should take place before releasing the
product.

 Test Strategy document - This mentions detail aspects of test team, responsibility matrix and
rights/responsibility of test manager and test engineer.

 Traceability Matrix document - This is SDLC document, which is related to requirement gathering
process. As new requirements come, they are added to this matrix. These matrices help testers know
the source of requirement. They can be traced forward and backward.

While Being Tested

The following documents may be required while testing is started and is being done:
  Test Case document - This document contains list of tests required to be conducted. It includes Unit
test plan, Integration test plan, System test plan and Acceptance test plan.

 Test description - This document is a detailed description of all test cases and procedures to execute
them.

 Test case report - This document contains test case report as a result of the test.

 Test logs - This document contains test logs for every test case report.

After Testing
The following documents may be generated after testing :

 Test summary - This test summary is collective analysis of all test reports and logs. It summarizes
and concludes if the software is ready to be launched. The software is released under version control
system if it is ready to launch.

Testing vs. Quality Control, Quality Assurance and Audit

We need to understand that software testing is different from software quality assurance, software quality
control and software auditing.

 Software quality assurance - These are software development process monitoring means, by which
it is assured that all the measures are taken as per the standards of organization. This monitoring is
done to make sure that proper software development methods were followed.

 Software quality control - This is a system to maintain the quality of software product. It may include
functional and non-functional aspects of software product, which enhance the goodwill of the
organization. This system makes sure that the customer is receiving quality product for their
requirement and the product certified as ‘fit for use’.

 Software audit - This is a review of procedure used by the organization to develop the software. A
team of auditors, independent of development team examines the software process, procedure,
requirements and other aspects of SDLC. The purpose of software audit is to check that software and
its development process, both conform standards, rules and regulations.

 Agile Testing

 Questions

 Quizzes
Home » SDLC » Incremental Model

Incremental Model
Updated: December 2, 2018 - Amir Ghahrai

What is the Incremental Model?

 incremental-
model
The incremental build model is a method of software development where the model is
designed, implemented and tested incrementally (a little more is added each time) until the
product is finished. It involves both development and maintenance. The product is defined as
finished when it satisfies all of its requirements. This model combines the elements of the
waterfall model with the iterative philosophy of prototyping.

The product is decomposed into a number of components, each of which are designed and built
separately (termed as builds). Each component is delivered to the client when it is complete. This
allows partial utilisation of product and avoids a long development time. It also creates a large
initial capital outlay with the subsequent long wait avoided. This model of development also
helps ease the traumatic effect of introducing completely new system all at once.

There are some problems with this model. One is that each new build must be integrated with
previous builds and any existing systems. The task of decomposing product into builds not
trivial either. If there are too few few builds and each build degenerates this turns into Build-
And-Fix model. However if there are too many builds then there is little added utility from each
build.
What is the difference between Incremental Model and Iterative
Model?
The Incremental Approach uses a set number of steps and development goes from start to
finish in a linear path of progression.

Incremental development is done in steps from design, implementation, testing/verification,

maintenance. These can be broken down further into sub-steps but most incremental models
follow that same pattern. The Waterfall Model is a traditional incremental development
approach.

The Iterative Approach has no set number of steps, rather development is done in cycles.

Iterative development is less concerned with tracking the progress of individual features.
Instead, focus is put on creating a working prototype first and adding features in development
cycles where the Increment Development steps are done for every cycle. Agile Modeling is a
typical iterative approach.

Advantages of Incremental Model

 Generates working software quickly and early during the software life cycle.
 More flexible – less costly to change scope and requirements.
 Easier to test and debug during a smaller iteration.
 Easier to manage risk because risky pieces are identified and handled during its iteration.
 Each iteration is an easily managed milestone.

Disadvantages of Incremental Model

 Each phase of an iteration is rigid and do not overlap each other.
 Problems may arise pertaining to system architecture because not all requirements are
gathered up front for the entire software life cycle.

When to use Incremental Model

 Such models are used where requirements are clear and can implement by phase wise.
From the figure it’s clear that the requirements ® is divided into R1, R2……….Rn and
delivered accordingly.
 Mostly such model is used in web applications and product based companies.
What is a Test Plan?
A test plan is a detailed document that outlines the test strategy, Testing objectives,
resources (manpower, software, hardware) required for testing, test schedule, Test
Estimation and test deliverables.

The test plan serves as a blueprint to conduct software testing activities as a defined
process which is minutely monitored and controlled by the test manager.

Let’s start with following scenario

In a meeting, you want to discuss the Test Plan with the team members, but they
are not interested - .

In such case, what will you do? Select your answer as following figure
 A) I am Manager do everything as I said

B) OK, let's me explain why we need a Test Plan

Importance of Test Plan

Making Test Plan has multiple benefits

 Test Plan helps us determine the effort needed to validate the quality of the
application under test
 Help people outside the test team such as developers, business managers,
customers understand the details of testing.
 Test Plan guides our thinking. It is like a rule book, which needs to be
followed.
 Important aspects like test estimation, test scope, Test
Strategy are documented in Test Plan, so it can be reviewed by
Management Team and re-used for other projects.

How to write a Test Plan

You already know that making a 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

Step 1) Analyze the product

How can you test a product without any information about it? The answer
is Impossible. You must learn a product thoroughly before testing it.
The product under test is Guru99 banking website. You should research clients and
the end users to know their needs and expectations from the application

 Who will use the website?

 What is it used for?
 How will it work?
 What are software/ hardware the product uses?

You can use the following approach to analyze the site

Now let’s apply above knowledge to a real product: Analyze the banking
website http://demo.guru99.com/V4.
You should take a look around this website and also review product
documentation. Review of product documentation helps you to understand all the
features of the website as well as how to use it. If you are unclear on any items, you
might interview customer, developer, designer to get more information.

Step 2) Develop Test Strategy

Test Strategy is a critical step in making a Test Plan. A Test Strategy document, is
a high-level document, which is usually developed by Test Manager. This document
defines:

 The project’s testing objectives and the means to achieve them

 Determines testing effort and costs

Back to your project, you need to develop Test Strategy for testing that banking
website. You should follow steps below

Step 2.1) Define Scope of Testing

Before the start of any test activity, scope of the testing should be known. You must
think hard about it.

 The components of the system to be tested (hardware, software, middleware,

etc.) are defined as "in scope"
 The components of the system that will not be tested also need to be clearly
defined as being "out of scope."

Defining the scope of your testing project is very important for all stakeholders. A
precise scope helps you

 Give everyone a confidence & accurate information of the testing you are
doing
 All project members will have a clear understanding about what is tested and
what is not

How do you determine scope your project?

To determine scope, you must –

 Precise customer requirement

 Project Budget
 Product Specification
 Skills & talent of your test team

Now should clearly define the "in scope" and "out of scope" of the testing.

 As the software requirement specs, the project Guru99 Bank only focus on
testing all the functions and external interface of website Guru99 Bank (in
scope testing)
 Nonfunctional testing such as stress, performance or logical
database currently will not be tested. (out of scope)

Problem Scenario

The customer wants you to test his API. But the project budget does not permit to do
so. In such a case what will you do?

Well, in such case you need to convince the customer that Api Testing is extra work
and will consume significant resources. Give him data supporting your facts. Tell him
if Api Testing is included in-scope the budget will increase by XYZ amount.

The customer agrees and accordingly the new scopes, out of scope items are

 In-scope items: Functional Testing, Api Testing

  Out of scope items: Database Testing, hardware & any other external
interfaces

Step 2.2) Identify Testing Type

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

Each testing type is formulated to identify a specific type of product bugs. But, all
Testing Types are aimed at achieving one common goal “Early detection of all the
defects before releasing the product to the customer”

The commonly used testing types are described as following figure

There are tons of Testing Types for testing software product. Your team cannot
have enough efforts to handle all kind of testing. As Test Manager, you must
set priority of the Testing Types

 Which Testing Types should be focused for web application testing?

 Which Testing Types should be ignored for saving cost?

Software Testing Limitations

August 16, 2018

Whenever we talk about technologies and some processes, every process has
set of limitations or drawbacks. Even in the software development, different
approaches limits themselves to some extent. Software testing which is an
inherited part of the whole software development process also possess some
limitations. Read and explore areas and aspects, where software testing lacks
to deliver the results.

1. We use testing to disclose many hidden errors but this methodology never
guarantees the absence of errors. It is only used to identify the known
errors. It never gives any information about those defects which remain
uncovered.

2. Testing do not provide you any help when you have to make a decision
either “you should release the product consisting errors for meeting the
deadline” or “you should release late by compromising the deadline”.

3. Software testing does not predicts or estimate the proper functioning of

the product under different conditions, but it may prove to be helpful in
 delivering the information w.r.t. Incorrect or improper functioning of the
product.

4. While injecting the defects, software testing unable to find the root causes
which may help in placing defects at the first place. Identifying the root
causes of defects/errors helps in injection of defects for future purposes.

5. Testing cannot be done against system requirements. We also cannot

detect any errors in requirements or ambiguous requirement leads the
complete testing process to inadequate testing.

6. When it comes to major constraints like Time & Budget, it requires

attentive planning of test effort. Mostly, we compromise in between
thoroughness and budget at the time of testing.

Manual Testing Limitations:

GUI object size difference and color combination are the two essential
measures which are very difficult to find by using manual testing. Manual
testing process is not suitable for large scale projects and limited time
projects. Comparing huge amount of data will be unrealistic in terms of
manual testing.

1. It requires more time and resources to accomplish quality goal. Many

times, it requires both.

2. When it comes to performance testing, it seems to be very impractical

in terms of manual testing.

3. With manual testing, it possess least accuracy.

 4. Executing recursive tests again and again take too much amount of time
which lead to project delay and incomplete testing.

5. GUI object size difference and color combination are the two essential
measures which are very difficult to find by using manual testing.

6. Manual testing process is not suitable for large scale projects and limited
time projects.

7. Comparing huge amount of data will be unrealistic in terms of manual

testing.

8. At the time of software maintenance, processing of change requests takes

huge amount of time.

Testing Tools Limitations:

1. Unrealistic expectation from tools.

2. Many times, testers make mistakes by underestimating factors like time,

cost, and effort for initial introduction of tool.

3. Testers repeated the miscalculation of time and effort required to achieve

prominent amount of benefit from tool.

4. Testers underestimate the effort required to maintain the test assets

which are generated by tool.

5. Testing teams are too much dependent on tools.