Author: Aakruti Shukla

Interviewing our FailQonf Speaker James Bach | Failure Stories, Mentoring, Reading

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 for 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 James Bach a few questions about Failures, Lessons learned, and a part of their amazing work in the Industry. We thank James Bach for their time to answer these, and for sharing a part of their life with us.

About James Bach: James is a founder of the Context-Driven school of testing. He created and teaches the Rapid Software Testing methodology, and has written two books: Lessons Learned in Software Testing (with Cem Kaner and Bret Pettichord) and a book about succeeding without going to a school, called Secrets of a Buccaneer-Scholar.

LinkedIn | Twitter


 

Aakruti: You recently completed 34 Years in Testing, from your experience what are the top 3-5 weaknesses of Testers which still exist?

James:

  • Poor grasp of the science behind testing
  • Lack of assertiveness and too much willingness to do bad work
  • Inability to explain testing to non-testers
  • Not understanding their own testing process

 

Aakruti: If you had to start your Testing career today, what would you do differently compared to most of the Testers starting their Career?
James: I imagine I would do the same thing I did when I started my career 34 years ago—

Read every book on testing and then re-think and re-invent testing for myself.


 

Aakruti: How would you suggest the Testers to find their Mentor(s) today? Rather than where to find, what should be the process to identify the right mentor?
James: Read blogs and watch videos. Attend conferences. Contact the people who inspire you. Some of them will respond.


 

Aakruti: Have there been any failures that made your professional life better? Any lessons learned from the same.
James: There have been many. Here’s one: I failed to get a job as a “computer operator” at a local insurance office in Chico, CA. I never found out why. It was painful because I really needed the money.

Anyway, two weeks later I got hired at Apple Computer, which was my dream job.

Here’s the lesson:

Hiring is a personal matter. Never obsess about why one employer doesn’t want you. Just move on to the one who does.


 

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?
James: Sure. Throughout my career, I have seen people who wrote loads of useless test cases and piles of bad test documentation. Because they’ve already tried that, I never felt that I needed to do it myself.


 

Aakruti: You are an avid Reader, what different methods would you suggest for reading quickly yet getting the most out of the reading?
James: Learn to scout a book: skim it quickly and summarize it to get a sense of what’s in it. I practiced doing this with my brother and made a video about it called “competitive swashbooking.” I think it’s still on Youtube.

When I read a book deeply, I read slowly. But the scouting process is fast.


 

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?
James: I’ve been married twice. My first marriage lasted five years. When it ended I decided to learn and improve from that experience so that my next marriage would last longer. The key lesson I gleaned is that my wife had been afraid to tell me her feelings because she was worried I would stop loving her. I realized that my dominating personality was actually leading me to have less control and security than if I made sure to listen and support what she wanted.
A year later, I met someone new, got married again, and this month will be our 30th anniversary. That is SIX times the duration of my first try at matehood. So, that’s pretty good.


 

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.

LinkedIn | Twitter

00
Interviewing our FailQonf Speaker Anne-Marie Charrett | Failure Stories, Emergent Quality

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 Anne-Marie Charrett a few questions about Failures, Lessons learned, and a part of their amazing work in the Industry. We thank Anne-Marie Charrett for their time to answer these, and for sharing a part of their life with us.

About Anne-Marie Charrett: Anne-Marie excels at creating spaces where quality thrives. As co-founder of Testing Times and its principal quality engineer, Anne-Marie is the lead advocate on quality engineering and how to navigate change and keep quality in the minds of all. Standing her in good stead is her years of experience as Head of Engineering at Tyro Payment, Quality Engineering Consultant, and Test Automation Engineer. Anne-Marie’s technical background as an Electronics Engineer has enabled her to speak to both technical and product expertise. Anne-Marie is an international keynoter having spoken at multiple international conferences. You can read more about her ideas on her blog https://mavericktester.com and/or catch some of her thoughts on Twitter at charrett.

Linkedin | Twitter


