Till now, whatever I have published mostly consisted of consolidation of what different test practitioners have expressed on the web or what they communicated to me via email. It’s my turn now. Since the beginning of this series of posts on Schools of testing, I have been pinging myself, about my views. Today, I will compile my own thoughts and publish them. To see the overall picture, I suggest that you read this series from the beginning and then sit back and think, “What do you think about the concept?”

Just one thing more before I start putting my views. The title of this post was originally meant to be “My Final Thoughts” meaning ‘What I finally think about schools of testing, as of now’. For me, opinion about anything, whatsoever, is a dynamic thing. Opinion is a function of what you already know and the time and thought process that you employ in careful analysis of the subject with your current knowledge. So, as you explore more and as you tend to spend more time to think about anything, your opinion might drastically change. We never know what the next moment might bring for us. So, I am not a man of opinion, opinion is the outcome of my current knowledge and the time I spare to think about it. From Pradeep’s comments for my previous post, I found that the title ‘My Final thoughts’ can be taken in some other manner, which gives some wrong indications about me and my attitude. So, I changed the title to ‘My Thoughts’. All this is to say that whatever I express here is as per my current understanding, so feel free to share your views and comments. If you can convince me, I can change my opinion about anything and everything.

Below are excerpts from whatever I jotted down, while I was thinking about Schools of Testing:

I. No idea is good or bad. It’s just that the perception about it varies from person to person. The idea which forced so many people to think, express and fight, can not be a forgettable idea. It has already left its mark in the amount of debate it created. So, I personally feel that it is good that James Bach, Cem Kaner and Bret Pettichord came up with this idea. It helped me to think about testing in new ways. I have given a lot of thought about how I think about testing, and how I have practiced it so far. To my surprise, I could observe a lot of variations. Some of the times, while testing, what I implemented was what I thought and sometimes it was altogether different. I analyzed the reasons and had some interesting observations. The Way I think and The Way I Test are two separate aspects and now it makes sense to me, that I think about them separately, trying to strike a balance between the two and trying to implement The Way I Think in The Way I Test. I foresee that given all the constraints (as discussed in further points), even if I partially succeed in this; still it gives a sense of achievement.

II. The idea of schools is not divisive, but I have seen that it did create a sort of division. What this means is that though the idea by its definition does not advocate one set of testers disregarding other testers, it just tries to categorize them, somehow it did! So, theoretically an otherwise innocent idea, made so many people fight over the topic of software testing, in not so healthy ways. In my opinion the debate could have been carried on, in a much better way, but it’s human to behave in this manner. Humans tend to fight as they feel belongingness to a particular sect/religion/caste. Humans want something to belong to. So, whenever some categorization is done, in the long run, it turns out into harsh discussions amongst those who belong to different categories. I am sure that you will agree that no one created a religion to create fights, but sadly it did – rather we humans unknowingly turned a sacred thing into a fighting platform. If you ask me, this makes me think that the basic purpose of the concept is lost. It was institutionalized for a better debate and it caused a debate in its worst form. I guess the idea has not been sold properly. OR it was advocated for something more than it should have originally meant. Schools of Testing is a good way to think about different ways in which a testing project can be carried out, and not about different kinds of testers. I do not think a concept is more important than harmony and mutual respect in testing community. So, even this concept should be considered in the light of the present stand of complete testing community for it and then should be refined. I believe that it’s a good concept, but to make it reach more people, to make it more acceptable to all, it needs to be reworked. Rework does not mean creating more schools; rework should strike the conditions it imposes on someone who wants to accept it.

