Search
Close this search box.
Search
Close this search box.
Search
Close this search box.

No QA? All QA!

Facebook
Twitter
LinkedIn
Pinterest
WhatsApp

One of the major topics that intimidate test engineers is the No-QA question or approach (depending on your view of it).

I heard such responses after the session “Fiverr delivering fast..No QA”, by Gil Wasserman, Fiverr VP R&D, at our Agile Israel 2016 event. QA members asked me if they should look for their next role, and I keep hearing this concern whenever this topic arises.

So, is it true? Should we eliminate the QA role? Or better say – merge it into the developer’s role?

I truly understand the motivation for a No-QA approach – We do want to have a shared team responsibility for quality. We want the team to own it. We want developers to develop quality code and quality products and not to hand over the code to someone else’s problem. But I found that the No-QA way of doing it provides a contradictory message. If we eliminate the QA how will we increase the quality? How will we focus the developer’s attention on quality? What do we expect them to do?

Does this mean that there is no need for QA as team members? No QA expertise that should be valued?

Well, if we eliminate the QA role we don’t leave much choice for the developers other than to tell them that there is no one else to test, so they have to.

It’s like homework, you can hate doing it, but if you don’t – how will you learn? And yes, developers resist doing testing, but if they won’t – how will they learn? How will they value their code, their solutions, and the user flow? How will they improve the product’s testability and support?

But No-QA? Can they just do it? Don’t they need guidance, or assistance? Someone that will help them make their environment more supportive for testing and quality improvements, someone that will help them criticize the product, its solutions, and technology, someone that will guide them in thinking from the customer’s point of view?
This is where the QA team member gets in.  In the webinar of Quality at Speed, How JIRA Does QA they call QA – quality assistance.

I really like this term, because test engineers should not be quality controllers, instead they should assist in building quality into the process, and grow their team’s quality consciousness and practices.

They should use their creativity to run exploratory testing, to better represent the user, by setting better test environments and assist in defining better user stories, MMFs (Minimum Marketable Features), and MVPs (Minimum Viable Products).

They should question if you are building the right it rather than if you built it right, as greatly discussed in GTAC 2011: Opening Keynote Address – Test is Dead.

They should inspire others by promoting test-first approaches, defining automation & TDD (Test Driven Development) as well as working closely with developers on defining UT (Unit Tests). They should assist in becoming an All-QA.

As such, the ratio of Quality Assistance doesn’t have to grow. You can keep a small community of QA to provide higher quality and the fastest speed. You can make the developers build AND also evaluate their outcomes, relieving the QA bottleneck, but without ignoring the QA added value. Instead, you leverage it.

In organizations that develop complicated products or projects, that require domain/field expertise, merging the QA role into the developer’s one is not an easy and sometimes not a doable path. In the same way that developers hold their main expertise and can do some in other areas, including testing (being more T-shaped members), there is a place in the team to hold test assistance that can be experts in a certain domain of testing and also guide others towards better quality and contribute to other team’s areas as automation, pairing with developers on UT and TDD and so forth. The magic word here is balance. Balancing dev-test work within the teams and balancing shared team ownership and individual distinctiveness.

In an HBR article of the-problem-with-rewarding-individual-performers, Jay Van Bavel and Dominic Packer wrote that “By balancing individuals’ need to belong with their desire to stand out, a leader can build a sense of “optimal distinctiveness” among group members”.

I find it a real art to keeping optimal distinctiveness in the team. To relieve the threat of a cross-functional team with T-shaped people and shared ownership of quality, and still keep the team members as individuals, that are being recognized for their distinct expertise that contributes to the team.

So, No-QA or All-QA? Yes, I think that words reflect and impact our mindset. Therefore, an ALL-QA approach is better than No-QA.

QA has lots to do with building quality, assisting developers to test, ensuring that quality can be enabled, qualifying that the organization is building the right it, and making quality an asset of ALL the team.

What do you think?

Subscribe for Email Updates:

Categories:

Tags:

