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.

1. The Agile Testing Mind-Set Maturity - Part #1
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?
From Wikipedia:
"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

2. 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 behaviour 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 behaviours 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

3. 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.

4. 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:
Agile manifesto or the Agile principles
From Wikipedia
Agile testing .by Lisa Crispin and Janet Gregory.