Though the duties of the various team members of a project are different, they all aim for the same thing--producing a quality product. Yet the only team member who can assure this, and must, is the QA Engineer. The author explores how everyone on the team, especially testers, can help to achieve the main goal. These jobs require qualitative rather than qualified people. And that is quality assurance.
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.
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