Michael Stahl

Member for

21 years 7 months

Michael Stahl retired from Intel after 35 years career as SW Validation Architect. In that role, he defined testing strategies and work methodologies for test teams, and sometimes even got to test something himself - which he enjoys most. Michael presented papers in SIGiST Israel, STARWest, EuroStar and other international conferences, and is teaching SW Testing in the Hebrew University in Jerusalem.

Michael is an executive board member of the Israeli Test Certification Board (ITCB), holds a full Advanced ISTQB Certification and is a member of the ISO workgroup that develops the ISO 29119 international standards series.

Michael's presentations and papers are available on www.testprincipia.com.

Company

Private consultant

Job Function

Testing

Job Title

Software Validation Architect

Industry

Computer Software - SaaS

Interests

Process Improvement

Test Automation

Testing

Country

Israel

Michael Stahl

Michael Stahl is a SW Validation Architect at Intel. In this role, he defines testing strategies and work methodologies for test teams, and sometimes even gets to test something himself - which he enjoys most. Michael presented papers in SIGiST Israel, STARWest, EuroStar and other international conferences, and is teaching SW Testing in the Hebrew University in Jerusalem. Before starting his career in testing in 2000, Michael worked at Intel’s manufacturing facility in Jerusalem, Israel, as a chip-level test engineer.

Michael is an executive board member of the Israeli Test Certification Board (ITCB), holds a full Advanced ISTQB Certification, and chairs ITCB’s advisory board. Some of Michael's presentations and papers are available on www.testprincipia.com.

All Articles by Michael Stahl

