In testing text books you can read that compatibility testing should be performed after the functionality testing and bug fixing is completed. I guess the reason is that you don’t want to mix these categories, but hey, what a waste of resources. My suggestion is to perform the compatibility testing at the same time as […]
I used to be a bit skeptic towards the word “heuristic”. It seemed needlessly advanced, and things are possible to explain in other words. But when I read Gigerenzer’s Gut Feelings about how to catch a flying ball, it all came together. For software testing, which can’t be complete, is dependent on many factors, with […]
This is a follow-up from Working with the testing debt – part 1 [1]. The reason for the clarification is that you so easily come up with a tip without a context or example. Tip 2: Focus on what adds value to developers, business analysers and other stakeholders. If you do not know what they […]
This began as an answer to Rikard’s post http://thetesteye.com/blog/2011/06/a-word-of-caution/ where the discussion on “traditional testing” came up. I often hear comparisons with our “industry” and the Automotive industry. In that context, you could say that “traditional testing” corresponds to the methods and practices that are applied in line production of large car companies. And the […]
If you are a faithful reader of this blog, you have probably read some challenges of established ways of testing. I write stuff like “anyone can do non-functional testing”, “look at the whole picture”, “test coverage is messing things up”, “you can skip all testing techniques”, “requirements are covered elsewhere, so focus on what’s truly […]