Comments on: Schools of software testing http://www.satisfice.com/kaner/?p=15 On the craft and community of software testing Thu, 09 Sep 2010 01:31:44 +0000 http://wordpress.org/?v=2.7 hourly 1 By: darreldamon http://www.satisfice.com/kaner/?p=15&cpage=1#comment-51 darreldamon Wed, 03 Jan 2007 12:53:33 +0000 http://www.satisfice.com/kaner/?p=15#comment-51 I'm not entirely certain that what you initially describe as "schools" of testing are that at all. Domain driven Stress driven Specification driven Risk driven Random / statistical Function Regression Scenario / use case / transaction flow User testing Exploratory To me, these are techniques, or tools. I use whatever tool or technique works best for the situation I am in. To put it in another world, I don't use a screwdriver to pound a nail. I have a toolbox with an assortment of tools that are purpose built for a certain task. Using another tool in it's place is less efficient, but it CAN get the job done. I can pound a nail with a screwdriver, but it will take me much longer and I will be more frustrated at the end of the process than if I had used a hammer. After I read this, I came away more confused than ever. I'm not sure where you are trying to go, unless the entire purpose of the blog is to open up the discussion and get people talking. I have to agree with the one essential theme that I came away with - that as software testing professionals, our discipline is not yet mature, as evidenced by the many disagreements over "commonly understood" terms. If the purpose is to try and resolve that issue, then I am with you. <em>As I mentioned in this post, I eventually discarded this as a useful way of characterizing different cognitive approaches to testing, in favor of the "schools" approach. Part of the reason I gave up is because it was so easy for a casual reader to misunderstand. </em> <em>The assertion is not that anyone who uses a given technique is cognitively bound by that technique. </em> <em>The assertion is that stunningly many people do pick one technique and envision all of testing around that. And that even in groups whose individual members enthusiastically identify a wide range of testing techniques, the group remarkably often locks down on one or two techniques. </em> <em>-- Cem Kaner </em> I’m not entirely certain that what you initially describe as “schools” of testing are that at all.

Domain driven
Stress driven
Specification driven
Risk driven
Random / statistical
Function
Regression
Scenario / use case / transaction flow
User testing
Exploratory

To me, these are techniques, or tools. I use whatever tool or technique works best for the situation I am in. To put it in another world, I don’t use a screwdriver to pound a nail. I have a toolbox with an assortment of tools that are purpose built for a certain task. Using another tool in it’s place is less efficient, but it CAN get the job done. I can pound a nail with a screwdriver, but it will take me much longer and I will be more frustrated at the end of the process than if I had used a hammer.

After I read this, I came away more confused than ever. I’m not sure where you are trying to go, unless the entire purpose of the blog is to open up the discussion and get people talking. I have to agree with the one essential theme that I came away with - that as software testing professionals, our discipline is not yet mature, as evidenced by the many disagreements over “commonly understood” terms. If the purpose is to try and resolve that issue, then I am with you.

As I mentioned in this post, I eventually discarded this as a useful way of characterizing different cognitive approaches to testing, in favor of the “schools” approach. Part of the reason I gave up is because it was so easy for a casual reader to misunderstand.

The assertion is not that anyone who uses a given technique is cognitively bound by that technique.

The assertion is that stunningly many people do pick one technique and envision all of testing around that. And that even in groups whose individual members enthusiastically identify a wide range of testing techniques, the group remarkably often locks down on one or two techniques.

– Cem Kaner

]]> By: doug.hoffman http://www.satisfice.com/kaner/?p=15&cpage=1#comment-47 doug.hoffman Sat, 30 Dec 2006 02:08:02 +0000 http://www.satisfice.com/kaner/?p=15#comment-47 I consider myself a member of the context school because I've actively practiced most software testing techniques as I found appropriate in diferent contexts. However, I'm unsure about the school concept because [I think] I am a member of several schools. I believe I've been able to successfully apply different test techniques in diverse situations by adopting the mindset that I believe represents what's needed to be successful. Rather than being just context driven, I have approached the situations from the viewpoint of the organizations' culture and mindset. Each mindset leads me to behave and think as a member of a different school. I've sometimes described myself as a chameleon - able to adapt and blend into various organizations' cultures. Maybe it's more like my being a method actor; getting into a part by really becoming the character the script calls for. The discussions I've seen about the schools have usually been exclusionary - a person belongs to one or another school and their behavior is predictable based on that. I don't think that exclusion is necessary or helpful. My view is that different techniques, paradigms, or schools are more like languages than religions. A language is a mechanism for organizing and expressing ideas. A religion is a set of deep rooted beliefs. When a person becomes fluent in a language it requires much more than knowing syntax and having a large vocabulary. A person becomes fluent by thinking in that language and understanding the culture it expresses. If a person is translating to what they find natural, they aren't yet fluent. Once a person becomes fluent, it's natural to think and speak in that language and culture. [Programming languages like JAVA, COBOL, LISP, and SMALLTALK are very different languages and expert programmers use different thought processes for each.] I consider myself a member of the context school because I’ve actively practiced most software testing techniques as I found appropriate in diferent contexts. However, I’m unsure about the school concept because [I think] I am a member of several schools. I believe I’ve been able to successfully apply different test techniques in diverse situations by adopting the mindset that I believe represents what’s needed to be successful. Rather than being just context driven, I have approached the situations from the viewpoint of the organizations’ culture and mindset. Each mindset leads me to behave and think as a member of a different school. I’ve sometimes described myself as a chameleon - able to adapt and blend into various organizations’ cultures. Maybe it’s more like my being a method actor; getting into a part by really becoming the character the script calls for.

