Speakers’ Spotlight: Michael Stahl
Let us introduce you with our speaker Michael Stahl, SW Validation Architect who passionately works as a tester for Intel.
Who is Michael Stahl?
I am from Israel and I live in Jerusalem, where I lived most of my life. I am working for Intel for the last 28 years; I worked for ten years in Fab8 – testing 8086, 186, 286, 386 and 486 among other chips. I then moved to the software world but stayed a tester. Currently I am a SW Validation Architect in the team that develops Intel Converged Security Engine.
I am a Tester by Choice. I am not in development, architecture or other aspects of SW development, because I prefer to test. I enjoy the domain, the character of the people involved and the wide scope testing provides. I am not a manager; this is a career decision I made many years ago, after managing a small group of people and hating that it took me away from being involved with technology. Luckily, I work for a company where the technical ladder is not just a phrase, so I get to do what I love.
At soul, I am also a teacher. I love to write about testing subjects, love to conduct training and people tell me I am good at it.
Work takes most of my time, but there is some time left for travel (to Ireland, for example), preferably with Noomi, my wife and my four children. I don’t generally cook, but I do like to bake Challa – a traditional type of bread.
1. What is your personal definition of QA and testing in the light of today’s?
All my career I tested embedded software and the essence of testing has not really changed for me personally through these years. Of course I experienced a few “aha” moments that changed some of my perspectives, but overall the definition stayed the same for me: the tester’s role is to bring the customer’s voice to the table; to look at the system in a holistic way and be efficient in providing coverage within a reasonable time and budget. The same can be said about QA as a wider subject: the basic principles that were known 20, 30 or even more years ago, are still mostly valid. What I do see is increased maturity and efficiency: If 18 years ago hardly any team had static analysis; or CI; or orderly code coverage… this is now the norm. New tools are making our job more efficient and generally there is more automation effort. It’s both a matter of maturity of tools and maturity of the processes.
2. How was the last 12 months? What worked well, what didn’t move as quickly as you would have liked?
In the last 12 months I was mainly involved in defining SW developments methodologies for compliance with the automotive industry requirements. We defined two high level guidelines:
- Don’t reinvent the whole development process; define what augmentation are needed to what we already have. This was the easy part.
- Define the processes in a language that the engineers understand, so they can execute them without having to have a Functional Safety engineer at hand to ask for clarification all the time. This was a difficult effort which is still on going. You need to translate ISO and IEC standards’ language into human-readable actions…
About two months ago I moved to a team that validates Intel’s Converged Security Engine. I am leading the methodologies forum, defining test strategy for one of the new projects and consulting on various test related challenges.
3. Where do you see yourself in the coming years? What are your career aspirations?
Sipping Mai Tai on the beach, of course.
Seriously: One of the main takeaways from my sojourn to Automotive processes was that I don’t want to get too far from Validation. My first task in the automotive field was related to validation and verification processes and that felt natural. But when it started diverting too much into QA management, I felt it’s time to return to a validation team.
So I think this is not going to change much. The difference from previous teams I worked with for the last 8 years is that my current team is a large team, which means there is room – and a need – for organized methodologies efforts. If this works well – I will be content.
Eventually, when I retire, I am thinking of teaching in high school or college.
4. What will you be talking about at Quest for Quality?
Before joining the SW development world, I worked for 10 years in an Intel fab. These two worlds have very different attitude towards quality and quality processes. The fab “lives” on processes and everyone adheres to them; the development world has processes, but many consider them as recommendations that don’t always apply. So implementing new methodology or process in a fab is relatively easy; doing it in development is like pushing a rope, with the negative impact of having to work much harder to achieve high quality. In my talk I review the reasons for this difference and propose some directions that may help move the development toward better acceptance of processes.
5. What inspired you to attend?
I attended a good number of small and large conferences and while the large conferences offer a variety of choices, the small ones are where you are more likely to meet people and have a chance to learn something from them. Add to this the chance to see Ireland, which I visited twice for work but never had time to explore.
6. Which influencers and websites do you follow to keep up to date with the latest developments?
I used to read a lot on Stickyminds and I published there a few articles in the last few years. So that website was influential in a sense. I occasionally visit the Israeli Test & QA forum on Facebook, but in truth, I prefer reading books. I do make an effort to read at least one new thing every week. A paper; an explanation of part of our product I am not well familiar with or a chapter in a book.
Going back in time, the book that influenced me most was the first book I read on software testing: “Testing Computer Software” – a classic by Kaner, Falk and Nguyen. It was the first time I realized SW testing is a profession and an option for a career. It had profound influence on how I approach testing and how I teach others about testing.
In the last few years I was learning new technologies (computer vision; security) and had little time to read testing texts; add to this the fact that there is really no solid book that I am aware of about testing computer vision, machine learning and AI applications. I suspect each company thinks that what they do is so unique that it’s part of their IP. So there is a limited amount of published text. There are many academic papers, but if they mention testing at all it is not product-level testing. It’s algorithms testing.
Lately I read Chris Hobbs book “Embedded Software Development for Safety-critical Systems” – which is a proof that literature about process and about safety standards does not HAVE to be boring.
7. How can people find out more about what you are working on?
Start by attending my lecture…
To see other presentations and papers, visit my website: www.testprincipia.com .
If you read Hebrew… My “Looking for Trouble” column is published quarterly in a Hebrew language test magazine: Testing World. I translated many of the columns and you can find them on Stickyminds.com together with some other articles.
8. Anything else you would like to add?
I mentioned that I like to teach. For the last few years I taught an introductory course in SW testing, in the Hebrew University Computer science faculty. Until now, the course was fairly easy – it IS an introductory course after all. I am now rethinking this approach; I think it may be doing injustice to the profession. By having the course easy to pass, the message is that software testing is easy; not much removed from applying common sense to a problem, therefore not a worthy career path to choose. The next time around I plan to make the course significantly different, with home assignment that will be intellectually and technologically challenging – which is what we actually encounter in our work.