Author: Aakruti Shukla

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

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

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