Diving Back into Selenium and Getting Somewhere!
Recently I've gone back to using Selenium and started to really get comfortable using it. One of the problems that I constantly face when using Selenium is not having good example and looking at Selenium as a whole in whether it is worthwhile. My problems only get work when I have to ask me whether to use the Selenium IDE or the server package. Which is more scalable to do? Which one is better to give to a team QA that non-technical? Some of these questions can be answered on the Selenium site but some of them depend on your work environment and how much time you want to spend on creating a system of some kind to do all that.
What you really want for all project is something that you can automate across popular browsers not just a single one. Plus avoid doing a dry run every time to correct your UI tests. So the IDE which really a plugin is not going to do that for you but even if I gave it to a QA non-technical team I don't think it would be used effectively. Instead I think what people need something more customized to a simplier audience.
Example Project: Login-AutomationIn the example I took a lot of notes from John Sonmez on Pluralsight which was in his videos for creating a Selenium framework. However I didn't get the whole picture until I watched a little bit on the Selenium IDE videos. After taking it all in, I took the example John provided in his videos and modified it to be more general. I hope to use it as a starting point of over projects.
I think Selenium is a must in projects where you have tightly coupled data views. Regardless of your work environment you should not use Selenium to test you're code but final results of an Application. My reason behind this is Unit Testing and Continuous Integration still provide a lot more details and bug smashing for development. It is a lot of work to create a framework with Selenium and there's no guarantee it will catch everything but there's no harm in adding it to your work environment espically with the issue state above. If you have "tightly coupled data views" then unit testing can be difficult to impossible.