I am a SQA professional with 15 years of experience. My industry experience is in games and in social network mobile platforms. I'm a very accomplished team leader and mentor, with more than a small amount of department and project management experience as well. I've founded new QA departments for small companies and managed up to 65 testers in large ones. In other words, my resume is fairly robust and my QA fundamentals are rock-solid.

However, my experience is at least 95% black box. And if I am seeing the writing on the wall correctly, the need for black box QA professionals is on the decline, while the need for SQE professionals is on an inevitable rise. I'd like to see my pool of employment opportunities grow over time rather than dwindle.

I've an opportunity to take myself out of the job market for the next 6-12 months, during which I'd like to do some combination of: - learn some programming - learn how to use some test automation tools - acquire an overview of SQE implementation

I won't be able to take any physical classes, but will have plenty of time for reading, online classwork and maybe find some open source projects to practice on. Obviously I don't think that 6-12 months is going to make me into a competent SQE. And my goal is not to entirely reboot my career and start again as a dedicated SQE. But if I could learn enough to be able to 'speak the language', hold my own in a strategy meeting, function as a competent liason between SQE and other departments, etc... I think those skills would really broaden my resume.

I'm not yet sure if I should try to become a generalist, with a broad overview of SQE, or perhaps pick something like Selenium (to pick an example out of thin air) and just learn everything possible about it. I could see myself doing contract work, say going into companies with no automated QA processes and doing all the work of implementing Selenium, training the testers, establishing the protocols, integrating the processes between departments, etc. I'm great at all that kind of stuff, I just don't know Selenium :).

Right now, I'm just at the beginning of trying to figure out what I need to learn and how best to learn it. It's a rough sea of too-much information and too many acronyms out there for me to set out without asking for some guidance. Recommendations of books, blogs, websites, discussion groups, forums would be most welcome at this time, as well as any other advice you feel like sharing.

  • In your current job is there anything that has potential to be automated? What is that? – dzieciou Jan 25 '15 at 10:33
  • 1
    @dzieciou I have no current job. And my situation for the next 6-12 months is that I won't be able to accept any regular employment. Plenty of time for study and self-improvement, though. – Tod Hostetler Jan 27 '15 at 21:05
  • So what you learned? And what advice you may have for someone trying to repeat your experience? – Peter M. Jan 20 '16 at 18:18

A few thoughts based on my not-quite-ten years experience as a tester and automator:

  • Learn the principles, not a tool - If you understand the principles of automation and how it works, you're going to be in a much better strategic position than if you simply learn an automation tool. You could do worse than to dig through Joe Strazzere's blog and Alan Page's blog for some interesting insights into test automation as well as test management in general.
  • Understand different automation levels and techniques - Test automation can be performed at multiple levels, from unit tests (which should be written by developers and run with each build) through various forms of integration, module, and API tests, to GUI-level tests. If you understand the pros and cons of each kind of automated test, and where you'd choose one over another, your automation specialists will worship at your feet (maybe not literally - but having had to educate a number of leads on this topic, I can say that someone who gets it is very welcome addition to a team).
  • Understand the different purposes of test automation - Test automation can happen for a number of reasons. A lead/manager who knows and understands them is someone many testers love to work with - because they aren't having to justify "unproductive" time (yes, I've had this...). The most common, and what you'll see a lot of here is functional and GUI-based automation used for regression testing. Most of the big-box tools are geared towards this, and most of them use record-playback as their selling point. Which leads to my next point:
  • Record-playback should be consigned to the deepest pits of hell - It makes fragile tests that are hellish to maintain. The main reason record-playback is such a big selling point is because it makes it easy for someone with no programming background to create a whole lot of tests quickly. When I use record-playback, I use it solely to get object handles I can manipulate programmatically: this is the only valid use for record-playback in my opinion, and a decent object inspection tool can do the same job.
  • Automation is programming - This should be obvious to a professional with your level of experience, but it's worth repeating anyway. Automation is programming, and automation code needs to be subject to similar levels of inspection, code review, and code standards as production code. It's got to stop somewhere, of course, or you have tests to test your tests of the tests of the test code, but code review of all new test code and regular review of the tests being run is a must. Don't be afraid to deprecate tests that are no longer relevant, either: automation is a resource-intensive activity, and maintaining test code that's not being used in production is a waste of everyone's time.
  • I mined Joe Strazzere's blog for a wealth of other automation-related blogs from which I selected 8 to begin following, thank you. Your Alan Paige link is broken (and it is Page not Paige). Future readers of this thread should go to angryweasel.com/blog for that link. – Tod Hostetler Jan 27 '15 at 20:56
  • @TodHostetler - thank you for the update - I'll edit my answer to correct the link and name. Unfortunately, the web filtering at work is a little too zealous and blocks Alan's blog. – Kate Paulk Jan 28 '15 at 11:48

