| || |
How best to approach Selenium testing?
(Sorry for the badly phrased title, but bare with me..)
I'm having a difference of opinion with a colleague wrt selenium. We have a current project to convert our existing manual test scripts to selenium tests. To spice things up, the website has zero requirements documentation, so our existing manual test scripts are effectively acting as our requirements (really an interpretation of ethereal requirement assumptions, but you take what you can get). I had originally envisioned a (close to) 1-to-1 relationship between the manual tests and the selenium tests. For me, that makes sense as the scripts are acting as our functional requirements so we need to achieve as much coverage of them as possible, as clearly as possible, whilst maintaining traceability with focused individual tests (and extending where appropriate). So we'd have things like
- Search titles for 'fire'. Assert all results returned contain 'fire' in their title.
- Search for documents published in the year 2000. Assert only and all documents published in 2000 are returned.
However my colleague wants to approach it from a scenario point of view. So you'd instead have something like
- The user wants to find a document on plumbing standards and knows it was published in the 1990s. They log in and search for plumbing. They then restrict the search to 1990-1999, increase their page size and search again. They find the document, access it and log out.
so we can test from a user perspective and generate requirements as well as test.
My opinion was that both goals (functional coverage and testing from a user perspective) are good, but using scenarios would result in confused tests with unfocused 'patchwork' coverage, reduce tracability, and increase the effort and cost of test design and maintenance.
I recommended using concise functional tests to achieve coverage of our 'requirements', extending when we uncover unstated or untested requirements. Once coverage is achieved for each script in turn, giving project time to designing scenario-based tests, not to achieve coverage, but to allow us to present to stakeholders/requirements-generators the high level of information they're interested in as well as hopefully generate requirements to improve the quality of the functional testing.
I appreciate that requirements generation probably isn't what selenium is for, but our job at the end of the day is to help increase the quality of the product and if no-one is willing to put requirements together then I think it reasonably falls under our remit to at least try and act as a catalyst, but I still think relying on a purely scenario-driven approach is a mistake.
It's also worth noting that it won't be us implementing the tests (in C#) but our system test team. They're quick learners, very keen, and more than capable of doing it but they are new to coding and so I think clarity of our methods and goals has to be a big concern.
I have a lot of respect for my colleague - he's much more experienced and to be frank more intelligent than I am and so I'm concerned that I may be missing something.
Does what I suggested sound reasonable? Am I being petty by sticking to (what seems to me to be) more traditional practices?
Re: How best to approach Selenium testing?
I can say two thing -
> Approach of writing selenium tests from requirements can be done right away.
> If scenario based tests are to be written so that non technical uses can also comprehend it then I suggest to have a look at Tellurium
which is built on the top of selenium and uses groovy as Domain Specific Language.
I know, I have not answered you question as this decision is to taken collectively by you and your team members. But there is nothing wrong in disclosing your views to others.