"After becoming a QA professional, you started finding fault in everything." This was my wife's response when I pointed out the excess salt in my dinner. I then told her the story of the testing company that lost its business when the representative of the company claimed that they only "test to pass the system."

Initially the testing was a sub-set of the Software Development Lifecycle (SDLC) and the developers performed the validation in the software programs coded by them. They then released them to the users for verification of the critical business flaws before starting production. The volume of business losses due to the inherent bugs in the systems has lead businesses to get independent verification and validation.

Stand Over the Developers
While the developers concentrate on the allocated programs and modules, the testers need to see the overall perspective of the application. If a programmer understands the functional and design specifications of the functions allotted to him, he can do a better job. But testers should broaden their vision to understand the entire functionality of the application. Testers should be comfortable with inputs, expected results, and data flows between modules and interfaces.

Unless you have a thorough knowledge on the functionality of the system, it is difficult to gain overall insight into the application. So, before you involve yourself in testing an application, make sure you spend enough time understanding the complexities of the functionality of the application under testing. Knowledge of the system will help you: suggest valid improvements to the system, perform a complete meaningful test on the system, improve your leadership capabilities by extending help to other testers, and substantiate your arguments while defending the defects found in the system.

Plan to Crack the System
Perhaps you may have read the 70:30 Project Management story in circulation on two different types of Project Managers. Structural Planning is the basis for sound testing. Instead of tardy, unstructured planning, you should spend 70 percent of your time in systematic planning and preparation of the test strategy, testware, and test execution methodologies. By doing that, you can execute the test unblemished within the scheduled timelines. Always remember to:

• Plan the execution schedule.
• Review all the test documents.
• Add traceability to ensure coverage.
• Prepare the test cases and scripts.
• Plan the data requirements and availability.
• Decide on the proper strategy depending upon the types of testing required.

Crack the System
Change yourselves. Crack the system. Create implicit test conditions and cases. See the system from the user's perspective. The role of QA is gaining more importance since the various systems in production are still inflicted with bugs. These defects lead to unexpected down time to the business. The financial loss caused due to bugs and downtime is higher. Bugs in mission critical applications may be catastrophic. And the board is becoming responsible for the unexpected business loss due to bugs.

As a test engineer you perform your role. Verify and validate the system for the business user requirements. Even if you detect hundreds of bugs nobody will appreciate it because you are performing your job. But when one unknown defect is unearthed in production it will fire back on the entire QA team. Your role is ensuring that no known bugs exist in the system.

Identify and Improve Processes
Although test engineers need to work within the defined boundaries of the processes and procedures established within their work environment, there is always room for continuous process improvement. Expect the unexpected. Identify the loose ends in the process and bridge the gaps with innovative quality improvement processes. Analyze the pattern in the defects identified in the previous releases of the application. Tighten the test cases to capture the hidden defects. Perform a complete review for ambiguous statements in the requirements documents, which may give rise to different interpretations and ultimately to bugs in the system.

Develop a Killer Instinct
Follow this list to help you develop a killer instinct.

• Deliver quality.
• Avoid repetition.
• Test to destroy.
• Improve the process.
• Create knowledge base.
• Analyze the test results.
• Verify the test environment.
• Help others to learn more for you.
• Do not hesitate to take help from others.
• Read between the lines in the base line documents.
• Generate required data to execute all the test cases.
• Emancipate lateral thinking in developing test cases.
• Arrive at the gap between various base line documents.
• Learn the new testing technologies and tools around you.
• Continue updating your business knowledge. It is because of that business we survive.
• Improve proper communication. Improper presentation has sent several testers home.

You cannot have your cake and eat it too. Unless the system is put through rigorous testing, the credibility of the QA team will be undermined. Place yourself in the shoes of the business users. Your interaction with others may give rise to different perspectives, which will fine-tune your test cases and help you unearth a hidden bug.