You already have a very solid foundation to build on, with your impressive knowledge about QA and your professional skills. If you can supplement that with more technical skills and expertise in test automation, you will have a very valuable (and rare) profile on the job market.

From my experience with the many excellent people I have had a chance to work with, I would suggest to work on the following aspects:

  • Knowledge about automation at a strategic level. How do you set realistic goals? What does an organisation need in terms of vision/policy, processes and roles? Which knowledge and skills are needed? And what are the technical constraints?

  • Broad knowledge of tooling. If by any means possible, try to get your hands on a few different tools to get a feel of what is currently on the market. Both open source tooling (Selenium, JMeter) and commercial tools. The ideal package would include tools for test management (such as HP ALM), testcase generation, test data management, automated test execution and performance testing.

  • Programming. Not just writing a few lines of code, but the real deal. In my experience this is often a real bottleneck and often underestimated. I'd recommend to follow a university-level programming course, that goes beyond just learning a language but also teaches you the basics in data structures, algorithms, etc.

  • Real-life experience. Make sure you get some hands-on experience, preferably working together with an experienced mentor. This will certainly speed up your learning.

  • Choose your focus. Either become skilled in a specific tool (Selenium?), or a particular problem-domain, etc. There is so much to learn, and if you don't focus chances are that you'll never get beyond the basics.

Good luck!

  • A 'university-level programming course' sounds intimidating keep in mind I have 6-12 months to devote. An example might help: I completed a 2-year program in Graphic Design. The same school offered a 2-year program in Photography. As part of the 2-year GD program, a 6 month primer in Photography was offered. Not enough to make you a professional Photographer but more than enough that as a GD you could talk the lingo, know what was involved and possible, work along pro Photographers, etc. If there is a parallel for QA Automation that could be recommended, that would be the ideal. – Tod Hostetler Jan 27 '15 at 21:19
  • Two introductory programming courses in a quarter system would be six months, and would teach you roughly 70-80% of what you need to know to be a decent programmer for the purposes of writing test automation. I agree with most of this advice, but disagree with "choose your focus" - beyond "writing test automation" and maybe "focus on one tech stack to start". Testing benefits from breadth of knowledge more than depth, IME. As you learn, try coding testing solutions for the kinds of problems you've tested manually in the past, so you can better leverage your previous experiences. – Ethel Evans Jan 30 '15 at 0:55

This is an excellent question. I had multiple times slowed down to ramp up. I would suggest to keep one core strength and develop on others on the fly.

Set Learning Goals and Identify Coding Exercises

  1. Coding for basic web service, writing unit test code
  2. Basics of Java Programming - Datastructures, basic programs exercises
  3. Basics of TestNG, Test mobile app using Appium, Test web app using Selenium
  4. Fundamentals of Automation Framework Design
  5. Basics of NOSQL, Big Data Vs RDBMS

Books Selenium Simplified - Automated Web Testing with Java and Selenium RC - http://www.compendiumdev.co.uk/selenium/

You are a proven team player, people manager. The goal of these exercises is Know How of How stuff works is good enough. For you to help in designing / reviewing you need to keep learning!!

So you would likely be geared more towards an automation lead role and less towards an automation engineer role. While having extreme technical experience is great, you should understand principles more than practice.

