Quality:
Quality is assured by the actions of a QA Engineer. This makes it necessary for a tester to embed quality into his own actions. Quality is to be “perfect”. A Quality Assurance Engineer should perform with perfection, if he has to bring out a quality product.

Responsibilities of a Tester:
Well, let us start with what the responsibilities of a tester are. All the responsibilities of a tester are derived from a sole responsibility, which is 'Software Quality Assurance' which means, 'making sure that the software exactly matches the requirements'. 'Requirements’ here does not refer to the ‘requirements specified in an SRS document’, they refer to the ‘User's Requirements'.

He is more responsible than most others:
Now, let us see how responsible a tester is. The project team consists of several people like business analysts, designers, developers and administrators. If any of these team members does a mistake, (human inability to perform with perfection…) here is tester to find out the mistake. But if the tester himself makes a mistake, there is nobody out there to find it out except the customer. And the reputation of the product is degraded! And of course, there is no end to how big a loss a single bug can result in. All these possibilities place a tester in a highly responsible position. And the tester has no choice, he should NOT make mistakes. He should act qualitatively.

Bug the Business Analysts:
Acting qualitatively requires Planning and Uncompromising attitude. Do not proceed further if you don’t properly understand the requirements. Bug the business analysts, it is no sin. (You need to have gone through all the related documentation, by then!) Improper understanding of the requirements can result in a greater loss at a later stage, if not now. On the other hand, your feedback of requirements helps the analysts to realize the gaps in requirements and correct them.

Changing Requirements:
There is another havoc with requirements, the change. Divide the requirements into 2 categories, ‘not likely to change’ and ‘likely to change’. Start writing down the test cases for the former category first. If you are lucky enough, ‘likely to change’ requirements change before you start the writing the test cases for them.

Test case design:
Coming to test case design, unanimous answer is hard to obtain for the question, ‘How many test cases a particular functionality deserves?’ Bringing down huge ideal number of test cases to a manageable number is always challenging. It requires experience along with knowledge of various testing techniques and observation of previous bug patterns. If you do not have sufficient experience to decide on a particular functionality, try grabbing the experience from some other sources. If you still cannot be sure, choose a greater number of test cases and work for long hours.

Though you need not do white-box testing, have a basic knowledge of languages used for developing the AUT. This knowledge helps you in effectively choosing the test cases.

Automation: Exploit it
It is in the tester's hands whether to make automation a pleasure or a burden. Just because you have a tool, you need not automate each and everything. Clearly deciding on what to automate and what not to automate helps a lot.

Incorporate Software Development Life Cycle into the Automated Test Script Development. Never run an automated test script without properly testing it! That may double or triple your time and effort on that script.

Automated Test Script Development Life Cycle:
Here are the phases of Automated Test Script Development Life Cycle:

Objective: Test Case Execution
Requirements: Test Casesbr> Design: Module Design, Test Data Design, Framework Design
Coding: Recording, Checkpoints, writing/modifying the code
Testing: White-Box testing is recommended!

Changes in AUT:
Make a list of all the changes the developer has made to the build, before starting over one more round of regression testing, especially changes made to the GUI. That will help you change your automated test scripts too, and you can save yourself from test failures due to changes in the AUT.

You can use your time saved by effective automation, to more extensively test the AUT.

Automated Tool:
Try to be modestly perfect with the automated testing tool before you start recording the tests. Having a clear idea about what the tool can or cannot do, saves lot of your time and effort. Keep the contact details of the technical support of the tool handy. You need not wait till you get into problem, to clarify your doubts with the technical support of the tool. You need not even wait to inform the bugs you came across in the automated tool itself!

Quality Assurance:
Though the duties of the various team members of a project are different, they all aim the same thing, i.e., the quality of the product, ensuring which, is the sole and whole duty of a QA Engineer.

That is why it is a job that requires qualitative rather than qualified people. It is Quality Assurance.