What is Software Testing Methodologies?

In the field of Software testing we use different types of Software Testing

Methodologies. In today’s Software Testing Class, we will see what all Software Testing
Methodologies & software testing technique is used in the day today software testing life
cycle.

In the Software Development Process different software development approaches are used.
A software development process also known as a Software Development Life Cycle (SDLC).

Each process model has its own advantages & disadvantages, the choosing of model is
based on the requirement & need of your project to do the success in process of software
development.
Here are the few commonly used Software Development Life Cycle used in actual
testing:

 Waterfall model
 V model
 Agile model
 Spiral model
 RUP
 RAD

1) Waterfall Model

The Waterfall Model approach is most basic life cycle model, which is the first Process Model
begins and used broadly in Software Development to make sure project success. This model
is developed by Winston Royce in the early 1970. Waterfall model is software development
process sequential process, as flowing progressively downwards like waterfall via multiple
phases & these simple sequence of phases has its own defines activities and goals. The
Waterfall model is divided into following separate phases:

 Requirement Gathering & Analysis phase,

 Software Design,
 Implementation and Testing
 Maintenance

All these phases are the sequential phases & next step is totally depends on the previous
step, so that second phase is begins as only if the defined set of objectives and goals are
completed first.

The stages of “The Waterfall Model” are:

Requirement Gathering & Analysis:
This is the starting phase of the SDLC in which all possible system requirements are
captured & analyzed. Software requirements specification includes the complete information
about how actual end users are expecting from the system. This document covers all the
necessary requirements for the development of project. Finally after completion of
requirement gathering & analysis (validation of requirement against the user needs), a
Requirement Specification document is created which give out as a input to the next phase
of SDLC. In this model once we moved to the next phase then it won’t possible to add or
update the requirements.

System & Software Design: Prior to start actual coding, it is mandatory to be aware of
what all features we are going to implement & how it would look like? The requirement
specifications document created in the first phase is used as the input to this phase & based
on this the system design specifications would be prepared. In which all hardware & system
requirements would be specified. The system design specifications document prepared in
this phase is used as input for the Implementation & Testing phase model.

Implementation & Unit Testing: Upon getting the system design specifications document
the actual coding would be started. Before starting the actual coding requirements are
divided into the models/units. In the actual coding the initially develop the small programs
called units. After implementing all units the integration would be started in the next phase.
The developed unit’s model functionality is tested separately in this phase to check whether
the unit models are meets the specified requirements & this individual model testing is
called as Unit Testing.

Integration & System Testing: In the previous model the system requirements are
divided into models & each model is developed & tested separately. In this phase all units
are integrated & done the system testing to check whether the all models/units are
integrated properly or not & the system as whole doing as mention as per the system
requirement document, so we call this phase as the Integration & System Testing. Upon
complete testing of software is done then actual Software is successfully send to customer.

Operations & Maintenance: This phase is the never ending phase of the Waterfall Model.
The problems are comes in picture afterImplementation & Unit Testing phase. The
issues found after the implementation phase i.e. not found in the period of the development
life cycle. Some of the issues are not catch after testing cycle done so those are
implemented in the maintenance phase, so this phase is called as Operations &
Maintenance phase.

Advantages and Disadvantages of Waterfall Model:

Advantages of Waterfall Model:

  This is linear simple model to implement & easy to maintain.
 In the SDLC initial phase spent time on reviewing requirements and design which
saves the time later.
 Required resources are minimum in this model as compare to other.
 After every phase of the model a document in created which help & simpler to
understand & design the system.
 Upon completion of coding, is done to check for implemented code or correctness of
system.
 For each stage deadlines can be set which will help to develop the system on
decided time frame.

Disadvantages of Waterfall Model:

 The biggest disadvantages of such system is it won’t allow to go back. If the

problems in the design phase which creates complication in the implementation
phase.
 This model is rigid model. Not flexible & make changes is not possible in the
development of system.
 Unable to start the next phase before completing the previous phase so time
consuming.
 In the deployment phase all requirements are not covered or all requirements are not
