This is kind of Testing 101, yet this still needs to be explained.
The common perception among non-technical people and even among some testers is that testing is to find defects/bugs. I have interviewed a fair number of people for testing positions and I am still surprised when I hear some harboring such views.
The main purpose of testing is to minimize risk for any application.
Trust me when I say that no product can be defect free. No company has unlimited budge, resource or time frame to test any application indefinitely until it is 100% defect free. From the inception of any application to its ultimate release, you always work against a deadline. Recall all those iPhone, Windows, Google press release about certain product’s official launch? This is why good Test Managers are paid handsomely, because they know how to deliver applications successfully.
The good Test Managers understand that no application can be defect free. So they plan the entire test strategy on minimizing the risk of allowing defects to production.
One of the key elements in my view for a good tester is to adopt the mentality of a “destroyer”. His job is to break the application. I have often come across testers who want to test the positive scenarios only to ensure that the application works. My personal opinion is that if a tester, despite all his efforts, cannot break an application, then he has minimized the risk of introducing defects into production.
The other key element for a good tester is the ability to perform risk based testing. While many esteemed Testing gurus have written articles on this area, such as James Bach, how you execute risk based testing may depend on the specific application, the SDLC (Software Development Life Cycle) process etc. For example, in a waterfall method where you have a base-lined requirements documents, you can sit with the relevant stakeholder or Subject Matter Expert (SME) and have a walk-through of what is vital to the stakeholder/customer, what has the highest impact and what forms the lowest priority areas. Then you can create all your test scripts and ask the stakeholder to review the coverage. Areas that are deemed to have highest business impact is likely to have a larger coverage than low impact areas. You can use different metrics to measure the extent of test coverage for the impacted area. There are some very good literature out there that explains how to use metrics for risk based testing.
I believe that anyone can be a tester, however to be an expert tester one needs years of experience. I know of software Test Managers who have come from Accounting background, or brilliant testers who have never gone to university. However, every tester needs to continually improve himself. If you think you know everything, then that would be the end of your growth and there is every chance that you will not be able to move up the career ladder. So keep reading, learn new techniques and share your knowledge. Remember, if you are a Test Manager, then the more you empower your team, the better they will be and the better you will appear to the upper management for the excellence of your team. While your team does the job, you will get the credit.