1

In manual testing, we create separate tests for a certain function. Example scenario is this: I have 2 radio buttons and a search dropdown. Each of the radio buttons have difference departments listed under a dropdown. You can use these either logged in or not. In order to test it, I test the first radio button and check the dropdown list if the departments are present. So 1 test case have passed. Then I do the same thing with the second radio button. It passed as well.

Now in automation scripts, I created a test script that is based off of these functions. What bothers me is that how do I run these scripts? Should I also follow the same procedure like what I do in manual testing, it is just that my scripts do the work for me? Or should I run both test scripts(for 2 radio buttons) altogether? If I do that, I'd get an error on stale element, or element not found. But if I run one test script at a time, I get the result I want. If I want the test to fail I change the expected value. Which is the best practice I could do? Thanks

Improve this question

2 Answers 2

Reset to default
1

You should have 2 test cases because they have difference steps and difference expected result. Run the test case one by one. If you want the test to fail, change the expected value to anything else. It sounds like you are not using testing framework. If you are using xUnit, it will help you to manage test fixture, assertions, ...

Improve this answer
1
  • Hi @Buaban, thanks for your input. I am using protractor and I am very new to it and to the functional automation stuff
    – Marj
    Jan 29, 2016 at 16:20
1

The main principles to guide you here are:

  • Each test should be independent. It should perform its own setup and teardown and after running leave the system in the same (initial) state. This will help avoid issues such as "But if I run one test script at a time, I get the result I want" The only exception to this is system-wide seed data needed for testing.

  • Each test should test one thing. Tests can share setup/teardown but should break out specific values that need to be tested into individual tests. When tests break it should be due to one specific thing making diagnosis and change relatively easy.

  • Seed data needed for the entire test run should be clearly identified and created. It should be read-only reference data that is not the same as the transaction data used for the individual tests. Example: zip code data for the US. Even in these cases seed data can often be minimized or sampled to keep it small and tests fast.

  • In some cases the same code that is tested in one place will be used as the setup (and teardown) for a different test. This is ok.

Improve this answer
1
  • so it means, referring to my above scenario, I'd like to test one radio button(Department) for search. If it is an independent test scenario, I would do, login > Validate the home page > Select the first radio button and click Search > Validate results > Logout.. After the validate results, I won't click another radio button again to search for another department?
    – Marj
    Jan 30, 2016 at 20:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.