Creating selenium scripts from requirements

Question

Is it possible to create selenium webdriver scripts just looking at test cases, use cases or requirements. I always wonder how the scripts could be created in advance when the functionality has not been implemented in the product. How could you get the locators and all the details of the application flow to add in your scripts? In a fast paced environment where testers are mostly writing test cases before development, how an automation can be done in that phase by just looking at the requirements?

In another scenario, testers are delivered with the implemented functionalities in the environment where developers keep making changes by adding or improving functionalities, the test script fails at some point due to those changes.

I sometimes come across this question, Have you created selenium scripts for new functionalities? And I ask myself the same question again and again, is that even possible?

From my understanding, a tester need a stable test environment to create scripts where functionality has been completely implemented and no further changes being made by dev team.

Answer 1

Is it possible to create selenium webdriver scripts just looking at test cases, use cases or requirements.

Yes, it is possible. One way I've done these in the past is having the requirements and the UI mockup of a page or feature. If you can align those two together, then you can start creating PageObject classes for that page/feature. You create the constructor, the element variables (without the specific locator), and any methods that use those variables. You can also create the test cases the implement the PageObject and even start adding your assert statements.

Then, once development is finished, all you need to do is find the right locator (css selector, xpath, id, class, etc) and plug those into your element variables in the PageObject.

Will it always work exactly as written? No, but you just gave yourself a great head start and now you just need to modify and adjust a few things to get it working.

The key to getting this going is having the UI mockups. Those give you enough of the application flow, the element types (buttons, links, forms, etc) to work with, which you can plan for in automation tests. If you're just going of the requirements or use cases without any UI, then it's much more difficult to get this head start.

I've also been asked this in interviews before and gave this answer, which always got a good reply.

In another scenario, testers are delivered with the implemented functionalities in the environment where developers keep making changes by adding or improving functionalities, the test script fails at some point due to those changes.

In this scenario, while you can doing some of the things described above to get a head start, you can also consider waiting for application/feature stability before completing any Selenium work, especially if there is potential for element locators to change. If the UI or the application logic drastically changes, then no head start will help.

I've had great success over the years of doing it this way regardless of a new feature/page.

Answer 2

While there is no reason that you couldn't do this (and I have before) there are some reasons that you might not want to.

Obviously you couldn't use a browser recorder to write the script, but if you're comfortable writing them by hand, then you just build the test. So, if you wanted to test that an email form checks for formatting, you could do something like:

 elementEmail = driver.findElement(By.id("email"));
 elementEmail.sendKeys("myemail");
 driver.findElement(By.id("sendbutton")).click();
 errorMessage = driver.findElement(By.id("error")).getInnerHTML();
 assert.areEqual(errorMessage, "This is not a valid email address");

And it'll fail until the work is done.

The big hangup I usually have with this is that selenium is so implementation-dependent, so you can get into situations where you have to know the implementation before you implement it so you can write the test. In addition, a lot of functionality just shouldn't be testing at the interface level. I don't want to see if I pull the right info from the database at the interface. It's much more effective to test that with a unit test or integration test.

So, while the direct answer to your question is "Yes, you can." I would take a good look at some Acceptance-Test-Driven or Behavior-Driven approaches that use tools like Cucumber, Specflow, or Fitnesse. You can use Selenium to build the guts of your test in the cases where it is needed or not if selenium isn't the best choice. The tests you write in these are usually not implementation-specific which gives the team as a whole a lot of flexibility in deciding how to fulfill the test case.

Answer 3

The discipline you are describing is called Test-Driven Development (TDD).

In TDD, one starts coding by writing a new test (1), but only until the moment the test fails (compilation errors is a test failure).

Then one jumps to the production code and writes the simplest and dumbest code to make the test pass (2).

Then one continues in the product code and refactors it (3).

After the improvement in the production code, you may want to refactor your tests using mutation testing.

When everything is clean and generic, you continue to the next step test and repeat.

(1) - Defining the software specification;

(2) - Implementing the software specification;

(3) - Generalizing and cleaning the software.

The process may seem long, but since you are moving in the smallest steps, it usually takes 30-60 seconds. Proefficients TDD programmers seem like maniacs jumping from test and production code files: Kent Beck has some videos showing his programming like this.

I would suggest watching Robert Martin's talk on TDD. Many other blogs and books on the topic exist out there.

One process that can be interesting is to pair with the developers. You write the smallest thing to make the test fail, the developer makes it pass, you both refactor in pairs, and repeat.

Answer 4

It sounds like you could use Cucumber; a tool used for Behavior Driven Development. The process goes something like...

1. Review Acceptance Criteria in the ticket
2. Write down each Scenario in your .Feature (Gherkin) file
   • This should be done by the Developer before they write a single line of code, so as to better understand their task before completing it
   • Reviewed by BA and QA as it clear text in git or can be copy+pasted into the ticket
3. Dev writes code for the new functionality
4. Now the Scenarios can be wired up to test methods via Step Definitions
5. Tests run and pass before the PR (new feature code + tests) is submitted