Development skills for test automation

The more time I work with test automation the more times I'm assured that there's nothing to do in this area without development vision of the overall solution. Where it is essential?

1. Test automation framework - it's first thing we encounter when we create tests. And it brings us to such things like design patterns, re-usable functionality, coding standards and various practices to increase maintainability of our tests. On test design stage test automation is purely development. If you missed something here get ready to problems in the future.
   
2. Attitude to testing solution - recently I encountered some unexpected problem with test engine we use for our testing. This engine was written some time before I started working with it. And the main problem was with batch execution when test suite contains only one test. It appeared that engine script operates with range and it doesn't handle case when range starts and ends with the same value. In comparison to it, everytime I see some code samples I see a lot of parts handling such trivial situations like null pointer, incorrect result of previous operation, connection wasn't opened etc. Development has some discipline for such trivial operations handling and there's a reason why. Real product for many users should work under different specific conditions and it's necessary to support the same work capacity or at least make application work the way it's supposed to work. Talking about testing solution I can say that usually it's built in a rush and a lot of things are maintained during all the period this testing solution is in use. Maybe this is the key factor why originally the quality of such solution isn't good. And eventually, each part of this solution is refactored one by one to provide stability and robustness of tests. And sometimes the question appears: "Why it wasn't done this way originally?" One of the most reasonable answers is: "We didn't handle a lot of necessary cases".
   
3. AUT understanding from inside - sometimes people don't understand the nature of the technology they work with while interacting with AUT. Sometimes they don't know how each particular control or service is built. This raise another problem. In these cases people look for direct solution though troubles actually appear in non-trivial cases when such solution doesn't work originally. Typical example is with Selenium interaction with Save file dialog. From what I see it's one of the most popular questions related to Selenium. And if only these people understood simple fact that Selenium interacts on DOM level (and Save dialog is out of DOM) there were no questions like that. Similar thing is with various custom controls where all is based on divs, frames though it looks like buttons, text fields or so.
   
4. Auxilary utilities - there're a lot of cases where basic abilities of testing solution is not enough. For this purpose there's necessity to create some additional utilities simplifying our life. It can be various code generators, parsers, services or so. Generally speaking it should be some kind of software product.
   
5. Skill-set - a lot of test automation tools use their own built-in languages. A lot of them operate with scripting languages like VBScript with their own limitations though these languages are not related to programming language for AUT development. This originally creates big gap in interaction with development and testing. Both sides have no idea what others are doing and how they do their things. Another problem is in career growth. Imagine you learnt some tool with its own specific language and mastered it on expert level. What would you do if this tool become out-dated or another tool replaced current one? Actually you have to learn a lot of things from the scratch and your previous knowledge becomes just another information trash. Of course, a lot of approaches are left the same butimplementation is always different.
   
6. Costs - usually automation tools are quite expensive and require additional licences. And such expences make testing more expensive. If we invest too much into testing we can come to the point when it's more effective to work without testing than with such test automation. In such cases there's usually one solution: get rid of such testing at all. It's clearly seen for small projects when we can work with minimal testing. At the same time we can use development solutions developers use. Usually it can save a lot of costs since they're less expencive and we always can ask developers for help in case of some difficulties.
   
7. Best practices - it's not a secret that development processes and practices are developped during longer period of time than corresponding practices in testing. So, why should we get rid of them? This question is necessary because a lot of practices and toolsets introduced into test automation were actually used in development for many years before. E.g. source control systems, continuous integration, automated code review, auto-documenting etc.
   

So, we shouldn't scare development stuff. We shouldn't scare things making us stronger as specialists. Having some development background we can speak the same language with AUT, we can speak the same language with developers. And this changes attitude to us. Since now we are no longer boring people digging into every little thing trying to get any mismatch. Since now we can be a specialists who can understand overall system from many points of view and we can pay attention to really necessary problems prior to some minor mismatches. At the same time we can find out the area where problem appears to simplify developers work on fixing it.

And in general, having additional abilities we can work more effectively from many points of view. It's performance due to various generators, it's testing solution quality and reliability due to best practices and various approaches introduction, it's more localized and well-described defects.

So, if you are involved in test automation and you think you're tester I recommend you to evolve to SDIT.