cover so adding such requirements may create unsuitable system.
 To make it customer happy such new requirement need to be implemented in new
version of system which leads to added cost to system development.

Agile Testing Mindset:

To play a role of agile tester, the tester should have the Agile testing mindset which will help
him to break free from the traditional project methodologies such as SDLC, V model,
waterfall etc. In order to develop the correct mindset, the agile tester should possess the
following characteristics.

 “Prevention is better than cure”. An agile tester should be focused on preventing

defects rather than finding defects.
 An agile tester should provide the Quality Assistance over the Quality Assurance.
 An agile tester should not believe in enough testing but should believe in the
continuous testing approach instead of starting testing at the last moment.
 An agile tester should not play as an individual player but the agile team player and
should work closely with the whole team in collaboration.
 Responsibility wise in agile testing mindset, it should be team responsibility instead
of an individual tester responsibility.
 Testing focus should be on automation rather than manual testing when it comes to
regression.
 An agile tester should prefer the Exploratory Testing over the Scripted Testing
approach.
 It is not SDLC methodology therefore; agile user stories from product owner should
be used for customer requirement gathering over the traditional requirements
specification.
 When it comes to web testing, the focus should be on Technical, API Testing and GUI
Testing in order to ensure complete end to end testing.
  The mindset of an agile tester is to make sure that the software is built correctly
instead of breaking the software like Monkey testing.
 An agile testing approach does not wait for the testing phase to start therefore, with
the agile mindset the tester should be involved into testing as early as possible.
 An agile testing approach does not require providing the detailed testing report after
the end of testing instead Short Feedback helps the team to get the idea that they
are building the software in the right direction. This approach gives lots of time to fix
the defect if it is identified in the early stage as a short feedback.

After all it is “Attitude that makes the altitude”. Therefore, if a tester has the above
Agile testing mindset then definitely he or she is a perfect fit to the project’s agile team.

Test Coverage in Software Testing

Test Coverage is an important part in Software testing and Software maintenance and it is
the measure of the effectiveness of the testing by providing data on different items.

What is Test Coverage in Software Testing?

Amount of testing performed by a set of test cases is called Test Coverage. By amount of
testing we mean that what parts of the application program are exercised when we run a
test suite. In other words, test coverage is defined as a technique which determines whether
our test cases are actually covering the application code and how much code is exercised
when we run those test cases. When we can count upon some things in an application and
also tell whether the test cases are covering those things of application, then we can say
that we measure the coverage. So basically the coverage is the coverage items that we
have been able to count and see what items have been covered by the test. The test
coverage by two test cases executed can be the same but the input data of 1 test case can
find a defect while the input data of 2 nd cannot. So with this we understand the 100%
coverage does not mean 100% tested.

Mainly more focus is put on getting code coverage information by code based testing and
requirement based testing but not much stress is put on analysing the code coverage by
covering maximum items in code coverage.

How To Choose Which Testing Technique Is Best?

Testing technique refers to the method or way to test a software or a part of software. Each
testing technique has its own benefits. Different techniques target different types of defects.
So, it would be wrong to call one technique best. Based on the software and its
requirements, one test technique may suit better than the other to serve the purpose. And
sometimes, a combination of different testing technique might be a good way to test a
software.
The various factors that determine which testing technique should be used are discussed
below:

 Time constraint – It helps in eliminating and/or selecting testing types, depending

on the timeline allotted for testing. For ex, a software with a small timeline for testing
will more likely skip Endurance Testing.
 Budget – Budget might put a restraint on the different aspects of testing for ex,
resources, no. of test cases etc., which may impact the choice of testing technique.
 Specifications provided by Client – Sometimes client can provide clear guidelines
as to what testing needs to be done. They can also intervene to eliminate the testing
types identified during planning too.

 Risks involved – Based on the risk assessment of the software, the testing
technique can be selected. For ex, The Medical and Financial
sectors http://www.health-canada-pharmacy.com are high risk areas and require
thorough testing for their software. Testing approach should be risk based and
performance testing is a must.
 System Requirement Specifications – Based on the documents and requirements
