Blog

Involving QA team in Agile process. Interview with Matthew Heusser

Matthew Heusser is a managing consultant at Excelon Development. Matt has deep experience in software testing, project management, development, writing, and systems improvement. His extensive network of contacts in these fields has enabled him to put together a diversified, high-level team of experts at Excelon.
9 October 2014
Agile
Interviews
The article by a1qa
a1qa

Matthew Heusser is a managing consultant at Excelon Development. Matt has deep experience in software testing, project management, development, writing, and systems improvement. His extensive network of contacts in these fields has enabled him to put together a diversified, high-level team of experts at Excelon.

Matthew was lead organizer for the initial Great Lakes Software Excellence Conference, a regional event that continues today. He organized the Agile-Alliance Sponsored Workshop on the Technical Debt Metaphor, and recently published a leading position paper on the subject for Better Software magazine. Matthew served on the board of directors for the Association for Software Testing, and was the testing track chair for the Agile Conference in 2013 and 2014.

a1qa: Matthew, involving QA team in Agile process is always challenging. Nevertheless it always worth trying, hope you agree. Maybe you have your own method of introducing agile to a QA team or some leadership tricks you follow?

Matthew Heusser: Well, I’d say that the ideal Agile process moves from what (requirements) to done (in production), and done includes “running”, or production support. When you start to cut involvement back you tend to decrease throughput and quality.

Introducing Agile into QA consulting, well, I see two or three big pieces to that. I’d start with introducing the idea of iterations, or sprints. This brings up the problem of regression-testing, or release candidate testing, in a day or two, preferably less. This isn’t a problem for some teams; they work on twenty to a hundred small pieces that can be deployed independently. For others, we have to talk about strategy.

My preference is to talk to the whole delivery team about Agile adoption. Typically I find that it is possible for the developers to scale back the work to small chunks. Even in an ancient system, the programmers can slice the work thin enough to get done in two, weeks, ‘just’ adding a column to a report, and so on. The challenge is that regression. But if we ‘just’ added a column to a report, we can do a much more risk-adjusted test run. So one ‘aha’ moment is that regression testing does not have to mean re-running a specific test plan, and instead can mean varying the test approach based on risk.

The second big issue to tackle is story-testing – breaking a huge requirements documents into a chunks small enough to be actionable and yet meaningful. With traditional development, we tend to assume a 80-page specification implies deep thought. When teams chunk work and look for examples, we can often push disagreements and misunderstanding upstream, before coding begins, in a story kickoff. This is critical to actually getting testing done in tight time boxes — you just don’t have time for the back and forth bickering over what the software should do. So I see story kickoff, or “shift left”, or whatever you’d like to call it, as another ‘aha’ moment for agile-testing.

