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

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

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