# Power Hour - Test Cases & Scenarios **URL:** \ **Category:** Archive\ **Tags:** strategy, automation, process, power-hour\ **Created:** [23 May 2019 09:30 UTC](https://club.ministryoftesting.com/t/power-hour-test-cases-scenarios/25867 "2019-05-23T09:30:55Z")\ **Posts on this page:** 9\ **Page:** 3
**Author:** ![gasparnagy](https://sea2.discourse-cdn.com/flex020/user_avatar/club.ministryoftesting.com/gasparnagy/32/5688_2.png) [@gasparnagy](https://club.ministryoftesting.com/u/gasparnagy)\ **Post date:** [29 May 2019 19:14 UTC](https://club.ministryoftesting.com/t/power-hour-test-cases-scenarios/25867/42 "2019-05-29T19:14:44Z")
> [@jonas](#): > > What are you recommendations when changing from traditionally SWRS development and start using TDD as development method? Oh. This is hard. With agile methods, the team has much more options to influence the solution. So don’t try to just replace one element of the old process, but thing out of the box. The things go wrong when the team just “replaces” the “XYZ-tests” of the old process with TDD and then realize that it is not conveniently fitting. Not a very detailed advice, sorry. ---
**Author:** ![gasparnagy](https://sea2.discourse-cdn.com/flex020/user_avatar/club.ministryoftesting.com/gasparnagy/32/5688_2.png) [@gasparnagy](https://club.ministryoftesting.com/u/gasparnagy)\ **Post date:** [29 May 2019 19:18 UTC](https://club.ministryoftesting.com/t/power-hour-test-cases-scenarios/25867/43 "2019-05-29T19:18:16Z")
> [@dimi](#): > > What would you consider a good quality BRD and Solution Design document for the successful creation of test scenarios? What will be the first thing to look for? A good preparation for the scenario-based story implementation is to have a good list of expectations in a from of business rules or acceptance criteria, but with the openness to change or extend them based on the discussions with the team. From the solution side, I think having a good design concept is a good starting point. I definitely would not go into detailed solution design decisions upfront. ---
**Author:** ![gasparnagy](https://sea2.discourse-cdn.com/flex020/user_avatar/club.ministryoftesting.com/gasparnagy/32/5688_2.png) [@gasparnagy](https://club.ministryoftesting.com/u/gasparnagy)\ **Post date:** [29 May 2019 19:24 UTC](https://club.ministryoftesting.com/t/power-hour-test-cases-scenarios/25867/44 "2019-05-29T19:24:09Z")
> [@sgodoy](#): > > I want to know what Gaspar think about use “Scenario Outline” for the BDD cases. Its a good idea? in wich cases? We will release a new increment of our beta book (Formulation, [BDD Books – Formulation by Seb Rose et al. [PDF/iPad/Kindle]](https://leanpub.com/bddbooks-formulation)) this week. In the new Chapter 3 we also talk about this. Generally the best approach is to see whether the problem you try do describe is calculation-like (data-driven). For those kind of problems, a table with the input-output pairs is an efficient way for discussion and understanding. For these problems converting these data-variation tables to Scenario Outlines is natural and it documents the results in an clear way. Other problems are more about the workflow or the behavior. For those cases, using Scenario Outline and test the things with a couple of more data points (just because we can) is usually an overkill. ---
**Author:** ![gasparnagy](https://sea2.discourse-cdn.com/flex020/user_avatar/club.ministryoftesting.com/gasparnagy/32/5688_2.png) [@gasparnagy](https://club.ministryoftesting.com/u/gasparnagy)\ **Post date:** [29 May 2019 19:28 UTC](https://club.ministryoftesting.com/t/power-hour-test-cases-scenarios/25867/45 "2019-05-29T19:28:01Z")
> [@emna\_ayadi](#): > > Another question how can we combine model based testing ( **MBT** ) with BDD cases? > And is it worthy ? Yes, this is definitely an interesting area that will develop further. I haven’t seen much concrete application that would really combine these, but I know about a few people who try. I was playing with combining property-based testing with BDD once (see [Property-based BDD Examples with SpecFlow and FsCheck - Gáspár Nagy on software](http://gasparnagy.com/2016/11/property-based-bdd-examples-with-specflow-and-fscheck/)). ---
**Author:** ![gasparnagy](https://sea2.discourse-cdn.com/flex020/user_avatar/club.ministryoftesting.com/gasparnagy/32/5688_2.png) [@gasparnagy](https://club.ministryoftesting.com/u/gasparnagy)\ **Post date:** [29 May 2019 19:31 UTC](https://club.ministryoftesting.com/t/power-hour-test-cases-scenarios/25867/46 "2019-05-29T19:31:42Z")
> [@asoc](#): > > How do you make test data considerations a natural part of your scenarios? Test data is usually a requirement for any scenario to be executable but it never seems to be an organic part of behaviour or logic models for writing tests. Jenny Martin has a very good concept that is called the Data Personas ([Data Personas | @Jennyjmar](https://jennyjmar.com/2016/04/15/data-personas/)). It is basically the same UX “persona” concept applied to any other data as well. I think stealing some techniques from UX how they manage and document their personas would be also beneficial for managing test data. ---
**Author:** ![gasparnagy](https://sea2.discourse-cdn.com/flex020/user_avatar/club.ministryoftesting.com/gasparnagy/32/5688_2.png) [@gasparnagy](https://club.ministryoftesting.com/u/gasparnagy)\ **Post date:** [29 May 2019 19:33 UTC](https://club.ministryoftesting.com/t/power-hour-test-cases-scenarios/25867/47 "2019-05-29T19:33:49Z")
Wow! Done! Thanks everyone for joining. If you have any further questions drop me a mail (gaspar at specsolutions.eu) or find me at the [London Testers Gathering Workshops](https://ti.to/mot/london-tester-gathering-workshops-2019) in June! Have a good evening! ---
**Author:** ![lisacrispin](https://sea2.discourse-cdn.com/flex020/user_avatar/club.ministryoftesting.com/lisacrispin/32/556_2.png) [@lisacrispin](https://club.ministryoftesting.com/u/lisacrispin)\ **Post date:** [29 May 2019 21:49 UTC](https://club.ministryoftesting.com/t/power-hour-test-cases-scenarios/25867/48 "2019-05-29T21:49:36Z")
Thank you! I like the idea of intention versus mechanics. ---
**Author:** ![gasparnagy](https://sea2.discourse-cdn.com/flex020/user_avatar/club.ministryoftesting.com/gasparnagy/32/5688_2.png) [@gasparnagy](https://club.ministryoftesting.com/u/gasparnagy)\ **Post date:** [30 May 2019 08:19 UTC](https://club.ministryoftesting.com/t/power-hour-test-cases-scenarios/25867/49 "2019-05-30T08:19:42Z")
> [@lisacrispin](#): > > Thank you! I like the idea of intention versus mechanics. Yeah. We “invented” the intention/mechanics pair with Seb in the scope of the Formulation book, because the declarative/imperative terms are a bit too techie and therefore not so broadly understandable. ---
**Author:** ![gasparnagy](https://sea2.discourse-cdn.com/flex020/user_avatar/club.ministryoftesting.com/gasparnagy/32/5688_2.png) [@gasparnagy](https://club.ministryoftesting.com/u/gasparnagy)\ **Post date:** [30 May 2019 08:29 UTC](https://club.ministryoftesting.com/t/power-hour-test-cases-scenarios/25867/50 "2019-05-30T08:29:23Z")
> [@anastasiya\_as](#): > > How huge can be those GUI automated tests? How many steps should one test consist of? I seem to have missed this question yesterday… The automated tests/scenarios should be focused, regardless whether they are automated through the GUI or not (see more on this at the question about manual/automated tests above). In many cases this can be achieved with a scenario that has not more than 5 steps. (This does not necessarily mean that you have only 5 UI actions, because one step can trigger multiple UI actions as well.) With UI tests the key challenge whether you can automate the preconditions (the “Given” steps in Gherkin) in a robust way, because the most of the instability and slowness is actually caused by these steps. Making them robust might mean that you bypass the UI (e.g. setup the necessary data through the REST API or programming API of the application) or make testing backdoors so that the test can jump directly to the UI to be tested (e.g. you should not need to automate clicking through a wizard just to be able to test the last page). In general, GUI tests should only be used for limited number of tests. The majority of the testing should be and can much better be performed with API-level integration tests or even unit tests. [Previous page](https://club.ministryoftesting.com/t/power-hour-test-cases-scenarios/25867.md?page=2)