1

My question is also related to who does what in typical BDD. My understanding, Product owner comes up with User Story (may or may not in Gherkin), QA writes Scenarios for End-to-End testing(in feature files), Dev writes his code (how and where, does he follow BDD as well?). At this point if the Dev writes the automated Unit Testing, whether this can be leveraged by the QA for End-to-End or they can be absolutely different?

My question is how the Dev and QA leverage each other's work in terms of coding while following BDD. I am not sure how to connect the dots.

Lets take the example of a JAVA based application and QA is already using Cucumber with Selenium Webdriver for automated testing.

Anp
  • 47
  • 8

3 Answers3

3

If you are practicing BDD, then you would create the specs first (define the behaviour) and only then implement this behaviour (i.e. write the production code). On which level you define the behaviour is less relevant, although at the unit test level most people would call this "TDD" (even though it's not necessarily test driven as much as the "test" is the design for the code you want to write). The developer and QA would collaborate on defining the behaviour and implementing the tests and production code. Ideally, I'd expect different tests at different levels, the final (highest) level being E2E tests. I would also make sure not to retest everything on every level, but to only test the things that make sense at that level. For instance: a method that calculates a value should be unit tested, how that value is displayed in the front end would be tested in the front end (can still be a unit test), how to get the value from the backend would be an integration test, etc. You might be interested in reading more about BDD either here: https://docs.cucumber.io/bdd/, in any of the related blogposts here: https://docs.cucumber.io/community/blog-posts/ or in The Cucumber Book / The Cucumber for Java Book.

Marit
  • 2,399
  • 18
  • 27
  • A lot of what you have mentioned makes sense to me. However, a part of my initial question was also where you kind of stopped. As the QA may proceed with E2E for backend testing, can s/he leverage the same BDD? As a user, it may not make sense. As the user would care less what's going on behind the scene. Is it fair to say that BDD is not meant to be used for E2E? – Anp Feb 28 '19 at 16:15
  • Actually, I'd argue that BDD is very suitable for E2E as that is the actual behaviour you are trying to describe and build. But if you are using Cucumber (or similar tools) to *automate E2E tests* after an application has already been built, you are not doing BDD (as it is not driving development). – Marit Mar 01 '19 at 13:37
1

I am working in a project applying BDD. When BA creates a ticket and writes down all scenarios, it is assigned to a developer. Meanwhile QA also create a QA ticket to work relevant to that DEV ticket. But QA will start writing automation test only when the code of DEV ticket is in review or Already done. It is because the feature need to be available for testing. when QA starts coding, all unit tests for that ticket should be done. So to leverage the work of DEV and QA, we proposed a solution. Although it is in pilot, not official applied. QA needs to involve in unit test review. What it means is s/he needs to look at all unit tests and give a comment if s/he think there are some more cases need to be added or removed. And also QA can get the test coverage in unit test and decide to write automation tests according to that coverage. Here the QA need to actively involve and decide what to test in e2e. It would easier if you can discuss face to face with the developer to get the unit test coverage but I think it is more objective to review the code. Also f2f , not any DEV willing to tell a QA what his work. However, this solution requires more skills in a QA engineer. Not any QA can read and understand the DEV code.

This is the idea that our QA team given in current project, I don’t know if any project apply this. This is really good question. I also want to hear more opinions/ideas from other people who also wish to leverage the work of QA and DEV.

Thach Hoang
  • 56
  • 4
  • True that. I am still struggling to understand or find an example from the real World where all the User stories after being groomed and decomposed to become Scenarios and then taken forward for UAT. I have no problem in understanding the Unit testing part of it. But, what happens next is my question. @Thach Hoang, I have followed exactly something similar to what you are doing as well. But the question remains, is that true BDD what Dan North has started? – Anp Mar 16 '19 at 23:07
0

How about BDD/TDD peer programming between Dev and QA individuals resulting in producing e2e testing automation.

This could entail

  1. E2e services and app deployment automation (one off - ideally to work on any engineer laptop)
  2. Use case setup
    • set up behavior application state (update data/db schema in datastore/database, config files if feature uses key switch)
    • decide on clear definition for behavior input and output
    • define feature trigger and validation rule
    • implement application logic
    • verify validation rule with implemented logic

I may sound like a lot of thinks to do at once, thus lot of folks would be discourage implementing e2e, I guess with the right tool set the process can be super easy to implement.

Adrian
  • 1,973
  • 1
  • 15
  • 28
  • I kind of get what you are suggesting. However, my question was more of a what part, not the HOW. Let's say the Dev/QA/PO comes up with a User story which later got converted to a Feature and then (let's say) a Scenario. Now the Dev starts the classic TDD approach in which (s)he codes and refactors until the Scenario passes. This is the back-bone of TDD or even BDD per se. My question is, then what? How the Automation QA picks it from here for an E2E testing. As the E2E will be around a combination of things while the former was not. Can he leverage the already written code for E2E testing? – Anp Mar 10 '19 at 02:58
  • 1
    @Anup - I guess it all comes down to the automation aspect, in our case we used it for almost everything from setting dev/staging environment, for reproducing production issues, and most importantly e2e testing. All that said there are lots of overlaps between all of these, where a certain modularized e2e workflows are responsible for setting up app system, datastores/database followed by build and deployment. automation, finally regression the most complex workflows focusing on all application input and output. – Adrian Mar 11 '19 at 02:27
  • 1
    In reality, once you have app data model addressed within e2e, all subsequent use cases bare lots of similarities. There is a moment where one makes the call that the only way forward is E2E or TDD like we did, clearly, at that point, we already had multi-stack (java/go/javascript) application in place, so what we did was to freeze application behavior with e2e tests based on semi-automated regression script used formerly by QA, from that point on we just explicitly implementing TDD – Adrian Mar 11 '19 at 02:28
  • 1
    All that said one of the most challenging aspects of TDD/E2E we found was data organization especially that quarterly we're producing hundreds of application behavior related use cases across a various team for the shared app. Here are some various data organization strategies in detail that help: https://medium.com/@adrianwit/killing-data-testing-swamp-6c3e11fb92c6 – Adrian Mar 11 '19 at 02:28