Each of our FailQonf Speakers has years of experience behind them and a crazy amount of knowledge acquired over those years. It would be bad on our part if we restrict their stories to only their FailQonf sessions. We are as eager as you all to know them and their journey better, and hence this Interview Series.
We had a few questions in mind which we wished to get answers from all of them, and there were questions we designed based on the little research we did on their work and life. We so enjoyed the process and now as we have the answers with us, we are enjoying it even more. We are sure you will enjoy this interview too.
In this interview, I (Aakruti Shukla) took the opportunity to ask our FailQonf Speaker Peter Walen a few questions about Failures, Lessons learned, and a part of their amazing work in the Industry. We thank Peter Walen for their time to answer these, and for sharing a part of their life with us.
About Peter Walen: Peter Walen is a strategist, technologist, and philosophical thinker who has spent the past 25 years focused on solving quality problems in complex organizations. His formal education included history, philosophy, music, and education. Using dialogical methodologies honed from years of teaching and technology experience, Pete works to help organizations, teams, and individuals enact positive change by changing the social relations in the organization.
Pete’s dialogical methodology has proven effective in large, enterprise organizations as well as small startups. Pete has employed his methodology in full-time, contract, and consultative capacities. He understands the nuanced challenges that testers face in an ever-changing landscape and uses the depth of his knowledge and breadth of his experience to make changes in the organizations where he works and to help other software professionals do the same.
Pete enjoys making and teaching Irish and Scottish traditional and folk music. He also writes to share his experiences in the software industry. You can learn more about Pete’s philosophies of software testing and quality on his blog.
He is a member of the American Society for Quality (ASQ), the Scrum Alliance, the Agile Alliance, and a former Member of the Board of Directors of The Association for Software Testing (AST).
Aakruti: What was the funniest reason had been given for releasing you from the project?
Peter: My sense of humor. Apparently, they did not want people to tell jokes at the beginning of meetings (before everyone joined) or in the test lab. I did not find that funny at the time though.
Aakruti: What do you mean by deep-dive testing that you mentioned you performed when you were with Salesforce?
Peter: Deep-dive is how I tend to approach complex testing challenges. There are always some form of requirements and expectations presented. There are always known behaviors that need to be evaluated. Then there are the behaviors that are lurking under the covers. The team I was part of did all API-level work. None of it involved a UI. This meant to test, we needed to drill down into the behavior of the API itself. How did they handle various combinations of data coming in, including unusual, irregular or unexpected. The requirements only covered so much and, like most documented requirements, made huge presumptions. My job, and the work I did training the development engineers, was how to drill down into those combinations. Particularly, the “improbable” or “no request would ever come for that” scenarios.
Aakruti: How production testing or pre-release testing should be? How the practices can be improved?
Peter: I’m not sure there is a single answer for that. Much depends on the software being developed, the people using the software, the nature of the software itself and the variables of implementation. In general, I try and replicate the conditions and installation of the largest or the majority of the customers. Depending on the nature of the problems and infrastructure, I try to run test scenarios, automated as much as possible, that will exercise the implementation for both positive conditions, and which have led to problems in production in the past.
Aakruti: If you recall your first professional failure, what was it and how did you respond to it?
Peter: Wow. My first? Oh my. There have been so many! Some have been simple, quickly handled and resolved. Others took some amount of effort and a little bit of open-mindedness from everyone involved. Then there were the ones that took a lot of work. Instead, I’ll talk about what one boss I had, many years ago, told me. There was a particularly hard day. Loads of problems and raised voices. After getting chewed out by my immediate manager, I was sitting at my desk trying to get the cause of one of the problems identified so it could be corrected. My manager’s manager came to my desk with two coffees. One for him and one for me. He said “Pete, you’re doing a fine job. I know people are blaming you for these problems and they are not your fault. There are a lot of things that go into these kinds of issues. Remember, everyone makes mistakes. If you make a mistake, fine. Learn from it. Learn to not repeat it and go on. If you make another mistake, learn from that one. Don’t make the same mistake twice.” I’ve tried to follow that ever since.
Aakruti: Any experience you would want to share wherein you learned from someone’s failure and based on that lesson you actually avoided a similar failure at work?
Peter: Code Reviews. Always walk through the code before checking it in or promoting it from your local environment. A teammate checked in some code that caused some problems in the test environment. Everyone was working really fast as we had delivery deadlines approaching and suddenly, nothing worked anymore. I ended up pairing with him walking through the code he had changed (SQL in this instance) and began asking questions. I was getting more confused the more I tried to understand it. We both realized what had happened at the same time. a block of code he intended to delete, after typing in new code, had in fact been duplicated. Quick change and poof! Everything worked again. Always review your code, automation or product it doesn’t matter. If you are under tight pressure, ask someone else to see if you missed something. None of us are perfect.
Aakruti: What is the most interesting failure you have experienced, which kicked hard, but once you learned from it you achieved the double of what was expected in the next attempts?
Peter: In truth, the failure that pushed me to greater things is the core of my talk for the conference. The short version is, leading people is not a one-tool-always work task. Even if you have several handy, they may not be what is needed. You can get results the organization needs, but the cost can be very high. The cost also may come with other opportunities. Being open to them and not focusing only on the loss is what pushes you forward.
We hope you enjoyed reading this amazing interview. Let us know your thoughts in the Comments section.
We can guarantee that you are going to enjoy FailQonf even more. Have yourself enrolled here if you have not done it so far. Please note there is a Free Pass option for the ones who cannot afford the Paid one in these difficult times. See you there.
About the Host:
Aakruti is working with Xoriant, Pune as Senior Test Engineer. She loves testing and had avoided many other paths that came across her career and chose to be a Tester, happily and proudly.
She likes to explore and experiment with new concepts, ideas, and thoughts, which can help in performing the tasks more efficiently and bring more quality to the product.
