Automated or Manual Testing

"Better" implies a value analysis. Some folks are good at manual testing andpoor at automated testing simply due to their make-up. Trying to trainsomeone who really is not cut out to be an automated tester will yield poorresults. A good automated test engineer needs the predisposition of atester, but also the mental composition and interest of a developer.Finally, in the U.S. at least, automation test engineers are normally paid apremium, averaging 20% more in salary, than manual testers. On average,remember, so there will be exceptions in industry segments. The reason? Theyhave to know some programming and development.Regarding the relative stability of employment you think manual testersenjoy compared to automation types, I assert that is domain specific to adegree, but more probably company specific. If you work for a company whodiscards testers proficient in Tool A when they bring on board Tool B, thenyou need to look for a job elsewhere. The management of such a company is ingrave need of a clue. The specific techniques for Tool A and Tool B will bedifferent, but the approach to test automation, the design and architecture,the discipline and engineering of it, is directly applicable regardless ofthe tool used. And that experience is more difficult to find in employees. Ican teach just about anyone with half a brain (which, from my experience,excludes some half of the candidates) how to use any tool to a basic anduseful degree of proficiency. Only a few will ever have what it takes toprogress to intermediate proficiency. Most companies choose one solution andas that improves or changes, they make sure their employees improve andchange too. It is an investment that is in the company's best interests. Ifthe underlying technology of the product radically changes, then the testapproach -- and tools used to implement that approach -- probably will haveto change as well. Client-server vs. web browser-based would be a commonexample. Moving from C++ to Java is another example.Regarding domain specific cases for stability, it is the knowledge of thatdomain and the prior product versions that makes the tester valuable morethan the fact that the tester is a manual tester or not. I worked for acompany where the QA testers pretty much had to have the equivalentknowledge base in geology and petrophysics of at least a Master's degree.Several were PhD level. THAT knowledge and experience of product, or how theuser community used the product is what made them employable at thatcompany. How they tested the product was less important.One last thought: many companies are sold a proverbial "bill of goods" bysaavy sales reps from the automation tools vendors and are convinced Tool Ais the complete and end-to-end solution to all their testing challenges.When it doesn't pan out, due to lack of training, lack of organization andarchitecture, etc. etc., the company management tends to want to jettisonthe tool that let them down. The tool users often are jettisoned as well, aspart of a failed project. This happens all too often. Then the next "silverbullet" be-all and end-all Tool B sales rep comes along and convinces thecompany that IT'S product was what the company should have had all along.New tool and new tool users come into play. Normally, the same resultoccurs, because it is the test management of the company that doesn't knowhow to implement test automation, and the same guys are there time aftertime after time, making the same mistakes over and over.

Relation between KLOC & Test cases

KLOC means Kilo Lines of Code means 1000 Lines of Code

so KLOC = 1000 LOC
10 LOC = 1 FP ( Functional Point)
we can design 3 test cases from each Functional Point

1 FP = 3 TC ( Test Case )

1000
------- = 100 FP
10

so 1 KLOC = 100 * 3 = 300 Test Cases ( we can write approximately ....this is according to my comp test metrics )

Getting the first break in Quality Control

Please let me begin with a clear note that I am writing these for candidate who are well deserved as QC professionals. They have systematically learnt QA process, and are prepared for this break. Please don’t misunderstand that I am writing this for people who think QC is a stop gap. A good QC professional is best in his breed and has selected this career not as the last option, but as a career of his choice.

I have found that approaching directly to a company with no experience has often been fatal. If you are extremely lucky, you may get pass the HR scanning but the QA manager will have a high probability of not selecting you as he also is answerable to someone. He would not like to gamble when there are other more experienced candidates.

I have found that if you want to get a jump start in your career, please approach the small consulting firms who are second level vendors. They often have more time and are more willing to listen and interview you.

Once you get on to their list, they often can you get a good break.

This is how it works: When IT departments or companies need people in rush for short medium or long term projects, they often approach their top vendors to produce skilled staff for the same. They often rate these vendors efficiency on a quick turn around not to mention also pay them a butt load of money. They assume that skilled man powers could be bought in supper markets.

So these vendors to prove point, as they also have to compete with others, resort to these second level vendors. These are the times when your consulting firm whom I am referring as second level vendors, pushes your resume to the direct vendors. In these cases resume scanning less stringent and sometime even an informal interview can get you in.

Once you are in it is up to you to prove your worth.

I am not saying this works always but I have seen many people getting their first break in QC in similar fashion.

I know many of you may not agree to this. But if you have other suggestions, please go ahead so that the candidates who are looking for their first break can use your help in this regards.

Of course networking, forums, groups etc helps too.

Worst resort, get into a company as an intern. Trust me, if you are good in your job, it won’t take time for you to be recognized and rewarded appropriately. There are always shortages of good QC personnel.

How to be a Good software Tester/QA Engineer

• Be a self learner about new technologies and new QA methodologies and keep an eye of development techniques as well.

• You should look at the products or projects that you have recently released and find out if you missed any defects (you will learn more about testing)

• You should be learning new techniques and studying new tools that are applicable.

• You should get off your butt and show some initiative.

• Dealing with developers to get the bug fix of other kind of QA activity is a skill. Try to understand the developer attributes and work according to that.

• Learn how to write effective test cases, Minimum number of test cases with maximum test coverage

• Never judge you team mates or rank them with you. Think that all the team members are equal since all of them working for same company and same company goals.

• Try to learn some programming languages and to some simple code, which will help you one day to be a good QA manager who understands Greek of developers?

• You should be experimenting with back-up and restore tools for your test lab
  such as Ghost, Drive Image, and Frisbee