Good morning from chilly Portland. I'm saying that just by virtue of the fact that San Francisco has been warm and downright balmy. I got off the plane in Portland and immediately regretted not packing a hat.
A Tri-Met ride and a couple of blocks walk to get me to the Portland WTC, home to the Pacific Northwest Software Quality Conference. This year is a special year for PNSWC as it has been 35 years since their first conference, emphasized by a cake currently sitting downstairs (impressed that no one had cut into it yet, but they were smart not putting a knife out ;).
The introductory talk for today is "Quality Engineering 2017: Trends, Tricks, and Traps" by Penny Allen. Penny deals with the return process at Recreational Equipment, Inc. You might be familiar with their acronym, REI. One of the key points of Penny's presentation is that "Quality Still Matters". It seems that disruption is the new normal, the rate of change is exploding, and it's not like we are putting simple things together. We are now creating complex and game-changing interactions. Who remembers the days of a client a server and a database, when LAMP was all containing? I actually do remember that.
We are dealing with Internet-connected refrigerators... that DDOS us. We have information overlays... with people walking into traffic because they are so immersed they aren't paying attention. The cloud is magnificent... until the cloud, or our slice of it, goes down. Disruption is accelerating, and there are things we haven't even considered. DevOps, Microservices, CI/CD/C*, you name it. The only sure way to survive chaos is adaptation, and Penny says "radical adaptation" is essential.
Quality Engineering goes beyond design and construction. We also need to think about deployment and usage. More to the point, we need to "safeguard" these approaches and methods.
Why Quality Engineering?
Quality Engineering is tearing apart the problems we see and breaking them down until we understand them? Want to see the best and most productive Quality Engineers out there? Look at young children. Does anyone ask more questions than they do ;)? More to the point, they understand the creative process and there is a low fear of failure (that is if there is any real fear). Penny suggests we build our engineering muscles again. Books suggested are "Think Wrong", "Applied Minds", and "The Way Things Work Now".
Are You Saying I Have to Become a Developer?
Short answer, no. Longer answer, you definitely need to be a technologist. It means you need to be an inventive problem solver, be a self-driven learner, become a coherent communicator, be open-minded but practical, and become adept at finding the signal in the noise. Think of it as though you want to get into better shape. Do you have to become a marathon runner? Certainly not, but you may need to do some running. Or lifting. Or backpacking. Whatever it is, you have to decide to do it and then work towards achieving the goals. Likewise, you don't have to become a developer, but you would be well suited to learn something about programming and find ways to regularly use those skills.
Shift Left?
Show of hands, is "shift left" signal, noise or meaningless? Penny says that "shift left" is noise, but it really doesn't mean anything. Asking "why" earlier is useful, but that's not shifting left, it's called "doing our job" and no amount of shifting left will matter as much as continually asking why. The earlier we do that, the better we will be.
Focus on the End Results
Software testers often are responsible for a lot of busywork and supporting efforts that focus on deliverable other than the end result. In short, process does not impart quality. No one goes to a company to buy a test plan, they go to buy an experience. Qualiy is not beat into a product, it's designed from the start and safeguarded along the way.
No comments:
Post a Comment