I often hear people describe their automated test approach by naming the tool, framework, harness, technology, test runner, or structure/format. I’ve described mine the same way. It’s safe. It’s simple. It’s established. “We use Cucumber”.
Lately, I’ve seen things differently.
Instead of trying to pigeon hole each automated check into a tightly controlled format for an entire project, why not design automated checks for each Story, based on their best fit for that story?
I think this notion comes from my context-driven test schooling. Here’s an example:
On my current project, we said “let’s write BDD-style automated checks”. We found it awkward to pigeon-hole many of our checks into Given, When, Then. After eventually dropping the mandate for BDD-style, I discovered the not-as-natural-language style to be easier to read, more flexible, and quicker to author…for some Stories. Some Stories are good candidates for data-driven checks authored via Excel. Some might require manual testing with a mocked product...computer-assisted-exploratory-testing…another use of automation. Other Stories might test better using non-deterministic automated diffs.
Sandboxing all your automated checks into FitNesse might make test execution easier. But it might stifle test innovation.
RSS
Love your post. I felt the same about the automation culture changed recently, it is like moving to the next generation.
People as us, what you use. we use user story to tailor the test and it is BDD style. What you use too? we use angularjs.
I'm suspicious of most of the "trends" in software testing, especially automated testing.
BDD/TDD/ATDD. . . these are all fine and good, but like anything else, they will never work perfectly for every scenario.
Unfortunately, people who follow these practices often act like it is heresy to suggest otherwise.
Yes, the trends in software test automation have seen pretty good varieties and more are yet to come.
It's a really nice blog.
Keep Sharing. Great Work! :)