The discussions I’ve seen about the schools have usually been exclusionary - a person belongs to one or another school and their behavior is predictable based on that. I don’t think that exclusion is necessary or helpful. My view is that different techniques, paradigms, or schools are more like languages than religions. A language is a mechanism for organizing and expressing ideas. A religion is a set of deep rooted beliefs. When a person becomes fluent in a language it requires much more than knowing syntax and having a large vocabulary. A person becomes fluent by thinking in that language and understanding the culture it expresses. If a person is translating to what they find natural, they aren’t yet fluent. Once a person becomes fluent, it’s natural to think and speak in that language and culture. [Programming languages like JAVA, COBOL, LISP, and SMALLTALK are very different languages and expert programmers use different thought processes for each.]

]]> By: Ainars Galvans http://www.satisfice.com/kaner/?p=15&cpage=1#comment-45 Ainars Galvans Thu, 28 Dec 2006 11:52:31 +0000 http://www.satisfice.com/kaner/?p=15#comment-45 I would like stress out that there is other benefits in agreeing of the “schools� notion besides helping communicate leaders and boost the community progress (for example doing one-school-conferences). Even in a single company – if it large enough (as it is in my case) – there are different leaders (test team leaders, project managers, BA leaders, etc.). The way they organize testing process as most appropriate maps perfectly with what you describe by the “schools� notion. There are people (quite powerful ones) who see Testing exactly as process to “translate the specification to powerful test cases, automate the tests, run them as regression tests, and report metrics based on these runs.“ I’m lucky to be independent enough from them and follow a different process; provide different training/leadership/feedback to my team. I’ve changed projects in past. I recall twice joining a project where everything was set up already and everyone worked according one of the “schools� (different from my previous experience). Despite the fact that I joined as team lead/manager, I decided better to change MY mind. This experience I’ve tried to cover in my ICSTEST (2005) talk about testing skills, but I don’t think anyone really realized what I’m talking about. More over – my conclusion back then was: the school result from project context a lot. Specifically unit under test: either it is legacy system with a huge functionality, pilots/custom projects or a new IT solution for a huge company like telco. So when you are on either side in hiring process (hiring a new tester, applying a new job or changing projects) – one of the key factors are to make sure employee vision of testing fits the project or he is willing to change it. And never be upset if you are not hired although you are an expert tester – maybe the project simply needs different school proponent. I would like stress out that there is other benefits in agreeing of the “schools� notion besides helping communicate leaders and boost the community progress (for example doing one-school-conferences). Even in a single company – if it large enough (as it is in my case) – there are different leaders (test team leaders, project managers, BA leaders, etc.). The way they organize testing process as most appropriate maps perfectly with what you describe by the “schools� notion. There are people (quite powerful ones) who see Testing exactly as process to “translate the specification to powerful test cases, automate the tests, run them as regression tests, and report metrics based on these runs.“ I’m lucky to be independent enough from them and follow a different process; provide different training/leadership/feedback to my team.
I’ve changed projects in past. I recall twice joining a project where everything was set up already and everyone worked according one of the “schools� (different from my previous experience). Despite the fact that I joined as team lead/manager, I decided better to change MY mind. This experience I’ve tried to cover in my ICSTEST (2005) talk about testing skills, but I don’t think anyone really realized what I’m talking about. More over – my conclusion back then was: the school result from project context a lot. Specifically unit under test: either it is legacy system with a huge functionality, pilots/custom projects or a new IT solution for a huge company like telco.
So when you are on either side in hiring process (hiring a new tester, applying a new job or changing projects) – one of the key factors are to make sure employee vision of testing fits the project or he is willing to change it. And never be upset if you are not hired although you are an expert tester – maybe the project simply needs different school proponent.

]]>