Understanding ‘context-driven’ testing. Interview with Paul Carvalho. Part I
Paul Carvalho, like everyone who a1qa has interviewed, is really passionate about Testing and enjoys mentoring and helping others to develop better testing skills and knowledge. His colleagues call Paul “The Quality doctor”. With over 25 years working with teams on computers, software and technology across various domains, he specializes in systems analysis, collaborative problem solving, test design and exploratory testing. During his long career Paul made his input to success of BlackBerry, AGFA, many scientific and research centers.
As a software testing coach and practitioner, Paul helps testers and teams grow and adapt to complement development efforts – to increase collaboration, effectiveness and efficiency, and to provide value to projects. He is a regular speaker at testing workshops and conferences, blogs occasionally, loves scripting with Ruby, and enjoys discovering new ways to break systems and applications.
“Have concerns about your Quality, QA, Testing or integrating with Agile? Let’s talk” – This is what Paul is proposing to do in his blog. a1qa accepted the invitation.
a1qa: Paul, during your impressive career you worked in a variety of industries, including Financial Services, Healthcare, Telecommunications, Engineering and many others. Which industry was the most challenging and demanding for more QA skills, patience and diligence?
Paul Carvalho (P.C.): About 15 years ago, I first heard the Jerry Weinberg quote “all problems are people problems.” I hadn’t met Jerry yet, and so I struggled a bit with that phrase at the time. I was rising in my career, pursuing learning from anyone and anything related to software testing and QA. For reference, getting good information and training was harder in the late ’90s than it is today.
I dived into quality assurance consulting and it was like magic. I couldn’t wait to show other testers what I learned and how powerful these new techniques were. I was working in the Healthcare industry at the time. I learned two valuable lessons while working in that company:
1. Not all testers cared to learn test techniques or think of their jobs as a profession. Blasphemy! Surely all testers would want to learn these magical, scientific thinking tools?! Alas, I was wrong.
2. The majority of the problems we encountered in getting products out the door had nothing to do with software testing techniques, processes or tools. Most of the problems came from people and relationships.
It was then that I truly understood that “QA” involves a lot more than testing, and that there were whole new areas of skills that I wanted or needed to work on beyond the test techniques that I was proud of.
I would say that the Healthcare environment was the most challenging, interpersonally complex, Regulatory rigorous and demanded more QA skills, patience and diligence than any other field I have worked in. I have a lot of respect for the professionals who continue to work in these intense environments over many years.
On a side note, I met Jerry Weinberg years later and he said to me after hearing a particular story I told: “All problems are people problems, especially the technical problems.” I now fully understand and appreciate that statement. That’s one of the reasons I like the Agile community so much – every coach I meet treats all problems as people problems. I have learned so many more new techniques and approaches for problem solving from the Agile community.
a1qa: How responsive were people in mentioned spheres to specific testing principles and requirements?
Paul Carvalho (P.C.): Different industries and technologies have different requirements for testing. I think each industry is responsive to testing principles and approaches, but I see the problem as more complex than that.
There is no “one right way” to do testing. In each situation I needed to learn what the project and customer needs were so that I could efficiently provide that information. Sometimes I would focus on exploratory testing; sometimes it might be test/check automation. Once, my main role was “Beta Test Manager” and I focused on managing a community of people worldwide to provide feedback on products that weren’t released yet. These were regular people, not testers, so it was certainly a challenge (for me) to keep the participants motivated and provide good feedback to us so we could make the products better.
In every company, I got the sense that Testing is important (in some way). The more you move from company to company, or industry to industry, the more flexible and adaptable you need to be in the types of approaches you use. I would say that moving around has helped me appreciate what “context-driven” means more than someone who has only ever worked in one place.
The first time you go into a company and try your favourite technique, tool or approach and watch it crash and burn, is very humbling. You adapt, learn and grow. You become wiser and better. Let go of your personal preferences and focus on what other people need. Challenges to specific testing principles often happen when testers refuse to let go.
Read the continuation of the interview next Tuesday.