a1qa: Lean software testing is one of your interests. Still, lean testing is a curve of AGILE. So what`s makes lean software testing different from other Agile approaches?

Matthew Heusser: Lean Testing as I practice and teach it provides theory for why Agile Software Works – with small batches, limited work in progress, moving toward one-piece flow, and so on. It also provides concrete measures and metrics that improve team performance even when gamed.

Dare I say it, those are two areas that I see Agile falling down. Scrum or XP introduced as sets-of-rules without theory tend to fail, and Agile ‘metrics’ like Velocity can be easily gamed to the determent of the system.

a1qa: Let`s talk about testing in Scrum. It`s well-known fact that Scrum has a number of Pros: saving time, quick product quality delivery in a scheduled time. But what about Cons? There is a viewpoint that scrum is good for small, fast moving projects as it works well only with small team. And this methodology needs experienced team members only. Do you agree with that? And if you faced these challenges, how you managed to handle them?

Matthew Heusser: Well, first of all, you have to understand the problem Scrum was introduced to solve – requirements churn so fast that no one could get anything done. If you don’t have that problem, if, for example, your team can turn around code in a day – then off-the-shelf scrum might actually slow you down!

Here’s why – Scrum tends to prescribe iterations of a fixed length, with a standard now around two weeks. You figure out all the stories for those two weeks, the technical team commits to them, and the product management team goes to figure out what to do next sprint. If your team already does just in time requirements, and that is not a problem, then you’ve increased the batch size. Lean methods wouldn’t think of that as an improvement.

As for the argument that scrum only works with small teams, I would agree – at least to the extent that scrum was designed for small teams and doesn’t tell you what to do with big ones. But let me push back on that a little, at least to say that large teams organized by function don’t work, or at least, don’t work well.

For example, I worked on one project that you might consider medium – perhaps sixty people full-time for two years. The teams were organized functionally. Every day you’d have a test standup, a fronted standup, a backend standup, a scrum of scrums, an operations standup … who knows. I didn’t even have exposure to all the standups! Nor did I want it.

Scrum would prescribe cross-functional teams. Instead of eight functional teams of eight people each, we could have had eight feature teams with eight people each. This would have required a little infrastructure work so that the teams didn’t step on each other, but that would have been good design work anyway.

a1qa: And finally applying Lean software testing, Scrum or any other methodology, can testers reach 100% application/system quality, make it highly efficient? Or maybe QA is an endless process?

Matthew Heusser: As long as a new version of Internet Explorer, or Chrome, or FireFox, or Safari, or iOS, or Android, can introduce a change to javascript that ‘breaks’ existing functionality, then I doubt we’ll have 100% application/system quality any time soon. Of course, you can lock down the browser, and only support a specific version of IE. You can lock down the language, and only support English US and English UK keyboards, and so on. Apple controlled everything on the original version of the iPod, from hardware to OS to software. In those environments, you can get a lot closer to 100% correct. For example, a few years ago I wrote some Electronic Data Interchange (EDI) software that ‘just’ converted from one EDI format to another in plain text. That software was certainly fit for use; I am not aware of a single problem in production, ever. Yet a multi-gigabyte file with lines of text that were too long would probably crash it.

So there may be a few domains where it may be possible to get close to 100%. For the most part, for what I do, I can be most valuable in the domains that offer risk – because riskier domains are ones where risk management is called for.

Time pressure? Uncertainty? Ambiguity? Sign me up, because it is often those domains where a tester can add the most value.

Matthew thanks for sharing your viewpoint and experience. We`ll be glad to see you and talk to you again.

You can follow Matthew Heusser on Twitter, LinkedIn  and read his blog.

More Posts

Agile and DevOps in eCommerce QA_mini
30 September 2021,
by a1qa
5 min read
Agile and DevOps: Boosting the quality of eCommerce apps
What benefits do Agile and DevOps bring to eCommerce business, and how QA helps with that? Find it out in the article.
Agile
Quality assurance
Agile article mini
15 July 2021,
by a1qa
4 min read
How to handle the uncertainty with Agile: three-phase game plan
With the instability taking place even now, we are highlighting 3 steps to address uncertainty issues through Agile and deliver high-quality software.
Agile
12 April 2021,
by a1qa
5 min read
Watch out for 6 telecom trends and QA tips to implement them
In our article, we unleash the upcoming telecom trends and reveal how to be certain in introducing them correctly by applying QA practices.
Agile
Test automation
18 December 2020,
by a1qa
4 min read
Top 5 QA and software testing trends in 2021: responding to a global situation with ease
Rapidly approaching 2021, a1qa proposes to have a closer look at the most influential trends empowering QA teams to perform even more effectively.
Agile
QA trends
Test automation
6 October 2020,
by Dmitry Tishchenko
4 min read
A clear view of smart team scalability
Get to know how to scale your team sagely and gratify end-user needs and fast-paced tech-market requirements.
Agile
Quality assurance
14 September 2020,
by a1qa
4 min read
Winning the competition: how to accelerate time to market
The current global situation has boosted the digital transformation of many processes and operations. Get more information on how to be ahead of competitors by speeding the delivery time.
Agile
Test automation
4 June 2020,
by Vitaly Prus
4 min read
SAFe vs. Scrum, and PI planning essentials
Let's shed some light on the SAFe differences from Scrum that are to be considered by the development and QA teams who have migrated from Scrum.
Agile
Quality assurance
13 May 2020,
by a1qa
4 min read
Understanding Agile testing: 6 questions answered
Consider the aspects regarding the quality of software products developed based on Agile best practices.
Agile
17 April 2020,
by a1qa
5 min read
QA-focused retrospective: identifying and solving project problems
The a1qa experts came up to consider an effective approach to identify project bottlenecks and get rid of problems successfully.
Agile
Quality assurance

Get in touch

Please fill in the required field.
Email address seems invalid.
Please fill in the required field.
We use cookies on our website to improve its functionality and to enhance your user experience. We also use cookies for analytics. If you continue to browse this website, we will assume you agree that we can place cookies on your device. For more details, please read our Privacy and Cookies Policy.