Importance of test automation experience to advancing in QA departments

Question

I am a test engineer with about 7 years of work experience. I am not an computer science / engineering graduate. I have done a post graduate conversion course that included a good mix of software engineering and management subjects.And my experience so far has been in both manual and automation testing.

Through my years of experience I have acquired good knowledge and practices around the testing paradigm - its methodologies, and have been able to successfully complete projects with a good testing approach, scope and the likes. In terms of automation, I can develop test cases easily, but not really develop frameworks. I find myself a little lagging behind in automation in this regard. Though I can grasp and comprehend practices and approaches used in automation, I am not necessarily an automation expert.

The situation I am in is - that to me, it looks like automation is valued more in teams these days. And since I am aware I am not proficient in it, at least not as much as I'd like to be, I feel I might not be able to grow in the QA hierarchy.

Though I believe automation is a tool among many other things that make up the QA paradigm, I think manual testing is grossly under-rated. So, my questions are:

1. Is it a correct inference in today's software world, that in order to grow in the QA organization, one must champion automation skills? (in any 1 language that is. I know. I am not talking about knowing how to code. I am talking about knowing how to build frameworks hands-on)
2. How do I market, my capabilities in a way that does not show my lack of automation expertise in a bad way, but I am able to convince my peers and manager that I still have what it needs to climb the rungs of QA ladder?
3. How do I leverage my QA skills so that I do not fall behind my peers who have the automation expertise advantage?
4. What other skills should I be proficient at, in order for me to be considered promotional material?

Note: It is not that I am not trying to strengthen my automation skills, I am. But do I need to?

IMPORTANT: I want to let the readers know that I am a believer in automation. The question is not about whether one should automate or not. The question is that skill needed at expertise level to get up the rungs of the corporate ladder in QA vertical.

Answer 1

QA automation is coding using specific library, usually Se Webdriver. If your goal is to advance toward management positions, advanced coding skills are almost irrelevant (basic coding skills you already have might be enough).

Dare I say, not being CompSci graduate might be even a positive, because CompSci graduates tend to be introverts, and management position requires more focus on communication skills (usually not a strong point of introverts).

If your coding skills are OK, and you want to be a QA manager, I would suggest (when considering T profiled skills from @FDM answer) to make your communication skills the deep part, and cover the shallow part just enough: Become OK in networking, system administration, database administration and design, have intro level knowledge of most tools your QA uses. So you can understand the concerns of the different members of your team and negotiate between different priorities, without micromanaging (let them own the technical side of the problem).

