Contributions
Re: Help needed to embed screenshot after each step in BDD Scenario
HiHarithaSaji , Can you give me some more details: - what version of IntelliJ are you using? - what version of Cucumber are you using? - are you running your scenarios against an Android device or a simulator (which version)? - are you running Cucumber from the IntelliJ integration or using a Cucumber runner (e.g. RunCukesTest)? - please share your CucumberOptions (if using the runner) or a screenshot of the relevant IntelliJ Run/Debug Configuration Thanks Seb4 years agoPlace Cucumber OpenCucumber Open6.3KViews0likes1CommentRe: The Secrets of Successful Collaboration - BDD
Hi Alex, First, BDD is focussed on agreeing and documenting behaviours, not testing. This may be why you don't see BDD implementations that support tree-like expandablestructures. In all but the most trivial systems, exhaustive path coverage is unattainable. Instead, metaphors such as the test automation pyramid were created to help us achieve confidence in a sustainable way. Narrow tests (at the bottom of the pyramid) give us confidence that the code satisfies the detailed requirements. Further up the pyramid there are tests that exercise interactions between a small number of components.This gives us confidence that the protocol/contract between the components has been correctly interpreted/implemented. Finally, at the top of the pyramid, there are a few tests that exercise the whole of the system. These should be thought of as smoke/deployment tests, giving us confidence that the system has been deployed correctly, is talking to the right end points, has the correct authentication tokens for the environment etc. Broadly, that it "hangs together". Combining these different types of test together can give us confidence that the system behaves as requested -- especially if the test doublesused to ensure isolation for the narrow and protocol tests are covered by contract tests.Other testing is also needed: exploratory, penetration, load etc. I've written a couple of blogs that partially cover these topics with this hereand here. When writing Journey Scenarios, we need to ensure that they are written using business language. They should express theintent of what the actor interacting with the system is trying to achieve, rather than themechanics of how they will achieve it. The technical details will be wrapped up in the automation code (step definitions) rather than being exposed to readers of the specification. However, the automation code is also used (and validated) in the narrow scenarios that guided the original implementation. To your final point, about supporting other stakeholders (e.g. Sales & Marketing), I have seen implementations where a single feature had several feature files, each of which targeted a different audience (in a recent example they were Sales and Actuarial). This is hugely beneficial for communication, but is definitely not motivated by a desire for exhaustive test coverage. In summary: BDD is not focused on testing Exhaustive path coverage is unattainable (so we lean on the test automation pyramid) Journey scenarios that use business language can be understood by (and are interesting to) less technical colleagues Documentation can (and should) be tailored to the specific stakeholders with whom you are collaborating Thanks Seb2.9KViews2likes1CommentRe: The Secrets of Successful Collaboration - BDD
Hi Alex, I'm glad you got some value from the webinar - which was focussed on collaboration rather than Behaviour Driven Development (BDD). BDD is not a QA activity, although one of the by-products of following all three BDD Practices (Discovery, Formulation, Automation) is a certain number of automated scenarios. The primary goal of BDD, however, is reaching a shared understanding of the required behaviour -- and capturing this using business-readable language. The majority of the behaviours that we describe in BDD scenarios are quite narrow, but there is a place for "Journey Scenarios" that document wider, end-to-end processes (see our forthcoming book, Formulation). These are useful to give the reader of the documentation an overview of how users will interact with the system and are not intended to replace other forms of testing that your organisation may require. It is our experience that product teams adopting BDD don't experience increased bureaucracy as a result -- and their product is higher quality and cheaper to deliver. Hope that helps Seb3KViews1like3Comments