Equivalence Partitioning & Boundary-value analysis

Equivalence Partitioning-
A good test case is a test case which has a reasonable probability of finding an error.But as we know,exhaustive input test of program is impossible and that is why we are limited to trying a small subset of all possible inputs.So we want to select the right subset which has highest possibility of finding the most errors. One of the possible way of it is equivalence partitioning.

The equivalence classes are identified by taking each input condition and partitionoing it into two or more groups.
e.g.-for a "X" condition,we can partition it in the valid equivalence class which represents all the valid inputs and invalid equivalence class which represents invalid inputs.


Boundary-Value analysis-
In Boundary value analysis,boundary conditions are on,above & below the edges of input  & output equivalence classes.
Unlike equivalence class,it requires one or more elements to be selected such that each edge of the equivalence class.

Walkthroughs

The Walkthrough is a set of procedures and error detection techniques for group code reading. The process of walkthrough is very much similar to code inspection. In walkthrough, generally 3-5 people participate-moderator,secretary who records all errors,tester,the person who will eventually  maintain the program and someone from different program.
In walkthrough,instead of reading the program/code, participants execute the test case mentally.These test cases are prepared by tester. The walthroughs should be followed by follow-ups.

Code Inspection

A Code inspection & walkthroughs are two primary human testing methods. The objective is to find errors & not find solution to the errors.
A code inspection is a set of  procedures and error detection techniques for group code reading.An inspection team usually consists of four people-moderator,programmer,test specialist & program's designer.
The moderator distributes the program's listing and design specification to the other participants.In the inspection, programmer narrates the logic statement by statement.Other team members should raise questions & try to determine whether error exists or not. The program should be analyzed with respect to a checklist of historically common programming errors.

Classification of Bug

Bug is classified according to the impact it has on testing efforts or users. It is very important aspect of Bug Management.

1.Critical/Show Stopper - A defect which prevents further testing of the product or function under test is classified as Critical or show stopper. No workaround is possible for such bugs.
e.g.-Missing menu option  
 2.Major/High - A defect which does not function as expected or cause other functionality to fail can be classified as Major or High.
e.g.- Wrong payroll calculation
3.Average/Medium - The defects which does not meet the norms & conventions can be classified as Average or Medium.
e.g. - Missing links.
4. Minor/Low-These bugs are defects which does not affect the functionality of system.
e.g.- cosmetic bugs.

Bug Life Cycle

Before looking at Bug life cycle, we should know what is a bug.In terms of software,bug can be defined as the abnormal behavior of the software.

               In SDLC, the bug has a life cycle & it should go through the life cycle to be closed.

Bug Life Cycle

1 New - When a bug is introduced for the first time,its state is 'New'.
2 Open - After bug is posted by tester,the lead tester verifies if bug is genuine and changes its state to    'OPEN'.
3 Assign - Once bug's state is changed to 'Open',bug is assigned to corresponding to developer and the state is changed to 'Assigned'.
4 Resolve - After developer fixes bug, he has to assign the bug to testing team for the further testing(regression testing).At this point, bug's state is changed to 'Test or Resolve' which specifies that the bug has been fixed & is released to testing team.
         4.1 Deferred - When the bug is expected to be fixed in next release, its state is changed to 'Deferred'.
        4.2 Rejected - If the developer feels that bug is not genuine,he changes its state to 'Rejected'.
       4.3 Duplicate - If bug is repeated or two bugs mention the same concept of bug, then bug state is changed to 'Duplicate'.
5 Verified - After bug is fixed and tested and if bug no longer exists in the software , the state of bug is changed to 'Verified'.
6 Reopened - If the bug still exists even after the bug is fixed by the developer, the tester changes state to 'Reopened' & bug traverses the life cycle again.
7 Closed - Once bug is verified, bug's state is changed to 'Fixed'.

Inspiration

Hi all,
Well I have tried many times to keep blogging but always failed to keep track after few posts.Besides I have never tried to blog about testing.You must be wondering then why on the earth am going to do that now...Well I have kept this documentation about stuff which I find confusing which are pretty basic concepts & definitions but are very important & want to share it with everyone.
Anyways,Guys,wish me luck for this effort.(Feedback is always welcome)