I came across this blog post from Brian Warner, titled "Some people hate BDD and Automation".
In short, Brain reacts to James Bach reaction that BDD is not the testing. And I agree with James.
However, BDD has its own benefits. In elevates the communication in development team.
Here is my response:
I must object at your final quote:
"""When you manually test, you are most likely always in the "black box." That's not necessarily bad, but you don't have any idea how something is made, or how it is working."""
Good tester (tester that James had in mind) do not need to know """How something is made""" in order to test the product. This is typical developer impression of tester. Tester can find a lot of bugs without that knowledge.
However, good tester will ask questions in order to find out how something is made. And in that process, tester will also find a lot of bugs.
Using exploratory testing (http://www.developsense.com/resources.html#exploratory) tester will find out how product is actually working, or does not working.
Problem with BDD is that while you are doing it, you are developer, not a tester. Tester job is to find out as many problems as possible (in time and budget constraint). Tester will document its finding by writing bug/issue reports. DEVELOPER automates those findings/bug reports, NOT TESTER.
My tweet about my respond trigger great tester, Eusebiu Blindu.
Here is our brief twitter conversation:
Eusebiu Blindu @testalways
@karlosmid for security bug bounties automatic scanners are very helpful. You can earn cash directly from its output results
@karlosmid but for the "nice" ones a complex work involving a multitude of actions is needed.
@karlosmid and i think this is applicable to general testing too.
Karlo Smid @karlosmid
@testalways Agree. One of my conversation with dev: "Someone who finds problems in our product, this is not a tester, this is hacker."
@testalways "Tester must do the checking of our product"
Eusebiu Blindu @testalways
@karlosmid yeah, when something cool is found in testing, the tendency is to strip from it and make it a separate area
@karlosmid developers have too much ego when it comes to testers and therefore their opinions should not be always taken in consideration
Brain responded on his blog with this.
He uses word QA tester (!@#$!), and he got wrong impression about my technical knowledge. What worries me is that he is doing interviews for hiring testers. The problem is that he actually hires developers.
And my latest respond is:
The last word in BDD is development. And I object that BDD is not coding. You have to write BDD code. And James objection is that tester is constrained with the BDD language.
Do you expect that users of your application will use it by writing BDD code? No, they will use keyboard, mouse, eyes, ears. What about users that are blind? They are using your application not because they like how your application is made (which technology is used). They will use your application because they want to fulfill some of their needs (e.g. I am using Facebook web application because I want to send a message to friend that also uses Facebook, not because I am crazy about Facebook web application.)
You probably have experience working with bad testers, because only bad tester will do such bug report (this is not working). But, with your impression what is good tester, that does not surprise me. Good tester will give as much details as possible in its trouble reports. As I stated before, he does not need to know from the start how something is made. He will ask questions to find out in more details where things went wrong. In your case, I know that I would hit F12 in Chrome browser to get more details about the error.
For whole team is better that in the beginning tester do not know how something is made. He will discover that by testing and asking questions.
Testers has a great amount of resources in order to elevate their skill. Very good starting point is "The little black book on test design".
And you got wrong impression about my technical knowledge. I picked a lot of web technology in my testing career. Which does not excludes me, for example, from testing business process in my local drug store. When I wanted to return some item after I purchased it I found serious bug that had legal consequences for the drug store. And I did not have great economy education.
And mixing QA and testing profession is so wrong. Here you can find more details about that topic.
I am not the one that hates BDD. BDD is great toll for communication between testers, developers, product owners. I just hate when testers have to do it, instead of developers. Testers must find as many product problems in the budget constraint they have. And tester has to learn topics from
"The little black book on test design", they do not have time to learn BDD. Testers will tell developers what to code in BDD (I am quoting Gojo Adzic here), in order to be safe on regression side.
And I contacted Michael Bolton to give his opinion on quote that I reacted on:
@karlosmid Reaction: "Manual" testing has no helpful meaning to me. I don't test with my hands. What does "manual" mean to you?
@karlosmid 2) Who says that manual == black box, or that I don't have any idea of how something was made or something is working?
@michaelbolton Manual testing also has no meaning for me. Quote is from blog post http://goo.gl/4oqSp .
@karlosmid Oh, that article. Heuristic: when someone uses a wooly term, their thinking on the subject matter around that term is wooly.
@michaelbolton Learned two things: new heuristic and new English word.
Labels: learn testing