III. The concept of Schools of testing was devised intelligently, but then put into too many conditions. Every person, in this industry, due to one or the other reason, does not have all the freedom to choose what he feels good. In today’s industry, every job requirement comes with so many conditions that mostly a person who is recruited is only a partial fit. Similarly for a professional, whatever place he chooses to work, is only a partial fit. Inside an organization, what project one gets, what team he has to work with, is normally not a choice but a requirement that he is pushed into. Reasons might be enumerable, varying from one person to other and one organization to other. Added to that when the authors of several of the best books on testing, stand as a close group and say, we are from X school, we will support only the community of Xs, it comes as a huge shock to the testers all over the world, who respect them, who read their books, who learn from them, but are not comfortable with schools of testing concept. I am one of them. I am not against the concept of schools, but I am not comfortable with all aspects of it and even with the aftermath it has created. So, if I do not agree to some base points of the concept, does it mean that I do not belong to the community to which James Bach, Cem Kaner, Bret Pettichord and other big names in the testing industry belong? When I buy their books, when I read their literature on the web, I never thought that they and I do not belong to one common root. I have always thought that we all belong to the bigger root – The Testing Community. So, because I want to get associated with them, as I love to read their literature, should I be emotionally forced to say that I agree to the schools of testing concept? I am sure, talking reasonably, this should not be true. When James Bach says that he want to spend time only for the Context-Driven testing community, I feel it is a huge loss to a large number of testers around the globe, who do not call themselves context-driven testers or do not agree with the concept of division based on schools of testing.

IV. I am a context-driven thinker (and I still feel that the term context-driven is redundant, the term “thinker” implicitly conveys evaluation of context) Please note that I have typed thinker and not tester. Whenever I start with testing a product/application, I think about the present context and possibly what is good for it – how much documentation, how much automation, how much process-implementation, what should be the approach, will some earlier practice be helpful etc. So, I think in context of the project. I tend to suggest this as well to the team and to my reporting manager. Now, depending upon the level of authority I have, I might be able to execute what I thought or at the worst all my ideas can be scrapped. I will have to do that testing as is suggested to me by the person who has authority. So, if as per schools division I am from school X and the person with authority is in school Y, and I do the testing in the Y-ways, then am I still an X-school student? It means, for a good number of years, I can keep practicing Y, and keep thinking X. What’s the whole fun? I should better learn the Y-ways to do my job properly; otherwise I will turn out to be a non-performer. Under all probability I will see a mix of X and Y in my way of working, even when I reach a position with authority. The proponents of the schools say – You do not choose a school, the way you test tells the school to which you belong. I disagree by saying that the way a person tests and the way a person thinks might vary based on the situation (as mentioned in the above example). One open question. Now, do you define a school based on Way One Thinks or the Way One Tests?

V. I do not belong to any school. For thinking, I think context-driven. For testing, I adapt.If you still stress that I do not have choice, then I have got two questions. Will the Context Driven School reject me, because I do not agree to some of their principles? Will the other schools reject me because I am a context-driven thinker? What I mean by these questions is that Schools of Testing concept is a good way to make one understand that in the current project, into what category of testing, he falls into, but using it to label him as an net tester, is something which will not be acceptable to many.

VI. I believe in project-based predominant-school concept: I think that at a particular point of time, a tester predominantly exhibits one school of testing. The dominant part might be his organization’s testing style (or his manger’s way), it might be his own way of testing (if he has the authority or freedom to do it) or it might be something imposed because of client, and the less dominant part might again be some suggestions from peers/client/manager, his own insight (in case his way is not the dominant one) or something else. In the next organization or in the next project, things might altogether change. So, for such a situation, schools of testing act more as schools of thinking for a tester and schools of testing for a project as a whole. Now the way one thinks might remain constant throughout his career but the projects are ever changing. So, schools of testing helps seeing a particular project being executed as exhibiting a particular school. For a tester, it just means that he will be thinking throughout the project, what changes he could have brought if it had been done in his way. So, the way a tester is conducting testing does not give much information about his so-called school, the way he thinks does.

VII. Context Driven is not a school, rather the desirable way of testing I had posted on this aspect as a separate post – Is Context Driven a Meta-school?. James Bach (as quoted in that post) clearly states that it is not a meta school. I being, a context-driven thinker, believe that a tester by definition should think in the context of a situation and then test. So, being context-driven means assessing the context and then evaluating what might be the best fit. This does not make it a separate school. Being context-driven is much more than belonging to a single school; it is the way every tester should think about testing. As mentioned earlier, schools of testing are more of schools of thinking for a tester. So, a tester should always think context-driven and then he should try to adapt to and experiment with the project as a whole, which as a bigger picture predominantly exhibits one of the several schools.