Hard part is how to maintain adequate sharpness of your skills in all those areas without spending too much time in any of them, when so much of your time would be spent in meetings... :-(

Answer 2

It depends.

Career growth opportunities for QA/Test vary widely depending on the organizational culture, the area, the size of the organization, and so forth. Companies in tech hub regions tend to have more career growth options than companies that aren't, some countries have a different view of what makes a good candidate for a promotion... The variations are endless.

That said, there are some common factors:

• Most organizations prefer to promote someone who's been effectively performing the role they're aiming for (because they have an observable, verifiable history of your ability to act in that role). So if you're wanting to move to Test Lead/QA Management type positions, you need to be volunteering to act as your current test lead/manager's backup and second.
• In my experience, the ability to translate between "programmer-geek" and "management-ese" is much more important to a test lead/QA manager than the ability to build automation frameworks. The best automation in the universe doesn't help your team if you can't effectively communicate the results to your managers.
• Understanding how automation works and why it's more complicated than tool vendors make it seem is essential to a test lead/manager. Being able to build your own framework probably is not (but there will be some places where it is).
• Being able to give broad estimates of test effort required that are moderately accurate and supportable is more important to a test lead/manager than being able to build test automation. (By "moderately accurate" I mean you should be able to look at a high-level description and say "That's going to take several months of testing" or "That's a few days of testing" and be in the right general range. If you're in an Agile environment, it's the T-shirt-sizing level estimation of epics/features to help stakeholders decide how they want to prioritize)
• In my opinion the most important aspect of a test lead/management role is to act as a buffer between your team and the rest of the organization. The test lead/manager role is a typical low-to-mid-level management position where the key responsibilities are communicating status to higher positions, and ensuring your team has everything they need to meet their responsibilities. That means if there are problems, you take the heat so your team isn't distracted. It means you resolve conflicts between team members. It means you track down resources for you team members and protect them from unreasonable demands.

Of course, if you're looking towards a test automation lead position, this is a completely different situation: that position tends to be much more of a technical leadership role than a managerial role, so extensive understanding of automation frameworks and software development is much more of a requirement.

Answer 3

Under growing 'vertically', I understand going to test lead and test manager positions.

As far as I know, a test lead or test manager is usually not going to automate. A test automation/tooling expert can be very valuable as a senior employee (just like an experienced manual tester) but they are still working 'hands-on' (executing, not managing).

A good test lead knows what it's like to automate, how much time it might realistically take to set up a framework or to code new tests, and what are the benefits and risks (maintenance effort, ...).

So, if you're constructing yourself as a T-Profile you need technical testing as part of your broad skillset, but your in-depth knowledge should probably focus on the conceptual side of testing and management skills.

Answer 4

Do I need to to strengthen my automation skills to advance?

My experience is yes. I was a developer for 20 years before moving to QA. I like manual testing as well as automated testing. I have also, like yourself, noticed that there is a huge emphasis on the automated part. Part of the problem is that manual testing is often assigned to junior or unskilled members. It is often done poorly in such cases as they lack domain experience, a factor that is frequently over-looked.

I have found that it works best to accept this, practice the required skills and write some automation. However, don't stop doing the other stuff. You still need to do manual testing, talk with the Product Owner, push Integrated testing as well as Unit testing. You still need to promote performance and scalability. You still need to promote usability. promote security.

For automation, think carefully about how to add automation with meaningful tests that actually fail usefully. It is easy to write a lot of automation that doesn't fail but takes a long time to run. It is also easy (as in hard to avoid) to write UI automation that fails intermittently. This is very common in UI automation and as a QA developer looking to advance you can promote best practices and techniques that help to avoid this.

Become a champion at the many aspects to Quality Engineering and make automated testing just one aspect of the puzzle that you are helping solve.

Some of those other aspects include:

• knowledge about usability issues and approaches to address them
• knowledge about standards such as W3C, section 508, etc.
• passion for representing the user experience
• persistence in raising UI issues until addressed
• social skills in discussing bugs which may feel like criticism to developers.
• continually learning more and newer domain knowledge
• continually representing the customers points of view
• testing performance under real world conditions
• putting on lunch and learns to teach others about usability, automation, etc.
• learning the language and frameworks that devs are using so you can converse with them.
• command line proficiency and vim proficiency may impress some managers
• learn about security, the risks and threats and approaches to address them.

Answer 5

As per James Bach testing has 3 roles:

1. Test Lead/ Test manager
2. Responsible Tester
3. Supportive Tester

Its the Responsible tester who develops automation frameworks and design testcases.

Supportive Tester writes/helps in test case development.

Automation is just one form of testing called 'Checking' (which verifies output). There are other forms of testing/test activities where Test Lead/Test Manager plays his role:

• Cultivate and support responsible testers
• Reporting to clients/management
• Developing Mind maps
• Defining test strategy
• Team building

But of-course, Technical skills helps a Test Lead/Test Manager to perform his activities more relevantly.

Refer: Rapid software Testing.pdf

Answer 6

I think manual testing is rated as it is: A tedious, repetitive process, that can be partially avoided with automation. You don't need to know automation to be a good QA, but you need to push it in your team to be a good QA in my opinion.

You seem to want to be promoted..What I would expect from a Head of QA:

• Push for automation, because it saves time and gives you a feeling of security.
• Know how to prioritize. This does not mean the typical bullshit everyone says, "I'm good at prioritizing", it means knowing when you can deploy even if there's a bug, or if you have to tell other people, we're not releasing, we have a situation here.
• Very good comunication skills. To me this means being consise, write tickets / tests that are easy to understand. Able to talk to both devs and non-devs
• Very good understanding of your product, including the technical part. Or ability to do so

The skills I list are very general, but I don't think you need special skills to be a good QA lead. You need to be someone other people can trust, because product quality should be in your hands: You know the product, its problems, and you're able to communicate them and prioritize what will be fixed.

Answer 7

I like dgmora's answer.

@Op, I am in the same position as you. I avoided learning automation because I either thought the learning curve would be too large or that the time/maintenance time to get things up and running made it not an option.

As a result, in our previous projects (without automation) we ended up having gaps due to not being able to regress efficiently. Also, we ended up with stale manual tests, because test maintenance can also be an issue for manual tests as well.

I finally bit the bullet and started learning to automate. It was much easier to get going than I thought, but it also changed my whole view of testing. Automation is just another tool in your toolbox. You wont want to automate everything, but in the long run, the things you do automate will free up time for you to focus on more important things.

I wish I knew this, because not having automation suites built, it became UN-maintainable for us. With hours in meetings and working on multiple releases and multiple projects, when our test phases began, we were way in over our heads.

Tl;Dr

• 1)Automation methods are just more tools in your tool box (like manual methods)
• 2)Not everything can or should be automated. Some things can only be tested through automation, and other things are just more efficient to automate.
• 3)By using the best, most efficient tools for each task, you'll increase your coverage, reliability, and hopefully free up time to address quality in other ways.
• 4)For both manual and automated, if you develop maintainable tests and continue trying to optimize, you can only help your efforts.

