Hello and welcome to our channel.
My name is Dmitri and I am a part of the Exactpro research team.
At Exactpro, we Build Software to Test Software.
Do check out our website - exactpro.com to learn more about us.
And feel free to subscribe and hit the bell button to see the new videos coming soon.
We are continuing our series based on the ISTQB foundation level syllabus.
Today, we are going to review the first part of chapter 2
titled ‘Testing Throughout the Software Development Lifecycle’.
If you missed the first video which was about chapter 1, please find the link in the description below.
Let’s begin.
Software development life cycles or SDLCs are quite fascinating.
Some are lightweight and fast, and so we follow them when time-to-market is of the essence.
Others can be controlled, documented and preferred in spheres where quality and reliability are
the key factors. As we mentioned in the previous video
testing is context-dependent. So the choice of SDLC is often tied to what
we are testing. It is important to be familiar with SDLC models
to be able to choose the appropriate one. A fit-for-purpose model can save time and
money, helping deliver a quality product. Whichever development life cycle is chosen,
we perform verification and validation. Verification is all about the requirements.
It makes sure that every one of them is fulfilled. In a nutshell, verification focuses on the question
'Is everything built according to the specification?'
Validation, on the other hand, centers on the user’s needs that were the reason for
writing the requirements. It answers the question ‘Does it provide
a solution to the problem?'. The ISTQB foundation level syllabus divides
all the cycles into sequential and incremental. A sequential model describes the software
development process as a linear flow of activities. This means that a new step should begin when
the previous one is completed.
Incremental development means that the software features
get updated by adding functions to the previous release until all functionality
is implemented.
Let's look at some of the sequential models.
The waterfall model is one of the oldest ones. It has a natural timeline where tasks are
executed in a sequential fashion. It’s easy to manage and the process should
be well-documented. And that is the blessing and the curse of
this model. If we don’t have clear-cut requirements
from the start, it becomes increasingly difficult to support.
It is hard to get feedback passed up the waterfall making it virtually impossible to correct
the mistakes made early in the life cycle. Under these conditions the price of an error
can skyrocket. This obvious disadvantage led to the development
of a more adaptive V model. The V-model associates test levels with corresponding
development phases, which supports early testing and it avoids defects snowballing from initial
phases to the final one. Each stage has defined results and is very
easy to control. The industry specialists agree that it works
great for small and medium-sized projects.
The problems start when the requirements have to change.
Because the V-model still supports linear software development
and has a limited built-in ability to respond to adjustments.
The other issue is that the testing is constrained by the rigid time frames.
It also promotes a strict link between the corresponding levels of coding and testing,
rather than encouraging testers to choose the most effective approach.
Both of the sequential models put out software
that contains the complete set of features, but typically require months before the end
product could be presented to its stakeholders.
The constant need to adapt to changes in requirements brought forth the publication of
the Manifesto for Agile Software Development.
It called for a new approach where changes could be implemented in small increments
to facilitate immediate feedback from end users and technology specialists.
In 2001, the creators of the Manifesto proclaimed that they were uncovering
better ways of developing software by doing it and helping others do it.
Through this work they came to value: * Individuals and Interactions over processes and tools
* Working Software over comprehensive documentation
* Customer Collaboration over contract negotiation * Responding to Change over following a plan
Agile didn’t not become an overnight sensation, but it slowly started to get traction and
now it is a de facto standard of software development across most industries.
It is iterative. It promotes flexibility and interaction with stakeholders to align development
with customer’s needs. Each iteration should yield a working product version
that you can show to your clients and get valuable feedback.
One of the best known methodologies based on Agile principles is Scrum.
It is a lightweight framework that requires the use of time-bound development cycles called Sprints.
Each Sprint starts and ends with a team meeting to discuss what to do.
The idea is somewhat similar to what happens in the game the term comes from.
A Scrum is a method of restarting play in rugby that involves players packing closely together
and attempting to gain possession of the ball. It’s a demonstration of strength, stamina
and what’s even more essential - teamwork.
The absence of comprehensive documentation reduces the workload but can also create additional
challenges. A record in the defect management system with a brief description of what
the new functionality contains is often the only thing available BUT the only thing needed
to huddle up together and push forward.
The only constant is change. In Exactpro, we embrace the values reflected in the Manifesto
for Agile Software Development. Agility allows us to turn learning into action and action
into change. From its inception, our company has been able to adapt to change. It is important
for us to keep this ability as we scale up our business. Here is what we practice.
* There is no need to confine QA to a scrum team or process. Instead, focus on individuals
and interactions capable of finding defects. * There is no need to request all test scenarios
upfront. Rather, focus on delivering working software.
* Defects should be used as a collaboration tool.
* And finally, Deliberate Practice of Software Testing enables you to respond to changes
in a truly agile manner.
To sum it all up.... Whichever life cycle model is chosen, there are several characteristics
of good testing: * for every development activity there should
be a corresponding testing activity, * test analysis and design for a given level
should begin during the corresponding development activity,
* testers should be involved in reviewing documents as soon as drafts are available.
* each test level has test objectives specific to that level
That's it for this video. If you liked it, give us a thumbs up.
In the next one, we will continue talking about chapter 2 of the ISTQB syllabus.
As always, let me remind you that we do have a lot more interesting content on our channel.
So, feel free to subscribe and hit the bell button.
Thanks for watching and good bye!