Above is what I think about schools of testing. The above thoughts are based on my exposure to testing assignments so far and to the writings I came across on schools of testing or on software testing as a whole. There might be and there must be lot of points which I have missed. The above are my honest views. I expect your honest comments in return.

This is the eleventh post in the series “The Big Fight – Schools of Testing”. For my previous posts on Schools of Testing, you can check the posts under the Schools of Testing Category.

Rahul Verma

16 Responses to “The Big Fight – Schools of Testing – My Thoughts”

  1. Ben Simo

    When I first read Brett’s material about the schools many years ago, I had difficulty understanding the Context-Driven school. At that time, my personal thinking was clearly in the Quality school and I was unhappy working in a Factory school company. At that time, I didn’t make the connection that my disagreements with my employer’s approach were due to differences in how we define the philosophy of testing.

    It was only after gaining some more experience that the schools made sense to me. The school idea helped clarify differences between my thinking and the thinking of other testers, managers, and executives. I have found that being able to connect someone’s thinking to a specific school helps me better communicate with people in other schools. It reminds me that others may not define things the same way I do. It reminds me to ask questions to clarify what people mean by their words.

    Schools do not define techniques. Schools model one’s philosophy and world-view of testing.

    I do not see the schools as an us vs. them fight. Instead the school definitions help me model other people’s thinking. As with any model, it is less complex than the thing it represents. As George Box wrote: all models are wrong, but some are useful. … the practical question is how wrong do they need to be to not be useful.

    Ben Simo

  2. Rahul Verma

    Hi Ben,

    I agree to your views.

    I found that this idea has helped me to think more about how I think about testing and how I am actually testing. I also did similar analysis for my peers. That’s the reason I support this idea. But when it is used to sell something beyond this, I find myself comfortable only with a part of it.

    Every idea always generates a debate. If everyone takes that debate in a healthy way, instead of leaving derogatory remarks, this debate is very useful for the upliftment of the complete community. But many of us start commenting on the person rather than on his or her views. You can find several such examples on blogs and other discussion groups. This is the sad part.

    Thanks for the visit and for sharing your views.

    Rahul Verma.

  3. Shrini Kulkarni


    First let me congratulate you for a fantastic job that you have done in consolidating all thoughts related to this topic. Your blog from now on provides a platform for all those who would like to debate on this topic.

    But, I am bit disappointed with this post (my thoughts).

    I am afraid, like many others whole chain – who argued against or denied the existence of schools –

    You seemed to have not understood the concept of Schools. You are confusing schools of testing with what actually happens in testing – practice(adapting to project and organization etc). A school of testing is not what you practice in a project/organization environment but what you believe about testing.
    Catch here is your beliefs guide and influence your practice and there are external practices that constrain you to work in a specific way but that does not (ideally should not) change your core belief about testing.
    If you are a context driven tester working in a CMM shop – you dont become Quality school person. You might feel unconfortable in that environment (just as Ben Simo getting frustrated with Factory environment) but you might still work and retain your core fabric of beliefs and value system

    That is what I can say in in short.

    I will come back and post more – point by point to your views …


  4. Rahul Verma

    Hi Shrini,

    My sincere apologies if I have disappointed you or any reader of the blog with my post. But that’s what my present thoughts are. If they indicate a lack of knowledge or understanding (these views indicate my complete analysis about myself for the past one month), I am sure that through the course of discussions, I will fill those gaps. In the course, there will be lots of things that others can pick up as well.

    You have correctly pointed out that I am attaching the schools of testing to the practice. This is not out of confusion, but an outcome of the analysis I did.


    If schools of testing advocates just “What I Think about Testing”, I guess I am already a part of the game. I have already accepted the idea. But I think this concept teaches us much more than that. There are learnings from it, that we can take back to our workplace. So, on a broader perspective, we can attach a school (apart from a school of thinking for a tester) to the project as a whole. If the present concept does not include this, I guess, It will help if it does.

    I will eagerly wait for your point-by-point analysis of what I posted.

    Thanks for sparing time to visit my blog.

    Rahul Verma.

  5. Shrini Kulkarni

    Can you please work out following two excercises for me – the purpose of these excercises will be to understand your beliefs on testing …

    1. How do you define testing?
    (choose that definition carefully as this identifies your fundamental belief about testing – I believe, I don’t have to say “avoid bookish or Standard definitions”

    2. What are your thoughts on this situation “Testing without any specifications” ? Explain how do you approach this situation?


  6. Pradeep Soundararajan


    Finally your thoughts came up 🙂

    I have never seen such a success with a series of posts in blog and I am happy that you achieved it. It’s difficult, at least for me to give a series.

    Jhony walker – Keep Going!

  7. Rahul Verma

    Hi Shrini,

    Please find my answers below:


    Testing is exercising a product or application to check:

    1. Under what conditions, it fails/crashes
    2. What modifications/additions/deletions could make it better
    3. What functionalities it is able to execute well. It is normally very easy to say ‘it failed’, but to say ‘it passed’, is very very subjective, for a functionality. There is no end to improving a functionality. But neverthless, some tests are quite simple and can be termed as pass without much speculation.

    For me, all the above put together give the level of confidence about a product.


    Testing without ANY specifications is a bad situation. Specifications always help you in doing your testing, though you do not depend fully on them.

    If no specifications are provided, I will need to start with lot of acivities simultaneously.

    1. I have to start exercising the product in different ways. I choose to document all my observations. It provides a basis for knowledge sharing and brainstorming. Some of the observations might be good for team and some might be totally wrong, so that I can correct my approach.

    2. Knowledge about other similar applications/products helps – either from prior experience or from someone else’s experience, books, web…there is a lot to look for.

    3. To keep a track of testing, I will document the tests as I conduct them, suggest the same to others and will devise some central repository for all, to avoid repetition/redundancy.

    Rahul Verma.

  8. Rahul Verma

    Hi Pradeep,

    Thanks for the good words.

    This is the only post in which I have put my thoughts. The rest were all because of those who devised the concept, or who expressed on the web, or practitioners like you who spared time to reply back to my request for views and those who spared time for brainstorming sessions. I have acted mostly as a compiler. So, cheers to all those who have contributed knowingly/unknowingly to this series. I will mention all the names in the Thanks note.

    Rahul Verma.

  9. Pradeep Soundararajan

    Rahul said, Testing without ANY specifications is a bad situation. Specifications always help you in doing your testing, though you do not depend fully on them.

    and before that Rahul said, Testing is exercising a product or application to check:

    1. Under what conditions, it fails/crashes
    2. What modifications/additions/deletions could make it better
    3. What functionalities it is able to execute well. It is normally very easy to say ‘it failed’, but to say ‘it passed’, is very very subjective, for a functionality. There is no end to improving a functionality. But neverthless, some tests are quite simple and can be termed as pass without much speculation.

    Hmmm, isn’t that contradicting?

    When you ( Rahul ) explained about testing, you never mentioned the word “specification” there.

    Had you mentioned “Testing is an activity that involves the following points…

    1) whatever
    2) whatever
    3) whatever

    using Specifications, I wouldn’t have bothered to bother you with this comment.

    If testing is an activity of finding crashes ( as per your own definition ) [ however the specification wont say, “Installing the software should not crash PC’s ], how does it matter if you don’t have a Specification?

    Well, did you want to mean “Testing without specification might not convince me enough to gain confidence”? when you said, “Testing without ANY specification is bad”?

    I’d say, “Testing without a mission is bad”

    Give me a product without giving me it’s specification and say “test this Pradeep, this is what your mission is …”

    I’d be asking questions, to gather information to help you and help myself meet the mission that you set.

    I am being smart tester ( in my own idiom ) as I meet the mission of my client than to say, “I doubt if I could test well as I do not have a specification”

    I am not sure if you are referring to a document when you say “Specification”. If you are saying that, here is something interesting for you, “Specifications need not be in document form. It might be in the form of words from mouth from the client. Let’s excuse the client for not having a specification as he is going to pay us money for testing and we keep thinking of adding value to him. The way, we as smart testers get the specification is by asking questions to the client. If he doesn’t answer them, we warn him of the risks that he might face.”

    This comment is no attack on you. It has two motives –

    1. To help someone who has put in effort to produce a wonderful series of posts on testing, gain a different perspective.

    2. To allow him comment back and check if I can learn something wonderful and really get smart, this time at least.

    Heuristics, Oracles, Questioning, Exploratory Testing…. Rapid Software Testing to the rescue!

    Hey Rahul wait a minute, I am not ending!

    I just noticed that you mentioned Specifications always help you in doing your testing, though you do not depend fully on them.

    Whom are you referring to when you ( Rahul ) say “YOU” in the above statement.

    In India, don’t most testers think – No Specification means No Testing – as they have memorized the SDLC, V and Waterfall Models and think that’s the only way software is developed?

    I have worked with testers who do not understand (and not bothered that they haven’t understood) the requirement document, which results in these testers adding 10K test cases that doesn’t fetch anything but adding to the cost.

    I have worked with testers who claim to understand the specification and aren’t open to understand the specification when someone wants to help them understand it.

    I have worked with testers who do understand the specification and did not use the understanding to its full potential.

    Although I am not completing the list… Now you tell me, how many testers are there who would benefit by the specification to do a wonderful job.

    I was no born test expert and I am not one yet and I admit that I myself have been one among the above categories I have listed. The only difference being; I say it out.

    If I was able to make you think more on the topic, I have been a good tester.

    If I was able to make you think without hurting you, I have been a good human being who also is a smart good tester.

  10. Rahul Verma

    Hi Pradeep,

    Thanks for sharing your detailed comments.

    I will try to clarify some points which you have put as a part of your comments. Also, I will not use the word ‘you’, instead I will take the ownership and say ‘I’. I got your point about not to generalize what I think to what everyone thinks.

    To avoid any communication gap, I will first define what I meant by specifications.

    You said…

    I agree that in my quoted text, specification is a document which is shared with me by the designers/developers of the product/application, which contains various details about it, e.g. various fields, their stipulated boundaries, functionality etc. Shrini asked about my opinion on “Testing without any specifications”, The question itself indicates some kind of document available to a tester before he starts testing. During testing, if I ask a question from the client and his reply should be taken as a specification (as mentioned by you in the above quoted text), then I do not think that there is anything called “Testing without specifications”. We should say, “Testing without prior specifications” instead and such prior specifications (which Shrini is hinting) will always be in written form. I guess this needs some more discussion. I will wait for your response on this. As of now, I will continue the discussion in the light of “Testing without prior specifications” (for the original phrase Testing without specifications).

    When I say “Testing without ANY specifications is a bad situation”, I mean that if I am available with the specifications (in the above meaning) of some sort, it helps me to get the first level understanding of what I am testing. So, I wrote “Specifications always help you in doing your testing, though you do not depend fully on them.” The second half of this sentence indicates that I, while testing, do not blindly follow specifications. I consider them as one of the important inputs, but not the only inputs. Why I call a situation without specifications as bad is that I personally feel that when the developers/designers of a project do not document the details (even in a minimal way), they did not do their job well. Whether or not, such specifications are available to me, I definitely ask questions, but number and quality of questions will vary.

    I fully agree to you on the concept of asking questions. But I would prefer to use it in addition to some already present specifications. The schedules which are given to us, sometimes does not allow us to get answers to all our questions during the testing phase. E.g for a basic control, suppose some boundary conditions have been defined already by the developers. It’s good to know them before you start testing. During testing when you touch other boundaries for that control or find something that the developers couldn’t think of, I believe that the quality of questions increases, the extent of communication required decreases, helping one to deliver things on time. I fully agree that we have to respect the client anyways, but parallel to this, I think that a client, who did not document specifications, might also turn out to be sparingly answering my questions.


    When I said…
    “Testing is exercising a product or application to check:

    1. Under what conditions, it fails/crashes
    2. What modifications/additions/deletions could make it better
    3. What functionalities it is able to execute well. It is normally very easy to say ‘it failed’, but to say ‘it passed’, is very very subjective, for a functionality. There is no end to improving a functionality. But neverthless, some tests are quite simple and can be termed as pass without much speculation.”>>

    The first point indicates a failure whether or not it is mentioned in the specifications.

    The second point indicates considering expressed specifications (prior specifications), and then applying one’s thought process and then come up with suggestions to improve upon the existing product e.g. by suggesting an additional feature, some change from usability perspective, or some feature that is redundant.

    Similarly the third point indicates that even if a test is “pass” as per the specifications, considering it as pass is something subjective. If I have an opinion that differs from specifications, definitely it will fall in either category 1 or 2.

    As per me, I am not contradicting myself. There might be some gap in my earlier communication. If you still sense some contradiction, I would like to clarify further. I did not use the word specification while answering the first question by Shrini, because I was specifically answering to his second question about specifications.


    I think that nobody can write perfect specifications. Nobody can write specifications which can cover everything. I consider them as one of the inputs and not the only input. If what I observe is not specified, or has to be override a specification, it does not stop me from reporting that observation or from taking it seriously. So, you are correct in pointing out that for a software crash, if there is no corresponding specification, it does not matter to the tester at all. A crash is a crash.

    What I meant was that some specifications if present give a tester something to start, something as basis of testing, instead of being totally directionless. I do not challenge the capability and insight of the individual; I just suggest specifications as something to start with.


    Very well said. Testing without mission is bad. I agree that you will execute the things well. Your questions will be good too. [Now I am in the role of the client] What if I do not answer them in time? What if I say, you are asking too many questions? What if I say, you are asking too much basic questions? Though you spared me being a client, but I have full authority to do anything. You told me the risks associated, but your management treats me as a valuable customer, so whatever delays I cause in answering, your team works on the weekend to compensate them! [I am back as Rahul] I have faced such situations Pradeep. Sometimes, we tend to take the mission more seriously than our counterparts on client side.


    I agree to you that if there are no prior specifications, the best I should do is start exploring the product/application and then ask questions from the client, instead of sitting back and complaining that I can not proceed without specifications. I have done plenty of performance testing projects, and for most of them, there were no documented specifications. I used to ask a lot of questions. Some of these situations were not very comfortable. Depending upon client’s attitude, the response time varied, so things were pushed to the end. The client was told about the risk of such a situation, but most of the times management ended up agreeing to the client’s request. The final test will always be done on time inspite of all such delays. What I mean to say is that if specifications are not there, I will definitely try to think what best can be done, but there should be some pressure on the non-testing teams for documenting some specifications and providing to the testing team. After all, a good product/application is everyone’s responsibility.


    I respect the way in which you have taken up this discussion. You haven’t written anything that hurt me. If I did so, in the above debate, please bring that into my notice.

    Thanks for visiting and sharing your views.

    Rahul Verma.

  11. Shrini Kulkarni


    Pradeep has just displayed characteristics, Beliefs and Value system of a context Driven Tester while analyzing your responses for my exercises.

    There are different types of testers, there are fundamental disagreements about testing – There should be a way to distinguish between a tester like Pradeep, Shrini, Rahul and others.
    No offense intended in this classification – some classes of testers are just different in their approaches.

    Schools concept gives a platform for reconciliation of such disagreements.


  12. Pradeep Soundararajan

    [Now I am in the role of the client] What if I do not answer them in time?

    If a client isn’t willing to answer my questions and do not like questions being asked from me ( a tester ) then I doubt his seriousness about the product and he doesn’t deserve my skills and I am sure he doesn’t know testing or it’s importance.

    What if I say, you are asking too many questions?

    My next question would be, “too many compared to what?”

    What if I say, you are asking too much basic questions?

    That’s a wonderful question that you asked me. By answering this question, I can help you [ client ] realize the importance of my questions.

    A question that you feel is ‘basic’ or ‘time consuming’ are usually the ones that testers who add less value to the money you pay don’t ask at all. I ask questions to you as early as possible to help you not get into traps later. Maybe, by answering my questions, you might discover something new or help me understand your product. If I understand it through an interaction with you, it helps me in adding more value.

    Moreover, you are paying me and I assume that you pay to get my help to solve a problem of yours and not get my help to create a problem for you that you like to solve on your own.

    Do you expect me to make a mistake that otherwise could have been solved, had I asked you a question and sought information to avoid trap?

    If you aren’t willing to answer my questions now, you might have to answer a lot of questions from your customers/clients later and hence I am helping you to avoid such a trap, early.

    If you intend not to get any value out of testing but want to say that the product is tested, why spend so much money? Google out for a test report template, fill in the numbers you like, fire a print, attach it with your product, and feel guilty, at the end.

    Though you spared me being a client, but I have full authority to do anything. You told me the risks associated, but your management treats me as a valuable customer, so whatever delays I cause in answering, your team works on the weekend to compensate them!

    If you delay in answering, it doesn’t mean my team works on the weekends. As you delayed the information, we tried digging it out and exploring and we did get some information on this. Here are the results, to surprise you… [ report.xls ]

    You said… As per me, I am not contradicting myself. There might be some gap in my earlier communication. If you still sense some contradiction, I would like to clarify further. I did not use the word specification while answering the first question by Shrini, because I was specifically answering to his second question about specifications.

    I see some contradictions and I suggest that you find it out by yourself.

    @ Shrini,
    You got me excited with the word “exercise”!

  13. Rahul Verma

    Hi Shrini,

    I agree to what you said, “Schools concept gives a platform for reconciliation of such disagreements.”. I am in favour of the schools concept, it’s just that my analysis about the concept itself varies somewhat from what is documented so far.

    I will constantly be pinging myself on this aspect and whenever I find that I have a new/changed viewpoint, I will definitely share.

    Rahul Verma.

  14. Rahul Verma

    Hi Pradeep,

    I will try to summarise what you have said in your comments –

    1. A client who is unwilling to answer a tester’s questions is not aware of the value of testing and is probably not worth some good testing services. He himself might be caught in a trap while dealing with his own clients.

    2. If the client terms a tester’s questions as “too basic” or “too many”, a tester can take the initiative to explain the importance of these questions to the client. A tester in the absence of information from the client should work on finding them as best as he can on his own.

    I as a tester, agree to both the points mentioned above. You can be sure that we do not have a difference in opinion on the above points. The questions which I asked from you as a client, were not the questions which I will ask when I am truly a client. I will encourage such questions, because I know the importance of them. They were the questions which I have come across while dealing with my clients. So, I was trying to put a practical situation before you, I am sure that I will be a much better client in terms of encouraging and supporting a tester.

    I again looked back into what I wrote. I still did not find any contradictions. I might be seeing all this with a pre-defined perspective which has been the outcome of my analysis so far. What I will do now is that I will give myself some time to relax and then after some days or so, I will try to locate such contradictions in my writing. If I find any, I will get back to you and if possible, edit the present post to include them.

    Your comments made me think a lot more than I originally thought and in the process I gained more clarity about myself and my thoughts on testing. This in itself is something to feel good about. I am quite happy about it. Cheers to your participation in this discussion.

    Rahul Verma.

  15. Debasis - The Bug Hunter!

    Hi Rahul,

    I think I am late (considering the date of post and the 12 comments on this blog entry!) in reading your “Final Thoughts” about the Schools of Testing. 🙂 Actually I was busy with my job recently and did not have the chance to read your blog.

    Anyway, first of all let me congratulate you for completing a series of posts on a debatable concept (Schools of Testing) with so much of Success. I am not sure if someone would not consider it as a Success. But to me, it is a huge success. At least because, I have NOT seen any blogger (writing on testing) achieving such success with a series of post. Hats off to you.

    And continue to do the good work. All the Best.

    Software Testing Zone

  16. Rahul Verma

    Hi Debasis,

    Nice to see your comments. As it is an ongoing discussion, so nothing can be considered as late.

    I am happy to hear that you consider this series successful. This encourages me to consider writing a new series in the near future.

    Keep visiting and sharing your views.

    Rahul Verma

Leave a Reply to Debasis - The Bug Hunter!Cancel reply


1 2 12
June 30th, 2020

Arjuna 1.1.0 Production Release

July 23rd, 2017

The Last Keynote on Software Testing

July 23rd, 2017

The Agile Qtopia

July 23rd, 2017

Reflections:: Persistent Learning

February 28th, 2017

Reflections :: Servitude

January 9th, 2017

Reflections on Testing: Dignity

May 10th, 2016

The Pluralistic School of Testing

May 9th, 2016

Don’t Ignore Your Special Users

May 9th, 2016

The Dogmatic Agile – A Critique of Deliberate Blindness

October 9th, 2015

Pattern Thinking for Performance Engineers