Becoming QA tester: learn a language or QA methodologies?
I'm fairly new to the world of QA, have done some black-box and some automated testing, and now feel like it's time to step up my game. I have some basic Java skill, but far from strong. So, I was thinking, to increase my chances of finding a job in software/web QA field, would it be more useful to strengthen my java skill or, rather, learn about different QA techniques and methods? What would you recommend?
The method I normall recommend:
1) Look for job adverts/job descriptions for the roles you want to do.
2) Analyse the skills/knowledge/competencies being asked for.
3) Do a gap analysis of yourself against the role requreiments.
4) Improve self.
When doing the analysis try to see what advertisers are calling essential and what desirable as this can help determine what aer the key gaps. What to learn will be very personal as it is better to target something that plays to your strengths and interestes. Also consider if you can use it in your current envirnoment and get some practice.
The story so far:
In the beginning the Universe was created.
This has made a lot of people very angry and been widely regarded as a bad move.
Personally I would concentrate on learning QA methods and techniques, writing test cases etc. Most places will look for experience testing java, C, .net etc. You can learn java etc, but that doesn't qualify you to be a tester. IMO.
If I want to become a plumber, I would not study the job of an electrician.
I pick the parts of Quality Center that I want to use for Managing the testing. I see how they link together. That becomes my QA Method for management.
I used the manual portion of QC for a while. Then started creating simple record/playback scripts.
Then the scripts became more advanced.
I don't think that the formal Requirements to scirpts relationships is a complete answer. The part thats missng from this idea is curiousity and exploration. Many errors I see in software would not be found with the formal ideas.
robtam90...I was wondering what you mean. Sometimes electric switches, signaling, monitoring of water supplies is done using electronics. Hydro Electric is another combination of the two technologies.
He's basically saying you don't become a tester by learning how to write code. I started out as a developer, and fell into QA finding it much more fulfilling. I've been able to leverage my developer skills into automated testing, but it takes analytical skills to understand requirements and specs and applying that analysis to what you actually get from development. I think studying QA methodologies will get you much further than sharpening your java skills. If you need java on the job, those skills will get better as you go.
Personally I think the next generation of testers will also double as test developers. I don't think you'll have much of a choice on focusing on either, you'll need to learn both. More and more emphasis is shifting towards automation, but in the past QA coding standards have been just get automation scripts created. However more and more companies are finding that maintaining and scaling up the scripts have become a bottleneck.
I think you'll find that you'll start seeing better coders than the developers in QA in the very near future. There's alot of skill net necessary to make your tests maintainable, scaleable, and be able to refactor large amount of code to adapt to an ever changing software under test. Let's say dev switches out a front end framework to 1/3rd or their application as part of a technology refresh. Business does not want to wait just as long as it took devs to do the work to release just because they're held up by QA. Especially since most Agile organizations will run very lean QA to Dev ratios.
You can already see this movement in the "Dev Ops" field. Where Ops is now expected to code complicated deployment scripts that's far more complicated than writing a simple front end script that most Jr. developers will be working on. I'll also suspect we'll one day see Dev skill sets creeping into sales and marketing. With sales becoming increasingly dependent on APIs like SalesForce, google analytics, crazy egg, etc... for harvesting vast amounts of information and converting it to leads, etc...
But they'll also need to have a good basis in bug and test coverage theory, and risk analysis to avoid more work than necessary. Business will of course want you to "Test Everything", but how do test everything when you do have enough time. So having that crucial QA grounding will be necessary. QA's job has never been there's not enough work to do, it's always the opposite.
Last edited by dlai; 03-24-2013 at 11:19 AM.
Peter...Did i say something rude? I read through the thread. I don't see anything rude from anyone. I hope everything is OK.