This afterthought status belied the importance of testing in the software development cycle. Testing also required time and resources that were often unavailable during crunch times. If things went awry in the testing stage, everything could fall apart, resulting in delivery delays, costly labor-intensive repairs and lost revenue.

1. THE EVOLUTION OF
THE TESTING MODEL
AND WHERE IT WILL
GO NEXT

2. From the V-model to the test
pyramid, testing models reflect
the structure and needs of the
leading software development
life cycle methodology.
New models such as Spotify’s
honeycomb illustrate the
evolving nature of software
architecture and automation
tools.

3. THE EARLY DAYS: THE
V-MODEL
When the waterfall model ruled software
development life cycles (SDLCs), testing could
only be done after the final development stage
was completed. As a result, the testing phase
was often rushed. By then, the errors it
uncovered could be costly to repair.
One of the early testing models developed to
address these issues was the V-model — named
for the V-shaped diagram outlining its
development and testing steps. It is also
sometimes referred to as the validation or
verification model.

4. THE TEST PYRAMID:
ELEVATED AGILE
LIFE CYCLES
As technology and development cycles sped
up, the waterfall methodology gave way to
more iterative processes and, eventually, to
the agile methods widely used today.
Just as the V-model evolved to adapt to the
needs of waterfall development, a new testing
model arose as an answer to accelerated
development timelines. The philosophy of the
testing model shifted as well. Instead of
redefining the role of testing in the SDLC, the
new model — the test pyramid — served as a
strategic metaphor to outline the volume,
type and order of testing that would best
optimize for speed, effort and cost.

5. The “test pyramid” was coined by author Mike
Cohn in his 2009 book Succeeding with Agile,
which visually represents a three-part testing
strategy.
Unit testing serves as the widest foundation
layer, and services or integration testing
makes up the middle layer, leaving UI or end-
to-end testing for the top layer.
Most testing is done at the unit level, where
both developers and testers can break down
larger functions into smaller pieces to validate
and test as they build. In the middle stage,
testers validate functions that work together,
as well as APIs and services that enable end-
user functionality. Both of these stages are
ideal for automated testing.

6. SPOTIFY’S HONEYCOMB MODEL: A
REFLECTION OF SHIFTING ARCHITECTURE
Testing models continue to evolve as the nature of applications changes.
In 2018, the engineering team at Spotify outlined their own model that they felt better captured the
testing needs of a microservice-based architecture. This new shape reflects a system architecture that
focuses on APIs and has fewer and smaller individual units to test. Spotify’s model has gained traction as
more organizations move toward a cloud infrastructure similarly based on APIs and service integrations.
These shifts have led to higher volumes and the greater importance of integration-focused validations
relative to the other two testing areas.

7. WHAT’S NEXT? THE FUTURE OF THE
TESTING MODEL
While testing models themselves may morph
over time in various ways to reflect the evolving
needs of the industry, it’s important to remember
that, at its foundation, any testing model is a
visual aid that illustrates a testing philosophy. No
model can dictate how testing actually happens.
Visual models may be most useful for generating
consensus among development teams on an
approach to software testing. Once leadership
has agreed on a testing plan, they are better able
to hire the right team and equip them with the
tools needed to accomplish the goal.
Reference : https://www.testevolve.com/