| || |
Question for QA Managers and Directors
As a very experienced functional BB QA Engineer I'm looking at moving into the Automation domain more seriously. My areas of expertise fall into Networking, Storage and Virtualization. Most of the QA Automation is coded in Perl, TCL and Python at the companies I've worked for. Presumably, this would be the direction to go in if I wanted to stay in these industries. The other case is many other industries are aggressively moving into
I want to get the most millage out of the training I will be taking, so I'm conflicted on the best route to take and wanted to get some feedback and advice from QA hiring managers and directors out there especially those located in Silicon Valley.
Option 1: Get the training needed in Perl and Python and stay in the technology domains with the most years of experience.
Option 2: Get training in more web/database automation tools such as PHP, SQL, JUnit, API test: SOAP and REST protocols and venture outside into domains of less or no experience.
** Please provide honest and unfiltered feedback
I am not a manager or Director but i have been working since 1983.
It seemed to used to matter more what I studied. i could predict what would happen if I learned something new.
Now it seems different. Anything I learn leads me to learning exponentially that there is so many more things to get involved with. I started to learn about Selenium. I found out about ANT, Java, Eclipse and 20 other things I could spend months learning about.
I feel that things are moving so fast that you should study anything to "stay in the swimming pool". Keep track of things you would like to come back to later.
I don't think it matters which path you take. You will probably wind up at a place in 5 years that does not even exist today.
I don't think management is going to give you any better answer than just a developer.
The tech stack will follow whatever makes the developer most productive. Most of the time, the automation tools chosen is basically an after thought which is generally the same tech stack and the software to simplify the build process and reduce knowledge gap between devs and SDETs.
If an SDET is going to be writing a lot of automation hooks, than it doesn't make sense to use a different language than the SUT. Having different languages in the test platform and SUT causes the complication of having to maintain service contracts and deal with cross platform build and serialization issues.
In terms of what education gets you the most bang for your buck. I'd say put more effort into learning frameworks and programming patterns than languages. Most developers and SDETs will never have their choice of ideal language to work with, it's just what the company is already using. I'm generally learning a new programing language every 2 years, it's inescapable. While languages change, programming patterns are something that stays more or less the same. Frameworks however are mostly language specific. But there are frameworks that are cross platform like Selenium. Generally automation specialists will know a few Unit testing frameworks (Junit, NUnit, TestNG), communication frameworks (like RestKit) mocking frameworks (like Mockito), and driver frameworks (like Selenium). Usually if a framework is good, there will quickly be clones of that framework in other languages.
Selenium is cross platform, making it a good one to learn for long term career.
Mockito is another good one, it has implementations in many different languages.
JUnit, TestNg, and NUnit are very similar. It's gone to learn one, but understand the underlying concepts so you can apply to different environments.
Generally good frameworks will be copied and re implemented in different languages. For example, you can find RestKit, Selenium, FactoryGirl, Mockito implemented in many different languages. This makes learning good frameworks greater mileage than learning individual languages.
With the learn frameworks not languages out of the way,
- Many native desktop apps are moving to the Cloud (like Office360), or becoming hybrid apps that provide a thin wrapper around a web app, since this is easier to manage updates and cross OS compatibility.
- Web is here to stay. Since web app does not require installation, this makes it easier to create simple services without the installation headaches.
Thank you very much for the feedback, David.
Given my core technical competencies and background, I rarely ever see these frameworks (Junit, NUnit, TestNG, Selenium) used in the environments I've worked in. Most of the legacy test harnesses support Perl, TCL and Pyhton almost exclusively. The juncture I'm at is; build skills in these programming languages and leverage my experience base or venture into some of the Unit testing frameworks you mention and try to break into an environment that I don't have a background in. Of course I can do both over time, but I like to see what other's have experienced.
This is why I was seeking some honest feedback from management folks who make these decisions. The market has gotten very rigid over the last few years. That's why I want to make a very strategic decision when allocating time and energy into learning something new.
Here's a dirty little secret (David Lai already mentioned this): for the most part it doesn't *matter* what language you learn. What matters is being able to take a problem ("I need to automate feature X") and break it into the logical steps that a computer can understand.
Every language can do this. Every language has some form of branching (IF/ELSE, CASE etc), some form of looping (WHILE, FOR) and some form of breaking things into functions/methods/routines that take in parameters and do something with them.
The one caveat I'd make is that if you start with something that doesn't have pointers, it's much more challenging to move to a language that has pointers than it is to go the other way.
Excellent Feedback and much appreciated. Thank you.