Hot answers tagged

3

I would recommend doing both approaches, for different purposes. Given / When / Then is good for testing communication. This format brings assurance that what you are testing is what the business owner / requirements writer intended. The bugs mainly caught by these tests, IME, are ones where the business owner intended X and the dev did Y. Often, these ...


2

The more detailed the test case, the more time you will spend on revisions as the software evolves. The less detailed the test case, the more you are leaving it up to your testers to read between the lines. Maybe you should try it both ways and see how it goes.


2

This looks fine. BDD feature files is meant to be at a level to give useful information to product folks. In each step you can call lower level steps if you want to give more specific information (or more reusable actions) For this one for example Given I am signed in It might just call within it // enter the username GivenIEnterInTheField(string ...


2

Run all the tests just right after the build as soon as possible, before deploying to the test environment. Developers should have feedback about their check-ins as soon as possible. Also you say the test-env is used for manual testing, why would you want to risk deploying a non working build. Certainly if you could have run the tests first. In short the ...


2

If QA and DEV environments are equal (have the same dependencies installed, the same build, etc.), there is no much sense to run acceptance tests on both of them, since it will be just duplicated execution and additional overhead in terms of analysing test results on two environments instead of one. Acceptance tests are the tests which provide you ...


1

In my project I created common step definition file with common method like login, logout, selecting checkbox(s), setting value in input fields, taking screenshot, selecting value in dropdown, selecting option in radio button group etc. and created separate step definition files for feature specific steps. And I was easily able to manage complete testsuite ...


1

to my experience in automation test, it is more valuable to run in qa environment but you should communicate with developer frequently on changing part which may affect your automated test cases so you can prepare your automated test cases during development phase and give priority to more static features of the product to prevent updating automated cases ...


1

From my experience at work a feature is a user story. There's a 1:1 relationship between a feature (as in Specflow) and a user story (as in BDD).


1

Fixed the issue by removing '/' before the 'src'



Only top voted, non community-wiki answers of a minimum length are eligible