Aakruti:
You talked about “Emergent Quality” in one of your talk. Can you give a brief idea of it?
Anne-Marie: Quality is not something that you create, but it emerges from many factors, including practices, tools, and skills. In today’s contemporary engineering practices, it makes better sense to focus on these, than focusing on the product as only one system we deploy.
You can read more about the emergent property here https://mavericktester.com/2018/12/04/emergent-quality/

 

Aakruti: If you recall your first professional failure, what was it and how did you respond to it?
Anne-Marie: I remember failing to prevent a release from being shipped even though I had discovered a significant design flaw in the system. It was an early lesson on how as software testers we can be given the responsibility to ensure quality but not the autonomy to make that happen. It was a great early lesson for me to focus on providing value as opposed to making a commitment to something I had no control of.


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?
Anne-Marie: Can you ever know if you have ‘avoided failure’?. Say you try and avoid something but end up never experiencing something that you come to regret. Wouldn’t that be a failure too? I feel life is too complex to apply one person’s lesson onto your own and hope that you will avoid failure. Having said that, do I learn from other people’s experiences? Absolutely!

 

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?
Anne-Marie: I’ve had some real kick in the gut failures during my career. It’s the failures that hurt the most that have inevitably provided me with the most to learn from. It doesn’t feel like that at the time though!
Rather than failure, I now think pivot. Life dishes out what it dishes out. How you respond to that point in time is what changes a possibly negative experience, to something that is quite positive and useful. It takes reframing the situation, looking at it through a different lens. But it’s a useful skill to learn.

 

Aakruti: You amazingly talked about the ‘Badass Tester’. How can one be a tester Badass in a good way?
Anne-Marie: The title of badass was given to me by Keith Klain. It wasn’t something I decided I was. I changed that title to badass Marshmallow, as I feel that better reflects me, opinionated, and really a total softy. A badass is not a set of behaviours. We can both be badass Tester’s and yet behave in very different ways. For me, authenticity and being congruent with myself are classic badass traits.


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.

LinkedIn | Twitter

00
Interviewing our FailQonf Speaker Dorothy Graham | Failure Stories, Test Automation, Metrics

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 Dorothy Graham a few questions about Failures, Lessons learned, and a part of their amazing work in the Industry. We thank Dorothy Graham for their time to answer these and share a part of their life with us.

About Dorothy Graham: Dorothy Graham has worked as an independent consultant and trainer in software testing and test automation for 50 years, and is co-author of 5 books: Software Inspection, Software Test Automation, Foundations of Software Testing, Experiences of Test Automation and A Journey Through Test Automation Patterns (see TestAutomationPatterns.org). She has been a popular and entertaining speaker at hundreds of conferences and events over the years. Dot has been on the boards of conferences and publications in software testing, including programme chair for EuroStar (twice). She was a founder member of the ISEB Software Testing Board and helped develop the first ISTQB Foundation Syllabus. She was awarded the European Excellence Award in Software Testing in 1999 and the first ISTQB Excellence Award in 2012. Now retired, she enjoys singing in choirs and small groups.

Linkedin | Twitter

 

Aakruti: In your professional experience, out of the different test automation approaches, which ones
did you found it to be the worst?
Dorothy: In our book Software Test Automation, we talk about five different levels of scripting, and the first
and worst is capture-replay, which gives you a linear script with hard-coded values. This approach
makes your automation tightly tied to the tool you are using and gives automation that is brittle
and expensive and hard or impossible to maintain.
If you are wondering, the other scripting techniques are structured scripts, shared scripts, data-
driven scripts and keyword-driven scripts. Levels of abstraction are essential for good automation;
the tool-specific aspects should be confined to only the minimum essential interface modules, the
testware should be designed according to good software design practices to be modular and easy
to maintain.
It is also important to pay attention to the user interface of the automation. If you make an easy-
to-use interface so that testers can easily write and run automated tests, even without knowing
the technical details of the tool, this opens the automation to a much wider set of automation
users, and will give more benefit.
Some of these are summarised in the Design Issue DESIGN DEPENDENCY, in the wiki
TestAutomationPatterns.org.
So the worst approach is capture-replay and automation closely tied to a particular tool; use good
testware architecture, with levels of abstraction, to avoid this.

 

