Twisted Testers

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

For more blogs stay tuned with twistedtesters.blogspot.com