Answer 8

I started as a programmer and stayed that way for many years, until I was appointed to a QA lead position. I had already known how to write Unit Tests as a developer and knew the proper methodology to apply. I started the QA team and taught the Manual testing team the exact same principles as I had learned as a programmer. They did a great job and the team was very well received.

As more and more web applications came into play there were many calls for more and more automation. For me it was a natural fit and provide a depth career wise that was sorely needed.

My belief is that the QA person of the future is an embedded member on the programming team who is fluent in writing automated tests and collaborating directly with the development team on what they are working on now (as opposed to dumping it onto the QA team later). Developers appreciate and need immediate feedback on their work.

Answer 9

Yes, it is helpful to know or have done some of the most popular automation techniques out there to advance or get the best jobs out there. I agree with many here that manual testing can be a great under-sought skill, but those doing the hiring love automation because of the perceived (and often very real) time savings it offers. As testers, we are often at the tail end of a release cycle and the blame falls on us too often.

I am also not the strongest programmer out there, even though I've been a software engineer for a short time. Just give any of the popular automation test methodologies a try whenever you can and be patient. Over time (and some internet searches), you'll slowly pick up more and more.

My opinion to your questions:

1. Much of the time, yes. You say you grasp the ideas behind automation but are not an expert. To me, just dive in, admit you need help, and ask questions and do your best!
2. Take every new task you can and add it to your personal toolkit. Also, do things like make the best reports, log the most bugs you can, support your coworkers, and show you are a leader.
3. See #1 and #2 above.
4. I think writing and communication are key. Also, for me I became very good at setting up networks and network analysis, something many people I worked with did not know or understand. It made me stand out and look knowledgeable. Is here something similar at your job?

Answer 10

Today, Test Automation is considered as one of the most trending term in the field of software testing, as it is considered as one of the most efficient as well as effective software methodology, making the overall software development/testing life cycle better and taking it to some different level. These days as software testing is moving towards automation, most of the software testers as well as QAs are switching themselves from Manual testing to Automated testing.

Some of the reasons, why automation testing is considered as one of the trending methodology and has a vital scope:

• Automation testing saves time as well as money.
• It is considered as cost effective method,
• Increases Test Coverage,
• Makes testing more accurate,
• Better Execution control,
• Provides better and concise results,
• Optimized resource usage, etc.

All these reasons make automation testing more effective as well as more efficient, resulting in better test outputs.