All Stories by Michael Stahl

	Metamorphic Testing Rapid change and adoption of new ideas are attributes we readily assign to engineering and high-tech. What was a novelty and special last year is old news today. And yet… have you ever heard of Metamorphic Testing?
	Wish-List Ideas for Software Testing ResearchThere are many established ideas for ways to test software, but the industry is changing every day, and there's plenty of room for growth of new ideas—or challenges to traditional ones. Here are three ideas for "wish-list" research to conduct in order to shake up some of the conventional notions you may have about software testing techniques.
	How to Respond to Retest Requests without a Clear Bug FixAfter finding and reporting a bug, a tester may get this response from a developer: "Please rerun the test on the latest version of the code and check if the bug still reproduces." This seems like a rational request; just as a change can cause a bug to appear, it can also fix a bug. But is following up the responsibility of the tester or the developer? And if the bug is no longer there, how do you classify and close it?
	Improving Test Data Collection and ManagementThere is much published about the data we generate to assess product quality. There is less discussion about the data testers generate for our own use that can help us improve our work—and even less is said about recommended practices for data collection. Test data collection, management, and use all call for upfront planning and ongoing maintenance. Here's how testers can improve these practices.
	Improve Tester-Developer Relationships with Helpful FeedbackTesters and developers often have a strained relationship. Each side has a certain level of expectations as to what the other side should know and do, while there is little understanding of the constraints, conditions, and requirements that the other team has to work within. But it does not have to be this way. A little effort in giving more specific and helpful feedback can go a long way toward improving attitudes.
	Dealing with a Test Automation BottleneckThe test team uses the test automation system to execute thousands of test cases because … why not? The tests are running automatically, for free, so there is no incentive to improve test efficiency. Just run them all! But eventually, as more and more tests are added, the system becomes overloaded. Test runs are delayed and you get a bottleneck. Don't throw more money—or new systems—at the problem; do this instead.
	Use the Rejected Defect Ratio to Improve Bug ReportingThere are many metrics to measure the effectiveness of a testing team. One is the rejected defect ratio, or the number of rejected bug reports divided by the total submitted bug reports. You may think you want zero rejected bugs, but there are several reasons that’s not the case. Let's look at types of rejected bugs, see how they contribute to the rejected defect ratio, and explore the right ratio for your team.
	Simplify Continuous Operation Tests with a Periodic RebootContinuous operation tests find important bugs, partly as a result of their long operation and partly by increasing the probability of finding statistical bugs. However, CO tests have their own downsides. Mandating a periodic reset or reboot can work around these issues, as well as save time and cost for testing, reproduction, debugging, and fix verification.
	Responsibly Reporting Performance Test Results: Trends, Noise, and UncertaintyIn order for performance test results to have value, you should report them in context. There are two main considerations: How do these compare to previous results? And how can we provide early reports on performance while emphasizing that these are preliminary results that may change significantly as we progress? Here are some ideas for responsible reporting.
	A Better Way of Reporting Performance Test ResultsReporting the results of functional tests is relatively simple because these tests have a clear pass or fail outcome. Reporting the results of performance testing is much more nuanced, and there are many ways of displaying these values—but Michael Stahl felt none of these ways was particularly effective. He proposes a reporting method that makes performance test results easy to read at a glance.
	How Much of Debugging Software Is a Tester’s Responsibility?Everyone knows a tester's job is to help improve the quality of the software under test. But it gets a little murky when you try to define the boundary between testing and debugging. There's no clear delineation: Some testers would state how to reproduce the bug, write the report, and hand it off, while others learn the code, find the root cause, and even create builds to fix the bugs. How much is useful, and how much is too much?
	Ethics in Software TestingWhen we speak of “test ethics,” the given examples usually are trivial dilemmas. Do we avoid reporting a bug? Do we report that testing is progressing as planned, even though it’s definitely late? These questions are kids stuff: easy because the situation is so black-and-white. But life will present you with complicated cases where the answer is not that obvious.
	When Testers Should Consider a Bug a DuplicateWhen can a bug report be considered redundant because it is already reported in the bug management system? If you ask the developers, if two bugs are caused by the same mistake in the code, it’s enough to report one of them. But Michael Stahl has good arguments from a tester's perspective about why it's better to err on the side of over-reporting bugs.
	Using Bug Taxonomy to Design Better Software TestsIn software testing, bug taxonomy involves defining feature categories and collecting lists of possible bugs in each category. These lists can be used to give inexperienced testers some starting points, to help experienced testers brainstorm new ideas, and to evaluate the completeness of a test case. Using an existing bug taxonomy can be useful, but creating your own is even better.
	The Unspoken Requirement: Testing for ConsistencyIt's easy to see that style consistency is important when discussing the user interface. But there are other areas where being consistent is just as important, even though they are not as visible. Consistency is one of the quality attributes of a product—any product—even if it is not stated clearly in the requirements documents, and testers have a responsibility to check for it.
	5 Ways to Overcome Your Hatred of Test DocumentationWriting test documents is a good practice to have: It enforces an orderly thought process, explains what you’re planning, and improves the test strategy. But knowing it's useful doesn't make it any more fun. Michael Stahl knows this, so he has five tips to help make the idea of test documentation a little easier—or at least a little more difficult to hate.
	Exit Criteria, Software Quality, and Gut FeelingsBug counts and trends don't cover all the quality aspects of a product. A good exit criteria list provides an orderly list of attributes that research and experience showed to have impact on product quality, so you can monitor the product quality at any given time and forecast the expected status at release. That's how you improve your product.
	The Secret to Change Management: Creating a New Tradition When we try to implement new processes, there is often resistance from the team. People get so used to their typical habits that it doesn't occur to them that there could be a better way to do things. To get buy-in from everyone, you need to understand the current traditions, then think about how you can set an example to start making the processes a new tradition.
	Less Is More: Picking Your Test Automation Language It's a classic dispute: Two test automation engineers can't agree on which programming language to use. In some contexts, the strong points of a certain language definitively make it the right choice, but what do you do when either language could work well for a project? That's when it becomes a managerial decision.
	The Homegrown Tools Syndrome Test management is a generic process, yet much effort goes into developing tools in house to do this work. Learn the reasons for this phenomenon and suggestions for avoiding it.