As the saying goes there’s never a second chance to make a first impression, and in the case of Scott Barber this could not be closer to the truth.
I remember meeting Scott in a testing conference some years ago.
Scott was the guy running around the conference, making sure everything was working perfectly and personally verifying that all the attendees where gaining the biggest value from the event.
From the very beginning it was clear that Scott was a pragmatic and value-oriented kind of person.
This impression of realistic pragmatism was also palpable in the way he talked and discussed about testing-related topics. Always approaching testing from a value-adding perspective.
Looking back, I think that Scott helped me to fine-tune my testing approach of always placing “the customer” in the centre of my testing practices. But the revolutionary part of this approach resides in the correct definition of who “the customer” really is in each of your testing projects.
Surprisingly enough, in most projects this figure (the customer) is not the end-user of your product but the “internal customer” of the information you are providing with your tests and bugs; your peers and management team looking for the information necessary to make the best possible decisions about their projects.
I am really happy I asked Scott to answer my five testing questions, as I think he gave us some very straight and insightful answers.
To quote a couple of phrases that really stuck to me:
“Counter to what many testers want to believe, testing is not about finding bugs, is not about quality, is not about the user, is not even about the software – at least not directly.”
“…if you feel like your organization sees what you do as easily replaceable, it’s time for you to raise your game and start adding value that isn’t seen as easily replaceable.”
“Businesses don’t *really* care about “low-defect” software. What they care about is software that makes or saves them the most money, as quickly and cheaply as possible.”
Now go and read the whole set of answers!
Other than providing consulting services as part of PerfTestPlus, he is constantly speaking in conferences and gatherings about a number of varied testing topics. He has co-authored or contributed to 4 testing books (Performance Testing Guidance for Web APplications, Beautiful Testing, How to Reduce the Cost of Testing, and Web Load Testing for Dummies), and has composed literally hundreds of articles and papers on the topic.
In the past Scott served for 4 years as the Executive Director of the Association of Software Testing.
And now, let’s dive into Scott’s answers…
5 Testing Questions
1) What is the role of testing in today’s “typical” development process or organization?
I like that you ask what the role of testING is, as opposed to the role of testERS. I think the distinction between those two things is both important and frequently overlooked.
Today, I don’t think there is *a* “typical” process or organization, but I do think it’s fair to say that there are 3 “typical” roles that testing plays. These roles appear in a variety of combinations and levels of focus in different processes or organizations.
· Help Developers write “good” code: detect and resolve issues *before* story acceptance or tagging a build as done.
· Find bugs: most frequently done one sprint or build behind development and includes the defect reports, triage meetings, etc. typical of iterative approaches.
· Ensure compliance with legal/regulatory standards: Generally limited to “Release Candidate” builds, *shouldn’t* find bugs, but always does; thus jeopardizing the release date.
I think these three roles are actually just different aspects of the same overall mission of testing within a for-profit business: to help the organization make or save money. Counter to what many testers want to believe, testing is not about finding bugs, is not about quality, is not about the user, is not even about the software – at least not directly. Testing is all about the bottom line on the accounting spreadsheet. Bugs, quality, the user and software are simply things businesses take into account when trying to turn the highest profit they can get away with.
Businesses don’t *really* care about “low-defect” software. What they care about is software that makes or saves them the most money, as quickly and cheaply as possible. Once the business perceives that it will cost more to fix a defect than it will cost to ship that defect, the software is going to ship.
In reality, that makes testING a supporting role of business risk management, not actually a role related to improving or assuring the quality of the software product.
2) Which are the most important traits a tester should have (or should develop) in order to succeed today?
Seek to understand what makes businesses successful. Learn to think like a business executive (at least sometimes) when you are testing. Understand business risk management and the reality that as a tester, you are a cost center, not a profit center. No one (in their right mind) wants to have to pay for testing – sure they want the information, but they’d rather not have to pay for it, so you’ve got to make sure that information is valuable in *their* eyes.
Of course, good business sense is useless to a tester if they are a lousy tester. I think to be a really good tester today one needs to be far more social, collaborative, cross-functional and participatory than was common when I started testing well over a decade ago. Of course, all of those traits we commonly associate with testers like curiosity, technical savvy, oral & written communication and industry expertise still apply.
3) There have been a number of publications, talks and twitter threads lately about the possibility that testing is in fact a “Dying Profession”.
Do you agree with this statement?
In the sense that testing as a profession is in the middle of a dramatic transformation, yes, I do agree. In the sense that testing as a part of software development is somehow less important or necessary, no, I do not agree.
I think there are certain types of testing that can be accomplished perfectly well by people whose primary job is *not* testing. I think there are other types of testing that absolutely demand the skills, knowledge and specialization that you only expect to find in someone who dedicates their career primarily to testing. I think organizations are starting to figure out which is which, and that as they do they will assign testing tasks where it makes the most sense as opposed to automatically assigning them to the people with “tester” in their title.
What does that mean for testers? It means that if you feel like your organization sees what you do as easily replaceable, it’s time for you to raise your game and start adding value that isn’t seen as easily replaceable.
4) Looking back at your successful professional career, can you point to 2 or 3 milestones (or people) that made you the testing professional you are today?
I have to give my father a lot of credit for teaching me how to think for myself, how to solve problems, how articulate concepts through analogy. As a kid, I was sometimes annoyed with how he wouldn’t just answer my questions, and seemed to turn everything into what I now know to be called “teachable moments”, but in retrospect, I am grateful. The skills and qualities I developed as a result have been absolutely invaluable in my career and my life.
Mike Kopecky deserves credit for recruiting me into testing when I didn’t even know that software testing was a career. At a time when I was looking for a new job, he recognized that my personality coupled with an Bachelor’s degree in Civil Engineering, a Master’s in IT, 4 years of experience as an active duty military officer, 18 months as an Information Engineer/Analyst, and year as a configuration manager/DBA/System Administrator added up to “future tester.” When I called and asked him to help me update my resume, he said “Don’t worry about that, comes work with me, we need a Performance Engineer.” I replied “What’s that?” He responded “Don’t worry, you’ll like it.” And that was all it took, I’ve been in testing ever since.
What finally solidified my career path was Ross Collard inviting me to co-found WOPR. That experience, along with the all of the great people it introduced me to who I have learned a great deal from along the way, are what allowed me to grow from a “very good employee performance tester” to the industry influencing thought leader I am today.
5) What would be your most important piece of advice to a beginner tester today?
I’d offer 2 pieces of advice to beginning testers today:
· If you don’t love what you’re doing, do something else (or at least try doing it for a different organization). Testing is not something you’re going to be happy doing for the next 10, 20, 30 years if you don’t love it today.
· Don’t ever let yourself believe that there is one way, one term, one process, one tool, one report, or one anything else that is either “universally best” OR that all testers agree on. There are only two things that seem to be even close to universally true when it comes to testing – things are constantly changing, and if you put 3 testers in a room with a testing term or topic to discuss, no more than 2 of them will ever agree at the same time (except maybe that they’ve had enough disagreeing and want to do something else now).
Thanks to Scott
Once again I wanted to thanks Scott Barber for his answers and for taking the time to explain his testing approach and real-life wisdom.
I am sure many testers will get a number of ideas on how to approach their testing in a concretely different way today, and generate more value to their organizations.
Practitest is an end-to-end test management tool, that gives you control of the entire testing process - from manual testing to automated testing and CI.
Designed for testers by testers, PractiTest can be customized to your team's ever-changing needs.
With fast professional and methodological support, you can make the most of your time and release products quickly and successfully to meet your user’s needs.