Development Principles

Learn the basics to a few different programming. Buy some development books that focuses more on the principles than any one specific language. Since it is unlikely you will be "neck deep in code" too often, you will likely be more responsible with consulting different partners and explaining your positions and ensuring that the project's long term goals are on track.

Automation Principles

Understanding how to automate is a major key. Learning Selenium is great, but if your system is using APIs on it's middleware layer than knowing SoapUI might be a better focus. Understanding what to automate, how to automate it and what tool to use is probably the most important thing you could possibly learn. Sadly this will to some degree only come with experience. The building of an extremely difficult to maintain GUI based automation system when there could have been an easy to maintain API automation built type of mistakes will lead to that experience.


If you hired a contractor and he tried to hammer in a screw, I think you'd fire him. Using the right tool for the right job is key. Knowing that while SoapUI can do Web Based testing, it is not wise for it, is crucial. Knowing that while Record and Playback scripts might give you the breathing room to build a maintainable Automation framework is useful, but expecting too much from those scripts could quickly get you either unemployed or without a staff. Knowing what is best to use for different situations is likely the most difficult task in the automation world. Tools are constantly changing and adjusting, all with a niche in a specific place. Learn them, know them and never stop studying them.

Where to learn

  • Question - "Buy some development books that focuses more on the principles than any one specific language" - Any specific recommendations? Further question - sounds like you are suggesting that I'd learn best by drilling down from my starting point on the Testing Pyramid, into automated GUI first, but always keeping in mind it's limitations, then drilling down further into Service, and finally into Unit Tests. I understand fully this is not necessarily the real world approach that would be used, but are you suggesting this is the best vector for a non-tech person to learn? – Tod Hostetler Jan 27 '15 at 21:35
  • 1
    Sadly, No books as I typically can not learn well from books. As for the GUI down approach it would likely best fit your needs as you are most likely aware of GUI level. The next step would likely be API and datalayer/database testing. – Paul Muir Jan 27 '15 at 21:39
  • I would recommend going the other direction - unit tests up. UI testing is one of the most challenging test disciplines to do well, and requires a solid understanding of object-oriented programming IME. – Ethel Evans Jan 30 '15 at 0:57

As a start, I would recommend going through this guys blog and working out all of the exercises on his site.

  • The specific link you gave was unhelpful but I spotted Dave Haeffner's name in the screenshot and a little googling took me to this link davehaeffner.com. Future readers of this thread that are looking for similar answers to mine should visit that site and then look for the Selenium Bootcamp tab in the lower right. I'm pretty sure that is what djangofan was trying to point me toward. – Tod Hostetler Jan 27 '15 at 21:43

You have really good experience and it would great if you learn automation tool properly.

According to me you should learn following tools :

1 - Selenium IDE [Basic selenium using firefox selenium addon to record and verify things]

2 - Selenium Web driver [Using this you can write your own automated script]

3 - Jmeter [It allow you to do best load/stress testing]

Above all are totally open source and having great capability to make almost everything automate.

Some helpful links :

1 - Selenium Web Driver

2 - Selenium web driver programs from basic to high level

3 - Jmeter

Automation will help you greatly to do repetitive tasks easy and fast. It will also save your time , efforts and human resources as well.

Dont forget about www.udemy.com as its a great resource and the teaching is well structured.

Now flipping this around a bit, where would you Tod Hostetler start if you had to teach someone on how to become a competent QA Manager as I seem to be getting more and more calls for a Technical QA manager with a development background. Cheers.

  • 2
    the second paragraph seems to be a question, not an answer – user246 Jan 25 '15 at 13:07

I don't know what SQE is (software quality engineer?) but if you want to get better at white-box approaches then learn to program. Python and Ruby are well known programming languages and both are useful to know if you intend to build automation using Selenium WebDriver. Once you are familiar with programming (or at the same time) start to learn WebDriver.

Building teams and building tools or automation require very different skill sets. One is not better than the other. If you are very good at building teams and you have a steady stream of opportunities then that's a reason to get better and better at team building.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.