The Agile testing mindset may be considered to be one of
the important things when implementing Agile quality and testing methods. While
many see “Agile testing” as just “having the QA and development part of
one team”, actually it is much beyond.
Agile testing challenging the core mindset of the organisation regarding the
role of the QA. Without dealing with the agile testing mindset , we may achieve
a limited or, in most cases, a costly, quality outcome, whereas we could have
performed better and cheaper.
Moving into Agile methodologies often demands adopting a new
set of knowledge and at the same time a new set of behaviors. after all, from
the starting point where quality people perceived as “bug hunters”,act as quality defenders, standing in the last
frontier line to “save the nation”, usually as separate “independent” unit that
need to be “objective”, from such mind-set we move to collaboration, “all team
approach” , we are all quality defenders and we are all the frontiers.
but before we will drill into the “new mind-set” , lets ask
ourselves, What is a mindset?
"A mindset is a set of assumptions, methods or
notations held by one or more people or groups of people which is so
established that it creates a powerful incentive within these people or
groups to continue to adopt or accept prior behaviors, choices, or tools. "
In other words, changing practices without changing mind-set
will not make the change lasting!
Now, what exactly is an Agile mindset?
Since agile aims to
deliver something that can go live, in a relatively short period of time it is
clear that we must shorter the cycle time between code developed to code
tested, we need to better react for immediate changes that pop-up as we learn
more and we need more effective and
faster communication channels than documents, as such - we must work
together.
We can identify mindset in various concepts and behaviors.
It's enough to take a look at the Agile
manifesto or the Agile principles
to understand that the Agile mindset is one that brings people to act together
in an ongoing working system.
So what happens to the testing mindset ?
We cannot achieve quality if only the testing unit are
quality oriented. we can do it only when the entire manufacturing chain is
quality oriented and committed to other chain units quality. This is a serious
thinking fixation change. To ensure
this, we need to change the mindset of the testers as well as the team and the
PO so they will be able to truly cooperate, share practices, and together be
accountable for a good working quality delivery software.
We want to bring the testers to collaborate with developers,
and we want developers to understand quality issues and to act upon them as
such they need to sit together or at least have daily direct communication. We can no longer leave the product owner far
from development and leave the testing as the last resort. The time frames are mach smaller ,the
feedback is given early and frequent and decisions needs to made faster and
easier. Development , product and testing needs to communicate more frequently
so small portions of code can be developed and tested into small working
business software units.
PO,development and testing is a collaborative triangle
that needs to be understood as a main agile mindset factor.
From “quality police” testers become professional support
for the PO and the development so all together as a team reaching quality
goals. We want also the QA to better understand the business and expected behavior
and the PO to understand system and quality impacts of his ideas, as such QA
move to the beginning of the process, acting as the right-hand of the PO during
requirement definition and of-course development.
The product owner is also becoming a key collaborative
factor for the agile team. If it's not working (Meaning also tested and accepted
by the PO), then it's not done, then it is not
"a working system".
We need to get used to working closely with product ,
getting and giving continuous feedback.
The following are example of
mindset statements which should act as the incentive of changing the
actual daily behaviors of developers, testers and product owners .
1. “We are all in this together ", “Whole team
approach”, “collective testing ownership”, “A testing mindset is a team
mindset.” “No more Us vs. Them. “ :
Testers aren’t expected to adopt quality and testing mindset
alone. We are all expected to do so. We all share the end-to-end concern of
delivering 'working software’. We are all accountable for quality. No
more" here are your requirements, let's meet in three month and see what
you delivered".
Another aspect of this mind-set statement is that as the
team (QA, Dev) share same goals and commit together on scope and quality there
is less attitude of “I am a developer so I will not
do QA work such as execute test plan …”, or PO that do not
have time to approve or even
write the test scenarios that cover the user story’s
expected behaviour.
it is a collective testing ownership approach with
developers and product. (while of course the tester bring the testing expertise
and developer the development but share ownership on the final result - high
quality software).
2. “ Development = Coding +Testing”, “We are building
quality in “ : We deliver working software. It's not done if it's not
tested. testing is part of the project ,
on a daily basis , it is no longer a phase . This is an easy mind set for
testers to adopt but it is a hard mind set for developers to adopt.
Do they need to start testing now? how can we test the
system ASAP? And why ? Who tests? When, what kind of testing? These are all
practical and mindset changes questions.
We are not waiting for the end of development to verify or
validate our quality.
We share quality activities throughout the product life
cycle, from coding standards, code review, unit testing until early system and
non-functional test. basically we didn’t finish any task if we didn’t validate
the quality. (quality activity is the “done” criteria to measure project progress from day 1). this
approach alone dictates a change in the entire testing practices to fit ongoing
testing feedback , ongoing quality feedback.
3. “Continuous integration”, Don’t wait to the
“integration hell period” at the end of project, where the integration is
big and heavy with a lot of details and defects. In fact, working in small
pieces is always better. Thinking small. Dividing a change to small pieces and
cope with small changes one at a time make the stabilization of the entire
system much easy. Furthermore, when the cycle time from code change, defect
detection, code fixing and system validation is short the waste (cost) is much
lower.
quality is not measured in scoped to the end. it is not a
huge defects reports used in the testing phase. it is an ongoing production of
working software Small pieces are tested continuously. Tests are integrated
into the development process. we need to think testing (and quality) at every
step we do.Developers and product are also expected to think testing first, not
only to review and examine testing planes and results after requirements and
coding are set.
4. “Communication is a key to our success”. we can no
longer communicate at the beginning of development or at the end. we need to
develop ways of ongoing communication, face to face communication so we can
produce early feedback.
5. “Visibility across entire team members” is a
primary aspect to our work. No more" I am coding and be finished in 7 days
..." every one needs to know what everyone doing .
6. “Customer collaboration”.”Testers are business
oriented” they represent the business
inside the team.
Why not share information with the customer or the customer
representative (such as the product owner, system analyst etc)? We are only
developing what the customer needs, not what we think he might need. Customer
involvement in early phases is the best way to develop software.
7. One of our goal is always working software (besides
satisfying our customers). This is our primary KPI. we need to understand that in each and every
development task , and a small business unit , we can not count any development
progress if it was not tested. we are measuring the progress of done software
only.
8. Continuous improvement. we are expected not only
to deliver but also to think about how we do things and to be proactive in
changing them.
Although testers are part of the team ,they are a
speciality, they are committed to constantly learn and improve their testing
and quality domain. In addition to improve their expertise as testers, QA needs
to lead the big Q thinking in the team (helping the scrum master), to advocate
for using metrics and implement team rules as defined following effective
retrospective and other process improvements beyond finding defects ...
Obviously, this mindset does happen in a day, it mature, it
is a process and it should be. A mindset is something that evolves and matures
along with practices, and skills, and team maturity. Testers cannot mature
alone. Mindset is one of the things that, in order to mature in it for testing,
we need also a team maturity.
How does it mature? what are the practical behaviors that
goes with it ? What is the manager role? All coming soon in the next posts…
References:
No comments:
Post a Comment