so what is agile testing well in this video we're gonna find out and I'm gonna
give you a common-sense overview based on experience of working as an agile
coach and consultant.
Alright so welcome to this series of videos on agile
testing we're going to look at the kind of theory and thought processes and to
help us understand it because when we are working on an agile project we need
to have a massive amount of flexibility and tailoring what we do so I'm gonna
start by going through a kind of slide deck that I created which answers the
nine common questions about agile testing. And in this one we're gonna cover
the first one. What is agile testing? Now people get hung up on this for some
reason they make it very very complicated. I'm gonna get a mindmap up
and we're gonna use that to discuss this a little bit. One thing that agile
testing is not. Is a noun. So when we say "what is agile testing?". It's not thing.
it's not... You can't buy a bunch of agile testing, what it is... it's a verb its an
approach it's a process. It is how we test on an agile project. It's the stuff
we do, and the way we think. But it's on an agile project that's the only thing
that makes it different from any other test approach the fact that we are
testing on an agile project. Now it seems kind of tautological, that seems obvious,
but for some reason people make it hard and it's not a new thing, as we're gonna
find out. Because people get hung up on the words and they get hung up on the
words because they don't really understand what the words meant before.
They didn't really understand what testing meant before. So agile testing
seems like it's a new thing. Fundamentally agile processes are
adaptive in their organization to help people deliver functionality on an
ongoing consistent basis meeting requirements and needs quickly because
of few trappings; it doesn't mean that the software development happens faster
it just means we meet needs and requirements faster, and testing has to
respond to that. Which means testing has to work differently because previously
with testing we, in theory, knew what we were gonna do in
advance so we planned for that and documented for that. Here with agile we
don't necessarily know what we're gonna do in advance. We're gonna adapt we're
gonna prioritize some functionality above other functionality and the test
approach has to compensate for that. Which makes it unique. And it's unique
for the environment that we're working in, the particular company. Or the
organization; and it might be different in each department in that organization.
And it might be different on each team in that organization. And sometimes it's
different for each team member. Now the more coherent and consistent an Agile
process is, the better it works. So hopefully every team member has the same view but
sometimes they don't. When we approach testing we are very often just trying to
fit into all these different viewpoints on agile and how it works. Because we're
trying to mitigate risk in different ways. So what we're trying to do is fit
in to that process. The test process is not a separate in parallel process that
we can outsource and offshore, it is a process that merges very tightly with
the programming approach. Because what we've got is we've got a software
development approach. One part of that software development approach is
Programming. One part of that a software development approach is Testing. They merge
together to get an effective Agile Development Process. We're trying to
cover risks. I'm gonna cover risks later on here, but we're very often
targeting risk because sometimes the programming approach will be built to
mitigate some risk. We might be doing Test-Driven Design (TDD). We might be trying to
do Acceptance Test-Driven Development (ATDD). We might have a lot of processes in our
normal programming process that mitigate risk. Therefore the test approach changes
because it's a different risk profile. The risk is going to be in different
places in the system so we test differently to try and accommodate that.
And it's important that the approach that we take to testing on Agile projects
is agreed. And the reason it's important its agreed is because testing is no longer
about the tester, and the tester role. It is about testing on the project so
different people can test in different ways to different levels. A tester
hopefully can test better than other people; and can test differently than
other people. So we want to use those skills appropriately on the project so
that they're not just spending their time covering very basic acceptance criteria.
Because pretty much anyone can do that. They're looking at targeted risks, system
risks, more complicated approaches. Longer term approaches to: performance, security,
stress testing, functional testing, technical testing, accessibility.
All the parts that require a bit more skill and a testing focused thought
process that requires time to buildup. Than just the normal obvious stuff that the
acceptance criteria tells us. Now the key thing about Agile; is that an Agile
process is one that adapts. It will change over time as the team learn how
to work together. As their system of development changes, their process will
change. Their needs, for what the software will deliver, change. The architecture
might change. The tools that we're using might change. The risk profile of the project
changes as it goes forward. When it starts, we accept a lot of risk because
we're trying to create something as a Minimum Viable Product to get something
out, to validate some assumptions to make sure we're on the right track, to
fully flush out the kind of needs that their users have. But later on we want to
make it more robust, we're not as accepting of issues when the system is
live. We won't accept risks because they're going out, not just internally
but to externally facing clients. There's money passing through the
system now. The risk profile changes so the test approach changes over time the
skills on the team will adapt over time. As the team learns to work together
knowledge transfer takes place. Programmers learn how to test better
because they're working with the testers. Therefore the amount of testing work
that the programmers can do changes over time. The test approach changes and
adapts. The system architecture changes. We have to learn different technical
aspects in the system and how to test, them which might require testing at
different levels: underneath the GUI, at the API, at certain binary protocols.
Understanding the risk that is in place with the way that we build the
interfaces. All of this changes over time and we have to learn it and adapt to it.
The time scales will change over time because we'll need functionality
delivered at different points. Some functionality might span multiple
iterations of releases. We have to test in a way that accommodates that. We have
to test the in-progress functionality knowing that it doesn't work completely.
Then test it as though it were finished. There's different stages and approaches
to our test we have to adapt. Now that might sound complicated, but the reality
is that agile testing is simple. What we've done is we're trying to involve
everyone, and we're trying to make this part of the development process, and
we're trying to make this simple. And to do that we just avoid many of the
trappings that we've come to associate with software testing. So given that
agile testing is simply an approach to testing on an agile project. We should
probably look at how it's different. Now it's not really different in the
fundamentals of testing. What is different is that we've come to
associate testing with a lot of process, with a lot of trappings, with a lot of
paraphernalia. A lot of extras. So we strip those away and get back to the
essence of testing, then we have something that can probably work better
on an agile project. So the kind of extras we're talking about are a lot
of the documentation overhead. Now they're overhead on an agile project
because an agile project is incrementally defining what it's doing.
It's making decisions as it goes along. It doesn't know in advance everything
that it's going to do. Or what its gonna try and aim for. Therefore a lot of
big documents to explain exactly what you're gonna cover at certain points is
not required anymore. These kinds of documents are a response
to a development process that required them because it was doing a lot of
things in advance. And testing is very often a response to the development
process. To the regulatory requirements that we have in place.
To the management process, to the reports that they need, or want. Or organizational
hierarchy that we're going through is. Agile changes all of that
so we should expect the process, the trappings, to change as well. We're no
longer offshoring it... hopefully. Because we're trying to get the team to work
together. Tightly. We're changing the way the team are organized so they all work
very closely together. All of that changes the extras that we have to do.
There's a much greater requirement for verbal communication, for taking
responsibility for pointing out risks and problems at the time that they
happen. We don't need a lot of documentation. That doesn't mean we don't
do any. Right I think it's still important to describe the decisions that
we make, and write those down, because they help us evaluate if we've done
enough later on. I think it's still important for us, when we do our testing,
to document what we've done. It's important to document the ideas we have
in advance if we have ideas in advance. Because there's no point keeping all
this stuff in our head, because then you're the only person that can do it,
and we're trying to spread the load. So trying to write things down is still
important. But it doesn't mean we need a test management tool, we can use whatever
tools that were using to track our project. If we are doing everything text
files and uploading them to github, then that's where we document our testing.
We're using JIRA for everything, then that's where we document our testing.
Whatever we're doing as part of the software development process, we use in
our software testing process. We don't add extras that are not actually
required for the team. And if we have a lot of extras that are being asked for
because of organizational concerns; we should probably be trying to get rid of
those if we as testers are the only people responding to those external
needs, because it's not helping the team move forward. So with agile testing the
way that we adapt testing to any environment, regardless of whether it's
Waterfall, agile, scrum, some sort of hybrid, whatever we're doing.
We need to understand testing and that's why we've had a problem with agile
testing. Simply because people haven't understood testing. So they've tried to
carry forward all the stuff that they did on a traditional waterfall project:
all the templates, all the processes. Because they don't really understand
testing. None of that was testing. We need to understand the essence of testing. Now
this might seem bad but it's not intended to be bad.
Essentially with an agile process: were making this up as we go along. And what
that means is we're responding to the needs and changes in the environment
based on our experience, and lessons learned from other people: from things
that we see in the world, from conference talks, from articles. We're pulling all
this in. We're doing experiments. We're seeing what works.
Now that sounds bad. But that's fundamentally the essence of:
psychotherapy, is the essence of lean manufacturing. I mean that's the reason
why I study things like Cybernetics. There's a small subset of my Cybernetics
library. Because Cybernetics is all about systems, and teleological based systems.
Systems with a purpose, how people respond, and how you use feedback.
Cybernetics is massively important in terms of understanding systems and
testing and agile. It's why I study systems theory and systems thinking.
Because we're working with systems, we're building systems, as a system. We as a
team are system of development. Systems stuff. Is really important to
understanding agile and testing. Lean manufacturing. All the stuff on lean
manufacturing. We get told, we shouldn't have factory approaches to
testing. But there's a lot we can learn from manufacturing industries that are
lean based. Who are trying to adapt to what's going on on the ground. Who are
trying to make their processes more effective. Who were trying to avoid all
the waste. We talk about Kanban processes. Kanban came from supermarkets
and lean manufacturing. That's where we go to understand how people improve
things. Because there's nothing wrong with a standardized process if it helps
us learn. And if we're flexible in changing it. So all of these things put
together help. So whilst it sounds like "make it up as you go along" is a bad
thing. we're making it up as we go along because we
are heavily invested in studying other areas that work, that deal with complex
dynamic systems, and we learn from those. So in terms of understanding testing we
need to understand what is testing for? What are we trying to achieve when we
test in this environment. Because there's lots of ways of looking at testing. We could
go we're just trying to find the problems. We're trying to prevent problems which means you
get involved in different ways in the process. We have to look at what models
of testing that we find value in. Wo we might model testing as feedback. So that
means who are we passing feedback into? Are we acting on the feedback? Is it
positive or negative feedback? Are we attenuating different signals so
that people don't notice them? Are we amplifying signals? Are we doing that
with the right signals to get the right feedback back? Are we doing this as part
of an assurance process to convince people that things are in a certain state?
Are we certifying it? Therefore it has to meet certain criteria mandatory on an
ongoing basis? That would change how we test. Do we value and model exploration in there
because we're trying to see what else we might not have thought about. What else it
can do and should it do that? Or not? To make decisions on it. What are the risks?
All of these things change how we approach the testing. And it comes down
to what models of testing we value on that project and in that team. And we have to
understand that testing has never been about the tester. Testing has always been
about the process that we use, the approach that we take, and the results
that we get back. And Agile in particular isn't about "a tester does
the testing". It is about "testing as a verb", a process on the project. And if
testers hold that close and say "we do the testing!". You are not harnessing the
flexibility and freedom that you can have on an an Agile project. Its important to
understand how we test. Because fundamentally, when we test, we... I think... we
build and compare models to the system, and as we do that we learn more, which
changes our models: requirement models, acceptance criteria models,
non-functional requirement models, certification requirements, assurance..
whatever. All those are models. They feed in, we use them to explore the system in
different ways with using the skills and techniques that we have at our disposal.
So learning how to model well, learning better skills, learning technical
knowledge. Are all massively important, and that's the essence of testing. And
that hasn't changed. It's just that when we did Waterfall and structured testing we had
a lot of trappings on top of them. So Agile Testing is new, only in the sense
that it's not a templated approach. You don't come into agile and go "right we're
an agile project now, we do a test strategy, one-page test strategy because
it's agile, and our process is..." It evolves. It changes based on the needs of
the project, based on the skill sets of the people there, based on the current
set dynamics, and we expect those to change
We can't shoehorn in old tools and processes and mandates and procedures
and templates and documentation and meetings after meeting after meeting.
That won't work. We can only succeed on agile by understanding and harnessing
the essence of testing, and that's what we as testers have to learn. That's the
value that we add in agile projects - the essence of testing. And sometimes we're
the only people that can implement that until we teach other people how to do it
properly. We're trying to avoid waste. All those trappings that you've brought from
your other projects, probably are waste and are not required on an Agile project. So we
have to understand that, we're trying to avoid it. That's why understanding lean
manufacturing can help because it's about avoiding waste a lot of the time.
And we're trying fundamentally to work effectively as part of a system of
development. That's really what is driving us as part of an agile approach.
So we are trying to adapt to the process that's in place. We tackle risk. Lots of risk.
Process risks - the way that we actually build the system. We might change our
test approach based on that. The actual product risks that were prepared to cope
with. The technical way that we're building the system, where we can test,
how we can inject data, what tools we need to work with. All of these things
change how we approach our testing. We want to
keep things as lightweight, as lean, as fast as we can, to avoid trappings. But
that doesn't mean we neglect the persistent mechanisms in our
communication process. That means we ... doesn't mean we don't write things down.
It just means that we write down the things that are important. And testing
fundamentally is a verb. It's not a noun. We're not going out and getting some
agile testing. We are testing well and effectively on an agile project. That's
agile testing. So if this video has been useful I'll do some more videos on agile
testing. So subscribe to the channel to make sure that you get that information.
And leave a comment, tell me what you think. What other questions should we be
answering about agile testing? What other questions do you have? Let me know we'll
see if we can answer those as well.