Behavior-Driven Development vs. Testing
The difference between Behavior-Driven Development and testing:
This is a BDD scenario (from Dan North, a man I respect and admire):
+Scenario 1: Account is in credit+
Given the account is in credit
And the card is valid
And the dispenser contains cash
When the customer requests cash
Then ensure the account is debited
And ensure cash is dispensed
And ensure the card is returned
This is that BDD scenario turned into testing:
+Scenario 1: Account is in credit+
Given the account is in credit
And the card is valid
And the dispenser contains cash
When the customer requests cash
Then check that the account is debited
And check that cash is dispensed
And check that the card is returned
And check that nothing happens that shouldn’t happen and everything else happens that should happen for all variations of this scenario and all possible states of the ATM and all possible states of the customer’s account and all possible states of the rest of the database and all possible states of the system as a whole, and anything happening in the cloud that should not matter but might matter.
Do I need to spell it out for you more explicitly? This check is impossible to perform. To get close to it, though, we need human testers. Their sapience turns this impossible check into plausible testing. Testing is a quest within a vast, complex, changing space. We seek bugs. It is not the process of demonstrating that the product CAN work, but exploring if it WILL.
I think Dan understands this. I sometimes worry about other people who promote tools like Cucumber or jBehave.
I’m not opposed to such tools (although I continue to suspect that Cucumber is an elaborate ploy to spend a lot of time on things that don’t matter at all) but in the face of them we must keep a clear head about what testing is.
October 19th, 2011 at 12:32 pm
TDD, BDD, ATDD etc etc are NOT about testing in the traditional sense of the word. They do not replace the need for human testers (in particular) or a QA process (in general).
They are techniques that facilitate communication – developer to developer; developer to stakeholder; developer to tester.
They can also help ensure that the software is nicely modular, that the software can be safely refactored over its (hopefully) long life, and that some classes of defects never get to the next stage in the lifecycle.
I know that James (who I respect and admire) understands this, but I worry that some developers might take this blog-post as a criticism of TDD/BDD (or unit testing as a whole), rather than a reminder of the importance of exploratory testing and the role of human testers.
[James' Reply: Why would you or anyone think I'm criticizing unit testing, unless by that you are referring to something that isn't testing at all?]
October 19th, 2011 at 1:13 pm
I agree too James.
Have you read The Cucumber Book?[1] I would like your feedback as to whether we’ve reflected this view clearly enough, because I think you’ve made a very important point that many people who embrace tools like Cucumber do unfortunately miss.
[1] http://pragprog.com/book/hwcuc/the-cucumber-book
[James' Reply: I have not read it. I've seen several demos of Cucumber. I'm reacting to what people said about it in the demos, and what I think I see in it. I'll check out the book.]
October 19th, 2011 at 1:25 pm
The link to Dan North’s “Introducing BDD” is broken. It is missing the colon between “http” and “//”.
[James' Reply: Fixed. Thanks.]
October 19th, 2011 at 1:29 pm
The people with whom I’ve worked that promote BDD or ATDD using tools like Cucumber or Fit all generally agree it’s a design tool and NOT a quality tool. Converting a requirement or a user story into a testable binary (or a “check”) forces all involved to analyze what’s being requested. Since computers won’t recognize fuzzy language, forcing us to use computers puts a check on such things. When it works well, a Cucumber test is a very informative metric letting the developer know when they’ve coded “just enough” to stop.
It is not, however, a tool for verifying quality or even the fitness of the requirement under test anymore than a unit test would be a replacement for an integration or performance test.
I do, however, understand your frustration. I find myself repeating this maxim a lot recently. It seems as though anything with the word “test” or “quality” somewhere in it will be immediately misunderstood.
October 19th, 2011 at 2:01 pm
What is the difference between ‘ensure’ and ‘check that’?
If the BDD definition had been written like this:
+Scenario 1: Account is in credit+
Given the account is in credit
And the card is valid
And the dispenser contains cash
When the customer requests cash
Then check that the account is debited
And check that cash is dispensed
And check that the card is returned
would you have changed the way you wrote your testing version with respect to these lines?
[James' Reply: The main thing I did in my version was add an "everything else" clause to illustrate that these BDD statements are not confirmations of correct behavior, but rather partially correct behavior combined with possibly incorrect behavior that goes unnoticed. The clause also illustrates that BDD coverage is limited to the particular states of the many aspects of the system that happen to be true at the moment of execution-- and that those states are both myriad and unspecified.
The second thing I did is roll back the arrogance of the word "ensure." We don't ensure anything in testing. To ensure is to "make sure of" or "compel." We don't do that. Developers do that by writing code. What a process like BDD can do is check something, not ensure.]
October 19th, 2011 at 2:05 pm
Cucumber introduces too much overhead/complexity to be an efficient design tool. If that is its main purpose, which I agree it is, then it is a big FAIL.
I appreciate the goal of Cucumber but there is simply too much plumbing overhead. I’ll spend my time talking with the customer and writing real BDD driven code.
[James' Reply: That's my biggest WTF feeling about Cucumber: The amazing amount of effort people will go to in order to accomplish a simple objective, when that objective can be accomplished with much less effort by other means.]
October 19th, 2011 at 2:16 pm
We use Cucumber in our team and we are very well aware that such automation relies on the supposition that the future shall resemble the past/documented – it helps verifying what you have coded, prevents documented problems and has to be incrementally improved.
We never rule out the need of QA and we have QA people.
[James' Reply: What I don't get is why you invest so much work to accomplish so little.]
October 19th, 2011 at 2:19 pm
(I’m double-posting)
But I understand what you (and this blog), people in my team (even myself, earlier) thought humans could really be replaced.
October 19th, 2011 at 2:41 pm
James,
I think you’ve just demonstrated what I consider to be the main benefit of writing Cucumber (from a team point of view rather than a design point of view) i.e. it gives the team the chance to discuss and critique the language of requirements before they are implemented. Just as you point out the invalid use of the word ‘ensure’, discussions around Cucumber tests often involve pointing out the invalid use of the words being used to describe how our system should behave. Over time this facilitates a much more exact use of language, which has benefits for everybody involved.
As a tester, I find it very beneficial to get the chance to play Socrates before work gets under way. It also gets my brain thinking about how to test the requirements before I actually get round to doing it.
[James' Reply: And I can do all of that, rather easily and cheaply, without Cucumber.]
October 19th, 2011 at 3:50 pm
In regards to your last comment as to the misplaced time in BDD/ATDD tools, my .02 is that the issue is that for most ‘fixtures’ one or more equally relevant user/customer facing demonstrative features exist that accomplish the same goal.
For example, one of the normal ways we show a user we ‘ensure[d] the account is debited’ is to provide a receipt. This example is a bit more complex due to the hardware integration, but assuming we can capture this (say by comparing the print stream) it supports both an automated development time ‘verification’ (not testing/checking) of specification examples, /and/ it also serves as the run-time feature itself.
IMO, Cucumber is an internally proxy for testing outcomes for the purpose of showing the development team their system is good. When instead we could be creating our best demonstration externally as an actual artifact of the system to the user/customer to show them the system is good.
The BDD/ATDD/Specification By Example ‘process’ is very good, but the wrong artifacts are being created. Rather than a parallel development-time-only artifact, we should just create the actual artifact that supports both development and run-time production.
This doesn’t change the central thesis of your post, though it is more obvious that it’s a demonstrative feature and not a ‘test’ per-se.
October 19th, 2011 at 5:52 pm
While I agree that for finding new defects human testers are irreplaceable (I make the ‘quest’ argument myself). We ourselves do not test “all possible states” but use techniques such as boundary value analysis that allows us the maximum coverage for minimum time / effort.
[James' Reply: Of course we don't test all possible states! But that wasn't my point. The quest of testing is not embodied in the things we check but in the unfolding dynamic of our thinking and learning which leads (for people with good testing skills) to a MUCH better sampling of the phase space of the product. BDD checks are don't unfold at all. They are cute little static confections.]
Those techniques translate very well into automated tests.
[James' Reply: No they don't. Not in any way. In fact, no good test has ever been automated. Good testing can only be done by humans. For the same reason that cruise control is not "automated driving" a program that performs a check is not automated testing.
It's this typical misunderstanding of the nature of manual testing and automated checking that led to I and my colleagues changing our language so that we now avoid the use of the term "test automation."]
However, automated testing is actually invaluable for a few things that human testers can’t do (not actually finding ‘new’ defects), the most prominent of those is speed.
[James' Reply: I use tools in the course of my testing, both to enable finding bugs (I don't use the term "defect" if I can help it) that I couldn't find otherwise, as well as to perform checks. I agree that it is wonderfully valuable when done well. It is typically, however, a shocking waste of time-- embraced by people who generally don't enjoy testing in the first place, and so have little idea what they are giving up.]
With automated testing you can ensure that the most important and / or risky aspects of your app is covered (you can even use our own techniques such as boundary value analysis) and working which allows you to change fast and deploy quickly. Without tools like RSPEC or Cucumber you can not hope deploy once or more a day.
[James' Reply: I don't think your tools are doing what you think they are doing.]
October 20th, 2011 at 12:44 am
Hi James,
Could you please clarify the difference between “Check” and “Ensure”… It seems that you have different understanding than mine for these words…
[James' Reply: I like to use the Oxford English Dictionary as my authoritative reference, to the extent I accept authority over my use of English...
There are several definitions of ensure. The first one seems closest to the notion of checking:
1. To make (a person) mentally sure; to convince, render confident.
This is not outrageously wrong, though it strikes me as over-confident. What troubles me are four other definitions that go way beyond checking and refer to causing something to be the case:
6. To secure, make safe (against, from risks).
7. Comm. To insure v. (a person's life, property, etc.). Obs.
8. To make certain the occurrence or arrival of (an event), or the attainment of
(a result); = assure v. 5.
9. To make (a thing) sure to or for a person; to secure.
]
October 20th, 2011 at 4:03 am
While I agree with the thrust of your argument, Curtis, I encourage you to be careful.
“Converting a requirement or a user story into a testable binary (or a “check”) forces all involved to analyze what’s being requested.”
Consider the assumptions in that statement:
1) The requirement is simple enough to be expressed in terms of a binary outcome (which is the sole outcome of a check). I can’t think of very many requirements that yield to that kind of simplification. Whatever is going on, something else is going on; whatever happens, something (or nothing) will happen in response.
2) The action of converting an idea from one form to another to can force someone to do something. At best, the process might suggest something to some person (but not to others).
3) “All involved” includes some person(s) other than the one who is performing the conversion.
4) The analysis is thoughtful and thorough.
—Michael B.
October 20th, 2011 at 7:52 am
We are actively implementing BDD at our place. And we use specflow for this purpose. Between I’m the tester in our company. I do lot of manual testing (did reasonable automation in the past) but also involved in BDD approach. This technique is helping us to establish the collaboration between testers, developers and product owners. This is working really well for us. We have written hundreds of scenarios so far and run them frequently. We all work together and come up with the test scenarios then developers convert them into Gherkin Language(Given,when then) format. This raised my interest in BDD. I did lot of research on “Do we need programming skills to implement BDD” and found zero results. This means it is clearly understanding that no tester asked this question ( I might be wrong). Although I’m the tester (Did very basic coding 8 years ago and I’m from IT background.) I’m really interested in learning C# with .net ( atleast basics) and then implement these scenarios myself which add’s lot of value to the company). Thank you James for giving me the opportunity to share my thoughts.
October 20th, 2011 at 9:52 am
Reading this reminded me how language shapes perception, and of an article by Don Gray: http://www.donaldegray.com/debugging-system-boundaries-the-satir-interaction-model/ where he makes the point that, “the words we use create meaning in other people – And we don’t get to choose what that meaning is, they do.”
In my FDA regulated world there are consequences for miss-communicating meaning. If we all agree that the word “ensure” is an overstatement in this context – then choose and use a more appropriate word.
Also, for me: the Check:Test:Ensure model is like the Intake:Meaning:Significance model in a Satir Interaction model way. When I identify people/organizations mistaking “intake” for “significant” that is an interesting anti-pattern to explore in the organization.
October 20th, 2011 at 9:13 pm
Although I agree with you, James, that automated specs don’t replace the human mind when it comes to testing, I still miss the point why you think Cucumber is a huge overhead.
I played with Cucumber a bit in the past, and found that it’s not much harder than writing an automated spec in any other tool.
[James' Reply: The concept of an automated spec is a dumb idea in itself. The source code of the product is ALREADY AN AUTOMATED SPEC. What you're doing with your so-called automated spec is creating a new layer of technology that is a pretense of communication while subtly discouraging it. Users and domain experts aren't programmers-- you are tricking them into thinking they are not programming while in fact they are programming. This trick gives them a false view of both the product and the automated check of the product. I would much rather walk my clients through the code, or else give them a fully realized English specification, than to write a boneheaded set of hundreds of simplistic examples and expect them to understand them, or give them a hideously oversimplified construct in which to express their ideas for the specification. We already have a construct: it's called English. We also have diagrams. We also have conversation. And we have prototyping. Those things work together to solve the problem.
As for overhead. Obviously you have to write all the fixtures to tie the language into the tool. That's pure work that I never have to do, because I don't fool with tools like that.]
Or, do you mean that writing executable specifications is an overhead by itself, regardless of the tool used? Then, what can we do instead?
[James' Reply: Come on man, use your head-- WE TALK TO EACH OTHER. We write, we draw, etc. I've been doing that for 28 years. Stop playing dumb!]
As a member of a team that looks for opportunities to automate user story verification and enhance the dialog between stakeholders, I’m very interested in your opinion.
[James' Reply: How about instead you stop hating talking to each other, develop your social skills, and engage people?]
October 21st, 2011 at 12:36 am
I like BDD and what it does. It tries to find a simple common denominator for producing software that fulfils wanted behaviour. To describe that behavior a language construct called Gherkin (and not Cucumber! Cucumber is the ruby interpreter for Gherkin) is used.
I see the strength not in the test (more to that later) or the automation bit. What I see is that the system designer/BA is forced into a simple model to describe the application. A language that can be easily understood by all involved and reduces defects/bugs at a point where they have the most severe consequences….the inception phase.
[James' Reply: I don't feel that we are served by simplistic language. I feel better served by using the full spectrum of English. Also diagrams. Where are the diagrams in Gherkin? I don't see them!]
Since BDD is a development methodology we do it some discredit using the testing scale to critique it. We have to see BDD as an extended form of Unit Test that testers can “play” with too. I’d expect the test that does the checking above to be scripted by the developer and not a tester. The tester would be underutilised doing that. As James points out his time is much better used testing things that require a brain and cannot be checked or automated.
I am an absolute fan of automated smoketests that test the absolute basic functionality (as would be the case above). James would probably disagree because that is like carpet bombing the same land over and over again. He is of course right from his context but these automated checks are needed too.
[James' Reply: They don't test anything, Oliver. They check. The checks can be useful. One thing I warn against is paying a high price for simple checks. I also warn against using checks to the exclusion of tests-- it's an abdication of tester responsibility.]
With frequent release cycles, hot-dog developers and careless infrastructure cowboys they manage to break something fundamental eventually. If I can prove/disprove that in 10 minutes in an automated fashion that’s great. Is that testing? Certainly not. Is that checking? Probably. Is it regression? Definitely not (using PM’s and test tools sales guy’s “definition” of regression here). Does it fulfill a useful function? Hell yeah. We save months of manual effort a year by doing it.
[James' Reply: I can create and use such automation inexpensively. When I look at Gherkin/Cucumber I see needless confection. Please DON'T confuse simple automated checks with overwrought fixtures tied into faux English protocols for specification.]
The nice thing with BDD is that this smoke test can be traced back to (mostly positive case) behavior we want to see. That will keep most PM’s, customers and auditors at bay. It also shows clearly how a piece of software was intended. If it is automated that would include a live demo!
[James' Reply: Yeah, I can do the same thing with simple Perl code.]
But I also think James is spot-on with saying this is not testing. Of couse it isn’t but lets not condemn the method as i think it has merit in a lot of other ways that bring quality into development without being about testing at all. So we need to complement BDD by the things we as testers already know and do.
Oliver
P.S. A tester using Cucumber is called a developer
October 24th, 2011 at 1:37 am
I’ve done alot of reading on BDD this year and I’ve run into the same problem with people thinking that doing BDD is the same as testing. Some things I like to bear in mind when I’m thinking/talking about BDD are…
- You must be sure what problem you’re trying to solve if you implement this stuff. BDD isn’t a solution to a testing problem so don’t expect it to fix any of those kinds of issues. It might help alleviate them (for a time) but it won’t fix them completely.
- It’s really important what you call the different practices involved. For example, thinking/communicating about the feature files as “Rejection checks” rather than “Acceptance tests” helps immensely (think about it! Thanks to Michael Bolton for that).
- Thinking of feature files as requirements rather than tests also helps. Well it helped me at least.
- You get nothing for free. There is a cost for everything (money, time, sanity, etc). Lots of people think the checks (NOT tests remember!) write themselves and that the results interpret themselves for some weird reason! So try and figure out whether the ROI is worth it for your needs. You have to create CODE to do this stuff which needs creating, maintaining and (shock horror) testing so don’t be seduced into thinking “any old tester” can do it. They can’t.
Vern
October 25th, 2011 at 12:12 am
James, wouldn’t BDD steps be helpful for coders to understand the scope of requirements better. I agree that BDD alone might not be efficient in testing.
[James' Reply: Better than what? Better than having a conversation and doing a prototype? I doubt that very much. I think it's a tool being pushed by fan boys.]
October 25th, 2011 at 12:47 pm
There’s an effort underway among developers in our shop to implement Cucumber tests as part of the build to “help us release faster.” I’ve not yet received a satisfactory answer to how this is so. Cucumber is the proposed solution, but the appeal is actually to some underlying principle (and not to Cucumber as a tool specifically. Presumably other tools would work in principle).
At any rate, does anyone know of an agile-esque principle that asserts that this kind of BDD testing helps developers get the release out *faster*? QA has been invited to participate in writing these tests. Since “speed of release” is not a quality concern in and of itself (and can of course even run contrary to QA objectives), I’m reluctant to commit much in the way of QA time/resources to writing such tests.
[James' Reply: The idea that it helps you release faster is a fantasy based on the supposed value of regression check automation. If you think regression checks will help you, you can of course put them in place and it's not necessarily expensive to do that (although if you automation through the GUI then you will discover that it IS expensive).
BDD, as such, is just not needed. But again, if it's cheap to do, you might want to play with it. The problem I have is that I don't think it IS cheap to do in many cases. I'm deeply familiar with the problems of writing fixtures to attach high level "executable specs" to the actual product. It can be a whole lot of plumbing to write. And the temptation will be to write a lot less plumbing and to end up with highly simplified checks. The simpler they are, the less value they have over a human tester who can "just do it."]
October 25th, 2011 at 7:01 pm
@PM Hut: It might be helpful to see the description of a check that James and I developed a couple of years back:
http://www.developsense.com/blog/2009/09/transpection-and-three-elements-of/
I’ve given a great deal of thought and keystrokes to checking. Two key posts are here http://www.developsense.com/blog/2009/08/testing-vs-checking/ and here http://www.developsense.com/blog/2009/11/merely-checking-or-merely-testing/.
—Michael B.
October 26th, 2011 at 7:19 am
Hi James,
To me, these practices address a couple of questions that I encounter in my work, on product development teams:
1) Did we break anything that mattered enough to us before that we chose to implement an automated check? (and then, “how should we respond to that?”)
2) Is this product worth testing? (essentially, is our prototype to the degree that we want to truly evaluate it)
[James' Reply: Other practices address them better.]
Did you EVER at ANY point in your testing career experience a scenario in which you thought “hey, this executable specification thing really seems to be helping this team move along”?
[James' Reply: No.]
I find it to be a valuable practice in my work because I use it as an investment strategy. I use ATDD and BDD to help guide my team to building a minimum viable product. Then once a certain amount of specs are achieved, I will switch my mode to critiquing the product, interactively.
I also wonder if, unknowingly, this whole BDD-ATDD thing is really a team prototyping technique. And it just so happens that once the specs are passing, some teams believe the product (at that point, a functioning prototype) is “good enough” to ship.
[James' Reply: You seem to be on the verge of comparing your favored practice to alternative practices. But I'm not seeing that, yet.]
I do value manual interaction with the product to test it. However, I also am interested in the concept of zero quality control, and try to explore both poles of behavior (prevent some failures, expose some failures). I’m not sure about the balance between the two. But I do keep my programming and testing chops exercised so I can temper my work based on assignment.
[James' Reply: Zero quality control? What does that mean?]
Not to candy coat, but I do sincerely appreciate the healthy antagonism you bring by questioning these practices that some of us unknowingly ritualize to the point of uselessness.
:patrick
October 27th, 2011 at 3:05 am
[James' Reply: Other practices address them better.]
I’m surprised I didn’t get a list of articles or suggestions with that comment. Though I am inspired to research, for myself, where other practices may excel.
[James' Reply: Patrick, what I've been trying to say about this BDD crap is that it's overwrought and underpowered. It's an excuse for dumping a lot of energy into a small gain. I don't need to give you articles or suggestions, other than, maybe, that I suggest you notice that before there was "BDD" there were people who talked together and wrote things down here and there. You may not believe it, but there is really is a history of practice that predates yours (and mine). I've never been on a project that was successful using BDD-like practice (I worked on an automation system to do something like that at Borland, for about a year, before giving up on it because it too much work for too little return), but I have been on projects that worked just fine without it.]
[James' Reply: You seem to be on the verge of comparing your favored practice to alternative practices. But I'm not seeing that, yet.]
What is the “favored practice” you mention? I didn’t mention a favored practice anywhere in my comment. I merely mentioned that I use this technique to help guide my teams. Maybe it’s the way I worded it that made it appear as though ATDD-BDD is “THE ONLY” way I approach the problem?
[James' Reply: When you mention the value of a practice, without discussing its cost or alternative practices, it does leave me with the impression that you favor it, yes.]
[James' Reply: Zero quality control? What does that mean?]
Yeah, I deserve an electric shock for using buzzwords like that. Based on what I’ve read, “zero quality control” means focus on prevention of defects at the point of origin. Stop production when an a problem is found within the product or delivery process and fix it there. Don’t focus on late-phase critique or assessment. I’m guessing you’d already heard of this concept, knowing how well-read you seem to be. This is not something I APPLY on my work in binary fashion. I seek out techniques to help teams build products that are WORTHY of testing, deployment, further effort, further investment. Applying a mindset of “prevent defects at point of origin” seems to be helpful so far, but it certainly is not something I apply without questioning it intermittently.
[James' Reply: Of course it's wonderful that people want to solve problems in better ways. But calling that "zero quality control?" That makes it sound like you want to abolish fire departments because you would rather that everyone just be really really careful around fire. Don't call it zero quality control (or zero defects, which is its more common handle). Instead call it self-improvement. And by the way, no amount of self-improvement, in a complex world, eliminates the need for looking at what you've done and appraising it critically.]
November 6th, 2011 at 1:46 am
BDD vs. Testing is a very interesting topic.
However, I propose a broader view : Specification by Example vs. Testing.
It seems to me that adopting a ‘documentation-centric’ model, as Specification by Example (see Gojko Adjic’s book Specification by Example, ISBN 9781617290084) and not the ‘system-behavior-specification-centric’ model as BDD or the ‘acceptance-testing-centric’ model as ATDD, would be benefic for testing, because it brings into the context the ideea of writing specifications using examples + automating some acceptance and rejection checks using executable specifications + obtaining a living documentation.
That means specs+docs+tests, under a single format, and a single document to be modified in case of a change request.
This can be done using Cucumber and Gherkin, and does not exclude exploratory testing.
What’s your opinion about this new view on the topic?
[James' Reply: I haven't read that book, so I can't say much about it. What I do know is that examples do not specify anything. An "example" is not even an example! The "exampleness" of a phenomenon depends entirely on how you interpret that phenomenon. Your mind is not a camera, and mental models are not merely images of the pictures that your eye took.
Examples in combination with mental models (that is to say, previous understanding) or sufficient explanation (which also relies on previous understandings) can be wonderful. I think it's a great idea to use examples. Use them liberally. But don't say that examples *are* the spec. That's not even true in the case where the examples are the ONLY use you will EVER make of the software.
Consider steganography. A steganographic message is an example of a message, obviously. But without an explanation of that, no one who views that "example" will be aware that a message is even there. In other words, you can demonstrate a feature, your user can nod and say "yeah, I like that" and later on it turns out the user was looking at and talking about some completely different aspect of the example than you had intended to convey. So, examples are in no way specification. But examples may illustrate and support specification.]
December 10th, 2011 at 3:03 am
In reading your comments to people, James, you often come across as very condescending even while you extoll the benefits of effective communication. A few of your “better” ones:
* [James' Reply: Come on man, use your head-- WE TALK TO EACH OTHER. We write, we draw, etc. I've been doing that for 28 years. Stop playing dumb!]
* [James' Reply: How about instead you stop hating talking to each other, develop your social skills, and engage people?]
* [James' Reply: I don't need to give you articles or suggestions, other than, maybe, that I suggest you notice that before there was "BDD" there were people who talked together and wrote things down here and there. You may not believe it, but there is really is a history of practice that predates yours (and mine).]
You also come across as vary dogmatic. You seem to dimiss other people’s experiences in many cases. (Again, I’m going by how you phrased your responses to comments.) I realize you have strong opinions and that’s great but your style of presenting them seems better suited for someone who wants to discourage communication. This post was my first and only viewpoint into your thinking and presentation style and while I probably agree with many of your points, I find myself really turned off by the way you communicate. I realize you probably don’t care about that one way or the other but I just wanted to give one person’s take on what I’ve seen in what is otherwise a very interesting post.
[James' Reply: Tatiana, I don't know who you are. But you know who I am. Why is that? It started a long time ago, when I first decided that it's important-- at least for me-- to be a defender and promoter of insight and excellence. It's so important that I will risk annoying people and hurting their feelings. It's like tough love. That's what I dish out.
I have been rewarded for being the way I am. I'm probably the single most famous tester in the world. Many thousands of people have seen my testing videos. You can Google me to verify this to your satisfaction.
I appreciate that there are people who are warm and friendly in the world. We need people like that. I'm married to one. And I can be like that, too, occasionally. It's just not my style.
One of the reasons I'm tough is that I'm 45 years old. I've been in the industry for 29 years. I've done a lot of special research that no other testers except those in my circle seem to do. And basically I know what the fuck I'm doing. People who dismiss the things I say are only hurting themselves. That's their choice.
Having said all that... I think you have picked a few examples where I am responding to fools or trying to wake folks up. If you read other comments I've responded to, you'll also find examples where I use a different tone. I am large. I contain multitudes.]
December 16th, 2011 at 1:31 pm
“Tatiana, I don’t know who you are. But you know who I am. Why is that?”
Actually, James, I had no idea who you were. I stumbled upon your blog by accident, while reading other blogs. I NOW know who you are.
I appreciate the insight into yourself. It’s been very enlightening, to say the least. As you continue “to wake fools up”, I assume you realize that someone who disagrees with you is not necessarily a fool nor are they necessarily ready to “dismiss the things [you] say.” Perhaps they are just learning and they do not have twenty-nine years of experience in the field yet. Sometimes we have to learn through the “slow path” and not just take something that an “authority” — even the “single most famous tester in the world” — has to say.
Forgive those of us who just aren’t quite up to your level yet. Hopefully we can all get to where you are and then we’ll all “know what the fuck [we're] doing.”
[James' Reply: This has nothing to do with agreement or disagreement, or authority. I don't teach from a position of authority. I told you those things I told you because you seemed to be of the opinion that my style is some sort of unfortunate aberration. It isn't. It's mostly intentional. I'm established in this craft.]