A Tester is a person who is able to rapidly discover highly relevant information about the product, who makes the most use of any resource that is available to him/her, and who has the respect of people involved in a project. It is a person who can be trusted.
There will be times, when as Testers you will encounter circumstances where you have to defend your findings. You will have to convince people to take action, so you’d better know how to explain why your findings are relevant. I glad to a tester and I love this job as it is a process oriented job. My work spans from analyzing the requirement documents to writing Test plans, Test cases, Testing the applications, Logging defects in defect tracking tool. (In market there are n number of tools are available like Redmine, Asana, Jira, Pivotal, Bugzilla). If you will search the following keywords on internet you will get know about these tools.
Another reason why I love testing is that I have a keen eye for details and defects dont escape my sight easily. The more defects i find the more happier I am. Developers code in a straight line (180 degree) but a Tester has to think from all directions (360 degrees). In testing indubitably first we need to verify the process to ensure that the work product meets their specification and then we validate if the product meets the client’s requirements in the intended environment or not.
As a tester one question is always on my mind that how I ensure that I cover 100% testing before giving a release to the client? Which is next to impossible in real world scenarios, and once discussing about the same with my senior, he happened to mention about “Exit Criteria”. He went on to explain that “The exit criteria says – the software will be acceptable to the client only if there are No critical defects, No high defects, No medium defects, Only two low defects.” Thus only two low defects are acceptable and thus 100% coverage is measured by this exit criteria.
Let take a look at what are the different ways of how we Testers go about testing every module that comes our way:
Black Box vs Grey Box vs White Box
| S.N. | Black Box Testing | Grey Box Testing | White Box Testing |
|---|---|---|---|
| 1 | The Internal Workings of an application are not required to be known | Somewhat knowledge of the internal workings are known | Tester has full knowledge of the Internal workings of the application |
| 2 | Also known as closed box testing, data driven testing and functional testing | Another term for grey box testing is translucent testing as the tester has limited knowledge of the insides of the application | Also known as clear box testing, structural testing or code based testing |
| 3 | Performed by end users and also by testers and developers | Performed by end users and also by testers and developers | Normally done by testers and developers |
| 4 | Testing is based on external expectations – Internal behavior of the application is unknown | Testing is done on the basis of high level database diagrams and data flow diagrams | Internal workings are fully known and the tester can design test data accordingly |
| 5 | This is the least time consuming and exhaustive | Partly time consuming and exhaustive | The most exhaustive and time consuming type of testing |
| 6 | Not suited to algorithm testing | Not suited to algorithm testing | Suited for algorithm testing |
| 7 | This can only be done by trial and error method | Data domains and Internal boundaries can be tested, if known | Data domains and Internal boundaries can be better tested |