drafted by the business entities, testing techniques like system testing, ad-hoc
testing etc. are decided. For ex, if there are no specific requirements provided then
tester can go for Ad-hoc testing.
 Defects: It is based on the defects found in a past release of the software.
Regression testing can be involved in the test suite for next release to recheck the
areas impacted.
 Software Development Lifecycle – SDLC followed for the software also acts as a
deciding factor for the test technique. For ex, Exploratory Testing is more likely to be
used in an Iterative test methodology rather than Waterfall method.
 Purpose of the software – It may include the end user. For ex, a software designed
for handicapped or disabled people must be test for accessibility.

You may interested in Software Estimation Techniques

Let’s discuss some of the testing techniques, their benefits and what they are suited for
most:
Static Testing:

This test technique should be included in all software testing. It helps in detecting defects
before the formal testing starts. It involves testing or review of documents or code during
early SDLC phases without doing any actual execution. This technique helps in software
development in following ways:

1. Reviewing the requirements or design to find out any missing or obscure

requirements and infeasible design.
2. A static analysis of code can help in finding structural defects without doing any
actual execution.

As we all know, the earlier a defect is identified in the SDLC, the cheaper it is to fix it. This
technique requires expertise in business and domain. Also, the efforts are increased during
this testing as involvement in various phase is expected from the team members.

Specification based testing technique:

This technique is best way to make sure that all the requirements have been covered and
expected matches the actual. It is based on specification or requirements of software as
drafted in the documents. It is also known as Black Box Testing. Based on logic used during
development one of the following black box technique can be selected :

2500. Equivalence partitioning testing: It is used when test conditions can be divided
into different sets. For ex, for testing a ecommerce site offering discount on purchase
like 5% off on Rs.1000, 10% on 1500 and 20% on 2500 and above, equivalence
partitioning can be used to divide testing in range of 0-999, 1000-1499, 1500-2499 &
>=2500. A value from each partition can be tested instead of testing the entire
range.
2501. Boundary Value testing: In the above example, the testing can be optimized
by involving Boundary values from each partition to have more coverage.

Decision Table:

It is mostly used for testing financial applications. The best example would be loan
application where depending on the combination of answers to different questions like if
loanee has account in the same bank, if he has taken some other loan etc., the maximum
loan amount is calculated.

1. State Transition Diagram: For testing a website for online form submission. Different
outputs come out on clicking on Next button depending on the details filled in. For
ex, if all the details are filled correctly then next page will display, error message will
display in case of incorrect information or on not filling the mandatory information.

Non-functional testing like stress testing, load testing etc. also come under this testing
technique.
Risk based Testing Technique:

This testing technique is very important for Financial and Medical areas. It is used to test
break points of system and its response in those conditions. If a system in Clinical Research
Organization crashes and the data is lost then many test trials and years of work may get
wasted. Performance testing comes under this technique.

 Structure Based Testing Technique: It is also known as White Box Testing. It

requires knowledge of the code and is generally performed by developers. It helps in
improving the quality of code as dead and redundant code can be spotted using this
technique. It also helps in identifying defect in early stage which can be fixed right
away. Unit Testing comes under Structure Based Technique Type.
 Defects based Testing Technique: This technique focuses on the area with
maximum defects. The test cases are written based on the defects found in the past.
Regression testing comes under this category. It can’t be used as sole test technique
but it is used to provide more coverage to overall testing.
 Experience based testing technique: It is based on the experience, background
and skills of a person in the field of testing. The testing is done on the basis of idea
that what could go wrong or where the defect might be. Testing methods like Ad-hoc
Testing and Monkey Testing comes under this technique. This test technique is
generally used for low risk system or when the requirements are not clear or enough.
It is also used when there is a time constraint and not enough time for testing.

Conclusion:
From the above discussion, we can conclude that each testing technique has its own
advantages and disadvantages. No technique is better than other. It rather depends on
factors such as time, budget, client, software type etc. and should be selected as per its
suitability to the software and its requirements.