Sprint Iteration
Agile Program
Agile
An Appreciative Retrospective
ATDD vs. BDD
RTE
Frameworks
Nexus vs SAFe
Development Value Streams
Jira Plans
Agile Product Ownership
TDD
Agile Community
RSA
Test Driven Development
Kanban
EOS®
Scrum With Kanban
speed at scale
Systems Thinking
Keith Sawyer
Lean Budgeting
Certified SAFe
Reading List
speed @ scale
Accelerate Value Delivery At Scale
Agile Product Development
Continuous Improvement
Agile Israel Events
Achieve Business Agility
Tips
Agile Games and Exercises
Scrum Master Role
System Archetypes
Legacy Code
Continuous Deployment
Entrepreneurial Operating System®
Introduction to ATDD
Business Agility
SAFe
Introduction to Test Driven Development
chatgpt
Hybrid Work
Lean Startup
NIT
Certification
Principles of Lean-Agile Leadership
Agile Release Management
Software Development Estimation
Agile Mindset
Kanban Game
lean agile change management
Kanban Basics
Planning
LeSS
Presentation
WIP
DevOps
Advanced Roadmaps
Amdocs
Portfolio for Jira
BDD
Large Scale Scrum
Jira admin
Scrum Primer
Lean Agile Leadership
Continuous Integration
SA
Tools
Pomodoro Technique
Software Development
Product Ownership
Agile Marketing
Manage Budget Creation
Lean and Agile Principles and Practices
Agile Israel
User stories
Enterprise DevOps
QA
Agile Exercises
Professional Scrum Master
Lean Agile
Agile and DevOps Journey
The Kanban Method
Sprint Retrospectives
Games and Exercises
Kanban 101
Agile Risk Management
Atlaassian
Lean and Agile Techniques
ATDD
Lean Agile Organization
Effective Agile Retrospectives
Acceptance Test-Driven Development
Nexus Integration Team
Agility
Perfection Game
Change Management
Artificial Intelligence
Lean Agile Basics
Covid19
Agile Games
ART Success
Agile Assembly Architecture
LAB
Continuous Delivery
Value Streams
Implementing SAFe
Continuous Planning
Video
Product Management
agileisrael
Nexus and SAFe
Jira Cloud
RTE Role
Sprint Planning
Engineering Practices
Legacy Enterprise
Iterative Incremental Development
POPM
Implementation of Lean and Agile
Agile Testing Practices
Agile India
Spotify
Releases Using Lean
Professional Scrum Product Owner
Nexus
What Is Kanban
PI Planning
Code
Agile in the Enterprise
Agile Project
Built-In Quality
Elastic Leadership
AI
Managing Risk on Agile Projects
Professional Scrum with Kanban
Agile Delivery
Scrum Master
System Integration Environments
Managing Projects
Agile Techniques
Agile Development
Webinar
Lean-Agile Budgeting
Scrum Values
Agile Project Management
AgileSparks
Release Train Engineer
Applying Agile Methodology
ARTs
Nexus and Kanban
ScrumMaster Tales
Kaizen
Risk Management on Agile Projects
GanttBan
LPM
Agile Contracts Best Practices
System Team
Atlassian
Team Flow
Scrum.org
Lean-Agile Software Development
Kanban Kickstart Example
Scrum Guide
Risk Management in Kanban
PI Objectives
ROI
Agile Outsourcing
Lean Risk Management
Slides
The Agile Coach
Agile for Embedded Systems
Story Slicing
Operational Value Stream
Quality Assurance
Coaching Agile Teams
Risk-aware Product Development
SPC
Process Improvement
ALM Tools
SAFe Release Planning
Scrum
Agile Basics
Daily Scrum
Lean Agile Management
Scrum and XP
Agile Release Planning
Self-organization
AI Artificial Intelligence
Rapid RTC
IT Operations
Jira
Scaled Agile Framework
Lean Software Development
A Kanban System for Software Engineering
Kaizen Workshop
Program Increment
Limiting Work in Progress
SAFe DevOps
AgileSparks
Logo
Enable registration in settings - general

Contact Us

Request for additional information and prices

AgileSparks Newsletter

Subscribe to our newsletter, and stay updated on the latest Agile news and events

This website uses Cookies to provide a better experience
Shopping cart