Aakruti: In your experience and if sharable, which is the biggest blunder that you faced in the test
automation?
Dorothy: In my presentation for the conference, I talk about several blunders in test automation, and the
most significant one is that tools are perceived to do testing. Although there are aspects of some
parts of testing that tools can do well, no tool ever does all of the software testing – this is the biggest
blunder, and lies at the root of many others. Testing tools only do what they are programmed to
do; they do not assess what the risks are and what should be tested, they never think of
significant new things while running a test, but they are very fast. But speed is definitely not the
same as quality – for software testing as for anything else.

 

Aakruti: What metrics indicate that Automation is going wrong and/or right ways?
Dorothy: Metrics for either testing or automation should be related to the objectives of the activities. If the
goal of automation is to run tests more quickly, then time to run could be measured. If the goal is
to run them more often, then the number of times they are run would show that. If the goal is to
test more of the software, then coverage could be used.
But it is also important to measure aspects of the automation itself, such as maintainability,
flexibility, robustness, reliability etc. For example, maintainability could be measured by the
average effort to update the tests when the software changes, and this should be going down over
time. These and other measures are discussed in Chapter 8 of the Software Test Automation book,
and examples of measuring automation are also given in the Experiences of Test Automation book.
Mark Fewster of Grove Software Testing has an excellent presentation about automation health
that includes useful measures for automation.

 

Aakruti: If you recall your first professional failure, what was it and how did you respond to it?
Dorothy: My first job was to write a test execution and a test comparison programme (they weren’t called
“tools” back in the 1970s!). I spent around two years at Bell Labs working mainly on these two
programs, written in Fortran. I thought I had done a reasonable job, but when I returned for a
visit to the company a few months after I had left, I was shocked to find out that no one was using
my programs! In fact, I think what I spent two years writing was probably some of the world’s first
shelfware.
I had not had any education or training in software design techniques at this point, and my code
was pure spaghetti. I even had a huge diagram of all the links between subroutines, which was
very spaghetti-like. In my next job, I learned about “structured programming”, which is about
encapsulation and abstraction – the sort of thing that was later called “object-oriented” – basically
just good design for software. Because of my earlier failure, I realised the importance of good
design – and that this also applies to automation code. In recent years, I have seen the
importance of well-structured automation systems, for long-lasting benefit.

 

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?
Dorothy: There is one failure story that I was allowed to share, provided the company was kept anonymous.
I had previously heard about how successful the company’s inspection programme was – they
were finding lots of bugs very early and saving the company lots of money. I was very impressed
when I heard the story, as they seemed to be doing things really well. There was a strong
champion who was involved with all of the inspections, they protected the authors but also made it
an enjoyable process, and they measured the benefits, which were significant (such as halved system
test time, and positive feedback from customers about quality).
Imagine my surprise to find out only a few years later that inspections had been completely
abandoned! I really wanted to know how this had happened, and I got permission to investigate,
where I discovered some significant factors: a reorganisation meant that the champion was no
longer involved, moderator’s time was now chargeable. the training was skimped or abandoned, and
managers had not known the value of what they had killed (or had allowed dying). However, I
also found out that inspections had gone “underground” – those who had realised their value were
secretly organising them with trusted colleagues as moderators.
Many of the lessons learned from this failure were already things that the book Software
Inspection recommends, but this company didn’t follow them – this gave me confidence about the
advice in our book. But it also highlighted how fragile good practices can be, especially when the
value is not communication (well enough) to high-level managers.


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.

LinkedIn | Twitter

00
Interviewing our FailQonf Speaker Peter Walen | Failure Stories, Deep-Dive Testing, Pre-release Testing

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).

Linkedin | Twitter


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.

LinkedIn | Twitter

00
X