Classic Software Testing Is Broken: An Interview with Regg Struyk


With twenty years of commercial software development and testing experience, Regg Struyk has developed for several software testing tools including test integrity, iTest, and Polarion QA. Regg is continually analyzing testing trends and their potential impact on software testing.


Regg Struyk will be presenting a presentation titled Why Classic Software Testing Doesn’t Work Anymore at STARCANADA 2014, which will take place April 5-9, 2014.


About Why Classic Software Testing Doesn’t Work Anymore:

The classic software testing team is becoming increasingly obsolete. Traditional processes and tools just don’t meet today’s testing challenges. With the introduction of methodologies such as agile, testing processes with a "test last" philosophy cannot succeed in a rapid deployment environment. To exacerbate our testing difficulties, we now have to deal with "big data," which introduces an entirely new set of problems. In the past, we have relied on tools such as test automation to solve these problems; however, classic test automation simply will not suffice on its own and must be integrated with the right testing activities while being supported by correct procedures. When you combine these problems with inadequately defined requirements and limited resources, you have a recipe for testing disaster. Regg Struyk shares real-world examples and offers constructive ways to move away from traditional testing methods to a more integrated process using concepts such as test-driven development and TestOps.


Cameron Philipp-Edmonds: Hello, here we are today with Regg Struyk, with twenty years of commercial software development and testing experience. Regg has had many different positions, ranging from the head of Pinnacle product management for Agfa HealthCare to, most recently, product evangelist for Polarion QA. Dedicated to the domain of test management, Regg is continually analyzing testing trends and their potential impact on the discipline of software testing. I guess I’ll start off. Regg, did we miss anything on that summary there?

Regg Struyk: No, it was a fairly complete summary, other than the fact that it’s Agfa HealthCare.

CP: OK, I apologize.

RS: That’s quite all right. It used to be a camera company that produced film for both cameras as well as medical devices for x-rays.

CP: OK. You are going to be speaking at STARCANADA this year, which will be April 5 through April 9. You are doing a session titled “Why Classic Software Testing Doesn’t Work Anymore.” That harps on the emerging trends in software testing. I guess this is the first question: Is there a traditional methodology being held on to by a lot of companies today that has proven to do more harm than good?

RS: That’s a great question, Cameron. I’d say that yes, there is. A commonly known one is the waterfall methodology. That would be the traditional QA that uses the concept of creating requirements and design specifications. Then you would use the method of going through these different gates, so to speak. Then, there’s a gate almost at the very end of the development process, which is called the testing process, which includes testing specifications, creating test cases, and executing those tests, and posting your results back to the development. Very tedious, regimented, rigorous methodology that certainly—in today’s fast-paced environments—really doesn’t meet the needs of the business community.

CP: Right. That makes plenty of sense. OK. Then, you spoke a little bit on requirements there, but what is more likely to lead to a testing disaster? Is it poorly defined goals, or is it requirements?

RS: That’s a tricky situation, because I think that when you get into different environments, it depends on potentially both of those issues, or maybe one or the other. An example is that, clearly, if a company doesn’t have defined goals and know what their objectives are, specifically from a business perspective, that obviously could create disaster for testing, as well—the same thing goes with requirements. If an organization doesn’t articulate correctly what their requirements are—meaning is—what exactly am I testing? What are the expectations? The outcomes could be very disastrous.

The mindset, I think, is definitely wrong. It comes down to there’s market pressures to release early and release fast, and the traditional QA methodologies don’t necessarily work in that environment. Requirements and goals get muddied because of the sake of being able to do increased releases at an exponential pace. An example, obviously, is looking at mobile apps. The expectation is to release them at lightning speed, but that could really suffer from a testing perspective if the user community doesn’t accept those particular apps.


User Comments

1 comment

About the author

Upcoming Events

Oct 15
Nov 05
Nov 14
Jun 03